The line-by-line answer to the only question that matters in 2026: if the National Competent Authority walks in tomorrow, can we produce the evidence in 48 hours? An 18-point DORA Article 28 evidence checklist grouped into the four categories an inspector works through, with the operational pattern that produces the pack as a byproduct of business-as-usual vendor management.
DORA — Regulation (EU) 2022/2554 — has been applicable since 17 January 2025 (Article 64). The first national supervisory reviews under it are running through 2026: the Central Bank of Ireland (CBI), BaFin in Germany, De Nederlandsche Bank (DNB) in the Netherlands, the ACPR in France, and the CSSF in Luxembourg are all conducting on-site reviews and information requests focused on ICT third-party risk. The question every CRO, Head of Procurement, and operational-resilience lead is being asked by their second line is simple: if the National Competent Authority walks in tomorrow, can we produce the evidence in 48 hours?
This piece is the line-by-line answer. We set out exactly what Articles 28 and 30 empower a supervisor to ask for, an 18-point evidence checklist grouped into the four categories an inspector works through, a 48-hour readiness drill you can run with your team this Friday, and the operational pattern that turns this evidence pack into a byproduct of business-as-usual vendor management rather than a twice-a-year scramble.
DORA places the obligation directly on the financial entity, not on its providers. Article 28(1)(a) states:
"Financial entities shall manage ICT third-party risk as an integral component of ICT risk within their ICT risk management framework... financial entities that have in place contractual arrangements for the use of ICT services to run their business operations shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation and applicable financial services law."
That responsibility crystallises in five evidence pillars.
(a) The maintained register itself. Article 28(3) requires financial entities to "maintain and update at entity level, and at sub-consolidated and consolidated levels, a register of information in relation to all contractual arrangements on the use of ICT services provided by ICT third-party service providers." Contractual arrangements must be "appropriately documented, distinguishing between those that cover ICT services supporting critical or important functions and those that do not." The register must be made available to the competent authority "upon its request… or, as requested, specified sections thereof, along with any information deemed necessary to enable the effective supervision of the financial entity." The standard template format for the register is set by the ESAs' Joint Committee through Implementing Technical Standards under Article 28(9).
(b) Contractual provisions. Article 30(2) sets a baseline of clauses required in every ICT contract: a clear and complete description of the functions and services provided; locations of service performance and data processing; provisions on availability, authenticity, integrity, and confidentiality of data; assistance at no additional cost or at a pre-determined cost when an ICT incident occurs; full cooperation with competent authorities; termination rights and minimum notice periods. Article 30(3) layers on additional requirements for contracts supporting critical or important functions: full service-level descriptions including quantitative and qualitative targets; reporting obligations; business contingency plans; ICT security standards; participation in Threat-Led Penetration Testing where in scope; and unrestricted rights of access, inspection, and audit by the financial entity, third parties appointed by it, and the competent authority.
(c) Exit strategies. Article 28(8) requires financial entities to put in place exit strategies for ICT services supporting critical or important functions, taking into account risks at the provider, including provider failure, deterioration of service quality, business disruption, and inappropriate or failed provision of services. Strategies must include a transition period during which the provider continues providing services to allow migration to an alternative provider or reintegration in-house.
(d) Concentration risk assessment. Article 29 requires financial entities, as part of their ICT risk management framework, to "regularly assess… all risks related to such contractual arrangements, including… concentration risk." That includes assessing whether a planned arrangement concerns an ICT third-party provider that is "not easily substitutable" or where the entity has multiple arrangements with the same provider or closely connected providers.
(e) Sub-contracting chain visibility. Article 30(2)(a) requires the contract to specify "a clear and complete description of all functions and ICT services to be provided… indicating whether subcontracting of an ICT service supporting a critical or important function, or material parts thereof, is permitted and, when that is the case, the conditions applying to such subcontracting." The ESAs' Joint Committee final report on RTS on subcontracting (JC 2024 53, July 2024) provides further detail on the elements financial entities must determine and assess. The European Commission notified the ESAs on 21 January 2025 of amendments to the draft RTS; the substance of the subcontracting-assessment obligation is unchanged.
For Irish entities the CBI's Cross-Industry Outsourcing Guidance sits alongside DORA — the CBI has indicated it will refresh the guidance in H2 2026 to reflect DORA, and supervisory reviews already use DORA terminology. The EBA's Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) continue to apply to non-ICT outsourcing of banking and payment services.
What a supervisor will ask for, what document satisfies it, the format they expect, and where most firms have a gap.
What's asked: "Show us the register, in the ESAs template, as of the most recent quarter-end."
Evidence: The Register of Information, populated to the ESAs Joint Committee ITS schema (contractual arrangement, entity, function, criticality, location, sub-contractors, etc.).
Format: Structured table — CSV or XLSX exportable to the ITS XBRL taxonomy, with a stated as-of date and a named owner.
Common gap: The register exists as a spreadsheet that nobody reconciles against the actual signed contracts.
What's asked: "Walk us through how you decided this provider supports a critical or important function — and how you decided that one does not."
Evidence: A documented criticality assessment per provider/function, with criteria, scoring, and approver.
Format: Per-provider memo or scoring record, dated and approved.
Common gap: Criticality is implicit ("everyone knows the core-banking provider is critical"), not documented to a defensible methodology.
What's asked: "Who does your provider rely on? Name every entity in the chain that touches the data or the service."
Evidence: A sub-contracting chain diagram or list, linked to the provider's most recent disclosure, with consent records where the contract requires consent.
Format: Diagram + table, dated.
Common gap: The map stops at the Tier-1 provider; Tier-2 cloud and managed-services dependencies are blank.
What's asked: "Where is each ICT service performed, and where is the data processed and stored?"
Evidence: Locations field of the register, supported by contractual location clauses and provider attestations.
Format: Country list per arrangement, with named data-centre regions for cloud services.
Common gap: "EU" listed without country granularity; sub-processor locations omitted.
What's asked: "Show us the clauses on service description, data location, security, incident assistance, cooperation with authorities, and termination."
Evidence: The signed contract, with the Art 30(2) clauses bookmarked or extracted.
Format: PDF of signed contract + a clause-mapping index pointing to each Art 30(2) requirement.
Common gap: Contracts pre-dating DORA were not re-papered; the clauses are partial or absent.
What's asked: "Show us the SLAs, the audit rights, the exit clause, the TLPT participation clause."
Evidence: The signed contract showing Art 30(3) provisions, plus the quantitative SLA targets.
Format: Contract + SLA appendix.
Common gap: SLAs reference "reasonable endeavours" instead of measurable thresholds; audit rights are limited to provider-controlled SOC 2 reports.
What's asked: "What happens if this provider fails next quarter? Show us the documented exit plan."
Evidence: A written exit strategy covering provider failure, deterioration, disruption, and failed provision (Art 28(8)), with named alternative providers or in-house reintegration plan and a transition period.
Format: Per-provider exit plan, dated, with last-tested date.
Common gap: The exit plan exists as a paragraph in the contract; no operational runbook, no tabletop exercise record.
What's asked: "When did you last exercise your audit right under Article 30(3)(e)? Show us the report."
Evidence: Audit reports, on-site visit records, or pooled-audit participation evidence, plus any third-party assurance reports (SOC 2 Type II, ISAE 3402).
Format: Dated audit report or attestation, with findings and remediation status.
Common gap: Reliance solely on the provider's standard SOC 2 with no entity-specific audit ever attempted.
What's asked: "When your provider added a sub-processor last quarter, what was your assessment? Where is the approval?"
Evidence: Sub-processor change-notification records, assessment memos, and consent decisions (where consent is contractually required for critical-or-important functions).
Format: Email chain or change-log entries + assessment record.
Common gap: Notifications received but never assessed or filed.
What's asked: "When did you last reassess the risk of this provider? Show us the assessment."
Evidence: Dated risk assessments per critical-or-important arrangement, on a stated cadence (typically annual minimum), with risk rating and trend.
Format: Per-provider assessment record.
Common gap: Onboarding-time assessment with no refresh.
What's asked: "Show us the last twelve months of SLA performance against the contracted targets."
Evidence: Monthly or quarterly service performance reports, breach logs, service credits applied.
Format: Dashboard or report extract, with named owner.
Common gap: Provider sends the report; nobody on the buyer side reconciles it.
What's asked: "How would you know if this provider's risk profile was deteriorating?"
Evidence: A documented monitoring process — financial health, security incidents, regulatory actions, sub-contracting changes — feeding into a risk score or watch-list status.
Format: Monitoring framework + most recent score/status record.
Common gap: No structured monitoring outside the SLA report.
What's asked: "When the provider had a major incident in February, was it classified and reported under Articles 18 and 19? Show us the reporting trail."
Evidence: Incident records linked to the provider, classification against the Article 18 criteria, initial/intermediate/final notifications submitted to the competent authority under Article 19, root-cause and lessons-learned records.
Format: Incident log entry + regulatory submissions.
Common gap: Incident logged operationally but never assessed for major-incident classification.
What's asked: "What's your contractual notification window if the provider experiences a security incident? When did you last test it?"
Evidence: Contractual notification SLA + last-test record (tabletop or live).
Format: Clause extract + test report.
Common gap: Notification windows documented but never tested.
What's asked: "Show us where the management body approved the use of this provider for a critical or important function."
Evidence: Board pack extract, committee minutes, or signed approval memo, dated.
Format: Minutes or memo with named approvers.
Common gap: Approval implicit in the procurement decision; no separate management-body sign-off for the critical-function classification.
What's asked: "Show us first-line, second-line risk, and third-line audit involvement in onboarding and ongoing oversight of this provider."
Evidence: Sign-off records from procurement/business (1LoD), risk and compliance (2LoD), and internal audit (3LoD) for onboarding, renewal, and material change events.
Format: Sign-off log per provider.
Common gap: 2LoD reviews onboarding but is invisible in ongoing oversight.
What's asked: "Show us the most recent concentration-risk report — by provider, by sub-processor, by jurisdiction."
Evidence: Concentration-risk report at entity and group level, identifying not-easily-substitutable providers and cross-arrangement dependencies (Art 29).
Format: Periodic report (typically annual minimum) to the management body.
Common gap: No view of multiple arrangements sitting on a shared cloud Tier-2.
What's asked: "When did you last test the exit plan? What were the findings?"
Evidence: Tabletop or live exit-test report, with date, participants, scenario, and findings.
Format: Test report, dated, with management-body acknowledgement.
Common gap: Exit plan documented; never tested.
The eighteen items above are not eighteen workstreams. If the underlying vendor-management system is designed correctly, the supervisory-ready evidence pack is what falls out of the BAU workflow. Three principles separate the firms that have it ready in 48 hours from the firms that schedule a two-week war-room every time the supervisor calls.
Single source of truth. The Register of Information is the system — not a quarterly export from a CRM, a procurement tool, and an Excel sheet. Every supplier record, criticality classification, sub-processor entry, contract metadata, and SLA target lives in one place that the operational team uses daily. If the register and the working system are different artefacts, the register is wrong by the time you email it to the supervisor.
Immutable audit trail. Every change — supplier onboarded, criticality reclassified, sub-processor added, SLA breach logged, exit plan tested — has a who/when/what record that cannot be retroactively edited. When the supervisor asks "when did this become a critical function?", the answer is a date and a named approver, not a memory.
Evidence-first scoring. Risk ratings reference the underlying document or registry record, not the supplier's self-declaration. A provider that says "we hold ISO 27001" without an attached, verified certificate is treated differently from one whose certificate has been verified against the accreditation body. Decisions trace back to evidence; evidence traces back to a source. Our Trust Center documents how this works.
Platforms like FiorLab build this workflow natively; see our DORA deep-dive for how Article 28 maps onto the platform's evidence model.
Block ninety minutes this Friday. Pick the three most critical ICT providers on your books — the ones where, if they failed on Monday, the regulator would be in the building by Wednesday.
For each of the three, give your team 48 hours to produce, in a single shared folder:
Score the result honestly. If you cannot produce any one of these six artefacts inside 48 hours for any one of the three providers, you have a finding waiting to be discovered. The exercise is cheap, the discovery is expensive — but only if you do it before the supervisor does.
We have a vendor-neutral version of this drill in our Buyer's Guide. If you would prefer an external pair of eyes, contact us at hello@fiorlab.com for a supervisory-readiness review against this exact pattern.
DORA is applicable from 17 January 2025 under Article 64. It applies to financial entities listed in Article 2 — credit institutions, payment and e-money institutions, investment firms, crypto-asset service providers, central counterparties, trading venues, insurance and reinsurance undertakings, IORPs, and others — and indirectly to their ICT third-party service providers through the required contractual provisions in Article 30.
DORA Articles 28–30 set binding requirements specifically for ICT third-party arrangements and have the force of regulation. The EBA Guidelines on Outsourcing Arrangements (EBA/GL/2019/02) continue to apply to non-ICT outsourcing of banking and payment services. The EBA published a consultation in 2025 on guidelines for non-ICT third-party risk; the final guidelines are pending publication.
Yes. Cloud providers are ICT third-party service providers in their own right and must be in the Register of Information. Sub-processors must be identified in the contract per Article 30(2)(a), and the ESAs' draft RTS on subcontracting (JC 2024 53) sets out the elements financial entities must determine and assess when subcontracting supports critical or important functions.
The register is the primary supervisory artefact under Article 28(3). An incomplete register is a supervisory finding in its own right and is often the indicator that prompts a deeper review. National competent authorities have requested registers in the ESAs ITS template format during 2025–2026 supervisory cycles.
Article 28(3) requires the register to be "maintained and updated." Financial entities must report annually to the competent authority on new arrangements, provider categories, contract types, and services. In practice, supervisors expect the register to be current at the point of any supervisory request and reviewed at least annually by the management body.
A spreadsheet can technically hold the data required by the ESAs ITS template, but it places a heavy reconciliation burden on the firm — the register must match the signed contracts, the criticality classifications, the sub-processor map, and the operational systems at all times. In practice, firms relying on spreadsheets have struggled to produce reconciled registers inside supervisory request windows.
We spent fifteen years in procurement before founding FiorLab. Every regulated firm we worked with built this evidence pack twice a year, manually, in a spreadsheet that no one trusted. The day before the supervisor arrived, three people stayed late re-reconciling rows. The regulator does not care that your team is overworked. They care that the evidence is there when they ask. We built FiorLab so the answer is always yes, here it is. If you would like to talk through how Article 28 maps onto your operating model, write to us: hello@fiorlab.com.
— Word from our founder
Final free pilot cohort closes 30 June 2026 · paid-only from 1 July. Up to 5 suppliers, no card required, audit-ready Article 28 evidence chain from day one. EU-hosted, customer-owns-data.
Start Your Free Pilot