NIS2 2024/2690 ISO 27001 Cloud Provider Map
At 08:17 on a Tuesday, Maria, CISO of a European managed service provider, receives the alert every MSP dreads. One privileged remote management account has triggered impossible travel alerts. Two customer tenants show abnormal administrative actions. The SOC has already opened a critical incident bridge.
By 09:00, the CEO joins the call. The questions change immediately.
Are we in scope of NIS2? Does Commission Implementing Regulation (EU) 2024/2690 apply to us? Do we need a 24-hour early warning? Which customers must be notified? Can we prove MFA, logging, segmentation, vulnerability management, supplier controls and incident escalation were operating before the incident?
Maria’s company is ISO/IEC 27001:2022 certified. It provides cloud management, data centre services and managed security support to customers that include a logistics provider and a regional bank. The certificate matters, but it does not answer the operational questions by itself. The legal team has a draft notification process. The compliance manager has a spreadsheet. The auditor has asked for the Statement of Applicability, incident response testing, privileged access logs, supplier due diligence, cloud shared responsibility evidence and business continuity assumptions.
This is the moment when NIS2 stops being a legal text and becomes an operational control problem.
For cloud computing service providers, managed service providers, managed security service providers and data centre providers, NIS2 and Implementing Regulation 2024/2690 raise the bar from general security intent to inspectable control evidence. Governance, risk management, access control, asset management, vulnerability handling, incident response, supplier security, logging, monitoring, encryption, business continuity and physical resilience must operate as one system.
ISO/IEC 27001:2022 is the best backbone for that system, but only if the organization maps NIS2 requirements into the ISMS, risk register, Statement of Applicability, policies and evidence model. A certificate on the wall is not enough. The real work is building an auditable thread from regulation to risk, from risk to control, from control to policy, and from policy to operating evidence.
Why NIS2 2024/2690 changes the cloud and MSP compliance conversation
NIS2 uses a sector-plus-size model, but its digital infrastructure and ICT service management categories are intentionally broad. Under NIS2 Article 2 and Article 3, read with Annex I and Annex II, many organizations can be classified as essential or important entities, including cloud computing service providers, data centre service providers, managed service providers, managed security service providers, DNS providers, TLD registries, content delivery networks and trust service providers. Member States must establish and periodically review lists of essential and important entities, with the first list deadline set for 17 April 2025.
This matters because cloud, MSP, MSSP and data centre providers sit inside other organizations’ risk chains. A cloud control-plane compromise can affect thousands of customer systems. A data centre outage can cascade into banking, healthcare, logistics and public administration. An MSP credential breach can become a multi-client ransomware event. An MSSP detection failure can delay containment across regulated customers.
NIS2 Article 20 requires management bodies to approve cybersecurity risk-management measures and oversee implementation. Article 21 requires appropriate and proportionate technical, operational and organizational measures based on an all-hazards approach. The baseline includes risk analysis, incident handling, business continuity, supply-chain security, secure acquisition and development, vulnerability handling and disclosure, effectiveness assessment, cyber hygiene, training, cryptography, HR security, access control, asset management, MFA or continuous authentication, secured communications and emergency communications.
Article 23 adds staged significant incident reporting, including an early warning within 24 hours, incident notification within 72 hours, intermediate reports when requested and a final report within one month after notification or after incident handling where the incident is ongoing.
Implementing Regulation 2024/2690 makes these expectations more concrete for relevant digital providers. In practice, authorities, customers and auditors will not only ask whether policies exist. They will ask whether the controls are mapped, owned, tested and evidenced.
ISO/IEC 27001:2022 turns NIS2 into ISMS operating context
A common NIS2 readiness mistake is to start with a large checklist and assign tasks across IT, legal, SOC, infrastructure, vendor management and compliance. That can create activity, but it often fails under audit because no one can show why controls were selected, how they relate to risk, who accepted residual risk and what evidence proves effectiveness.
ISO/IEC 27001:2022 gives providers the structure to avoid that failure.
Clauses 4.1 to 4.4 require the organization to determine internal and external issues, identify interested parties and their requirements, decide which requirements will be addressed through the ISMS and define the ISMS scope, including interfaces and dependencies. For a cloud or MSP provider, the scope should explicitly consider NIS2, Implementing Regulation 2024/2690, customer security schedules, DORA-driven customer requirements, cloud regions, subcontractors, data centre dependencies, remote management platforms, privileged access paths and incident notification obligations.
Clauses 5.1 to 5.3 require leadership, policy alignment, resources, communication, assigned responsibilities and management accountability. This directly supports NIS2 Article 20.
Clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, risk owners, likelihood and consequence analysis, control selection, comparison with Annex A, a Statement of Applicability, a risk treatment plan and formal residual-risk acceptance. This is where NIS2 becomes operational. Each regulatory requirement becomes a risk driver, compliance obligation, control requirement or evidence requirement.
Clarysec starts this work with Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, especially the Risk Management phase.
From Step 13, Risk Treatment Planning and Statement of Applicability, the Zenith Blueprint instructs teams to build traceability between risks, controls and regulatory drivers:
“Cross-reference regulations: If certain controls are implemented specifically to comply with GDPR, NIS2, or DORA, you can note that in either the Risk Register or in the SoA notes. E.g. control 8.27 (Secure deletion of data) might be very relevant for GDPR’s requirement to dispose of personal data; you could note ‘Applicable – supports GDPR Art.32 (security of processing)’. This is not required by ISO, but it helps demonstrate you considered those frameworks”
Step 14, Risk Treatment Policies and Regulatory Cross-References, adds the practical mapping discipline:
“For each regulation, if applicable, you may create a simple mapping table that lists the regulation’s key security requirements and the corresponding controls/policies in your ISMS. This isn’t mandatory in ISO 27001, but it’s a useful internal exercise to ensure nothing fell through the cracks.”
That is the difference between saying “we are ISO certified” and proving “our ISO/IEC 27001:2022 ISMS addresses NIS2 Implementing Regulation 2024/2690.”
Unified NIS2 to ISO/IEC 27001:2022 control map
The following mapping is not legal advice or a substitute for national transposition analysis. It is a practical control architecture for providers that need an auditable ISO/IEC 27001:2022 route to NIS2 readiness.
| NIS2 and Implementing Regulation theme | ISO/IEC 27001:2022 ISMS mechanism | Key Annex A control areas | Clarysec implementation evidence |
|---|---|---|---|
| Governance and management accountability | Clauses 4, 5, 6 and 9 define context, leadership, risk planning and performance review | 5.1 Policies for information security, 5.2 Information security roles and responsibilities, 5.31 Legal, statutory, regulatory and contractual requirements | ISMS scope, interested-party register, board approval, risk register, SoA, management review minutes |
| Cloud service governance | Risk assessment, supplier due diligence, shared responsibility and control selection | 5.23 Information security for use of cloud services, 5.19 Information security in supplier relationships, 5.22 Monitoring, review and change management of supplier services | Cloud inventory, provider risk assessment, shared responsibility matrix, contract clauses, cloud logging evidence |
| MSP and MSSP privileged access | Risk treatment for customer environments, admin platforms and support tooling | 5.15 Access control, 5.16 Identity management, 5.18 Access rights, 8.2 Privileged access rights, 8.5 Secure authentication | PAM records, MFA reports, remote access logs, bastion or Zero Trust gateway configuration, access reviews |
| Data centre resilience | Business impact analysis, continuity planning and dependency management | 5.30 ICT readiness for business continuity, 7.1 Physical security perimeters, 7.2 Physical entry, 8.13 Information backup, 8.14 Redundancy | BIA, RTO and RPO records, DR test report, physical access logs, power and cooling test evidence |
| Incident reporting and escalation | Incident process linked to legal, contractual and customer notification triggers | 5.24 Information security incident management planning and preparation, 5.25 Assessment and decision on information security events, 5.26 Response to information security incidents, 5.27 Learning from information security incidents | 24-hour early warning playbook, 72-hour notification workflow, incident register, post-incident review |
| Vulnerability handling and disclosure | Risk-based vulnerability treatment, exception handling and effectiveness evaluation | 8.8 Management of technical vulnerabilities, 8.9 Configuration management, 8.32 Change management, 8.16 Monitoring activities | Scan results, remediation SLAs, exception approvals, patch reports, threat intelligence inputs |
| Supply-chain security | Interested-party requirements and supplier risk integrated into the ISMS | 5.19 Information security in supplier relationships, 5.20 Addressing information security within supplier agreements, 5.21 Managing information security in the ICT supply chain, 5.22 Monitoring, review and change management of supplier services | Supplier tiering, due diligence questionnaires, contract clauses, audit rights, subcontractor register, exit plans |
| Logging, monitoring and investigation | Detection, evidence, time correlation and incident support | 8.15 Logging, 8.16 Monitoring activities, 8.17 Clock synchronization, 5.25 Assessment and decision on information security events | SIEM coverage map, log retention proof, alert tuning records, clock synchronization records, incident correlation evidence |
| Network and tenant isolation | Secure architecture, segmentation and restricted administrative paths | 8.20 Network security, 8.22 Segregation of networks, 8.23 Web filtering, 8.24 Use of cryptography | Network diagrams, firewall rules, cloud security groups, VPC or subnet rules, segmentation test results |
This mapping becomes powerful when embedded into the risk register and Statement of Applicability. For example, a provider can create a risk scenario called “Compromise of remote management platform leads to unauthorized actions in customer environments.” Controls include MFA, privileged access management, segmentation, logging, vulnerability management, supplier security, incident planning and customer notification procedures. The SoA notes can reference NIS2 Article 21, Article 23, Implementing Regulation 2024/2690, customer contracts and DORA customer due diligence requirements where relevant.
Cloud governance: ISO control 5.23 is a NIS2 anchor
For cloud providers and MSPs that use cloud services to deliver customer services, ISO/IEC 27001:2022 Annex A control 5.23, Information security for use of cloud services, is one of the most important anchors.
Zenith Controls: The Cross-Compliance Guide Zenith Controls summarizes control 5.23 as a preventive control supporting confidentiality, integrity and availability, tied to supplier relationship security, governance, ecosystem risk and protection. It covers cloud-service governance, shared responsibility, provider assessment, inventories, data location, logging, encryption, identity roles, monitoring, contract clauses, supplier risk, cloud exit and resilience planning.
The Zenith Blueprint, Controls in Action phase, Step 23, explains the practical reason:
“The cloud is no longer a destination, it’s the default. Control 5.23 recognizes this reality and requires that information security be explicitly addressed in the selection, use, and management of cloud services, not as an afterthought, but as a design principle from the very beginning.”
For an MSP, every remote monitoring and management platform, customer portal, ticketing tool, security telemetry platform, backup service, cloud directory and SaaS administrative console must be governed. For a data centre provider, cloud governance may apply to monitoring platforms, visitor management systems, physical access control integrations, remote management systems and customer portal infrastructure.
Clarysec’s Enterprise Cloud Usage Policy Cloud Usage Policy makes pre-activation due diligence mandatory:
“All cloud use must undergo risk-based due diligence before activation, including provider assessment, legal compliance validation, and control validation reviews.”
From section “Governance Requirements”, policy clause 5.2.
For smaller providers, the Cloud Usage Policy-sme Cloud Usage Policy-sme - SME creates a lightweight approval model:
“All use of cloud services must be reviewed and approved by the General Manager (GM) before implementation or subscription.”
From section “Governance Requirements”, policy clause 5.1.
Both approaches support the same NIS2 expectation: cloud dependency risk must be understood before the service becomes part of the delivery chain.
Incident response: the 24-hour clock starts before the report is drafted
NIS2 Article 23 is unforgiving because the reporting timeline starts from awareness of a significant incident, not from the moment a perfect root-cause analysis is available. The challenge for providers is quickly determining whether an event is significant, which customers are affected, whether personal data is involved, whether cross-border service impact exists and which contractual clocks have started.
ISO/IEC 27001:2022 Annex A control 5.24, Information security incident management planning and preparation, is the planning control. Zenith Controls summarizes it as a corrective control supporting confidentiality, integrity and availability, tied to Respond and Recover concepts, governance, event management and defense. It includes roles, responsibilities, escalation paths, communication protocols, regulatory notification readiness, alignment with logging and monitoring, integration with business continuity and disaster recovery, post-incident learning and mapping to NIS2, GDPR, DORA, ISO 22301, NIST CSF, NIST SP 800-53 and COBIT 2019.
Clarysec’s Incident Response Policy-sme Incident Response Policy-sme - SME turns the first decision into a time-bound requirement:
“The General Manager, with input from the IT provider, must classify all incidents by severity within one hour of notification.”
From section “Governance Requirements”, policy clause 5.3.1.
That one-hour classification supports the operational discipline needed for NIS2 24-hour early warning analysis, GDPR personal data breach assessment, DORA customer escalation and contractual notification triage.
A provider’s incident decision tree should answer four questions:
- Is there confirmed or suspected compromise of confidentiality, integrity or availability?
- Does the event affect service provision, customer environments, regulated customers, personal data or critical functions?
- Could it cause severe operational disruption, financial loss or material or non-material damage?
- Which notification obligations apply: NIS2, GDPR, DORA customer obligations, contractual SLAs or national regulator expectations?
The decision tree should be tested in tabletop exercises before a real incident.
Vulnerability management: prove risk reduction before impact
NIS2 requires vulnerability handling and disclosure. For customers and regulators, vulnerability management is one of the easiest control areas to measure because it produces clear evidence: scan coverage, patch timelines, exception approvals, exploited vulnerability analysis and remediation records.
ISO/IEC 27001:2022 Annex A control 8.8, Management of technical vulnerabilities, is summarized in Zenith Controls as a preventive control across confidentiality, integrity and availability, tied to Identify and Protect, threat and vulnerability management, governance, ecosystem, protection and defense. It includes vulnerability identification, assessment, prioritization, patching, compensating controls, threat intelligence integration, vulnerability disclosure, cloud and application vulnerability responsibilities, audit evidence and remediation timelines.
Clarysec’s Enterprise Vulnerability and Patch Management Policy Vulnerability and Patch Management Policy gives auditors a concrete model to test:
“The organization must classify all detected vulnerabilities using a standardized methodology (e.g., CVSS v3.x) and apply remediation timelines aligned with business criticality: 5.2.1 Critical (CVSS 9.0-10.0): Immediate review; patching deadline of 72 hours maximum. 5.2.2 High (7.0-8.9): Response within 48 hours; patching deadline of 7 calendar days. 5.2.3 Medium (4.0-6.9): Response within 5 days; patching deadline of 30 calendar days. 5.2.4 Low (<4.0): Response within 10 days; patching deadline of 60 calendar days.”
From section “Governance Requirements”, policy clause 5.2.
For a cloud provider, this must cover hypervisor components, container images, orchestration layers, customer-facing APIs, CI/CD pipelines, administrative consoles and third-party libraries. For an MSP, the key question is whether internal vulnerabilities are separated from customer-managed vulnerabilities and whether contracts define responsibility. For a data centre provider, the scope can include building management systems, access control systems, monitoring platforms, remote hands tooling and network infrastructure.
The shared responsibility model must be documented. A provider may not own every patch, but it must still manage the risk, notify the customer where appropriate and prove that responsibility boundaries are understood.
Logging, monitoring and segmentation make incidents investigable
When a provider incident becomes customer-impacting, the first evidence questions are simple: who logged in, from where, with what privilege, to which tenant, what changed, what logs exist and whether administrative paths were segmented.
Clarysec’s Enterprise Logging and Monitoring Policy Logging and Monitoring Policy requires covered systems to generate the logs responders and auditors need:
“All covered systems must generate logs capturing: 6.1.1.1 User authentication and access attempts 6.1.1.2 Privileged user activities 6.1.1.3 Configuration changes 6.1.1.4 Failed access attempts or system events 6.1.1.5 Malware detections and security alerts 6.1.1.6 External communications and firewall rule triggers”
From section “Policy Implementation Requirements”, policy clause 6.1.1.
For SMEs relying on external providers, the Logging and Monitoring Policy-sme Logging and Monitoring Policy-sme - SME adds a contractual requirement:
“Contracts must require providers to retain logs for at least 12 months and provide access upon request”
From section “Governance Requirements”, policy clause 5.5.1.3.
Segmentation is equally important. The Network Security Policy-sme Network Security Policy-sme - SME states:
“Internal networks must be segmented by function (e.g., finance, guest, IoT, administrative systems)”
From section “Policy Implementation Requirements”, policy clause 6.2.1.
The Zenith Blueprint, Controls in Action phase, Step 20, gives the practical audit procedure for network architecture and segmentation. It instructs teams to review and document network layout, verify firewall rules, IPS/IDS and remote access configurations, confirm cloud security groups and VPC or subnet rules match intended architecture, list internal and external network services and validate that sensitive systems are not reachable from general user VLANs or guest networks.
For an MSP, remote management tools must not sit flat on the office network. For a data centre provider, management interfaces for power, cooling, access control and customer network services should be isolated and monitored. For a cloud provider, control-plane access should be restricted through identity, network, device posture and privileged workflow controls.
Supplier security: the provider is also a customer
Cloud, MSP, MSSP and data centre providers are suppliers to regulated clients, but they are also customers of software vendors, telecom carriers, identity providers, SaaS platforms, hardware suppliers, subcontractors and infrastructure operators.
NIS2 makes supply-chain security a core requirement. DORA, which applies from 17 January 2025, makes ICT third-party risk management central for financial entities. NIS2 Article 4 and Recital 28 recognize DORA as the sector-specific Union legal act for financial entities where requirements overlap. This does not remove pressure from cloud and MSP providers. It increases it, because financial customers push DORA-grade contractual requirements, audit rights, resilience testing, exit strategies and incident reporting expectations into supplier contracts.
Clarysec’s Enterprise Third party and supplier security policy Third party and supplier security policy requires controlled third-party access:
“All third-party access must be logged and monitored and, where feasible, segmented through bastion hosts, VPNs, or Zero Trust gateways.”
From section “Policy Implementation Requirements”, policy clause 6.3.2.
The Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy-sme - SME expresses least privilege in direct terms:
“Suppliers must be granted access only to the minimum systems and data required to perform their function.”
From section “Policy Implementation Requirements”, policy clause 6.2.1.
These clauses map naturally to ISO/IEC 27001:2022 Annex A controls 5.19, 5.20, 5.21 and 5.22. They also support GDPR processor and subprocessor governance, DORA third-party risk reviews and customer audit questionnaires.
Business continuity and data centre resilience: prove the assumptions
NIS2 Article 21 includes business continuity, backup management, disaster recovery and crisis management. DORA Articles 11 to 14 require ICT business continuity policies, response and recovery plans, business impact analysis, backup policies, restoration procedures, recovery objectives, testing, post-incident reviews and crisis communications for financial entities.
For cloud and data centre providers, continuity is not a binder. It is architecture, capacity, contracts, dependencies, restoration evidence and tested assumptions.
Clarysec’s Enterprise Business Continuity Policy and Disaster Recovery Policy Business Continuity Policy and Disaster Recovery Policy requires annual BIA and review after significant changes:
“Business Impact Analysis (BIA) shall be performed at least annually for all critical business units and reviewed upon significant changes to systems, processes, or dependencies. BIA outputs shall define: 5.2.1. Maximum Tolerable Downtime (MTD) 5.2.2. Recovery Time Objectives (RTOs) 5.2.3. Recovery Point Objectives (RPOs) 5.2.4. Critical dependencies (systems, suppliers, personnel)”
From section “Governance Requirements”, policy clause 5.2.
In a data centre scenario, BIA should cover power feeds, UPS, generators, fuel contracts, cooling, fire suppression, network carriers, physical access systems, remote hands, monitoring, spare hardware and customer communication channels. In a cloud scenario, it should cover regions, availability zones, replication, backup immutability, identity dependencies, DNS, certificate authorities, API gateways and support systems. In an MSP scenario, it should cover remote management tooling, privileged access vaults, EDR consoles, ticketing, documentation repositories and emergency communications.
ISO 22301 can strengthen the business continuity management discipline, while ISO/IEC 27005:2022 supports risk criteria, treatment planning, monitoring, evidence and continual improvement. This is useful because NIS2 readiness requires the organization to consolidate legal, contractual, operational, supplier, technology, financial, process and human factors into one risk process.
Practical risk trace for an MSP remote access breach
A practical workshop can begin with one scenario:
“Compromise of privileged remote access results in unauthorized access to customer systems, service disruption, possible personal data exposure and regulatory notification obligations.”
Create a risk register row and complete the trace.
| Field | Example entry |
|---|---|
| Risk owner | Head of Managed Services |
| Assets and processes | Remote management platform, customer admin accounts, privileged vault, ticketing, SIEM, customer environments |
| Threat event | Credential theft, MFA fatigue, token theft, exploited RMM vulnerability, malicious insider |
| Impact | Customer compromise, service outage, contractual breach, NIS2 significant incident, GDPR personal data breach, DORA customer escalation |
| Existing controls | MFA, PAM, least privilege, segmentation, logging, vulnerability scanning, incident response plan |
| Required treatment | Tighten conditional access, enforce just-in-time admin, improve tenant isolation, increase log retention, test notification playbook |
| ISO/IEC 27001:2022 evidence | Risk assessment, SoA, access review, log samples, vulnerability reports, tabletop exercise, management review |
| NIS2 mapping | Article 21 risk management and Article 23 incident reporting, plus Implementing Regulation operational measures |
| Customer mapping | Contractual notification, audit rights, security schedule, DORA-aligned questionnaires where applicable |
| Residual risk decision | Accepted by risk owner after treatment, reviewed quarterly |
Then update the Statement of Applicability. For each relevant Annex A control, explain why it applies and which NIS2 theme it supports. Finally, collect evidence before an audit: MFA enforcement reports, privileged account lists, log retention settings, RMM patch status, SIEM alerts, incident classification records, supplier access approvals and tabletop results.
How different auditors will test the same control environment
An integrated ISMS must satisfy different assurance lenses without creating separate evidence packs for every framework.
| Auditor lens | What they will focus on | Typical evidence requested |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Whether NIS2, DORA and GDPR requirements are reflected in context, scope, risk assessment, SoA, internal audit and management review | ISMS scope, interested-party register, risk methodology, risk register, SoA, treatment plan, policies, internal audit report, management review |
| NIS2 competent authority or delegated assessor | Whether cybersecurity risk-management measures are appropriate and proportionate, and whether significant incident reporting is operational | NIS2 mapping, incident classification procedure, 24-hour and 72-hour workflow, board oversight, technical control evidence, supplier security evidence |
| DORA customer assessor | Whether ICT third-party risk, resilience testing, incident reporting, audit rights and exit planning meet financial-sector expectations | Contract clauses, subcontractor register, resilience tests, incident SLAs, exit plan, audit reports, concentration-risk support |
| GDPR auditor or DPO review | Whether personal data breach risk, processor obligations, confidentiality, integrity and accountability are addressed | Records of processing, DPA terms, breach assessment workflow, access logs, encryption evidence, retention and deletion controls |
| NIST-oriented assessor | Whether identify, protect, detect, respond and recover capabilities are implemented and measured | Asset inventory, access controls, vulnerability data, SIEM coverage, response playbooks, recovery tests, metrics |
| COBIT 2019 or ISACA auditor | Whether governance objectives, responsibilities, risk ownership, control monitoring and assurance processes are established | Governance charters, RACI, risk appetite, control ownership, KPI/KRI reporting, assurance plan, corrective action tracking |
This is where Zenith Controls helps as a cross-compliance guide. For controls such as 5.23, 5.24 and 8.8, it connects ISO/IEC 27001:2022 control expectations to NIS2, GDPR, DORA, NIST SP 800-53, COBIT 2019, NIST CSF and ISO 22301 themes. The goal is not to create separate compliance programs. The goal is one evidence architecture tagged by control, risk, regulatory driver and owner.
The Clarysec implementation pattern
For cloud, MSP, MSSP and data centre providers, the work should move in five layers.
First, confirm scope. Determine whether the organization and services are in scope under NIS2, which Member State rules apply, whether Implementing Regulation 2024/2690 applies to the provider category and whether customers impose DORA, GDPR, NIST or sector-specific obligations.
Second, build the ISMS context. Under ISO/IEC 27001:2022 clauses 4 and 5, identify interested parties, legal obligations, customer commitments, supplier dependencies, service boundaries and management responsibilities.
Third, perform risk assessment and treatment using ISO/IEC 27005:2022 principles. Consolidate NIS2, DORA, GDPR, contracts, internal policies and service risks into one baseline requirements register. Define risk criteria, owners, likelihood, impact, treatment options, control choices and residual-risk approvals.
Fourth, map controls into the Statement of Applicability. Use Zenith Blueprint Steps 13 and 14 to trace risks to Annex A controls and regulatory expectations. Use Zenith Controls to understand how controls such as 5.23, 5.24, 8.8, 5.20 and 5.30 map across frameworks and audit lenses.
Fifth, operationalize evidence. Policies are not enough. Clarysec’s policy library provides enforceable requirements for cloud approval, supplier access, logging, vulnerability remediation, network segmentation, incident classification and continuity planning. The evidence pack proves those requirements are working.
Next step: turn NIS2 pressure into audit-ready resilience
NIS2 Implementing Regulation 2024/2690 does not require chaos. It requires traceability, ownership and proof.
If you are a cloud service provider, MSP, MSSP or data centre operator, start with your services, customers, dependencies, incident scenarios and evidence obligations. Then run a structured NIS2-to-ISO/IEC 27001:2022 mapping exercise:
- Confirm whether your entity and services are in scope.
- Map NIS2 and Implementing Regulation themes into your ISMS scope.
- Update the risk register and Statement of Applicability.
- Apply Clarysec policies for cloud use, supplier security, logging, vulnerability management, incident response, network security and continuity.
- Use Zenith Blueprint Zenith Blueprint Steps 13, 14, 20 and 23 to create traceability and operational evidence.
- Use Zenith Controls Zenith Controls to cross-map ISO/IEC 27001:2022 controls against NIS2, DORA, GDPR, NIST and COBIT 2019 expectations.
- Test the evidence through an audit simulation before a customer, regulator or certification auditor asks for it.
Clarysec can help you move beyond checklist compliance and build an integrated ISMS that withstands NIS2, DORA, GDPR and customer audit pressure. Download the relevant Clarysec toolkits, book a mapping workshop or request an audit-readiness assessment to turn regulatory complexity into defensible security governance and operational resilience.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
