DORA Is Already in Force: What Swedish Financial Entities Actually Have to Prove

You have probably seen the message doing the rounds: DORA is live, every financial entity needs a fully tested incident response plan today, and regulators are moving in on anyone who is not ready. Part of that is accurate. Part of it overstates the case in ways that could leave a CISO chasing the wrong deadline. Here is what is actually true, what Finansinspektionen expects, and what to fix first.

What is DORA and When Did It Actually Take Effect?

The Digital Operational Resilience Act is an EU regulation that requires banks, insurers, investment firms and other financial entities, together with the ICT providers they rely on, to manage technology risk, test their resilience and report major incidents through one harmonised framework across the European Union.

DORA entered into application on 17 January 2025, so the trigger claim is right that it is already in force. It is a regulation rather than a directive, which means its core rules apply directly in every member state without needing to be transposed into national law first. Sweden still passed a supplementary act, Lag (2024:1278), which took effect the same day and gave Finansinspektionen its supervisory and sanctioning powers under the regulation.

DORA rests on six pillars. ICT risk management sets the baseline framework and governance. ICT third-party risk management covers vendor monitoring and contract terms. Digital operational resilience testing covers everything from basic vulnerability scans to advanced threat-led penetration tests. ICT-related incident rules cover detection, handling and reporting. Information sharing lets entities exchange threat intelligence. Oversight of critical ICT third-party providers gives EU supervisors a direct line into a small number of hyperscale cloud and technology firms that much of the sector depends on.

Where the trigger claim overstates things is the idea of a single test everyone has to clear today. There is no one universal deadline for a fully tested incident response plan. Basic resilience testing, including scenario-based exercises, runs on an annual cycle for every in-scope entity. Full threat-led penetration testing, the closest thing to a live-fire test of incident response, only applies to entities that Finansinspektionen specifically designates, and only on the cycle it sets, roughly every three years.

Who Must Comply With DORA?

DORA’s scope runs wider than most people assume. It applies to 20 different types of financial entities, from the obvious ones, credit institutions, insurers and investment firms, to less obvious ones such as crypto-asset service providers, crowdfunding platforms, credit rating agencies and pension schemes above a certain size.

The regulation applies the same principles to every entity but scales the detail by size and complexity. Smaller and less complex firms get a proportionate, lighter version of the ICT risk management requirements rather than a full exemption.

It is also worth remembering that DORA reaches your ICT providers directly, not just your own organisation. A cloud, hosting or software vendor that supports a critical function can be pulled into your contractual DORA obligations, and the largest of these providers can be designated as critical and placed under direct EU-level oversight.

What To Do Now Versus What Stays Ongoing

Because DORA has already applied for over a year, the practical starting point for a Swedish CISO is not a fresh implementation project but a gap check against obligations that are meant to be running already, then a plan for the ones that repeat every year.

The Register of Information, DORA’s inventory of every ICT contractual arrangement, is submitted annually and is consistently the requirement institutions report finding hardest to keep accurate and complete. Incident classification and the reporting clock are not one-time setup tasks either. They have to work correctly every time a real incident hits, which is why tabletop exercises against the actual reporting deadlines are worth running well before a live incident forces the issue.

The Attack Types DORA Is Actually Built to Address

DORA’s requirements are not written for their own sake. They map onto how the finance sector is actually attacked and disrupted. ENISA’s own finance-sector threat landscape reporting found finance to be the third most targeted sector in the incidents it collected, behind only public administration and transport, which is exactly the kind of concentrated exposure DORA’s risk management and testing pillars are aimed at.

Three risk patterns sit behind most of the regulation’s detail. ICT third-party concentration risk is the reason a handful of large cloud and technology providers now face direct EU oversight. A large share of the sector now leans on a small number of providers, so a single provider failing or being compromised can ripple across many institutions at once.

Operational disruption, including ransomware and denial-of-service activity aimed at knocking services offline rather than just stealing data, is the reason DORA leans so heavily on incident detection, classification and rapid reporting. Supply-chain and third-party compromise, where an attacker reaches a bank through a vendor rather than through the bank’s own perimeter, is the reason contractual detail on ICT providers is not optional paperwork.

What Happens if You Do Not Comply

This is where the trigger claim’s framing of immediate regulatory action needs the most correction. Unlike NIS2 or GDPR, DORA does not set one fixed EU-wide fine band for ordinary financial entities. Article 50 leaves the actual administrative penalty amounts to each member state, so the figure often repeated in marketing, up to 2% of global turnover, is a commonly cited industry aggregate rather than a single number written into the Regulation itself for every entity.

In Sweden, the picture is more specific still. The supplementary act sets fixed sanction bands only for a defined list of entity types, including crypto-asset service providers, pension foundations, benchmark administrators and crowdfunding platforms, capped at the higher of the SEK equivalent of EUR 1 million, 10% of the entity’s prior-year turnover, or three times any profit gained.

Banks, insurers and most other financial entities are instead sanctioned under their own existing sectoral legislation, which Finansinspektionen also enforces, and which can carry comparably significant fines. Individuals in a management role can face a sanction fee or a ban of three to ten years from serving as a board member or chief executive at the entities the fixed regime covers.

Critical ICT third-party providers sit under a separate, genuinely EU-level regime, with periodic penalty payments of up to 1% of average daily worldwide turnover for as long as six months of continued non-compliance. And 2025 itself was broadly treated by supervisors as a dialogue and gap-remediation year rather than an enforcement one, with several 2026 sources describing active enforcement as only now ramping up.

Swedish law also lets Finansinspektionen waive action entirely for a minor breach or one an entity corrects quickly, which is a long way from the immediate action the trigger implies.

How To Build Compliance That Actually Holds Up

The organisations that hold up under both a Finansinspektionen review and a real incident tend to treat DORA as a running operating model rather than a folder assembled once a year. Four things carry most of the weight in practice.

Keep the Register of Information current continuously rather than reconstructing it before each annual deadline. Run incident classification drills against the real 4-hour and 24-hour clocks, not just the 72-hour and one-month reports that feel less urgent.

Treat ICT third-party contracts, especially with any provider that could be designated critical, as living documents that get reviewed on a schedule. And keep the management body genuinely trained and accountable, since DORA’s governance expectations, and Sweden’s personal liability provisions, both assume the board understands what it is signing off on.

eBuilder Security supports Swedish financial entities working through these obligations, from ICT risk assessments through to incident detection and response and third-party risk reviews. Where any specific service claim needs sign-off against our verified claims register before publication, that is flagged in the accompanying QA note rather than asserted here.

Conclusion

DORA is real, it has been in force since January 2025, and Finansinspektionen does have teeth. What is not accurate is the idea of a single fully tested plan due today or an EU-wide fine everyone faces the moment they slip. The actual obligations are ongoing, tiered by entity type, and enforced partly through Sweden’s own sectoral laws rather than one universal band. Treat DORA as a standing operating requirement, keep the Register of Information honest, and rehearse the reporting clock before an incident forces you to learn it live.

Frequently Asked Questions

Is DORA a new deadline coming up, or is it already law?

It is already law. DORA has applied across the EU since 17 January 2025. There is no separate DORA start date still ahead, though testing cycles, annual Register of Information submissions and supervisory reviews continue on an ongoing basis through 2026 and beyond.

Does every financial entity have to run threat-led penetration testing?

No. Basic resilience testing runs annually for every in-scope entity, but full threat-led penetration testing (TLPT) only applies to entities Finansinspektionen specifically designates, based on criteria such as size and ICT risk profile, on a cycle of roughly three years.

What fine could a Swedish bank actually face under DORA?

It depends on entity type. A small list of entities face fixed bands under Sweden’s DORA supplementary act, up to the higher of about EUR 1 million, 10% of turnover, or three times any profit gained. Banks and insurers are instead sanctioned under their own existing sectoral financial laws, which Finansinspektionen also enforces.

How fast do we actually have to report a major ICT incident?

Within 4 hours of classifying an incident as major, and no later than 24 hours after first detecting it, financial entities must send an initial notification. An intermediate report follows within 72 hours, and a final report within one month.