GCSB-GDL-IRBC-001 Incident Response and Business Continuity Playbook

Document type: Guideline (advisory playbook) Parent procedure: GCSB-PRC-IRBC-001 Incident Response and Business Continuity Procedure Parent standard: GCSB-ST-CSF-IRBC-001 Incident Response and Business Continuity Standard, Version 2.0 Version: 1.0 Status: Issued Approved by: GCSB Governing Council, 19 October 2026 Effective: 19 October 2026 Next review: 19 October 2027 Prepared by: Global Converged Security Board (GCSB)

This playbook is advisory. It explains how to apply GCSB-PRC-IRBC-001 in practice. Where this playbook and the parent standard or procedure differ, the standard and procedure prevail.

1. Purpose

The IRBC standard requires the ability to detect, respond to and recover from incidents - cyber, physical and converged - and to keep the business running through disruption, within the standard's recovery time and recovery point tiers. The parent procedure fixes the plan structures, test cycles and clocks. This playbook shows how to build response and continuity capability that works on the worst day, with step-by-step guidance, worked examples, checklists and the records to keep.

The worked examples use the fictional Meridian Logistics Ltd (120 staff, head office, two warehouses, fleet operation).

2. Guiding principles

• Converged incidents are the norm. A break-in with a stolen laptop is physical AND cyber. Plans must handle combined events.
• Rehearsed, not read. A plan nobody has exercised is a hypothesis. Testing is a binding part of the standard.
• Decisions before disasters. Authority, thresholds and notification routes are agreed in calm times.
• Recovery is a business target. RTO and RPO come from the business impact analysis, not from what IT finds convenient.

4. Scope and roles

This playbook applies to every organisation adopting GCSB-ST-CSF-IRBC-001 through GCSB-PRC-IRBC-001. It is advisory throughout: where it differs from the parent standard or procedure, the standard and procedure prevail.

5. Traceability

Play 1 - Define incident categories, severity and authority (Procedure Steps 1-2)

Objective

Set the taxonomy: what counts as an incident, how severe it is, and who is in charge at each level.

Step by step

1. Define incident categories across all domains: cyber, physical and OT, including personnel and information/data aspects, and converged combinations.
2. Define three or four severity levels with concrete examples and the response each triggers (who is called, how fast, who decides).
3. Write the authority model: the incident commander role; who can take systems offline; who can close a site; who speaks to authorities, media and affected individuals.
4. Get the authority model approved by the governing body before it is needed.
5. Staff and publish the on-call and escalation roster.
6. Test the taxonomy: have the team grade ten sample events and check for consistency.

Worked example - Meridian Logistics

Meridian defines four severities. S1 (critical): life safety, site loss, major data breach - CCSO + sponsor immediately, board chair within 2 hours. S2 (major): confirmed intrusion, ransomware, significant theft - CCSO within 1 hour. S3 (minor): contained events - CCSO next working day. S4: near-misses, logged and trended. Authority model: the CCSO is incident commander; the CCSO may isolate any system; site closure needs the sponsor; external statements only from the sponsor; regulator/individual notification decisions per the DPP breach route. Approved at the June board. The grading test: ten sample events graded by three people - nine consistent; the tenth (a lost unencrypted phone) tightens the S2/S3 examples.

Checklist

• Categories defined across all domains including converged
• Severity levels with concrete examples and triggers
• Authority model approved by the governing body
• On-call/escalation roster staffed and published
• Grading consistency test completed

Records to keep

• The taxonomy and severity definitions
• The approved authority model
• The roster and its publication date
• The grading-test record

Common pitfalls

• Severity ambiguity. If two reasonable people grade the same event differently, tighten the examples.
• Authority vacuum. The first hour of a real incident is the wrong time to discover nobody may authorise a shutdown.

Measures of success

A tabletop exercise grades ten sample events consistently, and everyone knows who commands.

Play 2 - Build the response plan and playbooks (Procedure Steps 3-5)

Objective

Write the incident response plan and the scenario playbooks for the organisation's top incident types.

Step by step

1. Write the master plan: detection and reporting routes, triage, escalation, containment, evidence preservation, communication (internal, regulatory, individuals, media), recovery, post-incident review. Keep it short.
2. Select the top scenarios from the risk register; write a one-to-two-page playbook per scenario.
3. Each scenario playbook contains: first five actions, who does them, what to preserve, who to call, and what NOT to do.
4. Print the plan and playbooks; hold copies at defined locations - in a serious cyber incident the electronic copy may be unreachable.
5. Verify contact lists quarterly; numbers change.

Worked example - Meridian Logistics

Meridian's master plan is six pages. Six scenario playbooks: ransomware; data breach; warehouse intruder/theft; insider incident; loss of Warehouse South (fire/flood); converged event (break-in plus stolen laptop). The ransomware playbook's first five actions: 1) disconnect affected machines from the network (do not power off); 2) call the CCSO; 3) isolate the site network segment; 4) preserve logs and note times; 5) start the incident record. "What NOT to do": do not pay or contact attackers; do not rebuild machines before evidence capture. Printed copies live in the server room, both warehouse offices and the CCSO's car folder. Contact verification is diarised quarterly.

Checklist

• Master response plan written, approved, short
• Scenario playbooks for the top risks written
• Each playbook has first five actions, owners, preservation, contacts, prohibitions
• Printed copies at defined locations
• Contact lists verified quarterly

Records to keep

• The master plan and scenario playbooks (version-controlled)
• Print-location list
• Quarterly contact-verification records
• Approval evidence

Common pitfalls

• The 80-page plan. Nobody reads it under pressure. Master plan short; detail in scenario playbooks.
• No evidence discipline. Actions in the first hour decide whether later investigation, insurance claims and prosecution are possible.

Measures of success

A new team member can run the first hour of a top scenario from the playbook alone.

Play 3 - Establish business continuity (Procedure Steps 5-6; indicative RTO/RPO tiers per the standard, confirmed by the adopter)

Objective

Set recovery targets from business impact and build the continuity plans to meet them.

Step by step

1. Run the business impact analysis (BIA) process by process: maximum tolerable outage, RTO, RPO, minimum resources, dependencies.
2. Assign each process to the standard's recovery tier.
3. Build continuity plans per critical process: alternate arrangements, manual workarounds, supplier dependencies, communication trees.
4. Verify backups meet the RPOs and restores meet the RTOs - by test, not assumption.
5. Address converged dependencies: if access control fails, can the site operate? If the site closes, can the business run remotely?

Worked example - Meridian Logistics

The BIA covers 9 processes. Order fulfilment: RTO 4 hours, RPO 15 minutes (tier 1). Fleet dispatch: RTO 2 hours with a paper fallback (tier 1). Payroll: RTO 5 days (tier 3). The continuity plan for Warehouse South's loss: shift operations to Warehouse North within 48 hours using a pre-agreed overflow arrangement with a neighbouring depot (letter of agreement filed). Restore test in August: the order database restores in 3 hours 10 minutes against a 4-hour RTO - recorded. The door-system failure plan: manual signing-in book plus supervisor escort procedure, tested in September.

Checklist

• BIA completed; every critical process has RTO/RPO and tier
• Continuity plans written per critical process
• Backup/restore tested against RPO/RTO; results recorded
• Converged dependencies addressed with tested fallbacks
• Supplier/mutual-aid agreements documented

Records to keep

• The BIA with per-process RTO/RPO and tier
• Continuity plans
• Restore-test records with timings
• Fallback test records
• Mutual-aid/supplier agreements

Common pitfalls

• RTO fiction. Targets set by aspiration fail under test. Test a real restore before committing to the tier.
• IT-only continuity. Continuity for systems but not for people, premises and suppliers is half a plan.

Measures of success

Tested restores meet the tier targets; continuity plans name real alternatives, not hopes.

Play 4 - Train, exercise and test (Procedure Steps 7 and 9; test cycles per the standard)

Objective

Make response and continuity capability real through exercises, on the standard's test cycles.

Step by step

1. Approve an annual exercise programme: tabletops for the governing body and committee (decision-making), technical simulations for responders (execution), and at least one converged scenario per year.
2. Test continuity plans on the standard's cycle: restore tests, alternate-arrangement trials, call-tree tests.
3. Design exercises with friction and surprises - an exercise designed to pass teaches nothing.
4. After every exercise and every real incident, run a blameless post-incident review: timeline, what worked, what failed, actions with owners and dates.
5. Track actions to closure at the committee; the same finding twice means the process is broken.

Worked example - Meridian Logistics

Year one exercises: a July tabletop (board grades a simulated ransomware event; finds the out-of-hours phone tree had a wrong number - fixed); an October technical simulation (IT isolates a "compromised" machine and preserves evidence, timed at 22 minutes); a December converged exercise (simulated night break-in at Warehouse North with a stolen laptop - police liaison, evidence preservation, data-breach assessment and the manual door fallback all exercised together). Post-exercise actions: 7 raised, 7 closed by February. The call-tree test takes 40 minutes to reach everyone; target met.

Checklist

• Annual exercise programme approved, including one converged scenario
• Continuity tests run on the standard's cycle; results recorded
• Exercises include friction and surprises
• Blameless post-incident/exercise reviews held
• Actions tracked to closure at the committee

Records to keep

• The exercise programme and scenario materials
• Exercise records and timings
• Test results (restores, call trees, fallbacks)
• Post-incident review reports and action logs

Common pitfalls

• Exercises designed to pass. Include surprises.
• Lessons filed, not fixed. The same finding in two consecutive reviews means the process is broken, not the people.

Measures of success

Exercises happen on schedule; findings turn into closed actions; the same failure does not recur.

Play 5 - Review, maintain and evidence (Procedure Steps 10-11)

Objective

Keep plans current and the evidence trail complete.

Step by step

1. Review all plans annually and after every major incident, exercise or organisational change.
2. Report IRBC readiness annually to the governing body: tests done, results, open actions, tier compliance.
3. Keep the evidence pack: plans and versions, exercise records, test results, incident records, post-incident reviews, committee minutes.
4. Run the quarterly contact-list check without fail - stale contacts are the most common plan failure.

Worked example - Meridian Logistics

The February annual review updates three playbooks (new telematics supplier contact; revised isolation steps after the network re-segmentation; a new mutual-aid contact). The readiness report to the board: 3 exercises held, 2 restore tests passed, 1 converged test passed, 7 of 7 actions closed, all tier targets met. The evidence pack fills one folder per play, reviewed by the external assurance reviewer in spring with no findings.

Checklist

• Annual plan review completed and minuted
• Post-incident/change reviews trigger plan updates
• Annual readiness report to the governing body
• Quarterly contact verification done
• Evidence pack complete and retrievable

Records to keep

• Plan versions and review minutes
• Readiness reports
• Contact-verification logs
• The full IRBC evidence pack

Common pitfalls

• Stale contacts and stale plans. The quarterly contact check and annual review exist precisely because plans rot.

Measures of success

Plans are current; the governing body can state readiness honestly.

4. Quick reference

5. Related documents

• GCSB-ST-CSF-IRBC-001 Incident Response and Business Continuity Standard, v2.0 (parent standard, sole normative source)
• GCSB-PRC-IRBC-001 Incident Response and Business Continuity Procedure (parent procedure)
• GCSB-ST-CSF-DPP-001 (breach notification) and GCSB-ST-CSF-RMA-001 (risk inputs)

Version 1.0 - issued 19 October 2026. Copyright Global Converged Security Board.