GCSB-PRC-IAM-001 Identity and Access Management Procedure

Document control

1. Purpose

This procedure tells an adopting organisation exactly who does what, when and how to implement GCSB-ST-CSF-IAM-001. It converts the standard's identity 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.

2. Scope and applicability

This procedure applies to every organisation adopting the Identity and Access Management Standard. Full implementation is required within 12 months of certification commencement, with a gap assessment of existing systems within 6 months. The standard's milestone table applies: initial assessment within 60 days; gap analysis, roadmap and governance within 90 days; identity provider in place by month 4; MFA for privileged accounts by month 5; role-based access and HR integration by month 6; privileged access management by month 7; risk-based authentication by month 8; physical access and federation by month 9; monitoring by month 10; testing and training by month 11; full implementation by month 12. Reports run monthly to the CCSO, quarterly to the Enterprise Risk Management Committee, and a GCSB progress report every 90 days. Cutover approval is required at least 30 days before cutover.

3. Roles

4. Procedure

Step 1 - Record the adoption and scope (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 documents organisational entities, users, workforce and external identities, service/workload identities, facilities, systems, resources, security domains and material identity dependencies, distinguishing human authentication, machine access and physical entry (clause 2.2). An absent OT estate is explained, not invented.

Record: adoption decision; identity scope record.

Step 2 - Initial assessment and governance (Days 1-90)

1. The adopter completes the initial assessment within 60 days of certification commencement (clause 7).
2. The CCSO establishes the Cross-Domain IAM Governance Committee with competent domain, risk, legal/compliance, HR and business representation, meeting monthly with recorded decisions and monthly reporting to the CCSO (clause 5.2).
3. The committee issues a monthly report to the CCSO, a quarterly report to the Enterprise Risk Management Committee and a GCSB progress report every 90 days, each recording scope, milestones, exceptions, risks and evidence status.
4. The gap analysis, roadmap and governance arrangements are completed within 90 days (clause 7).

Record: initial assessment; committee records; gap analysis and roadmap.

Step 3 - Identity architecture and authoritative sources (Months 1-4)

1. Identity/resource inventories, architecture, data flows, trust boundaries, dependencies and accountable owners are maintained, covering scoped human, third-party and machine identities (clause 6.1.1).
2. Authoritative sources and reconciled identity mappings are documented with conflict handling and privacy controls; the identity platform architecture, identifier strategy and provisioning model are defined and documented (clause 6.1.2). A shared identifier does not confer access automatically.
3. Platform support, integration coverage, capacity and performance targets are defined proportionate to scale (clause 6.1.3).
4. The identity provider is in place by month 4 (clause 7).

Record: identity inventory; architecture records; IdP deployment evidence.

Step 4 - Lifecycle control (Months 3-6)

1. Provisioning and changes follow authoritative triggers, business justification, role/segregation checks, appropriate approvals and recorded evidence; emergency or manual provisioning is validated promptly (clause 6.2.1).
2. Lifecycle timing distinguishes request approval, completed provisioning, attribute propagation, access suspension and detailed deprovisioning; the adopter defines and documents its own timeframes proportionate to risk (clause 6.2.2).
3. Planned-departure preparation is bounded by actual notice availability; leave and role changes receive lawful, need-based decisions distinct from termination (clause 6.2.3).
4. Cross-domain consistency is validated with failure alerts, reconciliation and safe remediation; automated rollback never silently restores revoked access or compromises emergency egress or OT safety (clause 6.2.4).
5. Role-based access and HR integration are complete by month 6 (clause 7).

Record: lifecycle procedures; provisioning evidence; reconciliation reports.

Step 5 - Authentication and credential protection (Months 4-8)

1. Documented assurance and MFA controls are established for resources and users, distinguishing factor categories and authenticator assurance, with phishing resistance evidenced where required and safe treatment of legacy, OT and emergency interfaces (clause 6.3.1). MFA for privileged accounts is in place by month 5 (clause 7).
2. Authentication addresses binding, recovery, compromise, rate limits and sessions; the password and credential policy follows current NIST SP 800-63B guidance or an equivalent current standard the adopter selects and documents (clause 6.3.2).
3. Session, assertion and token lifetimes are defined coherently by service and protocol capability (clause 6.3.3).
4. Biometric deployment addresses lawful basis, special-category conditions, necessity, accessible alternatives, template protection and presentation-attack resistance (clause 6.3.4).
5. Risk-based authentication is in place by month 8 (clause 7).

Record: authentication policy; MFA deployment evidence; biometric assessments.

Step 6 - Authorisation, roles and privileged access (Months 5-7)

1. Access decisions enforce least privilege, documented business need, role boundaries and segregation of conflicting duties, with explicit emergency and small-estate safeguards (clause 6.4.1).
2. Elevated access is approved, bounded, logged and revoked; standard, emergency and recovery-token access periods are defined and documented; annual role revalidation and dormant-role revocation are scoped safely (clause 6.4.2).
3. Reviews are owner-performed with remediation evidence; review frequencies for standard, privileged and critical access are defined and documented proportionate to risk (clause 6.4.3).
4. Privileged identities have inventory, individual accountability, approved use, protected credentials, session oversight, separation of approval from use and monitored third-party access; no self-approval is permitted (clause 6.5.1).
5. Privileged access management, including vaulting, encryption, rotation, session oversight and monitoring, is implemented proportionate to risk by month 7 (clauses 6.5.2, 7).
6. Break-glass access remains bounded and traceable, with prompt notification to accountable roles, timely review and restoration (clause 6.5.3).

Record: role model; access review evidence; PAM deployment records; break-glass log.

Step 7 - Federation and secure integration (Months 7-9)

1. Federation defines trust, actual assurance, accepted assertions, attribute purpose and minimisation, signatures, audiences, replay handling, expiry, revocation capabilities, keys and agreement responsibilities; external providers receive periodic risk and security review (clause 6.6.1).
2. Provisioning, authentication and authorisation protocols are selected for their actual functions and current versions; logs do not collect passwords, tokens or excessive personal data (clause 6.6.2).
3. Integrations are tested before production with compatibility validated periodically; safe change, rollback, failover, partial-failure behaviour and dependency recovery are documented (clause 6.6.3).
4. Physical access and federation are complete by month 9, with high-risk systems compliant (clause 7).

Record: federation agreements; integration test results.

Step 8 - Monitoring, analytics and incident response (Months 9-10)

1. Relevant identity events are monitored and correlated across scoped domains with lawful evidence, restricted access, validated alerts, incident authority and investigation records; identity risks are assessed at least annually and registers updated quarterly or on material change (clause 6.7.1).
2. Where analytics or AI/ML tooling is used, representative data, model limitations, drift, uncertainty, error rates and accountable human authority are addressed (clause 6.7.2).
3. Incident handling distinguishes incident type, category and impact severity; immediate suspension and automated quarantine are authorised, safety-aware and linked to continuity; risk-ranked remediation timeframes are defined and documented (clause 6.7.3).
4. Monitoring is operational by month 10 (clause 7).

Record: monitoring configuration; identity risk register; incident records.

Step 9 - Privacy, retention and resilience (Months 6-11)

1. Actual controller/processor responsibilities, lawful bases, special-category conditions, transparency, rights, contracts and privacy safeguards are documented (clause 6.8.1).
2. Records receive sensitivity-appropriate classification, integrity, access, purpose-based retention and validated disposal; deletion from backups, logs and distributed stores follows a feasible disposal, isolation, lawful-hold and restoration process (clause 6.8.2).
3. International transfers use applicable UK and EU transfer mechanisms selected from those lawful at the time (clause 6.8.3); breach assessment distinguishes controller-to-regulator, processor-to-controller and affected-person communication, and cross-domain investigation complexity does not extend a binding statutory clock (clause 6.8.4).
4. Identity recovery is based on documented business impact, safety, dependencies, recovery order and restored integrity, with RTOs, RPOs, offline capacity and failover defined proportionate to criticality (clause 6.9.1); recovery exercises are conducted periodically with corrective actions tracked to closure (clause 6.9.2).
5. Zero-trust and dynamic access changes address device/resource capability, safety/egress, authorised maintenance and offline continuity; automatic quarantine and continuous authentication in OT are applied only where safe (clause 6.9.3).

Record: privacy records; retention schedule; recovery exercise reports.

Step 10 - Competence, suppliers and evidence (Months 9-11)

1. Role-based competence and training address identity operations, privacy, cross-domain risks, response and recovery, aligned with GCSB-ST-CSF-TRA-001 (clause 6.10.1); periodic exercises, content updates and post-incident refreshers are conducted (clause 6.10.2).
2. Supplier verification, sponsorship, expiry, risk assessment, periodic reviews, integration tests and lawful agreements are evidenced (clause 6.10.3).
3. Evidence supports identity scope, architecture, access decisions, lifecycle events, reviews, privileges, federation, risks, monitoring, recovery, training, suppliers, exceptions and corrective actions; metric definitions separate authentication success, service availability, record accuracy, workflow compliance and statutory compliance (clause 6.10.4).
4. Testing and training are complete by month 11 (clause 7).

Record: training records; supplier files; evidence register.

Step 11 - Cutover and completion (by Month 12, binding)

1. Cutover approval is obtained at least 30 days before cutover (clause 7).
2. The CCSO verifies every requirement of clauses 6.1 to 6.10 is implemented or covered by an approved exception, and every milestone met.
3. The CCSO signs the implementation completion declaration and presents it to the governing body.

Record: cutover approval; signed completion declaration.

Step 12 - Exceptions (as needed)

1. The CCSO may approve temporary exceptions up to 12 months; longer exceptions only by the Board Risk Committee on recommendation of the Enterprise Risk Management Committee; all exceptions are reviewed quarterly (clause 9).
2. The CCSO may delegate in writing the approval of exceptions of up to 30 days to IT managers, with each delegation recorded, time-bounded and reviewed quarterly; the CCSO remains accountable for every delegated approval.
3. Exceptions affecting MFA for privileged accounts and other critical controls are differentiated from ordinary exceptions by activity and risk. Each exception records requirement, necessity, affected scope and population, risk, compensating controls, authority, duration, monitoring, remediation and closure evidence, with a fresh risk assessment on renewal. Processing time does not create automatic approval.

Record: exception register; delegation records; quarterly reviews.

5. Records and retention

All records named in this procedure are retained for the period set by the adopter's records policy and the standard's evidence duties, whichever is longer. This procedure creates no alternative retention period.

6. Related documents

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

Revision history