Last reviewed: August 2026
Contract governance for financial entities in the DORA era
Most financial entities are running that obligation on shared folders and a spreadsheet.
Ten questions, about two minutes, no email.
Where does your entity stand on the contract side?
You have done this once. The second cycle is where it gets decided.
The first submission was a project. Everything after it is a routine, and the difference between the two is whether the contract picture stayed current in between or had to be rebuilt from memory and shared folders.
The next register references your arrangements as at 31 December, which is 18 weeks away. Everything that has to be true by then is decided before December, not in February.
The numbers
8.6% of annual contract value leaks through poor contract governance: missed renewals, unenforced clauses, unapplied discounts (WorldCC / Deloitte, 2023). For a bank, DORA turns that silent cost into an explicit supervisory finding.
DORA has applied to ~20 categories of financial entities (banks, payment and e-money institutions, investment firms, insurers and more) since 17 January 2025 (Regulation (EU) 2022/2554).
Registers of information are submitted annually, referencing 31 December data, in the ESAs’ xBRL-CSV format.
European supervisors consistently identify Articles 28–30, the register and contract provisions, as the area with the largest compliance gaps across financial entities.
Why is this hardest for smaller financial entities?
DORA scales with proportionality (Article 4): the depth of your ICT risk framework may reflect your size and risk profile, and specific smaller entity types qualify for the simplified framework of Article 16. What proportionality does not do is remove the third-party contract obligations. The register, the Article 30 clauses and the exit strategies still apply.
That leaves smaller institutions in a squeeze:
- Too regulated for spreadsheets. An Excel inventory and per-department network folders cannot demonstrate complete, current contract coverage to a supervisor.
- Too small for enterprise GRC. The platforms built for this, enterprise GRC suites, are priced and scoped for institutions with dedicated third-party-risk teams. An entity with a few hundred employees gets the same obligation with a fraction of the tooling budget.
- The knowledge is concentrated. In smaller institutions, contract history often lives with a handful of long-tenured people. DORA’s register asks for it in structured, reportable form.
The DORA Contract Governance Kit
Checklists, register field maps and an annual-cycle calendar for the contract side of Articles 28 to 30: the Article 30 clause checklist in both tiers, which register fields come from the contract and which do not, a cycle calendar you fill with your own authority’s deadline, and the internal memo for collecting contracts from department owners.
Or write to press@bizsupply.ai with “DORA Kit” in the subject and we’ll send it.
Where does bizSupply fit, and where doesn’t it?
bizSupply is not a GRC platform and does not claim to make you DORA compliant. It solves the layer underneath, the one every DORA contract obligation depends on: knowing what contracts you have, what’s in them, and when they change.
| What DORA needs from you | What bizSupply does today |
|---|---|
| A complete inventory of supplier contracts | Discovers contracts across mailboxes, drives, forwarding and manual upload, including the ones nobody remembered, into one centralized inventory |
| The terms that populate your register and governance | Extracts the metadata: parties, prices, renewal dates, notice periods, penalty clauses, payment terms |
| Contracts renewed or remediated on time, not discovered expired | Renewal control: alerts and triggers on renewal dates and notice windows, replacing the spreadsheet |
| Negotiating leverage when contracts come up for remediation | Benchmarking: compares your contracted costs so renegotiation and DORA-driven repapering start from data |
What bizSupply is not:
- Not a GRC or regulatory-reporting tool. It does not generate or submit your xBRL-CSV register. It maintains the contract inventory and metadata your register team draws from.
- Not a compliance certification, and not legal advice. Your DORA obligations remain yours; bizSupply gives the contract-side evidence base.
- Not bizAPIs. bizAPIs is Infosistema’s compliance-infrastructure API product (KYC, registry data). bizSupply is supplier-contract visibility. Same group, different products, different jobs.
- Not a CLM deployment. No six-month implementation: contract discovery runs on what your inboxes and drives already contain. If you need a six-month implementation to understand your contracts, you already lost.
If your institution is somewhere between “the auditor asked for our contract register” and “we can’t justify an enterprise GRC suite”, the place to start is the foundation every DORA contract obligation depends on: a complete inventory, extracted terms, and renewal control. That is what bizSupply does today.
Under evaluation for the roadmap
None of these are built today. Conversations with financial institutions keep raising the same DORA-specific needs, and we are evaluating them for the roadmap, and interest from institutions directly drives their priority:
- ICT-supplier tagging and criticality views aligned to register-of-information categories
- DORA-addendum and remediation tracking: which contracts have the addendum, which need repapering
- Contract-to-invoice reconciliation
- Support for ICT third-party risk assessment
If one of these would change how your institution handles DORA contract governance, tell us. That signal is what moves an item from evaluation to development.
Items under evaluation are not commitments. Status as of August 2026.
Show the regulatory referenceWhat DORA requires of your supplier contracts, the annual register cycle, and all fifteen Article 30 clauses, clause by clause.
In 30 seconds
- DORA requires financial entities to maintain, and submit annually, a register of information covering every contractual arrangement with ICT third-party service providers.
- Article 30 prescribes mandatory contract clauses, with a stricter tier for contracts supporting critical or important functions, including exit strategies and audit rights.
- Supervisors consistently identify the third-party provisions (Articles 28–30) as the area with the largest compliance gaps: incomplete registers, missing criticality classifications, non-conforming clauses.
- bizSupply gives banks the contract-side foundation this depends on: find every supplier contract, extract its terms, and control renewals.
Since 17 January 2025, the EU’s Digital Operational Resilience Act (DORA, Regulation (EU) 2022/2554) has made every ICT supplier contract in a financial entity a regulated object: inventoried in a register, remediated with mandatory clauses, monitored for renewals, exits and subcontracting. Most financial entities are running that obligation on shared folders and a spreadsheet.
Most financial entities don’t have a contract problem. They have a visibility problem, and DORA just made visibility a regulatory requirement.
What does DORA require of your supplier contracts?
DORA’s ICT third-party risk chapter (Articles 28–30) makes contract governance a supervisory matter. In practical terms, a bank must:
- Keep a register of information (Article 28(3)): a structured inventory of all contractual arrangements with ICT third-party service providers, at entity and, where applicable, consolidated level, distinguishing arrangements that support critical or important functions (functions whose disruption would materially impair the bank’s financial performance, or the soundness or continuity of its services).
- Report it annually to the competent authority, in the ESAs’ standard templates and machine-readable format.
- Assess before signing (Article 29): due diligence and ICT concentration-risk assessment before entering arrangements.
- Remediate the contracts themselves (Article 30): a baseline set of mandatory provisions in every ICT service contract (service descriptions, data-processing locations, data protection, access/recovery/return of data on termination, notice periods, incident assistance, termination rights), plus an enhanced tier for critical or important functions: precise quantitative and qualitative performance targets, unrestricted audit and inspection rights, participation in threat-led penetration testing (TLPT), and exit strategies with an adequate transition period so the bank can migrate providers or take services in-house without disruption (Article 28(8)).
- Control subcontracting: know when your providers subcontract functions, and keep contractual visibility down that chain.
Full text: Regulation (EU) 2022/2554 on EUR-Lex. Sector guidance: the EBA’s DORA hub and the ESAs’ register-of-information materials.
The register of information is now an annual routine, not a one-off project
The first submission cycle ran in 2025. From now on it recurs every year: registers reflect the state of your contractual arrangements at 31 December, national authorities collect them in the first quarter, and forward them to the ESAs. In 2026, national deadlines fell between mid-February and late March, ahead of the ESAs’ end-of-March consolidation, in the mandated xBRL-CSV format.
Which means the real question is not “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.
What Article 30 actually requires, clause by clause
Article 30(2) sets a baseline for every ICT service contract. Article 30(3) adds a second tier where the service supports a critical or important function. Both tiers apply to that contract, so an enhanced-tier arrangement carries all fifteen.
| Ref | What the contract must contain (summary) |
|---|---|
| 30(2)(a) | Complete description of all functions and ICT services, indicating whether subcontracting of a service supporting a critical or important function is permitted and on what conditions |
| 30(2)(b) | Locations and regions where data is processed and stored, with advance notification of changes |
| 30(2)(c) | Data protection provisions covering availability, authenticity, integrity and confidentiality |
| 30(2)(d) | Access to, recovery and return of personal and non-personal data on the provider’s insolvency, resolution or discontinuation of business, or on termination |
| 30(2)(e) | Service level descriptions, kept updated |
| 30(2)(f) | Incident assistance, at no additional or at predetermined cost |
| 30(2)(g) | Cooperation with competent authorities and resolution authorities |
| 30(2)(h) | Termination rights, with minimum notice periods |
| 30(2)(i) | Conditions for participation in security awareness and digital operational resilience training |
| Ref | What the contract must contain (summary) |
|---|---|
| 30(3)(a) | Full service level descriptions with precise quantitative and qualitative performance targets |
| 30(3)(b) | Notice and reporting obligations for material developments affecting the service |
| 30(3)(c) | Requirement to implement and test business contingency plans, and to have ICT security measures, tools and policies in place |
| 30(3)(d) | Participation and full cooperation in the entity’s threat-led penetration testing (TLPT) |
| 30(3)(e) | Ongoing monitoring, including unrestricted rights of access, inspection and audit |
| 30(3)(f) | Exit strategies with a mandatory adequate transition period |
Summaries, not quotations. The binding text is Regulation (EU) 2022/2554, Article 30.
Frequently asked questions
What does DORA require banks to do about ICT supplier contracts?
Three things: maintain a register of information covering every contractual arrangement with ICT third-party service providers (Article 28(3)), submit it annually to the competent authority, and ensure the contracts themselves contain DORA’s mandatory provisions (Article 30), with stricter requirements, including exit strategies and audit rights, where the service supports a critical or important function.
What is the DORA register of information?
A structured, machine-readable inventory of all of a financial entity’s contractual arrangements with ICT third-party providers, maintained at entity (and where applicable consolidated) level, distinguishing arrangements that support critical or important functions. It follows the ESAs’ templates and is submitted annually in xBRL-CSV format, referencing 31 December data.
When is the register of information due?
Annually. National competent authorities set collection windows in the first quarter (in 2026, typically mid-February to late March, varying by country), then forward registers to the ESAs by end of March. Check your national regulator’s exact deadline.
What contract clauses does DORA Article 30 require?
A baseline for all ICT service contracts: complete service descriptions, data-processing locations, data-protection provisions, access/recovery/return of data on termination or insolvency, service levels, incident assistance, cooperation with authorities, and termination rights with minimum notice. For critical or important functions, additionally: precise quantitative and qualitative performance targets, expanded incident notification, unrestricted audit/access/inspection rights, TLPT participation, and exit strategies with an adequate transition period.
Does DORA apply to small banks?
Yes. Proportionality (Article 4) scales the depth of the ICT risk-management framework, and Article 16 gives certain smaller entity types a simplified framework, but the third-party provisions, including the register of information and Article 30 contract clauses, apply regardless of size.
Does this apply beyond banks?
Yes. DORA covers roughly twenty categories of financial entities (payment and e-money institutions, investment firms, fund managers, insurers and more), and the register-of-information and Article 30 obligations described here apply to them in the same way. Everything on this page reads across.
Is bizSupply a DORA compliance or GRC tool?
No. bizSupply is a contract-visibility product: it discovers supplier contracts across your mailboxes and drives, extracts their commercial terms, and controls renewals. That is the contract-side foundation DORA governance depends on, but register generation, submission and compliance ownership sit with your compliance function and its reporting tools.
Does bizSupply generate the xBRL-CSV register submission?
No. bizSupply maintains the contract inventory and metadata that your register is built from; it does not produce or file regulatory submissions.
Does bizSupply have DORA-specific features like addendum tracking or ICT-supplier classification?
Not today. These are under evaluation for the roadmap, and interest from financial institutions drives prioritization. What bizSupply provides today is the contract inventory, metadata extraction and renewal control that those capabilities would build on.
How is bizSupply different from bizAPIs?
Both are Infosistema products. bizAPIs provides compliance-infrastructure APIs (KYC, official registry data) for building verification flows. bizSupply is a supplier-contract visibility product for finance and third-party-management teams. They solve different problems and share no data.
How do I know if our ICT contracts meet the DORA Article 30 clause requirements?
Article 30(2) sets nine baseline provisions for every ICT service contract, and Article 30(3) adds six more where the service supports a critical or important function. The fifteen requirements are listed in full on this page. Working through your own contracts against them is what the contract-side work consists of.
How can I check where our entity stands on the contract side of DORA?
Ten questions on this page cover the three things DORA’s third-party chapter depends on: whether you can see your ICT supplier contracts, whether you know what is in them, and whether keeping that current is somebody’s job. Your answers stay in your browser and nothing is sent unless you ask us to email you the summary.
What belongs in an ICT supplier contract inventory under DORA?
Enough to answer Article 28(3) without reopening the contracts: who the provider is, which of your services the arrangement supports, whether that service is a critical or important function, the renewal and notice dates, whether subcontracting is permitted, and which Article 30 provisions the contract already carries.
This page is general information about Regulation (EU) 2022/2554 (DORA) and bizSupply’s capabilities, last reviewed on the date shown above. It is not legal or regulatory advice. Obligations under DORA rest with each financial entity; consult your compliance function and legal counsel. bizSupply is a product of Infosistema (Joyn group).