SOC 2, HIPAA & GDPR Control Crosswalk: Map Once, Satisfy Three Frameworks

TL;DR — what overlaps, what doesn’t

If you already run a SOC 2 audit against the Trust Services Criteria, you have built most of the technical security controls that HIPAA and GDPR also demand. In our coordinated examinations, the reusable core is consistent: identity and access management, encryption in transit and at rest, centralized logging and monitoring, formal change management, vulnerability management, and vendor due diligence. That work carries over. What does not carry over is the paperwork and rights machinery unique to each regime — and that is exactly where teams over-claim coverage and get caught in enterprise diligence.

The honest framing is: SOC 2 gives you a large head start on HIPAA’s safeguards and on GDPR’s security of processing — but not on HIPAA’s Business Associate Agreements or GDPR’s privacy-governance duties. This guide gives you the control-by-control crosswalk, a shared-evidence matrix, and the specific gaps to flag rather than paper over.

The three frameworks are not the same kind of thing

Before mapping controls, separate the categories. A crosswalk fails the moment someone treats a SOC 2 report as if it “certifies” HIPAA. SOC 2 is a CPA attestation performed under the AICPA’s attestation standards (SSAE 18, with concepts in AT-C section 105 and the examination performed under AT-C section 205) that results in an independent auditor’s opinion. HIPAA is a US statutory rule enforced by HHS’s Office for Civil Rights — there is no government-issued HIPAA certificate; compliance is self-determined and demonstrable through documentation and, optionally, third-party assessment. GDPR is an EU regulation whose compliance is shown through accountability documentation, not a single certificate.

This matters commercially. A buyer’s security team may accept your SOC 2 report as evidence of your control environment, but their legal team will still want a signed Business Associate Agreement (for PHI) or a Data Processing Agreement (for EU personal data). Those are contractual obligations that no attestation replaces. For financial-reporting controls, note that SOC 1 / ICFR is a separate report and is out of scope for this security-focused crosswalk.

The master crosswalk: SOC 2 TSC ↔ HIPAA 45 CFR 164 ↔ GDPR Article

The table below is the centerpiece. It maps each control domain to its SOC 2 Trust Services Criteria identifier, the corresponding HIPAA Security Rule section in 45 CFR 164, and the relevant GDPR article, then states the shared control and the single reusable evidence artifact. The final column flags the framework-specific overlay you still owe.

A note on methodology: defensible crosswalks route through a neutral control spine rather than asserting one-to-one matches. NIST SP 800-53 and the NIST Cybersecurity Framework 2.0 are the common anchors most GRC tooling uses; ISO/IEC 27001:2022 Annex A is the credential many EU processors present for GDPR. Where a mapping is approximate, we say so. HIPAA implementation specifications marked † Addressable are currently addressable (not optional — you must implement or document why an alternative is reasonable); see the regulatory-status note after the table.

Regulatory-status note (dated July 1, 2026). The rows above reflect the HIPAA Security Rule as currently in force: technical safeguards live at 45 CFR 164.312 and several implementation specifications — including encryption/decryption and automatic logoff — are Addressable, meaning you must implement them or document a reasonable alternative. HHS published a Notice of Proposed Rulemaking on 6 January 2025 that would eliminate the Required/Addressable distinction and make measures such as encryption at rest and in transit, MFA, and network segmentation mandatory. As of this update the NPRM is not finalized, it missed its spring-2026 target, and more than 100 provider groups have asked HHS to withdraw it, citing (among other things) HHS’s own roughly $9 billion first-year cost estimate. Treat the † Addressable cells as current law, but design toward the proposed baseline, because encryption and MFA are best practice regardless.

Where the frameworks diverge — the gaps you cannot map away

The most common and most damaging mistake is assuming that because the security core overlaps, the whole framework is covered. It is not. In real coordinated examinations, the controls that most often fail to transfer are the governance and rights obligations that live entirely outside SOC 2’s security scope. The table below is the object to reference when a questionnaire asks “does your SOC 2 cover HIPAA/GDPR?”

HIPAA-only: ePHI and the BAA chain

HIPAA’s safeguards apply specifically to electronic protected health information, and its Privacy Rule (45 CFR Part 164, Subpart E) governs uses and disclosures that SOC 2 never touches. If you handle PHI on behalf of a covered entity, you are a business associate and must sign a Business Associate Agreement under 164.308(b)(1) — and flow equivalent terms down to your own subprocessors. A SOC 2 report can evidence the safeguards behind that BAA, but it cannot be the BAA.

GDPR-only: rights, records, and transfers

GDPR’s privacy-governance obligations have no SOC 2 or HIPAA equivalent. You need a documented lawful basis (Art. 6), a way to honour data-subject rights (Arts. 15–22), Records of Processing Activities (Art. 30), Data Processing Agreements with processors (Art. 28), and Data Protection Impact Assessments for high-risk processing (Art. 35). On transfers, the 2026 reality is that the EU-US Data Privacy Framework (the European Commission’s July 2023 adequacy decision, upheld by the EU General Court on 3 September 2025) lets a US organisation that self-certifies to the DPF receive EU personal data without additional safeguards. For recipients not DPF-certified, Standard Contractual Clauses plus a transfer impact assessment remain the fallback (Arts. 44–49). The DPF’s durability carries residual risk tied to US surveillance law (Section 702 FISA), so many teams keep SCCs ready as a backstop.

Collect once, satisfy many — the shared-evidence matrix

The operational payoff of a crosswalk is evidence reuse. Instead of collecting an access review three times for three audits, you collect it once and tag it to all three frameworks. The matrix below shows which artifact proves which requirement, how often to collect it, and who owns it. Pair it with disciplined audit evidence management so every artifact is complete, timestamped, and attributable.

GRC platforms such as Vanta, Drata, Secureframe, and Sprinto ship pre-built cross-mappings and automate much of this collection — “test once, satisfy many.” That tooling is genuinely useful for continuous monitoring. What it does not provide is the independent opinion a buyer’s procurement team ultimately relies on. Position a GRC tool as the evidence engine and a licensed CPA attestation as the assurance layer on top; the two are complementary, not competing.

How much of a head start does SOC 2 give you?

A mature SOC 2 (Security) program covers a large share of HIPAA’s technical and administrative safeguards, because CC6–CC8 map closely to 45 CFR 164.312 and 164.308. Vanta states that organisations already SOC 2 compliant “may be up to 65% of the way toward HIPAA compliance, based on controls cross-mapped in Vanta.” That is a useful directional benchmark — but it is a Vanta-tool-specific estimate, not an independent industry figure, so treat it as a competitor claim rather than a law of nature. The defensible way to talk about overlap is by safeguard family, not a single blended percentage.

For a stage-by-stage view of sequencing as you grow, see our compliance roadmap from seed to Series C. If you are weighing dual financial-plus-security reporting, our note on when you need SOC 1 and SOC 2 together covers that adjacent decision.

What a SOC 2+ report is — and what it does not replace

The value is efficiency and credibility: one scoping exercise, one evidence set, one fieldwork window, one report your buyers can read. Rather than running three disconnected projects, a coordinated examination tests the shared security core once and layers the framework-specific mappings on top. That is how a well-run audit methodology avoids the “audit fatigue” of collecting the same access review three times.

The guardrail matters because the central over-claim in this space is treating a SOC 2+ report as a HIPAA “certification.” There is no such thing — HIPAA is a statutory obligation with no government certificate. A SOC 2+ demonstrates that your controls align with HIPAA’s safeguards; you remain responsible for the BAA chain, ePHI-scoped risk analysis, and breach-notification obligations. For EU stakeholders who prefer an international assurance standard, the closest equivalent examination is ISAE 3000.

Build your unified control library in five steps

The mechanics of “map once, satisfy three” come down to a single control register that is framework-tagged and evidence-keyed. Here is the sequence we run in coordinated engagements.

1. Scope the systems and data. Name the systems, cloud environments, and subprocessors in scope, and classify the data each touches (general data, ePHI, EU personal data). Scope drives everything downstream — getting it wrong cascades into the wrong controls and wrong evidence.
2. Build one control register. Create a single list of controls with a stable ID and a role-based owner for each. Do not maintain separate SOC 2, HIPAA, and GDPR lists — that is where drift starts.
3. Map each control to all three frameworks. Tag every control with its SOC 2 criterion, HIPAA CFR section, and GDPR article using the master crosswalk above. Flag the framework-specific overlays (BAA, RoPA, DSR, transfers) as their own controls so nothing is silently assumed “covered.”
4. Define shared evidence and cadence. For each control, name the single reusable artifact, its collection frequency, and its system of record — the shared-evidence matrix above is the template. Add a pre-submission quality gate.
5. Run coordinated audit cycles. Schedule one examination that tests the shared core once, then layers framework-specific testing. Feed findings back into the register so the next cycle is faster.

Common mapping mistakes

The failure modes below recur in nearly every first coordinated engagement. Each maps to a specific gap in the crosswalk.

• Mapping only 164.312 and ignoring 164.308/164.310. HIPAA is broader than technical safeguards — administrative safeguards (risk analysis, workforce security, BA contracts) at 164.308 and physical safeguards at 164.310 must be mapped too, or your crosswalk covers a third of the rule.
• Assuming SOC 2’s Privacy category equals GDPR. SOC 2 Privacy (P1.0–P8.0) only partially addresses GDPR. Data-subject rights (Arts. 15–22), lawful basis, RoPA (Art. 30), DPIAs (Art. 35), and transfers (Arts. 44–49) remain GDPR-only.
• Treating a SOC 2+ report as a HIPAA certification. It is assurance of alignment, not a certificate, and never a substitute for a signed BAA.
• Running one breach playbook that misses the 72-hour clock. A single incident-response control can satisfy both regimes only if it defaults to GDPR’s tighter “where feasible, within 72 hours of awareness” standard while also meeting HIPAA’s 60-day-from-discovery rule.
• Citing SCCs as the only transfer mechanism. In 2026 the EU-US Data Privacy Framework is the primary route for DPF-certified US recipients; SCCs plus a transfer impact assessment are the fallback.