NIS2 Art. 21(2), SOC 2's CC-series, and CRA Annex I, read side by side: mapped letter by letter, eight of the ten measures have at least partial counterpart text in both other texts. The costly risk of a new framework is the second copy of a control you already run, drifting between audits — and where the texts genuinely split, on monitoring, a copied control fails both.
NIS2 Art. 21(2), SOC 2's CC-series, and CRA Annex I, read side by side: mapped letter by letter, eight of the ten measures have at least partial counterpart text in both other texts. The costly risk of a new framework is the second copy of a control you already run, drifting between audits — and where the texts genuinely split, on monitoring, a copied control fails both.
The three documents behind this post don't usually share a desk. Directive (EU) 2022/2555, NIS2, is open law and states its security demands as ten lettered measures. The AICPA Trust Services Criteria, the text behind every SOC 2 report, state theirs as numbered criteria; getting an ungated copy took an archive hunt, more on that below. And Regulation (EU) 2024/2847, the Cyber Resilience Act, puts its demands in an annex of product requirements and vulnerability-handling duties.
The pitch, every time one of these lands, is "new framework, new project." I've read the three texts side by side and I don't buy it: they largely ask for the same controls. The real cost shows up later, in the parallel copies of a control teams run per framework and in what happens to the copies between audits.
NIS2's Art. 21(1) requires "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems", and Art. 21(2) lists what those measures, "based on an all-hazards approach", "shall include at least". Ten letters:
NIS2's list is the cleanest spine for a three-way read. The Trust Services Criteria cover the same ground as single-sentence criteria, CC1.1–CC9.2, with category series (A for Availability) outside the common criteria; CRA Annex I covers it as product properties (Part I) plus eight manufacturer duties for vulnerability handling (Part II). So we go letter by letter: is there counterpart text in the other two (covered, partial, or absent)?
One rule first: this maps coverage, it doesn't rank. Picking a winner between a directive, an attestation framework, and a product regulation would be a category error.
| NIS2 21(2) | SOC 2 TSC anchor | Verdict | CRA Annex I anchor | Verdict |
|---|---|---|---|---|
| (a) risk policies | CC3.2 "identifies risks … and analyzes risks"; CC5.3 | covered | I(1) "cybersecurity based on the risks"; I(2) chapeau | covered |
| (b) incident handling | CC7.3–CC7.5 "defined incident-response program", recovery | covered | I(2)(h) availability "also after an incident"; I(2)(k) | partial |
| (c) continuity, backup, crisis | CC9.1; A1.2 "data backup processes"; A1.3 | covered* | no counterpart text (see below) | absent |
| (d) supply chain | CC9.2 "vendors and business partners" | covered | components only: II(1) SBOM; II(6) "third-party components" | partial |
| (e) secure development, vulnerability handling | CC8.1 change lifecycle; CC7.1 "newly discovered vulnerabilities" | covered | I(1); II(2) "without delay"; II(5) "coordinated vulnerability disclosure" | covered |
| (f) effectiveness assessment | CC4.1 "ongoing and/or separate evaluations"; CC4.2 | covered | II(3) "regular tests and reviews" of the product | partial |
| (g) hygiene and training | CC1.4 "competent individuals"; training in points of focus only | partial | no counterpart text | absent |
| (h) cryptography policy | CC6.7; cryptography in points of focus only | partial | I(2)(e) "encrypting relevant data at rest or in transit" | covered |
| (i) HR security, access control, assets | CC6.1–CC6.3 "least privilege"; CC6.5; CC1.4/CC1.5 | covered | I(2)(d) "authentication, identity or access management systems" | partial |
* Only with the Availability category in scope — A1.2 and A1.3 sit outside the CC common criteria.
The counts need their definitions attached, because the definition changes the number. Against SOC 2 alone, all ten letters find at least partial counterpart text: seven covered, three partial. Against CRA Annex I: three covered, five partial, two absent. Across all three at once, eight of ten measures appear in every text at least in part. But full coverage everywhere is rare: by this table, only (a) risk policies and (e) secure development and vulnerability handling are covered in all three. I'd say the shared ground is real and large, and I'd distrust any overlap percentage quoted without its definition.
Two verdicts are judgment calls, and I want them contestable on the record:
The absences run in both directions, each backed by a logged word search, synonyms included. NIS2 demands two things Annex I never mentions: hygiene and training (training, awareness, hygiene, personnel, staff, employee: zero hits each) and business continuity (backup, disaster recovery, crisis: zero hits each). Only the CRA demands a software bill of materials "in a commonly used and machine-readable format" (II(1); the term appears nowhere in NIS2 or the TSC), shipping "with a secure by default configuration" (I(2)(b)), and free, promptly disseminated security updates (II(8)). And inside SOC 2, multi-factor authentication and cryptography live only in points of focus (the guidance layer under each criterion, and the only layer the 2022 revision changed), never in a criterion sentence.
This is the sharpest split in the table. Here's SOC 2's CC7.2, in full:
"The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events."
Two operating activities in one sentence: monitoring that runs, and analysis of what it surfaces.
Now search NIS2 for the same idea. "Anomal-": zero hits in the entire directive, recitals included. "Logging": zero in the enacting terms — the directive's lone hit is a passing services-list mention in recital 56. Entity-side, "detect" shows up twice in Art. 29(1), a provision on voluntary information-sharing arrangements, and otherwise only inside a definition, Art. 6(8): "'incident handling' means any actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and recover from an incident." NIS2 folds detection into letter (b) by definition, and never requires monitoring, logs or anomaly evaluation in Art. 21(2).
The CRA's monitoring hook points at the product: I(2)(l) says products shall "provide security related information by recording and monitoring relevant internal activity, including the access to or modification of data, services or functions, with an opt-out mechanism for the user". That's a logging capability the product ships with, user opt-out included, rather than an organizational analysis process. "Anomal-": zero hits in the whole regulation.
Here's the drift in evidence terms. An approved incident-handling procedure plus a maintained incident register satisfies the words of 21(2)(b) read with Art. 6(8): the directive asks for measures and procedures. The same binder fails both halves of CC7.2: nothing shows monitoring operating, nothing shows anomalies being analyzed. Reverse it: an alert-triage log from your monitoring stack evidences CC7.2, but covers neither 21(2)(b)'s prevent-to-recover span nor CRA I(2)(l), which asks what the product records and whether the user can opt out.
ISO 27001 has its own monitoring-themed Annex A control, A.8.16. I can name it. I can't quote it, and odds are neither can you.
NIS2 and the CRA are open law on EUR-Lex: free to read, free to grep. The Trust Services Criteria are official but awkward: the current-edition download sits behind an AICPA login (the page's own JSON marks the file "locked"), and the quotable copies are a red-lined PDF on AICPA's CDN and a Wayback-archived 2020 edition. That was the archive hunt. Cross-checked, the thirty criterion texts behind this mapping are word-for-word identical in both editions.
ISO/IEC 27001:2022 tells you on its catalog page that it exists — "Published (Edition 3, 2022)" — and that a conforming ISMS "preserves the confidentiality, integrity and availability of information by applying a risk management process". The text itself is a priced standard: CHF 155 on the catalog page. So when a vendor hands you a mapping sheet with an ISO 27001 column: you can verify the NIS2 and CRA rows against the law, partially verify SOC 2 against archived text, and you cannot check a single Annex A claim without buying the standard. A mapping you can't check isn't necessarily wrong; you're taking it on faith.
Here's what I'd run: one maintained control set, with the NIS2 letters, TSC criteria, and Annex I items recorded per control as mapping notes, and the divergence rows — (b), (g), (h), the CC7.2 split — tracked by name, with an owner. Eight of ten letters share ground in all three texts; a second and third copy of those controls mainly creates extra places for the wording and the evidence to stop agreeing, with nobody assigned to notice.
A single set doesn't dissolve the divergence; these costs stay:
Three questions fall straight out of the mapping rows:
If the answers are "several", "no", and "I'd have to check", the drift is already running, and the mapping notes are the cheapest place to catch it.
One control set answers how to run three frameworks side by side; it doesn't answer where the floor sits for any one of them. For the CRA that question has a surprisingly specific shape, and Vadim took it apart against ENISA's maturity model on Tuesday: Which level of ENISA's SME maturity model is the actual CRA floor?
devguard keeps one control set mapped across frameworks, clause-level notes and divergence rows included: devguard.ch.
Angelo runs strategy and the relationships behind devguard. He spends his time with the teams who live with compliance day to day, and keeps what we build tied to what they actually need.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
| (j) MFA, secured communications |
| CC6.1/CC6.6; MFA is a 2022 point of focus only |
| partial |
| I(2)(d); I(2)(e) confidentiality in transit |
| partial |