One risk assessment for ISO 27001, SOC 2 and HIPAA

Risk assessment is where three of the most common frameworks start. ISO 27001 builds everything on it (clause 6.1.2). SOC 2 dedicates a section of its common criteria to it (CC3.1 to CC3.4). The HIPAA Security Rule makes the risk analysis its first required implementation specification (§164.308(a)(1)(ii)(A)), and it's the first document HHS investigators request. Many organisations run three. One is enough.

What each framework checks

• ISO 27001 wants a defined, repeatable method with criteria for acceptance; risks identified for confidentiality, integrity and availability; owners; analysis of likelihood and consequence; and a link to risk treatment and the Statement of Applicability.
• SOC 2 wants objectives specified clearly enough to identify risks (CC3.1), risks identified and analysed across the entity (CC3.2), fraud risk considered (CC3.3) and changes assessed (CC3.4).
• HIPAA wants an accurate and thorough assessment of risks and vulnerabilities to ePHI, wherever it is created, received, maintained or transmitted, kept up to date and followed by risk management (§164.308(a)(1)(ii)(B)).

In our data these requirements link directly:

Framework	Risk Assessment	Link
NIST CSF 2.0	ID.RA-03ID.RA-04ID.RA-05ID.RA-06	Topic definition
ISO 27001	Clause 6.1.2Clause 6.1.3	Crosswalk
CIS v8.1	—	No mapping in our data
SOC 2	CC3.2CC3.4CC3.3	Editorial
PCI DSS	12.3.1	Crosswalk
CMMC	RA.L2-3.11.1	Crosswalk
800-53	RA-3RA-7	Crosswalk
HIPAA	§164.308(a)(1)(ii)(A)	Crosswalk
GDPR	Art.35(1)Art.35(7)	Editorial
NIS2	2.1	Crosswalk
Essential Eight	—	No mapping in our data

Full detail and the reason for every link: Risk Assessment across frameworks →

Designing one assessment for all three

1. Scope it to cover everything: the ISMS scope, the SOC 2 system and every location of ePHI. Record which assets fall under which framework.
2. Use one method: asset or scenario based, with a likelihood and impact scale, acceptance criteria and owners. ISO's requirements for a documented, repeatable method are the strictest, so meet them.
3. Add the framework-specific prompts: fraud risk (SOC 2 CC3.3), ePHI-specific threats and vulnerabilities (HIPAA), and legal and contractual risks.
4. Link every risk to treatment: controls chosen, residual risk, owner's acceptance. That one table feeds the ISO Statement of Applicability, SOC 2's control activities and HIPAA's risk management.

Outputs that satisfy all three auditors

• The method, approved.
• A risk register with owners, scores and treatment decisions.
• A risk treatment plan with dates.
• Owners' acceptance of residual risk.
• Evidence of review at least annually and after significant change.

A simple risk register format

One row per risk works for all three frameworks:

Field	Example
Risk	Ransomware encrypts the production database
Assets	Production database, backups, ePHI store
Frameworks	ISO 27001, SOC 2, HIPAA
Likelihood and impact	Possible, severe
Existing controls	MFA, EDR, nightly backups
Treatment	Isolate backups; test restores quarterly
Owner	Head of infrastructure
Residual risk and acceptance	Medium, accepted by the CTO
Review date	Next quarter

The frameworks column is the trick: it lets one register answer three auditors without three spreadsheets.

Key takeaways

• One method and one register can satisfy ISO 27001, SOC 2 and HIPAA.
• Add the framework-specific prompts: fraud risk and ePHI locations.
• Review it at least annually and after significant change.

Common findings

• Generic risks ("hackers", "data breach") with no link to specific assets or controls.
• No owners, or the security team owning every risk.
• ePHI locations missed: exports, backups, email, test systems.
• Out of date: assessed once for the first audit and never again.

For more on how these frameworks relate, see the ISO 27001 vs HIPAA comparison and the Risk Assessment topic. The gap analysis shows every mapping between any two.

Questions

Is the HIPAA risk analysis the same as an ISO 27001 risk assessment?

They overlap heavily. HIPAA requires an accurate and thorough assessment of risks to the confidentiality, integrity and availability of ePHI; an ISO 27001 risk assessment that includes ePHI in scope and records the HIPAA-specific elements can serve both.

How often must a risk assessment be done?

ISO 27001 requires risk assessments at planned intervals and after significant change. SOC 2 auditors typically expect a risk assessment at least annually. HIPAA requires the risk analysis to be kept current.

Should the risk assessment be qualitative or quantitative?

Either works for all three frameworks, as long as the method is defined, applied consistently and produces comparable results. Most organisations start qualitative and add numbers where decisions need them.