Arckit Risk

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"

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

   Read the template (with user override support):

   • First, check if .arckit/templates/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)

   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

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:

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] → Default to "OFFICIAL" (UK Gov) or "PUBLIC"

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

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)

• 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):

G. 4Ts Response Summary:

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

I. Action Plan:

Prioritized list of risk mitigation actions:

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