CHAPTER 6: Cyber Risk and Resilience

TL;DR – Key Takeaways from Chapter 6

1. Cyber risk is about service impact and recovery, not just prevention
   Effective cyber and resilience programmes focus on keeping critical services running, limiting disruption when incidents occur, and recovering quickly enough to meet customer and regulatory expectations.

2. Translate technical findings into business-impact scenarios
   Vulnerabilities, tests, and incidents only become meaningful when expressed as scenarios that show cause, event, and impact on services, data, customers, and obligations.

3. Use the same risk lifecycle for cyber as everywhere else
   Threat-led activities such as scanning, testing, and exercises should feed into the shared risk loop: identify, assess, treat, monitor, and govern, rather than running in parallel technical workflows.

4. Exercises only matter if lessons lead to change
   Tabletop exercises, simulations, and incident reviews must result in updated risks, controls, playbooks, and tracked actions, or the learning will fade before the next disruption.

Cybersecurity is not only about preventing attacks. It is about:

1. Keeping important services running
2. Limiting the impact when incidents occur
3. Recovering quickly enough that customers, regulators, and partners can tolerate the disruption 

A practical cyber and resilience program helps you:

1. Understand which services and processes would hurt most if disrupted
2. Anticipate likely attack paths and failure modes
3. Prepare the organization to detect, contain, and recover from incidents
4. Learn from events and exercises so the same weaknesses do not repeat

From a GRC perspective, this means treating cyber risk as business-impact scenarios, not just a stream of vulnerabilities, alerts, or dashboards.

Start by framing cyber risk in terms that business leaders recognize. For example:

1. A ransomware attack encrypts a core platform and its backups, causing a multi-day outage and regulatory notifications.
2. Credentials stolen from a third-party support engineer are used to access production, leading to customer data exfiltration.
3. A misconfigured cloud storage bucket exposes sensitive reports to the internet for several weeks.

For each scenario, identify:

1. The services and entities affected
2. The data involved
3. Downstream impacts on customers, operations, revenue, and regulatory obligations

This connects cyber directly to the scenario structure in the risk chapter (cause → event → impact) and uses the shared objects from Fundamentals (services, risks, controls, vendors, issues, evidence).

Most security teams already run a range of threat-led activities, for example:

1. Vulnerability scanning and penetration testing
2. Red and purple team exercises
3. Threat hunting and log analysis
4. Cloud configuration and posture assessments

Instead of treating these as isolated technical tasks, use them as inputs to the same risk lifecycle you defined in Chapter 3.

A common pattern is:

1. Scope
   1. Focus on specific services, environments, or attack surfaces: external web apps, critical cloud workloads, identity systems, etc.
2. Discover
   1. Identify exposures, misconfigurations, vulnerabilities, weak or missing controls.
3. Prioritize
   1. Link findings to the scenarios and services that matter most; avoid long, unranked lists.
4. Validate
   1. Confirm what an attacker could realistically do and test the effectiveness of key controls.
5. Mobilize
   1. Turn validated exposures into tracked issues and remediation plans, with owners and target dates.

This is simply the generic risk loop from Chapter 3 applied to cyber exposures, not a separate framework. The critical part for GRC is that exposures and test findings land in the same issues and actions register used by the rest of the program, linked to risks and controls.

You cannot prevent every incident, so readiness is as important as prevention. That includes:

1. Tabletop exercises
   1. Scenario-based discussions walking through how an event would unfold.
   2. Include technical teams and business stakeholders (legal, communications, operations, HR).
2. Technical simulations and cyber ranges
   1. Hands-on exercises that test detection and response under realistic conditions.
3. Playbooks and runbooks
   1. Agreed steps and roles for responding to common incident types (ransomware, vendor breach, lost device, cloud misconfiguration).
4. Communication plans
   1. Clear guidelines for talking to leadership, regulators, customers, and staff during incidents.
   2. Alignment with legal and PR on who communicates what, when, and via which channels.

From a GRC perspective, the outputs of these activities matter as much as the exercises themselves:

1. Updated risks and scenarios
2. Refined controls, playbooks, and responsibilities
3. Logged issues and actions with owners and due dates

If the only record of an exercise is a slide deck, the learning will fade before the next event.

To ensure exercises and lessons learned actually improve your posture:

1. Record each exercise as an event in your incident or assurance log
2. Capture, at minimum:
   1. Scenario tested
   2. Services, entities, and vendors involved
   3. What worked well, what failed
   4. Recommendations and decisions taken
3. Log resulting actions in the shared issues and actions register, and link them to:
   1. Relevant cyber and enterprise risks
   2. Controls and playbooks that need updating
   3. Owners in both technical and business teams

This way, time spent on readiness translates into visible changes in your risk and control landscape.

Cyber incidents rarely stay within IT. They often overlap with:

1. Business continuity and disaster recovery
   1. Data center or cloud region outages
   2. Loss of identity platforms or communication channels
2. Third-party risk events
   1. Outages or breaches at SaaS providers, MSPs, and infrastructure vendors
   2. Compromised third-party accounts with access to your systems

In your GRC model:

1. Map critical services to both internal and external dependencies (systems, vendors, data centers, regions).
2. Link cyber and continuity risks to the same service and vendor objects used by TPRM and enterprise risk.
3. Make sure continuity plans and vendor incident processes reference the same roles and communication patterns as your cyber incident playbooks.

This lets you answer questions like:

1. “Which top risks involve this cloud provider?”
2. “Which services are at risk if this identity platform fails?”

and avoids cyber, continuity, and TPRM running in parallel universes.

Useful metrics focus on readiness and learning, not just “number of alerts” or “tools deployed”. Examples:

1. Percentage of critical services with defined cyber and continuity scenarios and named owners
2. Time to detect, contain, and recover from major incidents affecting those services
3. Number of significant cyber incidents or near misses per quarter, and how many led to changes in controls or playbooks
4. Coverage of tabletop and technical exercises across critical services and vendors in the last 12–18 months
5. Percentage of high-priority cyber and resilience actions completed on time

These metrics should be shareable in both security and enterprise risk forums.

To strengthen cyber risk and resilience within your GRC program:

1. Choose one or two critical services and write clear cyber-impact scenarios using the risk model from Chapter 3.
2. Map those services to their key systems and vendors, and confirm they appear in your vendor and engagement inventory.
3. Run (or review) at least one tabletop exercise about a realistic scenario (for example, a major vendor outage or ransomware against a core system), and log outputs as issues and actions.
4. Agree a small set of cyber resilience metrics to add to regular risk reporting, focusing on detection, response, and recovery rather than tool counts.

Handled this way, cyber risk and resilience become part of how you manage core services, not a separate specialist function reporting from the sidelines.

Continue to Chapter 7 - Third-Party Risk Management (TPRM)