What DORA Article 29 asks you to assess before you sign
Your entity is about to contract an ICT service that supports a critical or important function. Before you sign, Article 29 of DORA requires a risk assessment that goes beyond the provider's security posture. You need to ask whether the arrangement would make you dependent on a provider that is not easily substitutable, whether you already hold other arrangements with the same provider or with closely connected providers, and what it would cost to move to an alternative. The assessment also covers subcontracting chains, particularly where subcontractors sit in third countries, and whether long or complex chains would weaken your ability to monitor and supervise the service. For providers established outside the EU, you must also consider compliance with Union data protection rules and whether the third country enforces the law effectively.
The Regulation defines ICT concentration risk in Article 3(29) as exposure to one or more related critical ICT third-party providers, where their unavailability or failure could endanger delivery of critical or important functions, cause large losses or endanger EU financial stability. Read against your own portfolio, the question is practical: if this provider failed, which of your functions would stop, and which other contracts would fail with it? Article 29 also asks what insolvency law would apply to the provider and whether that law constrains urgent recovery of your data. Confirm with the provider where your data is stored, under which jurisdiction, and how quickly you could retrieve it in a failure scenario.
This is hard to answer because most entities have no ready inventory of dependencies. Cloud regions, hosting providers, managed services and software vendors often share underlying suppliers that appear in no single contract. Start by mapping each critical or important function to its ICT services, then to the providers and subcontractors behind each service, and record the results in your register of information. Ask providers to disclose their own subcontractors and locations in writing before signing. Where the answers are incomplete, document the gap and the decision you made, because the assessment has to be evidenced to your competent authority.
Which arrangements and third parties fall under the Article 29 assessment
The Article 29 assessment applies only to arrangements that support critical or important functions, but the boundary is set by several scoping decisions made before contracting. The cards below cover the decisions that change the work: function classification, what counts as an ICT service, cloud, intra-group and self-hosted software, and the subcontracting chain.
Critical or important functions
The assessment is triggered only when an ICT arrangement supports a critical or important function. Document the function first, then the arrangements that support it, rather than starting from a list of vendors. Record who owns the classification, what disruption would mean for service delivery, regulatory obligations and customers, and when the classification is reviewed. Unclassified functions still need a risk assessment under the ICT risk framework, but the Article 29 analysis is not automatically required for them.
What counts as an ICT service
Scope the arrangement by what the entity actually consumes: hosted platforms, managed operations, data processing, connectivity, support services and software licences that run on the entity's systems. Confirm whether a license with no provider-run component is an ICT service in scope. Ask for a written contract inventory, so that every arrangement touching a critical function is tested for concentration effects, including those bought through procurement outside IT.
Cloud providers and their dependencies
Cloud arrangements often concentrate risk in a few hyperscale providers and their regions, shared managed services and identity layers. Map which critical functions depend on the same provider, region, availability zone or managed database. Assess whether two contracts with different legal names still rely on one underlying operator. Check whether substitution would require data export, re-architecture or a second cloud, since that effort determines how substitutable the provider is.
Intra-group services
Services provided by another entity in the same group are still ICT third-party arrangements, and they can concentrate risk just as external providers do. Identify shared platforms, group data centers and central security or identity services that several regulated entities in the group depend on. Check whether a group-level failure would affect several critical functions at once, and whether the group provider has its own subcontracting chain that needs review.
Open-source and self-hosted software
Self-hosted open-source platforms running in the entity's own infrastructure still need a decision on whether they are an ICT third-party arrangement. Assess the support, maintenance, hosting, patching and integration providers involved, not only the code. Concentration risk can arise when one implementation partner or one upstream project supports many critical functions. Record the alternative options and their costs, and the entity's ability to maintain the software without the provider.
Subcontracting chains under 2025/532
Article 3(1)(i) of Delegated Regulation (EU) 2025/532 requires the Article 29 assessment before subcontracting of critical services is allowed, so the chain must be known before the decision. Map each subcontractor, its location and the data it touches. Long or complex chains, and subcontractors in third countries, reduce the ability to monitor and supervise. Confirm that the provider can disclose the chain and notify changes, since the assessment must be refreshed when the chain changes.
How an assessor tests the Article 29 assessment
This table sets out what an assessor samples, checks and asks for when testing the Article 29 assessment, with the evidence expected and the findings that most often appear. Read each row as a test step: the left column names the check, the middle column describes how it is performed, and the right column shows what usually goes wrong.
| Test step | What the assessor does | Common finding |
|---|---|---|
| Select a sample of pre-contract files | Pulls recent ICT arrangements supporting critical or important functions, including renewals and new subcontracting approvals, and confirms each has a dated Article 29 assessment on file. | Assessment dated after signature, or no file exists for arrangements inherited through acquisition. |
| Check entity-level concentration analysis | Looks for a concentration risk analysis at entity level, as Delegated Regulation (EU) 2024/1773 requires for the pre-contract risk assessment, and checks it covers the whole portfolio rather than one contract. | Analysis covers a single provider in isolation and never aggregates dependencies across the register of information. |
| Trace dependencies on related providers | Compares the provider's group ownership, shared hosting, shared subcontractors and shared data centers against other arrangements the entity already holds. | Generic risk statement such as 'reliance on third parties' with no dependency map or named related providers. |
| Test subcontracting decisions | Checks that each subcontracting approval for a critical service records the assessment required by Article 3(1)(i) of Delegated Regulation (EU) 2025/532, including third-country subcontractors. | Subcontractor named in the contract but absent from the assessment, or approval granted without a written review. |
| Review substitutability and alternatives | Asks whether the provider is easily substitutable, what alternatives were considered, and whether their costs and benefits were weighed against the chosen option. | Alternatives listed with no cost comparison, or substitutability asserted without an exit or migration estimate. |
| Review insolvency, data recovery and third-country factors | Confirms the file considers the insolvency law that would apply, constraints on urgent data recovery, Union data protection compliance and enforcement of law for third-country providers, and long subcontracting chains. | Insolvency and recovery questions left blank, or third-country risk omitted for a provider hosted outside the EU. |
| Request supporting evidence | Asks for the dependency map, alternative provider shortlist, cost comparison, subcontractor list, approval record, exit plan link and the sign-off by the responsible function. | Evidence exists only as a narrative memo with no source data or approver named. |
| Confirm the assessment is kept current | Checks whether the assessment was refreshed when the provider changed ownership, subcontractors or hosting location, and whether it feeds the register of information. | Assessment never updated after the initial contract signature, even after material changes. |
How to build the concentration risk assessment step by step
The sequence below moves from the functions an entity depends on to the providers behind them, then tests substitutability, insolvency and data recovery constraints, and ends with a recorded decision that management has approved before the contract is signed.
Map critical or important functions to ICT services
Start by listing the functions that the entity has classified as critical or important, then trace each one to the ICT services that support it. Record the business owner, the service name, and the systems involved. Involve operational leads as well as the ICT team, because the function is what the regulator cares about, not the contract. The step is done when every proposed arrangement that supports a critical or important function is linked to a named function and an accountable owner. Ask for a sign-off from the function owner before moving on.
Map providers and their subcontracting chains
For each proposed ICT service, identify the contracting provider and every subcontractor the provider relies on to deliver it, including cloud infrastructure, hosting, support and data processing. Record the location of each party and the depth of the chain. Ask the provider for its subcontracting list and check it against the register of information. The output is a dependency map for each arrangement showing every link between the entity and the underlying technology. The step is complete when no link is undocumented.
Identify shared or closely connected providers across the register
Compare the dependency maps across the whole register of information to find providers, subcontractors and infrastructure that appear in several arrangements supporting critical or important functions. Check for common cloud regions, common hosting providers, and providers that belong to the same corporate group. Flag any case where the failure of one provider would affect several functions at once. The output is a concentration register listing each shared or closely connected dependency, the functions it touches, and the number of arrangements that rely on it.
Test substitutability and exit options
For each flagged provider, assess whether the service could be replaced within the time the function can tolerate an outage. Consider whether data formats are portable, whether an alternative provider exists in the market and in the entity's jurisdiction, and what it would cost to switch compared with keeping the current arrangement. Weigh the costs and benefits of alternatives in writing. The output is a substitutability rating and an exit option summary for each critical dependency, reviewed by the exit plan owner. Confirm the findings against the provider's documented export and termination terms.
Assess third-country, insolvency and data recovery constraints
For providers or subcontractors established outside the EU, assess compliance with Union data protection rules, the effective enforcement of law in that country, and whether long or complex subcontracting chains weaken monitoring and supervision. Review which insolvency law would apply if the provider failed and whether that law could delay urgent recovery of the entity's data. Record the findings and any mitigations, such as escrow, data copies held in the entity's own environment, or contractual step-in rights. The output is a constraints note per provider, signed by legal and information security.
Record the decision and obtain approval
Bring the findings together in a single assessment record for each proposed arrangement. The record should state the functions affected, the concentration risks identified, the substitutability and exit position, the third-country and insolvency findings, the mitigations accepted or required, and the decision to proceed, change the design or decline. Route the record to the body that carries responsibility for ICT risk, normally the management body or a delegated committee, and file the approval with the contract file. The step is complete when the approved record exists before signature and is updated when the arrangement changes.
Which evidence to keep for each type of provider
When one provider supports a critical or important function and no alternative is in place, the file has to show why that dependency is acceptable and how the organization would leave it. Article 29(1) asks the entity to consider whether the provider is not easily substitutable and to weigh the costs and benefits of alternatives. The evidence therefore centres on a substitutability analysis, not on the contract alone.
- Dependency map: A diagram or table linking the function, the services it relies on, the provider, and the data and systems involved.
- Substitutability memo: A signed assessment of alternative providers or in-house options, the effort to migrate, and the reasons the current choice stands.
- Approval record: Evidence that the management body or the delegated owner reviewed and accepted the residual concentration.
- Exit plan reference: A pointer to the tested exit plan, so the memo and the exit plan do not contradict each other.
Refresh the memo at contract renewal, after a material service change, and after any incident involving the provider. Ask the provider to confirm, in writing, the services and locations in scope.
Concentration risk often hides in plain sight when several contracts share a parent company, a hosting platform, a common data center, or the same underlying software. Article 29(1) explicitly asks about holding multiple arrangements with the same or closely connected providers. The evidence must show that the entity looked across contracts rather than one at a time.
- Group dependency map: A consolidated view listing each provider, its corporate parent, its hosting location and its shared components.
- Aggregate substitutability note: An assessment of whether one failure could disable several critical functions at once.
- Approval record for the group: Sign-off that covers the combined exposure, not only each contract separately.
- Register cross-check: A reconciliation between the register of information and the dependency map, so both show the same related providers.
Re-run the group view whenever a provider is acquired, changes hosting, or adds a new contract that touches an existing dependency. Confirm ownership details with each provider, because corporate structures change without notice to customers.
Where a provider relies on a subcontractor established outside the EU, Article 29(2) requires the entity to weigh the benefits and risks of permitted subcontracting. For third-country providers, the entity must also consider compliance with Union data protection rules, the effective enforcement of law in that country, and whether long or complex chains impair monitoring. Delegated Regulation (EU) 2025/532 requires the Article 29 assessment before allowing subcontracting of critical services.
- Subcontracting review: A map of each subcontracting tier, its location, the services it performs and the data it touches.
- Legal enforceability note: A short analysis of data protection compliance and the practical reach of local law, prepared with counsel where needed.
- Chain-length assessment: A statement on whether each added tier still allows monitoring, audit and incident notification.
- Pre-approval record: Evidence that the entity approved the subcontractor before it was used.
Recheck the review whenever the provider notifies a change, and confirm that the provider still meets its contractual notice obligations for new subcontractors. Ask the provider for the current list rather than relying on the list supplied at signing.
Self-hosted open-source platforms still create concentration when they run on one cloud region, one managed database service, or one hosting partner. The open-source licence does not remove the dependency on the infrastructure underneath it. The evidence should therefore cover both the software and the hosting layer, and it should record who operates each part.
- Layered dependency map: Separate rows for the application, the operating system, the container or orchestration layer, the cloud or data center, and any managed service.
- Insolvency and data recovery note: A record of what happens to the data and the workloads if the hosting provider fails, including the location and format of backups and the time needed to restore them into another environment.
- Software continuity statement: Evidence of who maintains the open-source components, which upstream releases the deployment tracks, and whether a fork or internal maintenance option exists.
- Approval record for the hosting choice: Sign-off that names the accepted concentration and the review date.
Re-test the restore procedure on a schedule and after each major platform upgrade. Confirm with the implementation partner and the hosting provider which components they can export, and in what format, before relying on that assumption in an assessment.
Evidence artifacts that satisfy Article 29 and how to keep them current
An assessor testing Article 29 will look for a set of linked records, not a single memo. Each artifact below answers one question the assessor asks, and together they show that the concentration decision was made deliberately, documented and kept accurate as providers and dependencies change.
Concentration risk analysis
This is the core record of the pre-contract assessment. It states whether the proposed provider is not easily substitutable, whether the entity already holds other arrangements with the same or closely connected providers, and how the entity reached that conclusion. Under Delegated Regulation (EU) 2024/1773, the analysis must cover ICT concentration risk at entity level, so a per-contract view is not enough. Check that the analysis names the critical or important function it protects and records the scenario in which the provider fails.
Dependency and subcontracting map
This artifact traces who depends on whom, from the provider through each subcontractor to the underlying infrastructure and any third-country location. Assessors compare it against the register of information so that the same provider appears with the same identifiers in both places. Include the subcontracting chain depth, the countries where subcontractors operate and any point where monitoring or supervision would become hard to follow. Confirm the map is produced from the register rather than maintained separately.
Cost and benefit comparison of alternatives
Article 29(1) requires the entity to weigh the costs and benefits of alternatives before committing. The record should list the realistic substitutes, the migration effort for each, the exit time and the cost of running a second provider or a self-hosted fallback. Keep the comparison specific to the function at risk. A comparison that only restates the chosen provider's features will not show that substitution was considered.
Insolvency and data recovery review
Article 29(2) asks what insolvency law would apply if the provider failed and what constraints would limit urgent recovery of the entity's data. This review records the governing jurisdiction, the provider's data export and deletion terms, and how fast a copy of critical data could be restored. For third-country providers, add the enforceability of data protection rules and the effective enforcement of law in that country. Ask counsel to confirm the insolvency analysis for each relevant jurisdiction.
Management body approval record
The assessor will want evidence that the management body, not only the operational team, reviewed the concentration analysis and accepted the residual risk. The record should show the date, the participants, the options presented, the decision taken and any conditions attached, such as an exit plan or a second source for a critical component. Store the approval with the analysis so the two can be read together during supervision.
Review triggers and update log
Define the events that reopen the assessment, such as a change of subcontractor, a change of hosting country, a merger affecting the provider, a major incident at the provider or a new contract that adds volume with the same provider. Log each trigger, the reassessment performed and the outcome. Without this log, the analysis describes the contract as it was signed rather than as it operates now, which is the gap assessors most often find.
What meeting Article 29 costs in money and effort
This table breaks down the cost components of an Article 29 concentration risk assessment, showing who is paid for each, whether the cost is one-time or recurring, and what drives it up. No figures are given because none were supplied, so use the questions in the final column when requesting quotes.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it, and what to ask for in a quote |
|---|---|---|---|
| Internal analyst and architect time | Your own staff: risk, procurement, enterprise architecture | Both: first assessment is one-time, reassessment is recurring | Number of critical or important functions in scope. Ask the partner to state the assumed number of functions and provider relationships. |
| Legal review of insolvency and data recovery questions | External counsel or your in-house legal team | Mostly one-time per provider, recurring when law or contracts change | Number of third-country providers and governing law. Ask whether insolvency analysis is included or excluded from scope. |
| Mapping tooling and register data | Software licence or self-hosted tooling, plus configuration effort by implementation partner | Setup is one-time, licence and data upkeep recurring | Depth of provider and subcontractor data in your register of information. Ask what tooling is included and who maintains the mapping. |
| Subcontracting chain analysis | Internal teams and provider cooperation, sometimes partner effort | Initial mapping one-time, updates recurring | Depth of subcontracting chains and frequency of subcontractor changes. Ask how changes will be detected and re-assessed. |
| Evidence upkeep at renewal or subcontractor change | Your compliance and vendor management teams | Recurring | Contract renewal cycle and how often providers change subcontractors. Ask what triggers a reassessment and who signs off. |
| Independent review or auditor sampling | Independent auditor or reviewer, chosen and paid by you | Recurring with each audit cycle | Scope of the sample and whether critical providers are included. Ask the auditor for its sampling approach before engagement. |
| Implementation partner preparation work | DeployOpen or another partner, under a written fixed scope | Usually one-time, with optional retainer for upkeep | Scope boundaries, number of systems and documents prepared. Ask for deliverables, timelines and assumptions in writing before work starts. |
How self-hosted open source changes the concentration question
Self-hosting does reduce one kind of concentration risk: a single SaaS vendor can no longer switch off the platform, reprice it or change its data location without the organization having a say. But it does not remove the dependency. It moves it. The assessment under Article 29 should record three new dependencies: the people who operate and patch the platform, the hosting capacity it runs on (usually a cloud provider or a data center that may itself be an ICT third-party service), and the small number of upstream projects whose releases, security fixes and community support the organization relies on. If one of those upstream projects stops maintaining a component, the organization carries that risk directly.
To document substitutability for a self-hosted platform, record for each component who can operate it internally, which external support contracts exist and what they cover, and whether a second hosting environment could run the same software version. For exit, note where the data is stored, in which format it can be exported, how long a restore takes from the latest backup, and which configuration, keys and integrations would have to be rebuilt elsewhere. Describe these as tested facts where possible, not as assumptions. Confirm with the vendor or project which license applies to the version you deploy and whether the license terms, commercial add-ons or support subscriptions create any restriction on modification, redistribution or continued use. Ask for written confirmation of any clause that could affect continuity, such as a change of license for a future release.
Who owns the Article 29 assessment and who can help
Your organization owns the Article 29 preliminary assessment. The management body and the people responsible for ICT risk decide whether a provider can support a critical or important function, whether the concentration risk is acceptable, and whether mitigations are required before the contract is signed. No outside party can take that decision on your behalf, and the file you produce is the record a supervisor will read first.
- Decision and approval: Confirm who signs off the assessment and that the sign-off is recorded in the ICT third-party risk framework.
- Function scoping: Identify which functions are critical or important and which ICT services support them, because the assessment only applies to those arrangements.
- Substitutability judgment: Decide whether the provider is easily substitutable, and document the reasoning, including the cost and benefit of realistic alternatives.
- Concentration view: Record every existing arrangement with the same or closely connected providers at entity level, not only within one business unit.
- Exit and recovery position: Set the exit options, data recovery arrangements and insolvency assumptions that the business has accepted.
Before approval, check that every conclusion in the assessment traces back to an owner inside your organization who can defend it to a supervisor.
An implementation partner can prepare the technical and documentary inputs to the assessment under a fixed, written scope. For self-hosted open-source platforms, this often means mapping how the components depend on each other, which packages and services they pull from outside your environment, and how data would be recovered if a component or hosting provider failed. The partner prepares material. It does not decide the risk, approve the assessment or certify anything.
- Dependency mapping: Document the components, hosting, cloud services, container registries and subcontracted operations that the platform relies on.
- Evidence preparation: Gather configuration records, architecture diagrams, backup and restore test results and exit procedures for your review.
- Documentation drafts: Draft the assessment worksheets and supporting notes that your team then reviews, edits and adopts.
- Substitution options: Describe the technical effort involved in moving the workload to an alternative, so your team can weigh the costs.
- Scope boundaries: Agree in writing which systems, providers and deliverables are included, and which remain with your team.
Ask the partner to state in the scope which outputs are drafts for your review and which, if any, are final records you adopt.
The competent authority supervising your entity, and any independent auditor you engage for assurance, reviews the assessment and tests whether it works in practice. An auditor reports on what it examined and found. A competent authority applies its supervisory powers. Neither role is performed by the implementation partner, and neither is handed to your own team, which is why independence is the line that matters most in this section.
- Independent review: The authority or auditor tests the reasoning and evidence, not the partner's confidence in its own work.
- Limits of advisory work: Where a partner or consultant helped write the assessment, the auditor will need to see that your team made and approved the decision.
- Reports and certificates: Only an independent auditor or certification body issues assurance reports or certificates. DORA sets no certification scheme for this assessment.
- Access to evidence: Make sure the evidence an assessor needs is retained, dated and traceable to the assessment.
- Engagement terms: Confirm with the auditor, not the partner, what sampling and testing it will perform.
Check with your supervisor or auditor what form of review they expect for this assessment before work begins.
Where organizations usually fall short on concentration risk
Most concentration risk gaps come from assessments that stop at the contract, or that never follow a dependency down into the providers' own suppliers. The cards below cover the gaps we see most often and the closing check for each, so the assessment reflects the whole entity and the whole chain.
Assessing at contract level only
Teams often assess each ICT contract in isolation and approve it because the provider looks acceptable on its own. Article 29 asks about dependency on the same or closely connected providers, and Delegated Regulation (EU) 2024/1773 extends the pre-contract assessment to concentration risk at entity level. Check the entity-wide view: list every critical or important function that relies on each provider, including through other contracts, and record where several functions converge on one provider or one group of related providers.
Register of information not linked to subcontracting
The register of information often lists direct providers but not the subcontractors that support them, so the entity cannot see the chain that actually carries its critical services. Article 29 requires the entity to weigh permitted subcontracting before accepting it, and Delegated Regulation (EU) 2025/532 requires that assessment before subcontracting of critical services is allowed. Check that each entry records known subcontractors, their locations and the services they support, and that the register is updated when the provider changes its chain.
Substitutability assumed, not tested
Many assessments state that a provider can be replaced without testing whether a replacement exists in practice. Article 29 asks whether the provider is not easily substitutable and what alternatives would cost and deliver. Check the exit path concretely: name candidate alternatives, confirm data can be extracted in a usable format, and estimate the time a migration would take from the entity's own engineering and vendor records.
Insolvency and data recovery left out
Assessments frequently cover outages and cyber events but skip what happens if the provider fails. Article 29 asks entities to consider the insolvency law that would apply to the provider and any constraints on urgent recovery of their data. Check with counsel which insolvency regime applies, whether the contract gives the entity prompt access to its data and whether a copy can be held outside the provider's control.
Third-country subcontractors approved without enforcement review
Subcontractors located outside the EU are sometimes approved on the basis of certifications alone. Article 29 asks the entity to consider compliance with Union data protection rules, the effective enforcement of law in that country, and whether a long or complex chain impairs monitoring and supervision. Check each third-country link against these points, record the monitoring constraints in writing, and decide whether the entity can still exercise audit and information rights over that link.
Questions buyers ask about the Article 29 assessment
How long does an Article 29 concentration risk assessment take?
The duration depends on how many ICT arrangements support critical or important functions, how many providers sit in each chain, and how much of the required information already exists in your records. No supplied fact gives a duration, so treat any number from a vendor or consultant as a claim to test against a written scope. The biggest drivers are the number of candidate providers, whether subcontracting chains are documented, and whether the register of information is current. Ask for a work plan that lists each arrangement, the evidence to be reviewed, and the decision points where management sign-off is needed.
How much effort does the assessment take inside the organization?
Most of the effort falls on people who know the business and the architecture, not on the assessors. Procurement, the ICT risk function, the owners of each critical or important function and whoever holds the subcontracting information all contribute. Effort rises when providers are not easily substitutable, when a provider sits in a long subcontracting chain, or when data recovery and insolvency questions require legal input. Effort falls when exit plans and contract records already exist. Ask your partner to name which internal roles they need and for how many hours of their time.
Can a single internal team complete the Article 29 assessment alone?
A single team can often prepare the assessment, but it should not own every input alone. Article 29 asks about substitutability, related providers, third-country exposure, subcontracting, insolvency law and data recovery, and these questions cross legal, procurement, security and business lines. A small team typically needs written input from legal counsel on insolvency and enforcement questions and from business owners on impact. Your own management body remains accountable for the decision. Confirm internally who signs off the assessment before work begins.
What should a fixed-scope quote for this assessment include?
A fixed-scope quote should state exactly which ICT arrangements are in scope, which functions they support, and which of the Article 29 factors each one will be assessed against. It should list the deliverables, such as the assessment record per arrangement, the concentration map across providers, and the list of open risks with owners. It should name what the client supplies, including register extracts, contracts and subcontractor lists, and what happens if those inputs arrive late. Ask whether legal review is included or must be procured separately, and confirm that the partner prepares the evidence without issuing any audit opinion.
Do self-hosted open-source platforms remove the need for an Article 29 assessment?
No. Self-hosting reduces dependence on an external software vendor, but it does not remove the obligation to assess ICT concentration risk for services supporting critical or important functions. You still depend on the infrastructure provider, the hosting cloud, managed database or support services, and any third-country subcontractor involved in operating or supporting the platform. Open-source licensing also does not eliminate substitutability questions, since you must still judge whether skills, support and migration paths exist. Confirm with your supervisor how they classify internally operated software and which dependencies they expect to see documented.
What will an auditor or competent authority ask to see?
Supervisors and independent auditors normally ask for evidence that the assessment happened before contracting, was documented, and fed into the decision. Expect requests for the assessment record for each arrangement, the register of information entries it relates to, the subcontracting chain, the reasoning on substitutability and related providers, the insolvency and data recovery analysis, and the approval trail. Auditors test whether the conclusions follow from the evidence. Note that only an independent auditor or the supervisor issues findings, and DeployOpen prepares the records and systems that show the assessment was carried out.
Which parts of the assessment are usually outsourced?
Organizations commonly outsource the technical mapping of hosting, subcontracting and data locations, the preparation of assessment templates and evidence packs, and the gap analysis against Article 29 and the related delegated regulations. Legal opinions on insolvency law and third-country enforcement are usually bought from counsel. The decision on whether a dependency is acceptable stays with the financial entity's management body. Ask any partner to separate their deliverables from those of legal advisers and to state clearly which conclusions remain yours.
How DeployOpen prepares Article 29 evidence
DeployOpen prepares the material an Article 29 assessment depends on, but the financial entity owns the assessment and its conclusions. The work starts with a written scope agreed before any review begins. That scope names the ICT services that support critical or important functions, the contracts and providers in question, and the decisions the assessment must support, such as whether a new arrangement would create a dependency on a provider that is not easily substitutable. DeployOpen does not decide whether a function is critical or important; the entity's own governance does that, and DeployOpen records the outcome as an input.
Next, DeployOpen maps systems and dependencies inside the client's own environment, whether that is their cloud accounts, data centers or air-gapped networks. For each self-hosted open-source platform in scope, the mapping records the hosting location, the underlying infrastructure and managed services, the subcontracted components, and any third-country dependency or long subcontracting chain that would affect monitoring. Where two arrangements share a provider, a region or a data recovery path, the mapping makes that overlap visible, because shared dependencies are the usual source of concentration risk that a single-contract review misses.
DeployOpen then prepares the documentation and evidence: the dependency map, the substitutability and exit notes, the insolvency and data recovery questions raised by the provider's jurisdiction, and the records of the cost and benefit comparison with alternatives. The client's risk function, management body and independent auditor review and challenge this material and decide what it concludes. DeployOpen does not issue audit reports, attestations or certifications; only independent auditors and competent authorities do that. Before work starts, confirm with your auditor which evidence format they expect and who signs the final assessment.
