Summary: The first aggregated incident data reported under DORA gives an interesting picture of what actually causes serious ICT disruptions in the financial sector. System and process failures and external events account for the majority of incidents, while cyber-related incidents make up a considerably smaller share. For Swedish firms, Finansinspektionen also sees a clear link to third-party providers. That says something important about how operational resilience needs to be built in practice.

In July 2026, Finansinspektionen (the Swedish FSA) published a summary of the first joint European report on major ICT-related incidents under DORA.

The report is based on incidents that occurred during 2025 and were reported by financial firms within the EU.

A total of 3,383 major ICT-related incidents were reported. About a third had cross-border impact. At the same time, only around 10 percent of the reported incidents were cyber-related.

That does not, of course, mean cyber threats have become less important.

But it shows that an organisation’s digital resilience needs to cover considerably more than protection against external attackers.

System and process failures are behind many incidents

Finansinspektionen notes that failures in systems and processes, together with external events, account for the vast majority of the reported ICT incidents.

The same pattern is seen in Sweden. FI states that internal system and process failures are the most common causes among Swedish firms too. Cyber-related incidents occur, but make up a smaller share of the cases.

It is an important reminder.

A business-critical disruption does not have to start with ransomware or an advanced intrusion. It can start with:

a faulty system change
a configuration error
a process that did not work as intended
an integration that stops working
capacity problems
a failed maintenance operation
a dependency on an external service that disappears

The consequence for the business can still be the same: a critical service can no longer be delivered.

This means that work on information security and operational resilience needs to cover both deliberate attacks and ordinary operational failures.

Change management is also a security issue

When internal system and process failures recur among the causes of serious incidents, change management becomes an important part of the security work.

The organisation needs to ask not only “Is the change technically possible?” but also “What happens to the business if the change goes wrong?”.

For larger or business-critical changes, there should be clear answers to, for example:

which services can be affected
which dependencies exist
which tests are to be carried out
which controls are required before going into production
what rollback plan exists
who decides to abort
how the business is informed
how deviations are caught after the change

A well-functioning change process is therefore not only a matter of stable IT operations. It is part of the organisation’s risk management.

Third-party dependencies show clearly in the Swedish incident picture

Another interesting observation from Finansinspektionen is that a significant share of the Swedish incidents are linked to a third-party provider.

That is hardly surprising.

Financial firms – like many other organisations – today depend on cloud services, SaaS platforms, operations providers, network operators, payment infrastructure, security services and other external actors.

The problem is that an organisation can outsource a service. The risk and the business dependency, however, cannot be outsourced in the same way.

That is why third-party management needs to cover more than the security review before signing a contract.

For critical suppliers, the organisation needs to understand over time:

which service the business actually depends on
what impact a longer outage would have
which subcontractors exist
which incidents and major changes occur
what the supplier’s continuity and recovery capability looks like
which escalation paths apply
what contractual rights the organisation has
how the service can be replaced or wound down

DORA sets explicit requirements on managing ICT third-party risk, and FI highlights that both internal weaknesses and external dependencies need to be handled more systematically to strengthen the financial sector’s operational resilience.

A supplier incident is still your incident

A practical consequence is that suppliers need to be a natural part of the organisation’s incident handling.

If a critical SaaS service disappears for twelve hours, it matters less to the business whether the root cause is in your own server room or at an external supplier. The service still does not work.

Incident triage therefore needs to ask questions early such as:

Is a supplier affected?
Are we dependent on the supplier to understand or resolve the incident?
Does the continuity plan need to be activated before the supplier has solved its problem?
Do we have our own regulatory reporting requirements even if the fault lies with a third party?
When do management, customers or other stakeholders need to be informed?

It is one of the reasons why incident handling, third-party risk and continuity planning need to be connected.

Cross-border incidents show how the dependencies connect

The European supervisory authorities’ report also shows that about a third of the 3,383 major incidents had cross-border impact. The authorities point to shared infrastructure and shared services as an explanation for the increased interconnection.

This illustrates another important part of modern ICT risk.

An incident does not have to be particularly large at a single supplier to have a large aggregate effect if many organisations depend on the same service. This applies not least to:

cloud platforms
identity services
telecommunications
payment infrastructure
central SaaS services
operations and security providers

The risk analysis therefore needs to assess not only the supplier as such. It also needs to look at concentration risk and shared dependencies:

How many critical processes depend on the same supplier?
Are there alternative solutions?
How quickly can the organisation switch ways of working?
What happens if both the organisation and its supplier need to recover at the same time?

Cyber threats are still important – but resilience is broader

The fact that only around 10 percent of the reported major incidents were classified as cyber-related should not be interpreted as meaning cyber risk is small.

On the contrary, the European supervisory authorities emphasise a continued need for strong cybersecurity and also point to the development of increasingly capable AI-based tools as a factor to watch.

But the incident data shows why the concept of digital operational resilience is broader than cybersecurity. The organisation needs to be able to:

prevent disruptions
detect them
limit the consequences
continue critical operations
restore services

Regardless of whether the root cause is an attacker, a human mistake, a technical component or a supplier.

Five questions organisations should ask after the report

FI’s summary gives reason to check a few practical things.

1. Do we know which failures actually cause our incidents?

Not just the security incidents. Operational disruptions, change failures, capacity problems, process shortcomings and supplier incidents should also feed information back into the risk work.

2. Do we follow up critical suppliers after the contract is signed?

Due diligence at onboarding is not enough for a supplier the business depends on every day. The risk picture needs to be followed throughout the lifecycle.

3. Are our continuity plans built for supplier failure?

Many continuity plans still assume problems in the organisation’s own infrastructure. But what does the business do if the critical cloud or SaaS service is gone for two days?

4. Do we know we can recover – or do we only know we have backup?

A backup that has never been restore-tested provides limited assurance. Recovery needs to be tested against the business’s actual needs and dependencies.

5. Do we learn systematically from incidents?

When the incident is resolved, another important task begins:

What was the root cause?
Which controls worked – and which did not?
Which risk assessments need to be updated?
Does the same weakness exist elsewhere?
What does management need to know?

Incident handling becomes considerably more valuable when the experience is fed back into the organisation’s risk, supplier, continuity and change work.

DORA is about the capability when something actually goes wrong

DORA sets requirements on, among other things, ICT risk management, testing of digital operational resilience, management of third-party risk and reporting of major ICT-related incidents.

The first aggregated incident report now provides data on why the whole is needed. Systems can fail. Processes can break. Suppliers can run into problems. Cyberattacks can occur. And the same business-critical service can depend on all four.

For us, therefore, one of the most important conclusions from the report is: operational resilience is not only about reducing the likelihood of an incident. It is at least as much about the organisation’s ability to understand what is happening, limit the consequences, keep the business going and recover once the incident has already occurred.

How Kristensson i Skåne can support the work

Kristensson i Skåne helps organisations in regulated sectors with both governance and practical implementation within information security, risk, continuity and regulatory compliance.

The support can, for example, include:

current-state and gap analyses against DORA
ICT and information security risks
third-party risk and supplier reviews
continuity and recovery planning
incident processes and incident triage
testing and exercises
review of security measures and controls
management reporting and decision support
follow-up after incidents
ongoing GRC or CISO support

Our starting point is that the work should function in everyday life – and when everyday life suddenly does not work. That is when operational resilience becomes an actual capability and not just a regulatory requirement.

Would you like to know how your operational resilience holds up against DORA’s requirements? Read more about our work with information security and governance or contact us and we will have a first conversation about your current state and next steps.

Source and further reading: Finansinspektionen’s summary Report on major ICT-related incidents under the DORA Regulation (published 3 July 2026, in Swedish), and the European supervisory authorities’ first joint annual report on major ICT-related incidents under DORA.

This is a general description and not legal advice. Every organisation needs to assess its requirements, risks and dependencies based on its own operations.