HIPAA Security Risk Assessment (SRA): Methodology, Tools, and Documentation Requirements
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
HIPAA Security Risk Assessment (SRA): Methodology, Tools, and Documentation Requirements
The HIPAA Security Risk Assessment (SRA) — formally the Security Risk Analysis under 45 CFR §164.308(a)(1)(ii)(A) — is the most-cited deficiency in OCR enforcement actions and the foundational artefact every HIPAA programme must produce, maintain, and act on. Of the OCR resolution agreements published between 2018 and 2023, more than two-thirds named "failure to conduct an accurate and thorough risk analysis" as a violation. There is no template OCR will accept on its face, and there is no shortcut that produces a compliant SRA. There is, however, a defensible methodology that compliance officers, CISOs, and auditors all recognise.
This article walks through that methodology, the documentation expected by OCR, the tools that accelerate the work (including the HHS-published Security Risk Assessment Tool), and the operating cadence that turns the SRA from a one-time deliverable into a living risk programme.
What the SRA Has to Cover
The §164.308(a)(1)(ii)(A) standard reads: "Conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information held by the covered entity or business associate." Three words in that sentence carry weight.
- Accurate — based on real assets and real threats, not generic frameworks copy-pasted from a template
- Thorough — covering every system that creates, receives, maintains, or transmits ePHI, not just the EHR
- Risks and vulnerabilities — both the threat landscape and the control gaps that let threats land
The 2024 HHS Guidance on Risk Analysis Requirements (an update to the 2010 Guidance) describes the expected methodology in nine elements: scope, data collection, threat identification, vulnerability identification, current security measures, likelihood, impact, risk determination, and documentation. NIST SP 800-30 Rev. 1 ("Guide for Conducting Risk Assessments") is the baseline methodology HHS endorses. NIST SP 800-66 Rev. 2 ("Implementing the HIPAA Security Rule") translates 800-30 specifically for HIPAA.
Step 1: Scope the ePHI Estate
Scope is the single most under-done element. An SRA scoped only to the EHR fails because ePHI lives in dozens of adjacent systems: backup infrastructure, log aggregators, analytics platforms, clinician laptops, mobile devices, fax-to-email gateways, claim-clearinghouse extracts, marketing list exports for outreach, AI/ML training datasets, and the SaaS apps that connect to all of them.
The scoping deliverable is an asset inventory listing every system in scope, the categories of ePHI it handles, the data flows in and out, the responsible owner, the underlying infrastructure, and the BAA covering any third party in the chain. For most organisations, the inventory has 50-200 line items, not the 5-10 they expected when they started.
Need expert help with hipaa security risk assessment (sra)?
Our cloud architects can help you with hipaa security risk assessment (sra) — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
Step 2: Identify Threats
NIST SP 800-30 categorises threats into adversarial (external attackers, insiders), accidental (user error, misconfiguration), structural (hardware failure, software bug), and environmental (natural disaster, power outage). For HIPAA SRAs, the threat catalogue should reflect the actual threat landscape facing healthcare in 2026: ransomware (the dominant adversarial threat — see the 2024 Change Healthcare incident affecting an estimated 100M+ records), business-email compromise, third-party-vendor compromise, insider misuse, and physical theft of mobile devices.
The HHS 405(d) Health Industry Cybersecurity Practices (HICP) document and the HHS Cybersecurity Performance Goals (CPGs) published in 2023 enumerate the threats HHS itself thinks healthcare must defend against. SRAs that align to HICP and the CPGs land better with regulators because they speak the regulator's language.
Step 3: Identify Vulnerabilities
Vulnerabilities are the control gaps that let threats land. They come from technical scanning (vulnerability scanners, configuration review, pen testing), policy review (gap analysis against the §164.308-§164.312 control set), workforce assessment (training records, phishing-test results), and physical inspection (facility walkthroughs, device inventories). The output is a vulnerability register tied to specific assets in scope.
This is also where prior incidents matter. Section §164.308(a)(1)(ii)(D) requires periodic information-system-activity review, and the patterns it surfaces are vulnerabilities the SRA should explicitly account for. An SRA that does not reference the entity's own incident history is incomplete on its face.
Step 4: Assess Current Security Measures
For each in-scope system, document the controls already in place — the §164.308 administrative, §164.310 physical, and §164.312 technical safeguards as implemented today. The deliverable is a control catalogue with evidence: not "we encrypt at rest" but "S3 buckets in account 123456789012 are configured with default encryption using KMS key arn:aws:kms:..., verified via Config rule s3-bucket-server-side-encryption-enabled, with 100% compliance over the trailing 90 days."
Generic statements fail audits. Evidence-backed statements pass them.
Step 5: Determine Likelihood and Impact
For each threat-vulnerability pair against each in-scope asset, assess likelihood (the probability the threat exploits the vulnerability) and impact (the consequence if it does). NIST SP 800-30 uses a 5-point qualitative scale (very low, low, moderate, high, very high) for both, and most HIPAA SRAs follow suit. Quantitative scoring (CVSS-style) is more rigorous but harder to defend against an OCR investigator who is not a vulnerability-management specialist.
Impact for ePHI systems should explicitly consider confidentiality (PHI exposure), integrity (medical record corruption), and availability (system unavailability during patient care) — the §164.306(a) trifecta. Availability is often under-weighted; ransomware events that take an EHR offline during patient care have killed people, and OCR has cited that explicitly in its CPG documentation.
Step 6: Determine Risk and Build the Risk Register
Risk is the function of likelihood and impact, expressed as a single rating per threat-vulnerability-asset triple. The risk register sorts these by rating and feeds the §164.308(a)(1)(ii)(B) Risk Management Plan, which documents the treatment decision for each risk: accept, mitigate, transfer, or avoid.
The risk register is the single most-requested artefact in OCR document-production lists. It must be in writing, current, and traceable to specific implementation actions. A register without treatment decisions is a list, not a register; OCR will say so.
Step 7: Document Treatment Actions and Track Closure
For each risk above the entity's risk-acceptance threshold, the risk management plan defines the treatment action, the owner, the target date, and the closure evidence. This is project management, not compliance theatre — closing 50 items over 12 months requires the same discipline as any engineering programme.
Items that the entity decides to accept must be documented as accepted, with the rationale and the approving authority. OCR generally accepts written acceptance of low-rated risks; high-rated risks accepted without compensating controls are a signal that the SRA is not driving real risk reduction.
Tools That Accelerate the Work
Three tools are worth knowing about.
- HHS Security Risk Assessment Tool (SRA Tool) — free, downloadable from healthit.gov, walks through the §164.308-§164.312 controls in a wizard format. Excellent for small practices; insufficient on its own for enterprise SRAs but useful as a baseline.
- NIST SP 800-66 Rev. 2 — the HIPAA-specific implementation guide, free from NIST. The control mapping appendix is gold.
- Commercial GRC platforms — Archer, ServiceNow GRC, OneTrust, LogicGate, and Hyperproof all support HIPAA SRA workflows with workflow, evidence collection, and audit-trail features that scale beyond what a spreadsheet can sustain.
The right tool depends on scale. A 50-person clinic can run an excellent SRA in the HHS tool plus a managed spreadsheet. A 5,000-employee health system needs a GRC platform with role-based ownership, evidence linking, and reporting — anything else collapses under the weight of asset count and audit cadence.
Operating Cadence: Annual Refresh, Continuous Monitoring
The Security Rule does not specify an SRA frequency, but HHS guidance and OCR enforcement establish "periodic" review at least annually, with refresh on material change (new ePHI system, new threat actor, new regulation, new merger or acquisition). High-risk environments — large-EHR deployments, telehealth platforms, AI/ML pipelines — typically run continuous monitoring against the risk register and an annual full SRA refresh.
The SRA documentation must be retained for six years from creation or last effective date under §164.530(j). This means the 2020 SRA is still discoverable by OCR in 2026; the version history matters and should be preserved.
How Opsio Helps
Opsio facilitates HIPAA Security Risk Assessments for healthcare providers, payers, and business associates — from initial scoping through risk treatment and ongoing monitoring. Our HIPAA compliance services for healthcare follow the NIST SP 800-30 and SP 800-66 methodologies HHS endorses, integrate technical scanning and pen-test findings into the vulnerability register, and produce the documentation set OCR investigators expect to see. We pair SRA work with penetration and vulnerability testing to feed real findings into the risk register and with compliance risk assessment across GDPR, HIPAA, SOC 2, and ISO 27001 for organisations operating under multiple regulatory regimes simultaneously.
About the Author
Group COO & CISO
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.