If you are standing up a DORA third-party programme, the first thing to get right is which article says what. Article 28 is where most teams start, and it is the right place to start — but it is an obligations framework, not a contract template. The clause-by-clause list of what has to be written into the contract is in Article 30. Confuse the two and you will draft a register procedure where you needed contract language, or cite "Article 28" at an auditor who wants Article 30(3)(e)(i).
We pulled the full text of both articles from the live DORA corpus through the gateway before writing this, so every subsection number below is the one the regulation actually uses. Here is how the two articles divide the work, what each obligation maps to in ISO 27001 and the Secure Controls Framework, and what evidence a competent authority will ask you to produce.
What Article 28 actually obligates#
Article 28 is titled "General principles", and the first subsection sets the tone: under Article 28(1), a financial entity that uses third-party ICT services "shall, at all times, remain fully responsible for compliance with, and the discharge of, all obligations under this Regulation". You cannot outsource accountability. The same subsection ties third-party risk into the broader ICT risk management framework of Article 6(1) and applies the proportionality principle.
The substantive obligations follow:
- Article 28(2) requires a strategy on ICT third-party risk, including a policy on the use of ICT services supporting critical or important functions. Microenterprises and the simplified-framework entities of Article 16(1) are carved out.
- Article 28(3) requires the register of information — the document that has become the most visible DORA deliverable. More on it below.
- Article 28(4) lists the pre-contract assessment steps: decide whether the service supports a critical or important function, check supervisory conditions, identify all relevant risks including concentration risk, run due diligence on the prospective provider, and assess conflicts of interest.
- Article 28(5) restricts you to providers that meet appropriate information security standards, with a higher bar for critical or important functions.
- Article 28(6) covers access, inspection, and audit rights, on a risk-based, pre-determined frequency.
- Article 28(7) sets the grounds on which a contract must be terminable.
- Article 28(8) requires exit strategies for critical or important functions.
Two more subsections delegate the detail: Article 28(9) tasked the European Supervisory Authorities with the implementing technical standards for the register templates, and Article 28(10) with the regulatory technical standards for the third-party policy. That delegation matters in practice — the register is not a free-form spreadsheet, it follows the ESA templates.
The register of information (28(3)) is a reporting obligation, not a list#
Teams treat the register as an inventory exercise. Article 28(3) is stricter than that. It requires you to maintain and update the register "at entity level, and at sub-consolidated and consolidated levels", and to distinguish arrangements that cover ICT services supporting critical or important functions from those that do not. That critical/important flag is the same flag that decides whether Article 30(3) applies to the contract — so the register and the contract review share a classification, and they had better agree.
The register also carries hard reporting duties. Under Article 28(3) you report at least yearly to your competent authority on the number of new arrangements, the categories of providers, and the types of contractual arrangements and services. You must make the full register, or specified sections, available on request. And you have to inform the authority "in a timely manner" about any planned arrangement supporting a critical or important function, and when an existing function becomes critical or important.
The control mapping here is governance and inventory. In the Secure Controls Framework, the gateway corpus surfaces TPM-01 — "mechanisms exist to facilitate the implementation of third-party management controls" — as the umbrella, with the inventory and review discipline supported by service-management governance such as OPS-03. In ISO 27001:2022 terms, this is Annex A.5.19 (information security in supplier relationships) plus the supplier-monitoring control A.5.22. The evidence an auditor asks for is concrete: the register itself, the dated yearly submission to the authority, the procedure that updates it when a function is reclassified, and the access-control list showing who can edit it.
Termination (28(7)) versus exit (28(8)) — they are different obligations#
This is the pair that gets conflated most often. Article 28(7) and Article 28(8) sit next to each other and sound similar, but they are separate requirements with separate evidence.
Article 28(7) is about the right to terminate. It requires that contracts be terminable in defined circumstances: a significant breach of law or contract by the provider; circumstances found during monitoring that could alter performance; evidenced weaknesses in the provider's ICT risk management — including how it ensures the availability, authenticity, integrity, and confidentiality of data; and the case where the competent authority can no longer effectively supervise you because of the arrangement. These are contract-drafting requirements: the termination clause has to enumerate grounds at least this broad.
Article 28(8) is about what happens after you decide to leave. For ICT services supporting critical or important functions, you must have exit strategies that account for provider failure, quality deterioration, and business disruption — including disruption arising from a termination under Article 28(7). The exit must be achievable without disruption to business activities, without limiting regulatory compliance, and without harming service continuity to clients. Article 28(8) also requires alternative solutions, transition plans to move the service and data to another provider or back in-house, and contingency measures. The exit plan must be "comprehensive, documented" and, per the criteria in Article 4(2), "sufficiently tested and reviewed periodically".
In control terms, 28(7) maps to contract clauses the gateway corpus expresses as TPM-05.7 ("break clauses within contracts for failure to meet contract criteria for security, compliance and/or resilience controls"). 28(8) maps to the resilience-testing side: TPM-11 ("response/recovery planning and testing are conducted with critical suppliers/providers"), backed by the contingency-planning family BCD-01, plus asset-return controls such as AST-10 for getting your data and assets back when the arrangement ends. The ISO 27001:2022 anchors are A.5.30 (ICT readiness for business continuity) and A.5.22 for the ongoing review.
The evidence split follows the obligation split. For 28(7), the auditor reads the termination clause and checks it covers all four grounds. For 28(8), the auditor wants the exit plan document, the date of the last exit test, and the test result — a plan that has never been exercised does not satisfy "sufficiently tested".
Where the contract clauses actually live: Article 30#
Article 28 tells you what to assess and what rights to secure. Article 30, "Key contractual provisions", tells you what to write. This is the article to draft from.
Article 30(1) requires the rights and obligations of both parties to be "clearly allocated and set out in writing", in one document, in a durable accessible format, with the service level agreements included.
Article 30(2) lists the minimum elements for every ICT contract, including:
- a clear, complete description of all functions and services, stating whether subcontracting of a critical-or-important service is permitted and on what conditions (30(2)(a));
- the locations — regions or countries — where services are provided and data is processed, with advance notice of any change (30(2)(b));
- provisions on availability, authenticity, integrity, and confidentiality of data, including personal data (30(2)(c));
- access, recovery, and return of data in an accessible format on insolvency, resolution, discontinuation, or termination (30(2)(d));
- service level descriptions (30(2)(e)); incident assistance at no extra or pre-agreed cost (30(2)(f)); full cooperation with competent and resolution authorities (30(2)(g)); termination rights and minimum notice periods (30(2)(h)); and participation in your security awareness and resilience training (30(2)(i)).
Article 30(3) adds the heavier set for services supporting critical or important functions: full quantitative and qualitative service-level targets (30(3)(a)); notice and reporting obligations on material impacts (30(3)(b)); a requirement for the provider to implement and test business contingency plans and maintain ICT security measures (30(3)(c)); participation in your threat-led penetration testing under Articles 26 and 27 (30(3)(d)); unrestricted access, inspection, and audit rights including for the competent authority (30(3)(e)); and exit strategies with a mandatory adequate transition period (30(3)(f)).
That last point closes the loop with Article 28(8): the exit strategy is an obligation under 28 and a contract clause under 30(3)(f). The transition period must keep the provider delivering long enough for you to migrate to another provider or to in-house solutions.
The control mapping for Article 30 is the contract-content side of third-party management. The gateway corpus carries TPM-05.2 ("applicable security, compliance and resilience requirements are included in contracts that flow-down to applicable sub-contractors and suppliers"), TPM-10 ("control changes to services by suppliers, taking into account criticality") for the location-change and service-change clauses of 30(2)(b), and the assurance controls TPM-05.6 and TPM-05.8 for first-party declarations and independent (3PAO) attestations that back the audit-right clauses. In ISO 27001:2022, the contract checklist is A.5.20 (addressing information security within supplier agreements) and A.5.21 (managing information security in the ICT supply chain).
Concentration risk and proportionality are not optional context#
Two cross-references in Article 28 carry weight. Article 28(4)(c) requires you to identify the risk that an arrangement reinforces "ICT concentration risk as referred to in Article 29". Article 29 then requires a preliminary assessment at entity level — whether a provider is "not easily substitutable", and whether you are stacking multiple critical arrangements with the same or closely connected providers. The control anchors are supply-chain risk assessment, which the corpus expresses as RSK-09.1 ("periodically assess supply chain risks associated with Technology Assets, Applications and/or Services") and the diversification control TDA-03.1 ("obtain technologies from different suppliers to minimize supply chain risk").
Proportionality runs through all of it. Article 4 lets you apply Chapter II rules in proportion to size and risk profile — but proportionality scales effort, it does not remove obligations. A small entity still needs a register and an exit plan for its critical providers; it gets to size the rigour to its risk.
The control-to-article map, compactly#
This is the crosswalk we use when an agent drafts a DORA third-party gap analysis. Every DORA reference is verified through the gateway; every SCF control ID is one the Security Controls corpus returns for the matching query.
| DORA obligation | Subsection | ISO 27001:2022 | SCF control(s) |
|---|---|---|---|
| Strategy + policy for critical functions | 28(2) | A.5.19 | TPM-01 |
| Register of information + yearly reporting | 28(3), 28(9) | A.5.19, A.5.22 | TPM-01, OPS-03 |
| Pre-contract risk assessment, due diligence | 28(4) | A.5.19 | CPL-13.1, RSK-09.1 |
| Concentration risk assessment | 28(4)(c), Art. 29 | A.5.21 | RSK-09.1, TDA-03.1 |
| Information security standards of provider | 28(5) | A.5.20 | TPM-05.2 |
| Access, inspection, audit rights | 28(6), 30(3)(e) | A.5.22 | TPM-05.6, TPM-05.8 |
| Termination grounds | 28(7), 30(2)(h) | A.5.20 | TPM-05.7 |
| Exit strategy, transition, testing | 28(8), 30(3)(f) | A.5.30 | TPM-11, BCD-01, AST-10 |
| Contract content (all services) | 30(2) | A.5.20, A.5.21 | TPM-05.2, TPM-10 |
| Address provider weaknesses | monitoring under 28 | A.5.22 | TPM-01 |
The mapping is "supports", not "satisfies". An ISO 27001 control or an SCF mechanism is evidence that you have addressed a DORA obligation; it does not discharge the obligation by itself. The auditor reads the article, then asks for the control, then asks for the artefact the control produces.
What an auditor or supervisor will ask for#
Working backward from the obligations, the evidence requests cluster predictably. For Article 28(3): the register in the ESA template, the dated yearly submission, and the reclassification procedure. For 28(4): the due-diligence file and the concentration-risk assessment for each critical arrangement — CPL-13.1 frames this exactly as "evidence of due diligence activities capable of withstanding external audit or regulatory scrutiny". For 28(7) and 30(2)(h): the termination clause with all four grounds and the notice period. For 28(8) and 30(3)(f): the exit plan, the last exit-test date, the test result, and the named alternative provider or in-house path. For 30(3)(e): the audit-right clause and either a recent audit report or the 3PAO attestation that stands in for one.
The pattern is the same one we built the gateway around: a citation is only useful if it points at the exact subsection and the exact control, and if both are real. When your agent runs a DORA gap analysis, it calls get_provision for the article text and pulls the matching control from the Security Controls corpus, so the output reads "Article 30(3)(f) DORA → A.5.30 → TPM-11, last exit test: missing" rather than a vague "third-party section". A wrong subsection number fails validate_citation instead of reaching the report.
Run it against your own contracts#
The fastest way to see the split between obligation and clause is to point an MCP client at the gateway and have it read both articles for you.
- Connect your client —
https://gateway.ansvar.eu/mcp, OAuth 2.1. Works with Claude, Copilot in VS Code and Studio, Cursor, or any MCP client. The free tier gives you 100 searches a day, enough to read DORA end to end. - Ask: "Use the Ansvar gateway to fetch DORA Article 28 and Article 30, and build a checklist of every clause our ICT contracts for critical functions must contain." The agent calls
get_provisionand returns the cited checklist. - Hand it a contract and ask it to flag missing clauses against Article 30(2) and 30(3). The gaps come back article-anchored.
The same surface drives the wider compliance work — see how the gateway routes and enriches, the jurisdiction and framework coverage, and the quickstart. For the adjacent regimes most DORA programmes touch, the AI Act readiness and threat-modeling surfaces use the same citation discipline.
DORA's third-party chapter is precise about which article carries which duty. Citing it precisely — Article 28 for the obligations, Article 30 for the clauses, the right subsection for the right control — is the difference between a register that passes review and one that invites a follow-up question you did not budget for. The gateway exists so that precision is the default, not the thing you check by hand at the end.