GCSB-PRC-CCSO-001 CCSO Office Establishment Procedure

Document control

1. Purpose

This procedure tells an adopting organisation exactly who does what, when and how to implement GCSB-POL-CSF-CCSO-001. It converts the policy's requirements (R1 to R10) into repeatable, auditable steps for establishing and operating the adopter's CCSO office. It does not change, relax or extend any requirement of the policy; where this procedure and the policy differ, the policy prevails. The adopter CCSO office described here is distinct from, and does not confer, the GCSB CCSO membership grade.

2. Scope and applicability

This procedure applies to every organisation adopting the CCSO Policy, across all entities, systems, personnel and third-party integrations listed in clause 2 of the policy. Implementation is required within 12 months of certification commencement, with a 6-month gap assessment of existing systems against the policy's requirements.

3. Roles

4. Procedure

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

1. The Board passes a written adoption decision naming the policy, edition (v2.0) and adoption date.
2. The CCSO (once appointed) records the adoption date in the implementation register. This date starts every clock in this procedure.
3. The adopter confirms the scope: all organisational entities and controlled affiliates; all IT systems, networks, applications and data repositories; all OT systems; all physical security infrastructure; all third-party integrations, cloud services and supply chain connections; and all employees, contractors, consultants and temporary personnel (clause 2 of the policy).

Record: adoption decision; scope record.

Step 2 - Establish the Board Risk Committee and sponsorship (Month 1)

1. The Board establishes a Board Risk Committee with oversight responsibility for converged security governance; where the adopter's arrangements provide for independent directors, the Committee should include members with relevant security, risk management or technology expertise proportionate to the organisation's size and risk profile (clause 5).
2. The CEO confirms executive sponsorship and the budgetary allocation mechanism under CCSO authority (clause 5).

Record: committee establishment; sponsorship confirmation.

Step 3 - Appoint the CCSO (Months 1-3, requirement R1)

1. The Board formally appoints the CCSO with executive authority equivalent to other C-suite officers, reporting directly to the CEO and the Board Risk Committee (clause 5).
2. The appointment instrument records the decision-making authority: budgetary control over security-related expenditure across all domains; authority to issue security directives to business units, subsidiaries and third-party service providers; authority to require modification or suspension of business operations that pose unacceptable security risk; and final authority over security incident response decisions and business continuity activation (clause 5).
3. Appointment criteria reflect senior security leadership experience, relevant professional certification and a record of regulatory compliance management, without implying GCSB CCSO membership (R1).
4. Competence is demonstrated aligned with GCSB-ST-CSF-TRA-001 (R1).

Record: appointment instrument; competence evidence.

Step 4 - Establish the governance structure (Months 1-3, requirement R2)

1. The CCSO establishes and chairs the Converged Security Governance Committee comprising representatives responsible for IT security, OT security, physical security, risk management, legal and compliance, and Convergence Champions from major business units (clause 5).
2. The committee adopts a regular meeting cadence defined by the adopter, with provision for emergency sessions following significant security incidents (clause 5).
3. Each business unit appoints a Convergence Champion as primary liaison with the CCSO (clause 5).
4. The CCSO begins regular reports to the Board Risk Committee covering converged security posture, risk assessments, incident response activity and regulatory compliance status (R2).

Record: committee records; champion appointments; Board reports.

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

1. The adopter completes the gap assessment of existing systems against the policy's requirements R1 to R10 within 6 months of certification commencement (clause 7).
2. The CCSO consolidates findings into a gap register: gap, affected requirement, risk rating, interim control, owner, target date.

Record: gap assessment; gap register.

Step 6 - Unified risk register (Months 2-6, requirement R3)

1. The CCSO implements a risk management framework aligned with GCSB-ST-CSF-RMA-001.
2. The Unified Risk Register consolidates risks across cyber, physical and OT domains, including cascade effect mapping and interdependency analysis, reviewed on a regular cycle defined by the adopter (R3).

Record: Unified Risk Register; review cycle.

Step 7 - Identity and access governance (Months 3-9, requirement R4)

1. The organisation deploys and maintains unified identity and access management aligned with GCSB-ST-CSF-IAM-001.
2. This includes multi-factor authentication for critical access points, privileged access management based on least privilege, and identity lifecycle management integrated with human resources processes (R4).

Record: IAM deployment evidence.

Step 8 - Incident response tiers and business continuity (Months 3-9, requirement R5)

1. The CCSO establishes unified incident response procedures and business continuity plans aligned with GCSB-ST-CSF-IRBC-001, including a tiered escalation structure and defined recovery objectives.
2. Response, notification and recovery time values in the organisation's procedures are indicative values the adopter confirms and documents, unless a shorter or longer period is set by applicable law (R5).

Record: response procedures; continuity plans; escalation structure.

Step 9 - Compliance and regulatory alignment (Months 3-9, requirement R6)

1. The organisation maintains a regulatory compliance register and procedures for monitoring regulatory change, covering frameworks applicable to it such as GDPR/UK GDPR, NIS2 and DORA.
2. Regulatory notification periods stated in applicable law apply as set by that law; internally stated periods are indicative unless law requires otherwise (R6).

Record: regulatory compliance register; change-monitoring procedure.

Step 10 - Technology and supply-chain integration (Months 4-10, requirement R7)

1. The organisation integrates SIEM and PSIM platforms in a vendor-neutral manner, aligned with GCSB-ST-CSF-TIA-001, extending to OT environments and third-party and supply-chain integrations.
2. Third-party integrations are subject to CCSO approval and ongoing monitoring (clause 5).

Record: integration records; third-party approvals.

Step 11 - Audit, assurance and performance measurement (Months 6-12, requirement R8)

1. The CCSO establishes an audit and assurance framework, including periodic independent internal audit of converged security controls and corrective action plans for identified deficiencies within a timeframe the adopter defines and documents.
2. Performance measurement covers risk management, incident response, access management, regulatory compliance, and training and culture development.
3. Any quantitative targets (detection accuracy, false-positive rates, prediction accuracy, activation time, training completion) are either supported by a defined and documented measurement method or treated as aspirational indicators, and in either case are not commitments or guarantees (R8, clause 8).

Record: audit framework; performance reports; corrective action plans.

Step 12 - Resources, crisis management and change control (Months 6-12, requirements R9 and R10)

1. The CCSO holds defined budgetary authority for converged security expenditure, subject to thresholds set by the Board Risk Committee, with regular financial reporting (R9).
2. The CCSO maintains crisis management and communication procedures, including defined incident reporting channels and escalation to the CEO and Board Risk Committee for critical incidents (R9).
3. The CCSO maintains a change management process classifying changes to the policy (emergency, standard or major); emergency changes receive retrospective Board Risk Committee approval within a timeframe the adopter defines, and major changes receive Board Risk Committee approval following impact assessment (R10).
4. Version control records are retained for a period the adopter defines and documents, consistent with its regulatory and audit obligations (R10).

Record: budget authority record; crisis procedures; change records; version history.

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

1. The CCSO verifies every requirement R1 to R10 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 Board Risk Committee.

Record: signed completion declaration; Board Risk Committee minute.

Step 14 - Exceptions (as needed)

1. The CCSO may approve temporary exceptions to the policy for up to 12 months, supported by documented business justification and risk assessment (clause 9).
2. Exceptions longer than 12 months require approval by the Board Risk Committee on the recommendation of the Enterprise Risk Management Committee.
3. All exceptions are reviewed quarterly, with a centralised exception register recording business justification, compensating controls, risk evaluation and remediation progress.

Record: centralised 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 policy's evidence duties, whichever is longer. This procedure creates no alternative retention period.

6. Related documents

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

Revision history