NIS2 and ISO 27001: reuse controls, examine the gaps

An ISO 27001 program can provide a strong operating structure for NIS2: risk assessment, accountable owners, controls, evidence, and improvement. The next step is a requirement-by-requirement assessment of what that structure actually covers.

For a CTO, the useful question is not whether the frameworks overlap. It is whether an implemented control protects the relevant service, satisfies the applicable obligation, and produces evidence that supports that conclusion. Reuse the implementation where those conditions hold; preserve legal and operational differences where they do not.

Understand what each framework establishes

ISO/IEC 27001 specifies requirements for a scoped information security management system, or ISMS. Clauses 4–10 address its management structure, including risk treatment, performance evaluation, and improvement. Annex A contains 93 reference controls across organizational, people, physical, and technological categories. Control applicability is risk-based, not a requirement to implement every control identically. ISO 27002 provides implementation guidance.

NIS2 is an EU directive implemented through national law. Applicability depends on sector, size, service, and specific inclusion rules. Annex I and Annex II identify relevant sectors, but sector alone does not determine whether an organization is an essential or important entity. Some entities are covered regardless of size.

The practical differences are:

Certification is performed by independent certification bodies, not ISO. It does not establish NIS2 compliance, and NIS2 does not generally require ISO 27001 certification. Enforcement can include supervisory measures and penalties; ISO certification has a different assurance purpose.

Start with matching boundaries

Compare the certified ISMS scope with the legal entities and services subject to NIS2. A certificate covering a development team may leave production operations, another subsidiary, or additional locations outside its boundary.

Create a scope comparison recording:

• Covered legal entities, countries, services, and the basis for inclusion.
• Relevant systems, networks, locations, and supporting suppliers.
• The ISMS scope, certificate scope, and exclusions.
• Applicable national requirements, sector rules, and responsible authorities, including applicable registration duties, required entity information, submission channels, and update obligations.
• Who approved the applicability assessment and when it must be revisited.

Distinguish a scope gap from a control gap. A production environment outside the ISMS may already have good access controls, but those controls still need ownership, assessment, and evidence within the NIS2 workstream.

Check sector-specific legislation before duplicating obligations. Article 4 addresses the relationship with sector-specific EU legal acts. For financial entities, the relationship with DORA requires role-specific analysis. For German operations, consult the BSI’s NIS2 information rather than assuming that existing KRITIS duties and NIS2 duties are identical.

Map implemented controls, not matching labels

Article 21 requires appropriate and proportionate technical, operational, and organizational measures. Its ten minimum measure areas provide a starting point for mapping, but similar wording is a useful lead, not proof of equivalence.

Use the following as review prompts, not automatic coverage declarations:

The Statement of Applicability records necessary controls and inclusion or exclusion reasoning. It is not interchangeable with the risk treatment plan, internal audit findings, or management-review records. Use those artifacts together to explain both design and operation.

A policy establishes expectations. A configuration export can show implementation. Access-review results, remediation tickets, and test records can show operation. Reuse evidence only where the system, period, and assessment objective match.

Avoid fixed overlap percentages. Coverage depends on implementation and legal scope; a universal number cannot establish readiness.

Build an incident-reporting path that can run under pressure

An ISO-aligned response plan may support detection, containment, investigation, and recovery without defining regulatory notification. NIS2 Article 23 adds reporting obligations for significant incidents.

The directive’s reporting stages generally include:

• An early warning without undue delay and within 24 hours of becoming aware of a significant incident.
• An incident notification without undue delay and within 72 hours, updating the early warning and providing an initial assessment.
• A final report generally within one month of submitting the incident notification. For an ongoing incident, a progress report is required at that point, with the final report due within one month after handling the incident.

An intermediate report must also be provided if requested by the CSIRT or competent authority.

Check applicable national and sector-specific rules: the directive includes a different notification timing for trust service providers. Do not use a generic outage threshold as a substitute for the applicable significance criteria.

As a practical implementation recommendation, create a reporting runbook specifying the assessment owner, escalation route, authorized submitter, backup personnel, authority channel, and information needed at each stage. Record detection, awareness, significance assessment, and submission timestamps distinctly.

Exercise the process with incomplete information. The team should be able to submit the required initial report without waiting for a finished forensic investigation. Preserve submitted versions, receipts, supporting facts, and decisions about whether an incident meets the threshold.

Where another reporting regime also applies, coordinate the investigation but assess each notification duty separately. A shared incident record does not make the recipients, triggers, or deadlines identical.

Make governance and resilience demonstrable

Article 20 requires management bodies to approve cybersecurity risk-management measures and oversee implementation. It also addresses management-body training. An existing management review is useful evidence, but check whether it explicitly records the relevant approvals, oversight, decisions, and follow-up.

Give management a decision-ready view: affected services, material risks, treatment options, unresolved exceptions, and effectiveness results. Meeting minutes that merely state “security discussed” provide little evidence of meaningful oversight. Assign each approved action an owner and review date.

Continuity needs similarly concrete treatment. Article 21 includes backups, disaster recovery, and crisis management; it does not impose a universal requirement for ISO 22301 certification. Determine the necessary depth from the service, risks, and applicable rules.

Test restoration and service recovery, not just backup-job completion. Include dependencies such as identity services, DNS, supplier support, privileged credentials, and communications when the normal environment is unavailable. Record achieved recovery results and unresolved blockers against agreed objectives.

Maintain a visible difference register

For every requirement, record its source and version, mapped controls, scope, evidence references, reviewer, and reuse rationale. Distinguish supported coverage, partial coverage, missing implementation, missing evidence, and a reasoned non-applicability decision. Absence of a document does not always mean absence of a control, but it does require investigation.

Each gap needs an owner, required change, evidence expectation, due date, and closure reviewer. Prioritize failures that threaten services or prevent time-critical reporting rather than treating every documentation task as equally urgent.

Common mistakes include mapping only Annex A while overlooking governance requirements, accepting a supplier certificate without checking its scope, treating last year’s evidence as current, and closing a task when a policy is published but the process remains untested. Registration or certification should never be treated as proof of operational implementation.

Worked example: extending an existing ISMS

Illustrative assumptions: a managed service provider has an ISO 27001-certified ISMS covering its main operating team. Its applicability assessment concludes that a service operated through an additional legal entity is subject to NIS2. That entity uses the same identity platform and incident team, but separate recovery arrangements.

The team first compares service boundaries. Existing authentication configurations may support both scopes, but the reviewer checks whether the additional entity’s administrators, emergency accounts, and service accounts are included. An access-review export covering only the original team cannot prove complete coverage.

Next, the incident owner retains the established response procedure and adds a significant-incident assessment and authority-notification path. A tabletop exercise simulates a supplier outage with uncertain customer impact. Participants record when they became aware of relevant facts, who decided significance, and how an early warning would be submitted.

Finally, the infrastructure owner runs a recovery exercise for the additional entity’s service. The test reveals that recovery credentials depend on the unavailable identity platform. The gap register assigns a corrective action and requires a successful retest before closure.

The resulting deliverables are a scope comparison, reviewed mappings, extended access-review evidence, reporting-exercise records, recovery results, and management approval of outstanding treatment actions. Shared controls remain shared; entity-specific evidence and decisions remain visible.

Turn the assessment into maintained work

Secani’s connected requirements and evidence model gives teams a structure for preserving shared work and framework-specific decisions. Model the services and dependencies, attach existing evidence to relevant controls, and turn missing coverage into owned tasks. Keep human approval explicit for mappings and evidence conclusions, including AI-assisted suggestions. Our guide to traceable cross-framework mapping explains how to retain the rationale behind reuse.

Start with one regulated service. Bring its scope, risk treatment, Statement of Applicability, incident runbook, and recent test evidence into a joint technical and compliance review. Produce a reviewed difference register, then use normal ISMS review cycles to maintain it as services, suppliers, and requirements change.