all posts

compliance

DORA for ICT third-party observability vendors — what actually changes

EU Regulation 2022/2554 has been in force since 17 January 2025. If you sell observability to financial entities — banks, insurers, payment institutions, investment firms — Article 28-30 obligations cascade onto you via contract. Here's the actual addendum.

By Akshay Sarode· June 22, 2025· 13 min readdoraict-tppfinancial-servicescompliance

DORA for ICT third-party observability — what actually changes

DORA — the Digital Operational Resilience Act, Regulation (EU) 2022/2554 — has been in direct application across the entire EU since 17 January 2025. Unlike NIS2, which is a directive needing national transposition, DORA applies as written, in every member state, on the same date. If you are a SaaS vendor whose customer is a financial entity (a bank, insurer, payment institution, investment firm, electronic money institution, fund manager, central counterparty, central securities depository, trading venue, credit rating agency, or one of nineteen other categories listed in Article 2), DORA's third-party-provider regime cascades onto you through contract.

This post is what we tell financial-entity customers when they ask: "What do you sign for DORA, and what do you not?"

What DORA does and what it doesn't

DORA covers four pillars:

  1. ICT risk management (Articles 5-16) — financial entities must have a written ICT risk management framework.
  2. ICT-related incident reporting (Articles 17-23) — strict timelines, classification rules, and reporting templates for incidents.
  3. Digital operational resilience testing (Articles 24-27) — including TLPT (Threat-Led Penetration Testing) for "significant" entities every three years.
  4. Management of ICT third-party risk (Articles 28-44) — the bit that affects observability vendors.

For a vendor selling to financial entities, the relevant chapter is Chapter V Section II — Articles 28 through 30 in particular, which cover due diligence, contractual provisions, and the Register of Information. Sections III (Critical TPP regime) cover ESA-supervised hyperscalers and don't apply to most vendors.

The Critical TPP (CTPP) regime — and why it doesn't apply to most of us

A small number of ICT third-party providers will be designated as "Critical" by the European Supervisory Authorities (the ESAs — EBA, EIOPA, ESMA acting as a Joint Committee). The criteria in Article 31 — systemic impact, market concentration, substitutability — are deliberately calibrated to capture the AWS / Microsoft Azure / Google Cloud tier. Once designated, a CTPP comes under direct ESA supervision, including audit, fines, and remediation orders, and pays an annual oversight fee.

The practical reality for the rest of us: we are regular TPPs. Article 28-30 applies to our contractual relationship with our financial-entity customers, but we are not directly regulated by the ESAs. Anyone telling you otherwise is either confused or a CTPP — and CTPPs know who they are.

Sutrace is far below the CTPP threshold. We are an ICT TPP for the financial entities that buy our observability product, and we are subject to the cascade obligations described below. That's it.

The contractual provisions DORA Art. 30 requires

Article 30 is prescriptive about what must be in the written contract between a financial entity and an ICT TPP. The required provisions are:

Art. 30(1) — General

  • Clear and complete description of services
  • Whether sub-contracting is permitted
  • Locations where services are performed and where data is stored/processed
  • Description of services (including conditions for cooperation in case of insolvency, resolution, or business discontinuance)
  • Service level descriptions, including updates and revisions
  • Right of the financial entity to monitor performance
  • Adequate notice periods for termination

Art. 30(2) — For services supporting critical or important functions

  • Service level descriptions in quantitative terms with precise targets
  • Notice periods for changes that might affect the financial entity
  • Cooperation with competent authorities and resolution authorities
  • Termination rights with explicit triggers
  • Participation in the financial entity's TLPT testing if required
  • Audit rights — for the financial entity, the regulators, and any third parties appointed by them, including unrestricted access to premises, systems, and information
  • Exit strategies allowing migration to another provider or in-housing

Art. 30(3) — Audit cooperation

  • The TPP must "fully cooperate" with the financial entity, the competent authorities, and the resolution authorities in the conduct of audits.

For Sutrace, we sign all of these in our DORA addendum. The points worth flagging:

Audit rights are not negotiable

Some vendors push back on Art. 30(3) because they're scared of customer auditors traipsing through their data centre. The practical answer is: agree to it, and structure it so it's reasonable. Our addendum says: customer or its appointed third party may conduct an onsite audit on 30 days' written notice, no more than once per 12 months unless triggered by a material incident, scope limited to controls relevant to the customer's services, costs borne by the customer unless the audit reveals a material non-compliance.

Regulator audits — EBA, EIOPA, ESMA, BaFin, AMF, BdF, etc. — are unlimited in frequency. We agree to them with no advance notice required, because the regulator has the legal authority regardless of what our contract says.

Sub-contracting controls (Art. 30(2)(a))

Article 30(2)(a) requires the contract to address sub-contracting of "critical or important functions" or "material parts thereof." For us, the relevant sub-processor is Google Cloud (europe-west3 infrastructure) — without it the service doesn't exist. Our DORA addendum lists Google Cloud as a pre-approved sub-processor, with the customer retaining a right of objection to any new material sub-processor on 30 days' notice (which would terminate the contract if unresolved within that window).

This is the same model as our GDPR sub-processor change-notification clause. We don't change sub-processors silently.

Exit strategy (Art. 28(8))

Article 28(8) requires the financial entity to have "exit strategies" for its TPP arrangements. The vendor side of that obligation is supplying:

  • A complete data export in an interoperable format (we provide Parquet/CSV/JSON exports of all customer telemetry)
  • Reasonable assistance during a transition period (we offer 60 days post-termination at no extra cost; longer with a migration agreement)
  • Documentation sufficient for the receiving system to ingest the data

We commit to all three contractually. The data is the customer's; we do not hold it hostage to renewal negotiations.

Service-level descriptions in quantitative terms (Art. 30(2)(c))

For "critical or important function" support, vague SLAs are not enough. We provide:

  • Availability: 99.9% monthly uptime measured at the API and dashboard layers
  • Data ingestion latency: 95th percentile < 10 seconds from device publish to dashboard query availability
  • Backup: nightly, 30-day rolling, restorable within 4 hours
  • Incident notification: 24 hours from awareness, matching NIS2 Art. 23 (parallel obligation)

These are the same quantitative targets shown on the trust page and on pricing.

The Register of Information

Article 28(3) requires the financial entity to maintain a Register of Information of all contractual arrangements with ICT TPPs. The ESAs jointly published Implementing Technical Standards (ITS) in 2024 specifying 15 templates with 110+ data fields per arrangement.

The vendor's role is providing the inputs the financial entity needs to populate this register accurately. The fields we routinely supply on request:

  • Legal name, registered address, registration number (LEI if applicable)
  • Description of ICT services provided, mapped to the ITS taxonomy
  • Critical-or-important-function assessment (we provide our view; the customer makes the determination)
  • Sub-contracting chain and locations
  • Contractual provisions matrix (Art. 30 mapping)
  • Annualised cost of the arrangement
  • Reliance on the TPP for critical-or-important functions

We have a single PDF document that pre-fills all of these for our standard contract; financial-entity customers get it on request.

What about Article 24 testing?

Article 24-27 are the operational resilience testing chapters. Significant financial entities do TLPT (Threat-Led Penetration Testing) under TIBER-EU methodology every three years. Vendors are sometimes asked to participate.

Our policy: we cooperate with customer TLPT exercises that include our service in scope, with reasonable notice and a defined scope of testing. We do not allow uncoordinated red-team activity against our production environment because that would harm other tenants. The pattern is: scope the test, schedule a window, run it on a non-production tenant or a controlled production scope, share findings with the customer and us simultaneously.

What about ICT-related incident reporting (Art. 19)?

The financial entity reports "major ICT-related incidents" to its competent authority on an aggressive timeline: initial notification within 4 hours of classifying the incident as major, intermediate report within 72 hours, final report within one month. The classification criteria are set out in RTS published by the ESAs in 2024 and are based on number of clients affected, geographical spread, duration, data losses, economic impact, and reputational impact.

The cascade: when our service is involved, the customer needs information from us in time to meet their 4-hour clock. Our 24-hour contractual notification is the floor; in practice, for high-severity events we communicate within minutes. We have an incident-runbook tested quarterly that requires the on-call engineer to send first-customer-notification within 60 minutes of severity-1 confirmation.

What we don't sign for DORA

Three things we explicitly refuse:

  1. "Joint and several liability with regulator fines." We sign customary indemnification for our breach. We do not sign open-ended liability for regulatory fines that DORA imposes on the customer — those fines are penalties for the customer's own decisions and processes. Our liability cap is the standard 12-month-fees cap with carve-outs for confidentiality breaches and data-protection violations.

  2. "Unrestricted free access to source code and infrastructure for any auditor." We agree to scoped audits on reasonable notice. We do not agree to "any auditor at any time anywhere". This is not negotiable.

  3. "CTPP-equivalent oversight by the customer." Some financial entities try to treat regular TPPs as if they were CTPPs because the CTPP regime is more favourable to them. The CTPP designation is the ESAs' to make. We are a regular TPP and the contract reflects that.

How this maps to the broader compliance posture

DORA is one of three frameworks our customers care about — the others being NIS2 (overlapping for non-financial customers) and the EU AI Act (orthogonal). The shape of all three cascades is similar: regulated entity downstream-pushes obligations to vendors via contract; vendors sign reasonable cascading provisions; vendors refuse unreasonable extensions.

The unifying piece on our side is the compliance use-case page and the trust architecture — EU residency, sub-processor transparency, signed DPA, 24-hour incident clause. Once those are in place, the per-framework addendum is small.

External references