DORA ICT Dependency Map: From Critical Function to Tested Exit
A DORA ICT dependency map becomes useful when a reviewer can trace one business function to the services it needs, the parties controlling those services and the evidence that an alternative operating path can work. A list of supplier names does not show whether the receiving team can obtain the data or sign in when the original provider is unavailable.
Start with one function and follow its exit path. Record the dependencies that must survive the transition, then assign an observation that could demonstrate each requirement. Keep a proposed alternative separate from a tested capability. An unresolved identity dependency can stop the exit even when a replacement application is ready.
The twelve-field register D-108 below is a proposed engineering aid. Its function, providers and exercise quantities are fictional; no supplier exit or recovery test was performed. It does not determine whether an entity falls within DORA or establish regulatory compliance. The responsible legal and risk owners must determine the applicable obligations, including relevant technical standards and proportionality.
Use the regulation to set the boundary of the map
DORA Article 8 addresses identification and documentation of ICT-supported functions, supporting assets and dependencies. Article 28(8) addresses exit strategies for ICT services supporting critical or important functions. These provisions connect dependency knowledge to exit planning; they do not prescribe the twelve-field worksheet used here.
On exit plans, the European Parliament and Council state in Article 28(8) that they "shall be sufficiently tested and reviewed periodically." The same provision qualifies the testing by reference to Article 4(2)'s criteria. Keep that qualification beside the requirement when deciding the scope of an exercise.
The engineering consequence is a traceable review question: which operating dependency could prevent this function from continuing through the chosen exit scenario, and what evidence would resolve that concern? Answer it with a bounded map and exercise specification rather than a generic statement that a provider can be replaced.
This working map supplements the organization's contractual records and other required inventories. It should point to their authoritative versions instead of becoming an unofficial duplicate. A technical reviewer may identify a missing dependency; the accountable owner still determines how that finding affects the organization's regulatory and business decisions.
Name the function before naming the infrastructure
Define the business outcome the organization needs to preserve. In the fictional example, F-108 accepts synthetic payment instructions and makes their processing status available to a receiving operator. The example assumes a business owner has classified the function as critical or important. That classification is an assumption for the scenario, not a conclusion reached by this article.
Draw the boundary around that outcome. A map of the entire cloud estate can overwhelm the review, while a diagram of one application can omit the identity service needed to use it. Include the dependencies that determine whether the agreed business outcome remains possible under the specified conditions.
Distinguish a business function from an ICT service and from an asset. A customer-facing instruction intake function might depend on a hosted workflow service. That service might use a queue and a data store. The contract may name one provider while another party controls a dependency that the function cannot operate without.
For each connection, record why it matters. The queue carries pending work; the status store identifies completed instructions; the identity service permits the receiving team to administer the replacement. A label such as cloud dependency leaves the exit reviewer guessing which capability must be preserved.
Assign a function owner who can approve the minimum acceptable outcome. A supplier can describe an export format, but cannot alone decide whether the receiving business can operate with the records that format omits.
Specify twelve fields that connect dependencies to evidence
Use stable record references rather than copying sensitive configuration into the worksheet. The fields below describe an evidence relationship, not a universal DORA reporting template. Keep the entries small enough that a reviewer can identify the source and the unresolved condition without opening an entire project archive.
| Register field | What belongs in it | Review question |
|---|---|---|
| Function and owner | Function boundary, classification reference and accountable business owner | Who determined what must continue? |
| Operating service | The ICT service used to deliver the function | What capability must remain available? |
| Supporting assets | Relevant application, data store and network references | Which assets carry the required work and records? |
| Provider and contract | Service provider identity and authoritative contractual reference | Which party is responsible for the contracted service? |
| Indirect dependencies | Material subcontracting or shared control dependencies, with known limits | What can remain dependent on the original path? |
| Data and state | Required data, pending work and retained evidence | What must the receiver obtain and understand? |
| Access and authority | Administrative identity, permissions and usable access path | Can the receiver operate without the departing provider? |
| Recovery assumptions | Approved objectives, timing boundary and data-loss assumptions | What target is being assessed? |
| Exit route | Alternative provider or in-house path, with prerequisites | Is the alternative operationally distinct where required? |
| Exercise specification | Scenario, environment, fixture and expected assertions | Which conditions would the exercise actually demonstrate? |
| Evidence and receiver | Observations, retained artifacts and authorized receiving reviewer | Can another reviewer inspect the result? |
| Disposition and revision | Open gaps, decision owner and reviewed configuration | What remains unproved, and what change triggers review? |
Keep one record scoped to a coherent service dependency. If two services have different exit routes or evidence owners, split the records and link them to the same function. One large cell containing several providers and an unexplained pass label cannot support separate decisions.
Follow fictional D-108 through a shared identity dependency
Suppose provider P-A operates the current workflow service and P-B is the proposed replacement. Both rely on identity service I-Z. The planning team has not established how a receiving administrator could authenticate if the relevant I-Z path becomes unavailable. Naming P-B therefore does not resolve this dependency.
The completed planning example below records that gap explicitly. Its values describe a hypothetical review packet; they are not observed capabilities or executed exercise results. No real provider is being assessed.
| D-108 field | Fictional planning entry |
|---|---|
| Function and owner | F-108 synthetic instruction intake; criticality assumed for illustration; business operations owner |
| Operating service | Workflow service S-108 accepts instructions and exposes their processing status |
| Supporting assets | Queue Q-108, status store L-108 and their configuration references |
| Provider and contract | P-A current service; contractual reference C-108, assumed for the scenario |
| Indirect dependencies | Current and proposed routes both use identity service I-Z; independence unresolved |
| Data and state | Twelve synthetic instructions: eight accepted, three pending and one rejected in the planned fixture |
| Access and authority | Receiving administrator named; independent usable access path not established |
| Recovery assumptions | Business-approved objectives required; no achieved recovery time or data-loss result recorded |
| Exit route | Proposed P-B service; data import and administrative access remain prerequisites |
| Exercise specification | Provider-unavailable rehearsal with synthetic records and an independent receiver read-back |
| Evidence and receiver | Planned evidence packet E-108; no execution observations yet; receiving operations reviewer |
| Disposition and revision | NOT RUN; affected exit-readiness decision remains HOLD pending access evidence |
The point is not to reject every shared service. Some dependencies can remain acceptable under the chosen scenario. The reviewer must establish whether I-Z stays available and usable under that scenario, or whether another authorized path is needed. Until then, an independence claim is premature.
Look beyond the party named in the contract
A provider relationship and an operating dependency are different edges in the map. The contracting entity might be responsible for a service while another component supplies its identity or storage. Record the dependency that matters to continuity without treating every software library as a separate supplier exit project.
Choose depth by the function and failure scenario. If the receiving team cannot use P-B without an administrator controlled by P-A, that access path belongs in the review. If a documented support contact has no bearing on the tested operating path, it may belong in the supporting records rather than the main diagram.
Mark the basis of each edge. A contract, a reviewed configuration and a supplier statement provide different evidence. An unverified supplier statement should not appear with the same status as an independently observed connection. A missing subcontractor detail is an information gap to assign, not a relationship to invent.
Check whether the proposed alternative changes the relevant failure boundary. Two services may share a region or a control plane even when their product names differ. Whether that matters depends on the exit scenario. A planned commercial transition can assume cooperation that a provider-failure rehearsal must explicitly challenge.
Ask the receiving team to explain one dependency in its own words. They should identify the capability it supplies, the evidence supporting the connection and the consequence if it is unavailable. That explanation is a useful review check before anyone schedules a costly exercise.
Treat a usable data transfer as more than an export file
Specify which information the replacement needs to continue the function. For D-108, the synthetic instructions require stable identifiers and interpretable status. A file containing rows may still omit the relationship between a pending instruction and its last acknowledgment.
Agree the comparison population before exporting. In the planned fixture, eight accepted instructions plus three pending instructions plus one rejected instruction account for all twelve. These numbers are illustrative categories, not observed processing outcomes. A receiving reviewer must be able to locate each identifier and understand its disposition.
Do not equate import success with business completeness. A target application might accept the file while dropping a status it does not recognize. Include an assertion for the meaning of the imported state, along with handling for records that cannot be translated without a decision.
Preserve the records needed to explain work that remains with the original provider. An exit can have a transition period, and that period needs ownership. Identify who can read the old status, who can resolve an exception and which evidence the receiving organization can retain afterward.
Use synthetic or appropriately authorized data for the exercise. The map should reference secure evidence storage rather than reproduce customer records or secrets. Record the location and custody requirements relevant to the actual service, while leaving any jurisdiction-specific interpretation to the responsible reviewer.
Account for work that crosses the transition boundary
Give every instruction in the fixture a receiving disposition. For the eight accepted synthetic instructions, define which record establishes acceptance and whether any further processing remains outside the tested function. Accepted must not silently become a claim of completed settlement or another downstream outcome the exercise did not inspect.
For the three pending instructions, identify where they remain queued and who can decide their next treatment. Moving a copy into P-B does not by itself authorize both environments to process the same work. The exercise specification needs a rule for ownership at the transition boundary and evidence that the receiving operator can apply it.
The rejected instruction still matters to the record population. Its rejection reason and identifier may be needed to explain why it did not move with pending work. Deleting it to make the imported row count match a preferred total would conceal a state difference rather than resolve one.
Distinguish evidence of capability from the disposition of this particular fixture. The receiver might demonstrate that it can read a pending instruction and assign an owner, while the fictional planning packet still contains no actual execution. Record the observed capability only when an authorized exercise produces evidence, and keep unresolved work visible until its own decision is made.
If the original provider remains responsible during a transition period, preserve a usable route to the relevant old records. A contract end date does not establish that all instructions have crossed the operating boundary. The map should show which dependency remains and the condition for removing it.
Keep recovery targets separate from observed exit results
An approved recovery time objective is a target, not an elapsed time achieved by a rehearsal. A recovery point objective describes the tolerated data-loss boundary chosen for the relevant context; it does not prove the exported records satisfy that boundary. The map should retain both the assumption and the observation used to assess it.
Define the clock's start and stop events. Starting when an engineer opens a migration tool excludes the time needed to recognize a provider failure and authorize the transition. Stopping when infrastructure is running can exclude the receiving team's first usable business operation.
The correct timing boundary depends on the agreed scenario. A planned exit over an extended transition and an urgent provider failure are different exercises. Do not use a successful planned migration as evidence that an emergency recovery objective was met under unavailable-provider conditions.
Where the exercise uses a smaller workload or a simulator, state the limitation. It may demonstrate that identifiers and status semantics survive transfer without establishing throughput under the real operating workload. A single timing result cannot silently inherit conditions that were absent from the test.
For D-108, no timing result is filled in because the exercise has not run. The worksheet can still reveal a blocked prerequisite: the receiver's independent access path is unresolved. That finding should be addressed before a rehearsal is described as a complete demonstration of the proposed route.
Choose what the failure scenario actually removes
State whether the exercise assumes a cooperative provider, degraded service or loss of the relevant provider capability. These conditions change which evidence is useful. A planned transition can reasonably include agreed assistance; a provider-unavailable scenario cannot rely on that assistance without declaring the contradiction.
For D-108, specify what remains available from I-Z. If the scenario removes only P-A's workflow service while I-Z remains independently usable, shared identity may be acceptable for that exercise. If the scenario also removes the receiving administrator's authentication path, the team needs evidence for another authorized route before calling that scenario supported.
Use the same discipline for data retrieval. A fresh export obtained from a cooperative P-A can support a planned migration. It does not establish how a receiver obtains current records when P-A cannot respond. A retained snapshot may support a narrower continuity option, with its age and missing work made explicit.
Record scenario exclusions in ordinary language. For example, the exercise might test replacement application access while excluding a regional outage. That result should remain tied to that scope. Avoid a broad provider-failure label that suggests every dependency failed when the fixture actually removed only one interface.
Ask the decision owner whether the narrower result is enough for the intended business decision. If it is useful but incomplete, retain it as partial evidence and assign the additional scenario. Repeating the same cooperative demonstration cannot answer a different question merely because its screenshots are clearer.
Give the exit rehearsal six concrete questions
An exercise specification should name the unavailable components and the observations needed to judge the proposed route. The questions below are planning prompts to adapt, not a claim that this set exhausts the organization's testing obligations.
- Can the receiving operator authenticate and administer the proposed environment while the original provider's relevant access path is unavailable? Retain the observed route and its authority boundary.
- Can the receiver obtain the agreed data population without relying on a live export action from a provider assumed to be unavailable? Identify any previously retained snapshot and its limitations.
- Can the receiver interpret every instruction's state and identify pending or rejected work? Compare identifiers and meanings, not only row counts.
- Can the function perform its agreed minimum business operation through the proposed route? Observe that operation rather than inferring readiness from running infrastructure.
- Can the operating team handle an exception that spans the transition boundary? Name the party responsible for the old record and the party authorized to decide the next step.
- Can another authorized reviewer read the retained packet after the demonstration ends? Preserve the evidence path and the configuration to which the result applies.
Run the appropriate questions under conditions the organization has approved. Deliberately removing production access or disrupting a live provider is not implied by an engineering worksheet. A controlled rehearsal needs its own authority, containment and recovery arrangements.
Allow partial results. An exercise can establish data readability while leaving access independence unresolved. Record those outcomes separately, so a useful observation survives without being promoted into a broader exit-readiness claim.
Make evidence readable by the receiving owner
For each observation, retain the exercise reference, reviewed configuration and source artifact. Show the expected condition next to the actual observation. If the team could not obtain a required record, preserve that absence and assign an owner rather than inserting the planned value.
Separate evidence from interpretation. A screenshot may show that an administrator opened a page. It does not necessarily establish who controlled the identity service or whether the same access would remain available in the failure scenario. Link the observation to the specific assertion it supports.
Give the receiver access to the packet while the people who produced it are still available to explain its limits. A supplier-only dashboard can become inaccessible precisely when the exit matters. Agree a retained form the receiving organization can actually use within its permitted access and retention rules.
Use explicit dispositions such as NOT RUN, OBSERVED, UNRESOLVED or EXCLUDED for individual assertions. Keep the business acceptance decision separate. A record with every cell filled may still contain an unresolved prerequisite and therefore support a hold on the affected exit route.
If a gap is accepted temporarily, name its operating consequence and decision owner. Record the conditions for review and the evidence needed to close it. A general risk acceptance entry does not explain which function remains dependent on P-A or who can act if the assumption fails.
Review the map when the operating path changes
Tie the map to the service configuration it describes. A new identity provider, an altered export schema or a changed support boundary can invalidate a previously useful exercise result. Preserve the earlier result and identify which assertions need repeating for the changed path.
Keep updates connected to existing change and supplier-review processes. The working register should reference the authoritative records rather than compete with them. Define who detects a relevant change, who updates the dependency record and who decides whether additional evidence is required.
For a custom financial platform, Pharos Production's FinTech development services provide a relevant starting point for discussing payment-system architecture and integration scope. Ask for the dependency map, receiving responsibilities and exit exercise boundaries as named deliverables. A service description does not establish that a particular exit route has been tested.
Before approving D-108, the receiving reviewer would need an answer to the I-Z access question and observations from the agreed exercise. Until those exist, the accurate conclusion is limited: the proposed map identifies an unresolved shared dependency and an owner for the next evidence request. It does not establish an executed or successful exit.
More insights to read
- Cutover Acceptance Records: Baseline, Trigger and Return State
- Supplier Exit Acceptance: Access Closure and Operating Independence
- Supplier Access Exit: Privilege Inventory and Revocation Evidence
- The Payment Recovery Fieldbook: Identity, Replay and Reconciliation
- How to Scope a FinTech Blockchain Discovery Sprint
About the author
Dmytro Nasyrov. Photo supplied by the author.
Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder and CTO of Pharos Production. He works on production software architecture for FinTech, AI, Web3 and blockchain systems.
Comments
Post a Comment