Article 28 ICT third-party risk: requirements and evidence

What DORA Article 28 requires for ICT third-party risk

Article 28 is the general rule for managing ICT third-party risk inside the ICT risk framework, and it applies whenever a financial entity buys ICT services from someone else, whether that is a cloud platform, a managed hosting provider or a vendor running software the entity depends on. The rule is clear on one point: the financial entity remains fully responsible for compliance at all times, regardless of who operates the service. Outsourcing the work does not outsource the accountability, so the first question for any compliance lead is whether the entity can show its own management body, its own risk register and its own contracts covering every ICT arrangement it relies on.

The risks Article 28 targets are the ones that turn a supplier failure into a systemic problem: concentration on a few providers, weak oversight of what those providers actually do, and lock-in that makes it impossible to leave without disrupting critical operations. Applying this in practice is harder than the principle suggests. Many organizations do not hold a complete inventory of ICT services, including software-as-a-service tools bought by business units and self-hosted open-source components with a commercial support contract. Mapping which arrangements support a critical or important function often lives in people's heads rather than in documents. And many contracts were signed before DORA applied, so they lack the audit, termination and exit terms the Article expects. Confirm your own timeline with counsel, since the transition arrangements depend on the contract dates and your competent authority's expectations.

Start with a gap check. List every ICT arrangement, flag those touching a critical or important function, and compare each contract against the termination and exit expectations of Article 28(7) and 28(8). Where a contract falls short, decide whether to renegotiate, add an exit plan you can actually test, or move the workload. Self-hosted open-source platforms can change this calculation, because the entity controls the runtime and data, but the entity still owns the risk analysis, the due diligence on any support partner and the documentation proving it.

Which ICT services and providers fall under Article 28

Article 28 applies only to the ICT services a financial entity actually contracts for, and the depth of the work depends on how each service is classified. The cards below cover the scoping decisions that determine which arrangements enter the register of information, which need pre-contract assessment, and which trigger the exit and termination requirements.

What counts as an ICT service

Article 28 reaches digital and data services provided through ICT systems on an ongoing basis, including software, platforms, hosting and data services. Start from the contract inventory and ask, for each arrangement, whether the provider supplies a service through ICT systems that the entity relies on. Record borderline cases, such as one-off consultancy or hardware purchases with no ongoing service, with the reasoning, so an assessor can see the decision was made deliberately.

Critical or important function test

Whether a service supports a critical or important function changes almost every later step, including the planned-arrangement notice, the stricter contract clauses and the tested exit plan. Map each service to the business functions it supports and document who made the call and on what basis. Confirm the definition against the wording of Article 28 and the supporting technical standards before relying on a internal shortcut.

Intra-group ICT providers

Services bought from another entity in the same group still fall under Article 28 when they are ICT services. Group arrangements can be lighter on paper, but they still need to appear in the register of information and be assessed for concentration and dependency risk. Confirm how the group structure, service agreements and any sub-consolidated reporting apply to the entity in question.

Cloud and hosting providers

Cloud platforms, managed hosting and colocation usually bring subcontracting chains, data location questions and concentration risk that a single contract does not show. Trace which cloud services sit under each business service and which of them are themselves provided by further parties. Ask the provider for its subcontractor list and confirm how its exit and data return terms work in practice.

Self-hosted open-source software

Open-source software that the entity installs and runs in its own infrastructure is not always a third-party contract, but the support, maintenance, managed service or hosted component bought from a vendor usually is. Separate the licence from the services around it, and decide whether the entity's own operation of the software is an in-house ICT risk or a third-party arrangement. Document the decision, because the answer determines which register entries and due diligence steps apply.

Microenterprise and Article 16(1) status

Article 28(2) exempts microenterprises from the requirement to adopt a third-party strategy, and Article 16(1) sets simplified obligations for certain smaller entities. Whether either applies depends on the entity's legal classification, not on its size alone. Confirm the status with the competent authority or legal counsel before reducing the scope, and record the basis for the decision.

How an assessor tests the Article 28 arrangements

This table compares, for each Article 28 element, how a competent authority or independent assessor typically tests it, what evidence they ask for, and where arrangements most often fall short. Read each row as a checklist you can run against your own file before an inspection, with the findings column showing the gaps supervisors tend to raise.

Element	Test approach and evidence requested	Common findings
Strategy and policy (Art. 28(2))	Assessor reads the board-approved third-party strategy and the policy on ICT services supporting critical or important functions, then checks the approval date, review cycle and whether the policy is applied at individual and group level where relevant.	Policy approved but never reviewed after new cloud or SaaS adoption; no link between the strategy and the risk appetite set in the ICT risk framework.
Register of information (Art. 28(3))	Assessor requests the full register, reconciles it against contract repositories and procurement records, and checks the yearly submission and the notice given for planned arrangements on critical or important functions.	Register omits subcontractors and fourth-party locations; a SaaS tool bought by a business unit on a card never appears; entries exist but contract dates or service descriptions are stale.
Pre-contract assessment (Art. 28(4))	Assessor samples recent onboarding files and looks for a documented criticality decision, a due diligence record, a conflict of interest check and a concentration risk assessment before signature.	Criticality decided after the contract is signed; due diligence is a questionnaire returned without review; conflict of interest declarations absent.
Audit planning (Art. 28(5) and (6))	Assessor asks for the risk-based audit plan for each material provider, the pre-determined frequency and scope, the audit standard followed, and recent audit or assurance reports with the follow-up tracking.	Audit frequency set in policy but no audit run in the last cycle; reliance on a provider's marketing certificate without reviewing scope; no tracking of open findings.
Termination rights (Art. 28(7))	Assessor reviews contract clauses for each termination trigger listed in the Article, checks that rights are exercisable in practice, and asks how a supervisory bar on the provider would be handled.	Termination limited to material breach with no right tied to weaknesses in the provider's risk management or to supervisory conditions; notice periods that make exit impractical.
Exit strategies and transition plans (Art. 28(8))	Assessor asks for the written exit plan for each critical or important service, the data and configuration export steps, the alternative provider options, and the records of any test or tabletop exercise.	Exit plan written as a generic template; never tested; no data export has been trialled; dependence on a single provider's proprietary format is not assessed.
Governance and accountability	Assessor confirms the management body approved the strategy, that named owners hold each arrangement, and that reporting to the board covers provider risk and open issues.	Board minutes show no discussion of third-party risk; owners named in the register no longer work in the role.

How to build the Article 28 third-party framework step by step

The sequence below moves from knowing which ICT arrangements exist to proving that you can exit them, so each step builds the evidence the next one needs. Article 28 treats this as part of the ICT risk framework, so the outputs should feed that framework rather than sit in a separate procurement file.

Map every ICT arrangement
Start with a complete inventory of contracts and arrangements under which a provider supplies ICT services, including cloud, SaaS, managed services, intra-group services and self-hosted open-source software that a provider installs, supports or hosts for you. Procurement, IT operations and business owners should all contribute, because contracts often sit outside IT. The step is done when every arrangement has a named business owner, a service description and a link to the contract, and when you have a documented position on which open-source components are under a contract at all.
Classify critical or important functions
For each arrangement, decide whether the service supports a critical or important function, using the business function it serves and the impact of a failure on it. The risk owner should record the reasoning, not only the outcome, because supervisors will test the classification against how the function actually runs. The output is a classified list in which each arrangement is marked as supporting a critical or important function or not, with the rationale attached and reviewed by the management body or its delegate.
Adopt the third-party strategy and policy
Article 28(2) requires entities other than microenterprises and Article 16(1) entities to adopt and regularly review a third-party strategy, including a policy on the use of ICT services that support critical or important functions. Draft it inside the ICT risk management framework so that it names owners, approval routes and review cycles, then obtain management body approval. Confirm with your competent authority and your own legal advisers whether the policy applies on an individual, sub-consolidated or consolidated basis. The step is complete when the signed policy is in force and every arrangement in your inventory can be traced to it.
Build the register of information
Populate the register of information for all contractual arrangements for ICT services at the levels required, recording the provider, the service, the functions it supports and the subcontracting chain as far as you know it. Assign a single owner and set a process for updating the register when arrangements change. The output is a register that can be produced on request and that matches the classification from the previous step. Keep a dated change history so you can show what was known at each point in time.
Run pre-contract assessments and due diligence
Before signing, assess whether the service supports a critical or important function, whether supervisory conditions can be met, and all relevant risks, including ICT concentration risk. Perform due diligence on the provider, check its information security standards, and record any conflicts of interest. Where the arrangement is self-hosted open source operated by a partner, the due diligence covers the partner's staffing, change control and support model as well as the code's maintenance status. The output is a signed assessment file per arrangement that the approver can read without asking follow-up questions.
Set the audit and inspection schedule
Article 28(5) and (6) require audits and inspections of providers with a frequency and scope set in advance on a risk basis, following commonly accepted audit standards. Set the schedule by classification and risk rating, define who performs each audit and what evidence each audit will review, and confirm the audit rights in the contract. The output is an approved schedule with named owners and a record of findings and remediation for each completed audit. Ask any external auditor you engage to confirm in writing which standards they follow.
Write and test exit plans
For services that support critical or important functions, Article 28(8) requires documented exit strategies and transition plans. Article 28(7) also requires contracts that can be terminated in the circumstances listed in the Article. Write the exit plan for each such service, covering data return, service replacement, timing dependencies and the roles involved, then run a tabletop or technical test to check that the plan works in practice. The step is done when each exit plan has a recorded test, the gaps found are assigned to owners, and the termination rights in the contract match what the plan assumes.

How the register of information and due diligence connect

The register of information is the working record that makes Article 28 operable. Under Article 28(3), a financial entity must keep a register covering all contractual arrangements for ICT services, at entity level and, where relevant, at sub-consolidated and consolidated levels. The same register is the starting point for the pre-contract questions in Article 28(4): whether a proposed service supports a critical or important function, whether supervisory conditions are met, and what concentration risk the arrangement adds. If the register is incomplete, these assessments are run against an incomplete picture. Before any new ICT contract is signed, the risk owner should be able to see which existing providers already support the same function, which subcontractors sit behind them, and which services share a hosting location or a parent company.

The register also works in the other direction. Each new assessment and due diligence file should produce an entry, and each entry should link back to the assessment that justified it. Due diligence findings on security standards, audit rights and exit options belong in the same record, so that when a provider is reviewed or replaced, the file shows what was known at signing. Concentration checks draw on the same data: if several critical functions depend on one provider, one subcontractor or one jurisdiction, the register should make that visible before the contract is approved rather than after an incident. Confirm with your competent authority which data fields and templates it expects, because the register is a supervisory submission as well as an internal tool.

On reporting, ESAs Q&A 2025_7309, published 14 August 2025, states that submitting registers of information to the ESAs each year generally satisfies the yearly reporting obligation in Article 28(3), without a separate communication. Treat this as a clarification of the reporting route rather than a waiver of the duty to notify planned arrangements for critical or important functions in advance. Ask your competent authority to confirm the current form, submission window and whether any national expectations apply on top of the Q&A. Then set an internal owner, a quarterly check that the register matches signed contracts, and a sign-off step so the yearly submission reflects the register as it stood at the reporting date.

Evidence that satisfies Article 28 and how to keep it current

Article 28 is tested through documents, not intentions. The artifacts below show that the third-party strategy, the register, the due diligence and the contracts exist, were approved, and still match how ICT services are used today. Version history and approval records matter as much as the content, because they show the arrangement is current between audits.

Approved third-party strategy and policy

The strategy sets how ICT third-party risk is managed as part of the ICT risk framework, and the policy governs use of ICT services supporting critical or important functions. Assessors look for management body approval, a named owner, a review date and a link to the ICT risk framework. Check that the policy names the criteria used to decide which functions are critical or important, and that it covers each entity in the group where Article 28(2) applies.

Register of information extract

The register lists every contractual arrangement for ICT services, including those with subcontractors where relevant, at entity and group levels. Keep an extract that shows provider, service, function supported, contract dates and whether the function is critical or important. Confirm with your competent authority and the ESAs' Q&A 2025_7309 how yearly submission applies to your entity, and reconcile the register against accounts payable and contract records before each submission.

Due diligence files and conflict checks

Each pre-contract file should record the assessment of whether the service supports a critical or important function, the supervisory conditions, the concentration risk, the provider's due diligence results and any conflicts of interest. Include who approved the decision and when. For intra-group providers, the conflict check is often the weakest record, so document it explicitly rather than assuming it is clear.

Audit plans and completed reports

Article 28 expects a risk-based audit and inspection plan with a predetermined frequency and scope, following commonly accepted audit standards. Keep the plan, the scope agreed with each provider, the reports or assurance evidence received, and the findings tracked to closure. Note where a provider relies on independent assurance and where you performed your own inspection, because assessors test both.

Contract clauses on termination and audit rights

Keep the executed contract and the clause map that shows where termination rights for significant breaches, changes that alter performance, evidenced ICT risk weaknesses and supervision barriers appear. Include audit and access rights and any subcontracting conditions. Ask counsel to confirm the clause wording against Article 28(7) and the contract requirements in Article 30, because a clause that exists on paper but cannot be exercised will not satisfy an assessor.

Tested exit plan records

Article 28(8) requires documented exit strategies and transition plans for services supporting critical or important functions. Evidence means the plan itself plus records of testing: what was tested, who ran it, the result and the remediation. A plan that has never been exercised is weak evidence, so schedule a test and record its outcome.

Versioning and approval history

Currency is shown by history: every change to a strategy, policy, register extract, due diligence file or exit plan should be versioned with the author, the date, what changed and who approved it. Wiki and documentation tools with version control and role-based permissions can record this, but confirm they keep approval status and retain prior versions for the period your authority expects. Review each artifact on a fixed cycle and record the review even when nothing changes.

What meeting Article 28 costs in money and effort

This table breaks down the main cost components of Article 28 compliance, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to scope internal effort, decide what to outsource and build the list of items to request in a quote, since no DeployOpen price is implied.

Cost component	Who is paid or who carries the effort	One-time or recurring, and main drivers
Register of information tooling	Internal team for data model and ownership; software or platform vendor if purchased; implementation partner if built or configured	Setup is one-time; upkeep recurs. Drivers: number of contractual arrangements, number supporting critical or important functions, and how many entities the register covers at sub-consolidated and consolidated levels
Legal review of contracts	Internal legal or outside counsel, often for the largest or most critical provider contracts	Largest share is one-time per contract, with recurring review at renewal or amendment. Drivers: provider count, bargaining position, and how many Article 30 clauses must be negotiated
Due diligence effort	Internal risk, procurement and security staff; sometimes external assessors for provider evidence	Recurring at each new arrangement and periodic reassessment. Drivers: whether the service supports a critical or important function, provider count, and depth of sub-provider and concentration review
Audit and inspection execution	Internal audit or security team; external auditors or specialists for provider audits, often paid by the financial entity	Recurring on a risk-based schedule set in advance. Drivers: criticality of the service, scope of rights granted in contracts, and whether providers accept pooled or shared audits
Exit plan documentation and testing	Internal business and technology owners; implementation partner for migration rehearsal in self-hosted environments	Documentation is one-time with periodic updates; testing recurs. Drivers: number of critical or important services, data portability, and the complexity of the target environment
Evidence upkeep and governance	Internal compliance, risk and management body reporting; platform and documentation tooling	Recurring. Drivers: change frequency, number of owners, and whether evidence is captured automatically from systems or assembled by hand
Ask in any quote	Vendor or partner	Itemized scope by component, assumptions on arrangement and provider counts, who performs each task, what is one-time versus annual, and what evidence will be delivered

Who owns, who prepares and who assesses Article 28

The financial entity owns the third-party risk strategy, the policy on ICT services supporting critical or important functions, the decision to contract, and the accountability for every arrangement. Article 28(1) keeps the entity fully responsible for compliance, so no supplier, consultant or platform can take that responsibility over. The management body approves the strategy and policy, and the people who run each business service decide whether a function is critical or important and whether a provider is acceptable.

Strategy and policy: approve the third-party strategy and the policy on critical or important functions, and review them on a regular cycle.
Contract decisions: decide whether to sign, renew or terminate each ICT arrangement, and record the conflict of interest checks under Article 28(4).
Criticality calls: own the classification of each function and the sign-off on the pre-contract assessment.
Exit strategy ownership: approve the documented exit plan and transition plan, and accept the results of exit tests.
Audit decisions: set the risk-based audit frequency and scope, and decide what to do with audit findings.

Ask any partner which of these decisions it will never take on its own, and confirm that your approval workflow records the named individuals who signed each one.

Where Article 28 programs usually fall short

Most Article 28 gaps are not missing policies. They are registers, contracts and plans that exist on paper but no longer match the arrangements in use. The cards below cover the gaps assessors most often find, each with the check that closes it.

Register covers only major contracts

Article 28(3) asks for a register of information on all contractual arrangements for ICT services, not only the large or strategic ones. Teams often list the core platform and miss low-value SaaS tools, open-source components under support agreements, and intra-group services. Close this by reconciling the register against procurement records, accounts payable and cloud billing, then recording a named owner and a critical or important function flag for each entry.

Exit plans written but never tested

Article 28(8) requires documented exit strategies and transition plans for services supporting critical or important functions, and the plans must be tested. A plan that names a replacement provider but has never moved data or restored a service is unproven. Close this by choosing one critical service each year, running a partial migration or restore into a test environment, and recording the time taken and the gaps found.

Audit rights missing from older contracts

Contracts signed before DORA often lack clauses for access, audits and inspections by the entity and its competent authority. Article 28(6) expects a risk-based audit frequency and scope, which is hard to apply if the contract gives no right to audit. Close this by reviewing each pre-DORA contract for audit, access and information clauses, and agreeing amendments at renewal or through a written addendum before the next audit cycle starts.

Subcontracting chains left unmapped

A provider that looks compliant may rely on several subcontractors, cloud regions or support vendors that the entity has never recorded. Article 28(4) requires the risk assessment to cover all relevant risks, including concentration risk, and unmapped chains hide shared dependencies that affect both continuity and exit. Close this by asking each provider for its subcontractor list, recording the location and function of each, and flagging any that also support a critical or important function.

Strategy not reviewed regularly

Article 28(2) requires the third-party risk strategy and the policy on ICT services supporting critical or important functions to be adopted and regularly reviewed. In many firms the strategy is approved once and then drifts from actual use as new SaaS tools and cloud services arrive. Close this by setting a fixed review date in the management body calendar, comparing the strategy with the current register, and minuting the decisions taken on any changes.

Article 28 questions buyers ask before hiring help

How much effort does Article 28 take to implement?

Effort depends on how many ICT services your entity uses, how many of them support critical or important functions, and how much of your ICT third-party risk process already exists. Article 28 asks for a strategy and policy, a register of information on all contractual arrangements, pre-contract assessments, due diligence, audit planning, termination rights and tested exit plans. Most of the work is documentation, contract review and evidence collection rather than new technology. Entities with a large cloud and SaaS footprint usually carry the heaviest load because every arrangement must be inventoried and assessed. Ask any partner to size the work from your actual service list before agreeing a scope.

Can a small financial entity meet Article 28 in-house?

Often yes, provided someone accountable owns the process and has time to run it. Article 28 is proportionate in one important way: the strategy and register requirements do not apply to microenterprises in the same form, and Article 16(1) entities have a simplified regime. Small teams usually struggle with contract clauses, exit testing and audit planning, not with the policy itself. If your team lacks contract, legal or security assessment experience, an outside reviewer can check your work without taking ownership of it. Confirm your entity type and its proportionality position with your competent authority or legal counsel.

How long does Article 28 readiness work take?

It depends on scope. The duration is driven by the number of ICT arrangements in the register, how many support critical or important functions, the state of existing contracts, and whether exit plans must be written and tested from scratch. An entity with a current register and standard contracts will move faster than one that must rebuild its inventory. Ask any implementation partner for a written schedule tied to a defined scope, with named deliverables and client dependencies. Be cautious of timelines quoted before the service list and contracts have been reviewed.

What does the work need from our team?

The work needs named owners on both sides. Your side typically supplies the list of ICT services and contracts, access to procurement and legal records, the business owners of each critical or important function, and someone with authority to approve the strategy and policy through the management body. Security, IT operations and the exit owner must also review and test exit plans. Expect recurring input for the register, since it must be kept current and reported. A partner can prepare templates and evidence, but the entity must make the decisions and sign off the outcomes.

Does DeployOpen issue Article 28 certificates?

No. DeployOpen does not issue audit reports, attestations or certificates. Article 28 is a regulatory requirement that your entity owns, and it is supervised by the competent authority for your entity type under the DORA framework. DeployOpen can help prepare systems, documentation, registers and evidence for an assessment, and can review how your self-hosted open-source platforms and their providers align with the requirements. Only the independent assessor or the authority you engage can assess your position. Confirm with your supervisor which evidence it expects before work begins.

Does DeployOpen price Article 28 work and how is it quoted?

DeployOpen does not publish a price list. Engagements are normally fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and the quote follows from that written scope. Ask for a breakdown that separates the register, contract review, due diligence support, exit plan development and any ongoing retainer. Ask which items are one-time and which recur, such as annual register updates and periodic audit reviews. Compare any quote against the list of services you actually need to govern.

Where should we start if our self-hosted platforms are open source?

Start by treating each self-hosted platform as an ICT service with its own owner, support arrangement and exit route. Open-source software is not automatically outside Article 28. Where a commercial support, hosting or maintenance contract exists, that contract and its provider fall within the register and due diligence. Document who maintains the code, how upgrades are sourced, and how you would move data and configuration elsewhere. Confirm with your legal and supervisory contacts how your specific arrangements are classified.

How DeployOpen prepares Article 28 evidence

DeployOpen helps financial entities build the Article 28 evidence trail inside their own ICT risk framework, from the third-party strategy and register of information to tested exit plans. The financial entity remains fully responsible for compliance, and DeployOpen prepares the systems, documents and records that the entity and its auditors or supervisors will examine.

How we scope

Agree a written scope that names the ICT services, providers and self-hosted platforms covered by the third-party risk strategy.
Map which services support critical or important functions, so pre-contract assessment and exit planning are targeted correctly.
Confirm with the entity which register of information fields its own systems can populate and which must come from procurement records.

How we build

Configure the register of information and contract inventory in the entity's own infrastructure, with fields for provider, function and subcontractors.
Set up due diligence and pre-contract assessment workflows that record criticality, concentration risk and conflicts of interest.
Prepare an audit planning calendar with a risk-based frequency and scope that the entity's internal audit function can review.

How we hand over

Deliver documented exit strategies and transition plans for each service supporting a critical or important function, with ownership named.
Provide version-controlled policy and register records, showing who changed what, when and why, for review by the management body.
Run a walkthrough of the exit plan and termination triggers with the entity's risk, legal and procurement teams before sign-off.

How we support

Keep the register and exit plans current as contracts change, with ongoing support available as a retainer.
Support the entity's annual reporting preparation for new arrangements, using the records DeployOpen maintained during the engagement.
Confirm with the entity's supervisor and legal counsel how the entity's specific obligations apply, since DeployOpen does not issue attestations.