GCSB-GDL-IAM-001 Identity and Access Management Playbook

Document type: Guideline (advisory playbook) Parent procedure: GCSB-PRC-IAM-001 Identity and Access Management Procedure Parent standard: GCSB-ST-CSF-IAM-001 Identity and Access Management 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-IAM-001 in practice. Where this playbook and the parent standard or procedure differ, the standard and procedure prevail.

1. Purpose

The IAM standard governs the full identity lifecycle - joiners, movers, leavers - and access to both digital systems and physical spaces, converged. The parent procedure fixes the binding milestones, including the standard's month-by-month implementation milestones and periodic recertification. This playbook shows how to run identity and access as one converged 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

• One identity, one person, everywhere. The same person should not be "jsmith" in IT, "J. Smith" on the door system and an unlisted name on the alarm panel.
• Access is granted by role, removed by event. Joiner/mover/leaver events from HR drive access; ad-hoc grants are exceptions.
• Least privilege, converged. The minimum access needed - across systems AND spaces.
• Recertification is the control that keeps all others honest. Access only accumulates unless someone periodically removes it.

4. Scope and roles

This playbook applies to every organisation adopting GCSB-ST-CSF-IAM-001 through GCSB-PRC-IAM-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 identity register (Procedure Steps 1-2)

Objective

Create the single authoritative register of identities: staff, contractors, service accounts, and physical-access holders.

Step by step

1. Choose the authoritative source (usually HR) and document the choice.
2. Export the account lists from every system: IT accounts, email, door access, alarm codes, telematics, cloud services.
3. Reconcile each list against the authoritative source. Investigate every account or card that does not map to a current, entitled person.
4. Disable orphaned access immediately and record each removal.
5. Register non-human identities (service accounts, shared mailboxes, API keys), each with a named human owner.
6. Record for every identity: owner, status, access held (digital and physical), last review date.

Worked example - Meridian Logistics

Reconciliation in April finds: 118 HR records against 126 IT accounts (4 former employees, 2 test accounts, 2 shared accounts with no owner); the door system holds 134 active cards, including 9 belonging to leavers - one who left 14 months ago; the alarm panel has one shared code for everyone. All orphaned accounts and cards are disabled the same day and each removal logged. The shared alarm code is replaced with individual codes. The register opens with 118 people and 7 service identities, each with an owner.

Checklist

• Authoritative source chosen and documented
• Account/card/code lists exported from every system
• Reconciliation completed; every orphan investigated
• Orphaned access disabled and each removal logged
• Non-human identities registered with human owners
• Register fields complete (owner, status, access, review date)

Records to keep

• The reconciliation working papers (exports, match results)
• The removal log for orphaned access
• The identity register, dated
• Notes of any incidents discovered during reconciliation (e.g. access by leavers) and actions taken

Common pitfalls

• Reconciliation without removal. Finding orphaned accounts and not disabling them converts an audit into a liability list.
• Forgetting contractors and temps. They are the largest source of orphaned access.

Measures of success

Every live account and card maps to a current, entitled person or a registered service identity.

Play 2 - Build joiner-mover-leaver processes (Procedure Steps 3-5)

Objective

Automate or formalise the lifecycle so access follows role changes promptly.

Step by step

1. Define role profiles for common roles: the standard set of digital and physical access each role needs.
2. Joiners: access requested from the role profile before day one; physical and digital granted together; everything logged.
3. Movers: a role change triggers removal of the old role's access before the new role's is granted. Test this with real cases.
4. Leavers: same-day revocation as default, immediate for involuntary departures. The leaver checklist must be converged: IT accounts, email, door cards, keys, alarm codes, cloud accounts, third-party systems.
5. Where automation is unaffordable, run the process on a ticket checklist with a named operator - manual but reliable beats automated but broken.
6. Log every grant and revocation.

Worked example - Meridian Logistics

Meridian defines six role profiles (office, warehouse operative, warehouse supervisor, driver, finance, IT). The leaver checklist is a five-line ticket: disable IT account; disable email; deactivate door card; recover keys; remove alarm code. In July a warehouse operative leaves; the ticket closes all five items by 17:00 on the last day. A mover test in August: an operative promoted to supervisor - the old role's access is confirmed removed before supervisor access (including the restricted zone) is granted. The process is manual, ticket-based, and works.

Checklist

• Role profiles defined for common roles
• Joiner process grants digital and physical together, logged
• Mover process removes old access before granting new - tested with real cases
• Leaver checklist converged (IT, email, cards, keys, codes, third-party), same-day
• Named operator for the process
• Every grant and revocation logged

Records to keep

• Role profile definitions
• Joiner/mover/leaver tickets (completed checklists)
• Grant and revocation logs
• Mover-test evidence

Common pitfalls

• The mover gap. Pick five people who changed roles last year and check whether they still hold their old access.
• Leaver lag. "We'll disable it Friday" for a Monday departure is a four-day exposure.

Measures of success

Sampled movers hold only their current role's access; leaver access is dead on departure day.

Play 3 - Control privileged and physical access (Procedure Steps 6-8)

Objective

Apply the standard's tighter rules to privileged accounts and to physical zones.

Step by step

1. List all privileged accounts; separate them from daily-use accounts; assign individually (no shared "admin"); require strong authentication; log their use.
2. Review privileged accounts monthly (a local cadence the adopter sets proportionate to risk); record the review.
3. Define physical zones (public, office, restricted, critical) and map card access to role profiles.
4. Apply the same joiner-mover-leaver logic to physical access as to digital.
5. Build the converged view: for any person, show digital and physical access side by side.
6. Treat keys and cards as assets: record issue, return and loss in a register.

Worked example - Meridian Logistics

Meridian finds three people with shared knowledge of the server-room combination and a shared "admin" login on the order system. Both are replaced: individual admin accounts with strong authentication, and a server-room code changed quarterly with a named holder list. Physical zones: public (reception), office, restricted (warehouse floors), critical (server room, cash office). Card maps are aligned to role profiles; the converged view is a monthly spreadsheet join of the HR list, account list and card list. The key register records 34 keys; two unaccounted keys trigger a lock change at Warehouse North.

Checklist

• Privileged accounts separated, individual, strongly authenticated, logged
• Monthly privileged access review recorded
• Physical zones defined and mapped to role profiles
• Lifecycle applied equally to physical access
• Converged per-person access view produced
• Key/card register maintained; discrepancies resolved

Records to keep

• Privileged account list and monthly review records
• Zone definitions and role-to-zone maps
• Converged access views (dated)
• Key/card register with issue, return and loss entries

Common pitfalls

• Shared admin accounts. They destroy accountability. If a legacy system forces sharing, register an exception with compensating measures.
• Door-system drift. Card systems accumulate access even faster than IT. Include them in every review.

Measures of success

Every privileged action is attributable to one person; physical access matches role maps.

Play 4 - Recertify access periodically (Procedure Steps 4 and 6; cycle per the standard)

Objective

Run periodic recertification so access does not silently accumulate.

Step by step

1. Diarise the recertification cycle per the standard; name the coordinator.
2. Prepare reviewer packs: line managers see their team's access in plain language ("can read payroll files", "can enter the server room"); system owners confirm privileged and service accounts; facilities confirm physical zones.
3. Require an active decision per line: confirm or revoke. Silence defaults to revoke - "no reply means keep" is not recertification.
4. Execute revocations within days of the decision; log them.
5. Track completion as a metric; report to the committee. Incomplete recertification is a finding, not a footnote.

Worked example - Meridian Logistics

Meridian's first recertification (October) covers 118 people and 7 service identities over two weeks. Managers confirm 104 people unchanged; 11 need adjustments (mostly movers whose old access had already been fixed by the new process - evidence it works); 3 contractors are revoked as their engagements ended. Two managers do not respond by the deadline; their teams' non-essential access is suspended and restored only after explicit confirmation - the default-to-revoke rule holds. Completion: 100%, reported at the November committee.

Checklist

• Recertification cycle diarised per the standard; coordinator named
• Reviewer packs in plain language
• Active confirm/revoke per line; silence defaults to revoke, with safeguards for emergency access, service identities, egress and OT safety-critical access, which are never auto-revoked without a competent check
• Revocations executed within days and logged
• Completion metric reported to the committee

Records to keep

• Reviewer packs and returned decisions
• Revocation logs
• Completion metrics and committee reports
• Evidence the default-to-revoke rule was applied

Common pitfalls

• Rubber-stamping. Managers approving everything in one click. Show access in plain language so the decision is informed.
• Revocation lag. Confirmations arrive but revocations are never executed. Track both.

Measures of success

100% recertification completion; revoked access demonstrably removed.

Play 5 - Monitor, review and evidence (Procedure Steps 10-12)

Objective

Detect access anomalies, review the IAM programme, and keep the evidence trail.

Step by step

1. Define the alerts that matter: privilege escalation, dormant account use, failed-physical-access spikes, out-of-hours entry to critical zones.
2. Investigate every alert; record the outcome.
3. Review the IAM programme annually against the standard; feed findings into the risk register.
4. Keep the evidence: identity register, lifecycle logs, recertification records, review minutes - these are what the CSF assessment will examine.

Worked example - Meridian Logistics

An alert in December shows the Warehouse South alarm disarmed at 03:10 on a Sunday. Investigation: a supervisor responding to a freezer fault - legitimate, but it exposes that the freezer alarm routes only to a supplier, not to security. Fixed by dual-routing the alert. The annual IAM review in February records: lifecycle process working (evidence: mover tests), recertification at 100%, one improvement action (automate the HR-to-IT trigger when the HR system is replaced).

Checklist

• Access anomaly alerts defined and monitored
• Every alert investigated; outcome recorded
• Annual IAM programme review completed and minuted
• Findings fed into the risk register
• Evidence pack complete and retrievable

Records to keep

• Alert definitions and investigation records
• Annual review report and minutes
• The IAM evidence pack (register, logs, recertification records)

Common pitfalls

• Alert fatigue. Start with five alerts that always matter; expand only when those are handled well.

Measures of success

Anomalies are investigated; the annual review changes the programme; evidence survives an audit.

4. Quick reference

5. Related documents

• GCSB-ST-CSF-IAM-001 Identity and Access Management Standard, v2.0 (parent standard, sole normative source)
• GCSB-PRC-IAM-001 Identity and Access Management Procedure (parent procedure)
• GCSB-ST-CSF-TIA-001 (architecture dependencies) and GCSB-ST-CSF-DPP-001 (personal data in identity records)

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