Prepare the right scope and people
Choose one service or decision boundary. Invite the service owner, engineering, operations, security, data or privacy and key suppliers when needed.
Share the architecture and current evidence before the meeting. Use workshop time for challenge and decisions.
- Business objective
- Service and data flow
- Dependencies and owners
- Known incidents and findings
Write credible scenarios
Describe how an event unfolds and what it affects: compromised administrator, exposed API, poisoned software dependency, cloud control-plane loss or destructive ransomware.
Avoid vague labels such as “cyberattack.” Include the pathway, asset, consequence and duration.
- Threat or failure path
- Affected service and stakeholders
- Operational and legal impact
- Recovery assumptions
Evaluate controls and uncertainty
Ask for evidence that prevention, detection, response and recovery controls work. Record missing information explicitly.
Do not average control scores into false precision. Explain why the residual exposure matters.
- Control owner
- Last validation
- Known exceptions
- Confidence in evidence
Make and track decisions
Choose treatment, owner, target date and review point. Escalate acceptance according to impact.
Revisit after material changes or incidents. Keep the risk record connected to engineering work.
- Treatment action
- Risk owner
- Due and review date
- Verification method
A practical 30-day field plan
Week one — Frame. Service, objective, scope and impact. Put one accountable owner in the room, agree which business service or decision is in scope, and record the assumptions the team is making. Resist the urge to begin with a technology purchase; the first deliverable is a shared view of the problem and the authority to change it.
Week two — Explore. Threats, dependencies and failure scenarios. Walk through the current process with the people who operate it. Compare the written design with real access paths, data flows, exceptions and on-call practice. Mark every point where an owner is missing or where the team cannot produce evidence that a control works.
Week three — Evaluate. Controls, evidence and uncertainty. Choose a narrow pilot that can be observed safely. Define the expected result, the rollback path and the person who may accept a trade-off. Capture operational friction as product feedback; controls that are difficult to use will eventually be bypassed.
Week four — Decide. Treat, accept, transfer or avoid. Review the pilot with engineering, operations, security and the service owner. Close urgent gaps, assign longer work to a funded backlog and set the next evidence review. The month should end with a repeatable operating rhythm, not a one-time presentation.
Evidence worth keeping
Good evidence is understandable outside the team that created it. Keep a concise record that connects the decision, owner, technical implementation and observed result. Screenshots can support evidence, but configuration, logs, test output and approved records are stronger because another person can reproduce or challenge them.
- Business objective — owner, current state, last validation and any open exception
- Threat or failure path — owner, current state, last validation and any open exception
- Control owner — owner, current state, last validation and any open exception
- Treatment action — owner, current state, last validation and any open exception
- Decision log showing who approved residual risk and when it will be reviewed
- Test or exercise result with the actual outcome, not only a pass label
Questions for the leadership review
Use these questions to keep the discussion connected to operating risk rather than tool activity. A useful answer names a person, a service and evidence.
- Who is accountable for the cyber risk outcome when teams disagree about delivery and risk?
- Which critical service or customer promise would be affected by a failure in this area?
- What evidence would tell us the design is working in production today?
- Which exception creates the largest concentration of access, dependency or recovery risk?
- What would the team contain first, and how would it restore a trustworthy service?
- Which improvement can be completed in the next 30 days without waiting for a large programme?
Common questions
How many risks should one workshop cover?
Usually one service and a handful of meaningful scenarios produce better decisions than dozens of generic risks.
Should risk use a numeric score?
A scale can support prioritisation, but document assumptions, impact and evidence rather than relying on the number alone.