Version the rule before testing the product
OCR issued the proposed update in December 2024 and maintains a page describing the proposal. OCR's Security Rule page separately describes the existing standards for electronic protected health information. Keep those two source roles distinct in every question and buying note.
Record which source, publication stage, and checked date a diligence question comes from. Do not rewrite proposed requirements as current obligations, and recheck the Federal Register and OCR because rulemaking status can change. If the status changes, add a dated update rather than silently rewriting what governed the earlier review.
A proposal can still expose weak questions in a procurement process. Use its topics to ask for clearer evidence now, but label the exercise as diligence under the practice's current obligations and risk analysis—not as proof that the proposal is effective law.
Map the data and responsibility boundary first
Draw where electronic protected health information enters, is stored, is viewed, is exported, and leaves the product. Name the practice, vendor, hosting or service providers, connected systems, and users at each handoff. Then mark which party configures, monitors, investigates, restores, and documents the relevant control.
A feature label such as encrypted, logged, backed up, or MFA-enabled is incomplete without scope. Ask which data, components, accounts, environments, and routes are included; what is excluded; and which settings the customer must enable or maintain. The answer may differ by product version or contract.
Turn broad assurances into dated evidence requests
Ask about architecture and data flow, risk-analysis practices, access controls, multifactor authentication scope, encryption, logging, backup and recovery testing, incident handling, subcontractors, and responsibility boundaries. Match each answer to an artifact or demonstration instead of accepting one general sales assurance.
- Control: the precise safeguard or process being described, in plain language.
- Scope: the product, version, environment, data, user, or connection the statement covers.
- Evidence: the dated document, configuration view, test result, report, or demonstration supplied.
- Ownership: what the vendor performs and what the practice or another party must configure and monitor.
- Exception: what happens when access fails, a user leaves, a log is incomplete, or recovery is needed.
- Follow-up: the unresolved question, owner, due date, and contract or implementation consequence.
Test one access change and one recovery path
Use synthetic data and a permitted test environment. Change a user's role or access, attempt an action the new role should not perform, and inspect what the user and administrator can see. Then ask the vendor to walk through a bounded backup or recovery example and identify the evidence it retains.
The goal is not to conduct a penetration test or certify the system. It is to see whether the stated control has a defined scope, owner, observable result, and exception path. If the vendor cannot demonstrate an item in the sales environment, request the appropriate written evidence and leave the result unconfirmed.
Create a versioned diligence record
Record the question, vendor answer, supporting document, document date, reviewer, unresolved issue, and contract consequence. Revisit the item after material product, infrastructure, contractual, or regulatory changes. Keep superseded evidence available so the practice can reconstruct which information informed an earlier decision.
Carry shared responsibilities into implementation and operating instructions. A contract statement does not configure a role, review a log, test a restore, or remove a departed user. Assign the customer-side tasks, cadence, evidence, and escalation route that the selected arrangement requires.
Keep the conclusion narrower than the checklist
The appropriate evidence depends on the practice's role, data, contracts, systems, and risk analysis. A vendor statement, completed checklist, or successful demonstration is a diligence input; none independently determines whether a product or organization complies with HIPAA.
Use qualified legal, privacy, security, and technical review where needed. The practical output here is a clearer record of what was asked, what evidence was supplied, who owns each safeguard, and what remains unresolved under the current rule.