GCSB-PRC-RMA-001 Risk Management and Assessment Procedure

Document control

1. Purpose

This procedure tells an adopting organisation exactly who does what, when and how to implement GCSB-ST-CSF-RMA-001. It converts the standard's risk management 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 Risk Management and Assessment Standard. Full implementation is required within 12 months of certification commencement, with a gap assessment of existing systems within 6 months. The standard's phased table applies: assessment and planning in months 1-3, technology integration in months 4-8, process integration in months 6-10, operational monitoring in months 9-12, full deployment within 12 months.

3. Roles

4. Procedure

Step 1 - Record the adoption and risk context (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 risk objectives, scope, criteria and ownership, connected to organisational strategy and approved risk appetite (clause 6.1.1). Criteria address safety, continuity, financial, confidentiality, integrity, privacy, physical and applicable legal consequences.
4. The adopter documents entities, services, facilities, systems, data, personnel, third parties and security domains in scope, with justification for exclusions (clause 2.2).

Record: adoption decision; risk context document; scope record.

Step 2 - Establish the unified risk register (Months 1-3)

1. The CCSO establishes the unified risk register covering scoped cyber, physical and OT risks and relevant identity, supplier, environmental and business dependencies (clause 6.2.1).
2. Each entry identifies scenario, affected objectives/assets/services, threats, exposures, existing controls, likelihood/impact method, uncertainty, residual exposure, owner, treatment and review evidence.
3. Each material risk receives an accountable owner with recorded evaluation, treatment decision, action owners, status and escalation route (clause 6.1.2).
4. Hybrid, systemic and cascading pathways, shared failure points and material dependencies are documented (clause 6.2.2); quantitative correlation is not represented as causal proof without justified analysis.

Record: unified risk register; dependency and cascade documentation.

Step 3 - Baseline assessment cycle (Months 1-3, then recurring)

1. Domain specialists complete the first unified risk assessment using a documented method aligned with ISO 31000 principles (clause 6.3.1); repeat at least annually, with event-driven reassessment on material change, incidents, new dependencies and control failure.
2. The CCSO schedules quarterly threat landscape analysis covering scoped domains and identity/supplier threats, with intelligence assessed for provenance, timeliness, relevance, reliability, lawful use and coverage (clause 6.3.2).
3. Assessment methods distinguish technical vulnerability severity (for example CVSS) from enterprise risk; treatment also considers asset criticality, exploitation, business and safety consequences, controls and uncertainty (clause 6.3.3).

Record: assessment reports; quarterly threat analyses.

Step 4 - Business impact and recovery interface (Months 2-4)

1. Business impact analyses are maintained for material scoped services and dependencies, including IT/OT integration, physical access, identity/federation failures, suppliers and shared security-platform outages (clause 6.4.1).
2. Recovery priorities, RTOs, RPOs and alternative operating arrangements are documented, approved against business impact and tested; specific values are indicative and confirmed by the adopter unless binding law sets them (clause 6.4.2).
3. Dependency and cascade containment strategies are documented and validated at least annually; exercises validate restoration integrity, operational safety and failure of shared coordination or identity services (clause 6.4.3).

Record: business impact analyses; approved RTO/RPO records; validation exercise reports.

Step 5 - Gap assessment (by Month 6, binding)

1. Domain leads assess existing systems against every requirement of clauses 6.1 to 6.10.
2. The CCSO consolidates findings into a gap register: gap, affected clause, risk rating, interim control, owner, target date.
3. The CCSO presents the gap register to the coordination committee.

Record: gap register; compatibility deliverables.

Step 6 - Treatment and coordinated controls (Months 4-10)

1. Coordinated treatment plans are documented across affected domains with risk owner, chosen response, control purpose, implementation owner, resources, target completion, validation and residual-risk decision (clause 6.5.1).
2. Treatments connect to applicable Technology, Identity, Data Protection and Incident Response requirements; controls are vendor-neutral and, where relevant, safety-qualified (clause 6.5.2).
3. Live OT safety and authorised change procedures are addressed before any control affecting operational technology is implemented (clause 6.5.3).

Record: treatment plans; control validation evidence.

Step 7 - Monitoring, measurement and analytics assurance (Months 6-12, then recurring)

1. Coordinated monitoring and risk-to-incident information exchange is maintained across scoped domains, with defined operating arrangements and safe fallback (clause 6.6.1).
2. Every coverage, availability, accuracy, latency and compliance indicator receives a defined eligible population, numerator/denominator, calculation, measurement window, evidence source, exclusions, target, owner and escalation (clause 6.6.2). No percentage measure authorises an unmet binding duty.
3. Where models support risk decisions, the adopter documents purpose, data provenance, assumptions, scope, limitations, validation, uncertainty and accountable human decision authority (clause 6.7.1); automated containment is bounded by authorised playbooks and recorded for review (clause 6.7.2).

Record: monitoring arrangements; metric definitions; model assurance records.

Step 8 - Identity, privacy and supplier risk (Months 4-9, then annual)

1. Identity risk assessment covers privileged access, lifecycle failures, federation trust, authentication disruption, credential compromise and identity-data dependencies, aligned with GCSB-ST-CSF-IAM-001 (clause 6.8.1).
2. Privacy assessment identifies actual controller/processor responsibilities, lawful bases, special-category conditions, necessity, rights, retention and transfer requirements (clause 6.8.2).
3. Critical security suppliers receive annual risk assessment with cyber and physical considerations; contracts address information exchange, incident cooperation, assessment rights and remediation (clause 6.8.3).

Record: identity risk assessments; privacy assessments; supplier reviews.

Step 9 - Escalation and continuity interface (Months 6-10)

1. Risk monitoring connects to documented incident triggers, response authority, cross-domain coordination and continuity procedures (clause 6.9.1). Hybrid/systemic/cascading classifications are kept separate from severity, with Level 1 response teams, Level 2 CCSO and Level 3 board-risk engagement.
2. Activation, detection, response and containment timescales for each level are documented as indicative values with explicit start and stop events, unless binding law sets a clock (clause 6.9.2). Urgent safety or containment action is never deferred until a board convenes.
3. External notifications follow applicable law, separately from internal escalation (clause 6.9.3).

Record: escalation matrix; notification procedures.

Step 10 - Competence and information control (Months 3-12, then recurring)

1. Competence is defined and evidenced for risk owners, analysts, specialists, committee personnel and incident teams, with practical assessment and corrective development (clause 6.10.1); the adopter defines and documents its own completion, pass rate, proficiency and annual update-hour targets (clause 6.10.2).
2. Risk records, models and evidence are classified, access-controlled, retained and disposed of under documented purpose and applicable law, with integrity, versioning and traceability maintained (clause 6.10.3).

Record: competence records; records management evidence.

Step 11 - Completion declaration (by Month 12, binding)

1. The CCSO verifies every requirement of clauses 6.1 to 6.10 is implemented or covered by an approved exception, and every binding period met.
2. The CCSO signs the implementation completion declaration and presents it to the governing body.
3. The organisation continues the recurring cycles in Steps 3, 7 and 8, with monthly progress reporting through coordination committees.

Record: signed completion declaration; governing-body minute.

Step 12 - Exceptions (as needed)

1. Every deviation is recorded with business justification, affected requirement, scoped risk/impact, compensating controls, owner, approval, duration, review and remediation (clause 9).
2. 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.
3. No exception waives binding law or confers a scheme entitlement; processing time or extension documentation does not create automatic approval.

Record: exception register with quarterly review dates.

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

Revision history