GCSB-PRC-DPP-001 Data Protection and Privacy Procedure

Document control

1. Purpose

This procedure tells an adopting organisation exactly who does what, when and how to implement GCSB-ST-CSF-DPP-001. It converts the standard's data protection requirements (clauses 6.1 to 6.10) 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. Binding law always takes priority over this procedure.

2. Scope and applicability

This procedure applies to every organisation adopting the Data Protection and Privacy Standard. Full implementation is required within 12 months of certification commencement, with a 6-month gap assessment of existing systems. Existing lawful controls and binding legal obligations continue throughout transition; deferring privacy impact assessments, retention arrangements or individual rights handling until a later phase does not justify unlawful interim processing.

3. Roles

4. Procedure

Step 1 - Record the adoption and applicability (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 maintains an applicability register by jurisdiction, entity, sector and activity, treating UK GDPR, the Data Protection Act 2018, EU GDPR and member-state provisions, PECR, NIS2 implementing measures and DORA as distinct (clause 2.3). The 5 February 2026 commencement of UK data-subject rights timing and automated-decision reforms is addressed where applicable.

Record: adoption decision; applicability register.

Step 2 - Inventory, classification and data flows (Months 1-3)

1. The adopter documents entities, purposes, processing activities, personal data, individuals, locations, systems, recipients, suppliers, flows and dependencies in scope (clause 2.2); non-personal operational data is distinguished from identifiable or inferential personal data.
2. Processing inventories and accountable data-flow maps are maintained covering collection, use, recipients, storage, aggregation, transfer, recovery and disposal across scoped domains, updated for material changes (clause 6.1.1).
3. Classification supports consistent handling outcomes and preserves labels during transfer; special-category status is separately identified; public personal data remains regulated (clause 6.1.2).

Record: processing inventories; data-flow maps; classification scheme.

Step 3 - Lawfulness, transparency and purpose (Months 1-4)

1. Applicable lawful bases are recorded by purpose and activity, together with transparency, necessity, minimisation and accuracy measures (clause 6.2.1). An Article 9 condition, where required, is additional to the Article 6 basis.
2. Consent, where relied upon, is valid, evidenced, understandable and withdrawable without unnecessary friction; legitimate interests require an appropriate assessment and objection handling (clause 6.2.2).
3. Biometric and monitoring deployments address actual purpose, lawful basis, special-category conditions, worker rights, access, proportionality and alternatives; profiling and significant automated decisions follow the operative jurisdiction-specific rules (clause 6.2.3).

Record: lawful-basis register; consent records; legitimate-interest assessments.

Step 4 - Privacy impact assessment and design (Months 2-6, then per change)

1. Every change receives documented privacy screening before deployment (clause 6.3.1). Where law requires a DPIA, the controller completes it, seeks DPO advice where applicable and addresses prior consultation where residual legal high risk requires it.
2. Assessments address purposes, flows, aggregation and inference, necessity, proportionality, individual risks, mitigation, responsibility and rights, with competent security, physical, OT, safety, business, privacy and legal input (clause 6.3.2).
3. Design and defaults minimise collection, access, sharing and retention; pseudonymised data is not automatically treated as anonymous (clause 6.3.3).

Record: screening records; DPIAs; design decisions.

Step 5 - Architecture, encryption and keys (Months 3-9)

1. Architecture implements appropriate security, segregation, least privilege, authenticated interfaces, resilience and key lifecycle controls, proportionate and vendor-neutral (clause 6.4.1).
2. Cryptographic controls state purpose, profile, supported protocols, keys, owners, access, rotation, compromise response, escrow restrictions and sanitisation evidence; current, valid cryptographic and sanitisation profiles are used and reviewed regularly, taking account of the transition of FIPS 140-2 validations to historical status and of NIST SP 800-88 Rev. 2 (clause 6.4.2).
3. Backup and recovery protect personal data and keys and prevent erased or restricted data being silently restored into active processing (clause 6.4.3).

Record: architecture records; cryptographic profiles; backup safeguards.

Step 6 - Monitoring, DLP and analytics (Months 4-9)

1. Monitoring is justified, transparent where required, minimised, access-restricted and testable; logs do not indiscriminately collect credentials, tokens or unrelated personal content (clause 6.5.1).
2. Blocking and quarantine follow authorised rules, evidence and escalation, with OT safety, physical egress, critical-service continuity and safe fallback addressed (clause 6.5.2).
3. Analytics validate utility, limitations, error rates, drift, access and human authority (clause 6.5.3).

Record: monitoring justifications; DLP rules; analytics validation records.

Step 7 - Retention, holds and disposal (Months 3-9)

1. Retention is set by actual purpose, category, law, necessity and evidence, with owners and periodic review (clause 6.6.1).
2. Holds identify authority, scope, necessity, restricted access, review and expiry (clause 6.6.2).
3. Disposal coordinates active copies, recipients, caches, logs, archives and backups, with verification and restoration safeguards; no blanket postponement or indefinite retention is authorised (clause 6.6.3).

Record: retention schedule; hold register; disposal verification records.

Step 8 - Individual rights channel (Months 4-9, then standing)

1. The adopter provides a coordinated, accessible rights channel without requiring separate domain requests (clause 6.7.1).
2. Timing follows operative law with recorded receipt, identity verification, permitted clarification steps, legal pauses, extensions and notices (clause 6.7.2): under UK law, one month from the relevant time (the latest of receipt, permitted identity information and any permitted fee), extendable by two further months with notice within the first month, and a permitted Article 15 clarification pause; under EU GDPR, the ordinary response period runs from receipt with a necessary extension within the period set by applicable EU and Member State law.
3. Identity checks are necessary and proportionate; portability, rectification, objection and restriction follow the applicable tests (clause 6.7.3).

Record: rights channel; request log with statutory timing evidence.

Step 9 - Suppliers and international transfers (Months 4-9)

1. Processors receive applicable written processing terms covering instructions, confidentiality, security, subprocessors, assistance, audit evidence, incident and end-of-service obligations; joint controllers and independent controllers have their own appropriate arrangements (clause 6.8.1).
2. Controller choice of return or deletion, applicable legal storage requirements, backup safeguards and processor cooperation are scoped under operative law (clause 6.8.2).
3. Transfers are identified by actual exporting regime, recipient, access, location and mechanism; UK and EU adequacy, the IDTA and Addendum, standard contractual clauses, binding corporate rules and limited derogations are not treated as identical; framework status and eligible recipients are verified at the time of use (clauses 6.8.3, 6.8.4).

Record: processor terms; transfer register; transfer assessments.

Step 10 - Incidents, notification and recovery (Months 6-12, then standing)

1. Response distinguishes security suspicion or detection, actual legal awareness, personal-data breach assessment, internal command and statutory notifications; internal deadlines never postpone legal notifications (clause 6.9.1).
2. An authorised operational incident lead coordinates domain response and continuity with privacy and legal advice; incident types, operational severity and individual risk are different classifications (clause 6.9.2).
3. Controller regulator notice is without undue delay and, where feasible, within 72 hours of awareness unless the breach is unlikely to result in risk; processors notify controllers without undue delay; high-risk affected-person communication is without undue delay, subject to legal conditions; disproportionate effort triggers public or similarly effective communication, not silence (clause 6.9.3).
4. Recovery and testing align with the Incident Response and Business Continuity, Risk Management and Identity and Access Management standards (clause 6.9.4).

Record: breach assessment records; notification evidence; recovery test results.

Step 11 - Competence, records and assurance (Months 6-12, then recurring)

1. Personnel competence covers role-relevant law, classification, rights, handling, incidents, technology and privacy risks, with initial and refresher training appropriate to role (clause 6.10.1).
2. Evidence covers applicability, flows, lawful bases, transparency, impact assessment, architecture, access, monitoring, rights, retention, suppliers, transfers, incidents, training, exceptions and corrective actions (clause 6.10.2).
3. Independent assurance is distinguished from control operation and from GCSB recognition; reviews verify outcomes and corrective closure through lawful, minimised access (clause 6.10.3).

Record: training records; evidence register; assurance reports.

Step 12 - Gap assessment and completion (Months 6 and 12, binding)

1. The gap assessment of existing systems is completed within 6 months of certification commencement (clause 7).
2. The CCSO verifies every requirement of clauses 6.1 to 6.10 is implemented or covered by an approved exception, and signs the implementation completion declaration within 12 months.

Record: gap assessment; signed completion declaration.

Step 13 - Exceptions (as needed)

1. The CCSO may approve temporary exceptions up to 12 months; longer exceptions require approval by the Board Risk Committee on recommendation of the Enterprise Risk Management Committee; all exceptions are reviewed quarterly (clause 9).
2. Executive privacy delegation stays separate from independent DPO advice; no exception approval authority transfers to the DPO.
3. Each deviation documents requirement, scope, necessity, applicable law, risk, compensating controls, authority, duration, review, remediation and closure. Compensating controls never justify unmitigated unlawful processing.

Record: exception register with quarterly review dates.

5. Records and retention

All records named in this procedure are retained per the retention schedule established in Step 7 and applicable law. This procedure creates no alternative retention period.

6. Related documents

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

Revision history