Operational Resilience in 2026: What DORA and the FCA Now Expect From Your IT

For years, operational resilience in financial services was mostly a paperwork exercise. You wrote the policy, filed it, and moved on. That era is over.

In 2026 the regulators want proof. Not a document that says your systems are resilient, but evidence that they actually hold up when something goes wrong.The regulatory posture on DORA has shifted from remediation guidance to enforcement action, and the first wave of supervisory inspections is now showing firms exactly what examiners expect. The FCA, for its part, has made operational resilience a hard requirement rather than an aspiration.

If you run or advise a financial services firm, the practical question is simple. Can your IT actually demonstrate resilience, or do you just have a policy that claims it? For a lot of firms, there is an uncomfortable gap between the two.

First, does DORA even apply to you?

This is the single most misunderstood point, and getting it wrong costs money in one of two directions: either wasted effort on rules that do not apply, or a nasty surprise about ones that do.

DORA is an EU regulation. Here is the part that trips UK firms up. A UK firm falls under DORA only if it operates an EU-regulated entity, or provides IT services to EU financial entities. A purely UK firm serving only UK clients under FCA regulation is not directly caught by DORA.

But do not stop the analysis there, because that is the common mistake. DORA’s reach follows the entity, not the group. If your group has an EU branch, an EU subsidiary, or a UK arm that provides IT services to an EU-regulated client, those parts are in scope even if the parent is not. And a DORA problem at the EU-entity level can create trouble for the UK parent’s own relationship with the regulator.

So the first job is honest scoping. Work out, entity by entity, where DORA applies and where you sit under the UK’s own framework instead.

If you are a UK-only firm, you are not off the hook

Firms that fall outside DORA sometimes breathe a sigh of relief. They should not get too comfortable.

The FCA, the PRA and the Bank of England have their own operational resilience regime, and it became fully mandatory for FCA-regulated firms in March 2025. In plain terms, it requires you to identify your important business services, set the maximum tolerable level of disruption for each, and then prove you can stay within those limits even in a severe but plausible scenario.

The direction of travel is clear. UK regulators have signalled alignment with DORA’s principles, so in practice most UK financial firms are being held to a very similar standard whichever framework technically applies. The paperwork era is over on both sides of the Channel.

What the regulators actually want to see

Strip away the acronyms and the expectations come down to a handful of things your IT has to deliver. This is where a policy on a shelf meets the real world.

You stay within your impact tolerances

You need to know your important business services, and you need to know how long each can be down before real harm is done to customers or the market. Then you need the technical setup to actually keep within those windows: resilient infrastructure, tested recovery, and failover that works when you pull the plug on it rather than in theory.

You can recover, and you have proved it

Backups that have never been restored are not a recovery plan, they are a hope. Regulators increasingly want evidence that recovery has been tested, that it meets the timeframes you have committed to, and that someone owns the process. Testing your recovery once a year and documenting the result is no longer a nice-to-have.

You manage your third-party IT risk

This is where most firms have the most work to do. DORA requires that you remain accountable for resilience even when IT services are fully outsourced. You cannot contract your way out of the obligation. That means knowing who your critical IT suppliers are, understanding what happens if one of them fails, and having contracts that give you the audit rights, incident notification and exit arrangements the rules expect.

Concentration risk matters here too. If a single cloud provider, payment platform or IT partner underpins several of your important services, you need to have thought through, and documented, what you would do if it went dark for a few days.

You detect and report incidents quickly

Both frameworks expect fast, structured incident reporting. That is only possible if your systems are actually monitored, so problems are spotted early rather than discovered by a customer complaint. Continuous monitoring, clear escalation, and a tested incident process are the foundation.

Where financial firms most often fall short

Across the sector, the same weak spots come up again and again:

• Recovery that has never been genuinely tested. The plan exists. Nobody has pulled the plug to see if it works.
• A hazy picture of third-party risk. The firm knows its main suppliers but has not mapped the dependencies underneath, or checked whether the contracts meet the standard.
• Patchy monitoring. Alerts on some systems, blind spots on others, and no single view.
• Ageing infrastructure. Kit that is past its supported life quietly sitting under a critical service, which is exactly the sort of thing that fails at the worst moment and is hard to defend to a regulator.
• Security gaps. Inconsistent multi-factor authentication, weak identity controls, and manual processes for staff joining and leaving.

None of these are exotic. They are the everyday realities of a busy firm that has grown its IT over time without a resilience-first eye. The good news is that they are all fixable.

Turning the rules into a plan

You do not have to solve everything at once. A sensible order of work looks like this.

Start by scoping DORA properly, entity by entity, so you know which rules apply where. Then map your important business services and set an impact tolerance for each. From there, work through the technical gaps: test your recovery for real, map and document your third-party IT dependencies, close the monitoring blind spots, and fix the security basics like multi-factor authentication and identity controls.

Underneath all of it, deal with the ageing infrastructure. A resilience programme built on hardware that is out of support is building on sand. Where you have equipment that is past its manufacturer support date but still doing a job, third-party maintenance can keep it properly supported and defensible while you plan a longer-term refresh. That single step often closes a gap that would otherwise look bad in front of an examiner.

Why this is an IT partner question, not just a compliance one

Operational resilience sits awkwardly between the compliance team and the IT team. The compliance officer understands the obligation but not always the plumbing. The IT team understands the plumbing but is not always looking at it through a regulatory lens. The gap between them is where problems live.

That is the value of an IT partner who understands financial services specifically. Not a generalist who keeps the email running, but a team that can look at your infrastructure and tell you where it would fail a resilience test, then fix it. Euroland IT Services provides managed IT support for finance and financial services firms, covering resilient infrastructure, tested recovery, third-party risk, monitoring and the security controls the regulators now expect.

We also work with firms in other regulated and demanding sectors, so the same resilience thinking applies whether you are a financial services business, a healthcare organisation, or any business that simply cannot afford to be down. If your general IT support also needs strengthening, our managed IT support in London covers the day-to-day alongside the resilience work.

The bottom line

The regulators have stopped accepting policies as proof. In 2026, resilience means showing your systems hold up, your recovery works, your suppliers are managed, and your incidents are caught early. DORA enforcement has arrived, the FCA regime is live, and the standard on both sides is now evidence rather than intent.

The firms that treat this as a genuine IT programme, rather than a document to refresh once a year, are the ones that will handle the next disruption well and have the paper trail to prove they were ready.

Request a free operational resilience and third-party IT risk review for your firm. We will show you where your infrastructure would struggle against the current expectations, and what to do about it. Call us or request a callback.

Frequently Asked Questions

Q1: Does DORA apply to UK financial services firms?

A: Only if the firm operates an EU-regulated entity or provides IT services to EU financial entities. A purely UK firm serving UK clients under FCA regulation is not directly in scope of DORA, but is covered by the UK’s own operational resilience framework, which sets a similar standard.

Q2: What is the difference between DORA and the FCA’s operational resilience rules?

A: DORA is an EU regulation with detailed, prescriptive requirements. The FCA, PRA and Bank of England run the UK’s own regime, which became mandatory in March 2025 and is more principles-based. UK regulators have signalled alignment with DORA’s principles, so firms are often held to a comparable standard either way.

Q3: What are impact tolerances?

A: An impact tolerance is the maximum level of disruption an important business service can take before it causes real harm to customers or the market. You have to set one for each important service and then prove your systems can stay within it during a severe but plausible scenario.

Q4: Are we responsible for our IT if we outsource it?

A: Yes. Both DORA and the UK framework are clear that you remain accountable for resilience even when IT services are fully outsourced. You need to know your critical suppliers, understand the risk if one fails, and have contracts that meet the regulatory expectations.

Q5: How do we prove our recovery actually works?

A: By testing it. That means genuinely restoring from backup and failing over to recovery systems, checking it meets your committed timeframes, and documenting the result. A backup that has never been restored does not count as a tested recovery plan.

Q6: Can ageing hardware be a compliance problem?

A: It can. Running critical services on infrastructure that is past its manufacturer support life is hard to defend in a resilience review. Third-party maintenance can keep that equipment properly supported while you plan a refresh, which removes the immediate risk.

Q7: Where should a firm start if it is behind on this?

A: Start with honest scoping to work out which rules apply, then map your important business services and set impact tolerances. From there, test your recovery, map your third-party dependencies, close monitoring gaps and fix the security basics. An IT partner who knows financial services can run this alongside your compliance team.