GCSB-GDL-DPP-001 Data Protection and Privacy Playbook

Document type: Guideline (advisory playbook) Parent procedure: GCSB-PRC-DPP-001 Data Protection and Privacy Procedure Parent standard: GCSB-ST-CSF-DPP-001 Data Protection and Privacy 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-DPP-001 in practice. Where this playbook and the parent standard or procedure differ, the standard and procedure prevail. This playbook is not legal advice; where law and this playbook interact, take advice from a qualified professional.

1. Purpose

The Data Protection and Privacy standard requires classification, handling, retention, protection and lawful processing of information - including personal data - across the converged estate. The parent procedure fixes the mandatory sequence and cycles. This playbook shows how to run data protection as a daily operational discipline, 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

• You cannot protect what you have not found. Data discovery precedes classification; classification precedes handling rules.
• Classification drives behaviour. A label that does not change how people store, share or destroy data is decoration.
• Privacy is a design property. Lawful basis, minimisation and retention are decided when a process is designed, not after a complaint.
• Converged data is still data. CCTV footage, access-control logs and visitor records are personal data and live under the same rules as databases.

4. Scope and roles

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

5. Traceability

Play 1 - Discover and inventory data (Procedure Steps 1-2)

Objective

Build the record of what data the organisation holds, where, and why.

Step by step

1. List the business processes (sales, operations, HR, finance, security operations).
2. For each process, record: what data it uses, where it lives, who can access it, why it is needed.
3. Explicitly sweep the converged sources: CCTV, access logs, visitor books, vehicle/ANPR records, incident reports, body-worn video. These are routinely forgotten and routinely personal data.
4. For each personal-data processing activity, record the lawful basis. "We might need it" is not a basis.
5. Record the retention period per data type.
6. Consolidate into the data inventory; name its owner and review date.

Worked example - Meridian Logistics

Meridian's inventory covers 9 processes and 34 data types. The converged sweep finds: CCTV at both warehouses (footage kept indefinitely - no retention set), door-access logs (kept indefinitely), a paper visitor book at head office (pages never removed), and driver telematics including location history (no documented basis). Lawful bases are recorded per activity: employee data under contract and legal obligation, as applicable; customer data under contract; CCTV under legitimate interest with a documented balancing note. The inventory is owned by the office manager, reviewed annually.

Checklist

• Process-based inventory completed
• Converged/physical sources swept and included
• Lawful basis recorded per personal-data processing activity
• Retention period recorded per data type
• Inventory owner and review date set

Records to keep

• The data inventory, dated
• Lawful-basis notes (including legitimate-interest balancing notes)
• The converged-source sweep notes

Common pitfalls

• System-only inventories. Listing databases misses the spreadsheets, email archives and camera footage where data actually accumulates.
• Copy-paste lawful bases. "Legitimate interest" applied to everything, without the balancing test, is a finding waiting to happen.

Measures of success

The organisation can answer, for any data type: where it is, why it is held, on what basis, and for how long.

Play 2 - Classify and label (Procedure Steps 2-4)

Objective

Apply the standard's classification scheme so handling rules can attach to data.

Step by step

1. Adopt a small scheme: three or four levels (e.g. Public / Internal / Confidential / Restricted) with one-line definitions and examples per level.
2. Classify at the container level where possible (this folder, this system, this cabinet) - people classify containers reliably, documents not.
3. Individually classify the high-value data sets (customer database, HR records, CCTV).
4. Attach a handling table to each level: storage, sharing, transmission, disposal. One page, printed, distributed.
5. Brief all staff; record the briefing.

Worked example - Meridian Logistics

Meridian adopts four levels. Examples agreed: Public - website content; Internal - rosters, process documents; Confidential - customer contracts, telematics history; Restricted - HR records, payroll, incident investigations. Containers classified: the HR system and the HR shared drive are Restricted; the operations drive is Internal; the customer database is Confidential. The one-page handling table says, among other things: Restricted is never emailed externally; Confidential leaves the building only encrypted; CCTV footage is Confidential and exported only by the CCSO. Briefing delivered at the June all-hands; attendance recorded.

Checklist

• Classification scheme adopted with examples
• Containers classified; high-value sets individually classified
• Handling table per level published (one page)
• Staff briefed; briefing recorded
• Sample check: sampled data correctly classified

Records to keep

• The classification scheme and handling table
• The container classification list
• Briefing records (date, attendance, material version)

Common pitfalls

• Over-classification. If everything is Confidential, nothing is. Challenge over-classification in review, but never impose a fixed quota; classify by actual sensitivity.
• Labels without teeth. If Confidential data can still be emailed anywhere, the scheme is cosmetic.

Measures of success

Sampled data is correctly classified; staff can state the handling rules for each level.

Play 3 - Apply protection controls (Procedure Steps 5-7)

Objective

Implement the technical and physical controls the standard requires for each classification level.

Step by step

1. Map controls to levels: encryption at rest for Confidential and above; encryption in transit for anything leaving the organisation's control; access via IAM roles per level; physical storage and destruction rules for paper and media.
2. Verify encryption system by system - "the vendor says it's encrypted" is not verification.
3. Wire classification levels into IAM: Restricted data reachable only by named roles, recertified on the IAM cycle.
4. Apply the rules to converged systems: CCTV and access logs get retention limits, access logging and a named owner, exactly like a database.
5. Register exceptions for systems that cannot meet the controls, with compensating measures.

Worked example - Meridian Logistics

Verification finds the customer database and HR system encrypted at rest; the file store encrypted after a configuration change; laptops encrypted via a device-management rollout completed in August (11 laptops done, evidence: management console report filed). The CCTV recorders cannot encrypt storage - registered as an exception with compensating measures (recorders in locked cabinets, network-segmented per the TIA playbook, 90-day retention). CCTV access is restricted to the CCSO and facilities supervisor, with an export log started.

Checklist

• Control map per classification level defined
• Encryption verified system by system, evidence filed
• Classification levels wired into IAM roles
• Converged systems under retention and access rules with named owners
• Exceptions registered with compensating measures

Records to keep

• The control map
• Encryption verification evidence per system
• IAM role mapping
• Exception register entries
• CCTV/log export logs

Common pitfalls

• Encryption assumed, not verified. Check each system.
• Forgotten paper. Organisations secure the database and leave the printed payroll report on a desk.

Measures of success

Controls per level are verified operating, including for physical and converged data.

Play 4 - Retention, disposal and rights handling (Procedure Steps 7-9)

Objective

Operate retention schedules, secure disposal, and responses to individuals exercising their rights.

Step by step

1. Publish the retention schedule: per data type, the period, the trigger (e.g. "6 years from end of employment"), and the disposal method.
2. Automate disposal where possible; where manual, run a diarised disposal cycle with a recorded log or certificate.
3. Define the rights-request process: who receives requests, the identity-check step, the response clock per applicable law, the record kept.
4. Rehearse the rights process once with a fictional request - the first real request should not be the first test.
5. Include converged data in rights responses: a subject access request can cover CCTV footage and access logs.

Worked example - Meridian Logistics

Meridian's schedule sets: CCTV 90 days (auto-deletion configured after the recorder replacement); door logs 12 months; visitor book pages removed monthly and shredded; employee files 6 years after employment ends; telematics history 13 months. The first disposal run in September destroys 14 boxes of legacy paper with a certificate filed. The rights process is rehearsed in October: a fictional driver requests "everything you hold on me"; the team produces HR file, telematics extracts, door logs and CCTV search within the clock, and records the rehearsal. Two real requests arrive the following spring and are answered in 9 and 12 days.

Checklist

• Retention schedule published and operating
• Disposal cycles diarised and run, with logs/certificates
• Rights-request process defined with identity check and clock
• Process rehearsed once with a fictional request
• Converged data included in rights responses

Records to keep

• The retention schedule
• Disposal logs and destruction certificates
• Rights-request log (request, identity check, response, dates)
• The rehearsal record

Common pitfalls

• Retention without disposal. Schedules that say when data may go but no process that actually deletes it.
• Clock surprise. Rights requests carry legal deadlines. Know yours before one arrives.

Measures of success

Disposal happens on schedule with records; a rehearsal rights request is answered within the clock.

Play 5 - Incidents, review and evidence (Procedure Steps 10-13)

Objective

Handle data breaches per the standard and the IRBC procedure, and keep the data-protection programme under review.

Step by step

1. Define what counts as a personal-data breach, who decides, and the notification clocks that apply; link directly to the incident response playbook.
2. Keep a breach register, including near-misses and breaches not requiring notification, with the reasoning recorded.
3. Decide the decision route in advance - the middle of a breach is the wrong time to design governance.
4. Review the programme annually: inventory currency, classification health, disposal records, rights performance, breach history.
5. Keep the evidence pack: inventory, schedule, disposal logs, rights records, breach register, review minutes.

Worked example - Meridian Logistics

In November, a misaddressed email sends one customer's delivery schedule to another customer. The CCSO classifies it as a minor breach: contained (recipient confirmed deletion), low harm, no notification required - reasoning recorded in the breach register. The near-miss section records a printed route sheet found in a cab; the fix is a cab-clear-out rule added to driver training. The annual review in February finds disposal running on schedule, classification healthy, and one action: extend the retention schedule to the new customer portal's data.

Checklist

• Breach definition, decision route and clocks documented
• Breach register maintained with reasoning, including near-misses
• Annual programme review completed and minuted
• Evidence pack complete and retrievable

Records to keep

• Breach register with reasoning per entry
• Annual review report and minutes
• The full data-protection evidence pack

Common pitfalls

• Notification paralysis. Decide the decision route in advance.

Measures of success

Breaches are handled within the clocks; the annual review demonstrably improves the programme.

4. Quick reference

5. Related documents

• GCSB-ST-CSF-DPP-001 Data Protection and Privacy Standard, v2.0 (parent standard, sole normative source)
• GCSB-PRC-DPP-001 Data Protection and Privacy Procedure (parent procedure)
• GCSB-ST-CSF-IRBC-001 (breach response) and GCSB-ST-CSF-IAM-001 (access to data)

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