DORA Audits Don't Start With Your Policies — They Start With Your Last Deployment

DORA examinations in 2026 open with the change log from your last production release, not your governance frameworks. What a Joint Examination Team actually requests on day one — asset register, third-party contracts, incident log, per-release evidence — and where ICT providers stall.

DORA entered application on 17 January 2025. The first wave of supervisory examinations under the Joint Examination Teams (JETs) coordinated by the ESAs is now producing concrete document requests. What surprises most ICT providers is where examiners begin: not with governance frameworks or board-approved risk appetites, but with the change log from the most recent production release.

What the Examiner Actually Requests on Day One

A typical opening information request from a JET or national competent authority (NCA) examination in 2026 covers four document categories. First, the ICT asset register as defined under Article 8(4) of DORA, cross-referenced against the financial entity's register of critical or important functions (CIFs). Second, the contractual register for ICT third-party providers, including subcontractors at least one tier deep, per Article 28(2). Third, the incident log for the preceding 12 months, classified against the materiality thresholds in the RTS on incident classification (Commission Delegated Regulation (EU) 2024/1772). Fourth, and least expected: the change records for the three most recent releases to systems supporting CIFs, with associated test evidence and rollback documentation.

That fourth item is where unprepared providers stall. Policies exist. Registers exist. The per-release evidence trail often does not.

The Asset Register Is a Living Dependency Map, Not a Spreadsheet

Article 8 requires financial entities to maintain an inventory of ICT assets that supports CIFs, updated continuously. In practice, examiners check whether the register reflects the actual production topology at the date of the audit, not the topology at the date the register was last formally reviewed. Discrepancies — a new microservice introduced in Q3 that does not appear in the register, a deprecated component still listed as active — are treated as ICT risk management failures, not administrative oversights.

The RTS on ICT risk management (Commission Delegated Regulation (EU) 2024/1774) requires that the register include asset classification, ownership, interdependencies, and recovery time objectives. Examiners cross-check RTOs against the Business Continuity Plan and against actual recovery test results. A stated RTO of four hours for a payments processing component is immediately tested against the most recent DR drill report. If the drill achieved six hours, the gap requires a written remediation plan with a deadline.

The register is evidence of operational reality, not a documentation exercise. Examiners treat a stale register as proof that the ICT risk management framework is not functioning.

How the Per-Release Evidence Pack Closes the Change Risk Loop

DORA and its RTS on ICT risk management (Commission Delegated Regulation (EU) 2024/1774) require ICT change management procedures that include testing, approval, and rollback. The examination operationalises this by pulling the three most recent change records and asking for a complete evidence pack for each. A compliant pack contains: the pre-change risk assessment referencing the affected CIFs; test results from a non-production environment that mirrors production configuration; approval sign-off from the designated change authority; post-deployment validation evidence; and a documented rollback procedure with a tested execution time.

The rollback requirement is frequently incomplete. Many providers document a rollback procedure as a narrative step in a runbook. Examiners ask for evidence that the rollback was tested — not simulated in a tabletop, but executed in a staging environment — and for the measured time to restore the prior state. If that evidence does not exist, the change is considered to have been deployed without adequate risk controls, regardless of how thorough the pre-change assessment was.

A per-release evidence pack that is assembled automatically at pipeline completion — capturing test results, approvals, and deployment metadata in a structured, immutable record — answers these requests without manual reconstruction. Manual reconstruction introduces gaps and timestamps that examiners scrutinize.

Incident Classification Is More Granular Than Most Providers Expect

The RTS on incident classification sets out a set of materiality criteria for determining whether an ICT-related incident is major and therefore subject to mandatory reporting under Article 19: clients, counterparts and transactions affected; reputational impact; duration and downtime; geographic spread; data losses; criticality of services impacted; and economic impact. An incident is major when it hits a critical service together with a key threshold, or when two or more of the other thresholds are met. The numbers are specific — for payment institutions the thresholds combine relative measures (a share of clients or transactions) with absolute ones (downtime, economic impact), so an incident well inside one criterion can still be major on a second.

Examiners review the incident log against these thresholds and look for incidents that were classified as non-major but that, on the face of the log data, appear to meet one or more criteria. Misclassification — even if unintentional — is treated as a failure of the incident management framework. The examination will ask for the classification rationale for any incident that is borderline, and for evidence that the classification was reviewed by a designated function, not made unilaterally by the on-call engineer.

Indicative — confirm exact thresholds against the RTS (Delegated Regulation (EU) 2024/1772) for your entity type:

The Subcontractor Gap Is Where Most Findings Land

Article 28 requires financial entities to ensure that their ICT third-party providers apply equivalent standards to their own subcontractors. In examination, this translates to a request for the contractual clauses in the provider's agreements with its subcontractors, and for evidence that the provider has assessed those subcontractors' ICT risk management practices within the last 12 months.

Most providers have clean primary contracts. The subcontractor tier is where findings accumulate. A cloud infrastructure provider that subcontracts network operations to a regional carrier, or a software vendor that uses a third-party code signing service, must be able to demonstrate that those relationships are documented, assessed, and contractually bound to DORA-equivalent standards. The absence of a subcontractor assessment programme — not just a clause, but an actual assessment with results — is a finding under Article 28(7) and typically results in a remediation requirement with a 90-day deadline.

The practical implication for ICT providers serving EU financial entities is that audit readiness in 2026 is not a compliance team function. It is an engineering and operations function. The evidence that closes examination requests is generated at deployment time, at incident triage time, and at contract renewal time — not assembled retrospectively when the document request arrives.