We’re in September 2026, and something might put your shiny AI Roadmap to pause…: NIS2
Clock is ticking and everyone is late. Customers who a year ago were focused on their AI Roadmap or their next ServiceNow upgrade are now asking a different question:
"Can we prove, in writing, that we would detect and report a serious cyber incident within 24 hours?".
For a growing number of customers across energy, transport, healthcare, manufacturing, digital infrastructure and public administration, this is not an out of the blue question. It’s a legal obligation, with fines and PERSONAL liability for directors attached to it.
This article looks at what NIS2 actually requires, why it lands so directly on the ServiceNow platform, and what realistic, well-sequenced response looks like. It follows the same logic as our CSDM v5 article a few weeks ago: regulation, like AI, is only as strong as the operational foundation underneath it.
What is a NIS2 readiness assessment?
NIS2 compliance means having the appropriate cybersecurity risk-management measures, incident reporting processes, supply-chain controls and governance in place to meet the requirements of the EU’s NIS2 Directive.
For organizations already using ServiceNow, assessing NIS2 readiness does not necessarily mean introducing another platform. It can mean understanding whether the ServiceNow capabilities, workflows and data foundation already in place can support the requirements — and identifying the gaps that need to be addressed.
What NIS2 actually changes
The NIS2 Directive (EU 2022/2555) is the EU’s update to its 2016 cybersecurity baseline. It widens the net considerably: 18 sectors are now in scope, from the traditional energy, transport, banking, health and digital infrastructure, to newer additions such as public electronic communications, waste and wastewater management, critical manufacturing, postal and courier services, public administration, and space. Organizations fall into two tiers: essential entities and important entities, each with its own (steep) risk management and reporting obligations.
One quick scope note, since it comes up often: if you are a bank, insurer, investment firm or other financial entity, DORA (the Digital Operational Resilience Act) is your primary obligation, not NIS2. DORA is lex specialis and takes precedence for financial entities wherever the two overlap; NIS2 still applies to whatever DORA does not cover, but financial-sector readers should anchor their compliance programme on DORA first.
Key NIS2 compliance facts to know:
A few facts worth having on hand the next time this comes up in a steering committee:
- Deadline already passed. Member States were meant to transpose NIS2 into national law by October 17th 2024. As of today, 21 of the 27 Member States have done so; The rest, including France, Spain and Ireland, are still working through draft legislation. That gap does not mean the obligation is optional. It means the compliance clock and the exact national rules vary by country, which is exactly the kind of ambiguity that catches multinational ServiceNow customers out.
- The fines are real money. Up to €10 million or 2% of global annual turnover for essential entities, and up to €7 million or 1.4% for important entities, whichever is higher in each case.
- It is personal for leadership. Article 20 makes management bodies directly accountable. Non-compliance can mean temporary bans from management roles and personal liability, not just a corporate fine. That single clause is why NIS2 now sits on board agendas rather than only in the security team’s backlog.
- The reporting clock is unforgiving. An early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within one month. Meeting that timeline depends entirely on knowing, in the moment, what was actually affected, which is a platform and data question, not just a security-team question.
NIS2 incident reporting timeline
Why this lands directly on ServiceNow
NIS2 asks every in-scope organisation to do four things well:
- Know what it has,
- Manage risk against it continuously,
- Detect and report incidents fast
- Control the risk introduced by its suppliers.
Those are exactly the four questions a well-run ServiceNow platform should be able to answer. For customers who run ITSM, ITOM, Security Operations and GRC on ServiceNow, NIS2 compliance is not a new tool to buy. It is a configuration and data-quality exercise on a platform they already own.
Here is how the obligations map onto the products most of our customers already run, or should be running:
Article 21 risk-management measures → Risk and Compliance (IRM).
ServiceNow’s risk and compliance workflows turn NIS2’s ten minimum security measures into tracked controls with owners, evidence and continuous monitoring, instead of a spreadsheet that gets updated once a year before an audit. ServiceNow’s newly announced Cyber Risk and Compliance capability pushes this further, moving control evaluation from periodic review to continuous, automated monitoring.
24h / 72h / 1-month reporting → Security Incident Response.
SIR gives you the workflow, timers and audit trail to demonstrate that a significant incident was triaged, escalated and reported on time. Also it can just prove it after the fact. ServiceNow’s Agentic Incident Response direction (part of the Autonomous Security announcement) is aimed at compressing the time between detection and the first regulatory clock starting.
Vulnerability management → Vulnerability Response.
NIS2 expects a documented, risk-based approach to vulnerability handling, not best efforts. VR gives you the prioritisation and remediation workflow that regulators will ask to see evidence of.
Supply chain security → Third-Party (Vendor) Risk Management.
NIS2 explicitly extends accountability to your suppliers and service providers. If you cannot show how a critical vendor is assessed, monitored and re-assessed, you have a gap.
Knowing what was actually affected → CMDB and CSDM.
This is the one people underestimate.
Every one of the obligations above depends on being able to answer, quickly and confidently, “which Business Services, applications and data does this incident touch?”.
If your CMDB is unreliable, your 24-hour clock starts with your team trying to work out what broke before they can even start assessing severity.
For a deeper look at why this foundation matters, see our CSDM v5: The Foundation That Matters More Than Your Next AI Initiative.
We said it about AI a few weeks ago and it is equally true here: a risk and incident-response programme built on a weak data model is a penthouse on a sand beach.
Aloha has also worked on CSDM adoption and CMDB clean-up for a global biopharmaceutical company, addressing the kind of data foundation and service-awareness challenges that become critical when incident impact needs to be understood quickly.
How NIS2 Compliance Maps to ServiceNow
For organizations that already use ServiceNow, NIS2 readiness can be assessed against the capabilities they already have across risk, security, vulnerability, third-party management and the underlying CMDB and CSDM foundation.
The question is not simply whether a ServiceNow module is available. It is whether the platform is configured, connected and supported by sufficiently reliable data to provide the evidence and workflows required when a significant incident occurs.
| NIS2 requirement | ServiceNow capability | What it supports |
|---|---|---|
| Risk-management measures Article 21 security and risk-management measures | Risk and Compliance (IRM) | Tracked controls with owners, evidence and continuous monitoring. |
| 24h / 72h / 1-month incident reporting Early warning, fuller notification and final report | Security Incident Response | Workflows, timers, escalation and an audit trail to demonstrate that significant incidents were handled and reported on time. |
| Vulnerability management Documented, risk-based vulnerability handling | Vulnerability Response | Risk-based prioritisation and remediation workflows with evidence of how vulnerabilities are handled. |
| Supply chain security Assessment and monitoring of suppliers and service providers | Third-Party Risk Management | Supplier assessment, monitoring and reassessment — particularly for critical vendors. |
| Understanding incident impact Knowing which services, applications and data are affected | CMDB & CSDM | Identifying affected Business Services, applications and data quickly enough to assess severity and respond. |
What Does a NIS2 Readiness Assessment Involve?
A NIS2 readiness assessment helps organizations understand where their current processes, ServiceNow capabilities and data foundation stand against the requirements they need to support.
For ServiceNow customers, the assessment can help identify whether gaps sit in areas such as CMDB and CSDM, incident response, vulnerability management, risk and compliance, or third-party risk. The objective is not simply to produce another compliance checklist, but to establish where the most relevant operational gaps are and what should be addressed first.
What a realistic NIS2 readiness programme looks like
When a customer reaches out for a NIS2 engagement, usually a scoping and gap assessment has been performed, assessing their current state against the Article 21 minimum measures. And Gaps were found…
This is where we start our NIS2 readiness programme:
- Foundation check. Validate that CMDB/CSDM ownership and mappings are trustworthy enough to support incident impact analysis. We’re talking about the same foundation work we described in our CSDM v5 article, viewed through a compliance lens.
- Incident response readiness. Configure or tune Security Incident Response and Vulnerability Response workflows against the 24h/72h/1-month reporting timeline, including the escalation paths and evidence trail regulators will expect to see.
- Risk and third-party controls. Stand up or mature Risk and Compliance workflows for the ten minimum security measures, and bring supplier and vendor risk into a structured, repeatable process.
- Governance and evidence. Dashboards and audit reports that let you demonstrate compliance on demand, not reconstruct it under pressure during an incident or an audit.
As with CSDM, this is not a one-off project. NIS2 compliance is a steady-state discipline: new suppliers appear, incident procedures need rehearsing, and national transpositions will keep evolving through 2026 as the Commission’s simplification proposals work their way through the legislative process.
Is Your ServiceNow Environment Ready for NIS2?
NIS2 compliance is not only about having the right policies in place. When an incident happens, you need to know what is affected, how serious the risk is, who needs to act, what evidence exists and whether you can report it within the required timeframe.
For organisations already running ServiceNow, the first step may not be another implementation. It may simply be understanding how ready the platform you already have really is.
Aloha Clouds can help you assess your current state, identify the gaps across your data foundation, incident response, risk and third-party processes, and define what needs to happen next.
Can you answer those questions today?
100% of our team is certified in ServiceNow Data Foundations (CMDB & CSDM).
Enjoyed this Perspective?
If this article was useful, you’ll probably enjoy ALOHA Perspectives — our monthly newsletter featuring insights from our ServiceNow experts.
No spam. Just ideas worth your time.
Lilian Mével
