The DORA Contract Problem Nobody Budgets For

When banks budgeted for DORA, the money went to the visible workstreams: incident reporting, resilience testing, the ICT risk framework. The line item that keeps surprising institutions a year later is quieter — the contracts. Since 17 January 2025, every ICT supplier contract in a financial entity is a regulated object: inventoried in a register of information, remediated with mandatory clauses, monitored for renewals, exits and subcontracting.

Most banks don’t have a contract problem. They have a visibility problem — and DORA just made visibility a regulatory requirement.

The register is an annual routine now

The first register-of-information submission cycle ran in 2025, and many teams treated it the way you treat any first-time regulatory deliverable: as a project. A working group formed, contracts were hunted down across mailboxes and shared folders, a register was assembled, submitted, and everyone went back to their day jobs.

That changes the question. It is no longer “can we build the register once?” — it is “can we keep a complete, current contract inventory as an operational routine?” A register is only as good as the contract visibility feeding it. If old contracts can’t be traced to their origin, if renewals live in one person’s spreadsheet, if each department keeps agreements in its own shared folder — every annual cycle becomes an archaeology project.

Archaeology is not a compliance strategy

The archaeology pattern is easy to recognize. Someone in compliance emails five department heads asking for “any supplier contracts you have.” Three respond. One attaches a folder of PDFs with no metadata. The long-tenured operations manager remembers that the core-banking maintenance agreement was amended in 2019, but nobody can find the addendum. Multiply by every ICT supplier the institution has, every year.

This is not a people problem. It is what happens when a recurring regulatory obligation is serviced by tools that were never designed to answer the question “what contracts do we have, what is in them, and when do they change?”

What supervisors keep finding

European supervisors consistently identify Articles 28–30 — the register and contract provisions — as the area with the largest compliance gaps across financial entities. Incomplete registers. Missing criticality classifications. Contracts that never got the Article 30 clauses. None of these are exotic failures; they are all downstream of the same root cause: the institution cannot see its own contract estate.

The squeeze is tightest for small and mid-size banks. Proportionality scales the depth of the ICT risk framework, but it does not remove the third-party contract obligations — the register, the clauses, the exit strategies still apply. An Excel inventory cannot demonstrate complete, current contract coverage to a supervisor, and enterprise GRC suites are priced for institutions with dedicated third-party-risk teams.

The foundation is contract visibility

Every DORA contract obligation depends on the same underlying capability: knowing what contracts you have, what’s in them, and when they change. That is the layer worth fixing first — before the register template, before the clause remediation plan. We’ve written up how that contract-side foundation works for financial entities in our guide to DORA contract governance for banks, including what the register of information actually asks of your contract estate and where the common gaps are.

• A complete inventory: every supplier contract discovered and in one place — including the ones nobody remembered.
• The terms extracted: parties, prices, renewal dates, notice periods, penalty clauses, payment terms.
• Renewal control: alerts on renewal dates and notice windows, so contracts are remediated on time, not discovered expired.

If your institution is somewhere between “the auditor asked for our contract register” and “we can’t justify an enterprise GRC suite”, start with the DORA contract governance page for banks — it covers the obligations in plain terms and maps them to what a contract-visibility layer solves.