Use a gap assessment to establish what needs to change
A HIPAA gap assessment compares the organisation’s relevant practices with applicable requirements and identifies where the evidence does not support compliance. Its value is a clear account of scope, findings, uncertainty and work to perform. It should help management decide what to change and how to verify progress. It is not a government certification, and it is not automatically equivalent to a complete risk analysis.
The current Security Rule includes a periodic technical and nontechnical evaluation requirement. A well-scoped assessment can support that work, but the organisation should understand what the engagement covers and what it does not. Privacy operations, business associate arrangements, electronic protected health information (ePHI) safeguards and breach procedures may require different evidence and expertise. A brief questionnaire cannot establish the operating effectiveness of every process. 45 CFR Part 164, Subpart C
Begin with the decision the assessment must support. A healthcare provider preparing to replace a core system needs different emphasis from a technology supplier entering its first hospital contract. Both need the applicable requirements addressed, but the sequence, stakeholders and practical outputs can differ. Agree the decision, scope and deliverables before comparing proposals or setting a completion date.
Define entities, services and evidence boundaries
A scope should name the legal entities, services, locations, workforce groups, applications and relevant suppliers included. Explain the information types and main data flows. Identify important exclusions and the reason for them. If a support tool, overseas team or acquired practice is omitted, management should understand the effect on the conclusions. A broad title on the report should not conceal a narrow review.
Confirm applicability before testing requirements. Determine covered entity or business associate roles for the relevant activities and identify any specialised legal questions requiring separate advice. A global service organisation may have several customer relationships with distinct contractual conditions. Document those conditions rather than assuming one customer’s operating model applies to every account. Covered Entities and Business Associates
Agree how evidence will be obtained and protected. Interviews, policies, configurations, contract records and sampled operating evidence provide different kinds of insight. Define secure access and redaction arrangements so assessment work does not create an uncontrolled repository of patient information. Where possible, use synthetic demonstrations or metadata sufficient to explain the control without copying clinical content.
Also agree the time period and sampling limits. A setting checked today does not prove it was active throughout the previous year. A sample of one department may not represent another location with different systems. These limitations do not make the work useless, but they should be visible. The report needs to distinguish what was observed from what was inferred or stated by management.
Keep requirements separate from recommended improvements
Use the effective rule and relevant contractual obligations as the assessment baseline. Record the source and version or date checked. Do not silently replace current requirements with proposed provisions or a consultant’s preferred control catalogue. The Security Rule proposal announced in December 2024 remains separately identified in official HHS and eCFR material reviewed on 12 October 2026; it should not be scored as current law merely because it appears in a recent checklist. HIPAA Security Rule NPRM fact sheet 45 CFR Part 164, Subpart C
Classify findings accurately. A missing required process is different from insufficient evidence of an existing process. A weak design is different from a design that is sound but not followed. A recommendation to improve efficiency or resilience is different from a conclusion that a legal requirement is unmet. Clear categories help management avoid both complacency and unnecessary alarm.
Addressable implementation specifications require their own assessment logic. Review the entity’s reasoned decision and supporting facts, not just whether it selected the assessor’s favourite technology. If no documented assessment exists, that is an important issue. If an alternative measure is used, examine whether it addresses the relevant purpose and whether the decision remains reasonable in the current environment.
Where legal interpretation is uncertain, state the question and route it for appropriate review. An assessor should not disguise a disputed conclusion as a technical fact. Equally, uncertainty should not excuse ignoring a clear operational exposure. The team can restrict an unsafe data flow or preserve evidence while obtaining the interpretation needed for the final requirement mapping.
Our HIPAA Security Rule guide explains how required and addressable specifications relate to safeguard decisions and implementation evidence.
Test the work that people actually perform
Organise fieldwork around representative workflows. Follow onboarding and termination, a supplier engagement, a patient request, a routine disclosure, a security event and a restoration exercise. Ask participants to demonstrate how they handle exceptions. This reveals whether policies, system capabilities and actual behaviour align. A document review alone can miss the point where a process fails under workload or across organisational boundaries.
For access controls, compare approved roles with actual permissions and sample workforce changes. For supplier oversight, connect the agreement to the services and features receiving protected health information (PHI). For training, look beyond attendance to role coverage and the ability to make sound decisions and follow the relevant procedures. For contingency planning, inspect evidence of retrievable copies and the ability to restore the service, including dependencies.
Use technical testing proportionate to the engagement and operational risk. Define permissions, safe methods and change windows before interacting with production healthcare systems. A gap assessment need not include every form of intrusive security testing, and it should not imply that it has done so when it has not. Where deeper testing is needed, record the separate work and its purpose.
At the end of each review area, confirm the facts with the process owner. This is an opportunity to correct misunderstandings, locate missing evidence and identify a practical remediation owner. It should not become a negotiation to remove inconvenient findings. Preserve the distinction between a factual correction, a new piece of evidence and management disagreement about the proposed action.
Where the review depends on staff choices, use our HIPAA training guide to distinguish attendance records from demonstrated understanding of the relevant workflow.
Write findings that can be acted on
A useful finding states the condition observed, the relevant requirement or decision, the evidence, the effect and the recommended next action. Avoid vague labels such as policies inadequate. Explain which policy or process is missing, how that affects a specific workflow and what evidence would demonstrate improvement. The reader should not need to reconstruct the assessor’s reasoning from scattered interview notes.
Record scope and confidence. If evidence was unavailable, say whether the issue is an unverified claim or an observed failure. If a problem affects a sample of accounts, do not automatically claim it affects every user; instead, define the additional review needed. If the weakness is systemic, explain the process feature that makes recurrence likely. Precision helps leadership decide the necessary extent of remediation.
Prioritise using exposure, consequences and dependencies. A publicly accessible file location may require immediate containment. A poorly maintained policy index may require orderly correction but not the same emergency response. Consider patient care, confidentiality, integrity and availability, as well as whether one fix enables several others. A complete roadmap can sequence urgent containment and longer-term design work without confusing the two.
Assign ownership to a person or role with authority over the change. Security may coordinate, while the actual action belongs to clinical operations, human resources, procurement or an application team. A recommendation without a responsible owner and acceptance condition often becomes a recurring observation in the next assessment. Make the implementation decision visible while the finding is still fresh.
Build a roadmap around dependencies and acceptance evidence
Group related actions into manageable work packages. An access project may include role design, workforce data quality, application integration, termination procedures and review evidence. A supplier project may include inventory reconciliation, role classification, agreement review and incident contacts. This grouping allows management to fund a coherent change rather than a collection of disconnected audit responses.
Sequence prerequisites. A complete system inventory may be necessary before backup coverage can be confirmed. A reliable workforce list may be necessary before an access review can be trusted. Contract clarification may be necessary before a supplier can provide specific incident records. Identify these dependencies explicitly so overdue work is not repeatedly assigned to a team that cannot complete it without another decision.
Define closure evidence at the start. For a missing incident route, evidence might include the approved procedure, available contacts, training and an exercise demonstrating successful escalation. For excess permissions, evidence might include the approved role, configuration changes and a test of allowed and denied actions. A revised policy alone should not close a finding about a technical control that still fails.
Use staged reporting. Leadership should see completed changes, failed validations, overdue items and decisions requiring resources. Preserve temporary measures and residual limitations. Reassess priorities when new incidents or material changes occur. A roadmap is a decision tool that should adapt to evidence; it is not a promise that every action can be completed on the original date regardless of clinical, technical or supplier constraints.
Hypothetical example: a clinic group evaluates an acquired practice
A fictional clinic group acquires a small practice and commissions a HIPAA gap assessment before integrating systems. The initial assumption is that group policies can simply be applied to the new site. Fieldwork reveals local scanning software, a separate backup supplier and an informal process for sending records to specialists. The practice also relies on one long-serving administrator for account changes.
The assessment records the acquired site’s real boundary rather than treating it as identical to the group. Interviews are checked against system settings and representative workflows. The team identifies immediate access and sharing concerns, uncertainty about backup recovery and documentation that describes an older system. These are separated into observed gaps, evidence questions and improvement recommendations.
The roadmap begins with containment of uncontrolled sharing and removal of abandoned accounts. It then addresses inventory, supplier arrangements and recovery verification. Integration into group identity services depends on the application migration, so the team defines an interim access process with explicit ownership. Clinical operations reviews changes that could affect referral turnaround or access to historical records.
A follow-up review checks whether the interim process actually operates and whether the backup can restore the required information. The report does not declare the practice fully compliant merely because group policies have been issued. It shows which improvements are verified, which depend on integration and which require further decisions. That gives management a defensible basis for the next phase of the acquisition.
Hypothetical example: a healthcare software company prepares for enterprise customers
A fictional software company receives detailed security and privacy questions from prospective hospital customers. It has an external security test and a set of policies, but no integrated account of how support access, cloud services and patient-rights assistance work. Management commissions a gap assessment to determine the work required before expanding the service.
The assessor reviews the actual product and support model. Engineers demonstrate tenant separation with synthetic records. Support managers show how diagnostic uploads are handled. Procurement identifies the hosting and ticketing suppliers. The privacy reviewer examines the intended business associate relationships and the process for helping customers retrieve records. The prior security test is used as evidence within its scope, not as proof of every HIPAA responsibility.
Findings show that core access restrictions are functioning, while support attachments have unclear retention and incident escalation depends on a single individual. The roadmap assigns product changes, supplier clarification and operational exercises to different owners. Sales receives a precise statement of assessed scope and outstanding work so proposals do not overstate readiness.
Verification includes a simulated customer incident outside normal office hours and a request to retrieve a tenant’s records. The company can demonstrate improvement with concrete results and state remaining limitations honestly. It avoids marketing the assessment as a government certificate. HHS’s position is that private Security Rule certifications do not remove obligations or preclude a later violation finding. Are we required to certify compliance with the Security Rule?
Reference basis
eCFR: 45 CFR Part 164, Subpart C; HHS: Covered Entities and Business Associates; HHS: HIPAA Security Rule NPRM fact sheet; HHS: Security Rule certification FAQ.
Frequently asked questions
Is a gap assessment the same as a risk analysis?
No. They can inform each other, but a gap assessment compares practices with requirements, while risk analysis evaluates potential threats, vulnerabilities and consequences for ePHI. An engagement should state whether it includes both.
Can all findings be closed by updating policies?
No. Documentation can resolve a documentation problem, but an operating or technical weakness needs evidence that the process or safeguard has changed and works as intended.
How should assessment proposals be compared?
Compare scope, evidence methods, relevant expertise, sampling limits, practical deliverables, validation and implementation support. A low fee or short schedule is not meaningful without knowing what work is included.
Discuss the next practical step
When commissioning a gap assessment, request an explicit scope, evidence method, finding structure and closure criteria. Share your decision deadline and operational constraints so the proposed roadmap can distinguish urgent containment from dependent implementation work.
Explore CyberVantage360 HIPAA assessment and implementation services, or contact CyberVantage360 to discuss your priorities.