Digital Operational Resilience Act (DORA) compliance is mandatory as of January 17, 2025. For 2026, the focus shifts from initial implementation to continuous supervision and enforcement. Financial entities must maintain a risk management framework, report major incidents within 24 hours, conduct annual resilience testing, and manage third-party risk via a formal Register of Information (RoI).

What is DORA?

The Digital Operational Resilience Act (Regulation EU 2022/2554), commonly known as DORA, is a landmark EU regulation designed to strengthen the IT security of financial entities. Unlike previous guidelines, which were fragmented across sectors and countries, DORA provides a single, harmonized rulebook for digital resilience.

Its primary goal is to ensure that the European financial sector remains resilient in the face of severe operational disruptions, such as cyberattacks, system failures, or third-party outages.

Who is in scope?

DORA applies to over 22,000 entities across the EU and their global ICT providers, including the following:

• Core financial entities: Banks, credit institutions, and payment providers.
• Investment & insurance: Investment firms, insurance undertakings, and intermediaries.
• Modern finance: Crypto-asset service providers and crowdfunding platforms.
• The supply chain: Critical ICT third-party providers (including cloud service providers and software vendors) who serve the financial sector.

Why DORA compliance is the 2026 "North Star" for financial risk

DORA is no longer a "future project". We are now over a year into the enforcement era. EU competent authorities (NCAs) are actively auditing implementations, specifically looking for evidence of operational continuity rather than just "paper compliance".

DORA establishes uniform, enforceable resilience standards across 22,000+ entities, including banks, insurers, crypto-asset providers, and their critical ICT third-party providers. If you operate or serve clients in the EU, DORA is your primary regulatory hurdle.

The DORA compliance checklist: The five pillars of resilience

DORA organizes its requirements into five distinct pillars. Use the checklists below to audit your current posture against the specific Articles and Regulatory Technical Standards (RTS).

Pillar 1: How to build a DORA-compliant ICT risk framework (Articles 5-16)

Board-level accountability is the cornerstone of Pillar 1. Article 5 dictates that the management body, not just the CISO, owns the risk.

• Board accountability: Management has approved and actively oversees the ICT risk framework.
• Dynamic asset inventory: A continuously updated register of all hardware, software, and services, classified by criticality.
• Zero-trust principles: Network segmentation, identity management, and rapid patch cycles are documented and enforced.
• Verified recovery: An ICT disaster recovery plan exists with defined RTOs/RPOs, tested and updated within the last 12 months.
• Automated backups: Backup procedures are isolated from primary production environments to prevent ransomware lateral movement.

Pillar 2: Managing ICT incident reporting timelines (Articles 17–23)

In 2026, "major" incidents require a strict three-stage reporting cadence to your National Competent Authority (NCA):

1. Initial notification: Within 4 hours of classification (max 24 hours from detection).
2. Intermediate report: Within 72 hours.
3. Final report: Within one month.

• Classification logic: Incident management tools are configured with DORA RTS criteria (client impact, data loss, geographic spread).
• Automated escalation: Workflows trigger immediate alerts to the legal and compliance teams when "Major" thresholds are hit.
• Centralized logging: All incidents (even minor ones) are logged in an auditable record for year-end trend analysis.

Pillar 3: Executing digital operational resilience testing (Articles 24–27)

Standard pentesting is no longer sufficient for systemically important institutions (G-SIIs, O-SIIs, etc.).

• Annual testing: All critical ICT systems undergo vulnerability assessments at least once a year.
• TLPT readiness: If in scope for Threat-Led Penetration Testing (TLPT), a TIBER-EU certified test is scheduled every 3 years.
• Supply chain scanning: Open-source packages and container images are scanned for CVEs before they reach production.

Pillar 4: Mitigating ICT third-party risk (Articles 28–44)

This is the most common area for audit findings in 2026. Article 28 requires a RoI of all third-party ICT arrangements in a specific EBA-compliant format.

• EBA-compliant RoI: A full register of ICT vendors exists and has been submitted to the NCA via the 2026 reporting portals.
• Article 30 contract clauses: All vendor contracts include mandatory provisions on data locations, audit rights, and exit strategies.
• Sub-vendor visibility: Compliance extends to "material subcontractors" (the fourth party) providing critical functions.
• Software Bill of Materials implementation: A SBOM (SPDX or CycloneDX) is generated for all proprietary and third-party software.

Pillar 5: Voluntary information and intelligence sharing (Articles 45–49)

While Article 45 is voluntary, regulators view active participation in Information Sharing and Analysis Centers (ISACs) as a sign of high operational maturity.

• ISAC engagement: The organization participates in a sector-specific threat-sharing community.
• Internal intelligence loops: Threat indicators received from external partners are automatically ingested into SOC workflows.

The "Invisible" gap: Software supply chain provenance

Pillar 4 often reveals a blind spot: the software supply chain. Every open-source package or container image pulled from a public registry is a "third-party ICT dependency." Under Articles 8 and 30, you must know what is in your software and prove its integrity. This is where software provenance, knowing exactly where code came from and who touched it, becomes a regulatory requirement.

How Cloudsmith automates DORA compliance

Cloudsmith provides a specialized, cloud-native artifact management platform that serves as the foundation for software supply chain security and DORA alignment. By acting as a centralized "source of truth", Cloudsmith enables financial institutions to move away from fragmented, manual processes toward a unified DevSecOps environment where compliance is baked into the development lifecycle.

The platform ensures continuous identification, tracking, and management of every software component, whether proprietary code or a third-party open-source dependency. Through automated, configurable policy gates, Cloudsmith enables organizations to define strict quarantine rules that align with DORA’s risk-reduction intent, effectively blocking vulnerable or malicious packages before they ever enter the build environment. This proactive stance on software provenance directly supports the ICT asset inventory requirements of Article 8 and the testing obligations of Article 25.

Furthermore, Cloudsmith simplifies one of DORA’s most challenging documentation hurdles: the SBOM. The platform automates SBOM generation in industry-standard formats such as CycloneDX, providing security and compliance teams with a granular, real-time inventory of what is slated for production. Because every action within the platform is captured in an immutable, exportable audit log, Cloudsmith transforms compliance from a stressful manual scramble into a simple, on-demand report for regulators. By breaking down the silos between DevOps, security, and risk teams, Cloudsmith ensures that digital operational resilience is a continuous, automated state rather than a point-in-time exercise.

Next steps for your compliance team

DORA is a continuous operational commitment, not a one-time project. The checklist above gives you a structured view of every pillar, but the harder work is keeping those controls current: live asset inventories, continuous supply chain scanning, SBOMs for every release, and audit trails that hold up under scrutiny. That's where the right tooling makes the real difference.

If you want to see how Cloudsmith fits your DORA program, book a demo with us. We'll map your current software supply chain controls against the specific articles you're responsible for and show you exactly where the gaps are.