HIPAA compliance framework guide: Security Rule, HICP, and the 2013 Omnibus

HIPAA Security Rule / NIST SP 800-66 R2

All covered entities — healthcare providers that transmit health information electronically, health plans, and healthcare clearinghouses — and all business associates handling ePHI on their behalf. There is no size threshold. A sole-practitioner physician is subject to the same Security Rule as a health system with 50,000 employees. What scales is the expectation of what ''reasonable and appropriate'' controls look like at that size.

The documented risk analysis that has not been updated since it was first produced. OCR''s published audit protocols and investigation findings consistently cite outdated risk analyses as the primary deficiency. The risk analysis is supposed to be a living process — updated when there are significant changes to the environment, new threat intelligence emerges, or at minimum on a regular periodic schedule. In our assessments, the median age of a healthcare organisation''s most recent risk analysis at time of engagement is 27 months. (Vulnox assessment data, 2024)

The Security Rule organises requirements into administrative, physical, and technical safeguard categories, each containing standards, and each standard containing implementation specifications marked either required or addressable. Required specifications must be implemented. Addressable specifications require a documented assessment of whether implementation is reasonable and appropriate for the entity''s environment — and if the entity determines it is not, an equivalent alternative must be documented and implemented instead.

The administrative safeguard standards include: security management process (risk analysis and risk management are required here); assigned security responsibility; workforce security; information access management; security awareness and training; security incident procedures; contingency plan; evaluation; and business associate contracts. The risk analysis is required and is the foundation on which all other control selection should rest.

Physical safeguard standards cover facility access controls, workstation use and security, and device and media controls — including the disposal of hardware containing ePHI.

Technical safeguard standards cover access controls, audit controls, integrity controls, person or entity authentication, and transmission security. Encryption of ePHI at rest is addressable (requires documented assessment); encryption in transit is addressable but OCR has consistently signalled that the bar for treating it as not reasonable and appropriate is very high given modern transmission environments.

NIST SP 800-66 R2 maps each of these specifications to specific control recommendations and provides a crosswalk to the NIST Cybersecurity Framework. Its 2023 update incorporated lessons from a decade of OCR enforcement and added guidance on cloud computing, mobile device management, and ransomware response.

HHS OCR investigates complaints and conducts compliance reviews. Civil monetary penalties under the four-tier structure (post-Omnibus) can reach $1.9 million per violation category per year. The largest single HIPAA settlement to date exceeded $16 million. OCR has also pursued corrective action plans that impose multi-year oversight and third-party audits at the organisation''s expense. Criminal referrals to the Department of Justice are available for wilful violations.

The Security Rule is the legal foundation that all other frameworks in this group reference or implement. NIST SP 800-66 R2 is its implementation companion. HICP provides a practice-size-calibrated control guide. The Omnibus Rule is the enforcement and liability update. Nothing in the HICP or the Omnibus operates independently of the Security Rule.

HIPAA Administrative Simplification (2013 Omnibus Rule)

All covered entities and — critically, directly — all business associates. This is the defining change of the 2013 rule. Prior to the Omnibus, business associates were contractually obligated to covered entities but not directly regulated by HHS. Post-2013, a business associate that violates HIPAA faces direct OCR enforcement, independent of any contract with the covered entity.

Business Associate Agreements that were signed in 2013 and never reviewed. The Omnibus Rule required updates to all existing BAAs within one year of its effective date — September 2013. A BAA template that predates the Omnibus does not reflect current business associate obligations. Beyond the initial update, BAAs need to be reviewed when the nature of the business associate relationship changes, when the covered entity''s risk profile changes, or when OCR guidance updates the expectations for what BAAs must contain. In our assessments, the average BAA in a covered entity''s vendor inventory is 4.2 years old. (Vulnox assessment data, 2024)

The Omnibus Rule consolidated and updated four separate rules: the Privacy, Security, Breach Notification, and Enforcement Rules. The major substantive changes: the breach notification standard shifted from a ''significant harm to the individual'' threshold to a ''low probability that PHI has been compromised'' standard — the presumption is now that a breach has occurred unless the covered entity can demonstrate low probability through a four-factor risk assessment. This reversed the burden of proof.

The four-factor breach risk assessment must consider: the nature and extent of PHI involved (including the likelihood of re-identification); who accessed or could have accessed it; whether the PHI was actually acquired or viewed; and the extent to which risk has been mitigated. All four factors must be documented for each potential breach.

The civil monetary penalty tiers were restructured into four categories based on culpability: unknowing ($100 to $50,000 per violation), reasonable cause ($1,000 to $50,000 per violation), wilful neglect with correction ($10,000 to $50,000 per violation), and wilful neglect without correction ($50,000 to $1.9 million per violation). Annual caps apply per violation category. The structure is intended to scale penalty severity with how preventable the violation was.

Marketing restrictions were significantly tightened: covered entities generally cannot use or disclose PHI for marketing purposes without authorisation, and the sale of PHI requires explicit authorisation separate from any treatment or payment purpose.

Direct enforcement authority over business associates was the operational change with the broadest industry impact. Cloud providers, billing companies, EHR vendors, and any other entity that touches ePHI on behalf of a covered entity can now receive OCR civil monetary penalties directly. The business associate cannot shield itself behind the covered entity''s compliance programme.

The Omnibus Rule is the enforcement and liability layer that sits above the Security Rule. It also updated the Privacy Rule and Breach Notification Rule, which are not separately listed as framework entries in this group but are part of the same administrative simplification framework. The HICP guidance was developed after the Omnibus and reflects the post-2013 business associate landscape.

HICP Small Practice

Healthcare organisations with fewer than 10 clinicians — sole practitioners, small group practices, small dental practices, independent pharmacies, and similar organisations. This tier recognises that a single-physician practice cannot reasonably implement the same security infrastructure as a hospital system, and that prescribing enterprise-grade controls to small practices would result in no controls being implemented at all.

Treating HICP as a checklist rather than a practice guide. Small practices often use HICP to generate a self-attestation of compliance without verifying that the described controls are actually operating. The most common gap: MFA is listed as implemented for remote access, but the practice uses a consumer-grade VPN that does not enforce MFA because no one has tested what happens when a user logs in without the second factor.

The HICP small practice tier maps five threat areas to 10 practical cybersecurity practices calibrated to small organisation capabilities: email protection systems (anti-phishing filters, user awareness for recognising phishing attempts); endpoint protection (anti-malware, managed endpoints); access management (unique user accounts, strong passwords, MFA for remote access and privileged accounts); data protection and loss prevention (encrypted backups, awareness of what ePHI exists and where); and incident response (a documented response plan, even a simple one, with contact information for relevant parties including law enforcement and OCR).

For small practices, HICP explicitly acknowledges that many of these controls will be delivered through managed services rather than internal IT staff. The expectation is that the practice owner or administrator understands what they are purchasing and can verify that the vendor is delivering it, rather than that they implement it themselves.

HICP is not independently enforced. Its value in an OCR investigation is as evidence that the organisation''s security practices align with recognised healthcare cybersecurity standards, which HITECH authorises OCR to consider when calculating civil monetary penalties. HHS has confirmed that demonstrating adherence to HICP can reduce the penalty calculation.

HICP Small maps to the Security Rule''s required and addressable specifications at a scale appropriate for the small practice environment. It does not replace the Security Rule — a small practice still must conduct a risk analysis, document its safeguard decisions, and execute Business Associate Agreements. HICP provides implementation guidance for the technical safeguard layer.

HICP Medium Practice

Healthcare organisations with 10 to 249 clinicians — mid-sized group practices, community health centres, ambulatory surgery centres, regional health plans, and similar organisations. This tier assumes the organisation has some dedicated IT support — either internal or outsourced — but not a mature security operations function.

Documented policies that have outpaced actual controls. Medium practices frequently reach this tier through a growth phase — what was a 12-person practice five years ago is now 80 clinicians, several locations, and a technology footprint that was never redesigned for the larger environment. The access control policy says role-based access is enforced; the EHR still has 40 users in an ''all access'' role from when everyone wore every hat.

The medium practice tier adds control specificity beyond the small tier: email protection includes security awareness training programmes (not just ad hoc reminders); endpoint protection extends to managed detection and response capabilities and mobile device management; access management includes role-based access control tied to job function and regular access reviews; data protection adds data classification and formal data loss prevention controls; and incident response requires a documented and tested plan, not just a document.

The medium tier also introduces the expectation of formal vulnerability management — regular scanning of systems for known vulnerabilities and a defined remediation timeline. This is the first tier where patch management is framed as a security control rather than a routine IT task.

Same as HICP Small — not independently enforced, but recognised as a mitigating factor by OCR. At the medium practice scale, the stakes of an enforcement action are higher: a 100-clinician practice has more ePHI at risk and a larger workforce creating more exposure vectors, which typically means larger breach impact and higher penalty potential.

The medium tier is the most frequently under-resourced. Large practices have compliance teams; small practices have simple environments. Medium practices have complex environments and limited dedicated security resources. NIST SP 800-66 R2 is a useful companion document at this tier — its control recommendations are calibrated to organisations with some security infrastructure but not a full security operations capability.

HICP Large Practice

Healthcare organisations with 250 or more clinicians — large group practices, hospitals, health systems, large health plans, and healthcare clearinghouses. This tier assumes dedicated security staff, a security operations function (whether in-house or managed), and a formal risk management programme.

Security programme maturity that covers primary systems and misses the full ePHI environment. Large healthcare organisations have sprawling technology landscapes — clinical systems, billing systems, patient engagement platforms, medical devices, research databases, legacy systems that predate modern security expectations. The security programme is built around the EHR and the primary data centre. The 15-year-old radiology PACS system running on an unpatched operating system that stores ePHI and is directly connected to the clinical network is not in scope of the security programme. In our assessments, the average large healthcare organisation has between 3 and 7 ePHI-containing systems that are not included in their Security Rule scope. (Vulnox assessment data, 2024)

The large practice tier reflects enterprise-grade expectations: email protection includes advanced threat protection capabilities such as sandboxing and URL rewriting; endpoint protection includes EDR with active threat hunting capability; access management includes privileged access management (PAM) for administrative accounts, MFA across all remote access and all systems touching ePHI, and automated provisioning and deprovisioning workflows; data protection includes data loss prevention tools with policy enforcement, not just monitoring; and incident response requires a formally documented, regularly tested plan with defined response teams, communication protocols, and post-incident review processes.

The large tier also introduces third-party risk management expectations — organisations of this size have complex vendor ecosystems, and the HICP guidance expects systematic assessment and monitoring of high-risk vendors, not just BAA execution.

Network segmentation — isolating ePHI-containing systems from general corporate network traffic and from internet-facing systems — is an explicit large-tier expectation. For most hospital environments, this means the clinical network, the administrative network, and internet-facing systems are architecturally separated.

Large healthcare organisations face the highest absolute penalty exposure because their breach events typically affect the most individuals and involve the largest volumes of ePHI. The 2024 UnitedHealth Group / Change Healthcare incident — affecting an estimated 190 million individuals — illustrates the scale of exposure at the large end of this tier. OCR corrective action plans at this scale routinely impose two to five years of third-party monitoring.

The large practice tier is the most closely aligned with the NIST SP 800-66 R2 control recommendations, which were written with a level of technical detail that presumes security staff capable of implementing and operating them. Organisations at this tier should use 800-66 R2 as the detailed technical companion to their Security Rule implementation and use HICP Large as the strategic framework for programme organisation.

HICP does not address the Security Rule''s administrative safeguard standards that are not control-implementation questions. The Security Rule''s requirements for a formal risk analysis, assigned security responsibility, workforce training programme, contingency plan, periodic evaluation, and business associate contracts are governance and process obligations that HICP does not cover. An organisation that implements all HICP controls but has not conducted a documented risk analysis has not satisfied the Security Rule.

The five HICP practice areas — email protection, endpoint protection, access management, data protection, and incident response — map directly to Security Rule technical and administrative safeguard specifications. An organisation that fully implements the HICP controls appropriate to its practice size has addressed the majority of its Security Rule technical safeguard obligations. The mapping is explicit in the HICP documentation.

The Security Rule creates the operational obligation (have a breach notification procedure). The Omnibus Rule sets the legal standard for when that procedure triggers (low probability of compromise rather than significant harm) and what happens when it fails (direct enforcement against business associates, penalty tier structure). Understanding the Security Rule''s breach notification standard without understanding the Omnibus Rule''s enforcement update means operating against a pre-2013 standard that no longer reflects OCR''s enforcement posture.

The Security Rule''s breach notification procedures standard (an administrative safeguard) and the Omnibus Rule''s Breach Notification Rule govern the same event: a breach of unsecured ePHI. Both require the same outcome — timely notification to affected individuals, HHS, and in some cases media. Both reference the same four-factor risk assessment for determining whether a breach is notifiable.

The specific controls, their sophistication, and the expectation of continuous monitoring versus periodic review differ significantly across tiers. Small practice expects password managers and anti-malware. Large practice expects PAM infrastructure and EDR with active threat hunting. Organisations that grow through the tier boundaries must actively reassess which tier''s expectations apply to their current environment — the control set that was appropriate at 50 clinicians is not appropriate at 300.

All three tiers address the same five threat areas and the same five practice categories. The underlying threat model is identical — phishing, ransomware, insider threats, data loss, inadequate incident response — and the control categories that address them are the same.

Treating ''addressable'' as ''optional''

The Security Rule''s distinction between required and addressable specifications is genuinely confusing. The word ''addressable'' sounds discretionary. Healthcare compliance resources that describe the Security Rule sometimes use language like ''you do not have to implement this if it is not appropriate for your environment,'' which is technically accurate but omits the critical second step: if you do not implement it, you must document a reasonable and appropriate alternative. Most organisations stop at the determination and never document either the rationale or the alternative.

In OCR investigations, addressable specifications that were not implemented and not documented create a clean violation record. The organisation cannot demonstrate that a considered decision was made. The specification was effectively ignored rather than assessed. OCR treats this as evidence of inadequate security management processes, which is a required specification — meaning the failure to document the addressable assessment creates a separate violation at the required level.

Scoping ePHI environments based on where IT thinks ePHI lives

Security programme scope is typically defined by IT and security teams based on systems they manage. Clinical IT — the EHR, the lab system, the PACS — is in scope. The email system probably is. What frequently falls outside scope: the departmental file shares where clinical staff save patient-related documents; the practice management software running on the front desk workstations; the mobile devices used by physicians for patient messaging; the third-party patient portal platform. None of these are in the IT department''s primary purview, and none appear in the initial scope discussion.

A Security Rule risk analysis that does not identify all ePHI locations cannot accurately assess the risks to ePHI. Controls are implemented around the known scope. When a breach occurs through the unscoped environment — a front-desk workstation with unencrypted patient files, a physician''s personal phone with patient messages from an unmanaged messaging app — the organisation''s risk analysis does not address the risk that was exploited. OCR''s investigation starts with the risk analysis and asks why this system was not in scope.

Signing BAAs as a compliance event rather than as the start of a vendor risk process

The BAA is a legal document. Its execution is managed by legal or compliance. Once signed, the legal obligation is satisfied from a documentation standpoint. No one in most healthcare compliance programmes is responsible for what happens after the BAA is signed — whether the vendor''s security controls are adequate, whether they have experienced their own breaches, whether the BAA provisions (audit rights, breach notification timelines, subcontractor flow-down) are actually being exercised.

Business associates breach healthcare organisations. It is the most common breach vector in healthcare. A 40-person physician group whose billing company suffers a ransomware event has its patient data in the breach, and OCR will investigate the covered entity''s BAA and vendor oversight programme. A BAA that grants audit rights is not the same as having conducted an audit. The obligation does not end at contract execution.