DORA ICT Risk Appetite: Board Approval Guide for 2026

It is 08:15 on a Tuesday, and the CISO of a mid-sized payment technology company is standing outside the boardroom with three documents open on a tablet.

The first is the ICT risk register. It has 137 rows, colour-coded ratings and several high risks linked to cloud concentration, privileged access, ransomware recovery, customer data exposure and supplier incident response. The second is the DORA readiness tracker. It says the firm has policies, incident procedures, third-party registers and resilience testing plans. The third is the board pack for a regulatory meeting.

The chair has one question, and it is not a technical one:

“What level of ICT risk have we actually agreed to accept?”

The room goes quiet because the company has risk assessments, but not a board-approved ICT risk appetite. It has impact ratings, but not measurable tolerance thresholds. It has escalation meetings, but no formal trigger that says when a cyber risk becomes a management body decision. It has accepted residual risks, but some are justified as “business decisions” without a clear link to risk criteria, GDPR Article 32 proportionality, DORA tolerance expectations or NIS2 management accountability.

That gap is increasingly visible in 2026. DORA applies from 17 January 2025 and requires financial entities to maintain a governance and control framework for ICT risk, including management body responsibility for the ICT risk management framework, digital operational resilience strategy and ICT risk tolerance. NIS2 pushes management bodies to approve cybersecurity risk-management measures and oversee their implementation. GDPR Article 32 requires appropriate technical and organisational security measures based on risk. ISO/IEC 27001:2022 provides the management system mechanics: context, interested parties, risk criteria, treatment plans, documented information and management review.

The missing bridge is an ICT risk appetite and tolerance statement that a board can understand, approve, challenge and use.

This guide explains how to build that bridge using Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap, Clarysec’s Risk Management Policy, Clarysec’s Risk Management Policy-sme and Zenith Controls: The Cross-Compliance Guide.

Why risk registers are not risk appetite

Many organisations mistake a risk register for risk governance. A risk register tells you what risks exist, how they are rated, who owns them and what treatment is planned. It does not automatically answer the board-level questions that DORA, NIS2, GDPR and ISO/IEC 27001:2022 expect leaders to address.

A mature ICT risk appetite statement answers questions like:

• Which ICT risks are unacceptable regardless of cost?
• What operational downtime can the business tolerate for a critical or important function?
• What level of data loss or data integrity compromise is outside appetite?
• What third-party concentration risk requires board attention?
• Who may accept residual ICT risk, and at what level?
• When must a risk be escalated to senior management or the management body?
• How are legal, regulatory and contractual requirements built into risk criteria?

Under DORA, this is not optional governance polish. Article 5 requires the management body to define, approve, oversee and be responsible for the ICT risk management framework, including digital operational resilience strategy and ICT risk tolerance. Article 6 requires a documented ICT risk management framework, annual review for non-microenterprises, internal audit, remediation of critical audit findings and a digital operational resilience strategy with ICT objectives, risk tolerance, impact tolerance, architecture, testing and incident communication strategy.

NIS2 adds a parallel accountability model. Article 20 requires management bodies of essential and important entities to approve cybersecurity risk-management measures, oversee implementation and receive training. Article 21 requires appropriate and proportionate technical, operational and organisational measures based on an all-hazards approach, including risk analysis, incident handling, business continuity, supply-chain security, secure development, control effectiveness, training, cryptography, HR security, access control, asset management and MFA where appropriate.

For financial entities, DORA is treated as a sector-specific Union legal act where overlapping NIS2 obligations apply. In practice, DORA generally displaces overlapping NIS2 risk-management and incident-reporting requirements for financial entities within its scope, while NIS2 remains important for coordination and for providers outside DORA’s direct financial-entity obligations. For SaaS, cloud, managed service and managed security providers, NIS2 can apply directly where scope conditions are met.

This is why board-approved ICT risk appetite is no longer a financial risk artefact. It is a cybersecurity governance control.

Use ISO/IEC 27001:2022 as the operating system

DORA and NIS2 tell leaders what must be governed. ISO/IEC 27001:2022 gives organisations a practical operating system for how to govern it.

ISO/IEC 27001:2022 Clauses 4.1 to 4.4 require the organisation to define context, interested parties, requirements, ISMS scope and ISMS processes. This matters because DORA, NIS2, GDPR, contracts, supervisory expectations, customers, cloud providers and outsourcing arrangements all become requirements that influence risk criteria.

Clauses 5.1 to 5.3 require leadership commitment, policy alignment, resources, responsibilities and reporting of ISMS performance to top management. Clauses 6.1.1 to 6.1.3 require risk-based planning, a documented risk assessment process, risk acceptance criteria, consistent assessment criteria, risk owners, comparison against risk criteria, treatment planning, a Statement of Applicability and approval of residual risk.

This is the foundation for DORA ICT risk tolerance.

In the Risk Management phase, Step 10 of the Zenith Blueprint tells organisations to define risk criteria before rating risks:

“Risk criteria are the rules and benchmarks your organization uses to evaluate the significance of each risk. Establishing these criteria upfront ensures everyone speaks the same risk language.”

The same step warns that regulatory impact must be built into risk definitions:

“Any risk that could lead to non-compliance with applicable laws (GDPR, etc.) is not acceptable and must be mitigated.”

The Zenith Blueprint also gives practical guidance for impact scaling:

“When defining impact, it’s wise to relate levels to your specific business scale. For example, ‘Major financial impact = loss > $100k’ (adjust to your context). Also consider regulatory impact: for example, a data breach of personal data might automatically be ‘Major’ or ‘Severe’ due to GDPR fines and notification requirements, even if the direct financial loss is unclear. Similarly, if you’re in scope for NIS2 (essential services), an incident causing service disruption might be at least ‘Major’ due to legal implications. Include such considerations in your definitions.”

That guidance prevents a common failure: rating a cyber risk as moderate because the immediate financial loss appears small while ignoring legal, operational resilience, data subject or customer impact.

A board-ready model should separate four layers:

This structure makes risk appetite auditable because every statement can be traced to risk criteria, controls, evidence and decisions.

A board-ready DORA ICT risk appetite statement

A strong ICT risk appetite statement is short enough for the board to approve, specific enough for management to apply and measurable enough for auditors to test. It should avoid jargon, but it cannot be vague.

A practical high-level statement might read:

“Our firm has low appetite for ICT risks that could result in material harm to clients, disruption to critical or important functions, unauthorised disclosure or alteration of regulated data, failure to meet legal obligations or loss of resilience in critical ICT third-party services.”

That statement then needs measurable tolerance thresholds and escalation triggers.

This table changes the conversation. The board is no longer approving a slogan. It is approving operating boundaries for availability, confidentiality, integrity, suppliers, vulnerabilities, recovery and compliance.

Clarysec’s Risk Management Policy supports this governance model. The enterprise policy states:

“Approves the risk management framework and defines acceptable risk appetite and tolerance thresholds.”

Clause 6.2.1 makes the measurement requirement explicit:

“Risks shall be assessed for likelihood and impact using a standard risk matrix with clearly defined scoring scales.”

Clause 6.3.4 creates the acceptance rule auditors will expect:

“Risks accepted without treatment shall be justified in writing, linked to the organization’s risk appetite, and approved at the appropriate level.”

For SMEs, the Risk Management Policy-sme keeps the same governance principle in a lighter format:

“Ensure management involvement in approving risk tolerance and major risk treatment plans.”

It also requires escalation of high risks:

“High risks must be escalated to the General Manager for decision.”

This is proportionality in action. DORA Article 4 requires requirements to be applied in a manner proportionate to size, risk profile, and the nature, scale and complexity of services. ISO/IEC 27001:2022 enables the same principle through scope, context, risk criteria and treatment decisions. The governance standard is not that every organisation needs the same committee structure. The governance standard is that risk appetite, tolerance, escalation and acceptance are defined, approved, evidenced and used.

GDPR Article 32 changes the risk conversation

GDPR Article 32 is often treated as a technical security clause. In governance terms, it is also a risk appetite clause.

Article 32 requires controllers and processors to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. That risk-based approach considers the state of the art, costs of implementation, nature, scope, context and purposes of processing, and risks to the rights and freedoms of natural persons.

This affects ICT risk appetite in three ways.

First, personal data impact cannot be reduced to financial loss. A small database exposure may have limited direct cost but serious confidentiality, identity, fraud, discrimination or rights-impact consequences. If special categories of personal data are involved, such as health, biometric or genetic data, the appetite should be materially lower.

Second, processing roles must connect to risk ownership. GDPR distinguishes controllers and processors. DORA distinguishes financial entities and ICT third-party service providers. NIS2 distinguishes essential and important entities. ISO/IEC 27001:2022 requires risk owners. A mature appetite statement should identify who owns risk decisions involving personal data, outsourced processing, critical services and cross-border dependencies.

Third, Article 32 proportionality should be visible in control selection. Encryption, pseudonymisation, access control, backup, logging, monitoring, incident response and resilience are not isolated technical tasks. They are treatment measures selected because a risk exceeded appetite or tolerance.

Clarysec’s Risk Management Policy explicitly connects this:

“Article 32: Mandates a risk-based approach to security measures, fulfilled through impact-based risk evaluations and control selection.”

That is the operational link auditors look for: Article 32 requirement, risk assessment, risk rating, treatment plan, control selection, residual risk and approval.

How Zenith Controls supports cross-compliance evidence

A board-approved appetite statement becomes powerful when it is mapped to controls. Zenith Controls acts as Clarysec’s cross-compliance guide, helping teams reuse evidence across ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF and COBIT-style assurance.

Three ISO/IEC 27002:2022 control areas are especially important:

This is not a paper mapping exercise. It changes how decisions are made.

If a business owner asks to accept delayed MFA rollout for administrators, Zenith Controls helps the CISO show why this is not just an access control question. It touches policy governance, management responsibility, legal and regulatory requirements, GDPR security of processing, DORA ICT risk management, NIS2 cybersecurity measures, incident impact and audit evidence.

If a product team wants to launch in a new EU market using a new cloud service, ISO/IEC 27002:2022 control 5.31 pushes the legal and regulatory requirement review into ISMS scope. ISO/IEC 27001:2022 Clause 4.2 requires interested-party requirements to be identified, including legal, regulatory and contractual obligations. Clause 8.1 requires operational planning and control, including control of externally provided processes, products or services relevant to the ISMS.

The goal is one risk language, not separate compliance dialects.

Approval workflow: who decides what

A CISO can propose ICT risk appetite, but the board or management body must own it. That ownership needs a workflow.

This also aligns with NIST CSF 2.0. The GOVERN function, especially GV.RM, expects agreed risk management objectives, risk appetite and tolerance statements, risk activities integrated into enterprise risk management, defined risk response options, communication lines and standardised methods for calculating, documenting, categorising and prioritising cybersecurity risks. GV.RR expects leadership accountability, roles, authorities and resources aligned to risk strategy. GV.PO expects policies to be established, communicated, enforced, reviewed and updated.

COBIT 19 and ISACA-style assurance professionals will ask whether risk appetite is integrated into enterprise governance of information and technology, not merely attached as an appendix to a cyber policy.

Build an ICT risk appetite pack in one working session

A practical ICT risk appetite workshop can move an organisation from scattered registers to an auditable board pack.

Step 1: collect the right inputs

Prepare the current ICT risk register, business impact analysis, recovery objectives, list of critical or important functions, ICT asset inventory, ICT service inventory, supplier and cloud dependency register, incident classification criteria, GDPR processing inventory, DPIAs where relevant, legal obligations register, policies, Statement of Applicability and existing enterprise risk appetite statement.

This aligns with ISO/IEC 27001:2022 Clauses 4, 6 and 8, and with NIST CSF profile methods that start with business priorities, risk priorities, requirements, safeguards and roles.

Step 2: define impact scales that include regulation

Using Zenith Blueprint Step 10, define likelihood and impact in business language. Include financial loss, operational disruption, customer impact, reputational damage, legal and regulatory impact, data subject harm and critical function impact.

For example, “Major” impact might include a prolonged outage of a critical service, confirmed personal data breach requiring notification, failure to meet a DORA incident reporting obligation or supplier failure affecting a critical or important function.

Step 3: write appetite by domain

Do not create one generic cyber appetite. Define domains such as critical service availability, personal data confidentiality, data integrity, privileged access, third-party ICT dependency, cloud concentration, vulnerability exposure, incident reporting readiness, backup and recovery, and secure development change risk.

For each domain, write one appetite statement, one or more tolerance thresholds and escalation triggers.

Step 4: connect treatment to the Statement of Applicability

Step 13 of Zenith Blueprint instructs organisations to choose risk treatment options: mitigate, avoid, transfer or accept. It also emphasises management approval:

“Risk treatment decisions and the SoA should be reviewed and approved by top management.”

For DORA and NIS2, this is evidence that the management body or delegated leadership reviewed key risks, treatments and accepted residual exposure. For GDPR, it supports accountability by showing why selected measures were appropriate to the risk.

Step 5: record acceptance with expiry and conditions

Every accepted medium or high residual risk should include:

• Risk ID and owner
• Business rationale
• Appetite statement reference
• Tolerance threshold affected
• Legal and regulatory analysis
• Compensating controls
• Expiry or review date
• Approver
• Evidence location
• Trigger for reopening the decision

The Risk Management Policy-sme states:

“Any decision to accept or defer treatment of a high or medium risk must be documented in the Risk Register. This documentation must include:”

In enterprise environments, this becomes an approval workflow and risk committee pack. In smaller organisations, it may be a structured risk register tab with management sign-off. The point is not bureaucracy. The point is defensibility.

Incident tolerance: where appetite meets the clock

Risk appetite becomes real during incidents.

DORA Article 17 requires financial entities to establish an ICT-related incident management process to detect, manage and notify incidents, record all incidents and significant cyber threats, identify root causes, use early warning indicators, classify incidents by priority, severity and service criticality, assign roles, communicate to stakeholders, escalate at least major ICT-related incidents to senior management and the management body, and restore secure operations in a timely manner.

DORA Article 18 classifies incidents using factors such as affected clients, duration, downtime, geographic spread, data losses affecting availability, authenticity, integrity or confidentiality, criticality of affected services and economic impact. Article 19 requires major ICT-related incidents to be reported to the competent authority, with clients informed where their financial interests are affected.

NIS2 Article 23 has staged reporting for significant incidents, including early warning without undue delay and where applicable within 24 hours, incident notification without undue delay and where applicable within 72 hours, intermediate updates where requested and a final report no later than one month after the incident notification. Significant incidents include those causing severe operational disruption, financial loss or material or non-material damage to others.

The appetite statement should define escalation thresholds before the incident happens.

Annex A controls around incident planning, information security event assessment, incident response, learning from incidents, evidence collection, maintaining information security during disruption and ICT readiness for business continuity all support these thresholds. NIST CSF outcomes across IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER support the same operating model, including backups, monitoring, incident declaration, escalation, root-cause analysis, stakeholder communication and recovery verification.

Supplier and cloud tolerance boards often miss

DORA makes ICT third-party risk a core compliance obligation. Article 28 requires financial entities to manage ICT third-party risk as part of the ICT risk management framework while remaining fully responsible for compliance. It requires ICT third-party risk strategy, registers of ICT service contractual arrangements, distinction of services supporting critical or important functions, annual reporting, planned arrangement notification, pre-contract assessments, due diligence, audit and inspection rights, termination rights and documented exit strategies.

Article 29 adds concentration risk analysis, including non-substitutability, multiple dependencies on the same or connected providers, subcontracting risks, third-country subcontractors, data protection compliance, enforceability and complex subcontracting chains. Article 30 requires written contractual rights and obligations, service descriptions, locations, security protections, data access and return, service levels, incident assistance, cooperation with authorities, termination rights, tested contingency plans, monitoring and exit arrangements.

A board-approved supplier tolerance statement might say:

“We have low appetite for critical or important functions being dependent on an ICT third-party provider where we lack contractual audit rights, tested exit arrangements, incident notification duties, service level targets, data return rights or visibility into material subcontracting.”

That sentence gives procurement a practical rule. If the contract does not meet the threshold, the risk cannot be quietly accepted by the project team.

How auditors will test your ICT risk appetite

A strong appetite statement is designed with audit in mind.

Step 28 of Zenith Blueprint, in the Audit, Review and Improvement phase, reinforces the management review layer. It instructs organisations to gather inputs such as changes in external and internal issues, ISMS performance, audit results, monitoring and measurement, incidents, nonconformities, opportunities for improvement and resource needs. It also says management review must lead to decisions and actions, not merely presentations.

At least annually, and whenever there are material changes, management should review whether tolerance thresholds still align with the business model, incidents exceeded appetite, accepted risks remain within approved boundaries, new DORA, NIS2, GDPR or contractual requirements changed the baseline, suppliers remain within concentration tolerances and KRIs are causing timely escalation.

If the answer is no, the appetite statement must change, or the controls must.

Common failure patterns in 2026 readiness work

Across DORA, NIS2, GDPR and ISO/IEC 27001:2022 projects, the same weaknesses appear repeatedly:

• Appetite without thresholds, where the board approves a statement but nobody can tell when it has been breached.
• Thresholds without authority, where severity levels exist but risk owners can accept exceptions without senior approval.
• Legal risk outside the scoring model, where GDPR, DORA, NIS2 and contracts are listed separately but not embedded into impact criteria.
• Supplier tolerance missing from the board pack, even though critical ICT dependencies are known by procurement or IT.
• Management review as theatre, where slides are presented but decisions, actions, resource needs and risk acceptances are not documented.
• Audit evidence fragmentation, where policies, registers, KRIs, incident reports, supplier reviews and board minutes exist in different places with no cross-reference.

Clarysec’s approach is designed to remove these gaps. The Zenith Blueprint provides the phased implementation path. The Risk Management Policy and Risk Management Policy-sme provide governance clauses scaled to enterprise and SME environments. Zenith Controls maps the control spine across information security policy, management responsibility and legal or regulatory requirements, making evidence reusable across ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF and COBIT-style assurance.

Turn board intent into auditable ICT risk governance

If your organisation has a risk register but cannot show a board-approved ICT risk appetite, measurable tolerance thresholds, escalation triggers and formal acceptance rules, the gap is not cosmetic. It affects DORA governance, NIS2 management accountability, GDPR Article 32 defensibility and ISO/IEC 27001:2022 audit readiness.

A practical next step is to run a focused ICT Risk Appetite Workshop using Clarysec’s toolkit:

1. Use Zenith Blueprint Step 10 to define risk criteria and impact scales.
2. Use Zenith Blueprint Step 13 to link treatment options, residual risk and Statement of Applicability approval.
3. Use Zenith Blueprint Step 14 to cross-reference GDPR, NIS2 and DORA obligations.
4. Use Zenith Blueprint Step 28 to bring appetite, KRIs, accepted risks and resource decisions into management review.
5. Apply Risk Management Policy or Risk Management Policy-sme to formalise approval and acceptance rules.
6. Use Zenith Controls to map governance controls to audit evidence and cross-compliance expectations.

Clarysec can help you convert scattered risk artefacts into a board-approved, regulator-ready ICT risk appetite model that your teams can use when the next cloud outage, supplier failure, vulnerability disclosure or personal data incident tests the organisation’s real tolerance.