Account for the ways of supervising cyber-resilience, the approaches to testing and responding to incidents, and the metrics for cybersecurity and resilience.
The idea
Supervisors assess cyber-resilience through off-site reviews, on-site inspections, thematic reviews, self-assessments and sometimes supervisor-led testing. Institutions test with a ladder of methods. Vulnerability scans find known weaknesses, and penetration tests try to exploit them. Tabletop exercises rehearse decisions and communication without touching systems. Threat-led red teaming imitates real adversaries, using threat intelligence against critical functions, often without telling the defenders so that detection and response are genuinely observed. Incident response needs tested plans, escalation paths, recovery objectives, reporting to authorities and lessons fed back into the framework. Metrics fall into groups. Protection metrics include patch compliance and phishing-test results. Detection and response metrics measure the time to detect, contain and recover. Incident counts form a third group. No standard set exists. Beware averages distorted by outliers and compliance rates with the wrong denominator. Choose the test or metric that fits the stated objective.
Formulas
Patch compliance rate
compliance = patched ÷ (in scope − exempt)
- patched
- systems patched within the deadline
- in scope
- all systems covered by the metric
- exempt
- systems with formally approved exemptions
The denominator must follow the stated definition. Leaving exempt systems in the denominator understates compliance.
A practice question
Which type of test uses current threat intelligence to imitate a real adversary's methods against an institution's critical functions?
- An automated vulnerability scanWhy not: A scan lists known weaknesses; it does not imitate an adversary's campaign against critical functions.
- A tabletop exerciseWhy not: A discussion-based walk-through of an incident, with no live attack on systems.
- Threat-led penetration testing (red teaming) - correct
- A business continuity plan reviewWhy not: A paper review of recovery arrangements, not a simulated attack.
Threat-led penetration testing or red teaming draws on intelligence about realistic attackers and attacks critical functions as they would. Scans, tabletops and plan reviews are different tools.
A harder one
In a threat-led penetration test, only a small control team knows the test is under way and the security operations staff are not told. What is the main reason?
- To avoid having to report any of the findings to the supervisorWhy not: Findings are normally shared and remediated; secrecy during the test is about realism, not avoiding reporting.
- To observe genuine detection and response behaviour - correct
- To keep staff from patching systems before the testers use known exploitsWhy not: The aim is to see real detection and response; a patching rush is not the principal reason.
- Because the test is carried out against a copy of the system, so staff have no roleWhy not: Tests are typically run against live critical systems with safeguards, and the role of staff is exactly what is being observed.
Keeping defenders uninformed shows whether the bank would detect and respond to a real intrusion. The control team can stop the test if it threatens live services.
The hardest tier
Detection times for five incidents were 2, 3, 4, 5 and 46 hours. Which figure or approach is most appropriate for reporting detection speed to the board?
- Report only the 12-hour mean, because averages are the sole acceptable summaryWhy not: Uses the arithmetic mean alone, which one outlier distorts, and hides the typical performance and the tail.
- Report 3.5 hours after dropping the 46-hour incident as an anomalyWhy not: Excludes the worst case, which is exactly the one that matters most for resilience.
- Report only the 46-hour maximum, since the worst case alone captures the riskWhy not: Ignores the typical experience; a single maximum gives no sense of overall detection performance.
- Report the median of 4 hours alongside the 12-hour mean and investigate the 46-hour incident - correct
Mean = (2+3+4+5+46)/5 = 12 hours; median = 4 hours; excluding the outlier gives 3.5. Skewed data call for the median plus a look at the tail and the outlier's cause.
In the app: 6 practice questions on this outcome, spaced review that brings it back before you forget it.
Start free →More in Cyber-resilience: Range of practices
- State what cyber-resilience means and set recent regulatory initiatives on it side by side.
- Characterise present-day banking and supervisory approaches to overseeing a cyber-risk management framework, including the division of duties.
- Account for and judge how different kinds of institutions currently share cybersecurity information with one another.
- Characterise how risks from interconnected third-party service providers are governed in practice.