Five Questions Every Board Should Ask About Identity Security

Why Boards Are Now Accountable for Identity

Identity security has been a technical domain for most of its existence. That has changed. The regulatory frameworks introduced across the UK and EU in the last few years — DORA, NIS2, and strengthened FCA and PRA requirements — have made identity governance a matter of board-level accountability, not just IT policy.

Specifically:

• DORA (Article 5): Management bodies must "define, approve, oversee and be responsible for" the ICT risk framework — which includes access controls and identity governance. This is a positive accountability standard, not a passive one.
• NIS2: Senior management is personally liable for security failures, including inadequate access controls, where those failures result from a failure of oversight.
• FCA and PRA: Operational resilience requirements demand that boards understand and attest to critical system access controls as part of their self-assessment.
• Cyber insurers: Increasingly require board attestation of security posture, and use that attestation as the basis for claim assessment.

The gap in most organisations is not that boards are ignoring this — it is that the security updates they receive do not give them the information they need to fulfil these obligations. Traffic-light RAG statuses without explanation, technical reports without business translation, and "everything is under control" assertions without evidence do not constitute effective board oversight.

The questions below are designed to change that. They are not technical questions. They are governance questions — and if your CISO cannot answer them clearly and with evidence, that itself is an answer.

Question 1: What percentage of privileged accounts are protected by MFA — and what are the exceptions?

This is the most foundational identity security question, and it routinely receives inadequate answers at board level.

"We have MFA deployed" is not an answer to this question. Attackers do not target organisations with MFA — they target the accounts excluded from MFA. The question is specifically about exceptions: which accounts with elevated privilege bypass MFA, why, and who owns that risk.

If your organisation cannot produce MFA coverage statistics by account type, that is itself a governance gap — because it means your security team cannot evidence the controls you are attesting to.

Question 2: When was privileged access last reviewed — and who reviewed it?

Access review is one of the most consistently poorly-performed identity controls in organisations of all sizes. The conceptual answer is always "yes, we do access reviews." The evidence is frequently absent or partial.

The board question is specific: not "do you have an access review process" but "when did the last review happen, who conducted it, and what did it find?" These three questions together distinguish a functioning process from a policy document.

The phrase "evidence is available" matters. In a regulatory examination, an insurer investigation, or a post-incident review, the board will be asked whether they had reasonable assurance that controls were functioning. Assurance requires evidence — not a policy stating the review should happen.

Question 3: Who has access to our most critical systems right now?

This question is about visibility. Boards make investment decisions, approve risk appetite, and sign off on regulatory attestations based on their understanding of what their critical systems are and who can access them. Without accurate identity intelligence, all of those decisions are made on incomplete information.

The question is not asking for an account list. It is asking whether your organisation has the visibility to answer it accurately. Can your security team produce, in the next 24 hours, a list of every account with privileged access to your most critical systems — with ownership, last authentication, and MFA status?

The inability to answer this question in hours — not weeks — is a significant operational risk signal. In a live incident, decisions about who to revoke, what to isolate, and what to tell regulators all depend on this information being available.

Question 4: How long would it take to revoke all access if a breach were confirmed?

This question probes incident response readiness. The DORA, NIS2, and FCA operational resilience frameworks all require organisations to have tested, validated recovery capabilities — not theoretical plans.

For identity, the key measure is revocation speed: how quickly can your organisation disable accounts and revoke sessions across all connected systems if a breach is confirmed? In a ransomware incident propagating through privileged accounts, the difference between a one-hour and a 12-hour answer can be the difference between a contained incident and a catastrophic one.

Note the requirement for testing. A plan that has never been tested is not a recovery capability. Boards under operational resilience obligations should specifically ask when the revocation process was last tested and what the result was.

Question 5: What is the blast radius if our most privileged account is compromised?

This question is about the board understanding the actual risk exposure the organisation carries. Most board-level security reporting focuses on what defences are in place. This question asks: if those defences fail, how bad is it?

Blast radius is the combination of privilege scope and lateral movement potential. An account with Global Admin in Entra ID, unconstrained domain admin in Active Directory, and access to a connected financial system has an enormous blast radius. An account with those same permissions but scoped controls and just-in-time activation has a much smaller one.

This question often surfaces discussions about privileged access management investment that had previously stalled. Understanding the concrete consequence of privilege concentration — not just as a technical concern but as a business risk — changes the investment conversation.

What to Do With the Answers

These questions are not intended to put your CISO on the spot. They are intended to establish whether the board has the information it needs to fulfil its oversight obligations — and to surface gaps that need to be addressed before a regulatory examination or an incident does it for you.

Three productive outcomes from asking these questions:

1. Clear answers with evidence: Your security function is operating with appropriate visibility and governance. The board can fulfil its oversight obligations with confidence.
2. Confident answers without evidence: Controls exist at policy level but evidential capability needs to be built. This is an investment priority discussion.
3. Uncertain answers: Identity governance has been treated as operational rather than strategic. A baseline assessment is the right next step before the board can make informed risk decisions.

In any of the three cases, the board is better positioned for having asked. Under DORA, NIS2, and UK director accountability frameworks, the standard expected is not that you had no security problems. It is that you exercised appropriate oversight and made reasonable, informed decisions about risk.