Certified but out of scope: an ISMS certificate that does not cover the business

No, as drafted it cannot be made. Three independent reasons.

1. The certificate's scope excludes most of the entity. An ISMS certificate asserts something about the defined scope. Here that is corporate IT and one data centre - not product development, not the manufacturing execution systems, not Timișoara. For a valve manufacturer, the excluded systems are where the operational consequence lives. The statement would use a certificate as evidence for an area it says nothing about.
2. Several Art. 21 duties are unmet regardless of certification. The risk register is stale since the acquisition, which breaches Art. 21(2)(a) directly. The management review did not address the risk-management measures, which weakens the Art. 20 oversight obligation. Lessons learned not feeding back breaches the spirit and letter of (f), assessing the effectiveness of measures.
3. Certification is not a presumption of conformity. NIS 2 does not provide that ISO/IEC 27001 certification creates a legal safe harbour. It is evidence a supervisor weighs; it does not discharge the duties, and it cannot cover systems outside its scope.

Why the overlap misleads people. Annex A of ISO/IEC 27001:2022 maps well onto much of Art. 21(2) - access control, cryptography, incident management, continuity, supplier relationships. But mapping is not scope. The Directive applies to the entity's networks and information systems used for its operations or services, under an all-hazards approach, and the entity decides what its ISMS covers.

An accurate statement: certified ISMS covering corporate IT and the Ulm data centre; NIS 2 programme underway with X, Y and Z completed and a defined completion date. Never claim compliance you cannot evidence under audit.

Principle. Measure the effectiveness of controls, not activity volume. A phishing click rate is an input indicator; on its own it tells the board nothing about whether the entity could contain a ransomware event in the manufacturing network.

Metric set, grouped by the control it evidences.

• Vulnerability handling (Art. 21(2)(i)): patch compliance by severity and asset class, reported separately for OT, with compensating controls recorded where patching waits for a maintenance window.
• Access (j): percentage of administrative accounts with phishing-resistant MFA; count of shared or unassigned privileged identities, target zero.
• Continuity (c): number of restore tests performed against the number planned, and measured recovery time against the documented objective - not 'backups configured'.
• Supply chain (d): percentage of tier-1 suppliers assessed in the last 12 months; open supplier findings and their age.
• Detection and response (b): time from first observable signal to triage; number of incidents and number notified, with reasons for each non-notification.
• People (g): training completion by site, including Timișoara.
• Improvement: ageing of open corrective actions and on-time completion of the risk-treatment plan.

Cadence. Monthly operational review of the metrics; quarterly risk review that updates the register with new assets, including the acquired plant; annual management review chaired by the management body under Art. 20, minuted, with decisions and owners.

Closing the loop. Make the ticket system unable to close a security incident without a linked risk-register review, with a named owner and a due date. Then verify at the quarterly review that the control change was implemented, and re-test the control within the internal audit cycle. Audit will want to trace one incident end-to-end: ticket, risk entry, control change, effectiveness evidence, management review.

Sequence over roughly nine months.

1. Weeks 1–4: management-body engagement (Art. 20). A minuted approval of the cybersecurity risk-management measures and the programme plan, plus training for the body. Without this, nothing downstream is anchored.
2. Weeks 2–10: gap assessment against Art. 21(2)(a)–(j) at entity level, not certificate level - covering the manufacturing execution systems, product development and Timișoara. Update the risk register before anything else, because every later prioritisation depends on it.
3. Weeks 6–20: remediate major nonconformities inside the current scope (management review, internal audit coverage, the lessons-learned loop). Fixing the existing scope first keeps the certificate valid while the extension runs.
4. Weeks 12–28: prepare the extension. Bring Timișoara's 31 OT assets and the development environment into the asset inventory and risk assessment, extend the Statement of Applicability, run internal audit across all sites, and hold an extension audit with the certification body.
5. Weeks 20–36: evidence pack for supervision. Management-body minutes, risk analysis and treatment decisions, incident register with notification records, supplier assessments, training records, continuity test results. Then a tabletop exercise to test whether the documented capability works.

Likely failure point 1: treating the certificate as the finish line. Important entities are supervised ex post, but supervision tests effectiveness, and a scope-extended certificate with an unexercised incident capability will not survive the first targeted request for information.

Likely failure point 2: the acquisition. Newly acquired sites are where inventories, risk registers and audit programmes systematically do not reach. Set an explicit day-one integration checklist for future acquisitions rather than doing this again.