Cyber Resilience Strategy, Governance, and Risk
Cyber resilience is a governance outcome, not a toolset
The exam tests whether you can connect business risk appetite to resilience objectives and show who owns each decision. Cyber resilience is the ability to anticipate, withstand, recover from, and adapt to adverse conditions. NIST CSF 2.0 organizes outcomes under Govern, Identify, Protect, Detect, Respond, and Recover. Governance sets risk appetite, tolerances, roles, and reporting; it does not delegate accountability to IT.
Core rules
- The board or executive risk committee approves risk appetite and maximum tolerable disruption; business owners accept residual risk.
- A resilience strategy starts from the BIA: critical services, dependencies, single points of failure, and recovery objectives. Controls are chosen to meet those objectives, not to tick framework boxes.
- Use three lines of defense: operations owns controls, risk and compliance challenge, internal audit assures. Separate incident declaration from technical troubleshooting.
- Risk registers should record scenario, likelihood, impact, existing controls, treatment, owner, and residual risk. Concentration risk-one cloud region, one backup vendor, one identity provider-belongs on the register.
- Metrics must be outcome-based: actual RTO/RPO achieved in tests, restore success rate, mean time to detect and respond, percentage of critical vendors with tested resilience, and closure of exercise findings.
Worked example
An insurer's risk appetite says claims cannot be unavailable for more than four hours. The BIA shows the claims platform has an MTPD of eight hours and depends on an identity provider and a payment gateway. The strategy sets an RTO of three hours and an RPO of five minutes, funds a warm standby in a second region, requires immutable backups, and adds a manual claims intake procedure. The residual risk-cloud region loss exceeding three hours-is accepted by the claims director with a review date. That is a governance chain from appetite to control to accepted residual risk.
Traps
Do not treat DR as an IT project, equate compliance with resilience, or write zero downtime as an objective without funding it. Do not let a risk register list risks without owners or treatment dates. Do not measure success by the number of controls deployed rather than by tested recovery capability.