The 2026 HIPAA Risk Assessment Pattern for Healthcare APIs

Originally published at medcurity.com. Mirrored here for engineering teams shipping healthcare-adjacent software.

If you ship any service that reads, writes, or transports electronic protected health information (ePHI) — an EHR integration, a patient-portal API, a telehealth platform, a clinical-data analytics pipeline, a healthcare mobile app — your organization is required by HIPAA to maintain a current Security Risk Analysis (SRA). The SRA is the foundational compliance artifact under the HIPAA Security Rule and the single document that the U.S. Office for Civil Rights (OCR) cites most often in enforcement actions.

This article is the engineering team's view of the SRA: what the regulation actually requires, how to scope your APIs and services into it, a copy-pasteable risk-register schema, how to map technical controls to the rule, and how to coordinate cleanly with the non-engineering compliance owners who sign off on the result.

The regulation, in one paragraph

HIPAA's Security Rule lives at 45 CFR Part 164 Subpart C. The risk-analysis requirement specifically lives at 45 CFR §164.308(a)(1)(ii)(A), which states that covered entities and business associates must:

"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 legal text. Operational meaning is filled in by OCR's published guidance, by NIST SP 800-66 Rev. 2, and by NIST SP 800-30 Rev. 1. The OCR audit checklist breaks the analysis into nine documentation elements covering scope, data flows, threats and vulnerabilities, current controls, likelihood, impact, risk level, written sign-off, and periodic review.

If your company processes ePHI on behalf of a covered entity — even briefly, even just for an integration — you are a business associate and you must produce your own SRA covering your stack. The 2013 Omnibus Rule made business associates directly liable. Your SaaS does not get a pass because the hospital signed a BAA with you.

The engineering surface

Scoping is where engineering teams either save themselves weeks of audit prep or doom themselves to a re-do. The engineering surface of an SRA is the union of every code path, data store, and integration that could see ePHI.

A realistic scope inventory:

Data at rest

• Production primary databases

• Read replicas and analytics replicas

• Snapshots and backups

• Data warehouses or lakes

• Object storage buckets (especially anything an export job writes to)

• Search indices

• Caches that hold materialized records

Compute and code

• Every service that reads or writes ePHI

• Background workers and queue consumers

• Scheduled jobs

• Notebooks or one-off scripts the data team runs

Data in transit

• Internal service-to-service APIs

• Public-facing APIs (REST, GraphQL, gRPC, FHIR)

• Outbound webhooks

• Third-party API calls

• SFTP and other batch transports

• Email transports that may include ePHI in body or attachments

Identity, access, and observability

• Identity provider (Okta, Auth0, Cognito, AzureAD)

• MFA enforcement layer

• Service-to-service auth (mTLS, OIDC client credentials, signed tokens)

• Break-glass admin accounts

• Audit logs (where they live, retention, who can read them)

• SIEM or log analytics platform

Endpoints

• Engineering workstations with production DB access

• Bastion hosts

• Mobile or kiosk devices used in production support

Third parties (subprocessors)

• Every vendor with potential ePHI exposure

• Status of executed BAA for each

• Data residency / data handling per BAA

A useful test for whether a service should be in scope: could it see ePHI under any reasonable failure mode? If yes, it's in scope. If a control is supposed to keep it out of scope, document the control.

A copy-pasteable risk-register schema

The risk register is the heart of the SRA. One row per identified risk; one document for the whole organization. A schema engineers can paste into a YAML file, a structured Markdown table, or whatever issue-tracker satisfies your auditor:

- id: RR-2026-014
  asset: patient_records.prod-postgres-primary
  ephi_present: true
  threat: "Compromise of analytics read-replica role
    via credential theft"
  vuln: "Read-replica role retains SELECT on
    patient_records.*; rotated quarterly only"
  likelihood: moderate     # NIST 800-30: low/moderate/high
  impact: high             # NIST 800-30: low/moderate/high
  inherent_risk: high      # likelihood x impact matrix
  current_controls:
    - "OIDC-issued short-lived tokens, max 1h"
    - "Row-level security on patient_records.patient_id"
    - "Audit log to SIEM, 90-day retention"
  residual_risk: moderate
  remediation:
    - control: "Extend SIEM retention to 365d
        for 2026 NPRM compliance"
      owner: security-eng-lead
      due: 2026-09-30
      status: in_progress
  last_reviewed: 2026-06-05

The hard part is not the schema; it is keeping the register honest. Auditors detect a stale register in minutes — the dates give it away. Tie register updates to your change-management process so any ePHI-touching deploy can be required to consult, and optionally amend, the register.

For the foundational structure and the official OCR nine-element checklist, Medcurity's 2026 HIPAA SRA template (downloadable from the pillar page) is one starting point. The structure is generic enough to adapt to any internal documentation system.

Mapping technical controls to the three safeguard categories

HIPAA splits required controls into three buckets and your SRA must address all three. Engineering teams default to the technical column; the administrative column is what auditors actually probe.

Administrative safeguards. Designated security officer, workforce training, access-management policies, executed BAAs with subprocessors, incident response, contingency planning. From an engineering perspective: who is named in your runbook, what does workforce onboarding/offboarding actually do to access, and is the BAA file actually current.

Physical safeguards. Facility access, workstation positioning, device controls, secure media disposal. Mostly out of engineering's lane, but production-support workflows that involve engineer-owned devices fall here.

Technical safeguards. Unique user IDs, automatic logoff, audit logging and log review, integrity controls, authentication (MFA strongly expected; mandatory under the proposed 2026 rule), transmission encryption, encryption at rest. This is where engineering lives. The audit-log review part is where engineering teams most often fall short — having logs is necessary but not sufficient. Auditors ask who reviews them, on what cadence, with what runbook for anomalies.

The 2026 NPRM and what it means for your roadmap

HHS published a Notice of Proposed Rulemaking in January 2025 that would rewrite the Security Rule for the first time since 2013. Not yet finalized as of mid-2026; direction is locked. Engineering-relevant deltas:

• The "required" vs. "addressable" distinction goes away. Most addressables become hard requirements, encryption being the headline.

• Comprehensive technology asset inventory required as part of the SRA itself.

• Vulnerability scanning at minimum every six months on in-scope systems.

• Annual penetration testing for in-scope systems.

• MFA mandatory across every system that accesses ePHI.

• Encryption at rest mandatory.

• Quantitative risk ratings aligned with NIST SP 800-30 — qualitative narrative no longer satisfies.

The practical advice: build to the proposed standard now. Retrofitting MFA across a service mesh, or moving an unencrypted warehouse to envelope encryption, is uniformly more expensive than designing it in at the start.

Coordinating with non-engineering compliance owners

In most healthcare organizations, the SRA is owned by a compliance officer who is not an engineer and reviewed by a security officer who may or may not be. The clean coordination pattern that works across the engineering teams we have seen:

1. Engineering owns the technical surface map: services, data flows, endpoints, third parties. Living document maintained alongside the architecture diagram.

2. Engineering owns the technical-safeguards section of the risk register and the technical-control evidence behind each line item.

3. The compliance officer owns scope decisions, the administrative safeguards section, the BAA file, workforce-training records, and the periodic-review schedule.

4. Both sign the final document. Both have a calendar event for the annual refresh.

The failure mode to avoid: the compliance officer producing the SRA from a template without input from engineering, and then learning at audit time that the documented control set does not match the deployed system. Engineering should be reading and commenting on the document before sign-off, every cycle.

Common patterns that fail audits

Patterns we see repeatedly:

1. Stale register. Last last_reviewed date is more than a year old. Auditors notice instantly.

2. Identified high risks with no remediation plan. OCR treats known and unaddressed as worse than unknown.

3. Controls without evidence. "We have encryption" is not a control statement. "We have AES-256 encryption at rest on the EHR database via AWS RDS, verified by quarterly CIS Benchmark scan, last scan 2026-05-12, evidence in /security-evidence/2026-Q2/" is.

4. Missing analytics pipelines. The data-science team's warehouse is almost always overlooked and almost always in scope.

5. No log-review cadence. Logs exist; nobody reads them; auditors ask who, on what schedule, with what playbook.

Operational starting points

• The full pillar overview, target audience non-technical: What Is a HIPAA Risk Assessment? (2026 Guide).

• HHS OCR guidance: Guidance on Risk Analysis Requirements.

• The NIST implementation guide: SP 800-66 Rev. 2.

• The NIST methodology: SP 800-30 Rev. 1.

• The regulation itself: 45 CFR §164.308 on eCFR.

The SRA does not need to be perfect to satisfy the rule. It needs to be honest, complete, current, and tied to a remediation track-record. Engineering's contribution is the surface map and the technical-control evidence; the rest follows from there.