DORA ICT Third-Party Risk Policy: RTS 2024/1773’s 10 Articles Clause by Clause, Who Is Exempt, and the Yearly Board Review

A vendor management policy written for procurement will not pass as a DORA ICT third-party risk policy. Commission Delegated Regulation (EU) 2024/1773 asks for something narrower and harder: a policy that governs ICT services supporting critical or important functions across the whole life of each contract, with named owners, a yearly board review and an exit plan for each arrangement. This guide walks the regulation clause by clause and sets out who does not have to write one at all, the part summaries of the RTS tend to skip.

Who must write the policy, and who is exempt

In plain terms: every financial entity under DORA needs the Article 28(2) policy that the RTS specifies, except two groups, the five entity types in Article 16(1) and microenterprises. Being exempt from that policy does not exempt you from Chapter V.

The duty comes from DORA, Regulation (EU) 2022/2554, Article 28(2): “financial entities, other than entities referred to in Article 16(1), first subparagraph, and other than microenterprises, shall adopt, and regularly review, a strategy on ICT third-party risk”. That strategy “shall include a policy on the use of ICT services supporting critical or important functions provided by ICT third-party service providers”. RTS 2024/1773 was adopted under Article 28(10) to specify that policy, so its requirements on “the policy” follow Article 28(2)’s scope.

Entity	Article 28(2) policy under RTS 2024/1773?	Third-party duties that still apply
Any other financial entity in DORA Article 2(1)	Yes, in full	All of Articles 28 to 30
Microenterprise: fewer than 10 persons and annual turnover and/or balance sheet total not exceeding EUR 2 million; never a trading venue, central counterparty, trade repository or central securities depository (Article 3(60))	No	A management-body-approved policy under Article 5(2)(h), and the rest of Articles 28 to 30, including the register of information (28(3)), pre-contract checks (28(4)), exit strategies (28(8)), concentration risk (29) and contract terms (30), with the option to agree that audit rights are delegated to an independent third party appointed by the provider
Article 16(1) entities: small and non-interconnected investment firms; payment institutions exempted under Directive (EU) 2015/2366; institutions exempted under Directive 2013/36/EU where the Member State did not use the Article 2(4) option; electronic money institutions exempted under Directive 2009/110/EC; small institutions for occupational retirement provision	No	“identify key dependencies on ICT third-party service providers” (16(1)(e)); identify all critical or important functions supported by ICT third-party providers (RTS 2024/1774 Article 30(2)); the rest of Articles 28 to 30, including 28(3), 28(4), 28(8), 29 and 30

The microenterprise row surprises people. Article 5(2)(h) requires the management body to “approve and periodically review the financial entity’s policy on arrangements regarding the use of ICT services provided by ICT third-party service providers”, and Article 5 carves microenterprises out only of paragraph 3, the dedicated monitoring role. So a microenterprise still has a third-party policy to approve; it just isn’t bound to the RTS’s detailed content. Article 16(1) entities differ: Article 16(1) switches off Articles 5 to 15, so neither Article 5(2)(h) nor Article 28(2) reaches them.

One question the text leaves open. A few RTS provisions speak to “financial entities” directly rather than to “the policy”, for example Article 6(4) (ensure an appropriate level of assurance) and the first sentence of Article 8(3) (don’t rely solely on certifications over time). Whether those bind an entity that is not required to have the policy is not stated. One reading limits the whole RTS to Article 28(2) entities; the other applies those sentences to everyone. An exempt entity should record which reading it takes and why.

For entities in scope, the parent that prepares the consolidated or sub-consolidated financial statements “shall ensure that the policy is implemented consistently in all financial entities that are part of the group” (RTS Article 2). Recital 5, which is not binding, states that intra-group ICT providers “should be considered as ICT third-party services providers”. If your scope question is about a payments or lending model, see our fintech DORA scope map.

Where the policy sits, and the sentence the final RTS dropped

In plain terms: the policy is part of a strategy, the strategy is part of your ICT risk management framework, and the board approves the policy under DORA, not under the RTS.

Article 28(2) places the policy inside the strategy on ICT third-party risk, “taking into account the multi-vendor strategy referred to in Article 6(9), where applicable”. Approval sits in Article 5(2)(h). No article of the RTS imposes the adoption itself; only Recital 6 mentions “the adoption and review, at least once per year, of the policy”. The ESAs’ final draft, Joint Committee report JC 2023 84 of 10 January 2024, opened its Article 3 with “the management body of a financial entity shall adopt a written policy”. That sentence is not in the regulation the Commission adopted on 13 March 2024; the published Article 3(1) starts with the review duty.

In practice nothing is lost, since a policy that must “specify”, “assign” and “set out” reporting lines can’t exist unwritten. But the approval minute should cite DORA Articles 28(2) and 5(2)(h) as the basis for adoption, not “RTS Article 3(1)”, where a reviewer checking the Official Journal will find a review duty only.

Two status facts belong in the policy’s legal-basis section. The EUR-Lex record for Delegated Regulation 2024/1773 gives 15 July 2024 as its entry into force and lists no corrigendum (checked 4 November 2026). DORA itself has applied since 17 January 2025 (Article 64). The ESAs also say they built the draft “considering already existing specifications provided in Guidelines on outsourcing arrangements”. So an existing EBA, EIOPA or ESMA outsourcing policy is a reasonable structural starting point. Its scope is not, because DORA covers ICT services that are not outsourcing.

Articles 1 to 3: proportionality and governance, clause by clause

In plain terms: Article 1 tells you what to weigh, Article 2 covers groups, and Article 3 sets the governance text the policy must contain.

Each row below follows the text of Delegated Regulation (EU) 2024/1773. The third column is our drafting suggestion, not law.

Clause	What the RTS requires	What to write
Art 1	Weigh size, risk profile and ten complexity elements, from service type, provider location and where data is processed and stored, to concentration, transferability and the impact of disruption	A tiering rule that sets the depth of due diligence, monitoring and exit testing per tier
Art 2	Parent ensures consistent group implementation	Group clause plus entity annexes
Art 3(1)	Management body reviews the policy at least once a year; changes implemented “in a timely manner”; implementation timeline documented	Review month, owner, change log with target dates
Art 3(2)	A methodology for deciding which ICT services support critical or important functions, and when it is applied and reviewed	The DORA Article 3(22) test and reassessment triggers
Art 3(3)	Responsibilities for approval, management, control and documentation; skills kept in-house to oversee contracts	A RACI and a skills statement
Art 3(4)	Provider assessed to have sufficient resources for you to meet your legal duties	A resources check in due diligence
Art 3(5)	Name the role or senior manager monitoring the contracts, their cooperation with control functions, and the content, documents and frequency of reports to the management body	The role (not the person) and the reporting cycle
Art 3(6)	Contracts consistent with DORA Article 6 (framework), 9(4) (information security policy), 11 (ICT business continuity policy) and 19 (incident reporting)	Cross-references to those four documents
Art 3(7)	Critical ICT services subject to independent review and in the audit plan	Put them in the internal audit universe
Art 3(8)	State that contracts don’t relieve the entity of its obligations, don’t prevent supervision, require provider cooperation with authorities, and give access to data and premises	The four statements, close to verbatim

DORA only says “regularly”. The ESAs explained the tighter rule in paragraph 20 of their final report: a yearly review was “seen as necessary considering the rapid expansion of the provision of ICT services” by third parties, and “in case, there are no changes, then the process will still not be burdensome”. There is a second, separate review. Under DORA Article 28(2) the management body must “regularly review the risks identified” in contracts supporting critical or important functions. That one concerns the risks, not the policy text. Put both on the same yearly agenda item and minute them separately, so each duty has its own evidence.

Articles 4 to 7: planning, risk assessment, due diligence and conflicts

In plain terms: the policy covers the whole contract life cycle, and before signing you define the need, assess nine risk types, test the provider on six points and check for conflicts of interest.

Article 4 sets six life-cycle items the policy must cover “at least”: management body involvement; planning (risk assessment, due diligence, approval of new or materially changed contracts); involvement of business units and internal controls; implementation, monitoring and management; documentation, taking the register of information into account; and exit and termination.

Article 5, the ex-ante risk assessment. Business needs must be defined “before a contractual arrangement is concluded”. The risk assessment then runs at entity level and, where applicable, at consolidated and sub-consolidated level, and covers nine named risks: operational, legal, ICT, reputational, protection of confidential or personal data, data availability, data location, provider location and ICT concentration at entity level. The last links to DORA Article 29, which asks whether the provider is “not easily substitutable” and whether you already hold several critical contracts with the same or closely connected providers.

Article 6, due diligence. The selection process must take into account whether the provider is intra-group. Before signing, you assess whether the provider:

1. has the reputation, expertise, resources, information security standards, organisation, risk management, internal controls and any required authorisations;
2. can monitor technological developments and adopt ICT security leading practices;
3. uses or intends to use subcontractors for the service or material parts of it;
4. is located in, or processes or stores data in, a third country, and whether that raises operational or reputational risk or exposure to “restrictive measures, including embargos and sanctions”;
5. consents to contract terms that make audits possible, “including onsite”, by you, appointed third parties and authorities;
6. “acts in an ethical and socially responsible manner”, including respect for human rights, children’s rights and “the prohibition of child labour”, environmental principles and working conditions.

Point 6 looks out of place in a resilience regulation. Several consultation respondents asked for it (then numbered Article 7(1)(e)) to be deleted, arguing that it exceeded the RTS mandate and did not address DORA’s resilience aims. The ESAs replied that these risks “need to be managed throughout the supply chain” and recorded “No change”. Your questionnaire for critical ICT providers therefore needs an ESG section.

Article 6(2) to (4) make you set a required level of assurance and choose how to reach it from five sources: your own audits or independent assessments, independent audit reports obtained by the provider, the provider’s internal audit reports, third-party certifications, and other relevant information. “Where appropriate, more than one element” must be used. For your most critical providers, plan on combining at least two.

Article 7, conflicts of interest. The policy sets measures to identify, prevent and manage conflicts before contracting, with ongoing monitoring afterwards. For intra-group providers, decisions on conditions, “including the financial conditions”, must be “taken objectively”. One way to evidence that is an arm’s-length pricing file for the group IT company.

The policy also has to plug into DORA Article 28(4), which requires five steps before any ICT contract: assess whether it supports a critical or important function, check supervisory conditions for contracting, assess all relevant risks including concentration, complete due diligence, and assess conflicts of interest. Article 28(3) adds a step policies often omit: inform the competent authority “in a timely manner about any planned contractual arrangement” for a critical or important function. Put that notification in the approval workflow, before signature. For the NIS2 side of supplier risk in finance, see our guide to finance supply chain security.

Articles 8 to 10: contract clauses, monitoring and exit

In plain terms: the contract must be written and contain DORA’s mandatory terms, certificates can’t carry the assurance forever, monitoring results feed back into risk, and every critical arrangement needs its own tested exit plan.

Article 8, contractual clauses. Contracts must be “in written form” and include all elements of DORA Article 30(2) and (3): nine for every ICT contract and six more for those supporting critical or important functions: full service-level descriptions with precise targets, notice periods and reporting obligations, implemented and tested business contingency plans with ICT security measures, participation in TLPT, ongoing monitoring with unrestricted access and audit rights, and exit strategies with a mandatory transition period. Article 8(2) lists the ways to exercise audit and testing rights: your own internal audit or an appointed third party, and where appropriate pooled audits and pooled ICT testing “including threat-led penetration testing”, third-party certifications, and the provider’s audit reports.

Article 8(3) decides whether your provider’s SOC 2 report or ISO/IEC 27001 certificate can carry the assurance. Neither is named in the law, but both are certifications or audit reports in its sense. The eight conditions, with the evidence that shows each is met:

Art 8(3)	Condition	Evidence to keep
(a)	Satisfied with the provider’s audit plan for the contracts	Reviewed audit plan, dated
(b)	Scope covers the systems and key controls you identified	Scope-to-control mapping
(c)	Content assessed on an ongoing basis; reports not obsolete	Review notes per report period
(d)	Key systems and controls covered in future versions	Provider commitment or clause
(e)	Satisfied with the aptitude of the certifier or auditor	Auditor accreditation check
(f)	Widely recognised standards, with a test of operational effectiveness of key controls	Report type confirmed (a design-only report lacks this test)
(g)	Contractual right to request scope changes at a reasonable frequency	Clause reference
(h)	Contractual right to individual and pooled audits at your discretion	Clause reference

Article 8(4) requires material changes to be formalised in a document “dated and signed by all parties”, and the policy to specify the renewal process. Providers that change online terms by notice alone need a clause that routes material changes through that signed step.

Article 9, monitoring. Contracts must set measures and key indicators for ongoing monitoring, including the confidentiality, availability, integrity and authenticity of data, plus measures when service levels are missed, “including contractual penalties where appropriate”. Providers must send periodic, incident, service delivery, ICT security and business continuity reports. Article 9(3) says the documented assessment updates “the financial entity’s risk assessment referred to in Article 6”. Article 6 of the RTS is due diligence; the ex-ante risk assessment is in Article 5. Until the reference is corrected, the safer drafting feeds monitoring results into both. Article 9(4) adds remediation of provider shortcomings “within a defined timeframe, taking into account the materiality” of each one.

Article 10, exit. The policy must require “a documented exit plan for each contractual arrangement”, reviewed and tested periodically, that considers three scenarios: unforeseen and persistent service interruptions, inappropriate or failed service delivery, and unexpected termination. Each plan must be “realistic, feasible, based on plausible scenarios and reasonable assumptions”, with a schedule that fits the contract’s exit and termination terms. This sits on top of DORA Article 28(8), which requires that you can exit without disrupting your business, compliance or client service.

Who owns which clause

In plain terms: the board approves and reviews, one named senior role monitors, and ICT risk, legal and audit each own a slice.

Role	Owns	Legal anchor
Management body	Approves the policy, reviews it yearly, reviews contract risks	DORA Art 5(2)(h), 28(2); RTS Art 3(1), 4(a)
Senior manager or monitoring role	Monitors critical contracts, reports to the board	DORA Art 5(3); RTS Art 3(5)
CISO / ICT risk function	Criticality method, risk assessment, security due diligence, KPIs, exit testing	RTS Art 3(2), 5, 6, 9, 10
Legal / compliance	Article 30 clauses, signed amendments, authority notification, conflicts	DORA Art 28(3), 30; RTS Art 7, 8
Internal audit	Independent review of critical ICT services	RTS Art 3(7), 9(2)(e)
Business owner / procurement	Business needs, selection, register entry	RTS Art 5(1); DORA Art 28(3)

For a small firm several rows collapse into one or two people, which Article 1’s proportionality allows. What it does not allow is an unnamed owner. If you run a 30-person firm, the fastest workable version names you as the Article 3(5) role, sets a short quarterly report to the board, and tiers providers so that only the two or three most critical get the full Article 6 and Article 10 treatment.

Gap check before your next annual review

In plain terms: most entities start from an outsourcing or vendor policy, and these gaps appear when you hold one against the RTS. The effort ratings are our estimate for a mid-sized entity, not a regulatory measure.

Typical current state	What RTS 2024/1773 requires	Effort
Scope = “outsourcing”	ICT services supporting critical or important functions, intra-group included	Medium
Board approved once, at launch	Yearly review, documented change timeline (Art 3(1))	Low
No ESG or sanctions questions	Art 6(1)(d) and (f)	Low
Vendor SOC 2 report as sole assurance	Art 8(3) conditions; no sole reliance over time	High
Exit plan only for the largest provider	One per arrangement, reviewed and tested (Art 10)	High

Keep the policy consistent with your information security policy too: under RTS 2024/1774 Article 11(2), entities must consider a clear allocation of information security roles with their ICT providers, which for Article 28(2) entities follows “the financial entity’s policy on the use of ICT services supporting critical or important functions”. The DORA compliance hub shows how the policy, the register, the contract clauses and the exit plans fit together.

FAQ

Does a microenterprise need an ICT third-party risk policy under DORA?

Not the Article 28(2) policy specified by RTS 2024/1773. Its management body must still approve and periodically review a policy on ICT third-party arrangements under DORA Article 5(2)(h), and the rest of Articles 28 to 30 still applies.

Can we rely on our provider’s SOC 2 report or ISO 27001 certificate?

Partly. Article 8(3) permits reliance only when all eight conditions are met, and the entity “shall not over time rely solely” on certifications or audit reports. Keep your own audit right in the contract.

Do intra-group IT companies count as ICT third-party service providers?

Yes for this policy. Recital 5 says they should be considered ICT third-party providers, Article 6(1) requires the selection process to take into account whether a provider is intra-group, and Article 7(2) requires objective decisions on their conditions.

Is the policy the same as the register of information?

No. The register (DORA Article 28(3)) records all ICT contracts. The policy governs how contracts supporting critical or important functions are planned, signed, monitored and exited, and Article 4(e) of the RTS requires it to take the register into account.

What to do next

Start with scope. Confirm whether Article 28(2) applies to you at all; if you are a microenterprise, write the lighter Article 5(2)(h) policy rather than none. If you are in scope, draft against the clause table above, tier your providers on Article 1’s ten factors, and test your largest provider’s assurance package against the eight Article 8(3) conditions before the next board review. Bring the policy review, the risk review and the change timeline to that meeting as separately minuted items.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Sources

• Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 on digital operational resilience for the financial sector (DORA), Articles 3, 5, 16, 28, 29, 30 and 64. EUR-Lex, OJ L 333, 27.12.2022.
• Commission Delegated Regulation (EU) 2024/1773 of 13 March 2024 on the policy for ICT services supporting critical or important functions. EUR-Lex, OJ L 2024/1773, 25.6.2024.
• EUR-Lex document information page for Delegated Regulation (EU) 2024/1773 (dates, legal basis, no corrigendum listed; checked 4 November 2026).
• Commission Delegated Regulation (EU) 2024/1774 of 13 March 2024 on ICT risk management tools, methods, processes and policies and the simplified framework, Articles 11(2) and 30(2); its EN corrigendum of 15 May 2025 affects Article 22 only.
• Joint Committee of the European Supervisory Authorities, JC 2023 84, Final report on draft RTS to specify the policy on ICT services supporting critical or important functions, 10 January 2024.