What DORA Says About Management Body Accountability
Article 5 of DORA is explicit. The management body of a financial entity bears ultimate responsibility for managing ICT risk. This is not a provision that allows the board to sign off on a framework and step back. Article 5(2) sets out the specific obligations:
- The management body must define, approve, and oversee the implementation of the ICT risk management framework
- It must set and approve the ICT risk tolerance level — that is, the board must have an expressed position on how much ICT risk is acceptable
- It must approve ICT business continuity policy and the ICT response and recovery plans
- It must ensure adequate budget is allocated for ICT security — and this must be a deliberate board decision, not a finance function determination
- It must approve policies relating to ICT third-party risk
Article 5(4) adds a requirement that members of the management body "keep up to date with sufficient knowledge and skills to understand and assess ICT risk and its impact on the operations of the financial entity." This is not a training box-tick. It is a continuing obligation that regulators can examine.
What Cannot Be Delegated
Financial entities routinely delegate operational security decisions to the CISO or a security committee. DORA does not prevent this. What it prevents is the management body treating those delegations as a discharge of its own accountability. The board remains responsible for the framework within which those delegations operate, and for assuring itself that the framework is working. Article 5(2) uses the phrase "bear ultimate responsibility" — this is the standard against which regulators will assess board conduct when things go wrong.
What "Keeping Pace with ICT Risk" Means for Identity
The Article 5(4) obligation to maintain sufficient knowledge and skills to understand ICT risk is deliberately broad. The EBA, ESMA, and EIOPA have not published a competency framework that specifies what a director must know. What the regulators have said, through guidance and supervisory expectations, is that directors should be able to engage substantively with ICT risk matters — not simply receive reports and approve them.
For Identity Specifically
A director who can demonstrate adequate oversight of identity risk would be expected to understand:
- Why identity is the primary attack vector in financial sector incidents — the mechanism by which credential compromise, phishing, and insider threats translate to system access
- The difference between authentication (verifying who someone is) and authorisation (controlling what they can do) — and why both matter independently
- What MFA is, why it materially reduces credential-based attack success rates, and what the firm's current MFA coverage is for privileged accounts
- What privileged access means — administrative accounts, service accounts, and third-party access — and why these carry disproportionate risk
- How identity failures have manifested in publicised financial sector incidents and what the regulatory consequences were
None of this requires a director to configure an identity platform. It requires them to hold informed conversations with the CISO, to challenge assurance statements rather than accept them at face value, and to be able to identify when they are receiving reassurance rather than evidence.
The Questions That Demonstrate Adequate Oversight
Regulatory examiners often assess board competence through the quality of questions asked in board minutes. A board that receives a security update and records no questions or challenge demonstrates a different level of engagement than one that records specific questions about coverage gaps, exception processes, and testing results. The minutes are evidence.
The Liability Exposure
DORA creates a direct line between regulatory enforcement and individual accountability for management body members. Article 50 empowers competent authorities to impose administrative sanctions and remedial measures on financial entities for DORA violations. Article 53 allows competent authorities to publish information on the nature of the infringement, including the identity of the natural persons responsible where national law permits.
How Identity Incidents Translate to Enforcement
An identity-related incident — a privileged account compromise, a credential-based attack that disrupts operations, a third-party access failure that causes a reportable incident — triggers the DORA incident reporting obligations under Articles 19 and 20. Major ICT-related incidents must be reported to the competent authority within defined timeframes.
When regulators examine the incident, they will look at whether the management body had adequate oversight of the controls that failed. If the board had no visibility of MFA coverage, no recorded discussion of privileged access risks, and no articulated risk appetite that covered identity risk, that evidential gap becomes part of the regulatory assessment of whether Article 5 obligations were met.
Individual Director Accountability
Competent authorities in member states have different powers under national law to pursue individual directors rather than just the entity. In the UK, the FCA's Senior Managers and Certification Regime (SMCR) sits alongside DORA obligations for FCA-regulated firms — a Senior Manager with responsibility for technology and cyber risk has a Duty of Responsibility that can result in personal enforcement action if they did not take reasonable steps in their role. The combination of DORA Article 5 and SMCR creates a materially higher accountability standard than existed before.
The practical implication: a director who cannot demonstrate that they were asking the right questions, receiving the right information, and acting on assurance failures does not have a strong defence when an incident is examined retrospectively.
Five Questions a DORA-Compliant Board Should Be Asking
These are not generic governance questions. They are the specific questions that demonstrate substantive engagement with identity risk under DORA's requirements.
1. What is our current MFA coverage percentage across privileged accounts, and what is our exception register?
Coverage percentages matter. "MFA is deployed" is not an adequate answer — it does not tell the board whether 60% or 99% of privileged accounts are protected. An exception register documents accounts where MFA is not enforced and why, with a named owner and a remediation timeline. A board that has approved a risk appetite for identity should be receiving this data quarterly at minimum, and should be asking what is driving the exception count up or down.
2. When was our ICT risk assessment last updated, and who owns it?
Article 6(5) of DORA requires the ICT risk management framework to be reviewed at least annually and following major ICT incidents. A board that does not know when the last risk assessment was completed, or who is accountable for it, cannot meet its Article 5 oversight obligation. The answer should include the date, the scope, the methodology, and any material changes from the previous assessment.
3. Do we have a written TLPT plan for our significant ICT systems, and when did we last conduct threat-led penetration testing?
DORA Article 26 requires significant financial entities — those meeting the criteria set by the ESAs — to carry out Threat-Led Penetration Testing (TLPT) at least every three years. TLPT specifically tests identity controls: how an attacker with a compromised credential would move through the environment, whether privileged access paths are exploitable, and whether detection controls identify the activity. A board question on TLPT status is a question about whether the most realistic form of identity control testing has been conducted.
4. What is our tested Recovery Time Objective for identity systems in a worst-case scenario?
Identity infrastructure — the directory service, authentication platform, and privileged access management system — is foundational. If it fails, most other systems become inaccessible. DORA Article 12 requires business continuity capabilities including recovery time and recovery point objectives for ICT systems. A board should know the tested RTO for identity systems and whether that RTO has been validated through an actual test, not just documented in a policy. "Tested" is the operative word — a documented RTO that has never been exercised against a realistic scenario is not an assurance of recovery capability.
5. How do we evidence our compliance position to the regulator if asked today?
This question tests whether compliance is a documented state or an assumed one. Competent authorities can request information on DORA compliance at any time. For identity controls, the evidence package should include: the access control policy, MFA enforcement configuration and coverage data, privileged access review records, the leaver process and recent execution logs, and the output of the most recent ICT risk assessment. A board that is confident in compliance should be able to describe what that evidence package contains.
The Board's Role in Identity Risk Appetite
Article 5(2) requires the management body to set the ICT risk tolerance level. Risk appetite for identity is not something that should be defined solely by the CISO and ratified without substantive board input. The board's role is to make an informed decision about what level of identity risk the organisation is willing to carry — and that decision has consequences that directors need to understand.
What Risk Appetite Statements for Identity Look Like in Practice
A risk appetite statement for identity that meets the DORA standard is specific and measurable. It does not say "we accept low risk of identity-related incidents." It says something closer to:
- "MFA coverage for all privileged accounts must not fall below 98%. Any account below this threshold must be registered as an exception with board-level approval and a remediation date within 30 days."
- "We accept no standing privileged access for external third parties. All third-party privileged access is time-limited and session-recorded."
- "The RTO for identity infrastructure recovery must not exceed 4 hours and must be tested annually."
Statements at this level of specificity allow the board to assess whether risk is within appetite, to receive meaningful exception reports, and to take action when thresholds are breached. Vague risk appetite statements that cannot be measured do not serve this function and do not demonstrate the oversight Article 5 requires.
When Risk Appetite Needs Board Review
The risk appetite for identity should be reviewed when the threat environment changes materially, when a significant identity-related incident occurs in the sector, when the organisation undergoes a major technology change (cloud migration, new application platform, acquisition), or on the annual cycle required by Article 6(5). The board should not be receiving the same risk appetite statement year after year without discussion of whether it remains appropriate.
Preparing the Board Briefing Pack
The information the CISO presents to the board on identity risk matters as much as the underlying security posture. A board cannot exercise oversight it is not equipped to exercise. The briefing pack should provide the right data in a format that allows the board to ask substantive questions.
What Should Be in the Pack
- Current state against risk appetite. For each identity risk appetite metric, the current position. Green/amber/red status with the underlying data, not just the RAG rating.
- Trend data. How the metrics have moved over the last quarter. A single data point tells the board where you are. Trend data tells the board whether the programme is improving or deteriorating.
- Exception register. Every identity control exception currently open: what it is, why it exists, who owns it, and the remediation timeline. This is the board's visibility of known risk above appetite.
- Incident data. Identity-related security events in the period — authentication failures, account compromise investigations, privilege escalation detections. Not every alert, but the events that required investigation.
- Third-party and supply chain identity risk. Summary of privileged third-party access — how many third parties have privileged access, the access governance arrangements, and any access reviews completed in the period.
- Forward look. Planned changes in the next quarter that affect identity risk — technology migrations, new application deployments, workforce changes.
Format and Frequency
The board should receive an identity risk update at every scheduled board meeting at which ICT risk is on the agenda — which under DORA should be at least quarterly. The format should be consistent from meeting to meeting so that the board can track trends. A four-page summary with an appendix containing supporting data is workable for most boards. The test is whether a director reading it can determine whether identity risk is within appetite and whether the programme is moving in the right direction.
One specific recommendation: the board pack should record the questions asked and the responses given. Those records are evidence of oversight. Minutes that say only "the board received and noted the security update" do not demonstrate the engagement that Article 5 requires.
DORA-Specific Executive Briefings
We run DORA-specific executive briefings and tabletop exercises for boards and senior management teams. The sessions cover the Article 5 obligations, what adequate oversight looks like in practice, and the identity risk questions your board should be asking and recording.
For firms preparing for supervisory examination or responding to regulatory enquiries about ICT risk management, we also provide the evidential framework that demonstrates board-level engagement with identity risk — the records, the metrics, and the documented oversight that regulators expect to find.
Book an Executive Identity Briefing