NIS2 Registration Evidence in ISO 27001:2022

The email landed in Anna’s inbox with a quiet thud that felt more like a siren. As CISO of CloudFlow, a fast-growing B2B SaaS provider serving customers across the EU, she was used to security questionnaires, procurement audits, and ISO 27001 surveillance visits. This message was different.

The subject line read: “Information Request Regarding National Implementation of Directive (EU) 2022/2555 (NIS2).” The national cybersecurity authority wanted CloudFlow to confirm its classification, prepare entity registration information, identify the services in scope, and be ready to demonstrate cybersecurity risk-management measures.

Anna had an ISO 27001:2022 certificate framed on the wall. Sales used it in enterprise deals. The board had approved the information security policy. Internal audit had recently closed two findings. But the question in front of her was sharper than certification status.

Could CloudFlow prove, quickly and defensibly, that its ISO 27001:2022 ISMS covered NIS2 obligations?

That is where many organizations make the wrong move. They treat NIS2 entity registration as an administrative filing, like updating a business registry or tax portal. It is not. Registration is the doorway into supervisory visibility. After that doorway, the competent authority may ask for scope rationale, board approval records, incident reporting procedures, supplier risk evidence, contact points, control effectiveness metrics, and proof that the organization knows which services are critical.

For SaaS, cloud, managed service, managed security, data centre, digital infrastructure, and certain financial-sector providers, the real question is no longer “Do we have a security policy?” It is “Can we show an evidence chain from legal obligation to ISMS scope, risk treatment, control operation, and management oversight?”

The strongest NIS2 enforcement readiness program is not a parallel spreadsheet. It is a traceable evidence model inside ISO 27001:2022.

NIS2 registration is really an evidence problem

NIS2 applies broadly to public or private entities in sectors listed in Annex I and Annex II that meet or exceed the relevant medium-sized enterprise threshold. It also captures certain entities regardless of size, including providers of public electronic communications networks or services, trust service providers, TLD registries, DNS service providers, sole providers of essential services, and entities whose disruption could affect public safety, health, systemic risk, or national or regional criticality.

For technology companies, the digital categories are especially important. Annex I includes digital infrastructure, such as cloud computing service providers, data centre service providers, content delivery network providers, trust service providers, DNS service providers, and providers of public electronic communications networks or services. Annex I also includes ICT service management for business-to-business services, including managed service providers and managed security service providers. Annex II includes digital providers such as online marketplaces, online search engines, and social networking services platforms.

That means an organization can move into NIS2 scope without thinking of itself as “critical infrastructure.” A B2B SaaS company with managed security functionality, a cloud platform supporting regulated customers, or a fintech-adjacent provider can suddenly need a registration file, a competent-authority contact model, and a defensible control story.

NIS2 also distinguishes essential and important entities. Essential entities generally face a more proactive supervisory model, while important entities are usually supervised after evidence of non-compliance or incidents. The distinction matters, but it does not remove the need for preparation. Both categories need governance, risk management, incident reporting, supplier security, and evidence.

Financial entities must also consider DORA. NIS2 Article 4 recognizes that where a sector-specific Union legal act imposes at least equivalent cybersecurity risk-management and incident reporting obligations, those sector-specific rules apply to the corresponding areas. DORA applies from 17 January 2025 and establishes ICT risk management, major ICT-related incident reporting, digital operational resilience testing, information sharing, ICT third-party risk management, contractual controls, and oversight of critical ICT third-party providers. For covered financial entities, DORA is the primary cyber resilience framework for overlapping requirements, but NIS2 interfaces and national authority coordination can still matter.

The lesson is simple. Do not wait for the portal field or regulator email before building evidence. Every registration answer implies a future audit question.

Start with ISMS scope, not the portal form

ISO 27001:2022 is useful because it forces the organization to define context, interested parties, regulatory obligations, scope, risks, treatment plans, control operation, monitoring, internal audit, management review, and improvement.

Clauses 4.1 to 4.4 require the organization to determine internal and external issues, identify interested parties and their requirements, decide which requirements are addressed through the ISMS, define the ISMS scope by considering interfaces and dependencies, document that scope, and operate the ISMS processes.

For NIS2, that scope should answer practical questions:

• Which EU services, legal entities, subsidiaries, platforms, infrastructure components, and business units are relevant?
• Which Annex I or Annex II category may apply?
• Is the organization essential, important, DORA-covered, outside scope, or pending national classification?
• Which services are critical to customers, public safety, financial stability, healthcare, digital infrastructure, or other regulated sectors?
• Which cloud providers, MSPs, MSSPs, data centres, subcontractors, and other suppliers support those services?
• Which Member States, competent authorities, CSIRTs, DPAs, and financial supervisors may be relevant?

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint places this work early, in Step 2, Stakeholder Needs and ISMS Scope. It instructs organizations to identify regulators and authorities, review legal and regulatory requirements, review contracts and agreements, conduct stakeholder interviews, and consider expected industry standards.

Action Item 4.2: Compile a list of all significant interested parties and note their requirements related to information security. Be thorough – think of anyone who would complain or face consequences if your security failed or if you lacked a certain control. This list will guide what you must comply with or satisfy through your ISMS and will feed into risk assessment and control selection.

That is the right starting point for NIS2 registration. Before filing, create a short NIS2 scope memo that connects the business model to Annex I or Annex II categories, documents size and service assumptions, records national-law interpretation, identifies competent authorities, and states whether DORA, GDPR, customer contracts, or sector rules also apply.

Clarysec’s SME Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy - SME defines the purpose clearly:

“This policy defines the organization’s approach to identifying, meeting and demonstrating compliance with legal, regulatory and contractual obligations.”

For larger programs, Clarysec’s Legal and Regulatory Compliance Policy Legal and Regulatory Compliance Policy is even more explicit:

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

That sentence is the foundation of enforcement readiness. If a regulator asks how NIS2 obligations were identified, the answer should not be “legal advised us.” The answer should be a documented register, linked to scope, risks, control owners, procedures, retained evidence, and management review.

Build the NIS2 evidence chain inside ISO 27001:2022

NIS2 Article 21 requires essential and important entities to implement appropriate and proportionate technical, operational, and organizational measures to manage risks to network and information systems used for operations or service delivery. Measures must account for the state of the art, relevant European and international standards where applicable, cost, risk exposure, size, likelihood and severity of incidents, and societal and economic impact.

Article 21(2) lists minimum areas, including risk analysis and information system security policies, incident handling, business continuity, backups, disaster recovery, crisis management, supply chain security, secure acquisition and development, vulnerability handling, effectiveness assessment, cyber hygiene, training, cryptography, human resources security, access control, asset management, multi-factor or continuous authentication, and secure communications where appropriate.

ISO 27001:2022 maps naturally to that structure. Clauses 6.1.1 to 6.1.3 require risk assessment and risk treatment, including risk acceptance criteria, risk owners, likelihood and consequence analysis, a risk treatment plan, comparison with Annex A controls, and a Statement of Applicability. Clause 8 requires operational planning and control, evidence that processes operated as planned, change control, control over externally provided processes, recurring risk assessments, and documented treatment results. Clause 9.1 requires monitoring, measurement, analysis, and evaluation. Clause 9.2 requires internal audit. Clause 10.2 requires action on nonconformities and corrective action.

Clarysec’s Risk Management Policy Risk Management Policy - SME turns this into an operating rule:

“All identified risks must be recorded in the Risk Register.”

The enterprise Risk Management Policy Risk Management Policy connects risk treatment to ISO 27001:2022 control selection:

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

This matters because NIS2 evidence should be traceable. If an authority asks why a control exists, point to the obligation, risk, treatment decision, control owner, SoA entry, procedure, and evidence. If the authority asks why a control was not selected, point to the SoA justification, approved risk acceptance, and management review.

The best evidence chain is boring in the best possible way. Every obligation has an owner. Every owner has a control. Every control has evidence. Every exception has approval. Every audit finding has corrective action.

Put Article 20 governance into board evidence

NIS2 Article 20 moves cybersecurity into the boardroom. Management bodies must approve cybersecurity risk-management measures adopted for Article 21, oversee implementation, and may be held liable for infringements. Management body members must follow training, and entities are encouraged to provide regular cybersecurity training to employees.

A board cannot simply delegate NIS2 to IT. Evidence should show that management understood the NIS2 scope analysis, approved the risk management approach, reviewed material risks, allocated resources, tracked implementation, reviewed incidents and exercises, and received training.

ISO 27001:2022 clauses 5.1 to 5.3 support that governance model by requiring top management commitment, alignment of information security objectives with business strategy, integration of ISMS requirements into business processes, resources, communication, accountability, and reporting of ISMS performance to top management.

Clarysec’s Governance Roles and Responsibilities Policy Governance Roles and Responsibilities Policy defines the security liaison role as one that:

“Serves as the primary liaison with auditors, regulators, and senior leadership on information security matters.”

That role should be named in the NIS2 registration evidence pack. It should not be implied. Authorities, auditors, and customers want to know who coordinates regulatory contact, who owns incident reporting, who maintains the legal register, who updates authority contacts, and who reports to the board.

A practical governance evidence set includes:

• Board approval of the cybersecurity risk-management framework.
• Management review minutes covering NIS2 scope, risks, incidents, suppliers, and readiness.
• Training records for management body members and employees.
• A RACI matrix for NIS2 obligations, ISO 27001:2022 controls, incident reporting, supplier assurance, and regulatory communication.
• Evidence that NIS2 obligations are included in internal audit and compliance monitoring.
• Corrective action tracking for gaps, overdue risks, exceptions, and failed tests.

Articles 32 and 33 also make evidence quality important by identifying serious infringement factors such as repeated violations, failure to notify or remedy significant incidents, failure to address deficiencies after binding instructions, obstruction of audits or monitoring, and false or grossly inaccurate information. Weak evidence can become an enforcement problem even when technical controls exist.

Prepare authority contact and incident reporting evidence before 02:00

The most painful incident reporting failures often begin with a basic question: “Who do we notify?” During ransomware, DNS failure, cloud compromise, or data exposure, teams lose time searching for the correct CSIRT, competent authority, DPA, financial supervisor, law enforcement channel, customer template, and internal approver.

NIS2 Article 23 requires notification without undue delay of significant incidents affecting service provision. A significant incident is one that has caused or could cause severe operational disruption or financial loss, or has affected or could affect others by causing considerable material or non-material damage. The timeline is staged: early warning within 24 hours of becoming aware, incident notification within 72 hours, intermediate updates upon request, and a final report within one month after the 72-hour notification or after the incident is handled for ongoing incidents. Where appropriate, service recipients must also be informed of significant incidents or significant cyber threats and protective measures.

Zenith Blueprint, Controls in Action phase, Step 22, treats contact with authorities as preparedness, not panic:

The principle here is simple: if your organization were targeted by a cyberattack, involved in a data breach, or under investigation , who would make the call to the authorities? How would they know what to say? Under what conditions would such contact be initiated? These questions must be answered in advance , not after the fact.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls covers ISO/IEC 27002:2022 control 5.5, Contact with authorities. It classifies the control as preventive and corrective, tied to confidentiality, integrity, and availability, and connected to Identify, Protect, Respond, and Recover concepts. It also links control 5.5 to ISO/IEC 27002:2022 controls 5.24 Information security incident management planning and preparation, 6.8 Information security event reporting, 5.7 Threat intelligence, 5.6 Contact with special interest groups, and 5.26 Response to information security incidents.

From a cross-compliance perspective, Zenith Controls maps contact with authorities to NIS2 Article 23, GDPR breach notification, DORA incident reporting, NIST SP 800-53 IR-6 Incident Reporting, and COBIT 2019 external escalation practices. One authority contact register can serve multiple obligations if it is properly designed.

Clarysec’s Incident Response Policy Incident Response Policy - SME makes legal triage explicit:

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

A strong authority contact evidence pack should include:

• Competent authority and CSIRT contact details by Member State and service.
• DPA contacts for GDPR personal data breach notification.
• Financial supervisory contacts if DORA applies.
• Law enforcement and cybercrime contact routes.
• Authorized internal communicators and alternates.
• Incident thresholds for NIS2, GDPR, DORA, customer contracts, and cyber insurance.
• 24-hour, 72-hour, intermediate update, and one-month reporting templates.
• Tabletop exercise records testing external notification.
• Records of prior notifications, decisions not to notify, and legal rationale.

Map NIS2 Article 21 to ISO 27001 controls and policy evidence

A certificate alone does not answer a regulator’s question. A control mapping does. The following table gives security and compliance teams a practical bridge between NIS2 Article 21 areas, ISO/IEC 27002:2022 controls, Clarysec policy anchors, and evidence.

Clarysec’s Zenith Controls also covers ISO/IEC 27002:2022 control 5.31, Legal, statutory, regulatory and contractual requirements, as a preventive control with confidentiality, integrity, and availability impact. It ties 5.31 to privacy and protection of PII, records retention, independent review, and compliance with internal policies. It also maps 5.31 to GDPR accountability, NIS2 supply chain compliance, DORA ICT risk management, NIST CSF governance, NIST SP 800-53 program controls, and COBIT 2019 external compliance oversight.

“Control 5.31 ensures that all relevant legal, regulatory, statutory, and contractual requirements related to information security are identified, documented, and continuously managed.”

That is exactly what a national authority wants to see after registration: not just that NIS2 is listed, but that the organization has a living mechanism to identify, map, implement, monitor, and update obligations.

Do not separate NIS2 from DORA, GDPR, suppliers, and cloud

NIS2 evidence rarely exists in isolation.

NIS2 Article 21(2)(d) requires supply chain security, including security-related aspects of relationships with suppliers and service providers. Article 21(3) requires supplier-risk decisions to consider vulnerabilities, overall product quality, cybersecurity practices, secure development procedures, and relevant coordinated EU supply-chain risk assessments.

ISO 27001:2022 Annex A provides the operational bridge through A.5.19 to A.5.23. For SaaS and cloud organizations, these controls often determine whether registration evidence is superficial or defensible.

DORA sharpens the supplier picture for financial entities. Articles 28 to 30 require ICT third-party risk management, a register of ICT service contracts, distinction of services supporting critical or important functions, pre-contract risk assessment, due diligence, contractual security requirements, audit and inspection rights, termination rights, tested exit strategies, subcontracting assessment, data location transparency, incident assistance, cooperation with authorities, and transition arrangements. If a SaaS provider serves DORA-regulated customers, its contracts and assurance pack may be examined even if it is not the financial entity itself.

Clarysec’s Third-party and supplier security policy - SME Third-party and supplier security policy - SME should therefore be tied into the NIS2 evidence pack. Supplier readiness should include:

• Supplier inventory and criticality classification.
• Supplier due diligence and risk assessments.
• Contract clauses for security, incident assistance, audit rights, data location, subcontracting, and exit.
• Cloud shared responsibility matrices.
• Monitoring records for critical providers.
• Exit and recovery testing for critical services.
• Supplier incident notification and escalation procedures.

GDPR must also be integrated. A NIS2 significant incident can also be a personal data breach if customer, employee, or user data is compromised. GDPR requires controllers to demonstrate accountability and, where notification thresholds are met, notify the supervisory authority within 72 hours after becoming aware of a personal data breach. Your incident response workflow must assess NIS2, GDPR, DORA, contractual, and customer obligations in parallel.

Assemble a one-week NIS2 evidence pack

A SaaS provider, MSP, MSSP, cloud provider, or digital infrastructure company can make substantial progress in one focused week.

Day 1, classify the entity and services. Use the ISMS scope statement and interested-party register. Add a NIS2 scope memo that identifies Annex I or Annex II categories, EU services, Member States, customers, dependencies, size assumptions, and whether DORA or sector rules apply. Record classification uncertainty as a risk if legal interpretation is not final.

Day 2, update the legal and regulatory obligations register. Add NIS2 Articles 20, 21, and 23, registration requirements under national law, GDPR breach duties, DORA obligations where relevant, and key contractual notification requirements. Map each obligation to a policy, owner, control, evidence source, and review frequency.

Day 3, update risk assessment and treatment. Include legal, regulatory, operational, supplier, financial, reputational, and societal impact in the risk criteria. Add risks such as failure to register, incorrect entity classification, missed 24-hour early warning, unavailable authority contacts, supplier outage affecting critical services, insufficient board oversight, and inability to evidence control effectiveness.

Day 4, refresh the SoA. Confirm NIS2-relevant controls, including A.5.5 contact with authorities, A.5.19 to A.5.23 supplier and cloud controls, A.5.24 to A.5.28 incident controls, A.5.29 security during disruption, A.5.30 ICT readiness for business continuity, A.5.31 legal requirements, A.5.34 privacy, A.8.8 vulnerability management, A.8.13 backups, A.8.15 logging, A.8.16 monitoring activities, A.8.24 cryptography, and secure development controls A.8.25 to A.8.32.

Day 5, test incident reporting. Run a tabletop exercise: a cloud misconfiguration exposes customer data and disrupts service across two Member States. Start the clock. Can the team classify the event, assess GDPR, NIS2, DORA, contractual, and customer thresholds, prepare a 24-hour early warning, draft a 72-hour notification, preserve evidence, and assign root-cause analysis?

Day 6, gather evidence. Create a regulator-ready folder with the scope memo, legal register, risk register, SoA, authority contact list, incident playbook, supplier register, board minutes, training records, logs, monitoring reports, backup tests, vulnerability reports, internal audit scope, and corrective action log.

Day 7, management review. Present the readiness pack to leadership. Record approvals, residual risks, open actions, deadlines, resources, and owner accountability. If registration is due, attach the evidence index to the registration decision record.

Clarysec’s Audit and Compliance Monitoring Policy for SMEs Audit and Compliance Monitoring Policy-sme - SME anticipates this need:

“Evidence must be aligned with NIS2 obligations where the organization is designated as an important entity or otherwise falls within the scope of national law”

The enterprise Audit and Compliance Monitoring Policy Audit and Compliance Monitoring Policy states the objective:

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

That is the goal: defensible evidence before the request arrives.

Prepare for different audit lenses

A certification auditor, national authority, customer auditor, privacy auditor, and supplier assurance team will not ask identical questions. A strong NIS2 evidence pack works across all of them.

For ISO/IEC 27002:2022 control 5.5, auditors commonly expect documented authority contacts, assigned responsibilities, contact maintenance, incident response playbooks, and scenario-based clarity. A simple audit question can reveal maturity: “In the event of ransomware, who contacts law enforcement or the national CSIRT?” If the answer depends on someone remembering a name, the control is not ready.

Clarysec’s Logging and Monitoring Policy Logging and Monitoring Policy - SME reinforces the evidence expectation:

“Logs must be available and intelligible for external auditors or regulators upon request”

Clarysec’s Information Security Policy Information Security Policy sets the broader enterprise standard:

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

That is the audit test in one sentence. If a control cannot be evidenced, it will not carry much weight when a competent authority asks for proof.

Final NIS2 registration evidence checklist

Use this checklist before registration or before responding to a national authority request.

• Document the NIS2 scope analysis, including Annex I or Annex II rationale, service descriptions, size assumptions, Member State footprint, and entity classification.
• Identify whether DORA applies directly, or indirectly through financial-sector customers and ICT service contracts.
• Update the ISMS scope to include relevant services, dependencies, outsourced processes, and regulatory interfaces.
• Add NIS2, GDPR, DORA, sector rules, and contractual requirements to the legal and regulatory obligations register.
• Map each obligation to policies, controls, owners, evidence, review frequency, and management reporting.
• Confirm board approval and oversight of cybersecurity risk-management measures.
• Maintain management and employee cybersecurity training records.
• Update risk criteria to include regulatory impact, service disruption, customer harm, cross-border impact, and supplier dependency.
• Record NIS2-related risks in the risk register and link them to treatment plans.
• Update the SoA with NIS2-relevant Annex A controls and implementation status.
• Maintain authority contact lists and notification procedures for CSIRTs, competent authorities, DPAs, financial supervisors, and law enforcement.
• Test the 24-hour early warning, 72-hour notification, intermediate update, and one-month final report workflow.
• Maintain supplier and cloud evidence, including due diligence, contracts, audit rights, monitoring, subcontracting, and exit plans.
• Evidence control effectiveness through logs, metrics, audits, dashboards, test results, and corrective actions.
• Prepare an evidence index so any regulator, customer, or auditor request can be answered quickly.

The Clarysec next step

NIS2 entity registration is not the finish line. It is the point where your organization becomes visible to national cybersecurity supervision. The right question is not “Can we register?” The right question is “If the authority asks for evidence after registration, can we produce a coherent ISO 27001:2022 story in hours, not weeks?”

Clarysec helps organizations build that story through the Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, and practical ISO 27001:2022 policy sets that connect legal obligations, risk treatment, incident reporting, supplier security, logging, monitoring, audit evidence, and management accountability.

Run a NIS2 evidence gap review against your current ISMS. Start with the scope memo, legal register, risk register, SoA, authority contact list, incident reporting workflow, supplier register, and audit evidence folder. If those artifacts are incomplete or disconnected, Clarysec can help you turn them into a regulator-ready evidence pack before your national authority asks.