DORA compliance requirements for engineering teams

DORA compliance is a build list. Regulation (EU) 2022/2554 names the obligations, but the thresholds, time limits and templates an engineering team implements sit in the technical standards beneath it. Think of the regulation as a building code and the standards as the blueprints: a team that reads only the code builds something that fails inspection.

Regulation (EU) 2022/2554 (DORA) has applied since 17 January 2025 (Article 64). It requires engineering teams at EU financial entities to produce evidence of ICT risk control: a current asset and dependency inventory, pipeline controls, incident reporting on fixed deadlines, tested resilience, and third-party records.

The regulation sets the duties, and the regulatory technical standards (RTS) set the build detail. Under Delegated Regulation (EU) 2025/301, Article 5(1)(a), an initial notification is due within four hours of classifying an incident as major and no later than 24 hours from awareness.

Several duties, including the extra contract terms in Article 30(3) and the scope of TLPT, depend on which functions are essential or important.

Whether your entity is in scope under Article 2, and which national deadlines apply, is a legal determination for counsel and your competent authority. "DORA" here means this EU regulation, not the DevOps delivery metrics.

DORA timeline: the regulation and its technical standards

DORA's obligations have applied since 17 January 2025, two years after the regulation entered into force on 16 January 2023. Both dates are set in Article 64. The technical standards entered into force at different points in that window and after it.

The table lists when each standard an engineering team works from entered into force:

The asset management, encryption and classification texts were in force about six months before application. The reporting content, template and TLPT texts followed it, by roughly two months and almost six months respectively. Which expectations applied to incident reporting in that gap is a question for your competent authority and counsel.

Who must comply with DORA? Scope and proportionality

DORA applies to the financial entities and ICT third-party service providers listed in . Points (a) to (t) of Article 2(1) cover credit institutions, payment and e-money institutions, investment firms, insurers, crypto-asset service providers, trading venues and others.

Article 2(3) excludes some entities, such as insurance and reinsurance intermediaries that are micro, small or medium-sized enterprises, and Article 2(4) lets Member States exclude certain categories of credit institution. Whether your entity is in scope is a legal determination for counsel and your competent authority.

Software partners are reached in two ways. Article 2(1)(u) lists ICT third-party service providers, and Article 31 sets the oversight regime for those the ESAs designate. Most partners meet DORA through the contract terms in Article 30, which the financial entity has to include in its agreement with you.

Article 4 scales the Level 1 duties to an entity's size, risk profile and complexity. Entities covered by Article 16, such as small and non-interconnected investment firms, are outside Articles 5 to 15 and follow a simplified ICT risk management framework (Article 16(1) of ).

Level 2 specifies that framework in Delegated Regulation (EU) 2024/1774, and Level 3 guidelines come from the ESAs (EBA, EIOPA and ESMA).

Our recommendation is to read proportionality as permission to shrink paperwork. It does not remove the working systems:

Which five artifact groups does DORA create?

DORA creates five groups of engineering artifacts. They are an ICT asset and dependency inventory, pipeline controls and logging, an incident pipeline, a testing programme, and third-party data and contracts. The regulation, (Level 1), sets the duty. The delegated and implementing regulations (Level 2) hold the detail you build against.

The mapping from the regulation's chapters to what an engineering team ships:

Risk management appears twice because the inventory and the pipeline controls are built by different teams. Information sharing (Article 45) adds no standing artifact group of its own.

The Level 2 column is where the build decisions sit. Level 3 guidance is thin by comparison. Which technical standards bind a given entity, and in what form, is a question for counsel and the competent authority.

What must the ICT inventory hold?

The ICT inventory must hold the Article 4(2)(b) fields for every asset, plus its links to the business functions it supports. Those fields are set by .

That Level 2 article requires records of the links and interdependencies among ICT assets and the business functions using each one. It also requires, per asset, the fields in the table below. Article 8(1) supplies the classification the record refers to.

Each field already exists somewhere in your delivery stack:

To keep the inventory from drifting, generate it as a pipeline output. Read Terraform state and the cloud account APIs (AWS Config, Azure Resource Graph, GCP Cloud Asset Inventory), then join deployment metadata. Fail the deploy when a required tag is missing, and run a scheduled job that diffs the inventory against account listings and flags unmanaged resources.

Humans still enter three things: owner, classification and the function mapping. Keep those in the repository beside the code, so a change to a service is reviewed together with its inventory record.

Two caveats apply. Cloud APIs do not see SaaS products, on-premises hosts or mainframes, so those need a CMDB feed or a reviewed manual record.

Entities other than microenterprises must also keep the information needed for a specific ICT risk assessment of legacy systems (Article 4(2)(c), referring to Article 8(7)).

The entity itself decides which of its functions are critical or important functions; the inventory carries that flag but does not decide it.

Which controls belong in the delivery pipeline?

Three controls belong in the delivery pipeline: change management, logging, and restore testing. The duties sit in Articles 9, 10 and 12 of . , the regulatory technical standards (RTS) on ICT risk management tools, supplies the Level 2 detail.

The table translates each control into something to build, a place in the pipeline, and the evidence it leaves:

Check the exact event lists and retention rules against the RTS text. We recommend setting retention per function, by its criticality, so the inventory from the previous section drives the log settings.

SaaS and cloud logs are the first place this breaks. Managed services differ in what they export, how long they keep it, and whether audit logs sit behind a higher licence tier or an API pull. Compare each service's export and retention against the retention you set for the function it supports. Record the gaps in the inventory and raise them in contract terms.

Restores break next. A green backup job proves a copy exists. A restore test proves the copy comes back. If nobody runs it on a schedule, the Article 12 evidence file holds no dated measurement against your RTO and RPO.

An early sign is a runbook that has never been executed, or a test that restores one database while the function also depends on queues, secrets and configuration.

Proportionality under Article 4 scales how much of this a smaller entity needs. Whether your evidence satisfies a supervisor is for your competent authority and counsel to decide.

DORA major incident reporting deadlines and classification

Major incident classification follows Delegated Regulation (EU) 2024/1772, and the reporting clock follows Delegated Regulation (EU) 2025/301. One incident record has to feed both.

sets the duties in Articles 17 to 19. The thresholds and timers are Level 2. The classification RTS is Delegated Regulation (EU) 2024/1772, and the content and time limits sit in . The template is Implementing Regulation (EU) 2025/302.

Worked example. Assume a payment service used by 400,000 clients. During an outage, 43,000 clients cannot complete a payment. These figures are assumptions for illustration, not observed data.

Article 1(1) of Delegated Regulation (EU) 2024/1772 counts clients that were unable to use the service or were adversely impacted, plus third-party beneficiaries named in the contract. Article 9(1)(a) is met when that number exceeds 10% of all clients using the affected service.

43,000 / 400,000 = 10.75%, so the criterion is met. At 38,000 affected clients the share is 9.5% and this criterion is not met, though the other criteria are still assessed. Article 8 of the same act decides how the criteria combine into a major verdict. If the exact count is unknown, Article 1(5) requires an estimate from comparable reference periods.

Now the clock, using Article 5 of Delegated Regulation (EU) 2025/301:

Article 5(1)(a) requires the initial notification as early as possible, within four hours from classification as major and no later than 24 hours from awareness.

If the entity only classifies the incident as major after the 24 hours have passed, Article 5(2) still requires the initial notification within four hours of classification. Classified at 20:00 on Tuesday, it would be due at 00:00 on Wednesday. The intermediate report is due within 72 hours of the initial notification, and the final report no later than one month after the latest intermediate report (Article 5(1)(b) and (c)).

Weekends and bank holidays have their own rule. Under Article 5(4), a limit that falls on one may move to noon of the next working day, but Article 5(5) takes that option away for the initial notification and intermediate report of credit institutions, central counterparties, trading venue operators and entities that are essential or important under NIS2. Your timers need the entity type and a holiday calendar, not only a clock.

Three engineering consequences follow:

• Store awareness time and classification time as separate fields, and start two timers from them.
• Compute the affected-client share automatically from the service's client count, so classification does not wait for a manual tally.
• Map record fields to the Annex I template of Implementing Regulation (EU) 2025/302, and submit through the secure channel your competent authority provides (Article 4(1)).

Article 5(3) of Delegated Regulation (EU) 2025/301 requires a missed limit to be reported to the competent authority, with reasons, by the limit itself. Which authority and which channel apply is a question for counsel and your supervisor.

DORA threat-led penetration testing (TLPT) requirements

A DORA resilience-testing programme is the Article 25 test set run on a schedule, plus threat-led penetration testing (TLPT) for selected entities. The duties sit in Articles 24 to 27 of . Article 24(6) requires at least yearly testing of ICT systems that support critical or important functions.

Article 25(1) lists the baseline tests but does not say where they run. Our suggested mapping to an engineering pipeline:

Keep the CI results, the scan schedule and the exercise records. They are the evidence an auditor will ask for.

When TLPT applies

TLPT applies only if your TLPT authority requires it. Article 26(1) sets a three-year cycle for those entities.

Delegated Regulation (EU) 2025/1190 Article 2 sets the selection logic. The authority weighs impact, systemic character and ICT risk profile, and names some entity types by default, including central securities depositories and central counterparties. A banking group's authority may still add or exempt entities, so confirm your status with counsel and the authority.

A baseline penetration test is not TLPT. TLPT follows real threat intelligence, runs against live production systems that support critical or important functions, and sits inside the ECB's TIBER-EU lineage. Where an ICT third-party service provider's systems are in scope, the Article 30 contract terms should oblige it to take part.

Running TLPT on live production

Live production is the main hazard: a red team that corrupts data or trips an outage hits real customers. Article 26 requires risk controls against that impact. We recommend agreeing these with the control team before the active phase:

• A verified backup and restore for every in-scope system.
• Named people who can halt the test at once.
• Excluded change windows.
• Rules for handling any customer data the testers reach.

The testers submit the red team test report within 4 weeks of the end of active testing (Article 12(2) of Delegated Regulation (EU) 2025/1190). Once the TLPT authority confirms the red and blue team reports are complete, Article 12(7) gives the entity 8 weeks to submit the summary of findings, and Article 13(1) gives another 8 weeks from that notification for the remediation plans.

What do third-party data and contracts require?

Third-party data means a register of information on every ICT contractual arrangement, and Article 30 contract terms in each contract. The terms are in , with more of them where the service supports a critical or important function.

DORA register of information requirements

Article 28(3) requires the register at entity level, plus sub-consolidated and consolidated registers for groups. The templates are set by Implementing Regulation (EU) 2024/2956. They key the financial entity and its providers on Legal Entity Identifier (LEI) codes, so your vendor master data needs those fields. Submission timing is set by your competent authority.

The register feeds two other duties. Article 29 asks for a preliminary assessment of ICT concentration risk, and a query showing many functions on one provider is its input. Article 28(8) requires exit strategies for services supporting critical or important functions.

Entries go stale in three ways: a contract is amended, a subcontractor is swapped, or a workload moves region. Engineering is usually the only team that knows the provider, subcontractor, and region behind each function. Legal knows the contract, and neither side sees the other's change.

Our recommendation is to generate register rows from infrastructure tags and the contract repository, not from a yearly spreadsheet exercise. Tag each workload with function, provider, and contract ID. Then add a pipeline check that fails when a deployed managed service or region has no matching row.

Contract terms a software partner must support

A software partner that delivers ICT services to a financial entity is an ICT third-party service provider under DORA. The Article 30 terms describe what it has to support in day-to-day delivery.

Article 30(2) applies to every ICT services contract. It requires, among other things:

• a full description of the services and whether subcontracting is permitted, with its conditions;
• the locations where services and data processing take place;
• access to, recovery, and return of data if the provider becomes insolvent or discontinues the service;
• assistance in incidents and cooperation with authorities.

Article 30(3) adds terms for services supporting critical or important functions: quantified service levels, contingency plan testing, participation in the entity's threat-led penetration testing, unrestricted access, inspection and audit rights, and exit with a transition period. The financial entity decides which of its functions are critical or important functions, so a partner should ask for that classification at kickoff.

These terms only hold if the delivery setup can produce evidence for each one. Netguru builds software for banks, payment companies and fintechs and holds ISO 27001 certification; the table below is what we would expect any partner, including ourselves, to be able to show:

The subcontractor list matters beyond the contract, because it feeds the entity's register of information. For services supporting critical or important functions, Delegated Regulation (EU) 2025/532 sets what the entity has to assess before allowing subcontracting.

Source-code escrow is not named anywhere in the act. Whether it helps meet the insolvency-access and exit terms is a decision for counsel and the entity's exit plan.

Does information sharing (Article 45) need engineering work?

Information sharing under Article 45 is voluntary, so it needs engineering work only if you join an arrangement. The rules are in Article 45 of . The work then lands on the incident pipeline.

Article 45 confines sharing to trusted communities of financial entities, under rules covering business confidentiality, personal data protection and competition policy. It also expects you to notify your competent authority when membership starts and ends. Our rule: join only once the pipeline can export indicators of compromise with personal data and client identifiers stripped.

The data is mostly captured already. Article 3, point (l), of lists indicators of compromise as intermediate-report content. Tag those fields as shareable in the incident record, and keep client and transaction fields out of the export. For how DORA sits next to NYDFS, PCI DSS and other regimes, see our cross-regime guide to cybersecurity for financial services.

DORA engineering checklist: Artifact, standard, owner, evidence

A DORA engineering checklist pairs each Article and technical standard with the artifact it produces, the team that owns it, and the evidence a supervisor can open. The table below is our working version. The Owner column is our suggestion; the Article and standard columns follow and its Level 2 acts.

Read each row like a pipeline stage. The artifact is the build output, and the evidence is the stage's logs and sign-offs, kept so a supervisor can replay what happened.

Whether an entity must run TLPT, and the national deadlines for submissions, are legal determinations for your competent authority and counsel.

DORA compliance FAQ

What are the 5 pillars of DORA regulation?

DORA's five pillars are ICT risk management, incident management and reporting, resilience testing, ICT third-party risk, and information sharing. They map to Chapters II to VI of . "Pillars" is shorthand, not statutory text, and most build detail sits in the Level 2 technical standards.

What does it mean to be DORA compliant?

Being DORA compliant means meeting the obligations of Regulation (EU) 2022/2554 and its technical standards, and holding evidence your competent authority can inspect. That evidence includes the ICT asset inventory, logs and incident records. Software helps only if it produces those artifacts. We do not rank vendors here, because the right choice depends on your entity type and existing stack. Instead, screen any tool against four checks: - Incident clock: it records the moment of awareness and the moment of classification separately. , Article 5(1), sets deadlines relative to both, and Article 5(2) covers late classification. - Report format: it exports initial, intermediate and final reports in the Annex I template required by Article 1(1) of . - Classification thresholds: it lets you configure the criteria in Article 9 of , such as the 10% client threshold and the EUR 100,000 economic-impact threshold. - Inspectable exports: inventories, logs and contract registers leave the tool in a form an authority can read without your vendor. As a decision rule, drop any tool that fails the first two checks, since missed deadlines and malformed reports are the failures an authority sees first. Run a sample incident through each shortlisted tool before you buy. For a broader assessment method, see this guide to choosing compliance software for financial firms.

What are DORA regulatory requirements?

DORA requires four things: ICT risk management, incident reporting, resilience testing and third-party controls. In detail, it requires an ICT risk management framework owned by the management body (Article 5), major incident reporting (Article 19), resilience testing including TLPT (Article 26), and third-party controls with contract terms (Articles 28-30). Reporting deadlines sit in Delegated Regulation (EU) 2025/301, Article 5(1). The initial notification is due within four hours of classification and no later than 24 hours after awareness. The intermediate report is due within 72 hours of the initial notification, and the final report within one month of the intermediate report.

Who does DORA regulation apply to?

DORA applies to the 21 categories listed in Article 2(1), from credit institutions and payment institutions to insurers, crypto-asset service providers and ICT third-party service providers. Article 2(3) excludes some entities, such as certain managers of alternative investment funds (point (a)), and Article 4 scales duties to size and risk. Whether a specific firm is in scope is a legal determination.

What is DORA regulation in simple terms?

DORA is an EU regulation requiring financial entities to withstand, respond to and recover from ICT disruptions under one rulebook for the sector. It is unrelated to the DevOps DORA metrics. For engineering teams, it turns resilience into artifacts: inventories, logs, incident reports, test reports and contract terms.

When did DORA become applicable?

DORA has applied since 17 January 2025, under Article 64 of Regulation (EU) 2022/2554. The regulation entered into force earlier, on 16 January 2023, which gave financial entities two years to prepare. Each Level 2 act carries its own entry-into-force date, so check the act you are building against.

Where to start

Start with the two artifacts every other one depends on: the ICT asset and dependency inventory, and an incident record that stores awareness and classification times separately. The register of information, the log settings and the testing scope all read from the inventory, and the reporting clock reads from the incident record.

If you are planning this work for a financial services platform, our cybersecurity team can map your systems against the checklist above with you. Tell us what you are building and we will scope it together.