NIS2 and DORA Are Service Management Problems Wearing a Regulatory Badge
# ITIL
# Service Management
# Governance
Most of what the two regulations demand, ITIL practitioners already know how to do. Knowledge was never the problem. Evidence, speed and ownership always were.
October 29, 2026
Panos Mastrogiannis
NIS2 and DORA Are Service Management Problems Wearing a Regulatory Badge
Most of what the two regulations demand, ITIL practitioners already know how to do. Knowledge was never the problem. Evidence, speed and ownership always were.
When NIS2 and DORA arrived, most organisations I know treated them the same way. A compliance programme. A gap analysis from a consultancy. A new set of policies, signed and filed.
Then the first real incident came. And the clock started.
That is the moment most organisations discover what these regulations are really about. Not policies. Operations. Who decides, how fast, on what evidence, and who answers for it afterwards.
Those are service management questions. We have been answering them for twenty years. We just never had a regulator holding the stopwatch.
The clock is the point
Start with the deadlines, because they change everything.
Under DORA, a financial entity that has a major ICT-related incident sends an initial notification within 4 hours of classifying it as major, and no later than 24 hours after becoming aware of it. An intermediate report follows within 72 hours of the initial notification, and a final report within a month of the latest intermediate report.
NIS2 sets a similar rhythm for significant incidents: an early warning within 24 hours of becoming aware, an incident notification within 72 hours, and a final report within one month.
Read those again and ask one question. Who in your organisation decides, at 02:00 on a Saturday, that an incident is major?
If the honest answer is "the compliance team, on Monday", you have an incident management problem with a deadline attached, not a regulatory one.
Strip the legal language and you find ITIL
I have taken both regulations apart requirement by requirement and almost every line maps to a practice we already run.
- Classify incidents consistently and fast. That is incident management, with classification criteria agreed before the outage, not argued during it.
- Explain the root cause in the final report. That is problem management, and it has to start while the incident is still open, not a month later when the report is due.
- Know your ICT assets and what depends on what. DORA asks financial entities to identify and classify their ICT assets and dependencies. That is service configuration management, and a CMDB that nobody trusts will not survive the first supervisory question.
- Control ICT change. That is change enablement, with evidence that each change was assessed, authorised and reviewed.
- Manage third-party risk and keep a register of every ICT provider arrangement. That is supplier management, extended to concentration risk and tested exit plans.
- Prove you can recover. That is service continuity and availability management, proven by exercises rather than documents.
- Learn and improve. That is continual improvement, with lessons that actually change something.
Not much new, is it? What is new is that a supervisor now checks it, on a deadline, and the management body is personally accountable for the outcome. Both regulations say so explicitly.
Where it actually breaks
I have spent most of my career in capital markets, payments and outsourced operations. In my experience the hard part is never the framework. Everybody has the framework. It breaks in three places.
1. Evidence
Many organisations do the right thing and cannot prove it.
The change was assessed, but the assessment lives in the head of one senior engineer. The supplier was reviewed, but the review was a meeting with no minutes. The DR test happened, but the report says "successful" and nothing else.
Regulators do not audit intentions. They audit records. If the evidence does not exist at the moment of the decision, recreating it afterwards is expensive, slow and not very convincing.
2. Speed
A 4-hour window does not leave time to discover who owns the decision.
Classification criteria, decision rights, the escalation path and the reporting template have to exist before the incident. And the on-call team has to have used them, in an exercise, at least once. A runbook that has never been rehearsed is a hypothesis.
I learned this in payments. An application froze. Operations recommended the obvious fix: restart the application, or reboot the machine. Nobody from development or the application team would agree to it. We spent 35 minutes negotiating on the call, until the head of development joined, took responsibility and said yes. The restart took less than a minute, and the service was back.
Thirty-five minutes of outage for a one-minute fix. The technology was never the problem. The decision right was. It sat with heads of department, so the incident waited until someone senior enough was on the call.
Afterwards we rewrote the runbooks for that type of failure and pushed the decision down to the shift-level roles. Similar cases stopped waiting. Under a 4-hour reporting clock, that change is the difference between reporting an incident and explaining why you couldn't.
3. Ownership
Both regulations put responsibility on the management body. In practice, ownership falls between three teams. IT operations runs the incident. Security investigates. Compliance writes the report. Each owns a piece; nobody owns the outcome. And the outcome is the only thing the regulator, or the customer, actually cares about.
That fragmentation is exactly what value-stream thinking was designed to fix. The regulatory report is not a compliance deliverable. It is the last step of a value stream that starts with detection and ends with a lesson learned. Somebody has to own the whole stream, not just their stage.
The supplier you forgot is still your incident
One area deserves its own section, because it is where I see the biggest surprises: third parties.
Modern services run on a chain of providers. Cloud, SaaS, managed security, payment processors, outsourced service desks. When one of them fails, the regulator does not care whose fault it was. The incident is yours, the clock is yours, and the report is yours.
Three questions usually expose the gap. Does your incident process include the supplier's incident, with agreed notification times in the contract? Can you see, for each critical service, which suppliers it depends on, including their subcontractors? And has anyone tested the exit plan, or does it exist only because the regulation asks for one?
I saw this when we changed our managed detection and response provider. We had an exit plan on paper. The real switch needed things it did not cover.
The contract was hard, but not the hardest part. That was the overlap: running two providers in parallel, and keeping 24/7 detection with no gap on the day we cut over. Who owns an alert the old provider raises an hour before the switch? Who answers if the new one has not finished tuning its detection rules? Those are the questions an exit plan has to answer, and ours had never been tested against them.
The lesson stayed with me: an exit plan you have never executed is an assumption. DORA expects exit strategies for providers supporting critical or important functions. Rehearse one before the day you need it.
My view as an ITIL Master: real governance versus governance theatre
I have worked inside organisations and watched many more from the outside. All of them have governance. Fewer have governance that works when it is needed.
Governance theatre looks convincing from the outside. A CAB that meets every Friday and approves everything on the list. A policy library that passed the audit. An exit plan that exists because the regulation asked for one. A major incident procedure where the decision still waits for the most senior person to join the call. Everything is documented, and nothing moves faster when it matters.
Real governance is quieter. Decision rights are written down and pushed to the people on shift. Thresholds are numbers, not adjectives. The exit plan has been rehearsed at least once. The board asks for evidence rather than reassurance.
NIS2 and DORA are the first regulations I have seen that can tell the two apart, because they measure governance against a clock. Theatre does not survive a 4-hour deadline. A tick in a checklist that says you comply will not protect you when the real incident hits. At the end of the day, you either convince the board that something has to change or you explain afterwards why the failure happened and what it cost. Trust me the second conversation is much harder. Choose your battles wisely.
ITIL has always pointed the right way: value, outcomes, decisions as close to the work as possible. The regulation simply removes the option of pretending.
Design compliance as an output, not a project
The organisations that cope best do not run NIS2 and DORA as a separate programme. They design their service management system so that compliance evidence is a by-product of normal work.
In practice, that looks like this:
- Incident records capture the classification criteria and the time of each decision, so the regulatory report is assembled from data, not written from memory.
- Change records hold the risk assessment and the authorisation, so the audit trail exists by default.
- The configuration data used for impact analysis is the same data that answers "which critical or important function did this affect?"
- Supplier reviews follow a fixed format and update the register of information automatically.
- Every major incident review ends with a decision log: what changes, who owns it, by when.
This is not a tooling argument. A good tool helps, but it will faithfully record bad decisions too. It is a design argument: decide what evidence each practice must leave behind, and make leaving it the easiest path for the people doing the work.
Do this properly, and something interesting happens. The regulation stops being a tax on operations and becomes a quality bar for them. The same evidence that satisfies the supervisor tells the board where the service is fragile.
Three questions to test your readiness this week
- Can your on-call lead classify an incident as major, using written criteria, without calling anyone?
- For your most critical service, can you list every ICT supplier it depends on, and say what happens if one of them fails tonight?
- Could you produce the evidence for your last ten significant changes in under an hour?
If any answer is no, start there. That is not a compliance gap. It is a service management gap with a deadline attached.
Over to you
What has been the hardest part of NIS2 or DORA for your service management teams: classification, evidence, suppliers, or ownership? I would like to hear where others found the friction, and what actually fixed it.
Sign in or Join the community
Where conversation, connection, and real-world practices come together.
Create an account
Where conversation, connection, and real-world practices come together.
Like
Comments (0)
Popular
Dive in
Related
Blog
How ITIL (Version 5) and AI Are Redefining the Service Desk
By Dr. Arun Singh • Feb 10th, 2026 • Views 230
Resource
June Community Clinic Recap: Service Management, AI, Problem Management, and More
Jun 11th, 2026 • Views 48
Blog
Beyond IT Service Management: ITIL as a Strategic Enabler of Data Governance and Management
By Yurguen Penaranda Th... • Jun 16th, 2026 • Views 60
Resource
June Community Clinic Recap: Service Management, AI, Problem Management, and More
Jun 11th, 2026 • Views 48
Blog
Beyond IT Service Management: ITIL as a Strategic Enabler of Data Governance and Management
By Yurguen Penaranda Th... • Jun 16th, 2026 • Views 60
Blog
How ITIL (Version 5) and AI Are Redefining the Service Desk
By Dr. Arun Singh • Feb 10th, 2026 • Views 230