Introduction
Under the EU Digital Operational Resilience Act (DORA), organisations must be able to demonstrate how business activities are supported by ICT, which dependencies matter, and what evidence proves readiness and recovery. An application inventory alone won’t do this. You need a traceable link connecting business functions to processes, ICT services, assets, third-party providers, controls and verifiable evidence.
This article describes an operational approach to build that chain and shows a worked example for a payment-instruction function. The guidance is practical and intended for entities preparing evidence for auditors and supervisors; it is not legal advice.
Why classify functions before mapping systems
DORA defines a "critical or important function" by its impact when disrupted: effects on financial performance, operational continuity, legal or regulatory obligations, or systemic stability. That impact belongs to the function, not automatically to any single software component.
- A single application can support multiple functions with different criticality levels.
- A single function can depend on many systems — some of which may look minor but are essential for recovery.
Make classification decisions traceable: record the business impact (affected services and customers, operational deadlines, monetary consequences, regulatory obligations), reference the Business Impact Analysis (BIA) used, and capture approval from the responsible governance body. This prevents arbitrary or unprovable classifications.
Note: designating a provider as a critical third-party supplier under DORA is a separate assessment from declaring a function critical. A supplier can support a critical function without being designated as a critical vendor in the EU oversight regime.
Building the mapping chain required by DORA
Article 8 of DORA requires identifying and documenting business functions supported by ICT, relevant assets and dependencies. Translate that requirement into a model that your risk and continuity processes can operate on.
Create a verifiable classification record
Each function needs a stable identifier and a clear service description, a business owner, the organisational scope, the rationale for classification, the BIA version cited, and the date and approver of the decision.
Avoid vague labels such as "payments system." Prefer: "Receipt, authorization and submission of customer payment instructions for retail segment X." Also document exclusions: if a component is not part of the function, explain why and who approved the exclusion. Stable identifiers must persist across renames or reorganisations so historical evidence stays linked.
Map direct and shared dependencies
A useful DORA map goes beyond the primary application. Include supporting capabilities that can prevent use or recovery: identity and access management, connectivity, DNS, databases, cryptographic keys, monitoring, backup services, and any external transmission services.
For each dependency record:
- Which ICT service or external service is involved
- The technical or business asset identifier
- The owner responsible for it
- The impact if it becomes unavailable
- Whether an alternative exists and whether that alternative has been verified
Pay special attention to shared services (for example, a single authentication platform that many functions use). An application-level map alone can hide concentration risks.
For third-party suppliers, link the service to the relevant contractual agreement and to the supplier register entries. Implementation rules under DORA provide templates for information registers; use them to standardise your supplier linkage.
Link risks to controls and then to evidence
A dependency implies scenarios (unauthorised access, data loss, service unavailability, transaction integrity loss, failure to recover). A good control definition specifies what is checked, the scope, who performs it, how often, and the acceptance criteria.
Avoid vague controls like "backups are in place." Replace with verifiable descriptions: "Restore of the function’s database in an isolated environment, with integrity checks and measurement of recovery time against the function RTO."
Crucially, each control must be linked to execution evidence and a recorded outcome. Policies and procedures describe control design; test reports, logs and signed test minutes show execution. Keep control identifiers and evidence identifiers separate because one recurring control produces multiple pieces of evidence over time.
(See our guidance on evidence for audits: /en/blog/audit-evidence.)
Operational example: the payment-instruction function
Assume a function has been assessed as critical. Its operation depends on the customer portal, an authorization engine, a transaction database and an external transmission service. The internal BIA sets illustrative recovery targets: RTO = 2 hours, RPO = 15 minutes. These are examples only — actual RTO/RPO must reflect your business impact and obligations.
Designing a concise control-and-evidence matrix
Below is a simplified set of dependency–control–evidence associations your map should support. Frequencies, sampling and test methods must be defined by your organisation.
- Identity and privileged access risk (unauthorised privileges): control = access review and authentication verification; owner = IAM lead; evidence = account extracts, approved review records, and revocation tickets.
- Database integrity and data loss: control = restore and reconciliation test of the transactions database; owner = DB lead; evidence = restore logs, measured recovery times, and reconciliation results.
- Infrastructure availability: control = failover/switchover test including dependent services verification; owner = infrastructure lead; evidence = test minutes, technical event logs, and post-switchover activities.
- External transmission service outage: control = verification of continuity and recovery arrangements with the provider; owner = service owner; evidence = provider reports, support tickets, and joint test results.
The matrix must also allow reverse navigation: from a piece of evidence you must be able to find the control it supports, the dependency it covers and the function affected. A test targeting only the database does not prove continuity of the entire payments function unless the test scope includes all dependent components.
When does a test truly demonstrate functional recovery?
A technical restore completed within the RTO may still be insufficient if another dependency remains unavailable (for example, authentication is down or credentials for sending instructions are blocked).
A test report should record environment, configuration version, start and end timestamps, recovery point used, and which business operations were exercised. For the payments example, confirm that recovered instructions reconcile correctly and that no uncontrolled duplicates occur.
If tests use non-production environments, document differences and limitations. Partial tests are useful but must be presented as partial.
When a criterion is not met, link the finding to a remediation item with an owner, due date and evidence of re-test. Don’t close issues based only on implemented changes; require verification that the observed problem is fixed.
Assigning responsibilities without role confusion
Roles should be clear:
- The function owner evaluates business impact and approves continuity needs.
- The technical owner operates dependencies and executes assigned controls.
- The supplier relationship owner collects supplier-side evidence and manages open actions.
- Risk and compliance confirm method consistency with the organisation’s governance.
- Internal audit performs independent assessment and should not be made the operational owner of the controls it audits.
In your map, distinguish who executes a control, who reviews the outcome and who can approve acceptance of residual risk. Labels like "owner: IT" are too vague to govern accountability. Record changes of ownership with effective dates and handover notes. Audit trail and change-traceability practices help reconstruct which map version applied at a given test or incident (/en/blog/audit-trail-best-practices).
Keeping the map up to date
A formally approved map does not remain accurate by default. Cloud migrations, supplier changes, new services, architectural changes and incidents can alter impacts or render evidence obsolete.
Define explicit update triggers: significant changes should trigger a review of affected links, owners and controls. Operationally, reconcile the map with the change-management system, the asset inventory and the supplier register. If a new database appears and no function references it, either link it or document why it is out of scope.
Maintenance must include evidence relevance: an old proof tied to a prior configuration may not cover the current setup. You do not need to repeat every test after every change, but you must justify which existing evidence remains valid and which items require new verification.
Incidents should feed updates: if an event reveals an unknown dependency, an ineffective control or an unexpected recovery time, the map and related controls must be revised accordingly.
Common mistakes that weaken your mapping
-
Treating the CMDB as a complete answer. A CMDB records assets and technical relationships but often lacks business impact rationale, decision approvals and executed-control evidence. Connect the CMDB to those items — don’t substitute one for the other.
-
Equating an SLA to proof of resilience. A contractual SLA describes expected performance; it does not, by itself, prove your function meets your recovery objectives. You need test outcomes, service metrics and verification of recovery mechanisms.
-
Overextending test evidence beyond its scope. Shared controls can serve multiple functions, but reusing evidence requires checking configuration, environment and scenarios covered. A backup test on one application does not automatically validate backups for all applications hosted by the same provider.
These errors produce documentation that looks complete but does not prove the function is protected for the scenario in question.
Pre-delivery checklist for auditors
Before exporting the map for auditor review, pick a function and trace the full chain to confirm navigability. This is a practical check of the map, not a substitute for a compliance assessment.
- Classification: the rationale cites documented impacts and an identifiable approval.
- Dependencies: applications, shared assets and external services are linked with stable identifiers.
- Controls: every control lists owner, scope, execution method and acceptance criteria.
- Evidence: each proof cites date, configuration/version, outcome and coverage limits.
- Remediation: findings have owner, deadline and verification evidence or a formally accepted residual risk.
- Traceability: the export allows reconstruction of links and versions without relying on the oral explanation of a single person.
If any step is missing, record it as a gap. An incomplete but declared perimeter is more defensible than a supposedly complete one that cannot be demonstrated.
Frequently asked questions
-
Does ISO 27001 replace this mapping? No. ISO 27001 can supply reusable controls and evidence, but you must verify their scope and relevance against the specific functions, dependencies and DORA obligations that apply.
-
Do I need a unique control for every function? Not necessarily. A shared control can cover multiple functions if the relationships are explicit and evidence demonstrates coverage for each function’s scope.
-
Can I start with a spreadsheet? Yes. Use stable identifiers, links to evidence and version control. As relationships and participants grow, ensure the method preserves ownership, history and link consistency.
-
Who decides if a function is critical or important? The organisation’s governance body should decide using documented impact criteria. It should not be an IT-only decision.
Preparing an evidence pack auditors can verify
A map is ready for audit when you can reconstruct function → dependency → control → evidence → remediation. AuditReady centralises evidence with ownership, versioning and an audit trail, and supports exports for auditors and stakeholders.
To evaluate this flow against your perimeter, request an AuditReady DORA demo: /en/auditready/lp/dora
The process described here is operational guidance and does not constitute legal advice on applicability or compliance.