TRUST-IT · Published
DECISION BRIEF
What this assessment should establish
- Confirm the legal entity and applicable requirements before collecting evidence.
- Use stable identifiers to connect business functions, assets, contracts and tests.
- Track unresolved gaps, accountable owners and retest criteria through to closure.
Confirm applicability and agree the assessment boundary
DORA has applied since 17 January 2025. Its scope and proportionality rules depend on the entity and applicable provisions. A bank, an ICT supplier and a family office should not be treated as interchangeable cases. Confirm the assessment perimeter with the organisation’s compliance and legal teams, including relevant competent-authority instructions. This guide proposes a technical evidence method; it is not an exhaustive regulatory checklist or a certification scheme.
Choose a specific service to trace, such as payment processing, customer onboarding or investment order handling. Record the entities, environments, locations, providers and reporting responsibilities involved. Define whether the work examines control design, operating effectiveness or both. Agree access permissions, safe testing windows, exclusions and the decision the resulting report needs to support.
Build a dependency map that can be reconciled
Start with a business-function identifier and connect it to applications, data stores, identity services, network dependencies, backup systems and external ICT services. Keep the business owner and technical owner distinct. Record how each dependency was confirmed: configuration export, service inventory, contract, interview or observed test. Mark inferred relationships as unverified until corroborated.
Reconcile the map against actual inventories rather than copying one spreadsheet into another. Look for a production application with no support owner, an unrecorded identity dependency, a backup service using the same administrative credentials, or a shared platform whose outage affects several functions. The purpose is to explain the consequence of a dependency and how recovery would work, not simply to count assets.
Keep the chain of evidence reviewable
- FunctionIdentify the business outcome
- DependenciesConnect systems and providers
- ControlsState what should happen
- EvidenceTest and retain provenance
- DecisionResolve gaps and retest
Give every evidence item provenance and a review criterion
The technical standards in Regulation (EU) 2024/1774 provide detail on ICT risk management. Translate the requirements applicable to the assessment into explicit checks. For example, an access-control review can reconcile the authorised privileged population with current role assignments and selected approval records; an operational change review can link an approved request to deployment evidence and rollback verification.
For each evidence item, record a stable reference, source system, collection time and timezone, coverage period, collector, version and access restrictions. Where useful, retain a cryptographic digest to detect later change; a digest does not establish that the original content was correct. Protect the collection and transfer channel, use redacted or synthetic records when adequate, and keep the main report separate from restricted technical material.
Connect the supplier register to the service actually delivered
Regulation (EU) 2024/2956 sets standard templates for the register of information. Maintain that regulated dataset using its applicable instructions. A separate working dependency map can help reconcile contracts, entities and ICT services, but should not silently replace or redefine the required templates.
Use stable contract and provider identifiers to investigate discrepancies between procurement, finance and technical inventories. Check whether the recorded service, supported function, contract period and responsible owner match current operations. For selected critical dependencies, ask how assurance findings are handled, what evidence supports exit planning and what assumptions rely on an untested replacement provider. Record missing or conflicting information as a gap with an owner, rather than filling it with an unsupported estimate.
A practical evidence register for the assessment
| Evidence area | Suggested working record | Review or validation |
|---|---|---|
| Business-service dependency | Function, application and provider IDs; named owners; source references. | Trace a selected service end to end and resolve contradictory inventories. |
| Control operation | Dated population export, approved configuration and sampled activity. | State sample selection and exceptions; distinguish design from operation. |
| Third-party ICT service | Contract/provider cross-reference and register-quality exceptions. | Reconcile selected entries to current contracts and actual service owners. |
| Incident and recovery exercise | Decision timeline, exercise outputs, restore checks and limitations. | Review handovers, business usability and unresolved recovery dependencies. |
| Remediation | Finding ID, evidence gap, owner, target date and acceptance criterion. | Retest the agreed check and record residual risk and approval. |
Rehearse incident evidence and recovery decisions
Regulation (EU) 2025/301 specifies content and time limits for major ICT incident notifications and reports. The organisation’s procedure should use the applicable rules and authority instructions. A useful exercise records when the team became aware of an event, when classification decisions were made, who approved the notification and what evidence supported each version. A technical alert alone does not establish the complete reporting decision.
In a controlled exercise, introduce partial information and require a documented handover between operations, risk, management and the reporting owner. Record uncertainty and corrections instead of retrospectively rewriting the timeline. For recovery, restore a selected process into an agreed environment and validate data integrity, access, reconciliation and business usability. Record observed recovery time and data loss against the approved objectives; do not infer a full-service result from a component-only test.
Deliver an evidence plan that supports ongoing oversight
A readiness engagement should leave a reviewed scope, dependency map, evidence register, findings and remediation plan. Assign an accountable owner and an acceptance check to each material gap. Distinguish a missing document from a control that failed a test and from an area that could not be assessed. A numerical score without these distinctions can conceal the decisions that management needs to make.
Agree who will maintain the records after organisational or supplier changes and how fixes will be retested. An existing ISO 27001 programme can contribute evidence, but its certification does not by itself establish DORA compliance. Similarly, routine penetration testing does not automatically meet the separate requirements applicable to threat-led penetration testing. TRUST-IT can scope technical assessment, evidence preparation and validation work alongside your internal risk, compliance and legal teams.
Illustrative scenario: a successful restore with an untested dependency
In an illustrative assessment, a payments application is restored successfully in isolation, but its production identity service and message reconciliation process are excluded from the exercise. The supported conclusion is that the tested component was restored. The team would record the exclusions, assign owners and agree an end-to-end exercise before claiming that the payment service can resume. This is a technical example, not a completed client project or a regulatory finding.
Common questions
Does this assessment provide DORA certification?
No. The deliverables describe the agreed technical scope, evidence, findings and remediation. Regulatory compliance depends on the entity’s applicable obligations and continuing operation; a report is not an authority’s approval.
Can we reuse our existing ISO 27001 evidence?
Yes, where it is current and covers the relevant entity, service and control. Map it to the assessment criterion, identify gaps and validate operating evidence instead of treating a certificate as a substitute for the review.
How should we start?
Identify the entity, a critical business service, its principal ICT dependencies and the decision you need to support. Agree a proportionate scope and secure evidence exchange before providing detailed configurations or customer records.
Further reading
- EUR-Lex — DORA, Regulation (EU) 2022/2554
- EUR-Lex — ICT risk management, Regulation (EU) 2024/1774
- EUR-Lex — Register of information, Regulation (EU) 2024/2956
- EUR-Lex — Incident reporting, Regulation (EU) 2025/301
Put the guidance to work
Connect risk management, GDPR, NIS2, DORA, and ISO 27001 preparation with practical CISO and DPO support.
Governance & compliance