Building a HIPAA Risk Assessment: A Plain-English Guide for Healthcare Teams

#hipaa #healthcare #security #compliance

Originally published at medcurity.com. Mirrored here for the engineering audience. Canonical points to the source.

If you build, deploy, or support a system that touches electronic protected health information (ePHI), the HIPAA Security Risk Analysis (SRA) is the audit nobody on your team wants to fail. It is the single most cited deficiency in OCR enforcement actions, and the one piece of paperwork that auditors actually read end-to-end.

This is a plain-English walkthrough of what an SRA is, what the regulation literally says, the nine things it has to document, and the places engineering teams typically stub their toes.

What a HIPAA Risk Assessment actually is

Strip away the consultant vocabulary and the SRA is one thing: a written analysis of the threats and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your environment, plus a plan to reduce the high-priority ones to an acceptable level.

The legal hook lives in 45 CFR §164.308(a)(1)(ii)(A):

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.

That is the entire regulatory text. Everything else — scoring, methodology, format — is inferred from OCR enforcement actions, the NIST SP 800-66 Rev. 2 implementation guide, and NIST SP 800-30 Rev. 1 (the risk-assessment methodology HHS references).

Who has to do one

Every covered entity (hospital, clinic, health plan, clearinghouse) and every business associate (any vendor that processes ePHI for one) has to perform an SRA. Since the 2013 Omnibus Rule, business associates are directly liable — your SaaS doesn't get a pass because the hospital signed a BAA with you.

If you are an engineer at a digital-health startup, your company is almost certainly a business associate, and an SRA covering your stack is mandatory.

The nine elements OCR expects to see

OCR's published guidance breaks the SRA into nine concrete elements. If any one is missing, the SRA is considered deficient — and that's the most common audit finding in the entire HIPAA program.

Scope of the analysis. Every system, application, network segment, vendor, and physical location that touches ePHI.
Data collection. Where ePHI is created, received, maintained, and transmitted. Diagrams help here; auditors love a flow diagram.
Identification and documentation of potential threats and vulnerabilities. Real, specific ones — not "ransomware in general."
Assessment of current security measures. What's actually in place today, with evidence.
Determination of the likelihood of threat occurrence.
Determination of the potential impact of threat occurrence.
Determination of the level of risk. Likelihood × impact, scored against a defined scale.
Finalize documentation. Written, dated, with named contributors and an approver.
Periodic review and updates to the risk assessment.

A risk register that maps each identified risk to a control, an owner, and a remediation deadline satisfies elements 4 through 7 in one artifact. Most of the platforms in the 2026 SRA software landscape generate this register as a first-class object.

Scoping in the real world

In a microservices stack, scoping is where engineering teams either save themselves weeks or doom themselves to a re-do.

A practical scope inventory:

Data stores — production DBs, replicas, snapshots, analytics warehouses, S3 buckets, message queues, search indices.
Compute — every service or job that reads, writes, or transforms ePHI.
Egress paths — outbound webhooks, third-party APIs, SFTP, email transports.
Identity and access — IdP, MFA solution, service-to-service auth, break-glass accounts.
Endpoints — workstations and mobile devices that access ePHI, including BYOD if it's allowed.
Vendors with ePHI exposure — every subprocessor, with executed BAA, located in the register.

If a system could see ePHI but is supposed to be excluded by control, document the control. Auditors test the boundary, not the intention.

A risk register pattern you can copy

A single row should answer: what's the asset, what could go wrong, how likely, how bad, what mitigates it today, what's the residual risk, who owns the fix.

asset:           prod-postgres-primary
ephi_present:    yes
threat:          credential compromise of read-replica role
vuln:            read-replica role permits SELECT on patient_records
likelihood:      moderate
impact:          high
inherent_risk:   high
current_ctrls:   - IAM role assumed via OIDC short-lived tokens
                 - row-level security on patient_records
                 - audit log to siem (90d retention)
residual_risk:   moderate
remediation:     promote retention to 365d to satisfy 2026 NPRM
owner:           security-eng-lead
due:             2026-09-30

Repeat for every asset in scope. The 80/20 of an SRA is getting this register populated honestly.

The three safeguard categories you have to evaluate

HIPAA splits required controls into three buckets and your SRA must consider all of them:

Administrative safeguards — security officer designation, workforce training, access-management policies, BAAs, incident response, contingency planning.
Physical safeguards — facility access, workstation security, device and media controls.
Technical safeguards — access controls (unique IDs, automatic logoff, RBAC), audit controls (logging, log review), integrity controls, authentication (MFA strongly expected, mandatory under the proposed 2026 rule), transmission security, encryption at rest.

Engineering teams default to the technical column. The administrative column is what auditors actually probe — show me your BAA register, show me your termination playbook, show me your last incident retro.

What is changing under the proposed 2026 Security Rule update

HHS published a Notice of Proposed Rulemaking in January 2025 that would rewrite the Security Rule for the first time since 2013. The proposal is not yet finalized, but the direction is locked in. The most operationally significant deltas for engineering teams:

The "required" vs. "addressable" distinction goes away. The categories that used to be "addressable" — most notably encryption — would become hard requirements.
A comprehensive technology asset inventory would be required as part of the SRA itself.
Vulnerability scanning at least every six months.
Annual penetration testing for in-scope systems.
MFA mandatory on every system that accesses ePHI.
Encryption at rest mandatory.
Quantitative risk ratings aligned with NIST SP 800-30 — narrative "high concern" descriptions would no longer satisfy the rule.

Build to the proposed standard now. The retrofit cost when the final rule lands is uniformly higher than the cost of doing it right the first time.

How often you have to do this

HIPAA doesn't name a frequency. OCR's de facto position, repeated across enforcement actions:

At minimum annually.
Immediately upon any significant change — new EHR, new cloud migration, a merger or acquisition, a security incident, a material workflow change.
Per-project for new ePHI workflows — onboarding a new vendor with PHI access, launching a new service line.

If your last SRA is more than 12 months old, you are out of compliance regardless of how good the previous one was.

Common engineering-side mistakes

Patterns we see on every audit:

Treating the SRA as a one-time document. It's a program. The report is just the most recent snapshot.
Documenting controls without evidence. OCR's audit posture is "if it isn't documented with proof, it doesn't exist."
Skipping the BAA register. Vendor risk is the second-most-common breach vector after phishing.
Identifying high-priority risks without remediation plans. OCR treats known and unaddressed as worse than unknown.
Forgetting analytics pipelines. That ePHI warehouse you spun up for the data science team is in scope.

A practical starting point

For teams just getting started, Medcurity's 2026 HIPAA SRA template (downloadable PDF from the pillar page) gives you the nine-element structure, the safeguard checklist, and a risk-register skeleton.

FAQ

Is a HIPAA risk assessment the same as a HIPAA audit? No. The SRA is something you perform on your own environment to identify and remediate risks. The audit is OCR or its delegate verifying that you actually did the SRA and addressed the findings.

Does the OCR free SRA Tool satisfy the requirement for a startup? It produces a defensible baseline for a solo practitioner. For a multi-service stack with cloud infrastructure, it's an inadequate substitute for a real risk register, mostly because there is no continuous remediation tracking and no multi-environment aggregation. Treat it as a starter, not a finish line.

Do we need an SRA for the staging environment? If staging holds real ePHI — even briefly — yes. If staging only holds synthetic data, document the control that enforces that boundary.

What does an SRA usually cost? Internal effort: typically 40–120 hours for a mid-sized practice; more for a multi-site or platform organization. Platform-supported SRAs that integrate with control evidence and BAA management materially reduce the per-cycle effort starting in year two.