Compliant With What? A Working Map of GDPR, HIPAA, SOC 2 and ISO 27001

By John

A security questionnaire lands in your inbox with a checkbox next to four acronyms: GDPR, HIPAA, SOC 2, ISO 27001. Tick them and the deal moves forward. The trouble is that two of those four are things you can hold a document for, and two of them are things nobody on earth can be certified against. “Compliant” is doing an enormous amount of work in that sentence, and it means something different every time.

This is not pedantry. Companies routinely spend six figures and nine months pursuing the wrong artifact for the question their customer actually asked, or run four separate programs over a control set that overlaps by more than half. The map below is the one worth having before any of that money gets spent.

Two of these are laws. Two are claims you pay someone to check.

The cleanest way to sort the four is by what exists at the end of the process.

ISO 27001 ends in a certificate. SOC 2 ends in a report. GDPR and HIPAA end in nothing at all — there is no certification for either, only compliance and the standing risk of an enforcement action. You cannot become GDPR-certified any more than you can become tax-code-certified. You can only be in a defensible position when someone asks.

That distinction drives almost everything downstream. A certificate has a scope, an expiry date, and an auditor whose name is on it. A law has a regulator, a complaint process, and a penalty schedule. The first is something you show a prospect. The second is something you survive.

It also explains a category of wasted effort that shows up constantly in procurement: a customer asks “are you GDPR compliant?” and the vendor answers by attaching an ISO 27001 certificate. The certificate is genuine and it is evidence of something real. It is not an answer to the question, and a buyer with a competent privacy team will notice.

What each one is actually asking

GDPR: do you have a reason to hold this data at all?

GDPR is a privacy law, not a security standard, and the difference matters more than most engineering teams expect. Its central questions are about lawful basis, purpose limitation, data minimisation, and the rights individuals hold over their own records. Security is one article out of ninety-nine.

Its territorial reach is the part that catches non-EU companies: it applies to the processing of EU residents’ data regardless of where the processor sits. Penalties run to €20 million or 4% of global annual turnover, whichever is higher.

Those numbers stopped being theoretical some time ago. Cumulative GDPR fines have reached roughly €7.1 billion across more than 2,500 penalties since 2018, and over 60% of that total was issued after January 2023 — enforcement is accelerating rather than settling. The largest single fine remains the €1.2 billion levied against Meta’s Irish entity in May 2023 over EU–US data transfers; the biggest of 2025 was €530 million against TikTok, again over transfers, this time to China.

HIPAA: are you protecting one specific class of US data?

HIPAA is narrow where GDPR is broad. It is a US federal statute covering protected health information, and it binds covered entities and their business associates — which is how a European SaaS vendor with one American hospital customer ends up inside its scope.

Its Security Rule has, since 2003, split implementation specifications into “required” and “addressable.” Addressable never meant optional, but it was widely read that way, and it is the reason two organisations can both claim HIPAA compliance while one encrypts data at rest and the other has a memo explaining why it doesn’t.

That structure is being dismantled. More on that below, because it is the one part of this map that is actively moving.

ISO 27001: do you have a functioning system for managing security risk?

ISO 27001 certifies a management system, not a product and not a control set. The object being audited is your ISMS: the risk assessment process, the governance around it, the evidence that it runs on a cycle rather than existing as a folder assembled the week before the audit.

The 2022 revision restructured Annex A into 93 controls across four themes — 37 organizational, 8 people, 14 physical, 34 technological — consolidated down from 114 controls in 14 domains under the 2013 version. The document that ties it together is the Statement of Applicability, which lists every Annex A control, states whether it applies, and justifies each exclusion in writing. An auditor reads the SoA first. It is the closest thing in the standard to a confession.

Certification comes from an accredited certification body via a two-stage audit, and the certificate runs three years with surveillance audits in between. The scope statement on that certificate is worth reading carefully — a certificate covering one product line in one data centre is a very different assurance from one covering the whole company, and both look identical at a glance.

SOC 2: can an accountant vouch for you to your customer?

SOC 2 is an AICPA framework, and the artifact it produces is an attestation report carrying a CPA firm’s opinion — not a certificate, despite the number of vendor sites that call it one. Type I says the controls were designed appropriately at a point in time. Type II says they operated effectively across a period, typically three to twelve months, and it is the only one enterprise buyers take seriously.

The framework is built on the Trust Services Criteria, of which only Security is mandatory; Availability, Processing Integrity, Confidentiality and Privacy are elected. Two SOC 2 reports can therefore describe wildly different scopes while both being “SOC 2 Type II.” It is a US-market instrument above all — outside North America, ISO 27001 usually carries more weight.

The overlap is real, and the number nobody agrees on

Everyone selling compliance software will tell you SOC 2 and ISO 27001 overlap heavily. They do. The interesting part is that the published figures range from 43% to about 85%, and the spread is not sloppiness — it is measuring two different things.

Map control names and the overlap looks enormous. AICPA’s own crosswalk is cited at roughly 80%; other analyses put around 78% of SOC 2’s Trust Services Criteria as having direct or partial mappings into ISO 27001:2022’s Annex A, and 60–70% is the most commonly repeated range.

Map evidence and it collapses. A-LIGN’s benchmark work found that only about 43% of SOC 2 evidence also satisfies ISO 27001 requirements. The controls rhyme; the artifacts an auditor will accept for each frequently do not. Both frameworks want access reviews — one wants the review, the other wants the review plus the risk assessment that determined its frequency plus the SoA entry justifying the control’s applicability.

The practical lesson is directional and worth stating plainly: build the ISO 27001 evidence set and most of it will serve a SOC 2 audit. Build the SOC 2 evidence set first and you will be assembling a substantial amount of new documentation when you go for ISO. That sequencing decision is worth more, in real hours, than any tooling choice made afterwards. Teams that have been through a structured compliance audit before the first external engagement generally find this out on a whiteboard rather than three weeks into fieldwork.

What the evidence actually looks like

Framework documents describe controls in the abstract. Audits are won or lost on artifacts, and the artifacts are more mundane than the standards make them sound.

An access review is not a policy saying access will be reviewed quarterly. It is an exported list of every account in a system, a record of who looked at it, a date, and a visible outcome — three accounts removed, two downgraded. Change management is not a branch protection rule; it is the pull request showing an approver who was not the author. Onboarding and offboarding evidence is a ticket per person, with timestamps, that a sample can be pulled from. Vendor management is a register with a review date that has actually moved in the last year.

Two categories catch teams out consistently. The first is testing that only counts if it happened: an incident response tabletop with notes and attendees, and a backup restoration test that produced a restored system rather than a successful backup job. Plenty of organisations have never restored from backup in anger and discover this in the middle of fieldwork. The second is the risk register, which under ISO 27001 has to demonstrate a process — risks identified, owners assigned, treatment decisions recorded, the whole thing revisited on a cycle. A register created once and frozen tells an auditor exactly what it looks like.

The structural reason this matters is the SOC 2 Type II observation window. Type II examines a period, typically three to twelve months, and evidence has to exist across that period. There is no retroactive fix. A quarterly access review cannot be performed four times in the week before the audit, and an auditor who sees four reviews with adjacent timestamps will say so in the report. This is the single most common reason a first Type II slips: the controls were fine, the calendar was not.

Which is why the useful framing is not “prepare for an audit” but “run the process and let the audit read the exhaust.” Every control that produces evidence as a side effect of normal operation — ticketing, code review, an IdP’s own logs, automated vulnerability scanning — costs nothing at audit time. Every control that requires someone to remember to write something down becomes a gap. Designing for the first category is the whole game, and it is equally true whether the destination is a certificate, a report, or a regulator’s questions after an incident.

Why GDPR has no certificate, even though Article 42 says it might

GDPR does contemplate certification. Article 42 encourages the establishment of data protection certification mechanisms, seals and marks, and the EDPB maintains a register of the ones formally approved. So the “there is no GDPR certification” line needs a footnote.

The footnote is that management-system certifications don’t qualify. ISO 27001 and ISO 27701 are both explicitly outside Article 42’s scope, because an Article 42 certification must target specific processing activities rather than a management system wrapped around them. ISO 27701 is a genuinely useful privacy extension to an ISMS and it will make a GDPR programme easier to run. It is not a GDPR certificate and no regulator will treat it as one.

What does qualify is a much shorter list. Europrivacy is the scheme furthest along toward recognition as a European Data Protection Seal, with the EDPB issuing Opinion 15/2026 on its criteria, including their use for international transfers under Articles 42 and 46. Even so, an Article 42 seal demonstrates compliance for the processing it covers. It does not immunise the organisation.

Which leaves documentation as the actual deliverable. Records of processing, DPIAs, a lawful-basis analysis that predates the processing rather than reconstructing it afterwards, transfer mechanisms, and a defensible answer to the DPO question — the failure mode is almost never a missing certificate, it is a data map nobody maintained after the initial project closed.

HIPAA is being rewritten, and “addressable” is what’s going

The one genuinely unstable piece of this map sits in Washington. OCR issued a Notice of Proposed Rulemaking on 27 December 2024, published 6 January 2025, proposing the most substantial overhaul of the HIPAA Security Rule in two decades. The comment period closed on 7 March 2025 with more than 4,000 submissions.

The central change is the removal of the required-versus-addressable distinction. Under the proposal, essentially every implementation specification becomes mandatory, with narrow exceptions. Encryption at rest and in transit, multi-factor authentication, network segmentation, a maintained asset inventory and network map, defined restoration timelines after an incident, and annual written verification that business associates have the required safeguards in place — all of it moves from “document why not” to “do it.”

As of August 2026 the final rule has not landed. It was expected in May 2026 and is overdue, with reporting suggesting it may emerge in slimmed-down form. Enforcement is anticipated within 240 days of finalisation, which means the practical planning horizon for anyone touching PHI is short and the direction of travel is not in doubt.

Meanwhile the existing rule is being enforced. OCR closed 21 enforcement actions in 2025, its second-highest annual total, against a backdrop of more than 374,000 complaints filed since 2003. The 2026 penalty schedule tops out at an annual cap of $2,190,294 for the most serious tier.

What it costs, and where the money actually goes

Published figures vary by vendor incentive, so treat these as ranges rather than quotes. A SOC 2 Type II audit fee generally lands between $12,000 and $70,000, with total programme spend — readiness assessment, tooling, penetration testing, internal time — more realistically $30,000 to $150,000. A workable timeline is six to nine months, consuming somewhere around half to one full-time equivalent spread across a programme owner, DevOps, IT and engineering.

ISO 27001 adds surveillance audits of roughly $7,500 in each of years two and three, on top of the initial certification. Readiness work runs $10,000–15,000, tooling another $10,000–20,000, penetration testing $10,000–15,000.

The line item that never appears in those estimates is the one that dominates: engineering attention. Compliance automation vendors advertise reductions from 550–600 hours of self-managed effort per year down to around 75 — a marketing figure, and worth reading as one, but it points at something true. Most of the cost of a first audit is not the auditor. It is the six months of evidence collection that happens because nobody was logging access reviews in a form anyone could export.

The question is never “which one should we get”

It is “who is asking, and what will satisfy them.”

An enterprise buyer in the US asking for security assurance wants SOC 2 Type II. An international buyer, or a public-sector one, wants ISO 27001. A European customer worried about their own regulator wants a Data Processing Agreement, a transfer mechanism, and evidence you know where their data lives — not a certificate. A US healthcare customer wants a Business Associate Agreement and, increasingly, proof of the specific controls the new Security Rule will require whether or not it has been finalised.

Answer those four questions honestly and the sequencing usually resolves itself. Build the ISMS once, map the evidence outward, and treat the certificates as reporting formats on top of a single control set rather than four parallel programmes. Organisations that get this wrong rarely fail an audit — they pass all of them, four times over, at four times the cost, and discover afterwards that the standards were never the hard part.

None of these frameworks was designed to make a company secure. They were designed to make it demonstrable. Keeping that distinction in view is what stops a compliance programme from quietly becoming a documentation exercise with a security theme.