How to Map ISO 27001, SOC 2 and UK GDPR Evidence Once

Running ISO 27001, SOC 2 and UK GDPR in parallel can feel like three audits wearing one badge. Each framework asks for evidence, but the requests often overlap. The real problem is not missing features in a compliance automation software platform. It is control mapping. When one control library maps controls to outcomes and risks, ISO 27001, SOC 2 and UK GDPR become views of the same evidence rather than separate projects. This tutorial shows how that model works. You will see why parallel frameworks create duplicate work, what published mappings cover and where gaps remain, how a single control library operates, and a worked example of one evidence item satisfying three frameworks. You will also learn how to keep the library current when a standard is revised and what questions to ask any compliance automation platform. By the end, mapping will look less like a one-time project and more like an operating discipline.

Why Running ISO 27001, SOC 2 and UK GDPR in Parallel Doubles the Work

Multi-framework duplication is not created by the standards. It is created by organising evidence per framework instead of per control. ISO 27001 Annex A controls, the SOC 2 Trust Services Criteria and UK GDPR accountability duties overlap far more than most teams assume. The published AICPA and CIMA mapping exists precisely because that overlap is real.

The symptoms are concrete. The same quarterly access review screenshot is requested three times. The same information security policy is re-uploaded into three folders under three naming conventions. One control owner fields separate requests from an ISO auditor, a SOC 2 auditor and an internal GDPR review, then answers the same question three times.

That vocabulary mismatch keeps the overlap invisible. Annex A speaks in control objectives. The TSC speak in outcome-based criteria, evaluating whether a system and its controls give reasonable assurance that management's objectives are met. UK GDPR speaks in principles and accountability duties, including the security of processing and records of processing activities. Nothing lines up by name, so nothing gets reused.

Practitioners in multi-framework programmes commonly report that duplication consumes much of their audit preparation effort. Treat that as a reported pattern, not a statistic: no primary study quantifying audit time lost to cross-framework duplication was identified for this piece.

This is a buyer's problem, not a documentation one. Searches for compliance automation software, compliance process automation and compliance workflow automation rise when duplication becomes an operational bottleneck, yet checklist automation layered onto a clause-first library automates the duplication faster. Three folders become three workflows.

The fix is structural, and it starts with deciding which certification frameworks you actually need: you do not need three control sets, you need one control library with three framework views, and the sections that follow build that model.

What Published Mappings Cover, and the Gaps You Have to Fill Yourself

Cross-framework mapping is not a vendor invention. AICPA and CIMA published a mapping of the 2017 Trust Services Criteria to ISO 27001 requirements in May 2018, updated for the March 2020 TSC changes, as a spreadsheet (trust-services-map-to-iso-27001.xlsx, around 138 KB). It is the strongest published precedent for this model.

The limitation matters: the download is restricted to AICPA members and only a short abstract is public, so row-level mappings cannot be verified from outside. Cite it as evidence that cross-framework mapping is established practice, not as a table to lift and reuse.

The criteria justify a risk-first library. They are outcome-based tests of whether a system and its controls give reasonable assurance that management's objectives are met, and management must first understand the risks that could prevent those objectives being reached. Map controls to outcomes and risks, never to clause numbers.

UK GDPR is the weakest leg: no equivalent published mapping to ISO 27001 Annex A or to the TSC was identified for this piece. Treat it as a third lens, applied through accountability principles, security of processing and records of processing duties, and work from the UK GDPR text and ICO guidance rather than assuming a clause-level table exists.

Three honest limits before you read on. No independent comparison of multi-framework compliance platforms was found; no quantified study of audit time saved by mapping was found; and public documentation of how platforms handle standard revisions is thin. Every DataDoc capability referenced later is a vendor claim, labelled as one. See Building a Multi-Framework Audit Documentation Strategy for the documentation side, then build the library itself.

The Mapping Model: One Control Library, Frameworks as Views

Published crosswalks help, but the real work is architectural. The mapping model inverts the usual structure: the control library is the master record, and ISO 27001, SOC 2 and UK GDPR are views over it. A control exists once, is written once, is tested once, and carries its framework references as metadata rather than being copied into framework-specific sets.

The minimum control record. Six fields: a plain-language control statement, the risk or objective it addresses, the control owner, the test or assurance activity, the evidence artefact type with its collection frequency, and one or many framework references. Keep references (an Annex A clause, a TSC criterion, a UK GDPR article) out of the control statement itself; once a clause number enters the wording, the control is framework-shaped again.

Sequence risk first. Define the objectives you are protecting, identify the risks that would prevent them being met, then design or adopt controls that address those risks (risk-anchored controls survive framework renumbering; clause-anchored ones do not).

Evidence as a first-class layer. Evidence types are defined once, with an owner, a cadence and a collection method, and one artefact links to every control it satisfies. That is what turns reuse from accident into design, and where compliance workflow automation earns its place by routing one collection cycle to three framework references, as covered in mapping evidence across frameworks.

Governance stops decay. One named library owner, a documented change process for adding or retiring controls, a review cadence, and a clear line between mapping a control and testing it. Without these, the library tends to drift back toward per-framework sprawl, a pattern practitioners in multi-framework programmes consistently report.

Intake changes. Evidence requests are raised against a control, never a framework, and a control is only added when it maps to at least one risk. Judge regulatory compliance automation on that discipline, not on framework count. A worked example shows the payoff.

Worked Example: One Evidence Item Satisfying Three Frameworks

The model only proves itself when one artefact carries three framework tags. The example below is illustrative: it applies published mapping methodology and the outcome-based framing of the Trust Services Criteria (TSC), not a verified row-level extract from the members-only AICPA spreadsheet, and it does not replace framework-specific procedures.

Take a quarterly user access review record and tag it once:

• ISO 27001 Annex A: the access control requirement, evidenced against the statement of applicability.

• SOC 2: a TSC criterion addressing logical access.

• UK GDPR: a principle-level lens on security of processing and demonstrable accountability, not a claimed clause-level mapping.

Reuse is auditable only through metadata: artefact name and version, control owner, collection frequency, source system, period covered, and the framework references the artefact is tagged to. Without that tagging, an auditor sees a screenshot rather than traceable assurance.

Each audience reads the same file differently. The ISO auditor wants the control described and evidenced against the statement of applicability. The SOC 2 auditor wants the criterion addressed and the period covered. The UK GDPR reviewer wants the processing risk and the accountability record. These are presentation differences, not three separate pieces of evidence.

Acceptance varies by scope and engagement. Some frameworks still demand framework-specific artefacts or additional sampling, so mapping reduces repeat collection rather than eliminating every requirement. Automating that collection cycle, as covered in How DataDoc Automates Access Control Evidence Across 100+ Frameworks, makes the reuse repeatable; How to Build an Effective Audit Checklist Before You Buy Software covers what to verify before committing.

Keeping the Library Current When a Standard Is Revised

A mapping is a snapshot. ISO editions move, the standard has been revised more than once, and each revision can affect how Annex A controls are numbered and scoped. The Trust Services Criteria were reissued with revised points of focus in 2022, adding and revising points of focus without modifying the criteria themselves. ICO guidance keeps developing. An unmaintained library still looks complete, which is precisely what makes it dangerous.

Two failure modes need separate watching. Mapping drift: the framework changed but the library was never re-reviewed, so a control reads plausibly while no longer answering the criterion. Evidence expiry: the artefact no longer covers the current period, or no longer reflects how the control actually operates after a process change.

Staying current is bookkeeping done deliberately. Version the mapping, not just the controls. Record which edition or version each framework reference targets. Schedule a standing review ahead of known revision cycles instead of reacting to an auditor finding. Keep a change history showing who edited a mapping, when, and why.

Historical evidence needs an explicit decision. When a reference is superseded, document whether previously collected evidence remains valid for the period it covered, and confirm that framework reports generated before the change stay reproducible from the library. The ISO 27001:2022 Standard: What Changed and Why It Matters Now is a useful example of a transition managed this way.

Public documentation on how compliance platforms handle standard revisions is thin. Treat revision handling as an evaluation question, not a solved problem; the questions section below sets out what to ask.

Without tooling, start small. One mapping register in a spreadsheet, with a target edition column and a next review date per reference, prevents most drift and costs almost nothing.

Questions to Ask Any Compliance Automation Platform

Treat those questions as your demo script, and run every check against your own three-framework scenario.

Mapping architecture. Ask whether the library is control-centric or framework-centric, and whether one control can reference ISO 27001 Annex A, a Trust Services Criterion and a UK GDPR accountability duty at once. Confirm the mapping is editable by you, and that you can export the full control-to-framework mapping in a usable format.

Revision handling. Ask how revisions are detected and communicated, who updates the mappings, how quickly, what happens to evidence collected under a superseded reference, and whether mapping changes carry a visible change history. Request a live walkthrough, not a slide.

Evidence mechanics. Establish how artefacts are tagged, how duplicate collection is prevented when several frameworks reference one control, how differing auditor formatting requests are handled, and how sampling requests route to the correct control owner.

Reporting. Test whether framework-specific, audit-ready outputs come from the same evidence set, whether reports are reproducible for a historical period after the library changed, and whether each report line traces back to its underlying artefact.

Governance and exit. Cover user roles, the audit trail on mapping changes, data location, and how that sits with your controller obligations under UK GDPR, where the ICO sets out what distinguishes controllers from processors. Then ask how you extract the mapping, evidence metadata and report history on exit.

Claims to verify. DataDoc states support for more than 100 frameworks, including GDPR, ISO 27001, SOC 2, CCPA and NIST, a 14-day free trial with no credit card required, and audit-ready reports generated in minutes. DataDoc's compliance automation coverage is the starting point; verify each claim against your own scenario before you rely on it.

Conclusion: Make Mapping a Discipline, Not a Project

Those questions work best when you have something of your own to test them against.

Start with the library, not the tool. Write one control statement per control, attach the risks and objectives it addresses, then attach framework references as metadata. ISO 27001, SOC 2 and UK GDPR then become views over a single record rather than parallel control sets.

Verify DataDoc's claims against your own three-framework scenario in a live demo. Running the quarterly access-review proof described in the worked example above is the fastest way to find out.

Put revision review on the calendar with a named owner, a target edition column for each standard, and a documented change history. Mapping drift costs the most and gets noticed the least.

When you evaluate compliance automation platforms, score mapping architecture, revision handling, evidence tagging, reproducibility and exit rather than framework count.