Map once, comply many: how multi-framework control mapping works

Most companies do not decide to run five compliance frameworks. It happens to them. First a large customer asks for ISO 27001, so the company gets certified. Two years later a US prospect wants a SOC 2 report. Then the company grows past a size threshold and finds itself under NIS2. An automotive customer asks for a TISAX label. And because the product now uses AI, someone in legal starts asking about the EU AI Act.

Each of these requests arrives as a separate project, often with a separate consultant, a separate spreadsheet and a separate audit calendar. After a few years the same security team answers the same questions five times, in five different formats, for five different auditors. Nobody planned it that way. It just accumulated.

“Map once, comply many” is the way out. The idea is simple: describe your company once, build one set of controls, collect each piece of evidence once and connect all of it to every framework that needs it. This guide explains how that works in practice, where it saves the most work, and where it does not help at all.

Why the frameworks overlap so much

Security frameworks are written by different organisations for different audiences. ISO writes for certification bodies, the AICPA for US auditors, the EU for national authorities, the German automotive industry for its suppliers. The language differs, the structure differs and the audits differ.

But underneath, they all ask a short list of the same questions. Who has access to what, and is it still right? Are your systems configured securely and kept up to date? Is data protected in transit, at rest and in backups? Do you notice incidents and respond to them? Do you manage the risk that comes from your suppliers? And for every one of these: is there a written rule, a responsible person and proof that the rule is followed?

Because the questions are the same, the answers are largely the same too. NIS2 Article 21 lists ten areas of risk-management measures, from incident handling to supply chain security, access control and multi-factor authentication. Almost every one of them has a counterpart in Annex A of ISO 27001. For digital service providers, the EU’s NIS2 implementing regulation from October 2024 describes those measures in a way that reads very close to ISO 27001 controls. A company that runs a mature ISO 27001 program has already done most of the technical work NIS2 asks for. What it usually lacks is the mapping that proves it.

The work is rarely missing. The connection between the work you already do and the requirement in front of you is what is missing.

Start with your company, not with a framework

The most common mistake is to start with the framework: open the list of requirements and work through it from top to bottom. That produces answers that fit the framework but not necessarily your company.

The better starting point is a description of the company itself. Which legal entities do you have, and where? Which products and services do you offer? Which systems do you run, and where do they run? What data do you process, and whose? Who are your suppliers, and which of them are critical? How do you use AI?

This description, call it your company model, does two jobs. First, it tells you which frameworks and regulations apply at all. A company that ships connected devices to EU customers is under the Cyber Resilience Act; a company that does not, is not. Second, it tells you which requirements are relevant within a framework. A company without its own data centre does not need controls for the physical security of one.

Every framework is then read against the same model. When the company changes, with a new product, a new cloud provider or a new market, you record the change once, and every framework sees it.

One set of controls, written in your own words

The heart of the approach is a single control set. A control is something your company actually does, written in plain language: “All employees and administrators sign in with multi-factor authentication”, not “A.8.5”. Each control has an owner, a short description of how it is done and the evidence that proves it is done.

Then every requirement from every framework is linked to the controls that satisfy it. The direction matters: you go from the requirement to the control, not the other way round. One control can serve many requirements, and one requirement can need several controls.

Multi-factor authentication is the easiest example. The same control answers ISO 27001:2022 A.8.5 on secure authentication, SOC 2 CC6.1 on logical access, NIS2 Article 21(2)(j) on multi-factor authentication and DORA Article 9(4)(d) on strong authentication, and it supports GDPR Article 32 on the security of processing. One weekly report from your identity provider, showing that every account uses a second factor, is the evidence for all five. You collect it once, you keep it fresh once, and every framework can see it.

Be honest about partial matches

Not every link between a requirement and a control is a perfect fit. It helps to label each one plainly:

• Full: the control completely satisfies the requirement.
• Partial: the control covers part of it, and something extra is needed.
• None: the requirement is new and needs its own control.

Partial matches are where most audit findings come from. A general incident response process covers detection, analysis and recovery, so it looks like a match for NIS2. But NIS2 adds fixed deadlines: an early warning to the authority within 24 hours, a notification within 72 hours and a final report within a month. If your process does not contain those steps, the match is partial, and treating it as full is the classic mistake of multi-framework programs.

A worked example: adding NIS2 to ISO 27001

Let us follow one company through it. Acme is a software company with around 300 employees, ISO 27001 certified for two years. In spring it learns that, because of its size and sector, it is an important entity under NIS2.

Without a mapped control set, Acme would do what many companies do: hire a consultant, run a NIS2 gap analysis from scratch and start a second program. With a mapped control set, the work looks very different.

First, Acme reads NIS2 against its company model. It confirms it is in scope and that it is an important rather than an essential entity, which affects supervision but not the core measures.

Second, it maps the NIS2 measures onto its existing controls. Most of the technical measures are covered already: access control, backups, encryption, vulnerability handling, supplier security. They exist because of ISO 27001.

Third, it lists what is partial or missing. For Acme, that is a short list: the NIS2 reporting deadlines are not in its incident process, the management body has not formally approved the security measures or taken training as Article 20 requires, and the company has not yet registered with the national authority.

Fourth, it turns only those gaps into tasks. Acme extends its incident process with the 24-hour step, schedules a management training, prepares the registration and updates two policies. A few weeks of focused work instead of a second program.

The same pattern works when SOC 2 is added to ISO 27001, DORA to NIS2, or ISO 42001 to an existing ISMS.

What does not map

Mapping removes duplicate work. It does not remove what makes each framework different, and pretending otherwise is how companies get surprised in an audit.

SOC 2 Type II is not about whether a control exists today. It asks whether the control operated effectively over a period, often six to twelve months. You need evidence across that whole period, which means evidence collection has to run continuously, not just before the audit.

NIS2 adds personal accountability for management and fixed incident reporting deadlines that no ISO standard contains.

DORA adds a register of information on all ICT third-party arrangements and specific contract requirements in Article 30. For some financial entities, it also requires threat-led penetration testing.

TISAX works with assessment levels set by the customer and has additional modules, for example for prototype protection, that have no counterpart elsewhere.

The EU AI Act and ISO 42001 add obligations around AI systems: knowing which AI you use, classifying it by risk, ensuring AI literacy and, for high-risk systems, human oversight.

A good mapping makes these differences visible early, so you can plan for them instead of discovering them in the audit.

Keeping the mapping alive

A mapping built once in a spreadsheet starts to decay the day it is finished. Frameworks get new versions, regulators publish guidance and implementing acts, and your company changes every month. Three habits keep it alive.

Collect evidence on a schedule and link each piece to every requirement it supports. Then the freshness of that evidence is tracked once, not five times.

Check coverage regularly, not once a year before the audit. A gap found in March is a task. A gap found by the auditor in November is a finding.

Update the company model first when something changes. A new product, a new supplier or a new country goes into the model, and from there the effect on controls and frameworks becomes visible.

Where to start

If you run more than one framework today, you do not have to rebuild everything at once. Start with the framework you know best, usually ISO 27001, and treat its controls as the first version of your shared control set. Rewrite them in your own words where needed, assign owners and link the evidence you already collect.

Then take the next framework and map it onto that set, labelling every requirement full, partial or none. The first mapping takes the longest. Every one after it gets faster, because most of the controls are already there.

Sources: Directive (EU) 2022/2555 (NIS2), Articles 20, 21 and 23; Commission Implementing Regulation (EU) 2024/2690; Regulation (EU) 2022/2554 (DORA), Articles 9, 28 and 30; ISO/IEC 27001:2022; ISO/IEC 42001:2023; AICPA Trust Services Criteria.