GCSB-GDL-CSF-001 Main Implementation Playbook for the Converged Security Framework

Document type: Guideline (advisory playbook) Parent procedure: GCSB-PRC-CSF-001 Main Implementation Procedure Parent standard: GCSB-ST-CSF-001 Converged Security Framework - Main 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-CSF-001 in practice. Where this playbook and the parent standard or procedure differ, the standard and procedure prevail. Nothing here creates a binding obligation beyond those in the published standard.

1. Purpose

The Main Standard is the spine of the CSF suite: it sets the converged security model, the organisational structures, and the core controls every adopter must operate. The parent procedure fixes the mandatory sequence and clocks - existing systems assessed within 6 months, full implementation within 12 months, monthly committee meetings, quarterly threat analysis, semi-annual gap analysis, annual risk and supplier reviews. This playbook shows how to run that programme well, play by play, with worked examples, checklists and the records to keep.

The worked examples continue the fictional organisation used across this playbook suite: Meridian Logistics Ltd, a 120-person company with a head office, two warehouses, a fleet operation and a small IT team. Its operations director is sponsor; its IT manager is the part-time, formally mandated CCSO.

2. Guiding principles

• One security function, not many. The Main Standard's central demand is convergence of cybersecurity, physical security and operational technology security - with personnel and information concerns embedded across all three - under one accountable structure.
• The committee is the engine. Monthly converged security committee meetings are binding. Treat them as the programme's heartbeat, not an optional forum.
• Clocks are commitments. The 6/12-month assessment and implementation clocks, quarterly threat analysis and semi-annual gap analysis are obligations, not aspirations.
• Converged risk picture. Every play should produce information that feeds a single, unified risk view for the governing body.

4. Scope and roles

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

5. Traceability

Play 1 - Establish the converged security structure (Procedure Steps 1-2)

Objective

Stand up the single accountable security structure the standard requires: a named CCSO (or equivalent), a converged security committee, and clear reporting to the governing body.

Step by step

1. Write the CCSO mandate: scope across all security domains (cybersecurity, physical security and operational technology), authority (require information, stop non-compliant activity, approve exceptions within limits, escalate), and time commitment. Approve it by governing-body resolution.
2. Charter the converged security committee in writing: purpose, membership (cybersecurity, physical security, OT security, risk and legal/compliance, plus business representation), monthly cadence, quorum, decision authority, minute-keeping.
3. Diarise twelve monthly meetings immediately.
4. Document the reporting line: the CCSO reports to the governing body or its risk committee, not into a single operational silo.
5. Name deputies for the CCSO and the committee chair.
6. Publish the structure internally.

Worked example - Meridian Logistics

Meridian's board resolves on 12 March: the IT manager is CCSO at 40% time; the committee is the CCSO (chair), the warehouse operations supervisor (physical), the HR manager (personnel), the finance manager (information/business), and the office manager (deputy chair). Quorum is three including the chair or deputy. Meetings are diarised for the first Tuesday of each month, 14:00, for twelve months. The CCSO reports to the board directly at its quarterly meetings and to the sponsor between them. The structure is announced by all-staff email on 14 March.

Checklist

• CCSO mandate in writing, covering all four domains, approved by resolution
• Committee charter approved (purpose, membership, cadence, quorum, authority)
• Twelve monthly meetings diarised
• Reporting line to the governing body documented
• Deputies named for CCSO and committee chair
• Structure published internally

Records to keep

• The CCSO mandate and the appointing resolution
• The committee charter
• The meeting schedule and, as they happen, the minutes
• The internal announcement

Common pitfalls

• Committee in name only. A committee that meets monthly but only shares slides is not governing. It must take decisions and record them.
• Cyber-heavy membership. If the committee is eight IT people and one facilities manager, convergence has not happened.

Measures of success

The structure exists on paper and in practice: monthly meetings happen, decisions are minuted, and staff know who the CCSO is.

Play 2 - Baseline assessment of existing systems (Procedure Step 3; binding clock: within 6 months)

Objective

Assess every existing system, process and site against the Main Standard's core controls within six months of adoption.

Step by step

1. Build the assessment checklist directly from the standard's clauses so nothing is missed.
2. List the systems, processes and sites to assess (use the strategic scope statement).
3. Assess each item against each applicable clause, covering every security domain - cyber, physical and OT - even where one domain is obviously weak - the weak domain is where the value is.
4. Use the Met / Partially met / Not met / Not applicable scale; evidence every judgement.
5. Prioritise critical systems and sites first so the highest-risk areas are assessed even if time runs short.
6. Present results to the committee, then the governing body.
7. Complete and date the baseline within 6 months of adoption.

Worked example - Meridian Logistics

The CCSO assesses nine systems and three sites against the Main Standard's clauses during April-May. Example finding: "Door access system, Warehouse North - Partially met. Cards are individually issued (met), but there is no joiner/mover/leaver process linking cards to HR events (not met), and the system logs are never reviewed (not met). Evidence: interview with facilities supervisor 24 Apr; card list export showing two cards belonging to staff who left in January." The baseline is complete and presented to the committee on 3 June - month 3, inside the clock.

Checklist

• Assessment checklist derived from the standard's clauses
• All in-scope systems, processes and sites assessed
• All domains covered per item (cyber, physical, OT)
• Judgements evidenced and dated
• Critical items assessed first
• Results presented to the committee and governing body
• Baseline complete within 6 months of adoption

Records to keep

• The completed baseline assessment with evidence references
• Interview notes and artefact copies (e.g. the card list export)
• The committee and governing body minutes where results were presented

Common pitfalls

• Assessing only IT. The standard is converged; a cyber-only baseline fails the requirement.
• Late start. Beginning in month four leaves no implementation runway. Start in month one.

Measures of success

A complete, evidenced baseline exists within the clock, and the governing body has seen it.

Play 3 - Implement the core converged controls (Procedure Steps 4-6; binding clock: full implementation within 12 months)

Objective

Close the baseline gaps by implementing the standard's core controls across all security domains within twelve months.

Step by step

1. Convert baseline gaps into control actions; sequence by risk and dependency (identity and access foundations, incident response capability and asset visibility usually first).
2. For each core control, define four things before starting: the control statement, the operator, the operating record, and the verification method. A control without all four is not implemented.
3. Assign every action a named owner and due date within the 12-month clock.
4. Track implementation weekly at working level; review monthly at the committee.
5. Verify each control operates before closing it - test one real instance.
6. Use the domain playbooks (IAM, IRBC, DPP, TIA, RMA, TRA) for detailed techniques; this playbook coordinates, they execute.

Worked example - Meridian Logistics

Control example: "Converged leaver process. Statement: on any departure, IT accounts, door cards, keys and alarm codes are disabled or recovered on the last working day. Operator: HR manager (trigger) with IT manager and facilities supervisor (execution). Operating record: leaver ticket in the HR system with four checkboxes. Verification: quarterly sample of leavers against account/card lists." The control is verified in July by processing a real leaver and confirming all four items closed same-day. The committee reviews implementation status at every monthly meeting; the dashboard shows percent closed per domain, which exposes that physical-security actions lag in August - fixed by reallocating contractor days.

Checklist

• Every baseline gap mapped to a control action with named owner and date
• Each control has statement, operator, operating record and verification method
• Weekly working-level tracking; monthly committee review
• Each control verified operating (one real instance) before closure
• All core controls implemented by month 12
• Domain balance monitored; lagging domains resourced

Records to keep

• The control register with the four elements per control
• Weekly status notes and monthly committee minutes
• Verification evidence per control (test notes, tickets, screenshots)
• Closure record per action

Common pitfalls

• Declaring controls "done" on paper. Verify each control operates before closing it.
• Domain imbalance. A domain that consistently lags usually signals a resourcing problem, not a motivation problem.

Measures of success

All core controls verified operating within the 12-month clock, with evidence packs.

Play 4 - Run the governance rhythm (Procedure Steps 7-10; binding clocks: monthly committee, quarterly threat analysis, semi-annual gap analysis)

Objective

Operate the standard's standing governance cycle so the security posture stays current after implementation.

Step by step

1. Monthly committee (binding): run with a standing agenda - incidents and near-misses, control health, risks, exceptions, decisions needed. Minute every meeting, including dissents.
2. Quarterly threat analysis (binding): each quarter, produce a short dated analysis of the threat landscape relevant to the organisation - cyber, physical and OT threats, including personnel and information aspects, together. Sources: incident data, sector advisories, police/regulator bulletins, insurer guidance. Present to the committee and governing body.
3. Semi-annual gap analysis (binding): every six months, re-run a proportionate gap analysis against the standard to catch drift, new systems and changed threats. Use the same workbook as the baseline so changes are visible.
4. Diarise the whole rhythm a year ahead.
5. File every output, dated.

Worked example - Meridian Logistics

Meridian's Q3 threat analysis (two pages) notes: a rise in courier-tailgating incidents reported in the local business park (physical), a phishing campaign imitating a fleet-telematics supplier (cyber), and a sector warning about fraudulent references in driver recruitment (personnel). Actions: reception briefed on tailgating, a simulated phishing run themed on the telematics campaign, and reference-checking tightened. The semi-annual gap analysis in September finds two new systems (a customer portal, a dashcam platform) that entered service without security review - both are assessed and added to the control register.

Checklist

• Twelve monthly committee meetings held and minuted per year
• Four quarterly threat analyses produced and presented per year
• Two semi-annual gap analyses completed per year
• Rhythm diarised a year ahead
• All outputs dated and filed

Records to keep

• Committee minutes (monthly)
• Quarterly threat analysis documents
• Semi-annual gap analysis workbooks
• Actions arising, with closure evidence

Common pitfalls

• Rhythm decay. The most common failure is the monthly committee quietly becoming quarterly. The standard does not permit this.
• Threat analysis as copy-paste. Each quarterly analysis should reflect what actually changed; a reused template with a new date is a red flag to auditors.

Measures of success

The rhythm runs unbroken for a full year; every output is dated, minuted and filed.

Play 5 - Annual reviews: risk and suppliers (Procedure Steps 4, 9 and 10; binding clocks: annual)

Objective

Complete the standard's annual risk review and annual supplier review, and act on their findings.

Step by step

1. Annual risk review: convene the committee; retire dead risks, add new ones, re-score the rest; feed results into next year's control priorities and budget.
2. Annual supplier review: list every supplier with access to facilities, systems or information; assess each against the standard's third-party requirements; confirm contracts carry required security clauses; remediate or exit failures.
3. Include legacy suppliers - those engaged years ago often predate current requirements.
4. Align both reviews with the financial planning cycle so findings can be funded.
5. Present both reviews to the governing body; minute decisions.

Worked example - Meridian Logistics

The annual supplier review covers 14 suppliers. Findings: the cleaning contractor's staff hold after-hours access cards but the contract has no vetting clause (remediated: clause added, vetting evidence obtained); the dashcam platform stores footage overseas with no data terms (escalated; supplier provides a data processing addendum); the uniform supplier has no access to anything sensitive (no action). Two suppliers cannot meet requirements and are replaced at contract renewal. Decisions are minuted at the November board meeting.

Checklist

• Annual risk review completed, minuted, fed into planning
• Annual supplier review completed; every relevant supplier assessed, including legacy
• Contract gaps remediated or suppliers exited, decisions recorded
• Both reviews presented to the governing body
• Reviews aligned with the budget cycle

Records to keep

• Updated risk register with review minute
• Supplier assessment list with per-supplier outcomes
• Contract variations or exit decisions
• Governing body minutes

Common pitfalls

• Supplier amnesia. The annual review is where legacy-supplier debt surfaces - do not skip them.
• Review without consequence. A review that never changes a contract, a control or a risk score is theatre.

Measures of success

Both reviews happen annually, on time, with recorded decisions and follow-up actions.

Play 6 - Exceptions, evidence and completion (Procedure Steps 11-12)

Objective

Manage deviations within the standard's exception limits and close the implementation cycle with an evidenced completion declaration.

Step by step

1. Operate the exceptions register exactly as in the Strategic playbook: CCSO-level approval up to 12 months; longer only via the Board Risk Committee on the recommendation of the Enterprise Risk Management Committee; compensating measures mandatory; quarterly review.
2. Before declaring implementation complete, sample-test critical controls across all security domains.
3. Draft the completion declaration: requirements verified, sample tests recorded, open exceptions listed.
4. Have the CCSO and sponsor sign; present to the governing body; minute acceptance.
5. File the declaration with the baseline assessment, committee minutes and evidence packs.
6. Confirm the steady-state calendar (monthly, quarterly, semi-annual, annual cycles) continues after closure.

Worked example - Meridian Logistics

Before declaring completion in February, Meridian sample-tests five controls (see the Strategic playbook example). The declaration lists one open exception (legacy alarm panel, expiry month 14, replacement scheduled). The board accepts the declaration on 18 February; the monthly committee and quarterly threat analysis continue uninterrupted - the March committee meeting happens as diarised, three weeks after declaration.

Checklist

• Exceptions register current; authority limits respected
• Critical controls sample-tested before declaration
• Completion declaration signed and filed with evidence packs
• Governing body acceptance minuted
• Steady-state calendar confirmed running

Records to keep

• Exceptions register and approvals
• Sample-test records
• Signed completion declaration and acceptance minute
• The continuing meeting/review schedule

Common pitfalls

• Clock gaming. Splitting long exceptions into serial short ones to avoid the Board Risk Committee is concealment.
• Completion without verification. A declaration not backed by testing is a liability, not an achievement.

Measures of success

An honest, evidenced declaration exists; the standing rhythm continues after the programme closes.

4. Quick reference: the standing calendar

5. Related documents

• GCSB-ST-CSF-001 Converged Security Framework - Main Standard, v2.0 (parent standard, sole normative source)
• GCSB-PRC-CSF-001 Main Implementation Procedure (parent procedure)
• GCSB-CSF-STRAT and GCSB-PRC-STRAT-001 (programme-level adoption)
• Domain standards, procedures and playbooks (GLA, RMA, TIA, IAM, DPP, IRBC, TRA)

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