After almost two years of European guidance around NIS2, an uncomfortable digital resilience mirror is gradually emerging. The intention was clear: a higher, harmonised level of cyber resilience across Europe, with management no longer delegating cybersecurity risks, but actively approving, monitoring and owning them. The reality looks less coherent.
Deadlines are being missed, national transpositions are progressing unevenly, and organisations are losing valuable momentum instead of gaining direction. What was supposed to start as a controlled compliance launch risks exploding, in some environments, into a collection of islands: many local interpretations, a lot of ego, little cohesion, and objectives that are barely understandable for employees.
Perhaps the most critical signal is that management often appears to be living on a different compliance planet: busy with reporting, certificates and formal responsibility, while operational teams struggle with feasibility, priorities, resources and practical execution.
That is precisely why a feasibility study before launch is not a luxury, but a necessary reality check. Without a balance between user experience, warranty, value visibility and metrics & lifecycle, NIS2 will not become a resilience programme, but a project with negative starting energy. The EU transposition deadline was 17 October 2024, and the Commission subsequently noted that several Member States had not fully completed transposition on time. At the same time, NIS2 requires management bodies to approve cybersecurity measures and oversee their implementation.
Together with Harry van der Plas and Karin Printemps, we successfully completed this exercise for many organisations. We would like to share the essence of our toolbox. Process management expert Karin Printemps took the lead. Harry’s experience and my own helped steer and refine the approach.
In practice, we see that compliance projects such as NIS2 are often approached incorrectly as a legal deadline or technical checklist, while in reality they are governance-driven change projects.
The European Commission describes NIS2 as a harmonised legal framework for cybersecurity across 18 critical sectors, with obligations related to risk management and resilience. Member States had to transpose the directive by 17 October 2024, and NIS2 replaced NIS1 from 18 October 2024. That is why the HarmonyQ triangle described here fits so well: it makes clear that an organisation only becomes mature when compliance, operations and governance are connected.
Karin Printemps: Compliance projects do not fail because organisations take no measures, but because they lose the balance between experience, reliability, visible value and measurable lifecycle control.
In ITIL 4, and now ITIL 5, value is not seen as a purely technical result, but as something created through collaboration, usability, risk reduction, reliability and continuous improvement. ITIL 4 refers to value co-creation, the service value system approach, the four dimensions of service management, and the importance of governance, practices and continual improvement.
The same reasoning can be applied to an internal NIS2 or ISO 27001 project: the goal is not “to obtain a standard”, but to create a governable, demonstrable and broadly supported level of cyber resilience.
Where NIS2 currently gets stuck is rarely at the level of intention. Nobody is against greater cyber resilience, better incident response or clear responsibility. The problem arises when ambition reaches the operational floor. That is where it becomes clear that compliance is not executed by policy documents, but by people with calendars, legacy systems, limited budgets, supplier dependencies and management expectations that are sometimes based more on PowerPoint than on reality. This is exactly where the feasibility study becomes the first real stress test: not the question “do we want to be compliant?”, but “can this organisation carry this without getting itself stuck?”
The HarmonyQ triangle makes that tension visible. It forces NIS2 and ISO 27001 out of the abstract world of standards, clauses and controls, and places them back where they belong: in the daily operation of the organisation. Because a measure that no one understands will be bypassed. A control that does not work reliably becomes theatre. A dashboard that shows no governance value becomes decoration. And a project without a lifecycle sooner or later becomes a compliance fossil: once intended to be alive, but petrified in a folder that no one opens anymore.
Or, as a board member had better not say out loud, but often thinks:
“We bought compliance. Why are we still not resilient?”
That is the uncomfortable core. Compliance can be bought as advice, a tool, a certificate or a project plan. Resilience cannot. Resilience only emerges when four forces come into balance: user experience, warranty, value visibility and metrics & lifecycle. Not as a theoretical ITIL model, but as a practical launch check before an organisation locks itself into deadlines, ownership and promises that are not operationally feasible.
The first question is therefore not technical but human: does compliance work for the people who have to live with it? In an internal NIS2 project, the “user” is not only the end user. It is also the process owner who has to accept a risk, the IT administrator who has to roll out MFA, the CISO who has to escalate incidents, the auditor who searches for evidence, the supplier who receives questionnaires, the board member who carries liability and the customer who expects trust. When controls exist only on paper but are too heavy, too slow or too unclear in practice, the familiar pattern emerges: exceptions, shadow IT, resistance and, ultimately, cynicism.
“A control that blocks the business will not protect the business. It will be bypassed by the business.”
Then comes warranty: the question of whether the measure also works when it matters. Not “do we have an incident procedure?”, but “does it work on a Friday evening at 10 p.m. when the responsible person is on holiday?” Not “have we assessed suppliers?”, but “do we know which supplier could break our continuity tomorrow?” Not “do we have logging?”, but “can we prove what happened before the customer, regulator or press asks?” Without warranty, compliance becomes documentation. With warranty, it becomes a management system.
“If the control only works during the audit, it is not a control. It is a performance.”
But even workable and reliable measures are not enough if the value remains invisible. Many organisations show activity: policies, meetings, dashboards, project plans, gap analyses. Yet the board does not always see which risks have actually decreased. That is where the gap between management and operations emerges. One side talks about percentages, maturity and compliance status; the other talks about patch pressure, supplier chaos, missing logging and people who do not understand the procedures. Value visibility translates these worlds to each other. MFA then no longer means “rollout completed”, but “lower likelihood of account misuse”. A tested incident procedure is no longer “exercise performed”, but “faster detection, escalation and decision-making”. An ISMS is no longer “ISO project”, but “structural risk governance”.
“Management does not need more dashboards. It needs fewer illusions.”
The fourth layer connects everything: metrics and lifecycle. Without measurements, there is no evidence. Without lifecycle, there is no sustainability. A NIS2 or ISO 27001 project that ends at implementation actually ends before it has begun. The real question is what happens after launch: who measures effectiveness, who follows up deviations, who closes risks, who retests controls, who reports trends, who decides when the context changes? Metrics must not be cosmetic. They must show whether the system is learning, deteriorating or remaining governable.
“A compliance project without lifecycle is not a programme. It is a snapshot with a deadline.”
That is why the feasibility study is not an administrative intermediate step, but the backbone of a successful launch. It examines whether the organisation can understand, carry, execute, prove and improve the measures. It exposes where islands arise, where egos collide, where ownership is missing and where management risks remaining stuck on another compliance planet. It shows whether NIS2 can become a mature resilience programme, or merely a project that accumulates negative energy before it has even started.
The central question then becomes simple but confrontational:
“Is this organisation ready to launch compliance — or only ready to announce it?”
That difference determines everything. An organisation that is only ready to announce compliance will mainly produce deadlines, documents and responsibilities. An organisation that is ready to launch compliance has tested the balance between people, measures, value and improvement beforehand. That is where the real digital resilience mirror begins: not with the question of whether NIS2 was implemented on paper, but whether the organisation is strong enough to sustain it in practice.
The four measures translated into NIS2 and ISO 27001
1. User experience: compliance must be workable
In an internal compliance project, the “user” is not only the end user, but also the process owner, IT administrator, CISO, auditor, supplier, board member and customer.
A NIS2 project fails when controls exist only on paper but are bypassed in daily operations. Think of MFA, incident reporting, asset registration, supplier assessment or logging: if they are too complex, exceptions, shadow IT and resistance will arise.
Article position:
Cybersecurity measures are only mature when people can apply them correctly, consistently and without disproportionate friction.
Examples of questions:
| Question | Application |
|---|---|
| Do employees understand why this measure exists? | Awareness and ownership |
| Does the measure fit into existing processes? | Process integration |
| Is the control executable for SMEs and departments with limited resources? | Proportionality |
| Is compliance experienced as support or as an administrative burden? | Adoption |
NIS2 itself is also based on appropriate and proportionate technical, operational and organisational measures. This supports the idea that compliance should not blindly be maximised, but aligned with risk, impact and context.
2. Warranty: the measure must work reliably
In ITIL terms, warranty concerns whether something is reliable, available, secure and fit for use. In a compliance context, this means not only “we have a policy”, but “the policy works under normal and disruptive conditions”.
For NIS2 and ISO 27001, warranty concerns:
| Warranty question | Compliance translation |
|---|---|
| Does the control work when it is needed? | Effectiveness |
| Is the control reproducible? | Consistency |
| Is there evidence? | Auditability |
| Is there ownership? | Accountability |
| Is the control maintained? | Lifecycle control |
ISO/IEC 27001 is described by ISO as a standard for establishing, implementing, maintaining and continually improving an Information Security Management System. Conformity means that an organisation has a system to manage information security risks.
Article position:
A NIS2 or ISO 27001 project without warranty becomes a documentation project; a project with warranty becomes a management system.
3. Value visibility: value must be visible to governance and stakeholders
Many compliance projects show activity, but not value. There are policies, dashboards, meetings and gap analyses, but the board does not always see which risks have actually decreased.
Value visibility means translating compliance into visible decision-making information:
| Operational output | Governance value |
|---|---|
| MFA rolled out | Lower likelihood of account misuse |
| Incident procedure tested | Faster detection and response |
| Suppliers assessed | Reduced supply-chain risk |
| Logging improved | Better detection and evidential capability |
| ISMS established | Structural risk governance |
NIS2 explicitly emphasises cybersecurity risk-management measures, incident impact and measures for network and information systems that are essential for services.
Article position:
Compliance only becomes governable when technical measures are translated into risk reduction, continuity, customer trust and board assurance.
4. Metrics & lifecycle: measure, adjust and keep improving
The fourth measure is the connecting layer. Without metrics, there is no evidence. Without lifecycle, there is no sustainability.
ITIL 4 includes measurement & reporting and continual improvement as core practices within the broader service value system approach. The ITIL service value system consists of guiding principles, governance, the service value chain, practices and continual improvement.
For a NIS2 or ISO 27001 project, this means that an implementation plan alone is not enough. A permanent measurement and improvement cycle is also required.
Possible KPIs:
| Domain | Example metric |
|---|---|
| Governance | % of risks with owner and review date |
| Awareness | % of employees trained and tested |
| Incident response | Time to detection, escalation and reporting |
| Suppliers | % of critical suppliers assessed |
| Technical hygiene | Patch compliance, MFA coverage, endpoint coverage |
| ISMS | % of controls tested, % of deviations closed |
| Board reporting | Number of open high risks, quarterly trend |
Thought exercise:
A compliance project without a lifecycle is a snapshot. NIS2 and ISO 27001 require a demonstrable system of continuous control.
Core message
A NIS2 or ISO 27001 project should not only answer the question “are the measures present?”, but four better questions: does it work for the user, is it reliable, is the value visible, and is it measured and improved across the full lifecycle?
Conceptual model
| HarmonyQ balance point | ITIL inspiration | NIS2 / ISO 27001 translation | Risk if absent |
|---|---|---|---|
| User experience | Value co-creation, focus on value | Workable controls, adoption, process ownership | Paper compliance |
| Warranty | Fit for use, reliability | Effective and demonstrable controls | False assurance |
| Value visibility | Value for stakeholders | Board reporting, risk reduction, customer trust | Management only sees costs |
| Metrics & lifecycle | Measurement, reporting, continual improvement | KPIs, audits, PDCA, control testing | One-off gap analysis without assurance |
Final reflection
NIS2 and ISO 27001 require more than checklists. They require a governable system in which measures are usable for people, work reliably in practice, create visible value for boards and customers, and are continuously measured and improved. The HarmonyQ triangle can serve as a practical thinking model: not to make compliance more complicated, but to prevent organisations from appearing compliant without actually being resilient.
The good news is that an almost missed target does not have to mean a failed project. In ITIL terms, improvement often begins with the simple but powerful question: where are we now? Not to look for someone to blame, but to look again at the risk model, the feasibility of the measures and the signals that were already visible along the way. What today feels like delay, resistance or project noise can become valuable input tomorrow: management that needs to steer more clearly, users who show where controls are too heavy, employees who know where processes break, suppliers who expose dependencies, and auditors who sharpen evidential requirements.
The art, therefore, is not to throw everything overboard, but to refine the model: reprioritise risks, make measures more proportionate, clarify ownership and strengthen the lifecycle. In this way, an almost missed deadline does not become proof of failure, but a learning moment before the real launch. NON-failure to launch then means: daring to return to the facts, learning from the almost-missed target and allowing the compliance project to restart with more realism, more cohesion and more governable resilience.
