One control set, four frameworks: mapping compliance so you only do the work once
ISO 27001, SOC 2, ENS and NIS2 overlap heavily. Running them as four separate projects triples the cost. How to build a single control set with a single evidence pipeline, and where the mapping genuinely breaks down.
A company that sells in Europe and North America, to both enterprise and public sector, eventually needs ISO 27001, SOC 2, something like ENS, and NIS2 obligations on top. Run as four projects with four owners and four sets of documents, this is most of a security team's year, every year.
Run as one control set with four mappings, it is substantially less — but only if you build it in that order. Retrofitting a mapping onto four existing document sets is harder than starting with one.
Why the overlap is so large
All of these frameworks are trying to make the same organisation do the same things: know what you have, control who can reach it, keep logs, patch, back up, train people, manage suppliers, handle incidents, and prove you did.
Where they differ is in vocabulary, in the evidence format, and in who attests. ISO 27001 certifies a management system; SOC 2 is an attestation about controls described in your own words; ENS assigns measures by system category; NIS2 is a legal obligation with a notification clock and management liability. The underlying engineering is largely identical.
Published estimates of the control overlap between ISO 27001 and SOC 2 sit around 80 percent. Our experience with ENS on top of ISO is similar once the category is fixed.
Build the control set first, frameworks second
The structure that works is an internal control register where each row is a thing you actually do, not a thing a framework asks for:
| ID | Control | Owner | Evidence source | ISO 27001 | SOC 2 | ENS | NIS2 |
|---|---|---|---|---|---|---|---|
| AC-04 | Quarterly access review across cloud, IdP, repo, DB | Head of Eng | compliance/access-reviews/ |
5.18 | CC6.2, CC6.3 | op.acc.5 | Art. 21(2)(i) |
| VM-02 | Scanner findings triaged to SLA by severity | Security | Issue tracker query | 8.8 | CC7.1 | op.exp.4 | Art. 21(2)(e) |
| BC-01 | Monthly restore test with recorded RTO | SRE | compliance/restores/ |
8.13, 5.30 | A1.2 | mp.info.6 | Art. 21(2)(c) |
The control is written once, performed once, evidenced once. The framework columns are a lookup, used when an auditor arrives asking in their own vocabulary.
Two properties make this work. Every control has exactly one owner, and every control has an evidence source that is a path or a query rather than a person's memory. A row whose evidence source is "ask Marta" is a row that will fail an audit the week Marta is on holiday.
Make the evidence source machine-produced where you can
The mapping saves duplicated documentation. The bigger saving is not producing evidence four times, and that comes from making the evidence a by-product of the control running.
A restore test that writes its result to a dated file in a repository produces evidence for ISO 8.13, SOC 2 A1.2, ENS mp.info.6 and NIS2 Article 21(2)(c) simultaneously, without anybody taking a screenshot. A posture scan that stores a dated report proves encryption, logging and MFA controls held on every day of a SOC 2 observation window and on the day an ENS auditor asks.
The rule of thumb: if producing the evidence for a control requires a human to remember to do something, it will be produced for the first audit and not for the second.
Where the mapping genuinely breaks
Do not pretend the mapping is total. Four places where it is not:
Scope boundaries differ. ISO 27001 scope is what you declare. SOC 2 scope is the system described in the report. ENS scope is per system, by category. PCI DSS scope is determined by data flow. The same control can be in scope for one and out for another, and a single "in scope: yes/no" column is wrong. Track scope per framework.
Attestation mechanics differ. SOC 2 requires you to write the control description and then be tested against your own words — so vague wording hurts you twice. ISO tests against the standard. ENS tests against a prescribed measure at a prescribed category level. The same underlying control needs three different descriptions, and that is unavoidable work.
Time windows differ. SOC 2 Type II tests across a period. ISO tests at a point with evidence of operation. ENS and NIS2 have their own cadences. A control that runs quarterly satisfies one and may not satisfy another.
NIS2 and DORA are law, not certification. There is no auditor to satisfy and no certificate to hold; there is a regulator, a notification clock and personal liability for management. You can map the measures, but you cannot map the 24-hour reporting obligation or the board approval trail onto anything in ISO. Those are separate builds.
Sequence for a company starting from nothing
Do ISO 27001 first if Europe is your market, SOC 2 first if North America is. Build the control register and the evidence pipeline during that first framework, knowing the others are coming — one extra column costs nothing at the time and saves months later.
Then add the second framework as a mapping exercise plus a gap list, which is typically weeks of work rather than months. Then handle the legal obligations, which are mostly about notification capability and governance records rather than new controls.
The failure pattern is the opposite: each framework run by a different person, under deadline pressure from a different deal, producing its own document set. Three years in, that company has four sets of policies that disagree with each other and an engineering team that has learned to treat compliance as a tax. The mapping is not just cheaper — it is the difference between controls that operate and documents that exist.