GCSB-GDL-STRAT-001 Strategic Implementation Playbook for the Converged Security Framework

Document type: Guideline (advisory playbook) Parent procedure: GCSB-PRC-STRAT-001 Strategic Implementation Procedure Parent standard: GCSB-CSF-STRAT Converged Security Framework - Strategic Standards for Resilience, 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-STRAT-001 in practice and offers recommended techniques, worked examples, checklists and record-keeping guidance. Where this playbook and the parent standard or procedure differ, the standard and procedure prevail. Nothing in this playbook creates a binding obligation beyond those in the published standard.

1. Purpose of this playbook

GCSB-PRC-STRAT-001 tells an organisation what must happen, in what order and by when, to adopt the Converged Security Framework (CSF). This playbook tells you how to do it well. It is written for the people who actually run the adoption: the sponsoring executive, the Converged Security Officer (CCSO) or equivalent, and the small working team that carries the programme for its first twelve months.

The playbook is organised as a series of "plays". Each play corresponds to a step in the procedure and provides:

• Objective - what the play achieves.
• Step by step - the recommended sequence of actions.
• Worked example - the play executed by a fictional organisation, so you can see the artefacts and decisions in concrete form.
• Checklist - a practical list you can tick off.
• Records to keep - the evidence the procedure expects, in the form auditors ask for it.
• Common pitfalls - mistakes seen repeatedly in security transformation programmes, and how to avoid them.
• Measures of success - how to know the play worked.

The worked examples use one continuing fictional organisation throughout: Meridian Logistics Ltd, a 120-person company with a head office, two warehouses, a fleet operation and a small IT team. Meridian has no dedicated security staff when it begins; its operations director becomes the sponsor and its IT manager becomes the CCSO (part-time, formally mandated). Adjust the scale to your own organisation - the sequence does not change.

2. How to use this playbook

1. Read the parent standard (GCSB-CSF-STRAT) once, end to end, before starting. It is short by design.
2. Read the parent procedure to fix the mandatory sequence and clocks in your mind: adoption recorded, scope defined, gap assessment within 6 months, full implementation within 12 months, quarterly reviews thereafter.
3. Work through the plays in order. Do not skip Play 1 (governance and sponsorship); programmes that skip it almost always stall.
4. Adapt the examples to your organisation's size. A 30-person company and a 30,000-person company can both adopt the CSF; the depth of documentation differs, the sequence does not.
5. Keep every record the procedure requires. The playbook suggests formats, but any clear, dated, attributable record is acceptable.

3. Guiding principles

• Convergence first. The CSF exists to end the separation of physical security, cyber security, personnel security and information security into silos. Every play should be executed by a converged team, not delegated to one silo.
• Evidence over assertion. A control that is not evidenced does not exist. Prefer simple, dated artefacts (minutes, registers, screenshots, signed statements) over narrative claims.
• Proportionality. Apply effort in proportion to risk. The standard sets the floor; the playbook helps you decide how far above the floor to go.
• Honest gap reporting. A gap assessment that flatters the organisation is worse than none. The Board cannot fund or fix what it cannot see.
• Sustainability. The 12-month implementation clock is a beginning, not an end. Design every control so it can be operated by the team you will actually have in year two.

4. Scope and roles

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

5. Traceability

Play 1 - Record adoption and secure sponsorship (Procedure Step 1)

Objective

Convert a general intention to adopt the CSF into a formal, recorded decision with a named accountable executive.

Step by step

1. Draft a one-page adoption paper for the governing body: what the CSF is, why the organisation is adopting it, what the binding clocks are (6-month gap assessment, 12-month implementation, quarterly reviews), what it will roughly cost in money and time, and who is proposed as sponsor and CCSO.
2. Put the paper on the governing body's agenda as a decision item, not a discussion item.
3. At the meeting, secure a formal resolution: adoption approved, sponsor named, CCSO named, clocks acknowledged. Record the resolution in the minutes with the date.
4. If the organisation has no board (sole trader, small partnership), the owner writes and signs a dated adoption decision instead.
5. Within one week, announce the decision internally: what is happening, who is leading it, what staff will notice first.
6. File the resolution (or signed decision) and the announcement in the programme's evidence folder.

Worked example - Meridian Logistics

The operations director tables a one-page paper at the March board meeting. The resolution reads: "Meridian Logistics Ltd adopts the GCSB Converged Security Framework. The Operations Director is accountable sponsor. The IT Manager is appointed Converged Security Officer at 40% time commitment, backfilled by a contractor for 1 day/week. The Board notes the 6-month gap assessment and 12-month implementation clocks." The resolution is minuted on 12 March. On 14 March, an all-staff email announces the adoption, names the sponsor and CCSO, and says staff will first notice "a survey about how we protect people, sites, systems and information". Both documents are filed in a new folder: CSF/01-Adoption/.

Checklist

• Adoption paper drafted (one page)
• Formal resolution or signed decision recorded, with date
• Accountable executive sponsor named
• CCSO (or equivalent) named, with time commitment stated
• Internal announcement issued within one week
• Adoption record filed where auditors would expect to find it

Records to keep

• The adoption paper as tabled
• The signed minutes or signed decision, dated
• The internal announcement (email or notice), dated
• The CCSO mandate or appointment letter, stating time commitment

Common pitfalls

• Unminuted enthusiasm. A verbal "yes, let's do it" in a leadership meeting is not adoption. Insist on the written record.
• Sponsor without time. A sponsor who cannot give the programme two hours a month cannot clear obstacles. Name a deputy.
• Announcing before deciding. Do not communicate adoption to staff or clients before the decision is recorded; retractions damage credibility.

Measures of success

The decision is recorded, dated, and retrievable; staff can name the sponsor and CCSO when asked.

Play 2 - Define scope (Procedure Step 2)

Objective

Draw an explicit boundary around what the first adoption cycle covers: legal entities, sites, business units, systems and information assets.

Step by step

1. List the legal entities covered by the adoption resolution.
2. List every site and facility, marking each in or out of scope for cycle one.
3. List business units and critical processes (the things that, if stopped, stop the organisation).
4. List key systems and information stores. Reconcile against finance procurement records and IT's asset list to catch shadow purchases.
5. For every exclusion, write a one-line justification and record who accepted the risk.
6. Keep the whole scope statement to one page. If it needs ten pages, the scope is not yet understood.
7. Have the governing body approve and date the scope statement, on the sponsor's recommendation.

Worked example - Meridian Logistics

Meridian's scope statement covers: one legal entity (Meridian Logistics Ltd); three sites (head office, Warehouse North, Warehouse South - all in scope); four critical processes (order fulfilment, fleet dispatch, payroll, customer data handling); nine key systems (order management, fleet telematics, email/file store, accounting package, CCTV at both warehouses, door access system, alarm system, HR records, customer database). One exclusion: the fleet's subcontractor depot, justified as "third-party operated, covered by contract review in cycle two", accepted by the governing body. The statement is one page, approved and dated 26 March.

Checklist

• Legal entities listed
• Sites and facilities listed with in/out status
• Business units and critical processes listed
• Key systems and information stores listed
• Procurement and asset records reconciled for shadow items
• Exclusions recorded with justification and named risk acceptor
• Scope statement approved by the governing body and dated; fits on one page

Records to keep

• The approved scope statement, dated
• The exclusion list with justifications and acceptor names
• The source lists used (asset register extract, procurement list) as evidence the scope was built from reality

Common pitfalls

• Scope by convenience. Scoping only what the current team already controls produces a gap assessment that finds nothing.
• Forgotten shadow operations. Procurement cards, personal devices, cloud subscriptions bought on expense accounts - ask finance and IT for lists and reconcile them.
• Static scope. Revisit scope at each quarterly review; mergers, new sites and new products change it.

Measures of success

Anyone in the organisation can determine whether a given asset, site or process is in scope by reading one page.

Play 3 - Conduct the gap assessment (Procedure Step 3; binding clock: within 6 months of adoption)

Objective

Produce an honest, evidenced comparison between current practice and every requirement of the CSF suite, early enough to leave room for implementation within the 12-month clock.

Step by step

1. Build the assessment workbook: one row per requirement of each applicable standard (GLA, RMA, TIA, IAM, DPP, IRBC, TRA, the Main Standard, and the strategic requirements themselves).
2. Choose the maturity scale: Met / Partially met / Not met / Not applicable (justified). Avoid five-point scales at this stage; they invite false precision.
3. Assign assessors in pairs, and never let the person responsible for a control be its only judge.
4. Assess by interviewing process owners and inspecting artefacts - not just reading policies. Ask "show me the last time this happened" for every control.
5. Record for every row: the judgement, the evidence seen (or its absence), and the assessor's initials and date.
6. Rank every gap high/medium/low by risk, with a one-line rationale.
7. Present the completed assessment to the sponsor, then to the governing body. The CCSO signs it.
8. Finish and date the assessment within 6 months of adoption - start in month one or two, not month five.

Worked example - Meridian Logistics

Meridian's CCSO and an external assessor spend six weeks (April-May) on the assessment. The workbook has 214 rows. Example row: "IRBC - incident response plan exists and is tested: Not met. Evidence: no plan found; IT manager confirms informal practice only; no test records. Assessed 22 Apr, JB/MK." Findings: 61 met, 88 partially met, 58 not met, 7 not applicable. Top gaps (high risk): no incident response plan, no leaver process for door cards, no data retention schedule, CCTV footage kept indefinitely, no security training. The assessment is signed by the CCSO on 30 May (month 2.5, well inside the 6-month clock) and presented to the board on 12 June.

Checklist

• Assessment workbook built from every applicable standard's requirements
• Maturity scale agreed (Met / Partially / Not met / N/A)
• Assessors paired; no self-assessment alone
• Every judgement evidenced by an artefact or interview note
• Gaps ranked high/medium/low with rationale
• Assessment signed by the CCSO and presented to the sponsor and governing body
• Completed and dated within 6 months of adoption

Records to keep

• The completed assessment workbook with evidence references, initials and dates
• Interview notes or summaries per process owner
• The signed assessment summary presented to the governing body
• The gap ranking with rationales

Common pitfalls

• Self-marking. The person responsible for a control should not be the only person judging it. Pair assessors.
• Policy-practice confusion. A written policy is not a working control. Test at least one instance of each critical control.
• Boiling the ocean. Do not re-engineer during assessment. Record the gap, rank it, move on.

Measures of success

A complete, dated, signed assessment exists; every judgement is evidenced; the sponsor can state the top five gaps without notes.

Play 4 - Build the implementation roadmap (Procedure Step 4)

Objective

Turn the ranked gap list into a costed, scheduled, owned plan that closes every gap within the 12-month implementation clock.

Step by step

1. Convert every gap into one or more actions, each with a single named owner - "security team" is not an owner.
2. Sequence by risk and dependency: foundations first (incident response basics, joiner/mover/leaver, asset visibility), then core controls, then refinements. The standard's indicative sequence (months 1-2 foundations, 3-4 core controls, 5-6 verification, 7-9 extension, 10-12 consolidation) is a guide, not separate binding deadlines.
3. Attach to every action: due date, cost estimate (even rough), and resourcing note.
4. Identify dependencies between actions and mark the critical path.
5. Plan to finish in month 10-11, leaving month 12 as contingency.
6. Present the roadmap to the sponsor, then the governing body, for approval - including the budget line. Approval without budget is decorative.
7. Review and re-date the roadmap at every quarterly review; record why dates move.

Worked example - Meridian Logistics

Meridian's roadmap has 47 actions. Examples: "A1 - Write and approve incident response plan. Owner: CCSO. Due: end month 3. Cost: internal time + 2 days external review (GBP 1,800)." "A9 - Implement leaver checklist covering IT accounts, door cards, keys and alarm codes. Owner: HR manager with IT manager. Due: end month 4. Cost: nil (process change)." "A23 - Set CCTV retention to 90 days with auto-deletion. Owner: facilities supervisor. Due: end month 5. Cost: nil." Total external cost estimate: GBP 14,000. The board approves the roadmap and budget on 12 June. The plan completes in month 11, leaving one month of contingency.

Checklist

• Every gap mapped to at least one action
• Every action has a named individual owner, a due date and a cost estimate
• Dependencies and critical path identified
• Plan finishes by month 10-11 with contingency
• Roadmap and budget approved by the governing body
• Roadmap reviewed and re-dated at each quarterly review, with reasons recorded

Records to keep

• The approved roadmap with owners, dates and costs
• The governing body's approval minute, including the budget line
• Each quarterly re-dating with recorded reasons
• Dependency/critical-path notes

Common pitfalls

• Hero schedules. A roadmap that assumes nobody is ever sick, on leave or pulled to an incident will fail. Add slack.
• Unfunded mandates. Approval of the roadmap must include approval of the budget line, or the approval is decorative.
• Plan worship. When reality diverges from the roadmap, change the roadmap at the next quarterly review and record why.

Measures of success

The governing body has approved the roadmap; every action is owned and dated; the plan finishes before the 12-month deadline with visible contingency.

Play 5 - Execute and gather evidence (Procedure Step 5)

Objective

Implement the controls, and - equally important - generate the evidence trail as you go.

Step by step

1. Stand up a weekly 30-minute stand-up of action owners; record attendance and status changes.
2. Adopt the rule "no control closes without its evidence". The evidence pack per control is: the control description, the operating record (log, register, ticket, minutes), and the name of the person operating it.
3. Where a control needs a tool, pilot on the highest-risk scope first; never let procurement consume the implementation clock.
4. Escalate any action that slips to the sponsor within one week of the slip.
5. Record every change to scope or roadmap, with the sponsor's approval.
6. Use the domain playbooks (GLA, RMA, TIA, IAM, DPP, IRBC, TRA) for detailed techniques within each domain.

Worked example - Meridian Logistics

The weekly stand-up runs every Tuesday, 09:00, 15 minutes by phone for site supervisors. When action A23 (CCTV retention) slips because the recorder's firmware will not support auto-deletion, the facilities supervisor raises it the same week; the sponsor approves a recorder replacement (GBP 900) within days instead of discovering the problem in month 11. The evidence pack for A9 (leaver checklist) contains: the checklist itself, three completed leaver tickets from June-August, and the HR manager's name as operator.

Checklist

• Weekly stand-up running with attendance recorded
• Each closed action has a complete evidence pack (description, operating record, operator)
• Slipping actions escalated to the sponsor within a week
• Tool pilots scoped to highest risk first
• Changes to scope or roadmap recorded and approved

Records to keep

• Stand-up notes (brief, dated)
• Evidence pack per closed control
• Escalation notes and sponsor decisions
• Change log for scope/roadmap changes

Common pitfalls

• Evidence retrofitting. Reconstructing evidence in month 11 produces artefacts that auditors distrust. Capture as you go.
• Tool-first thinking. Buying a platform before defining the control leads to the tool dictating the control. Define, then buy.
• Quiet failure. Create a culture where a red status is a request for help, not a confession.

Measures of success

Actions close on or before their dates; every closed action has a complete evidence pack; the sponsor hears about slippage within days, not months.

Play 6 - Metrics, review and reporting (Procedure Step 6; binding clock: quarterly reviews)

Objective

Give the governing body a truthful, regular picture of progress and residual risk.

Step by step

1. Diarise all four quarterly reviews at the start of the year - reviews that depend on someone remembering will slip.
2. Build a one-page dashboard: roadmap progress (percent of actions closed), top five residual risks, incidents and near-misses in the quarter, open exceptions with expiry dates, budget consumed versus plan.
3. Present the dashboard at each quarterly review; minute the meeting, including challenges and dissents.
4. Keep metrics few and honest: five the CCSO can defend beat fifty that cannot be explained. Prefer outcome metrics over activity metrics.
5. File every dashboard and minute in the evidence folder.

Worked example - Meridian Logistics

Meridian's Q3 dashboard shows: 34 of 47 actions closed; top residual risks (warehouse tailgating, unpatched telematics unit, single-person payroll); two near-misses (a reported phishing email, a propped-open fire door); one open exception (legacy alarm panel, expires month 10, compensating measure: weekly manual checks); budget GBP 9,200 of GBP 14,000 spent. The board minute records a challenge: "Why does telematics patching keep slipping?" - and the answer and action.

Checklist

• Four quarterly reviews diarised at year start
• One-page dashboard produced each quarter
• Reviews held and minuted every quarter without exception
• Minutes record challenges, not just approvals
• Dashboards and minutes filed

Records to keep

• Quarterly dashboards
• Review minutes including challenges and actions
• Updated residual-risk list each quarter

Common pitfalls

• Vanity metrics. "Number of training sessions held" is activity; "percentage of staff who completed and passed awareness training" is outcome. Prefer outcomes.
• Review drift. Quarterly reviews that slip to five-monthly become annual reviews, and the standard's clock is broken.

Measures of success

Four minuted reviews per year; the governing body can state current progress and top risks at any time.

Play 7 - Manage exceptions (Procedure Step 7; binding limits: CCSO up to 12 months; longer only via the Board Risk Committee on ERMC recommendation)

Objective

Handle unavoidable deviations from the standard transparently, time-boxed and at the right authority level.

Step by step

1. Create the exceptions register: columns for requirement affected, reason, compensating measures, expiry date, approver, approval date.
2. For each deviation, record it before or as it arises - never retrospectively.
3. Apply the authority limits exactly: the CCSO (or equivalent) approves exceptions up to 12 months; anything longer goes to the Board Risk Committee on the recommendation of the Enterprise Risk Management Committee.
4. Attach compensating measures to every exception. An exception without compensating measures is an uncontrolled risk.
5. Review the register at every quarterly review: close exceptions no longer needed; re-justify those still needed - never rubber-stamp.
6. Never split a long exception into serial short ones to stay under the CCSO's limit; that is concealment, not management.

Worked example - Meridian Logistics

Meridian's register has two entries. E1: "Legacy alarm panel at Warehouse South cannot log individual user codes. Compensating: panel code changed monthly, weekly supervisor check log. Expires month 10 (panel replacement in roadmap action A31). Approved: CCSO, 15 Jul." E2: "Payroll run by one person; segregation not possible until new hire. Compensating: monthly director review of payroll change report. Expires month 9. Approved: CCSO, 15 Jul." At the Q3 review, E2 is closed (new hire started); E1 is re-justified and kept until the panel is replaced.

Checklist

• Exceptions register exists with all required columns
• Every exception has compensating measures and an expiry date
• Authority limits respected (CCSO up to 12 months; Board Risk Committee beyond)
• Register reviewed at every quarterly review
• Closed exceptions marked with closure date and reason

Records to keep

• The exceptions register, current and historical
• Approval evidence per exception (who, when)
• Quarterly review notes showing re-justification or closure

Common pitfalls

• Permanent exceptions. An exception renewed three times without scrutiny is a policy change made by default. Force the governing body to confront it.
• Verbal exceptions. If it is not in the register, it does not exist - and the requirement is simply being breached.

Measures of success

Every deviation is registered, time-boxed, compensated and approved at the correct level; no exception survives review without re-justification.

Play 8 - Declare completion and move to steady state (Procedure Step 8)

Objective

Close the adoption cycle with a formal, evidenced declaration, and hand the controls over to business-as-usual operation.

Step by step

1. Run a final verification pass: for each requirement, confirm the control exists, operates, and has an evidence pack. Sample-test critical controls rather than trusting the register - pick five and test them end to end.
2. List any remaining gaps with their approved exceptions; do not hide them and do not wait for perfection.
3. Draft the completion declaration: scope covered, verification performed, open exceptions listed, signed by the CCSO and the sponsor.
4. Present the declaration to the governing body; minute its acceptance.
5. File the declaration with the adoption record.
6. Close the programme but start the steady-state calendar immediately: quarterly reviews, annual re-assessment, and each standard's own cycles (risk reviews, training cycles, access recertification) all keep running. Name the owner of the CSF after closure - usually the CCSO.

Worked example - Meridian Logistics

In month 11, the CCSO and external assessor verify all 214 requirements and sample-test five critical controls: they process a fictional leaver (accounts and door card dead within the day), restore a file from backup (14 minutes, inside the target), walk the warehouse perimeter, check the exceptions register, and review training completion (100%). The declaration, signed 4 February (month 11), lists one open exception (alarm panel, due for replacement in March). The board accepts it on 18 February. The steady-state calendar is diarised the same week: quarterly reviews in May, August, November, February; annual re-assessment the following March.

Checklist

• Final verification pass completed and documented
• Critical controls sample-tested end to end
• Open exceptions listed in the declaration
• Completion declaration signed by CCSO and sponsor
• Declaration presented to the governing body, accepted and filed
• Steady-state calendar diarised for the next 12 months
• Post-programme CSF owner named

Records to keep

• The verification pass results, including sample-test notes
• The signed completion declaration
• The governing body's acceptance minute
• The steady-state calendar

Common pitfalls

• Premature declaration. Declaring completion to hit the 12-month date, with unassessed gaps, converts a management problem into a misrepresentation problem.
• Programme hangover. Keep a named owner for the CSF after closure - usually the CCSO - or controls decay within a year.

Measures of success

A signed, filed declaration exists; the governing body accepted it; the steady-state calendar is running.

4. Quick reference: the first twelve months

5. Related documents

• GCSB-CSF-STRAT Converged Security Framework - Strategic Standards for Resilience, v2.0 (parent standard, sole normative source)
• GCSB-PRC-STRAT-001 Strategic Implementation Procedure (parent procedure)
• The other CSF standards and their procedures and playbooks, for domain detail

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