How service management can help organisations strengthen cyber resilience, operational resilience, and regulatory readiness.

The EU is raising the bar for digital and operational resilience. Cyber threats are increasing, critical services are increasingly dependent on complex technology ecosystems, and regulators are putting greater pressure on organisations to demonstrate they can withstand, respond to, and recover from disruption. Two regulations are central to this shift: NIS2 and DORA.

NIS2 strengthens cybersecurity obligations across essential and important sectors. DORA introduces a dedicated digital operational resilience framework for the financial sector. Together, they make one thing clear: resilience can no longer sit in policy documents, risk registers, or disconnected spreadsheets. It needs to show up in how organisations manage services, incidents, suppliers, changes, evidence, and accountability every day.

The urgency is sharper in 2026. NIS2 entered into force in January 2023, with EU Member States required to transpose it into national law by 17 October 2024. DORA entered into application on 17 January 2025 for banks, insurers, investment firms, and other financial entities. These are no longer future deadlines. Organisations are now in the evidence, enforcement, and operational-readiness phase.

Why now?

For the past few years, many organisations treated NIS2 and DORA as future compliance programmes. That window has closed.

In 2026, the question is no longer “are these regulations coming?” It is “can you prove how your organisation manages resilience today?”

Regulators are looking for operational proof. They want to understand which services are critical, who owns them, what systems and suppliers support them, how incidents are managed, how risks are controlled, and how quickly the organisation can respond when disruption happens.

The urgency around third-party technology risk is also increasing. In November 2025, the European Supervisory Authorities designated the first critical ICT third-party providers under DORA, bringing major technology providers into direct EU-level oversight. This signals that regulators are not only focused on internal systems, but also on the external providers that support critical financial services.

Why you cannot ignore this in 2026

NIS2 and DORA are no longer theoretical regulations. They are active expectations.

For organisations in scope, the risk extends beyond financial penalties and regulatory action. The greater operational risk is the inability to prove control when disruption occurs.

If a regulator, auditor, board member, or executive asks which critical services are exposed, which suppliers are involved, what systems are affected, who owns remediation, and where the evidence sits, many teams still need to search across spreadsheets, tickets, documents, vendor records, and individual knowledge.

That creates delays at the exact moment speed and confidence matter most. In 2026, organisations need to move from compliance planning to operational proof. That means integrating cybersecurity, service management, risk management, supplier oversight, incident response, and evidence into a single working model.

What now?

The next step is not simply creating more documentation. It is making resilience visible in day-to-day operations.

Organisations need to identify critical services, map the systems and suppliers that support them, define ownership, link risks and vulnerabilities, standardise incident and change workflows, and capture evidence as work happens.

This is where service management can make compliance more practical.

ITSM practices help organisations standardise how incidents, changes, requests, assets, suppliers, risks, documentation, and evidence are managed. The right service management platform can connect regulatory expectations to the workflows teams already use.

With Jira Service Management, Atlassian Assets, Jira, Confluence, Rovo, and Teamwork Graph, organisations can connect services, assets, incidents, changes, suppliers, risks, documentation, and evidence into a more joined-up operating model. Atlassian describes Assets in Jira Service Management as a way to manage assets and configuration items, troubleshoot incidents, and reduce change risk; Teamwork Graph connects work, pages, service requests, projects, and data across Atlassian and other apps.

Incident management

Both NIS2 and DORA place strong emphasis on incident response and reporting. Organisations need clear processes for identifying, classifying, escalating, resolving, documenting, and reporting significant incidents.

Service management helps by creating consistent workflows for incident intake, ownership, prioritisation, escalation, communication, resolution, and post-incident review.

For example, when a major incident occurs, Jira Service Management can manage the incident workflow, Atlassian Assets can identify affected services and dependencies, and Confluence can hold supporting playbooks, documentation, and post-incident reviews.

This gives teams a clearer record of what happened, who acted, what decisions were made, and what remediation followed.

Risk management

NIS2 focuses heavily on cybersecurity risk management. DORA requires financial entities to manage ICT risk as part of operational resilience.

Service management helps make risk operational by connecting risks to services, assets, suppliers, vulnerabilities, incidents, and changes.

For example, if a vulnerability affects a critical application, teams can link the issue to the affected service, the service owner, remediation work, related change activity, and evidence of action.

This helps security, IT, risk, and compliance teams work from a shared operational view rather than separate registers and disconnected reports.

Change management

Changes to systems, infrastructure, and applications can create resilience risk. Under NIS2 and DORA, organisations need to show that technology changes are assessed, approved, implemented, and reviewed in a controlled way.

Service management helps teams assess the impact of change before work begins.

For example, before changing a firewall rule, server, application component, or cloud service, teams can use CMDB and dependency data to understand which services could be affected. If the change affects a critical service or a regulated process, the team can add additional approval, testing, timing, or rollback controls.

This turns change management from a process checkpoint into a resilience control.

Governance and accountability

NIS2 and DORA both raise expectations around governance. It is not enough for controls to exist in principle. Organisations need clear ownership, repeatable workflows, and evidence that responsibilities are being managed.

Service management helps by making ownership visible.

Services, assets, incidents, changes, suppliers, risks, and controls can be assigned to accountable owners, reviewed through workflows, and evidenced through audit trails.

For example, a critical service owner can be responsible for validating service data, reviewing dependencies, approving changes, and confirming that required documentation is up to date.

This helps show that governance is embedded in operational workflows, not just written in policy.

Third-party management

Third-party risk is one of the strongest links between NIS2 and DORA.

NIS2 includes supply chain security expectations. DORA places detailed obligations on ICT third-party risk management for financial entities. The 2025 designation of critical ICT third-party providers under DORA reinforces that supplier dependency is now a central resilience issue.

Service management can help by linking suppliers to the services, systems, applications, and contracts they support.

For example, a cloud provider, managed service provider, software vendor, or data platform can be connected to the applications, infrastructure, incidents, service owners, and critical functions it supports.

If that provider has an outage or control issue, teams can quickly identify affected services and owners.

This moves supplier risk from a static register into an operational view.

Evidence and audit readiness

In 2026, the strongest organisations will not wait for an audit to gather evidence. They will embed evidence into how work happens.

Service management can create an operational evidence layer by linking incidents, changes, approvals, service records, supplier relationships, recertifications, post-incident reviews, and control updates.

For example, instead of manually collecting screenshots and reconciling spreadsheets, teams can show governed records from Jira Service Management, linked assets from Atlassian Assets, and supporting documentation in Confluence.

This helps organisations move from reactive compliance to continuous readiness.

Employee awareness and training

Compliance also depends on people. NIS2 and DORA require stronger awareness, accountability, and operational discipline across teams.

Service management supports this by standardising how people work. Clear request types, workflows, knowledge articles, playbooks, templates, and escalation paths help teams consistently follow the right process.

For example, Confluence can hold incident playbooks, resilience procedures, supplier escalation guidance, and training materials. Jira Service Management can then connect those processes directly to live operational work.

This helps make compliance easier to follow, not just easier to document.

AI and automation readiness

AI is becoming part of service management, but AI is only useful if the data behind it is trusted.

For NIS2 and DORA, this matters because AI-generated summaries, reports, recommendations, or analyses need to be grounded in accurate service, asset, incident, supplier, and control data.

With governed service data in Jira Service Management and Atlassian Assets, teams can use Rovo and automation to support incident summaries, dependency analysis, knowledge article drafts, reporting packs, post incident review summaries, and operational recommendations. Atlassian positions Rovo and AI features in Jira Service Management to help service and operations teams use AI in their daily work.

The goal is not to replace human oversight. It is to reduce manual effort, improve consistency, and give teams a stronger starting point.

What organisations should do now?

In 2026, organisations should focus on practical steps that turn regulatory requirements into operational capability.

1. Start by identifying critical services and the systems, applications, assets, suppliers, and teams that support them.
2. Then define ownership, map dependencies, and connect those records to incident, change, request, risk, and supplier workflows.
3. Next, reduce evidence gaps. Look at where audit and regulatory evidence is currently gathered manually, then design workflows that capture evidence as work happens.
4. Finally, prepare for AI carefully. Before scaling AI-enabled service management, make sure the underlying service and asset data are governed, current, and trusted.

This is how organisations move from “we have a compliance plan” to “we can prove how resilience works.”

Are you ready for NIS2 and DORA in 2026?

NIS2 and DORA cannot be treated as one-off compliance projects. They are operating model changes.

They require organisations to understand critical services, manage cyber and ICT risk, evidence incident response, control technology change, oversee third parties, and maintain audit-ready proof.

Effective service management makes that practical.

Adaptavist has already helped financial services organisations navigate this journey, designing and implementing service management solutions using Jira Service Management, Atlassian Assets, Jira, Confluence, Rovo, and Teamwork Graph. We help FSI teams build the workflows, data models, governance processes, and evidence structures needed to support regulatory readiness and operational resilience.

In 2026, the organisations that act now will be better placed to respond to incidents, satisfy auditors, manage third-party risk, and prepare for AI-enabled service management.