# DORA ICT Risk Register Template: 2026 Guide for Financial Entities

Source: https://www.cyadviso.com/dora-compliant-ict-risk-register
Last reviewed: 2026-04-29
Tags: DORA, ICT Risk

DORA ICT risk register template for 2026: required fields, risk scoring, control mapping, ownership, third-party dependencies and board-ready audit evidence.

---

**Last reviewed: 29 April 2026**

**Key takeaways**

- A DORA-ready ICT risk register connects risks, controls, owners, evidence and management reporting.
- The register should be operational: reviewed, updated and linked to remediation, incidents and suppliers.
- Supervisors and partners ask how ICT risk decisions are made, challenged and closed.
- Fastest path: define risk taxonomy -> assign owners -> link evidence -> review exceptions regularly.

## Short answer

A DORA ICT risk register is the operating record that connects ICT risks, business impact, controls, owners, remediation and management-body oversight.

It is different from the DORA Register of Information. The Register of Information maps ICT third-party arrangements. The ICT risk register maps risks and controls across technology, processes, providers and critical or important functions.

In 2026, a useful DORA ICT risk register should show:

- which ICT risk exists;
- which critical or important function is affected;
- which asset, process or provider creates exposure;
- inherent and residual risk;
- control owner;
- treatment decision;
- remediation action;
- review date;
- evidence link;
- board or management-body reporting status.

The goal is not to create a large spreadsheet. The goal is to make ICT risk decisions traceable.

## DORA ICT risk register vs Register of Information

These two artefacts are related, but they are not the same.

| Artefact | Main question | Primary use |
|---|---|---|
| ICT risk register | What ICT risks could disrupt the entity, and how are they controlled? | Risk management, board reporting, remediation |
| Register of Information | Which ICT third-party arrangements exist, and which functions do they support? | Third-party risk transparency and reporting |
| Supplier contract tracker | Which ICT contracts have DORA-relevant clauses or gaps? | Article 30 contract remediation |
| Asset inventory | Which ICT assets support services and data flows? | Control scoping and dependency mapping |

For a financial entity, the clean operating model links all four. A critical cloud provider appears in the Register of Information. The outage, concentration, exit and data risks connected to that provider appear in the ICT risk register.

## Minimum ICT risk register template

The register should be simple enough to maintain and complete enough to defend.

| Field | Purpose | Example |
|---|---|---|
| Risk ID | Stable reference | ICT-001 |
| Risk title | Short risk name | Core ledger outage |
| Risk description | What could happen and why | Cloud-hosted ledger unavailable during payment processing |
| Critical / important function | Business function affected | Payment execution |
| Asset / provider / process | Source of exposure | Core ledger SaaS, cloud region |
| Inherent impact | Impact before controls | High |
| Inherent likelihood | Likelihood before controls | Medium |
| Existing controls | Controls currently operating | Multi-region backup, monitoring, DR test |
| Residual risk | Risk after controls | Medium |
| Risk owner | Accountable person | CTO |
| Control owner | Person operating the control | Infrastructure lead |
| Treatment decision | Accept, mitigate, transfer, avoid | Mitigate |
| Remediation action | What must change | Run quarterly restore test |
| Due date | Target date | 2026-06-30 |
| Evidence link | Proof | DR test report, board pack |
| Last review | Currency | 2026-04-29 |

Avoid free-text-only registers. Use defined values for likelihood, impact, status, owner, function and treatment decision so the register can be filtered, challenged and reported.

## Example ICT risk register rows

| Risk ID | Risk | Function affected | Source | Residual risk | Owner | Treatment |
|---|---|---|---|---|---|---|
| ICT-001 | Payment platform outage | Payment execution | Payment processor + cloud dependency | Medium | CTO | Mitigate through DR and provider SLA review |
| ICT-002 | Incident reporting delay | Regulatory reporting | Manual classification and unclear escalation | High | COO | Mitigate through workflow and tabletop test |
| ICT-003 | Supplier concentration | Customer onboarding | Single KYC provider | Medium | Head of Operations | Mitigate with exit plan and fallback review |
| ICT-004 | Privileged access misuse | Core systems administration | Weak access review cadence | Medium | CISO | Mitigate with quarterly review and MFA evidence |
| ICT-005 | Backup restore failure | Business continuity | Untested restore procedure | High | Infrastructure lead | Mitigate with restore test and RTO/RPO evidence |

These rows are examples, not a complete risk taxonomy. Each entity should calibrate risk descriptions to its licence, services, architecture and dependency profile.

## How to define risk scoring

The risk register needs a scoring method that the management body can understand.

Start with a simple impact and likelihood model.

| Impact level | Example criterion |
|---|---|
| Low | Localised disruption, no regulated service impact |
| Medium | Service degradation, manual workaround available |
| High | Regulated service disrupted, customer or reporting impact |
| Critical | Critical or important function unavailable, material customer or systemic impact |

| Likelihood level | Example criterion |
|---|---|
| Low | Unlikely based on architecture and history |
| Medium | Plausible scenario or known control weakness |
| High | Repeated events, weak controls or material external exposure |
| Critical | Active issue, unresolved incident pattern or unacceptable control gap |

The exact scoring scale can be 3x3, 4x4 or 5x5. What matters is consistency and evidence. A risk score without rationale is weak.

## Link risks to critical or important functions

DORA risk management should not stay at the asset level. A server, SaaS tool or API matters because it supports a business function.

For each material risk, capture:

- business function affected;
- whether the function is critical or important;
- customer or market impact;
- legal entity affected;
- NCA or reporting relevance;
- third-party dependency;
- recovery objective.

### Function mapping table

| Risk source | Function affected | DORA relevance |
|---|---|---|
| Cloud outage | Payment execution | Critical or important function, BCDR and provider risk |
| KYC vendor failure | Customer onboarding | Operational dependency and third-party risk |
| SIEM failure | Incident detection | Incident management and detection capability |
| Core database corruption | Account balance integrity | ICT risk, data integrity, recovery |
| Staff phishing compromise | Privileged access and data exposure | Security controls, incident classification |

This mapping makes the register useful for board reporting. It turns technical risks into business decisions.

## Link risks to controls

A risk register should not be a list of worries. Each risk should point to operating controls.

| Risk type | Example controls | Evidence |
|---|---|---|
| Service outage | Monitoring, redundancy, DR plan, provider SLA | Monitoring dashboard, DR test, SLA review |
| Data loss | Backup, restore test, access controls, encryption | Backup logs, restore evidence, access review |
| Incident delay | Classification workflow, escalation matrix, tabletop exercise | Incident log, decision trail, exercise report |
| Supplier failure | Due diligence, Register of Information, exit strategy | Supplier assessment, register entry, exit plan |
| Access misuse | MFA, privileged access management, quarterly access review | MFA report, access review sign-off |

If a control has no evidence, treat it as unproven. If a risk has no control owner, treat it as unmanaged.

## Treatment decisions

Every material risk needs a decision.

| Treatment | When it may be appropriate | Evidence |
|---|---|---|
| Mitigate | Control gap can be reduced with action | Remediation plan, owner, date |
| Accept | Residual risk is within appetite | Risk acceptance record, management approval |
| Transfer | Insurance or contractual allocation helps reduce impact | Insurance note, contract clause |
| Avoid | Activity or provider is too risky | Exit decision, decommission plan |

Risk acceptance should not be informal. If the entity accepts residual risk for a critical or important function, the decision should be visible to the right level of management.

## Board and management-body reporting

DORA expects management-body oversight of ICT risk. The ICT risk register is a natural source for board reporting.

### Board risk report extract

| Report section | Data from the risk register |
|---|---|
| Top ICT risks | Highest residual risks and changes since last review |
| Overdue remediation | Actions past due date, owner, reason |
| Risk acceptances | Accepted residual risks and approving body |
| Critical functions | Risks mapped to critical or important functions |
| Supplier concentration | Risks linked to major providers or platforms |
| Incident lessons | New risks or score changes after incidents |

Board reporting should show movement. A static top-risk list every quarter suggests the register is not being used.

## Operating cadence

The ICT risk register should be updated by events, not only on a calendar.

| Trigger | Register update |
|---|---|
| New critical system | Add related risks and controls |
| New ICT provider | Assess supplier-related risks and link to Register of Information |
| Major incident | Add or update risk, controls and remediation |
| Failed resilience test | Increase risk score or open action |
| Contract renewal | Review Article 30 and exit-related risk |
| Architecture change | Reassess impact and recovery assumptions |
| Board review | Update decisions, acceptances and priorities |

For a fintech SMB, a quarterly review is a reasonable baseline, with event-driven updates for incidents, supplier changes and major technology releases.

## How to build the register in 30 days

### Week 1: Scope and inventory

- Confirm DORA scope and legal entity.
- Identify critical or important functions.
- Pull asset, supplier and process inventories.
- Identify relevant NCA and reporting context.

### Week 2: Risk workshop

- Run a cross-functional ICT risk workshop.
- Include technology, security, compliance, operations and business owners.
- Draft top 10-20 ICT risks.
- Map each risk to function, asset/provider and owner.

### Week 3: Control and evidence mapping

- Link each risk to existing controls.
- Identify missing control evidence.
- Add remediation actions and due dates.
- Align supplier-related risks with the Register of Information.

### Week 4: Management review

- Prepare a board or management-body risk summary.
- Agree treatment decisions for high risks.
- Record risk acceptances.
- Set the ongoing review cadence.

The register does not need to be perfect on day 30. It needs to be owned, structured and improving.

## Evidence checklist

| Evidence | Why it matters |
|---|---|
| ICT risk register | Core risk record |
| Scoring methodology | Shows consistency |
| Critical-function mapping | Links ICT to business impact |
| Control evidence | Proves controls operate |
| Remediation tracker | Shows gap closure |
| Risk acceptance records | Shows management decisions |
| Board pack | Shows oversight |
| Incident after-action reports | Shows learning and risk updates |
| Testing reports | Shows resilience evidence |
| Register of Information links | Shows supplier dependency integration |

This evidence set is what turns the register from an internal spreadsheet into a review-ready DORA artefact.

## Common mistakes

### Mistake 1: Mixing the ICT risk register with the supplier register

Supplier data is important, but the ICT risk register must also cover internal systems, processes, incident management, access control, recovery and governance risks.

### Mistake 2: Writing risks as control failures only

"No DR test" is a finding. The risk is inability to recover a critical service within required objectives. Write risk statements in business-impact language.

### Mistake 3: No residual risk

Inherent risk alone is not enough. The register should show the risk after existing controls and the decision on whether that residual risk is acceptable.

### Mistake 4: No owner

If everyone owns a risk, no one owns it. Separate the accountable risk owner from control operators.

### Mistake 5: No evidence links

Controls without evidence become assertions. Add evidence links or document what is missing.

## Related reading

- [DORA Compliance Checklist 2026: Practical Implementation Guide](/dora-compliance-guide)
- [DORA Register of Information: 2026 Guide for ICT Third-Party Risk](/dora-register-of-information)
- [DORA Requirements in 2026: 10 Controls Financial Entities Must Keep Current](/dora-requirements-2025)
- [DORA board responsibilities and management-body evidence checklist](/dora-board-responsibilities-2025-eu-financial-checklist)
- [DORA Business Continuity and Disaster Recovery: Articles 11-12 Roadmap for 2026](/dora-business-continuity-and-disaster-recovery)

## Primary sources

- [Regulation (EU) 2022/2554 — DORA, EUR-Lex](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R2554)
- [European Banking Authority — Digital Operational Resilience Act (DORA)](https://www.eba.europa.eu/activities/direct-supervision-and-oversight/digital-operational-resilience-act)
- [EBA — Regulatory Technical Standards on the ICT risk management framework](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/operational-resilience/regulatory-technical-0?version=2024)
- [EBA — Guidelines on ICT and security risk management](https://www.eba.europa.eu/activities/single-rulebook/regulatory-activities/internal-governance/guidelines-ict-and-security-risk-management)

## Bottom line

A DORA ICT risk register is useful when it supports decisions.

It should show what can go wrong, which function is affected, who owns the risk, which controls operate, what evidence exists and what still needs remediation.

In 2026, the strongest register is not the longest spreadsheet. It is the one the management body can read, challenge and use.

## FAQ

### Is the ICT risk register the same as the DORA Register of Information?

No. The ICT risk register tracks ICT risks, controls, owners, residual risk and remediation. The Register of Information tracks ICT third-party service arrangements. They should link to each other, but they are different artefacts.

### What fields should a DORA ICT risk register include?

At minimum, include risk statement, affected function, asset or supplier, inherent risk, existing controls, residual risk, owner, treatment decision, remediation action, due date, evidence link and latest review date.

### How often should the ICT risk register be reviewed?

Quarterly review is a practical baseline for many fintech SMBs, but the register should also be updated after material incidents, supplier changes, failed tests, architecture changes and management-body decisions.

### Who should own ICT risks under DORA?

Each material ICT risk should have a named accountable owner, usually from technology, security, operations or business leadership. Control operators can support the risk owner, but ownership should not be left to an unnamed team.

### Should supplier risks be recorded in the ICT risk register?

Yes, where the supplier affects ICT services, critical or important functions, security, resilience or recovery. Supplier risks should also connect to the Register of Information and contract review evidence.

### What makes an ICT risk register review-ready?

A review-ready register has clear scoring, current owners, residual risk decisions, evidence links, remediation status, management review records and traceability to critical functions, incidents, testing and supplier dependencies.

---

Authored by Andrey Gubarev — CISO for EU fintechs (CISM, CDPSE, SABSA).
CyAdviso · DORA / ICT risk / vCISO programmes for EU-licensed fintechs.
Canonical HTML: https://www.cyadviso.com/dora-compliant-ict-risk-register