DORA register of information: ICT contracts under control

The register is still missing a data storage location. The cloud contract is apparently “somewhere in procurement.” The DORA register of information turns those missing details into work someone has to finish. Here’s who needs a register and how to bring the contract terms and data together.

What is the DORA regulation?

The DORA regulation sets requirements for digital operational resilience in the EU financial sector.

DORA stands for Digital Operational Resilience Act. Regulation (EU) 2022/2554 has applied since January 17, 2025. DORA is a regulation, so it applies directly in every member state without national transposition.

The goal is practical: financial firms should manage digital risks, prepare for disruptions, and understand their dependence on IT providers. ICT means information and communication technology. Behind the acronym are familiar services, including cloud hosting and business software.

Who does DORA apply to?

DORA applies to many types of financial firms, including smaller institutions that fall within its scope.

The Article 2 scope includes:

• Credit institutions, including small banks.
• Payment institutions and e-money institutions.
• Investment firms and crypto-asset service providers.
• Insurance and reinsurance undertakings.

Insurance intermediaries, including ancillary insurance intermediaries, are exempt if they qualify as microenterprises or small or medium-sized enterprises.

DORA applies the principle of proportionality: size, risk profile, and complexity matter when implementing its requirements. Certain smaller firms can use a simplified ICT risk management framework. “We’re small” still isn’t a scope assessment.

IT and SaaS providers often encounter DORA through customer contracts. A payment institution needs specific commitments and sends its software provider an addendum. Financial regulation has arrived at a team that was hoping to spend the afternoon selling software.

What are the 5 pillars of DORA?

The five DORA pillars are ICT risk management, incident management and reporting, resilience testing, ICT third-party risk management, and information sharing.

• ICT risk management: identify digital risks, set safeguards, and assign responsibilities.
• ICT-related incident management and reporting: record, assess, and handle incidents, and organize the required reporting.
• Digital operational resilience testing: check whether systems and response procedures work in practice.
• ICT third-party risk management: assess dependencies on providers and address them in contracts.
• Information sharing: exchange information about cyber threats between financial firms.

The register and contract reviews belong to third-party risk management. They’re a concrete part of DORA compliance, but they aren’t the whole program.

What is the difference between NIS2 and DORA?

NIS2 and DORA both address digital resilience; for financial firms within its scope, DORA provides the more specific rules on these topics.

That makes DORA the focus when you’re working on ICT contracts and the register of information.

What is the DORA register of information?

The DORA register of information is a continuously maintained record of all contractual arrangements for ICT services supplied by ICT third-party providers.

Article 28(3) requires financial firms to maintain and update it. It covers all contractual arrangements for ICT services, including those that don’t support critical or important functions. The register must distinguish between arrangements that support those functions and those that don’t.

You must provide the register to your competent authority on request. You must also inform the authority in a timely manner about planned arrangements supporting critical or important functions.

The ESA reporting framework uses standardized register templates set by Implementing Regulation (EU) 2024/2956. A list of provider names and contract end dates won’t cover that structure.

Financial firms keep the register for the competent authority in their country. The European Supervisory Authorities, EBA, EIOPA, and ESMA, coordinate the annual submission cycle through those national authorities.

Germany provides a concrete example. Under the BaFin reporting cycle, firms submit the full register annually, reflecting the position as of December 31 of the previous year. The submission process must be completed without errors by March 31. The next submission therefore reflects the position as of December 31, 2026, with the process completed by March 31, 2027. Other national authorities set their own submission windows within the EU cycle.

Data quality deserves time before submission week. In the ESA register dry run, only 6.5% of the 947 registers analyzed in 2024 passed all data quality checks. Partially completed registers were accepted, and errors were expected.

The practical work starts well before reporting. Provider details, services, data locations, and termination terms sit across master agreements, addenda, and service descriptions. The register needs consistent data drawn from those documents. Maintaining it is, to a large extent, contract work.

What must ICT contracts include under DORA Article 30?

ICT contracts must define services, data locations, safeguards, assistance, and termination rights; services supporting critical or important functions need additional terms.

Under Article 30(1), rights and obligations must be clearly allocated and recorded in writing. The complete contract, including service level agreements (SLAs), must be available in one written document, on paper or in another downloadable, durable, and accessible format.

What are the minimum terms for all ICT contracts?

The minimum terms for contractual arrangements covering ICT services appear in DORA Article 30(2):

• Services and subcontracting: describe all functions and services. Specify whether subcontracting is permitted for services supporting critical or important functions, and under what conditions.
• Service and data locations: state the regions or countries where services are provided and data is processed, including storage. Require advance notice of location changes.
• Service and data protection: address availability, authenticity, integrity, confidentiality, and personal data protection.
• Access and return: secure access to, recovery of, and return of data if the provider becomes insolvent, is wound down, stops operating, or the contract ends.
• Service levels: describe the agreed service levels and how they’re updated.
• ICT incident assistance: agree on assistance at no additional cost or at a cost determined in advance.
• Cooperation with authorities: require the provider to cooperate fully with competent authorities.
• Termination: define termination rights and minimum notice periods.
• Awareness and training: set the conditions for the provider’s participation in ICT security awareness programs and digital operational resilience training.

For data locations, “it’s in the cloud” is about as useful as “it’s in the office” when someone asks where the contract is. You need the agreed regions or countries.

What additional terms apply to critical or important functions?

If an ICT service supports a critical or important function, Article 30(3) requires additional contract terms:

• Precise service targets: set quantitative and qualitative targets against which performance can be measured.
• Notices and reporting: agree on notice periods and reporting duties for developments that could affect the provider’s ability to deliver the services.
• Contingency planning and security: require business contingency plans, testing of those plans, and appropriate security measures.
• Security testing support: address participation and cooperation in threat-led penetration testing (TLPT).
• Access and audit: secure unrestricted access, inspection, and audit rights. Microenterprises may agree to delegate these rights to an independent third party appointed by the provider.
• An orderly exit: agree on exit strategies with a mandatory, adequate transition period.

Under Article 30(4), the parties must also consider using standard contractual clauses developed by public authorities for specific services.

How do you build the register of information from your contracts?

Build the register by collecting your contracts, classifying the services they support, checking the required data, and tracking changes as they happen.

Step 1: Collect all ICT contracts and attachments

Gather master agreements, addenda, service schedules, and SLAs. Include subcontractor documentation. Group each agreement with its attachments and identify the current version. Cross-check the collection with IT, procurement, and accounting so an active software subscription doesn’t exist only as an invoice line.

When you handle vendor contract management, the agreement and its attachments belong together.

fynk’s Document hub keeps those documents in one place. AI import extracts details from existing PDFs, including contract parties, dates, and termination terms. Check the extracted data against the original before using it in your register.

Step 2: Classify the functions each service supports

Work with the responsible business team to establish which function an ICT service supports and whether that function is critical or important. Record the reasoning and name the person responsible.

“Critical function? Ask Thomas.” A reasonable place to start. A slightly fragile documentation policy.

In financial services, the business team’s input matters here. The contract’s name tells you little about how the service is actually used.

Step 3: Record register data in consistent fields

Structure provider details, services, supported functions, criticality, locations, notice periods, and subcontractors as fields. These are working fields for your contract collection. Check them against the complete register templates.

Use consistent names and record where each detail appears in the contract. If something is missing, mark it as open and assign someone to clarify it. An empty cell isn’t an assignment.

With Metadata, you can store these details in fynk as fields for filtering and reporting. The data stays with the contract, reducing the work of maintaining a separate spreadsheet.

Step 4: Check contracts for missing clauses

Compare each agreement against the contract requirements above. Separate the general minimum terms from the additional requirements for critical or important functions.

Create a gap list: what’s missing, which clause falls short, and who will address it? “DORA checked” doesn’t say much about what anyone found.

Use contract playbooks to turn DORA Article 30 requirements into reusable review rules. fynk’s AI review checks contracts against your playbook and flags missing or differing terms, with explanations and references to the relevant passages. Your team can assess each finding against the contract text.

Step 5: Negotiate the gaps

Discuss gaps with the provider and amend existing contracts with a DORA addendum where needed. Pay particular attention to data locations, audit rights, assistance costs, and an orderly exit.

For exit terms, establish how data will be returned, who will support the transition, and how much time the contract allows. A termination clause alone doesn’t answer those questions.

With Redlining in fynk, proposed changes and comments stay with the relevant clause. Your team and the provider work on a shared version, keeping agreed changes together.

Step 6: Track deadlines and changes

Assign owners and reminders for notice periods, exit transition periods, and annual register preparation. Review incoming notices about location changes and update the affected data.

Schedule an internal check before the register’s reference date. Discovering a missing addendum during submission turns routine data maintenance into a search party.

Tasks & reminders connects these dates to the relevant contract and a responsible person in fynk. The Audit trail records contract activity with the person and timestamp. If the authority asks about a change, you can trace its history.

fynk keeps together the contracts and contract data you use to build the register. For submission, you then map that information to the required register structure and check it for completeness.

What does DORA mean for IT and SaaS providers?

IT and SaaS providers should prepare for DORA clauses, contract addenda, and specific information requests from financial clients.

Agree internally on a DORA addendum you can use as a starting point for negotiations. Prepare reliable information on service locations, data locations, and subcontractors. Establish which audits, notices, and assistance commitments your team can actually meet.

For IT teams, an agreed set of answers saves repeated work. The storage-location question doesn’t need another tour of the same inboxes.

Track which customer signed which version and which exceptions apply. With Document templates in fynk, you reuse approved wording and start each negotiation from an agreed base.

fynk also encounters these requirements as a provider: the Pro plan includes a DORA addendum, a contractual addendum addressing financial institutions’ DORA requirements, listed in pricing.

Is a spreadsheet enough?

A spreadsheet can hold register data; you’ll still need to organize contracts, clause reviews, deadlines, and change histories alongside it.

The workbook with 14 tabs that exactly one person understands gets interesting when that person takes a vacation.

The benefit is keeping contract data, review findings, and follow-up work together with the document.

Frequently asked questions about DORA

Common DORA questions concern its legal form, application date, register deadlines, and the duties of smaller financial firms and ICT providers.

• Is DORA a regulation or a directive?

  DORA is an EU regulation. It applies directly in every member state without national transposition.

• When did DORA start to apply?

  DORA has applied since January 17, 2025.

• When is the register of information due?

  The ESAs coordinate the annual submission cycle through national competent authorities, which set their own submission windows. In Germany, the BaFin reporting cycle requires the full register annually, reflecting the position as of December 31 of the previous year, with an error-free submission process completed by March 31. The next submission reflects December 31, 2026, and must be completed by March 31, 2027.

• Do small financial firms need a register of information?

  Yes, if they fall within DORA's scope. The register obligation in Article 28(3) doesn't disappear because a firm is small. Proportionality and simplified requirements elsewhere in DORA are separate considerations. This isn't legal advice.

• Are ICT providers covered by DORA?

  The direct critical ICT provider oversight framework applies to providers designated as critical. Other IT and SaaS providers are mainly affected indirectly through their financial clients’ contract requirements.