GCSB-PRC-IRBC-001 Incident Response and Business Continuity Procedure

Document control

1. Purpose

This procedure tells an adopting organisation exactly who does what, when and how to implement GCSB-ST-CSF-IRBC-001. It converts the standard's requirements (clauses 6.1 to 6.6) into repeatable, auditable steps. It does not change, relax or extend any requirement of the standard; where this procedure and the standard differ, the standard prevails. Where the NIS2 Directive, DORA, the UK and EU GDPR or other sectoral rules impose stricter requirements, the stricter rule applies.

2. Scope and applicability

This procedure applies to every organisation adopting the Incident Response and Business Continuity Framework. Full implementation is required within 12 months of certification commencement, with an assessment of existing incident response and business continuity systems within 6 months. This standard does not sit on the 18-month extended track. No interim or compensating control removes a legal duty.

3. Roles

4. Procedure

Step 1 - Record the adoption and scope (Week 1)

1. The governing body passes a written adoption decision naming the standard, edition (v2.0) and adoption date.
2. The CCSO records the adoption date in the implementation register. This date starts every clock in this procedure.
3. The adopter confirms the in-scope systems: incident response systems across IT, OT and physical domains; business continuity platforms; cross-domain integration platforms; cloud and hybrid environments; third-party arrangements; escalation systems; RTO/RPO implementations; and crisis management and communication systems (clause 2).

Record: adoption decision; scope record.

Step 2 - Establish governance and command (Month 1)

1. Board-level oversight is established with designated accountability for unified risk management across all security domains (clause 5).
2. The CCSO is confirmed with authority over incident response coordination across all domains.
3. The cross-functional governance committee adopts a monthly meeting calendar (clause 5).
4. Unified command and control arrangements are documented for incidents, with standardised communication protocols, clear authority delegation and designated regulatory-reporting owners (clause 5).

Record: oversight appointment; committee calendar; command and control document.

Step 3 - Unified incident response protocols (Months 1-4)

1. The adopter deploys unified incident response protocols integrating cyber incident response, physical security breach response and OT disruption response, with coordinated cross-functional response teams and clearly defined roles (clause 6.1).
2. A standardised incident classification system is implemented, categorising Hybrid, Systemic and Cascading incident types mapped to the separate severity-tier model required by clause 4 of the standard.
3. Cross-domain integration between incident response systems is established consistent with GCSB-ST-CSF-TIA-001, vendor-neutral and proportionate to the adopter's risk profile (clause 6.1).
4. Zero Trust Architecture principles are applied across incident response operations, with continuous verification during incidents (clause 6.1).
5. Where AI/ML is used for predictive threat analysis or automated response coordination, it is proportionate, governed and consistent with GCSB-ST-CSF-TIA-001 (clause 6.1).

Record: response protocols; classification system; integration evidence.

Step 4 - Escalation and decision-making authority (Months 2-4)

1. Notification arrangements alert designated response teams promptly upon detection of a security incident in any domain (clause 6.2).
2. Escalation levels and decision-making authorities are defined - response-team level, CCSO level, board-level risk committee level, and regulator notification - with reliability of notification arrangements evidenced; the adopter sets and documents its own target reliability and response-time figures as indicative values, except where law sets a specific figure (clause 6.2).
3. Automatic escalation triggers are configured for incidents affecting multiple security domains simultaneously, compromising critical infrastructure systems, or showing cascading-failure potential (clause 6.2).
4. Regulatory notification procedures comply with applicable law, including NIS2, DORA and GDPR where applicable; for personal data breaches, UK GDPR notification timing follows the UK statutory rule, and for the EU the period set by applicable EU and Member State law (clause 6.2).
5. Escalation is integrated with business continuity activation for incidents affecting critical business processes (clause 6.2).

Record: escalation matrix; notification procedures; reliability evidence.

Step 5 - Business continuity planning and recovery (Months 3-8)

1. Business continuity plans address scenarios affecting multiple security domains simultaneously, including simultaneous compromise of cyber, physical and OT systems (clause 6.3).
2. RTOs and RPOs are defined for each critical business process by criticality tier. The standard's indicative tiers (Critical: 4 hours RTO / 1 hour RPO; Essential: 24 hours / 4 hours; Important: 72 hours / 24 hours; Support: 1 week / 48 hours) are a starting reference which the adopter confirms, adjusts and documents in its own procedures, reconciled with recovery clocks under GCSB-ST-CSF-RMA-001 and GCSB-ST-CSF-IAM-001 (clause 6.3).
3. Integrated recovery procedures provide coordinated activation linking incident response and business continuity teams, alternative operating arrangements and supply chain continuity (clause 6.3).
4. Cascading-failure prevention and mitigation measures are developed: dependency mapping, cascade trigger identification and containment procedures for each identified cascade pathway (clause 6.3).
5. Hybrid-threat response procedures address simultaneous physical and digital exploitation, with safety-qualified controls for operational technology (clause 6.3).

Record: business continuity plans; approved RTO/RPO register; cascade containment procedures.

Step 6 - Gap assessment (by Month 6, binding)

1. The adopter completes the assessment of existing incident response and business continuity systems against every requirement of clauses 6.1 to 6.6 within 6 months of certification commencement (clause 7).
2. The CCSO consolidates findings into a gap register: gap, affected clause, risk rating, interim control, owner, target date.

Record: gap assessment; gap register.

Step 7 - Training and awareness (Months 4-10, then recurring)

1. Cross-functional training is provided for all personnel covering cyber, physical and OT incident awareness and response; specialised training for incident response personnel covers converged threat scenarios and hybrid attack vectors (clause 6.4).
2. Regular tabletop exercises and simulation drills test response to multi-domain incidents, with lessons learned documented and incorporated into procedures (clause 6.4).
3. Competency requirements are defined for incident response roles; business continuity training covers role-specific procedures and communication protocols; executive training covers crisis management, strategic decision-making during incidents and regulatory reporting obligations (clause 6.4).
4. Training completion targets and competency levels are set by the adopter consistent with GCSB-ST-CSF-TRA-001.

Record: training records; exercise reports; competency register.

Step 8 - Compliance integration (Months 4-9)

1. Incident response and business continuity management is aligned with ISO 31000, ISO/IEC 27001 and ISO 22301 as applicable, and applicable sector-specific regulatory requirements are mapped, including NIS2 and DORA where relevant (clause 6.5).
2. GDPR requirements are integrated into incident response procedures, including breach notification protocols and cross-border data transfer implications (clause 6.5).
3. An internal audit programme is maintained to verify compliance with this standard's requirements (clause 6.5).

Record: compliance mapping; audit programme and reports.

Step 9 - Monitoring and continual improvement (Months 6-12, then recurring)

1. Dashboards provide visibility into incident response and business continuity performance, with alerting for performance degradation across any security domain (clause 6.6).
2. Reporting cadences are defined and operated appropriate to the governance structure - periodic compliance reporting, periodic gap analysis and an annual resilience assessment (a cadence chosen by the adopter) including recovery-time testing for multi-domain scenarios - reconciled with the cadences used elsewhere in the CSF suite (clause 6.6).
3. Post-incident analysis is conducted for all significant incidents, with lessons learned documented and incorporated into procedures and training (clause 6.6).

Record: dashboards; reporting calendar; post-incident analysis reports.

Step 10 - Completion declaration (by Month 12, binding)

1. The CCSO verifies every requirement of clauses 6.1 to 6.6 is implemented or covered by an approved exception, and every binding period met.
2. The CCSO signs the implementation completion declaration and presents it to the governing body.
3. The organisation continues the recurring cycles in Steps 7 and 9.

Record: signed completion declaration; governing-body minute.

Step 11 - Exceptions (as needed)

1. Deviations require documented business justification and CCSO approval; the CCSO may approve temporary exceptions for up to 12 months (clause 9).
2. Longer exceptions require approval by the Board Risk Committee on the recommendation of the Enterprise Risk Management Committee.
3. All exceptions are reviewed quarterly, with remediation progress, a risk assessment and compensating controls documented for each exception.

Record: exception register with quarterly review dates.

5. Records and retention

All records named in this procedure are retained for the period set by the adopter's records policy and the standard's evidence duties, whichever is longer. This procedure creates no alternative retention period.

6. Related documents

• GCSB-ST-CSF-IRBC-001 v2.0 (parent standard)
• GCSB-ST-CSF-001 Main Standard and GCSB-PRC-CSF-001
• Companion standards: GLA, RMA, TIA, IAM, DPP, TRA and the CCSO Policy
• GCSB certification procedure (assessment and decision clocks)

Revision history