NIS2 Evidence Mapping with ISO 27001:2022 for 2026

The 2026 NIS2 problem is not awareness, it is proof

It is Monday morning, 08:35. Maria, the recently appointed CISO of a fast-growing B2B cloud and managed services provider, joins the quarterly board risk meeting with a thick NIS2 gap assessment open on her laptop. The first slide looks reassuring. Policies exist. A risk assessment exists. Incident response is documented. Suppliers are listed. Vulnerability scans run every month.

Then the chair asks the question that changes the meeting:

“Can we prove these measures operated last quarter, and can we show which ISO 27001:2022 controls, owners and records support each NIS2 obligation?”

The room goes quiet.

Legal knows the company falls within the NIS2 universe because it provides managed ICT and cloud services to EU customers. Compliance knows Article 21 requires technical, operational and organisational cybersecurity risk-management measures. Operations knows the team patches systems, reviews suppliers and monitors logs. But the evidence is scattered across ticketing systems, SIEM exports, policy folders, spreadsheets, cloud consoles, supplier portals and meeting notes.

No one can quickly show a defensible chain from NIS2 Article 21 to ISO 27001:2022 scope, risk, control, policy, owner, procedure, operating record and audit finding.

That is the real 2026 challenge.

Many organizations are no longer asking, “Are we in NIS2 scope?” They are asking a harder question: “Can we prove our NIS2 technical measures actually work?” The answer cannot be a one-time mapping spreadsheet. It must be a living operating model inside the Information Security Management System, where legal obligations are translated into risks, policies, controls, owners, evidence and continual improvement.

Clarysec’s model uses ISO/IEC 27001:2022 as the management system spine, NIS2 Article 21 as the regulatory obligation set, policy clauses as the operational rulebook, Zenith Blueprint: An Auditor’s 30-Step Roadmap as the implementation path, and Zenith Controls: The Cross-Compliance Guide as the cross-compliance map for ISO 27001:2022, NIS2, DORA, GDPR, NIST CSF and COBIT-style assurance.

Start with scope, because NIS2 evidence begins before controls

A common NIS2 failure is jumping directly into MFA, logging, incident response and vulnerability management before confirming entity scope, service scope and jurisdictional scope.

NIS2 applies to covered public and private entities in regulated sectors that meet size and activity criteria, with certain entity types covered regardless of size. Relevant digital and ICT categories include cloud computing service providers, data centre service providers, content delivery network providers, trust service providers, public electronic communications providers, managed service providers, managed security service providers, online marketplaces, online search engines and social networking platforms.

For cloud providers, SaaS platforms, MSPs, MSSPs and digital infrastructure providers, this scoping work is not theoretical. Article 3 requires Member States to distinguish essential and important entities. Article 27 requires ENISA to maintain a registry for several digital and ICT providers, including DNS service providers, TLD name registries, domain name registration service providers, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines and social networking platforms.

ISO 27001:2022 gives the right structure. Clauses 4.1 to 4.4 require the organization to understand external and internal issues, interested parties, requirements, interfaces and dependencies, then define the ISMS scope. NIS2 must be captured here, not left in a legal memo.

A practical NIS2 scoping record should include:

• Legal entity and EU establishment analysis
• NIS2 sector and service category
• Essential or important entity status, where confirmed by national law or authority designation
• ENISA registry relevance, where applicable
• Critical services delivered to customers
• Network and information systems supporting those services
• Dependencies on cloud, data centre, telecom, security monitoring, identity and software providers
• Links to DORA, GDPR, customer contracts and sector-specific obligations
• Evidence repositories, system owners and review cadence

This is also where DORA must be separated correctly. NIS2 recognizes that where a sector-specific EU legal act imposes equivalent cybersecurity risk-management or incident-notification obligations, that sector-specific regime applies instead of the corresponding NIS2 provisions. For covered financial entities, DORA is generally the operative cybersecurity and ICT incident-reporting regime. DORA applies from 17 January 2025 and covers ICT risk management, incident reporting, digital operational resilience testing, ICT third-party risk and oversight of critical ICT third-party providers.

A fintech group may therefore have different compliance treatments across one corporate structure. The payment entity may be primarily under DORA. The MSP subsidiary may be directly under NIS2. A shared cloud platform may support both. The mature answer is not duplicate controls. It is one ISMS evidence model that can serve multiple regulatory lenses.

ISO 27001:2022 as the NIS2 compliance operating system

NIS2 Article 21 requires appropriate and proportionate technical, operational and organisational measures to manage risks to network and information systems and to prevent or minimize incident impact on service recipients and other services.

ISO 27001:2022 is well suited to operationalize that requirement because it forces three disciplines.

First, governance. Clauses 5.1 to 5.3 require top management commitment, alignment with strategic direction, resourcing, communication, assignment of responsibilities and a documented information security policy. This aligns directly with NIS2 Article 20, which requires management bodies to approve cybersecurity risk-management measures, oversee implementation and receive training.

Second, risk treatment. Clauses 6.1.1 to 6.1.3 require a repeatable risk assessment process, risk owners, risk evaluation, treatment options, control selection, a Statement of Applicability, a risk treatment plan and approval of residual risk.

Third, operational control. Clause 8.1 requires the organization to plan, implement and control ISMS processes, maintain documented information, control changes and manage externally provided processes, products and services relevant to the ISMS.

This turns NIS2 from a legal checklist into a control operating model.

Every row needs an owner, a record source and a sampling method. If those are missing, the organization has a control aspiration, not a control.

Policy is where NIS2 becomes operational behaviour

Policies are often treated as templates. For NIS2, that is dangerous. A regulator or auditor will not be convinced by a policy folder if the policies do not assign ownership, define records, link to risks and produce evidence.

The enterprise Legal and Regulatory Compliance Policy sets the foundation in clause 6.2.1:

All legal and regulatory obligations must be mapped to specific policies, controls, and owners within the Information Security Management System (ISMS).

That clause is the bridge between NIS2 and ISO 27001:2022. NIS2 Article 21 is not simply listed as an external requirement. It is decomposed into policy obligations, mapped to controls, assigned to owners and tested through evidence.

For smaller organizations, the SME Legal and Regulatory Compliance Policy keeps the same concept lightweight. Clause 5.1.1 requires:

The GM must maintain a simple, structured Compliance Register listing:

The sentence is deliberately practical. SMEs do not need a complex GRC implementation to begin. They need a compliance register that captures obligation, applicability, owner, policy, evidence and review cadence.

Risk treatment then converts the obligation into action. The enterprise Risk Management Policy, clause 6.4.2 states:

The Risk Officer shall ensure that treatments are realistic, time-bound, and mapped to ISO/IEC 27001 Annex A controls.

For SMEs, the Risk Management Policy - SME, clause 5.1.2 gives the minimum viable risk record:

Each risk entry must include: description, likelihood, impact, score, owner, and treatment plan.

These clauses matter because NIS2 is explicitly risk-based and proportionate. Article 21 expects measures to reflect the state of the art, relevant standards, implementation cost, risk exposure, size, incident likelihood and severity, including societal and economic impact. A risk register without owners and treatment plans cannot prove proportionality.

The enterprise Information Security Policy completes the evidence principle in clause 6.6.1:

All implemented controls shall be auditable, supported by documented procedures and retained evidence of operation.

That is the difference between having a NIS2 programme and having a NIS2 evidence programme.

The Clarysec route from mapping to operation

The Zenith Blueprint is valuable because it mirrors how auditors think. They do not only ask whether a control exists. They ask why it was selected, where it is documented, how it operates, who owns it, what evidence proves it and how the organization improves it.

In the Risk Management phase, Step 13 tells teams to add traceability between risks, controls and clauses:

✓ Map controls to risks: In your Risk Register’s treatment plan, you listed certain controls for each risk. You can add a column “Annex A Control Reference” to each risk and list the control numbers.

For NIS2, this means the risk register and Statement of Applicability should show why controls such as 8.8 Management of technical vulnerabilities, 5.19 Information security in supplier relationships and 5.24 Incident management planning and preparation are applicable.

Step 14 of the Zenith Blueprint makes the regulatory mapping explicit:

For each regulation, if applicable, you may create a simple mapping table (could be an appendix in a report) that lists the regulation’s key security requirements and the corresponding controls/policies in your ISMS.

This prevents fragmentation. GDPR personal data security, NIS2 incident reporting, DORA ICT resilience testing and customer security commitments may all rely on the same evidence: access reviews, vulnerability remediation, logging records, backup tests, supplier reviews and incident reports.

Step 19 moves from design to operation:

Tie each of these documents to the appropriate control in your SoA or ISMS manual. These will serve as proof of implementation and internal reference.

The Step 19 documentation set includes endpoint security, access management, authentication, secure configuration baselines, logging and monitoring, patch management, vulnerability management, capacity planning and IT operations reporting. These are exactly the operational documents needed to make NIS2 technical measures auditable.

Step 26 explains how audit evidence should be gathered:

As you gather evidence, record your findings. Note where things conform to the requirement (positive findings) and where they do not (potential nonconformities or observations).

For NIS2, this means sampling evidence before a regulator, customer assessor or certification auditor asks for it.

The cross-compliance role of Zenith Controls

Zenith Controls is not a separate control framework. It is Clarysec’s cross-compliance guide for mapping ISO/IEC 27001:2022 and ISO/IEC 27002:2022 controls to related controls, audit expectations and external frameworks. It helps teams understand how one ISO 27001:2022 control can support NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-style assurance.

Three ISO 27001:2022 controls are especially important for NIS2 evidence mapping.

Control 5.1 Policies for information security is the entry point because NIS2 Article 21 includes risk analysis and information system security policies. If a NIS2 technical measure is not reflected in policy, it is difficult to govern and hard to audit consistently.

Control 5.36 Compliance with policies, rules and standards for information security is the reality check. It connects policy requirements to actual conformity with internal rules, standards and external obligations. In NIS2 terms, this is where an organization asks whether it is doing what its Article 21 mapping says it does.

Control 8.8 Management of technical vulnerabilities is one of the hardest 2026 test areas. Vulnerability management is directly relevant to secure acquisition, development, maintenance, vulnerability handling and disclosure. It also supports DORA testing and remediation, GDPR security accountability, NIST CSF Identify and Protect outcomes, and ISO 27001 audit sampling.

Supporting standards can sharpen the design without requiring additional certifications. ISO/IEC 27002:2022 provides implementation guidance for Annex A controls. ISO/IEC 27005 supports information security risk management. ISO/IEC 27017 supports cloud security. ISO/IEC 27018 supports protection of personally identifiable information in public cloud processor scenarios. ISO 22301 supports business continuity. ISO/IEC 27035 supports incident management. ISO/IEC 27036 supports supplier relationship security.

The objective is not more standards for their own sake. The objective is better evidence design.

Hands-on example: build a NIS2 vulnerability evidence pack

Consider Maria’s SaaS platform. It serves EU manufacturing customers and depends on cloud services, open-source components, CI/CD pipelines and managed monitoring. Her gap report says “vulnerability management implemented,” but evidence is scattered across scanners, Jira, GitHub, cloud configuration tools and change tickets.

A NIS2-ready evidence pack can be built in one focused sprint.

Step 1: Define the risk scenario

Risk: an exploitable vulnerability in an internet-facing application, dependency or cloud component causes service disruption, unauthorized access or customer data exposure.

The risk register should include description, likelihood, impact, score, owner and treatment plan. The treatment plan should reference ISO 27001:2022 control 8.8 Management of technical vulnerabilities, plus related controls for asset inventory, secure development, logging, access control, supplier management and incident response.

Step 2: Map the risk to NIS2 Article 21

The risk supports Article 21 requirements for secure acquisition, development and maintenance, vulnerability handling and disclosure, risk analysis, incident handling, supply chain security and control effectiveness assessment.

Step 3: Anchor the operating rules in policy

Use a vulnerability management procedure, secure development standard, patch management requirements, security testing policy and audit evidence rules.

The enterprise Security Testing and Red-Teaming Policy, clause 6.1 states:

Types of Tests: The security testing programme shall include, at a minimum: (a) vulnerability scanning, consisting of automated weekly or monthly scans of networks and applications to identify known vulnerabilities; (b) penetration testing, consisting of manual in-depth testing of specific systems or applications by skilled testers to identify complex weaknesses; and (c) red-teaming exercises, consisting of scenario-based simulations of real attacks, including social engineering and other tactics, to test the organisation’s detection and response capabilities as a whole.

That clause creates a defensible testing baseline. It also aligns with DORA’s expectation for recurring, risk-based digital operational resilience testing for covered financial entities.

Step 4: Define evidence metadata

The Audit and Compliance Monitoring Policy - SME, clause 6.2.3 states:

Metadata (e.g., who collected it, when, and from which system) must be documented.

For vulnerability evidence, the pack should capture:

• Scanner name and configuration
• Scan date and time
• Asset scope and exclusions
• Critical and high findings
• Ticket number and owner
• Patch or mitigation decision
• Risk acceptance decision, where applicable
• Remediation date
• Validation scan
• Change record link
• Exception owner and expiry date

Step 5: Add logging evidence

The Logging and Monitoring Policy - SME, clause 5.4.4 includes system logs such as:

System logs: Configuration changes, administrative actions, software installations, patching activity

A patch ticket alone may not prove the change occurred. Configuration logs, administrative actions and software installation records strengthen the evidence chain.

Step 6: Run a sample audit

Select five critical or high vulnerabilities from the previous quarter. For each item, verify that the asset was in inventory, the scanner detected the finding, a ticket was opened within SLA, an owner was assigned, remediation matched severity and exploitability, logs show the change, validation confirms closure and any exception has risk-owner approval with an expiry date.

That sprint produces a NIS2-ready vulnerability evidence pack and an ISO 27001:2022 internal audit sample.

Supplier security is ecosystem governance

NIS2 Article 21 requires supply chain security, including security aspects concerning relationships with direct suppliers and service providers. It also expects organizations to consider supplier vulnerabilities, product quality, supplier cybersecurity practices and secure development practices.

This is where the first version of Maria’s gap report was weakest. It listed suppliers, but it did not prove due diligence, contract security clauses, monitoring or exit readiness.

The Third-party and Supplier Security Policy provides the policy anchor. Related implementation can be supported by the Secure Development Policy, Information Security Awareness and Training Policy, Vulnerability and Patch Management Policy, Cryptographic Controls Policy, Access Control Policy and Remote Access Policy.

A single supplier evidence register can support NIS2, DORA and ISO 27001:2022.

This table prevents duplicate questionnaires, duplicate registers and contradictory control ownership.

One incident workflow for NIS2, DORA and GDPR

NIS2 Article 23 requires significant incidents to be notified without undue delay. It establishes a staged timeline: early warning within 24 hours of awareness, incident notification within 72 hours with initial severity or impact assessment and available indicators of compromise, intermediate updates if requested, and a final report no later than one month after the incident notification.

DORA has a similar lifecycle for financial entities: detection, classification, logging, severity assessment, escalation, client communication, authority reporting, root-cause analysis and remediation. GDPR adds personal data breach analysis, including controller and processor roles, impact on data subjects and the 72-hour notification timeline where applicable.

The correct design is not three incident processes. It is one incident workflow with regulatory decision branches.

The Incident Response Policy - SME, clause 5.4.1 states:

All incident investigations, findings, and corrective actions must be recorded in an incident register maintained by the General Manager.

A strong incident register should include:

The GDPR link should not be underestimated. NIS2 competent authorities may inform GDPR supervisory authorities where cybersecurity risk-management or reporting failures can entail a personal data breach. The ISMS should therefore make privacy assessment part of incident triage, not an afterthought.

How auditors and regulators will test your NIS2 evidence

A 2026-ready organization should expect the same control to be tested through different lenses.

An ISO 27001:2022 auditor will start with the ISMS. They will ask whether NIS2 obligations are identified as interested-party requirements, whether the ISMS scope covers relevant services and dependencies, whether risks are assessed and treated, whether the Statement of Applicability justifies applicable controls and whether records prove operation.

A NIS2 competent authority will focus on legal outcomes. It may ask whether all Article 21 measures are addressed, whether controls are appropriate and proportionate, whether management approved and oversees the measures, and whether incident reporting can meet the required timelines.

A DORA supervisor, for covered financial entities, will test ICT risk management, incident classification, resilience testing, third-party risk, contractual arrangements, concentration risk and exit strategies.

A GDPR reviewer will test whether technical and organisational measures protect personal data, whether breach assessment is embedded in incident handling, whether controller and processor roles are clear, and whether accountability records exist.

A NIST CSF 2.0 or COBIT 2019-style assessor will focus on governance, risk ownership, performance metrics, current and target outcomes, process capability and alignment with enterprise risk appetite.

The enterprise Audit and Compliance Monitoring Policy, clause 3.4 captures the evidence purpose:

To generate defensible evidence and an audit trail in support of regulatory inquiries, legal proceedings, or customer assurance requests.

That is the operational standard NIS2 teams should build toward.

Management accountability: the board cannot delegate NIS2 away

NIS2 Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation and receive training. Members of management bodies can be held liable for infringements, subject to national liability rules.

This aligns with ISO 27001:2022 leadership requirements. Top management must ensure the information security policy and objectives align with strategic direction, integrate ISMS requirements into business processes, provide resources, communicate importance, assign responsibilities and promote continual improvement.

A board does not need raw scanner exports or full SIEM logs. It needs decision-grade assurance.

A quarterly NIS2 board evidence pack should include:

1. Scope and regulatory status changes
2. Top NIS2 risks and treatment status
3. Article 21 control effectiveness dashboard
4. Significant incidents, near misses and reporting decisions
5. Supplier and cloud risk exceptions
6. Internal audit findings, corrective actions and overdue evidence

This pack gives management the information needed to approve measures, challenge exceptions and accept residual risk.

The 2026 Clarysec operating model

Operationalizing NIS2 technical measures with ISO 27001:2022 requires a simple but disciplined model:

• Scope NIS2, DORA, GDPR and contractual obligations inside the ISMS
• Map obligations to risks, policies, controls, owners and evidence
• Use the Statement of Applicability as the control truth source
• Build evidence packs for high-risk Article 21 areas
• Integrate incident reporting into one regulatory workflow
• Treat supplier security as a lifecycle, not a questionnaire
• Run internal audits using real samples
• Report control effectiveness to management bodies
• Improve based on incidents, audit findings, tests and regulatory changes

For Maria, the turning point was realizing that she did not need a separate NIS2 project. She needed a stronger ISMS evidence engine.

Clarysec’s policies, Zenith Blueprint and Zenith Controls are designed to work together. Policies define expected behaviour and records. The Zenith Blueprint gives the 30-step implementation and audit route. Zenith Controls provides the cross-compliance mapping so NIS2, ISO 27001:2022, DORA, GDPR, NIST CSF and COBIT-style assurance can be managed as one coherent programme.

Next step: build your NIS2-to-ISO 27001:2022 evidence map

If your NIS2 work still lives in a gap spreadsheet, 2026 is the year to operationalize it.

Start with one high-risk technical measure, such as vulnerability management, incident handling or supplier security. Map it to ISO 27001:2022 risks, policies, Annex A controls, owners, procedures and evidence. Then sample last quarter’s records and ask a hard question: would this satisfy a regulator, a customer assessor and an ISO 27001:2022 auditor?

Clarysec can help you build that answer using the policy library, Zenith Blueprint and Zenith Controls.

The goal is not more documentation. The goal is defensible, repeatable evidence that your NIS2 technical measures actually work.