Control Mapping: SOC 2, ISO 27001, HIPAA, PCI DSS

Compliance control mapping is the practice of linking each internal control you operate to every framework requirement it satisfies, so one access review counts for SOC 2 CC6.1, ISO 27001 A.5.15, HIPAA 164.308(a)(4), PCI DSS Req. 7, and GDPR Art. 32 at the same time. Done properly it removes the duplicated majority of a second framework, typically leaving a company that has finished SOC 2 with roughly 40% of ISO 27001 still to do rather than 100%. The work it does not remove is the framework-specific machinery, and knowing which is which is the whole skill.

The situation that forces this on people is always the same. You did SOC 2 because an enterprise deal needed it. Six months later a European customer asks for ISO 27001, or you sign a healthcare client and suddenly HIPAA is in scope, or you move payments in-house and PCI DSS arrives. The instinct is to treat framework number two as a fresh project, hire a consultant, and start a new spreadsheet. That instinct is expensive, because the frameworks were largely written about the same handful of security practices.

What is control mapping in compliance?

Control mapping links one control to many requirements. A control is the thing you actually do: quarterly user access reviews, mandatory MFA, code review before merge, an annual policy approval cycle. A requirement is a framework's way of asking for it. Control mapping records the relationship, so when the control is satisfied, every requirement pointing at it is satisfied too, and when the control lapses, everything it supports goes amber at once.

The reason this matters more than it sounds is evidence. Frameworks do not just want the control to exist, they want proof it operated. If your controls are tracked per framework, you collect the same access review screenshot three times, file it in three places, and let it go stale in all three independently. If they are mapped, you collect it once and it lands everywhere it counts. That is where the actual savings sit, not in the policy documents.

There is a naming quirk worth knowing. Auditors and standards bodies usually call the mapping between two specific frameworks a crosswalk, and reserve control mapping for the internal exercise of connecting your controls to requirements. Vendors use both words interchangeably. NIST publishes formal crosswalks, including one between the AICPA Trust Services Criteria and the NIST Privacy Framework, which is a good model for what a rigorous mapping looks like.

The control mapping crosswalk: one control, five frameworks

This is the overlap in practice. Each row is one thing you do, with the code each framework uses to ask for it. Codes are the current versions: the AICPA 2017 Trust Services Criteria with revised points of focus from 2022, ISO/IEC 27001:2022 Annex A, the HIPAA Security Rule at 45 CFR Part 164, PCI DSS v4.0.1, and the GDPR articles.

Control you operate	SOC 2	ISO 27001:2022	HIPAA Security Rule	PCI DSS v4.0.1	GDPR
Access granted on business need, reviewed periodically	CC6.1, CC6.2	A.5.15, A.5.18	164.308(a)(4)	Req. 7	Art. 32
Unique IDs and multi-factor authentication	CC6.1	A.5.17, A.8.5	164.312(d)	Req. 8	Art. 32
Documented risk assessment with treatment decisions	CC3.2	Clause 6.1.2	164.308(a)(1)(ii)(A)	Req. 12.3	Art. 35 where DPIA applies
Change management on infrastructure and code	CC8.1	A.8.32	164.308(a)(8)	Req. 6.5	Art. 32 by implication
Logging, monitoring, and log review	CC7.2	A.8.15, A.8.16	164.312(b)	Req. 10	Art. 32
Incident response plan, tested and owned	CC7.4, CC7.5	A.5.24, A.5.26	164.308(a)(6)	Req. 12.10	Art. 33, Art. 34
Approved, versioned information security policies	CC5.3	A.5.1	164.316	Req. 12.1	Art. 24
Security awareness training with completion records	CC1.4	A.6.3	164.308(a)(5)	Req. 12.6	Art. 39 where a DPO exists
Vendor and third-party risk management	CC9.2	A.5.19, A.5.20	164.308(b), business associate agreements	Req. 12.8	Art. 28
Encryption in transit and at rest	CC6.7	A.8.24	164.312(a)(2)(iv), 164.312(e)	Req. 3, Req. 4	Art. 32(1)(a)
Vulnerability management and patching	CC7.1	A.8.8	164.308(a)(1)(ii)(B)	Req. 6.3, Req. 11.3	Art. 32
Backup and recovery, tested	A1.2 where availability is in scope	A.8.13	164.308(a)(7)	Req. 12.10.1 in the response plan	Art. 32(1)(c)
Physical and environmental access control	CC6.4	A.7.1 to A.7.4	164.310	Req. 9	Art. 32
Secure disposal of media and data	CC6.5	A.7.14, A.8.10	164.310(d)(2)	Req. 9.4.6, Req. 3.2	Art. 17

Read down any column and you are looking at most of a framework. Read across any row and you are looking at one piece of engineering or process work that you were going to do anyway. Fourteen rows is not the complete picture of any of these frameworks, but it is a fair picture of where the duplication lives, and it covers the majority of what a small company actually gets asked to evidence.

How much of ISO 27001 does SOC 2 actually cover?

Roughly 60% in our experience of running both, and that number is worth unpacking because it gets quoted as though it were measured. It is not a percentage of clauses. It is a rough share of the effort, and it comes almost entirely from Annex A. A company with a clean SOC 2 Type 2 has already implemented and evidenced most of the organizational and technological controls in Annex A, because those are the same controls the CC series asked for.

What SOC 2 gives you nothing for is Clauses 4 through 10, the management system itself. Scope definition, the Statement of Applicability covering all 93 Annex A controls with justifications, internal audit at planned intervals, and management review. None of that has a SOC 2 equivalent, and it is the part teams underestimate, because it is administrative rather than technical and nobody enjoys it. Plan for the ISMS machinery as genuinely new work and the rest as a mapping exercise. The difference between SOC 2 and ISO 27001 is mostly this, not the controls.

How do you map controls between HIPAA and PCI DSS to avoid duplicate work?

Start from your controls, not from either framework's table of contents. Write down what you actually operate, then attach both sets of codes to each one. The overlap between HIPAA and PCI DSS is heavy on access control, authentication, logging, encryption, and workforce training, so the rows above carry most of it: HIPAA 164.312(d) authentication and PCI Req. 8 are the same MFA program, 164.312(b) audit controls and Req. 10 are the same logging pipeline, 164.308(a)(5) and Req. 12.6 are the same annual training.

The parts that genuinely do not merge are the scoping concepts. PCI DSS cares about the cardholder data environment and expects you to define its boundary, segment it, and scan it quarterly through an Approved Scanning Vendor. HIPAA cares about electronic protected health information wherever it lives and expects a risk analysis under 164.308(a)(1)(ii)(A) that HHS treats as required rather than addressable. Those are two different inventories of two different data types, and no crosswalk collapses them. Map the shared control layer, keep the two data scopes separate, and you have done the honest version of this.

How to build a control map that survives an audit

Five steps, in this order. Skipping the first is the most common failure.

1. Inventory the controls you actually operate. Not the ones your policies claim. Walk your infrastructure, identity provider, code repository, and HR onboarding, and write down what genuinely happens on a schedule. A control map built on aspirational controls fails the first time an auditor samples one.

2. Pick a primary framework and map to it fully. Whichever one you are being audited against first becomes the spine. Every control gets its primary code. Gaps become work items with owners and dates rather than notes.

3. Attach secondary codes to each control. This is the crosswalk step, and it is where the table above saves you a week. Attach every framework code a control satisfies, including frameworks you have not started yet. Doing it now costs nothing and means the second framework arrives pre-filled.

4. Attach evidence to the control, not to the framework. This is the step that most spreadsheets get wrong. If the access review evidence is filed under SOC 2, it is invisible when the ISO auditor asks. File it against the control, and let every mapped requirement point at the same artifact. Our guide to what counts as audit evidence covers what each type has to show.

5. Record what does not map. Every framework has a residue that belongs to it alone. Write those down explicitly as framework-specific obligations. A control map that implies 100% overlap is worse than no map, because it hides the remaining work until an auditor finds it.

What does not map, framework by framework

This is the section most vendor pages skip, and it is the one that determines whether your second framework runs to schedule.

ISO 27001 keeps the ISMS clauses: documented scope, the Statement of Applicability, internal audit, and management review on a cadence. It also wants a risk methodology written down rather than just risk decisions recorded.

GDPR keeps its records of processing under Art. 30, lawful basis for each processing activity, data subject rights handling, data processing agreements with every processor under Art. 28, and the 72-hour breach notification clock in Art. 33. No SOC 2 control produces any of that. Art. 32 security is the only part that maps cleanly.

HIPAA keeps the risk analysis as a named, required implementation specification, plus business associate agreements with every vendor touching electronic protected health information, and the workforce sanction policy. HHS guidance lists nine elements a risk analysis has to cover, and a SOC 2 risk assessment written for CC3.2 rarely covers all of them without being extended.

PCI DSS keeps cardholder data environment scoping, the annual Self-Assessment Questionnaire and attestation, quarterly external scans by an Approved Scanning Vendor, and payment page script controls under Req. 6.4.3 and 11.6.1 if you validate on SAQ A-EP or SAQ D. Software can track those dates but cannot perform the scans.

SOC 2 keeps the system description written by management under the AICPA description criteria, and the choice of which Trust Services Categories beyond security you scope in. Nothing in another framework produces that document for you.

Where evidence reuse actually works, and where it does not

Mapping a control is a claim about requirements. Reusing evidence is a claim about artifacts, and auditors are stricter about the second. The reliable pattern is that a technical artifact generated by a system, an IAM export, a monitoring configuration, a pull request history, a completed training report, gets accepted across frameworks without argument, because it is the same fact about the same system.

Where reuse gets pushed back on is timing and scope. A Type 2 examination tests a window, so evidence has to fall inside that window. An ISO certification body sampling the same control will want evidence from its own audit period, which will not line up with your SOC 2 window. And an artifact scoped to one environment does not automatically cover another: an access review of your production AWS account says nothing about the separate environment where card data lives. Collect on a recurring schedule and the timing problem disappears, because there is always evidence inside any given window.

Training is a good example of the pattern working. The same annual security awareness completion report satisfies SOC 2 CC1.4, ISO A.6.3, HIPAA 164.308(a)(5), and PCI Req. 12.6, provided it names every person who took it and when. Most teams run that through a platform that delivers the training and issues the completion records, then attach the export to a single control that all four frameworks point at. One report, four requirements, no re-collection.

Is there an ISO 27001 to SOC 2 mapping spreadsheet?

Plenty exist, and they are a reasonable way to see the shape of the overlap before you commit to anything. Two cautions. First, no official mapping is published by either the AICPA or ISO, so every spreadsheet you download is somebody's interpretation, and the good ones say so. Second, a spreadsheet maps requirements to requirements, which is the easy half. The half that matters is mapping your controls to those requirements and keeping the evidence attached as things change, and a cell in a spreadsheet does not chase a quarterly access review or notice that a policy went stale.

That is the point at which teams move the map into something that tracks state. Control mapping software holds the control, its framework codes, its owner, its evidence, and its next due date on one record, so a lapse shows up in every framework it touches on the day it happens rather than during fieldwork.

How do teams coordinate evidence collection across frameworks?

The teams that do this well share one habit: a single control register, owned by named people, with recurrence built in. Not a folder per framework. Each control has an owner who knows which requirements depend on it, evidence arrives on a cadence rather than on request, and the framework view is a filter over the register instead of a separate system.

The operational tell that you have got it right is what happens when a new framework arrives. If adding it means a new spreadsheet and a new evidence drive, the map is not real. If it means selecting a framework and watching most of it come back pre-filled from controls you already run, with a short list of genuinely new obligations, then the mapping is doing its job. That is what SOC 2 compliance software should feel like the second time around, and it is why the second framework should never cost what the first one did.

Three mistakes that break a control map

Mapping requirements to requirements instead of controls to requirements. A framework-to-framework crosswalk tells you the standards overlap. It does not tell you whether you have implemented anything. The map has to start from your controls or it is reference material, not a program.

Letting the overlap claim outrun the evidence. Marking an ISO control satisfied because a SOC 2 control maps to it, without checking that the evidence covers the ISO audit period and scope, produces a readiness score that collapses under sampling. Map the requirement, then confirm the artifact.

Treating the residue as rounding error. The 40% of ISO 27001 that SOC 2 does not cover is the ISMS, and it takes real calendar time because internal audit and management review have to actually happen. Teams that budget only for the mapped 60% miss their certification date for reasons that were entirely predictable in month one.

Get the register right and control mapping stops being a spreadsheet exercise and becomes the thing that makes framework three cheaper than framework two. That compounding is the entire argument for doing it deliberately instead of discovering the overlap by accident.