Skip to main content

​
Overview

The /arckit.risk command creates a comprehensive risk register following the HM Treasury Orange Book 2023 risk management framework.

​
When to Use

  • Phase: Phase 3 - Risk Assessment
  • Timing: AFTER stakeholders, BEFORE business case
  • Purpose: Identify, assess, and manage project risks using Orange Book methodology

​
Command Usage

/arckit.risk <project ID or category>

​
Examples

# Create risk register for project
/arckit.risk 001

# Focus on specific category
/arckit.risk procurement risks

# Technology modernization context
/arckit.risk Create risk register for cloud migration

​
Orange Book Framework

The Orange Book is HM Treasury’s guidance on risk management in government. The 2023 update provides:
  • 5 Risk Management Principles: Governance, Integration, Collaboration, Risk Processes, Continual Improvement
  • Risk Control Framework: 4-pillar “house” structure
  • 4Ts Risk Response: Tolerate, Treat, Transfer, Terminate
  • Risk Assessment: Likelihood × Impact for Inherent and Residual risk
  • Risk Appetite: Amount of risk organization is prepared to accept

​
Risk Categories

Risks identified across 6 Orange Book categories:

​
STRATEGIC Risks

  • Risks to strategic objectives and organizational goals
  • Competitive position, market changes, policy changes
  • Stakeholder drivers under threat
Example: “Strategic direction changes mid-project”

​
OPERATIONAL Risks

  • Risks to operations, service delivery, business continuity
  • Resource availability, skills gaps, dependencies
  • Process failures, quality issues
Example: “Insufficient cloud migration expertise in team”

​
FINANCIAL Risks

  • Budget overruns, funding shortfalls, ROI not achieved
  • Cost escalation, currency fluctuations
  • Economic downturn impact
Example: “Cloud costs exceed budget by 40%“

​
COMPLIANCE/REGULATORY Risks

  • Non-compliance with laws, regulations, policies
  • Audit findings, regulatory penalties
  • Data protection (GDPR, DPA 2018), procurement rules
Example: “GDPR non-compliance due to data transfer”

​
REPUTATIONAL Risks

  • Damage to reputation, stakeholder confidence, public perception
  • Media scrutiny, parliamentary questions (UK Gov)
  • Service failures visible to public
Example: “High-profile service outage damages citizen trust”

​
TECHNOLOGY Risks

  • Technical failure, cyber security, legacy system issues
  • Vendor lock-in, technology obsolescence
  • Integration challenges, scalability limitations
Example: “Legacy integration fails during peak load”

​
Risk Assessment Methodology

​
Inherent Risk (BEFORE Controls)

Inherent Likelihood (1-5 scale):
  • 1 - Rare: < 5% probability, highly unlikely
  • 2 - Unlikely: 5-25% probability, could happen but probably won’t
  • 3 - Possible: 25-50% probability, reasonable chance
  • 4 - Likely: 50-75% probability, more likely to happen than not
  • 5 - Almost Certain: > 75% probability, expected to occur
Inherent Impact (1-5 scale):
  • 1 - Negligible: Minimal impact, easily absorbed, < 5% variance
  • 2 - Minor: Minor impact, manageable within reserves, 5-10% variance
  • 3 - Moderate: Significant impact, requires management effort, 10-20% variance
  • 4 - Major: Severe impact, threatens objectives, 20-40% variance
  • 5 - Catastrophic: Existential threat, project failure, > 40% variance
Inherent Risk Score: Likelihood × Impact (1-25)
  • 1-5: Low (Green)
  • 6-12: Medium (Yellow)
  • 13-19: High (Orange)
  • 20-25: Critical (Red)

​
Current Controls

  • Existing Controls: What controls are already in place?
  • Control Effectiveness: Weak | Adequate | Strong
  • Control Owners: Who maintains these controls?
  • Evidence of Effectiveness: How do we know controls work?

​
Residual Risk (AFTER Controls)

Residual Likelihood (1-5): Likelihood after controls applied
Residual Impact (1-5): Impact after controls applied
Residual Risk Score: Likelihood × Impact (after controls)

​
4Ts Risk Response Framework

Select ONE primary response for each risk:

​
TOLERATE

When to use: Low residual risk score (1-5), within appetite
Example: “Minor UI inconsistency - aesthetic only, no functional impact”
Accept the risk because cost of mitigation exceeds benefit

​
TREAT

When to use: Medium/High risk, can be reduced through actions
Example: “Implement automated testing to reduce defect risk”
Mitigate or reduce the risk through additional controls

​
TRANSFER

When to use: Low likelihood/high impact, can be insured or contracted out
Example: “Purchase cyber insurance for breach liability”
Transfer risk to 3rd party through insurance, outsourcing, or contracts

​
TERMINATE

When to use: High likelihood/high impact, exceeds appetite, cannot be mitigated
Example: “Cancel high-risk vendor contract, source alternative”
Stop the activity creating the risk

​
What It Creates

​
A. Executive Summary

  • Total risks identified (by category)
  • Risk profile distribution (Critical/High/Medium/Low)
  • Risks exceeding organizational appetite
  • Overall risk profile: Acceptable | Concerning | Unacceptable
  • Key risks requiring immediate attention (top 3-5)
  • Recommended actions and decisions needed

​
B. Risk Matrices (Inherent & Residual)

Two 5×5 matrices showing Likelihood (rows) × Impact (columns): Inherent Risk Matrix (before controls): 
                                IMPACT
          1-Minimal   2-Minor    3-Moderate   4-Major    5-Severe
       ┌───────────┬───────────┬───────────┬───────────┬───────────┐
5-     │           │           │   R-003   │   R-007   │   R-001   │
Almost │    5      │    10     │    15     │    20     │    25     │
       ├───────────┼───────────┼───────────┼───────────┼───────────┤
4-     │           │           │           │   R-009   │   R-004   │
Likely │    4      │    8      │    12     │    16     │    20     │
       └───────────┴───────────┴───────────┴───────────┴───────────┘
Residual Risk Matrix (after controls): Same format showing new positions

​
C. Top 10 Risks (by residual score)

Ranked table with:
  • Rank | ID | Title | Category | Residual Score | Owner | Status | Response

​
D. Detailed Risk Register

For each risk (R-001, R-002, etc.): Risk Identification:
  • Risk ID, Category, Title
  • Risk Description (2-3 sentences)
  • Root Cause
  • Trigger Events
  • Consequences if Realized
  • Affected Stakeholders (linked to STKE)
  • Related Objectives
Risk Assessment:
  • Inherent L/I/Score
  • Current Controls & Effectiveness
  • Residual L/I/Score
Risk Response:
  • 4Ts Response (Tolerate/Treat/Transfer/Terminate)
  • Risk Owner (from RACI matrix)
  • Action Owner
  • Escalation Path
Action Plan:
  • Additional Mitigations Needed
  • Specific Actions with owners
  • Target Date
  • Target Residual Risk
  • Success Criteria
Risk Status:
  • Open | In Progress | Monitoring | Closed | Accepted

​
E. Risk by Category Analysis

For each category:
  • Number of risks
  • Average inherent score
  • Average residual score
  • Effectiveness of controls (% reduction)
  • Key themes

​
F. Risk Ownership Matrix

Which stakeholder owns which risks (from RACI):
StakeholderOwned RisksCritical/High RisksNotes
CFOR-003, R-007, R-0121 Critical, 2 HighHeavy concentration of financial risks
CTOR-001, R-004, R-0092 CriticalTechnology risk owner

​
G. 4Ts Response Summary

ResponseCount%Key Examples
Tolerate5 risks25%R-006, R-010…
Treat12 risks60%R-001, R-002…
Transfer2 risks10%R-005 (insurance)
Terminate1 risk5%R-008 (cancel activity)

​
H. Risk Appetite Compliance

(If organizational appetite exists)
CategoryAppetite ThresholdRisks WithinRisks ExceedingAction Required
STRATEGICMedium (12)32Escalate to Board
FINANCIALLow (6)51CFO approval needed

​
I. Action Plan

Prioritized list of risk mitigation actions:
PriorityActionRisk(s) AddressedOwnerDue DateStatus
1Implement automated backupsR-001 (Critical)CTO2025-11-15In Progress
2Obtain cyber insuranceR-005 (High)CFO2025-12-01Not Started

​
J. Monitoring and Review Framework

  • Review Frequency: Monthly for Critical/High risks, Quarterly for Medium/Low
  • Escalation Criteria: Any risk increasing by 5+ points, any new Critical risk
  • Reporting Requirements:
    • Weekly: Critical risks to Steering Committee
    • Monthly: All risks to Project Board
    • Quarterly: Risk appetite compliance to Audit Committee
  • Next Review Date: [Date]
  • Risk Register Owner: [Name from stakeholder RACI]

​
K. Integration with SOBC

Note which sections of SOBC use this risk register:
  • Strategic Case: Strategic risks inform “Why Now?” and urgency
  • Economic Case: Risk-adjusted costs use financial risks + optimism bias
  • Management Case Part E: Full risk register feeds into risk management section
  • Recommendation: High risks may influence option selection

​
Traceability to Stakeholders

Every risk must link back to stakeholder analysis: 
Stakeholder: CFO (from ARC-{PROJECT_ID}-STKE-v*.md)
  → Concern: Budget overrun risk (from conflict analysis)
    → Risk R-003: Cloud costs exceed budget 40% (FINANCIAL, High)
      → Risk Owner: CFO (from RACI matrix - Accountable)
        → Action: Implement FinOps controls, monthly cost reviews
          → Success Criterion: Costs within 5% of budget monthly

​
UK Government Specific Risks

For UK Government/public sector projects: STRATEGIC:
  • Policy/ministerial direction change mid-project
  • Manifesto commitment not delivered
  • Machinery of government changes
COMPLIANCE/REGULATORY:
  • Spending controls (HMT approval delays)
  • NAO audit findings
  • PAC scrutiny and recommendations
  • FOI requests reveal sensitive information
  • Judicial review of procurement
REPUTATIONAL:
  • Parliamentary questions and media scrutiny
  • Citizen complaints and service failures
  • Social media backlash
  • Select Committee inquiry
OPERATIONAL:
  • GDS Service Assessment failure
  • CDDO digital spend control rejection
  • Civil service headcount restrictions
  • Security clearance delays

​
Output File

Creates: projects/{project}/ARC-{PROJECT_ID}-RISK-v1.0.md

​
Prerequisites

MANDATORY (command will warn if missing):
  • STKE (Stakeholder Analysis) - Every risk MUST have owner from RACI matrix
If stakeholder analysis doesn’t exist:
  • DO NOT proceed with risk register
  • Tell user: “Risk register requires stakeholder analysis to identify risk owners and affected parties. Please run /arckit.stakeholders first.”
RECOMMENDED (read if available):
  • PRIN (Architecture Principles) - Non-compliance creates risks
  • projects/000-global/risk-appetite.md - Risk appetite thresholds
  • REQ (Requirements) - Complex requirements create risks, NFRs mitigate risks

​
Quality Checks

Ensures Orange Book compliance:
  • ✅ Governance and Leadership: Risk owners assigned from senior stakeholders
  • ✅ Integration: Risks linked to objectives, stakeholders, and business case
  • ✅ Collaboration: Risks sourced from stakeholder concerns and expert judgment
  • ✅ Risk Processes: Systematic identification, assessment, response, monitoring
  • ✅ Continual Improvement: Review framework and action plan for ongoing management

​
Common Risk Patterns

​
Pattern 1: Technology Modernization

  • TECHNOLOGY: Legacy system failure during migration (High)
  • OPERATIONAL: Skills gap in new technology (Medium)
  • FINANCIAL: Cloud costs exceed estimates (Medium)
  • REPUTATIONAL: Service outage during cutover (High)

​
Pattern 2: New Digital Service

  • STRATEGIC: User adoption below target (High)
  • TECHNOLOGY: Scalability limitations at peak (High)
  • COMPLIANCE: GDPR/Accessibility non-compliance (Critical)
  • OPERATIONAL: Support team not ready for go-live (Medium)

​
Pattern 3: Vendor Procurement

  • FINANCIAL: Vendor pricing increases post-contract (Medium)
  • OPERATIONAL: Vendor delivery delays (Medium)
  • TECHNOLOGY: Vendor lock-in limits future options (High)
  • REPUTATIONAL: Vendor security breach affects reputation (High)

​
Next Steps

After creating risk register:
  1. Review with risk owners to validate assessment
  2. Escalate critical/high risks to Steering Committee
  3. Run /arckit.sobc and use risk register for Management Case Part E
  4. Implement priority actions from Action Plan
  5. Schedule monthly risk review meeting

Stakeholders

MANDATORY prerequisite for risk owners

Business Case

SOBC uses risk register in Management Case

Requirements

Risk-driven requirements and mitigations

Secure by Design

Validate security controls against risks

​
Example Outputs

Build docs developers (and LLMs) love

Get started for freeTalk to us