Control Framework Crosswalk Template (ISO 27001, NIST CSF, SOC 2, NIS2, DORA)

Control Framework Crosswalk: [Organization name]

Maps the ISO/IEC 27001:2022 + Amd 1:2024 management system clauses and a selection of Annex A controls to five other frameworks that customers and regulators often ask about: NIST Cybersecurity Framework (CSF) 2.0, the AICPA Trust Services Criteria used in SOC 2 reports (criterion IDs only), the cybersecurity risk-management measures in Article 21(2) of the NIS2 Directive, the chapters and articles of the Digital Operational Resilience Act (DORA), and CIS Controls v8.1 (control numbers and names only). Use it to test a control once and reuse the evidence, to answer "do you cover framework X?" honestly, and to find the gaps a single framework leaves. A mapping row shows that two requirements address related outcomes; it never shows that they are equivalent. Replace every [bracketed] value and every row marked Example. This is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

1. Purpose and scope
2. Frameworks covered
3. Mapping method and caveats
4. Management system clauses mapping
5. Annex A controls mapping
6. Reverse gaps: requirements without a strong ISO/IEC 27001 counterpart
7. Using the crosswalk: test once, report many
8. Size tiers
9. Maintenance and change triggers
10. Records and evidence
11. References

1. Purpose and scope

This crosswalk links the controls that [Organization name] operates under its ISMS (scope DOC-ISMS-002, SoA DOC-ISMS-011) to the other frameworks it reports against. It supports four uses:

1. Evidence reuse. One control test and one evidence set serve several audits or assessments, recorded in the control evidence matrix (DOC-ISMS-033).
2. Gap analysis. When a new framework applies, the crosswalk shows which requirements are already served, which are partly served and which need new work.
3. Customer and regulator questions. The security and sales teams answer framework questions from one approved source instead of improvising.
4. Audit planning. Internal audit (DOC-ISMS-082) and external assessors can plan combined fieldwork where requirements overlap.

In scope: the clauses 4 to 10 of ISO/IEC 27001:2022 and the Annex A controls listed in section 5 (a selection of the 93; extend it to every applicable control in your SoA). Out of scope: privacy frameworks, which belong in the PIMS documents (isms/pims-27701-statement-of-applicability), and AI management controls, which belong in isms/iso-27001-42001-integrated-soa.

2. Frameworks covered

DORA chapter legend (article ranges as commonly cited; confirm in the Official Journal text): Chapter II ICT risk management, Art. 5 to 16; Chapter III ICT-related incident management, classification and reporting, Art. 17 to 23; Chapter IV digital operational resilience testing, Art. 24 to 27; Chapter V management of ICT third-party risk, Art. 28 to 44 (Art. 28 to 30 key principles and contracts, Art. 31 to 44 oversight of critical providers); Chapter VI information-sharing arrangements, Art. 45.

CIS Controls v8.1 legend (numbers and names only): 1 Inventory and Control of Enterprise Assets; 2 Inventory and Control of Software Assets; 3 Data Protection; 4 Secure Configuration of Enterprise Assets and Software; 5 Account Management; 6 Access Control Management; 7 Continuous Vulnerability Management; 8 Audit Log Management; 9 Email and Web Browser Protections; 10 Malware Defenses; 11 Data Recovery; 12 Network Infrastructure Management; 13 Network Monitoring and Defense; 14 Security Awareness and Skills Training; 15 Service Provider Management; 16 Application Software Security; 17 Incident Response Management; 18 Penetration Testing.

NIS2 Article 21(2) legend (short paraphrases of the topic of each point, not the legal text): (a) risk analysis and security policies; (b) incident handling; (c) business continuity, backup, disaster recovery and crisis management; (d) supply chain security; (e) security in acquisition, development and maintenance, including vulnerability handling and disclosure; (f) assessing the effectiveness of measures; (g) basic cyber hygiene and training; (h) cryptography and encryption; (i) human resources security, access control and asset management; (j) multi-factor or continuous authentication and secured communications. The chapeau of Article 21(2) also calls for an all-hazards approach that protects systems and their physical environment.

3. Mapping method and caveats

3.1 Direction and unit

Rows are written from ISO/IEC 27001 outwards: each row starts with one clause or Annex A control and lists the requirements in the other frameworks that address a related outcome. Reading a row backwards ("CC6.1 is covered by A.5.15") is not safe, because the other framework may ask for more, or for something different. Section 6 lists the known reverse gaps.

3.2 Strength rating

3.3 Caveats that apply to every row

• Many-to-many. One ISO/IEC 27001 control can serve several criteria, and one criterion can need several controls. Do not force one-to-one rows.
• Not equivalence. Frameworks differ in purpose: ISO/IEC 27001 is a risk-based management system, CSF 2.0 describes outcomes, SOC 2 criteria are examined by an auditor against a system description, NIS2 and DORA are law, and CIS Controls are prescriptive safeguards.
• Legal obligations stay legal. A mapping never discharges a duty under NIS2 or DORA. National transposition of NIS2 may add or change details; check the law of each Member State where you operate with qualified counsel.
• Official mappings first. NIST publishes Informative References for CSF 2.0 (see NIST SP 1347, the quick-start guide on Informative References) and the AICPA and CIS publish their own mappings. Where an official mapping exists, compare your rows with it and record differences in the "Notes" column of your working copy.
• Selection. Section 5 lists a selection of Annex A controls that typically carry cross-framework weight. Controls not listed may still map; add rows as needed.
• Names-only sources. SOC 2 criteria are cited by ID only and CIS Controls by number and name only. Do not paste criterion text or safeguard text into this document.

3.4 Mapping workflow

Build and maintain the rows in this order. Two reviewers rate any row for which no official mapping exists, and the CISO approves the result.

4. Management system clauses mapping

5. Annex A controls mapping

5.1 A.5 Organizational controls

5.2 A.6 People controls

5.3 A.7 Physical controls

5.4 A.8 Technological controls

Row count check. Section 4 has 18 rows (XW-001 to XW-018) and section 5 has 70 rows (32 in 5.1, 7 in 5.2, 5 in 5.3, 26 in 5.4), 88 rows in total. Recount after you add or delete rows, and keep IDs stable: retire an ID rather than reuse it.

6. Reverse gaps: requirements without a strong ISO/IEC 27001 counterpart

7. Using the crosswalk: test once, report many

7.1 Evidence reuse rules

1. Record each control test once in the control evidence matrix (DOC-ISMS-033), with the population, sample, period and result.
2. For each Strong row, tag the test with every framework it serves.
3. For each Partial row, add a supplementary test or record and tag it only with the framework that needs it.
4. Align sample periods: if a SOC 2 Type 2 period runs from January to December, schedule ISMS internal audit sampling inside that period so the same records serve both.
5. Keep one owner per control, whatever the number of frameworks.

7.2 Worked example

Example: Quillmere Health Systems (medium tier, 320 staff) runs an ISO/IEC 27001 certification project and receives SOC 2 Type 2 requests from US hospital customers. EU hospital customers treat it as a key supplier under their NIS2 supply chain measures and flow requirements down by contract. DORA does not apply. The ISMS manager uses this crosswalk to plan one evidence cycle.

Example: the team estimated 210 separate control tests before the crosswalk (126 for SOC 2 and 84 for the ISMS internal audit) and 148 after it, because the 41 Strong rows removed 62 duplicate tests (several Strong rows carry more than one test) (210 - 62 = 148). Use your own figures and record the estimate method; these numbers are illustrative only.

7.3 Answering framework questions

When a customer asks "are you NIST CSF aligned?" or "do you meet NIS2 Article 21?", answer from this crosswalk and the SoA, state the framework edition, and avoid words such as "compliant" or "certified" unless an assessment or certificate supports them. Store approved answers in isms/security-questionnaire-answer-library.

8. Size tiers

9. Maintenance and change triggers

Review the crosswalk at least once a year and whenever:

• a mapped framework publishes a new version or errata (for example a new CIS Controls release, new SOC 2 criteria or points of focus, or a NIST CSF update or new Informative References);
• national NIS2 transposition or DORA technical standards change what is expected in a jurisdiction where you operate;
• the SoA changes a control decision or status;
• a new customer contract names a framework not yet mapped;
• an audit or assessment finds that a Strong row did not hold.

Record each review in the revision history and report material changes to management review (DOC-ISMS-085).

10. Records and evidence

11. References

Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 (clauses 4 to 10 and Annex A numbering). The mapping rows, strength ratings, short labels, gap analysis and examples are original work and reproduce no text, tables or definitions from ISO or IEC standards; read the official standard, which is copyrighted and sold by ISO, IEC and national standards bodies (https://www.iso.org/standard/82875.html). AICPA Trust Services Criteria are cited by ID only and CIS Controls by number and name only. NIS2 and DORA summaries are short paraphrases; read the official texts and national law. The mapping is a starting judgement, not an official or authoritative mapping. Check the current edition of every framework before use. This is a documentation format, not legal advice. Template licence: MIT.