DORA ICT Risk Register Template: A Practitioner Outline

TL;DR — DORA Article 8 obliges in-scope firms to identify, classify and adequately document all ICT-supported business functions, information assets and ICT third-party dependencies. This piece is a practitioner template for the underlying ICT risk register — the fields, the taxonomy, who owns each row, how often it is refreshed, and three worked examples a Head of Compliance or DPO can lift straight into their GRC tooling.

Table of contents

• Why the ICT risk register matters
• Where the register sits in the DORA framework
• The minimum fields
• Classification taxonomy aligned to the RTS
• Three worked examples
• Ownership and refresh cadence
• Common supervisory findings
• A 10-item quality check
• How leading firms automate this with Sedric
• FAQ

Why the ICT risk register matters

Most DORA workstreams start with a framework document and the Register of Information. The artefact that supervisors keep coming back to in walk-throughs, though, is the underlying ICT risk register: the structured inventory of ICT-supported business functions, the information assets that support them, the threats and vulnerabilities mapped against them, the controls in place, and the residual risk owners are accepting.

The Register of Information (Article 28) is about third-party arrangements. The ICT risk register is about the firm's own functions and assets. They feed each other — a function in the risk register references the third parties recorded in the Register of Information — but they are not the same artefact, and supervisors notice when firms have conflated them.

Done well, the ICT risk register is the spine that connects the framework (Article 6), business-function classification (Article 8), incident classification (Article 18) and testing scope (Article 24). Done poorly, it is a spreadsheet that nobody updated since the project kickoff.

Where the register sits in the DORA framework

Article 8(1) of Regulation (EU) 2022/2554 states that financial entities shall "identify, classify and adequately document all ICT supported business functions, roles and responsibilities, the information assets and ICT assets supporting those functions, and their roles and dependencies in relation to ICT risk."

Article 8(2) requires firms to identify on a continuous basis all sources of ICT risk and to review at least yearly. Article 8(3) requires assessment of cyber threats and ICT vulnerabilities relevant to the firm's functions.

The Level 2 detail is in Commission Delegated Regulation (EU) 2024/1774 — the RTS specifying the elements of the ICT risk management framework, including the taxonomy for the asset inventory, the documentation expectations, and the simplified regime for entities falling under Article 16 (microenterprises and the small/non-interconnected subset of investment firms).

For the third-party side, the ITS in Commission Implementing Regulation (EU) 2024/2956 sets the Register of Information template. The two artefacts share keys (function identifier, criticality classification) but answer different questions.

The minimum fields

Below is the field set we recommend for the core ICT risk register. The first block (rows 1–6) is the asset record. The second block (rows 7–12) is the risk record that hangs off it.

Asset record fields

1. Asset ID — internal identifier. Stable across rebranding and re-platforming events.
2. Asset name and description — the operational name and a one-line description.
3. Asset type — from a controlled taxonomy: information asset, ICT system, network component, software, hardware, or data set. Align to RTS Article 4 expectations.
4. Supported business function(s) — link to the function identifier used in the Register of Information. Avoid free text here.
5. Criticality classification — critical, important, or non-critical. Defined consistently with how the firm classifies "critical or important functions" elsewhere in the framework.
6. Owner and information owner — a named role (not a person) for accountability; a named individual for the current incumbent.

Risk record fields

7. Threat scenario — e.g., ransomware on the core banking platform; insider exfiltration of customer records; supplier outage at the payment gateway.
8. Vulnerabilities — specific, not generic. "Out-of-support OS on host X" rather than "weak patching".
9. Inherent risk rating — likelihood × impact, on a defined scale.
10. Controls — the specific controls in place, referenced by control ID where you have a control library.
11. Residual risk rating — after the controls are applied.
12. Risk treatment decision and owner — accept, treat, transfer, avoid; with the accountable owner and review date.

We also recommend three operational fields that are not strictly required by the RTS but make the register usable:

• Last reviewed — date and reviewer.
• Linked incidents — IDs of any classified incidents that touched this asset/function.
• Linked test findings — IDs of test findings (Article 24) that touched this asset/function.

Classification taxonomy aligned to the RTS

The RTS (Commission Delegated Regulation (EU) 2024/1774) does not mandate a fixed taxonomy, but it sets expectations that the taxonomy is documented, internally consistent, and capable of supporting the wider framework. The taxonomy below is what we see working in practice for medium-to-large EU credit institutions, payment institutions and insurers.

Asset type taxonomy

• Information asset: a dataset or information collection (customer records, transaction history, model artefacts).
• ICT system: an application or platform (core banking, KYC platform, complaints management).
• Software: a third-party or in-house software component (the database engine, the message bus).
• Hardware: physical infrastructure (server, network appliance, payment terminal).
• Network component: logical network segment, VPN concentrator, SD-WAN policy.
• Data set: structured/unstructured data store, including AI/ML training data.

Criticality taxonomy

• Critical — disruption would significantly impair the continuing performance of the firm's licensed activities or expose customers to material harm.
• Important — disruption would materially affect operations or a regulated function, but not in a way that immediately threatens continuity.
• Non-critical — supportive or peripheral.

Reuse this in the Register of Information and in the testing scope. If your "critical" assets list and your "critical or important functions" list disagree, you have a finding waiting to happen.

Threat taxonomy

Map to a recognised reference — ENISA Threat Landscape, MITRE ATT&CK, or your sectoral ISAC's taxonomy. Pick one and stick to it; do not let each business unit pick its own.

Three worked examples

The shape of each row is the same. The detail in the threat and control fields is what makes the register useful in a walk-through.

Example 1 — Core lending platform at a neobank

• Asset ID: SYS-CORE-001
• Asset name: Core lending platform (origination + servicing)
• Asset type: ICT system
• Supported function: F-LEND-01 (consumer credit origination), F-LEND-02 (consumer credit servicing)
• Criticality: Critical
• Owner: Head of Lending Technology (role); A. García (current)
• Threat scenario: ransomware encrypts the origination database, halting all new originations and disbursements
• Vulnerabilities: 11% of supporting hosts running an OS version with end-of-vendor-support in Q3 2026; backup restoration not tested at full scale since Q4 2024
• Inherent risk: High (likelihood 3 × impact 5 on a 5×5 scale)
• Controls: EDR on all hosts; offline backups with 14-day retention; segmented network zone; quarterly DR drill scheduled
• Residual risk: Medium (likelihood 2 × impact 4)
• Treatment: Treat — accelerate OS uplift; full-scale restoration test in Q3 2026; owner Head of Lending Technology; review 30 September 2026

Example 2 — Customer call recordings at a MiFID II investment firm

• Asset ID: INFO-COMS-014
• Asset name: Recorded telephone conversations and electronic communications relating to investment advice and order execution
• Asset type: Information asset
• Supported function: F-INV-04 (investment advice), F-INV-05 (order reception and transmission)
• Criticality: Important (record-keeping obligation under MiFID II Article 16(7))
• Owner: COO (role); B. Schmidt (current)
• Threat scenario: provider outage at the recording platform leads to missed recordings of in-scope calls
• Vulnerabilities: single recording provider; gap-detection runs daily, not real-time
• Inherent risk: High
• Controls: contractual recording-completeness SLA; daily gap-detection report routed to compliance; manual fallback recording procedure
• Residual risk: Medium
• Treatment: Treat — procure secondary provider; move gap-detection to near-real-time; owner COO; review 31 July 2026

This example also lives inside the MiFID II recording requirements workstream — the ICT risk register is where the operational view meets the conduct view.

Example 3 — Payment-rails connectivity at a payment institution

• Asset ID: NET-PAY-002
• Asset name: SEPA Instant connectivity (production)
• Asset type: Network component
• Supported function: F-PAY-01 (SEPA Instant payment initiation and settlement)
• Criticality: Critical
• Owner: Head of Payments Operations (role); C. Lambert (current)
• Threat scenario: connectivity loss to the scheme operator during peak hours
• Vulnerabilities: single physical line; failover not tested under load
• Inherent risk: High
• Controls: redundant logical paths; BCP runbook; monthly tabletop with operations
• Residual risk: Medium-High
• Treatment: Treat — second physical line procured; load failover test scheduled Q3 2026; owner Head of Payments Operations; review 15 September 2026

Ownership and refresh cadence

A register that is owned in name only does not survive a thematic review. We recommend the following ownership model:

• First-line owner (asset owner): accountable for the asset record being current — typically a business or operations role.
• First-line owner (information owner): accountable for the information classification, retention and access — typically the head of the business function that uses the data.
• Second-line owner (ICT risk): aggregates risk, challenges the residual rating, and signs off treatment decisions.
• Independent review (internal audit): tests on a risk-based plan, at least every two years for critical assets.

Refresh cadence:

• Annual full review (Article 8(2)).
• Event-driven review on any major incident, significant test finding, material change to the asset, or change in third-party provider.
• Quarterly delta review for critical assets — a short, focused check on the threat picture and the residual risk.

The register is not the strategy. It is the data source for the framework. Treat it as such — version it, control it, and reconcile it to the Register of Information at least quarterly.

Common supervisory findings

In the first sixteen months of DORA being in application, the same three findings recur across NCA walk-throughs:

• Function identifiers do not match across the ICT risk register, the Register of Information and the business continuity plan. You can see the team realised mid-project that the function list had drifted, and patched only one of the three artefacts.
• The threat picture is generic. "Cyber attack" is not a threat scenario. Specific scenarios with specific vulnerabilities are.
• Treatment decisions have no review date, or the review date is in the past. Acceptance without expiry reads as "we forgot about this".

The same issues show up in DORA third party risk reviews — different artefact, same data-quality problem.

A 10-item quality check

Run this before a supervisory engagement:

1. Every asset has a single accountable role-based owner, with a named incumbent.
2. Function identifiers reconcile to the Register of Information.
3. Criticality classification reconciles to the BCP and the testing scope.
4. Every critical asset has a specific (not generic) threat scenario.
5. Every threat scenario references at least one identified vulnerability.
6. Inherent and residual ratings are produced from the same scale, applied consistently.
7. Every residual rating above the firm's appetite has a treatment decision with an owner and a future review date.
8. Linked incidents and test findings are populated for the last 24 months.
9. The register has a documented annual review, plus event-driven reviews where applicable.
10. There is a clear, board-visible record of where the residual risk sits and where it is being accepted.

If you cannot answer "yes" to all ten today, the register is doing less work than it should.

See Sedric in action

Sedric is the AI compliance platform for regulated marketing and communications. Every flag is mapped to the specific rulebook provision, every override is logged with reasoning, and the audit trail is the format regulators expect on first request. Book a 30-minute demo and we will walk through your specific compliance footprint.

FAQ

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

No. The Register of Information is the third-party arrangements inventory required by Article 28 and the ITS. The ICT risk register is the firm's own assets, functions and risks under Article 8. They reference each other but are separate artefacts.

How often must the ICT risk register be reviewed?

Article 8(2) requires at least annual review, plus event-driven review on material changes or significant incidents.

Does the simplified Article 16 regime apply?

Article 16 applies to microenterprises and to specific small and non-interconnected investment firms. The register is still required; the level of detail is proportionate.

What taxonomy should we use?

The RTS does not mandate a specific taxonomy. Pick one that is internally consistent, reuse it across the framework, and document the definitions.

Who owns the register?

The framework is owned by the management body. The register is typically operationally owned by the second-line ICT risk function, with first-line asset owners providing the data.

Does the register feed incident classification?

Yes. Article 18 and the RTS on classification reference criticality of services — the same criticality that lives in the ICT risk register. The two must reconcile.

Are MiCA-authorised CASPs in scope?

Yes. Crypto-asset service providers authorised under MiCA are in the scope of DORA (Article 2). The register applies to them on the same terms. For their wider authorisation map, see our MiCA authorisation checklist.

Where to go next

If you have not yet pressure-tested your wider DORA programme, start with our DORA implementation checklist. For the third-party side, see DORA third party risk. MiCA CASPs reading this should pair it with the MiCA authorisation checklist, and trading-side teams should look at market abuse regulation surveillance for adjacent control mapping.

See Sedric in action

Sedric is the AI compliance platform for regulated marketing and communications. Every flag is mapped to the specific rulebook provision, every override is logged with reasoning, and the audit trail is the format regulators expect on first request. Book a 30-minute demo and we will walk through your specific compliance footprint.