DORA ICT Risk Register Template

In this article ↓

Short answer
DORA ICT risk register vs Register of Information
Minimum ICT risk register template
Example ICT risk register rows
How to define risk scoring
Link risks to critical or important functions
Function mapping table
Link risks to controls
Treatment decisions
Board and management-body reporting
Board risk report extract
Operating cadence
How to build the register in 30 days
Week 1: Scope and inventory
Week 2: Risk workshop
Week 3: Control and evidence mapping
Week 4: Management review
Evidence checklist
Common mistakes
Mistake 1: Mixing the ICT risk register with the supplier register
Mistake 2: Writing risks as control failures only
Mistake 3: No residual risk
Mistake 4: No owner
Mistake 5: No evidence links
Related reading
Primary sources
Bottom line
FAQ
Is the ICT risk register the same as the DORA Register of Information?
What fields should a DORA ICT risk register include?
How often should the ICT risk register be reviewed?
Who should own ICT risks under DORA?
Should supplier risks be recorded in the ICT risk register?
What makes an ICT risk register review-ready?

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.

Need to turn an ICT risk spreadsheet into operating evidence?

A 15-minute call can check whether the register structure will survive board, partner or supervisory review.

Book a free 15-min call →

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.

Primary sources

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.

DORA ICT Risk Register Template: 2026 Guide for Financial Entities