The most common OCR enforcement finding: no SRA
If there is one single thing that the HHS Office for Civil Rights (OCR) cites in HIPAA enforcement actions more than anything else, it is the failure to conduct — or to properly document — a Security Risk Assessment under §164.308(a)(1)(ii)(A).
In virtually every published resolution agreement and civil money penalty from OCR, the covered entity or business associate either: (a) had never conducted an SRA, (b) had conducted an inadequate SRA (too narrow in scope, not updated after significant changes, or not organisation-wide), or (c) had an SRA but had not implemented the risk management measures required by §164.308(a)(1)(ii)(B).
The SRA is not optional. It is a required specification under the HIPAA Security Rule — not an addressable specification — which means there is no flexibility to implement an equivalent measure or document why it's not reasonable and appropriate. It must be done.
What §164.308(a)(1) actually requires
45 CFR §164.308(a)(1) is the Security Management Process standard. It contains four implementation specifications:
- §164.308(a)(1)(ii)(A) — Risk Analysis (Required): Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI held by the covered entity or business associate.
- §164.308(a)(1)(ii)(B) — Risk Management (Required): Implement security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level.
- §164.308(a)(1)(ii)(C) — Sanction Policy (Required): Apply appropriate sanctions against workforce members who fail to comply with the security policies and procedures.
- §164.308(a)(1)(ii)(D) — Information System Activity Review (Required): Regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.
The SRA itself satisfies (A). The risk management programme required by (B) is what you build in response to the SRA findings. Most organisations focus on the SRA document and underinvest in the risk management programme — that's the second most common OCR finding.
Who must conduct an SRA
Both covered entities and business associates must conduct an SRA. The HITECH Act (2009) extended the full Security Rule obligations to business associates directly — not just through contract requirements.
- Covered entities: Healthcare providers, health plans, and healthcare clearinghouses that transmit health information electronically.
- Business associates (BAs): Entities that create, receive, maintain, or transmit ePHI on behalf of a covered entity. This includes EHR vendors, cloud hosting providers, billing companies, telehealth platforms, and SaaS products used by healthcare organisations to process or store patient data.
- Subcontractors of BAs: Also required to comply with the Security Rule and conduct their own SRA.
A Business Associate Agreement (BAA) is required between covered entities and BAs — but a BAA does not transfer the SRA obligation. Each organisation must conduct its own SRA for its own systems handling ePHI.
The three HIPAA safeguard categories
The HIPAA Security Rule organises safeguards into three categories. Your SRA must address all three:
Administrative Safeguards (§164.308) — the most extensive category
Administrative safeguards are the policies, procedures, and processes that protect ePHI. They include:
- Security Management Process (§164.308(a)(1)): The SRA itself + risk management + sanction policy + activity review
- Assigned Security Responsibility (§164.308(a)(2)): Designating a HIPAA Security Officer
- Workforce Security (§164.308(a)(3)): Authorisation, clearance, and termination procedures
- Information Access Management (§164.308(a)(4)): Access authorisation and role-based access controls
- Security Awareness and Training (§164.308(a)(5)): Security reminders, malware protection, password management
- Security Incident Procedures (§164.308(a)(6)): Incident response and reporting
- Contingency Plan (§164.308(a)(7)): Backup, disaster recovery, emergency mode operation
- Evaluation (§164.308(a)(8)): Periodic technical and non-technical evaluation
- Business Associate Contracts (§164.308(b)(1)): BAAs with all BAs handling ePHI
Physical Safeguards (§164.310)
Physical safeguards protect the physical systems that house ePHI:
- Facility Access Controls (§164.310(a)): Physical access to facilities containing ePHI systems
- Workstation Use and Security (§164.310(b)/(c)): Policies for workstations that access ePHI + physical security for those workstations
- Device and Media Controls (§164.310(d)): Disposal, media re-use, and accountability for devices containing ePHI
For cloud-hosted ePHI, many physical safeguards are covered by your cloud provider's BAA — but you still need to document that the responsibility has been allocated and verify the provider's physical controls through their compliance reports (SOC 2, ISO 27001, HITRUST, etc.).
Technical Safeguards (§164.312)
Technical safeguards are the technology controls that protect ePHI:
- Access Control (§164.312(a)): Unique user IDs, emergency access, automatic logoff, encryption at rest
- Audit Controls (§164.312(b)): Hardware/software/procedural audit trails for ePHI access
- Integrity (§164.312(c)): Mechanisms to verify ePHI has not been altered or destroyed
- Person or Entity Authentication (§164.312(d)): Verifying users before granting ePHI access
- Transmission Security (§164.312(e)): Integrity controls and encryption for ePHI in transit
HHS and NIST SRA methodology
HHS guidance (published at hhs.gov/hipaa/for-professionals/security) describes nine steps for a compliant risk analysis:
- Scope: Identify all ePHI — where it's created, received, maintained, or transmitted. Must be organisation-wide, not limited to specific systems.
- Data Collection: Document all systems, applications, and processes that handle ePHI.
- Identify Threats: Identify reasonably anticipated threats to ePHI (human, environmental, natural, technical).
- Identify Vulnerabilities: Identify vulnerabilities in systems and processes that could be exploited by those threats.
- Assess Current Controls: Document existing security controls and their effectiveness.
- Determine Likelihood: Assess the likelihood of each threat exploiting a vulnerability.
- Determine Potential Impact: Assess the magnitude of impact if the threat occurs.
- Determine Risk Level: Combine likelihood and impact to assign a risk level (Critical/High/Medium/Low).
- Finalise Documentation: Document the entire process, findings, and the organisation's decision to implement or not implement specific safeguards.
NIST SP 800-66r2 (Implementing the HIPAA Security Rule, updated 2023) provides detailed guidance aligned to this methodology and maps NIST SP 800-53 controls to HIPAA specifications. HHS explicitly endorses the NIST methodology for HIPAA SRAs.
OCR enforcement: what triggers an audit and what happens
| Trigger | OCR Action | Typical Finding |
|---|---|---|
| Breach notification (500+ records) | OCR investigation, document requests, potential settlement | Missing/inadequate SRA is the #1 finding |
| Patient/employee complaint | Complaint investigation | Access control failures, lack of workforce training |
| OCR Phase 2 Desk Audit | Request for documentation: SRA, policies, BAA list, training records | SRA missing or outdated, no risk management programme |
| OCR Phase 3 Onsite Audit | Document review + interviews + technical inspection | Discrepancies between policy and practice, audit log gaps |
OCR fine exposure depends on culpability:
- Tier 1 (no knowledge): $100–$50,000 per violation, up to $25,000/year per category
- Tier 2 (reasonable cause): $1,000–$100,000 per violation, up to $100,000/year per category
- Tier 3 (wilful neglect, corrected): $10,000–$250,000 per violation, up to $250,000/year per category
- Tier 4 (wilful neglect, not corrected): $50,000–$1.9M per violation, up to $1.9M/year per category
The absence of an SRA is typically treated as Tier 3 or Tier 4 — wilful neglect — because the requirement is well-publicised and unambiguous.
SRA documentation requirements
The SRA document must include:
- Scope statement: what ePHI systems and processes are included
- Threat identification with rationale
- Vulnerability identification with current controls assessment
- Risk level assignments (likelihood × impact) with methodology explanation
- Planned and implemented risk management measures
- Residual risk assessment
- Assessment date, assessor identity, review date
- Management approval/sign-off
The SRA must be updated when there are changes to the environment (new systems, new staff, new threats, mergers/acquisitions) and at minimum annually as part of the §164.308(a)(8) periodic evaluation requirement.
Use our free HIPAA Security Risk Assessment Generator to work through all 18 HIPAA Security Rule safeguard areas, get OCR-aligned risk scoring, and generate a documented SRA report. For related HIPAA compliance, see the Information Security Policy Generator and the Incident Response Plan Generator.