Mapping controls to DORA, ISO 27001 and SOC 2 at once

Somewhere in your organization there is a spreadsheet that maps your vendor controls to SOC 2. Next to it is another spreadsheet that maps almost the same controls to ISO 27001. And since January 2025, a third has been growing for DORA. Three artifacts, three owners, three versions of the truth, all describing one set of controls and all drifting apart a little more each quarter.

The fix is structural, and it is the single highest-leverage change a compliance-heavy risk program can make: stop mapping frameworks to each other, and map every framework to one canonical control set. Answer each control once, with evidence, and let the frameworks be views over it.

Why frameworks converge more than they diverge

Strip away the numbering schemes and the three regimes ask overlapping questions. Access control, encryption, incident response, business continuity, vendor oversight, logging, change management: the core is common. The honest overlap between ISO 27001 Annex A and SOC 2's Trust Services Criteria is commonly estimated at 70–80% of controls; DORA's ICT risk management requirements land on much of the same ground, with a sharper focus on operational resilience and, notably for this audience, on the ICT third parties you depend on.

Answering the common core three times is not rigor. It is triple data entry, and every copy is a chance to contradict yourself in front of an auditor.

The canonical control set

Build one internal control library (yours, not any framework's) where each control has a single owner, a single statement, and a single evidence trail. Then map each framework requirement onto it:

• One control, many citations. "Access to production systems requires MFA and quarterly review" satisfies ISO A.5.15/A.5.18, SOC 2 CC6.1–CC6.3, and DORA Art. 9 in one record. The citations live on the control, not in separate spreadsheets.
• Evidence attaches to the control, not the framework. The quarterly access-review export is uploaded once and cited three times. When the auditor for any regime asks, the trail is already there.
• Gaps become visible instead of triplicated. When a control fails or lapses, you immediately see every framework it dents: one remediation, three regimes advanced.

Where the frameworks genuinely differ, isolate the delta

Map the common core first, then handle each regime's real specifics as a small explicit delta rather than a whole parallel program:

• ISO 27001 wants the management system itself: risk assessment methodology, Statement of Applicability, internal audit, management review. Mostly artifacts about how you run the program.
• SOC 2 wants operating effectiveness over a period: the same controls, but with evidence they ran all year. This changes evidence discipline, not control design: collect continuously, not in a panic before the audit window.
• DORA adds the pieces TPRM teams should care about most: a register of information covering all ICT third-party arrangements, contractual provisions for critical providers, exit strategies, resilience testing, and incident reporting clocks. For most organizations the register alone is the forcing function that finally makes the vendor inventory real.

In practice the deltas are 20–30% of each regime. That is the part that deserves fresh work, not the 70% you have already answered twice.

Extend the same trick to your vendors

The map-once principle applies on both sides of the questionnaire. If you assess suppliers with bespoke questionnaires per framework, you are exporting the same triple-entry problem to hundreds of vendors, and they respond exactly as you would: slowly, with copy-paste, and with drift between versions.

Instead, assess against your canonical control set and let the framework mapping do the translation. One well-built questionnaire scores a vendor once and reads out against SOC 2, ISO, and DORA simultaneously. Vendors answer faster because the questions overlap honestly, and your reviewers stop re-scoring the same answer under three headings.

Keeping the map alive

A control map is not a project; it is an asset with a maintenance schedule. Three habits keep it from rotting:

• Version the mappings. Frameworks revise (ISO 27001:2022 reshuffled Annex A; DORA technical standards are still landing). Citations need dates and a named maintainer.
• Review the map when controls change, not annually. A retired control should immediately show which requirements just lost coverage.
• Let the map generate the audit view. If preparing for an audit still means assembling a bespoke pack by hand, the map exists but is not working. The readout for any framework should be a filter, not a fortnight.

The payoff compounds. The second framework costs a fraction of the first; the third is mostly paperwork on the delta. And when the next regulation arrives (and it will) you will map it onto controls you already run, instead of starting a fourth spreadsheet.