Answer DORA questionnaires as contract terms

A DORA questionnaire works best when every answer is a term your legal, security, and service teams can keep. Under the EU's Digital Operational Resilience Act, many of those answers feed one of two things: the written contract your customer must have with you, or the register of information it keeps on every ICT contract. An answer written to impress can therefore bind you to an audit right, a service level or a notice period nobody approved. This guide works through the job in order: settle the scope of your service, ready your identifiers, map each question to its contract term, answer for your subcontractors, use certifications as evidence and commit only to operations you can run.

Who answers it and what to gather first

You answer it, as the supplier. DORA defines an ICT third-party service provider as any undertaking that provides ICT services. The questionnaire is how an EU bank, insurer or investment firm assesses you before it signs or renews a contract with you. Expect the questions now, on renewals as well as new contracts.

It sits alongside the other due diligence questionnaires your team handles. It also overlaps with the wider vendor due diligence a financial customer runs. What sets it apart is where the answers end up. Before anyone drafts, gather the documents the answers will be checked against:

• the draft contract or DORA addendum you'd sign with this customer
• a current list of every subcontractor that supports the service, with what each one does
• your current certifications and audit reports, with their scope and dates
• your incident response runbook, including how and when you notify customers
• your service level schedule and your exit and data return procedure

Then name one owner per topic before the questionnaire is split up. Legal owns anything that reads as a contract term, and security owns the control and evidence questions. Service delivery owns service levels, incident handling and exit. Whoever manages your own suppliers owns the subcontractor answers. The bid manager owns the whole response and signs it off.

Find out whether your service supports a critical or important function

Before you draft, ask your customer whether your service supports one of its critical or important functions. That one fact decides how much of the questionnaire becomes a contract term.

A yes switches on a second tier of obligations. DORA requires extra contract terms for a service that supports a critical or important function. They include full service level descriptions with precise targets. They also include unrestricted rights of access, inspection and audit for three parties: the customer, a third party it appoints and its supervisor. A yes also brings in Commission Delegated Regulation (EU) 2025/532 on subcontracting, which sets conditions on your chain of subcontractors that a non-critical service doesn't carry.

Getting the classification wrong costs you either way. Answer a critical service as if it were non-critical and you'll have described a contract the customer can't sign. Answer a non-critical service at the critical standard, and you may give away audit rights and service level detail nobody needed.

When the questionnaire doesn't state the classification, ask through the customer's clarification route. Phrase the question so it can be answered yes or no, for example: does the service under this contract support a critical or important function, or a material part of one? If no answer comes before the deadline, say in the response which basis you've answered on. Each commitment is then read on that basis.

A no doesn't take you out of scope. A service that supports nothing critical still goes into the customer's register of information, so the next section applies either way.

Have your identifiers ready for the register of information

Have your legal entity's identifier ready before you start. DORA requires each financial entity to keep a register of information on all its contractual arrangements for ICT services, and your answers supply the entries. That's why the questionnaire asks who you are, which legal entity contracts, what service you provide and who supports it.

The register covers more than critical services. Even a small, non-critical service still needs a clean identification answer.

Commission Implementing Regulation (EU) 2024/2956 is the implementing standard for the register. It sets how you are identified there:

• Its LEI or its EUID identifies a provider established in the EU.
• A provider established outside the EU is identified by LEI only.

Three practical points follow:

• Use the identifier of the entity in your group that will sign this contract, not the parent's.
• If that entity sits outside the EU and has no LEI, get one before you answer, because nothing else identifies it in the register.
• Keep the entity's registered name and identifier identical across the questionnaire and the contract. A mismatch gives the customer a data problem to resolve before it can record you.

Sort every question by the contract term it feeds

Tag every question with the DORA contract term it feeds and the person who approves it. DORA requires the rights and obligations of both parties to be clearly allocated and set out in writing, with the service level agreements in one written document. The questionnaire is where your customer collects what that document will say. An answer about where your data is stored is a first draft of the locations clause. An answer about incident support is a first draft of the assistance clause.

A questionnaire is usually organised by its author's topics, not by the contract. Sorting the questions by provision does three things. It shows which answers legal must see. It separates the terms that apply only to a critical service. And it gives every commitment one approver who answers for it.

A clause map you can copy

Use one test for anything the map doesn't cover:

• If an answer sets a number, grants a right, names a place or fixes a cost, treat it as a contract term. Send it to the team that will have to keep it.
• If it only describes how you work today, the topic owner can approve it.

Either way, the bid manager signs off the whole response and carries the accountability for what it commits the company to.

In SEQUESTO: each question in a SEQUESTO aOS project carries its own reviewer and approver. Legal approves the answers that become contract terms, and security approves the control answers before the bid manager signs off.

Answer subcontractor questions from your actual chain

List every subcontractor that actually supports the service. For a critical or important function, your customer may contract with you only if you can do three things: identify all those subcontractors, notify the customer of them, and give it the information it needs to assess them. That condition comes from the subcontracting regulation. A vague answer, such as a reference to trusted partners, gives the customer a reason not to sign.

Two further rules in the same regulation decide what you can truthfully say:

• Audit rights. Where subcontracting is allowed, the contract must require each subcontractor to grant your customer and its supervisors the same rights of access, inspection and audit that you grant.
• Changes. You may make a material change to the subcontracting only after the customer has approved it, or after a reasonable notice period has passed without objection.

So check what your own subcontracts allow before anyone answers yes to an audit question. For example, if a hosting provider's terms don't pass audit rights through, you'd be promising something you can't deliver.

For each subcontractor on your list, check three things before you answer:

1. Does it support the service you're offering this customer, or a material part of it?
2. Do your terms with it pass on the same access, inspection and audit rights?
3. Can you notify this customer of a change to it, and wait for approval or non-objection, before the change takes effect?

A no to the second or third question is a gap to raise with legal now. It isn't a detail to smooth over in the answer.

Use certifications as evidence, not as the answer

An ISO 27001 certificate or a SOC 2 report supports your answer but doesn't complete it. Your customer may not rely solely on certifications or audit reports over time. That rule comes from Commission Delegated Regulation (EU) 2024/1773, on the financial entity's ICT third-party policy. The same regulation requires the customer to check that a report's scope covers its systems and key controls, and that the report isn't obsolete.

These answers carry real weight. DORA lets financial entities contract only with ICT providers that comply with appropriate information security standards. Your security answers determine whether the contract can be signed.

Write each control answer so it stands without the attachment:

• Say what the control is and how it runs for this service.
• Point to where in the report the customer can check it.
• State the report's scope and date in the answer, so the customer doesn't have to work out whether it applies.

Two checks decide whether a report helps the answer or undermines it:

• its scope covers the service, systems and locations this customer will use
• its period is current, and you know when the next one is due

If either check fails, say so and explain what covers the gap. Don't attach the report and hope. For a critical or important function, the customer also holds unrestricted audit rights. If it can't verify something from the report, it can verify it in person. There's more on writing security answers that hold up when the report alone isn't enough.

In SEQUESTO: you attach a report such as your SOC 2 report to the answer it supports. When a new version is uploaded, every answer that cited the old one is flagged for review.

Commit only to service levels, incident and exit terms you can run

Commit only to the service levels, incident terms and exit terms your teams already run, because each one becomes a written obligation your customer can hold you to. Sometimes a question asks for more than your standard terms. When it does, say so in the answer and name the term you offer, rather than accepting the higher figure to keep the response tidy. The contract negotiation then settles the difference, with legal in the room.

Service levels and incidents

For a critical or important function, service-level descriptions must be precise enough for the customer to take corrective action when you miss a target. Give the figures your monitoring already measures, and say how you measure them.

Your incident answers tell the customer how fast it will hear from you. Answer with the notification times in your runbook. Have commercial confirm whether incident assistance is free or charged at a rate you can state now.

Exit and data return

Every ICT contract must cover access to, recovery of and return of the customer's data in an easily accessible format. This applies if you become insolvent, go through resolution, stop trading, or the contract ends. Name the format and the process you'd use. Have service delivery confirm it's a process your team has actually run.

Changes you must notify

The contract must state the locations where you provide the service and process and store data, and it must require advance notice before you change them. Material subcontracting changes also depend on the customer so that each customer can have its own notice terms. Record every commitment against the customer it was made to, in an answer library that keeps owners and review dates. The next questionnaire then repeats what you agreed rather than inventing something new.

Checklist for a DORA questionnaire response

Run this before you sign off. Each line should be true of the response you're about to submit.

• The customer has confirmed whether the service supports a critical or important function, or the response states the basis you answered on.
• The contracting entity's LEI, or its EUID if it is established in the EU, is in the response and matches the entity that will sign.
• Every question carries the DORA provision it feeds and a named approver.
• Every subcontractor supporting the service is listed, and each passes on the same access, inspection and audit rights.
• Every certification or report cited covers the service in scope and is current.
• Every service level, incident, exit and notice commitment is approved by the team that runs it and recorded against this customer.

On your next DORA questionnaire, start with the first line. Until the scope is settled, every other answer is a guess at which contract you're writing.