Arckit Risk

You are helping an enterprise architect create a comprehensive risk register following the UK Government Orange Book (2023) risk management framework.

About Orange Book Risk Management

The Orange Book is HM Treasury's guidance on risk management in government. The 2023 update provides:

• Part I: 5 Risk Management Principles (Governance, Integration, Collaboration, Risk Processes, Continual Improvement)
• Part II: Risk Control Framework (4-pillar "house" structure)
• 4Ts Risk Response Framework: Tolerate, Treat, Transfer, Terminate
• Risk Assessment Methodology: Likelihood × Impact for Inherent and Residual risk
• Risk Appetite: Amount of risk organization is prepared to accept/tolerate

User Input

$ARGUMENTS

Instructions

Note: Before generating, scan projects/ for existing project directories. For each project, list all ARC-*.md artifacts, check external/ for reference documents, and check 000-global/ for cross-project policies. If no external docs exist but they would improve output, ask the user.

This command creates a comprehensive risk register following HM Treasury Orange Book principles and integrates with ArcKit's stakeholder-driven workflow.

When to use this:

• After: $arckit-stakeholders (MANDATORY - every risk needs an owner)
• Before: $arckit-sobc (SOBC Management Case Part E uses risk register)
• Purpose: Identify, assess, and manage project risks using Orange Book methodology

1. Read existing artifacts from the project context:

   MANDATORY (warn if missing):

   • STKE (Stakeholder Analysis) — Extract: risk owners from RACI matrix, affected stakeholders, conflict analysis (conflicts ARE risks), stakeholder drivers (drivers under threat = strategic risks)
     • If missing: STOP and warn user to run $arckit-stakeholders first — every risk MUST have an owner

   RECOMMENDED (read if available, note if missing):

   • PRIN (Architecture Principles, in 000-global) — Extract: technology standards, compliance requirements — non-compliance creates risks
   • projects/000-global/risk-appetite.md — Extract: risk appetite thresholds for assessment calibration
   • REQ (Requirements) — Extract: complex requirements that create risks, NFRs that mitigate risks

   OPTIONAL (read if available, skip silently):

   • SOBC (Business Case) — Extract: financial risks, ROI assumptions at risk
   • DPIA (Data Protection Impact Assessment) — Extract: data protection risks, privacy risks

2. Understand the request: The user may be:

   • Creating initial risk register (most common)
   • Updating existing risk register with new risks
   • Reassessing risks after changes
   • Creating organizational risk appetite (advanced - if user asks for this specifically)

3. Read external documents and policies:

   • Read any global policies listed in the project context (000-global/policies/) — extract risk appetite, risk tolerance thresholds, threat landscape, industry benchmarks
   • Read any external documents listed in the project context (external/ files) — extract previous risk findings, mitigation effectiveness, residual risks, lessons learned
   • Read any enterprise standards in projects/000-global/external/ — extract enterprise risk frameworks, threat intelligence reports
   • If no external risk docs exist but they would improve the assessment, ask: "Do you have a risk appetite statement, previous risk assessments, or external threat reports? I can read PDFs directly. Place them in projects/000-global/policies/ and re-run, or skip."
   • Citation traceability: When referencing content from external documents, follow the citation instructions in .arckit/references/citation-instructions.md. Place inline citation markers (e.g., [PP-C1]) next to findings informed by source documents and populate the "External References" section in the template.

4. Determine project context:

   • If user mentions "UK Government", "public sector", "department", "ministry" → Include regulatory/parliamentary risks
   • If user mentions specific industry → Include industry-specific risk categories
   • Check stakeholder analysis for context on project scale, complexity, stakeholders

5. Read stakeholder analysis carefully:

   • Extract risk owners from RACI matrix (Accountable = Risk Owner)
   • Extract affected stakeholders (who cares about which risks?)
   • Extract stakeholder concerns from conflict analysis (these ARE risks!)
   • Extract stakeholder drivers (drivers under threat = strategic risks)
   • Note: EVERY risk MUST have a risk owner from stakeholder analysis

6. Identify risks across Orange Book categories:

   Use these risk categories aligned to Orange Book framework:

   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"

   Supplier-concentration risk (if procurement evidence exists): If a TNDR (Procurement Market Intelligence) or CMPT (Competitor Landscape) artefact exists at projects/{P}/research/ARC-{P}-{TNDR,CMPT}-*.md, read its Concentration section. If concentration_flag is HIGH (a single supplier holds > 50% of awarded value, or the top 3 hold > 80%), record a single-supplier-dependency / supplier-concentration risk under the dependencies category (OPERATIONAL), citing the notice-backed figures and supplier name. Carry the caveat that awarded value is not actual spend — it evidences market structure, not committed cost. If no such artefact exists, skip silently.

7. For EACH risk identified, create comprehensive risk profile:

   Read the template (with user override support):

   • First, check if .arckit/templates-custom/risk-register-template.md exists in the project root
   • If found: Read the user's customized template (user override takes precedence)
   • If not found: Read .arckit/templates/risk-register-template.md (default)
   • Then read .arckit/templates/_partials/RENDERING.md and resolve the <!-- DOC-CONTROL-HEADER --> marker in the template before writing. Do not hand-write the Document Control table: the partial RENDERING.md selects is the only source of the 14 standard fields and of the classification ladder.

   Tip: Users can customize templates with $arckit-customize risk-register

   Populate the template with:

   Risk Identification:

   • Risk ID: R-001, R-002, R-003, etc. (sequential)
   • Category: STRATEGIC | OPERATIONAL | FINANCIAL | COMPLIANCE | REPUTATIONAL | TECHNOLOGY
   • Risk Title: Short, clear description (5-10 words)
   • Risk Description: Detailed description of the risk (2-3 sentences)
   • Root Cause: What underlying issue creates this risk?
   • Trigger Events: What events would cause this risk to materialize?
   • Consequences if Realized: What happens if this risk occurs? (tangible impacts)
   • Affected Stakeholders: Link to ARC-{PROJECT_ID}-STKE-v*.md (who is impacted?)
   • Related Objectives: Link to stakeholder goals/business objectives that are threatened

   Inherent Risk Assessment (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 and Mitigations:

   • 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 Assessment (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)

   Risk Response (4Ts Framework):

   Select ONE primary response:

   • TOLERATE: Accept the risk (within risk appetite, cost of mitigation exceeds benefit)

     • When to use: Low residual risk score (1-5), within appetite
     • Example: "Minor UI inconsistency - aesthetic only, no functional impact"

   • TREAT: Mitigate or reduce the risk (implement additional controls)

     • When to use: Medium/High risk, can be reduced through actions
     • Example: "Implement automated testing to reduce defect risk"

   • TRANSFER: Transfer risk to 3rd party (insurance, outsourcing, contracts)

     • When to use: Low likelihood/high impact, can be insured or contracted out
     • Example: "Purchase cyber insurance for breach liability"

   • TERMINATE: Stop the activity creating the risk

     • When to use: High likelihood/high impact, exceeds appetite, cannot be mitigated
     • Example: "Cancel high-risk vendor contract, source alternative"

   Risk Ownership:

   • Risk Owner: From stakeholder RACI matrix (Accountable role = Risk Owner)
   • Action Owner: Responsible for implementing mitigations
   • Escalation Path: Who to escalate to if risk materializes?

   Action Plan:

   • Additional Mitigations Needed: What else should we do?
   • Specific Actions: Concrete steps with owners
   • Target Date: When will mitigations be in place?
   • Target Residual Risk: What score are we aiming for after mitigations?
   • Success Criteria: How will we know mitigations are effective?

   Risk Status:

   • Open: Newly identified, not yet addressed
   • In Progress: Mitigations underway
   • Monitoring: Mitigations in place, monitoring effectiveness
   • Closed: Risk no longer applicable
   • Accepted: Risk tolerated within appetite

   Risk Appetite Assessment (if organizational appetite exists):

   • Risk Appetite Threshold: What's the appetite for this category?
   • Assessment: Within Appetite | Exceeds Appetite | Significantly Exceeds Appetite
   • Justification: Why is this acceptable/not acceptable?
   • Escalation Required: Yes/No (if exceeds appetite)

8. Generate comprehensive risk register with these sections:

   A. Executive Summary:

   • Total risks identified (by category)
   • Risk profile distribution:
     • Critical risks (score 20-25): X risks
     • High risks (score 13-19): Y risks
     • Medium risks (score 6-12): Z risks
     • Low risks (score 1-5): W risks
   • Risks exceeding organizational appetite: N risks
   • Overall risk profile: Acceptable | Concerning | Unacceptable
   • Key risks requiring immediate attention (top 3-5)
   • Recommended actions and decisions needed

   B. Risk Matrix Visualization (using ASCII 5×5 matrix):

   Create 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-Almost   │           │           │   R-003   │   R-007   │   R-001   │
   Certain    │    5      │    10     │    15     │    20     │    25     │
              ├───────────┼───────────┼───────────┼───────────┼───────────┤
   4-Likely   │           │           │           │   R-009   │   R-004   │
              │    4      │    8      │    12     │    16     │    20     │
   L          ├───────────┼───────────┼───────────┼───────────┼───────────┤
   I 3-Possible│          │           │   R-002   │           │           │
   K          │    3      │    6      │    9      │    12     │    15     │
   ...        └───────────┴───────────┴───────────┴───────────┴───────────┘
   
   Legend: Critical (20-25)  High (13-19)  Medium (6-12)  Low (1-5)
   

   Residual Risk Matrix (after controls): Same format showing new positions

   Show movement: "R-001 moved from Critical (25) to Medium (6) after controls"

   C. Top 10 Risks (by residual score):

   Ranked table:

   Rank	ID	Title	Category	Residual Score	Owner	Status	Response
   1	R-001	...	STRATEGIC	20	CEO	In Progress	Treat

   D. Risk Register (detailed table):

   Full table with columns:

   • Risk ID
   • Category
   • Title
   • Description
   • Inherent L/I/Score
   • Controls
   • Residual L/I/Score
   • 4Ts Response
   • Owner
   • Status
   • Actions
   • Target Date

   E. Risk by Category Analysis:

   For each category (STRATEGIC, OPERATIONAL, etc.):

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

   F. Risk Ownership Matrix:

   Show which stakeholder owns which risks (from RACI):

   Stakeholder	Owned Risks	Critical/High Risks	Notes
   CFO	R-003, R-007, R-012	1 Critical, 2 High	Heavy concentration of financial risks
   CTO	R-001, R-004, R-009	2 Critical	Technology risk owner

   G. 4Ts Response Summary:

   Response	Count	%	Key Examples
   Tolerate	5 risks	25%	R-006, R-010...
   Treat	12 risks	60%	R-001, R-002...
   Transfer	2 risks	10%	R-005 (insurance)
   Terminate	1 risk	5%	R-008 (cancel activity)

   H. Risk Appetite Compliance (if organizational appetite exists):

   Category	Appetite Threshold	Risks Within	Risks Exceeding	Action Required
   STRATEGIC	Medium (12)	3	2	Escalate to Board
   FINANCIAL	Low (6)	5	1	CFO approval needed

   I. Action Plan:

   Prioritized list of risk mitigation actions:

   Priority	Action	Risk(s) Addressed	Owner	Due Date	Status
   1	Implement automated backups	R-001 (Critical)	CTO	2025-11-15	In Progress
   2	Obtain cyber insurance	R-005 (High)	CFO	2025-12-01	Not 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

9. Ensure complete 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
   

10. Flag risks that need escalation:

Identify risks that require immediate action:

• Critical risks (score 20-25): Escalate to steering committee immediately
• Risks exceeding appetite: Escalate to risk owner + approval authority
• Increasing risk trends: Risks getting worse over time
• Unmitigated high risks: High risks with no treatment plan

11. Write the output:

    Before writing the file, read .arckit/references/quality-checklist.md and verify all Common Checks plus the RISK per-type checks pass. Fix any failures before proceeding.

    • Create or update projects/NNN-project-name/ARC-{PROJECT_ID}-RISK-v1.0.md
    • Use project directory structure (create if doesn't exist)
    • File name pattern: ARC-{PROJECT_ID}-RISK-v{VERSION}.md
    • Update date and version in header

IMPORTANT - Auto-Populate Document Information Fields:

Before completing the document, populate document information fields:

Auto-populated fields

• [PROJECT_ID] → Extract from project path (e.g., "001")
• [VERSION] → Start with "1.0" for new documents
• [DATE] / [YYYY-MM-DD] → Current date in YYYY-MM-DD format
• [DOCUMENT_TYPE_NAME] → Document purpose
• ARC-[PROJECT_ID]-RISK-v[VERSION] → Generated document ID
• [STATUS] → "DRAFT" for new documents
• Classification → comes from the resolved Document Control header, not from a placeholder. _partials/RENDERING.md fixes the ladder from the artefact's own regime; ${default_classification} applies only where that regime falls through to user config.

User-provided fields

• [PROJECT_NAME] → Full project name
• [OWNER_NAME_AND_ROLE] → Document owner

Revision History

| 1.0 | {DATE} | ArcKit AI | Initial creation from `$arckit-risk` command |

Generation Metadata Footer

**Generated by**: ArcKit `$arckit-risk` command
**Generated on**: {DATE}
**ArcKit Version**: {ARCKIT_VERSION}
**Project**: {PROJECT_NAME} (Project {PROJECT_ID})
**AI Model**: [Actual model name]

Output Format

Provide:

1. Location: projects/NNN-project-name/ARC-{PROJECT_ID}-RISK-v1.0.md
2. Summary:
   • "Created comprehensive risk register following HM Treasury Orange Book"
   • "Identified [X] risks across 6 categories"
   • "Risk profile: [X] Critical, [Y] High, [Z] Medium, [W] Low"
   • "Overall residual risk score: [X]/500 ([Y]% reduction from inherent)"
   • "All [X] risks have owners from stakeholder RACI matrix"
   • "[N] risks require immediate escalation (exceed appetite or critical)"
3. Top 3 Risks:
   • "1. R-001 (STRATEGIC, Critical 20): [Title] - Owner: [Name]"
   • "2. R-002 (TECHNOLOGY, High 16): [Title] - Owner: [Name]"
   • "3. R-003 (FINANCIAL, High 15): [Title] - Owner: [Name]"
4. 4Ts Distribution:
   • "Tolerate: X% | Treat: Y% | Transfer: Z% | Terminate: W%"
5. Next steps:
   • "Review with [Risk Owners] to validate assessment"
   • "Escalate [N] critical/high risks to Steering Committee"
   • "Use risk register for SOBC Management Case Part E"
   • "Implement priority actions from Action Plan"
   • "Schedule monthly risk review meeting"

Orange Book Compliance Checklist

Ensure the risk register demonstrates 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)

UK Government Specific Risks

For UK Government/public sector projects, include:

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

Error Handling

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."

If risks are very high/critical:

• Flag explicitly: "⚠️ WARNING: [N] Critical risks (score 20-25) identified. Immediate escalation required. Consider if project should proceed."

If all risks exceed appetite:

• Flag: "⚠️ WARNING: Project risk profile significantly exceeds organizational appetite. Senior approval required to proceed."

Template Reference

Use the template at .arckit/templates/risk-register-template.md as the structure. Fill in with:

• Stakeholder analysis data (owners, affected parties, concerns)
• Architecture principles (non-compliance risks)
• Organizational risk appetite (if exists)
• User's project description
• Industry/sector specific risks
• UK Government risks (if applicable)

Generate a comprehensive, Orange Book-compliant risk register that enables informed decision-making and effective risk management.

Important Notes

• Markdown escaping: When writing less-than or greater-than comparisons, always include a space after < or > (e.g., < 3 seconds, > 99.9% uptime) to prevent markdown renderers from interpreting them as HTML tags or emoji

Suggested Next Steps

After completing this command, consider running:

• $arckit-sobc -- Feed risk register into SOBC Management Case
• $arckit-requirements -- Create risk-driven requirements
• $arckit-secure -- Validate security controls against risks
• $arckit-tenders -- Ground supplier-concentration risk in real UK procurement award data (when UK government procurement context)