Mapping DORA obligations to risks, controls, policies and evidence

A control register is not a regulatory mapping

Many programmes begin by placing DORA article numbers beside existing controls. That can be a useful index, but it does not yet explain the compliance position. A reviewer still needs to know which precise requirement was interpreted, why it applies, which risk or operational concern it addresses, what the control is expected to do, who operates it, how it is tested and which evidence supports the latest conclusion. A connected mapping makes those relationships explicit while retaining each record’s own purpose and history.

The objective is not to create the largest possible graph. It is to create the smallest set of durable relationships that lets a practitioner move from official source to accountable decision. DORA spans ICT risk management, incident handling and reporting, resilience testing, information sharing and ICT third-party risk. The same control may contribute to several obligations, and one obligation may depend on multiple controls. A many-to-many model reflects that reality better than duplicating the same control text under every article.

Begin with a versioned source hierarchy

Start with the official act and retain its identity, version and source URL. Break the material into navigable provisions and operational obligations at the level where ownership and evidence can be evaluated. An obligation should be specific enough to support an applicability decision and a control response, but it should not rewrite the law into an unsupported conclusion. Keep the original provision available beside the internal interpretation so reviewers can distinguish authoritative text from organisational analysis.

1. Source: the official regulation or technical standard, including version and authoritative URL.
2. Provision: the article, paragraph or annex location that gives the requirement context.
3. Obligation: the organisation’s reviewable statement of required action or outcome.
4. Applicability decision: the scope, rationale, reviewer and review date.
5. Operational response: connected risks, policies, controls, evidence and actions.

Map the risk without turning the regulation into a risk taxonomy

An obligation and a risk answer different questions. The obligation describes what the regulatory framework requires; the risk record describes uncertainty or exposure in the organisation’s context. Connecting them shows why a control response matters without forcing the legal structure to become the risk taxonomy. For example, an obligation relating to ICT business continuity can connect to service-unavailability and recovery-capability risks. Those risks can also be relevant to other regulations, internal policies and business objectives.

The mapping should retain direction and rationale. ‘Obligation addressed by risk’ is different from ‘risk affected by regulatory change’. A short relationship note can explain why the connection exists, who approved it and whether it is direct or contextual. When a DORA source update changes an obligation, impact analysis can then find the connected risks without treating every nearby record as automatically affected.

Separate policy intent from control operation

Policies express approved organisational direction. Controls are the repeatable activities, configurations or checks intended to achieve an objective. Keeping them separate avoids a common weakness: citing a policy document as if its existence proves that the underlying control operates. A DORA obligation may connect to one policy statement and several operational controls. Each control needs an owner, frequency or trigger, applicable scope, expected evidence and assessment history.

Control reuse should be deliberate. If access review control CTRL-IAM-07 supports multiple DORA obligations and GDPR security measures, maintain one control definition and map it to each relevant obligation. The DORA and GDPR assessments can still reach different conclusions because scope, risk, evidence and review authority differ. Reuse reduces duplication; it must not collapse distinct legal reasoning or accountability.

Treat evidence as a reviewed record

Evidence is not only an uploaded file. The record should state what was requested, which control and period it supports, who provided it, whether it is complete, when it expires and who accepted or rejected it. Automated evidence can carry provenance and collection time; manually supplied evidence needs equivalent context. A reviewer should be able to see what material supported a conclusion at that time even after newer evidence is collected.

For DORA, evidence may include approved ICT policies, risk assessments, control execution records, test results, incident reports, recovery exercise outputs, supplier registers, contract reviews and remediation approvals. The appropriate set depends on the obligation and the entity’s circumstances. The operating model should make expected evidence configurable rather than imply that one generic checklist proves compliance across every financial entity.

Use assessment and remediation to close the loop

A mapping becomes operational when it produces a decision. The assessor reviews obligation scope, control design, operation and supporting evidence, then records a conclusion with rationale. Missing or unsuitable evidence should not disappear into a note; it can create a finding, exception or remediation action connected to the affected obligation and control. Closure requires its own review so completion is not inferred merely from an owner marking an action done.

• Preserve the source and internal interpretation separately.
• Require relationship rationale for material mappings.
• Reuse controls without reusing conclusions blindly.
• Version applicability, assessment and evidence decisions.
• Connect gaps to owned actions and independent closure review.
• Retain source, configuration, operational and decision history as distinct audit trails.

An illustrative obligation-to-evidence path

Illustrative obligation OBL-DORA-028 is derived from a cited DORA provision and approved as applicable to business service SVC-012. It connects to resilience risk RSK-ICT-04, policy POL-BCM-02 and recovery-test control CTRL-BCP-11. Evidence request EREQ-088 defines the expected test record; evidence EVD-142 contains the reviewed exercise output; assessment ASM-061 records a partially effective conclusion; action ACT-243 assigns a recovery-documentation gap; closure decision DEC-233 confirms the remediation after independent review. Every identifier is representative product data rather than a customer result.

That path supports several buyer questions at once. Compliance can show why the obligation applies. Risk can see the exposure and treatment. Control owners know what must operate and what evidence is expected. Audit can inspect the assessment and closure history. Regulatory change analysis can identify the downstream records that may require review when the source changes. The shared model reduces repeated reconciliation while keeping the final decisions attributable to the teams authorised to make them.

Maintain mappings when sources and operations change

Mappings are not a one-time implementation artefact. A new regulatory version, revised technical standard, reorganised business service, changed provider or redesigned control can alter the reasoning. Change analysis should compare the versioned source or operational record, identify the relationships that may be affected and assign review to the appropriate owners. The system can propose an impact set, but a named reviewer should decide whether each obligation, risk, policy, control or evidence expectation actually requires amendment.

Quality checks should look for more than empty fields. Useful measures include obligations without applicability review, applicable obligations without an accountable owner, controls without current evidence, evidence used beyond its review period, findings without actions and actions closed without an authorised decision. These are workflow signals rather than claims of compliance. They help practitioners focus review on the places where the operating model cannot yet support its own conclusion.