ISO 27001 Backbone for NIS2 and DORA Evidence

The Monday morning compliance collision

At 08:12 on Monday, Maria, the CISO of a European payment processor, receives three messages that look unrelated.

The internal audit manager asks for evidence that the ISO 27001:2022 Statement of Applicability is current. The legal team forwards a banking partner’s questionnaire about DORA ICT third-party risk oversight. The operations director asks whether the same incident playbook can support NIS2 notification expectations for a newly acquired EU business unit.

By 09:00, the whiteboard in Maria’s office is covered in acronyms: ISO 27001, NIS2, DORA, GDPR, NIST, COBIT 2019. Her organization has controls. It has access management, backups, supplier questionnaires, encryption, incident response, policy approvals, management reviews, and training records. What it does not have is a single audit-ready evidence backbone that explains why those controls exist, which risks they treat, which regulations they support, who owns them, and where the proof lives.

That problem is becoming common across Europe. NIS2 pushes cybersecurity risk management, governance, incident handling, and supply chain resilience. DORA adds detailed ICT risk management, resilience testing, incident reporting, and ICT third-party oversight for financial entities. GDPR continues to require accountability, security of processing, processor governance, and personal data breach assessment.

The wrong response is to build three parallel compliance programs. That creates duplicated controls, inconsistent evidence, and exhausted teams.

The stronger response is to use ISO 27001:2022 as the control backbone. Not as a certificate on the wall, but as the operating system for risk, policy, supplier governance, incident response, compliance mapping, and audit evidence.

Clarysec’s practical model is simple: use the ISO 27001:2022 ISMS as the organizing system, use the Statement of Applicability as the bridge, use policies as enforceable operating rules, and use Zenith Controls: The Cross-Compliance Guide as the cross-compliance compass. Build once, map carefully, prove continuously.

Why ISO 27001:2022 works as the compliance backbone

NIS2 and DORA have different scopes, legal mechanisms, and supervisory models. NIS2 applies to essential and important entities across sectors. DORA applies to financial entities and creates detailed requirements for digital operational resilience. GDPR focuses on personal data processing and accountability.

Yet the operating questions behind these frameworks overlap:

• Is cybersecurity governed by management-approved policies?
• Are information security and ICT risks identified, assessed, and treated?
• Are controls selected based on risk, business context, and legal obligations?
• Are suppliers governed through due diligence, contracts, monitoring, and exit controls?
• Can personnel recognize and report security events early?
• Can incidents be triaged, escalated, investigated, and assessed for regulatory notification?
• Can the organization retrieve evidence quickly during an audit, customer review, or supervisory inquiry?

ISO 27001:2022 gives leadership a management system for answering those questions consistently. ISO/IEC 27007:2022 treats the Statement of Applicability as an auditable list of selected information security controls, including controls from ISO 27001:2022 Annex A, other standards, or organization-specific measures, with documented rationale for inclusion or exclusion. ISO/IEC 27006-1:2024 reinforces that the SoA and related ISMS documentation form a core evidence base for showing which controls are required, how responsibilities are assigned, and how policies are implemented and communicated.

That makes the SoA much more than a spreadsheet. It becomes the control contract between risk, compliance, operations, legal, procurement, audit, and the board.

Clarysec’s [P01] Information Security Policy anchors this governance requirement:

The organization shall implement and maintain an Information Security Management System (ISMS) in accordance with ISO/IEC 27001:2022 Clauses 4 through 10.

From section “Policy Implementation Requirements”, policy clause 6.1.1.

This matters because NIS2 and DORA evidence requests rarely arrive in ISO language. A regulator, customer, or board committee may ask for proof of cybersecurity risk management, ICT governance, third-party dependency oversight, incident escalation, or operational resilience testing. The ISO 27001:2022 ISMS gives those answers a structure.

The SoA is the bridge, not a paperwork exercise

In Zenith Blueprint: An Auditor’s 30-Step Roadmap, Risk Management phase, Step 13, Clarysec frames the SoA as the key traceability mechanism between risk treatment and implemented controls:

The SoA is effectively a bridging document : it links your risk assessment/treatment to the actual controls you have.

That sentence is the heart of cross-compliance. A control without traceability becomes a loose artifact. A control linked to a risk, legal obligation, policy, owner, evidence record, and test result becomes audit-ready.

Step 13 also recommends adding control references to risk scenarios, such as linking a customer database breach scenario to access control, cryptography, vulnerability management, incident response, and supplier controls. It also recommends noting when controls support external requirements such as GDPR, NIS2, or DORA.

Clarysec’s [P06] Risk Management Policy makes this operating rule explicit:

Control decisions resulting from the risk treatment process shall be reflected in the SoA.

From section “Policy Implementation Requirements”, policy clause 6.5.1.

For smaller organizations, Risk Management Policy - SME uses the same logic:

It ensures that risk management is an active component of planning, project execution, supplier selection, and incident response, in alignment with ISO 27001, ISO 31000, and applicable regulatory requirements.

From section “Purpose”, policy clause 1.2.

If a DORA third-party risk treatment, a NIS2 incident handling measure, or a GDPR processor security requirement is not reflected in the SoA or related compliance register, the organization may still be doing the work. But it will struggle to prove the work coherently.

A practical ISO 27001:2022 crosswalk for NIS2 and DORA

The following crosswalk is not legal advice. It is a practical evidence model for CISOs, compliance leaders, internal auditors, and business owners who need to align ISO 27001:2022 evidence with NIS2 and DORA expectations.

ENISA, working with the European Commission and the NIS Cooperation Group, has provided advisory cross-reference guidance that helps align EU cybersecurity requirements with international and national standards, including ISO 27001. That guidance is not legally binding and must be supplemented by national authority instructions, sector rules, and legal review. It does, however, support a defensible mapping approach.

The crosswalk works because it does not create duplicate controls for each regulation. It uses ISO 27001:2022 as the control backbone and adds regulatory tags, ownership, and evidence expectations.

Three ISO 27001:2022 controls that unlock the backbone

Several controls matter for NIS2 and DORA, but three ISO/IEC 27002:2022 controls frequently become the spine of the evidence model: 5.1, 5.19, and 5.24. A fourth control, 6.8, often determines whether incident reporting works in reality.

In Zenith Controls, ISO/IEC 27002:2022 control 5.1, Policies for information security, is characterized as a preventive control supporting confidentiality, integrity, and availability, with governance and policy management as core operational capabilities. The cross-mapping explains that GDPR Articles 5(2), 24, and 32 require accountability, responsibility, and security of processing. It also maps the same control to NIS2 cybersecurity risk management and governance expectations, and to DORA ICT governance and risk management framework requirements.

That is why the information security policy is not just another policy. A NIS2 assessor may read it as governance evidence. A DORA supervisor may read it as ICT risk framework evidence. A GDPR reviewer may read it as accountability evidence. An ISO 27001:2022 auditor may read it as part of the ISMS policy structure.

Control 5.19, Information security in supplier relationships, is where procurement, legal, security, privacy, and resilience meet. Zenith Controls maps it to GDPR processor obligations, NIS2 supply chain cybersecurity, and DORA ICT third-party risk management. For DORA, this evidence becomes even stronger when supported by controls 5.20, Addressing information security within supplier agreements, 5.21, Managing information security in the ICT supply chain, and 5.23, Information security for use of cloud services.

Control 5.24, Information security incident management planning and preparation, is the operational engine for incident readiness. Zenith Controls maps it to NIS2 incident handling and notification, GDPR personal data breach notification, and DORA ICT-related incident management and reporting. Its evidence is not only an incident response policy. It includes reporting channels, triage criteria, escalation records, legal notification assessments, tabletop exercises, incident tickets, and lessons learned.

Control 6.8, Information security event reporting, closes the gap between the written plan and human behavior. If personnel do not know how to report suspected phishing, data leakage, supplier outages, or suspicious system activity, the organization may lose critical time before legal or regulatory reporting assessments even begin.

One supplier incident, one coordinated evidence chain

Imagine a cloud analytics provider used by Maria’s payment processor detects unauthorized access to a support portal. The provider hosts pseudonymized customer usage data and supports a business-critical reporting workflow. The incident may affect personal data, regulated ICT resilience, and service availability.

A fragmented compliance program opens three separate workstreams: a GDPR breach assessment, a DORA ICT incident review, and an ISO 27001 supplier ticket. Each team asks for similar evidence in a different format. Procurement searches for the contract. Legal asks whether the provider is a processor. Security asks whether the incident meets reporting thresholds. Compliance starts a new spreadsheet.

A mature ISO 27001:2022 backbone opens one coordinated evidence chain.

First, the event is logged under the incident response process. The reporter uses a defined channel, the security team triages the event, and legal evaluates notification obligations. Clarysec’s [P30] Incident Response Policy requires regulated data incidents to be assessed by Legal and the DPO:

If an incident results in confirmed or likely exposure of personal data or other regulated data, Legal and the DPO must assess the applicability of:

From section “Policy Implementation Requirements”, policy clause 6.4.1.

For smaller organizations, Incident Response Policy-sme - SME assigns the same practical decision point:

Where customer data is involved, the General Manager must assess legal notification obligations based on the applicability of GDPR, NIS2, or DORA.

From section “Risk Treatment and Exceptions”, policy clause 7.4.1.

Second, the supplier relationship is reviewed. Was the provider classified as critical? Did the contract include breach notification obligations, audit rights, data protection responsibilities, service continuity expectations, and exit provisions? Clarysec’s Third party and supplier security policy sets that expectation:

Embed standardized security requirements into all supplier contracts, including breach notification obligations, audit rights, and data protection responsibilities.

From section “Objectives”, policy clause 3.2.

For SMEs, Third-Party and Supplier Security Policy-sme - SME makes the cross-compliance purpose explicit:

Support compliance with ISO/IEC 27001:2022, GDPR, NIS2, and DORA obligations related to supplier governance.

From section “Objectives”, policy clause 3.6.

Third, the risk register, treatment plan, and SoA are updated if the incident reveals a gap. Perhaps the supplier contract lacks a specific regulatory notification timeline. Perhaps supplier monitoring frequency is too low for a critical ICT provider. Perhaps the incident response plan does not clearly distinguish personal data breach criteria from ICT service disruption criteria.

The point is not to create a new compliance universe. The point is to update one integrated evidence chain so the same records can answer multiple audit questions.

Turning the SoA into a NIS2 and DORA evidence map

A standard SoA often answers ISO questions well: which controls are applicable, why they are selected, and whether they are implemented. To make it a practical NIS2 and DORA evidence map, enrich it with regulatory and operational evidence fields.

Open the SoA_Builder.xlsx from the Audit Ready Toolkit referenced in Zenith Blueprint, Audit, Review & Improvement phase, Step 24. Step 24 explains that auditors will often sample a control from the SoA and ask why it was implemented. The justification column and linked risk or requirement should answer that question.

Add these columns:

Now apply it to the core control set.

Then run a sample trace. Pick one supplier incident from the last year and follow it from incident ticket to supplier contract, from supplier classification to risk register, from risk treatment to SoA, and from SoA to management review.

If the chain breaks, that is not failure. It is a precise corrective action before an auditor, customer, regulator, or board committee finds the gap.

Centralized evidence is the overlooked accelerator

Many organizations have adequate controls but weak evidence retrieval. Proof is scattered across email, ticketing systems, SharePoint folders, contract repositories, HR platforms, GRC tools, and supplier portals. During audit season, the compliance team spends weeks chasing screenshots.

That is not audit readiness. It is audit recovery.

Clarysec’s [P33S] Audit and Compliance Monitoring Policy-sme - SME states:

All evidence must be stored in a centralized audit folder.

From section “Policy Implementation Requirements”, policy clause 6.2.1.

A centralized audit folder does not mean an uncontrolled dumping ground. It means a structured repository aligned to the ISMS, SoA, risk register, audit plan, and compliance register.

Clarysec’s Legal and Regulatory Compliance Policy - SME addresses the mapping problem directly:

Where a regulation applies across multiple areas (e.g., GDPR applies to retention, security and privacy), this must be clearly mapped in the Compliance Register and training materials.

From section “Governance Requirements”, policy clause 5.2.2.

This is exactly how ISO 27001:2022 becomes the control backbone for NIS2 and DORA. You do not rely on tribal knowledge. You map regulations across processes, policies, controls, evidence, and training.

Incident reporting starts with people, not portals

A common audit weakness appears when the incident response plan looks strong, but employees do not know when or how to report. This is dangerous for NIS2, DORA, and GDPR because regulatory assessment timelines depend on detection, escalation, and classification.

In Zenith Blueprint, Controls in Action phase, Step 16, Clarysec emphasizes personnel-driven incident reporting under ISO/IEC 27002:2022 control 6.8. The guidance states that incident response begins with people. Organizations should create a clear, simple, accessible reporting channel such as a monitored email address, internal portal, hotline, or ticketing category. It also recommends awareness training, a blame-free reporting culture, confidentiality, low-threshold reporting, and periodic simulations.

The cross-compliance impact is direct. Zenith Blueprint links this personnel reporting capability to GDPR Article 33, NIS2 Article 23, and DORA Article 17. If employees hesitate to report suspicious activity, the organization may lose critical time before legal, security, or regulatory teams can assess notification duties.

A practical control test is simple:

1. Ask five employees how to report a suspected phishing email.
2. Check whether the reporting channel is monitored.
3. Confirm whether the ticketing system has a security incident category.
4. Review the last simulation or tabletop exercise.
5. Verify that lessons learned were reviewed in management review.

If any answer is unclear, update the incident instruction sheet, training material, reporting channel, and SoA evidence reference.

How different auditors inspect the same backbone

Cross-compliance evidence must survive different audit lenses. The same control may be tested differently depending on the reviewer’s mandate.

This is where Zenith Controls adds value beyond a simple mapping table. It helps translate ISO/IEC 27002:2022 controls into audit-relevant perspectives, including control attributes, regulatory relationships, and evidence expectations. For control 5.1, the attributes support governance, policy management, accountability, and security objectives. For control 5.24, the attributes support respond and recover concepts, incident readiness, and corrective action. For control 5.19, the supplier relationship attributes connect governance, ecosystem risk, protection, and third-party oversight.

What the board should see

The board does not need every SoA line item. It does need the story the SoA tells.

A strong board pack for ISO 27001:2022, NIS2, and DORA alignment should include:

• ISMS scope and covered business services.
• Top information security and ICT risks.
• Summary of applicable controls by domain.
• NIS2, DORA, and GDPR mapping status.
• Critical suppliers and concentration risks.
• Incident reporting metrics and tabletop outcomes.
• Open corrective actions and overdue risk treatments.
• Decisions needed on risk acceptance, budget, ownership, and resources.

This turns compliance into governance evidence. It also aligns with the purpose of control 5.1 in Zenith Controls, where policies for information security support executive-level direction, accountability, and security objectives.

Common mistakes to avoid

The first mistake is assuming ISO 27001:2022 certification automatically proves NIS2 or DORA compliance. It does not. ISO 27001:2022 gives you a strong management system and control backbone, but you still need regulatory scoping, legal analysis, sector-specific interpretation, notification workflows, and awareness of national authority expectations.

The second mistake is treating the SoA as static. The SoA must evolve when new suppliers, systems, incidents, regulations, services, or risks emerge. Zenith Blueprint, Step 24, recommends cross-verifying the SoA against the risk register and treatment plan, ensuring every selected control has a rationale based on mapped risk, legal requirement, or business need.

The third mistake is mapping too high. A slide that says “ISO 27001 maps to DORA” is not audit evidence. A specific SoA entry that links supplier relationship security to a critical ICT supplier risk, contract clause, supplier review record, and DORA third-party oversight expectation is much stronger.

The fourth mistake is failing to centralize evidence. If the compliance manager spends two weeks collecting screenshots before every audit, the organization has a retrieval problem.

The fifth mistake is ignoring people controls. Incident reporting, supplier onboarding, access reviews, policy acceptance, and escalation all depend on human behavior. A polished process that nobody follows will collapse under audit sampling.

Clarysec’s operating model for cross-compliance

Clarysec’s method connects the compliance story from strategy to evidence:

• In Zenith Blueprint, Risk Management phase, Step 13, you map controls to risks and build the SoA as the bridging document.
• In Zenith Blueprint, Risk Management phase, Step 14, you cross-reference GDPR, NIS2, and DORA requirements to policies and controls.
• In Zenith Blueprint, Controls in Action phase, Step 16, you operationalize people-driven incident reporting so escalation begins early.
• In Zenith Blueprint, Audit, Review & Improvement phase, Step 24, you finalize and test the SoA, cross-verify it against the risk treatment plan, and prepare it as one of the first documents an auditor will request.

That method is supported by Clarysec policies that turn principles into operating rules: information security governance, risk treatment, supplier security, incident response, legal and regulatory mapping, and evidence storage.

The result is not just ISO 27001:2022 readiness. It is a reusable compliance evidence system for NIS2, DORA, GDPR, customer assurance, internal audit, and board oversight.

Next steps: build once, prove many times

If your organization is facing NIS2, DORA, GDPR, customer audits, or ISO 27001:2022 certification pressure, start with the backbone.

1. Review your SoA and add regulatory driver columns for NIS2, DORA, and GDPR.
2. Cross-check the SoA against your risk register and risk treatment plan.
3. Map critical suppliers to supplier security controls, contract clauses, and monitoring evidence.
4. Test your incident reporting workflow with a tabletop exercise.
5. Centralize audit evidence by control, regulation, owner, and test status.
6. Use Zenith Controls to translate ISO/IEC 27002:2022 controls into cross-compliance evidence.
7. Use Zenith Blueprint to move from risk treatment to audit-ready SoA validation.
8. Deploy Clarysec’s policy set, including the Information Security Policy, Risk Management Policy, Third party and supplier security policy, and Incident Response Policy, to accelerate implementation.

The fastest path is not more disconnected checklists. It is one integrated ISMS, one traceable SoA, one centralized evidence model, and one cross-compliance operating rhythm.

Clarysec can help you turn ISO 27001:2022 from a certification project into a practical control backbone for NIS2 and DORA. Download Zenith Blueprint, explore Zenith Controls, or book a Clarysec assessment to build an audit-ready evidence model before the next regulator, customer, or board committee asks for proof.