12-risk-analysis

name	12-risk-analysis
description	Use when producing or reviewing the 12 risk analysis component of a business plan; applies its specialist evidence, decisions, and acceptance tests instead of neighbouring pipeline skills.
metadata	{"portable":true,"compatible_with":["claude-code","codex"]}

Risk Analysis & Mitigation Skill

Overview

Generate Section 12 of the business plan: the risk analysis. Use this skill to surface the risks that actually matter, assess their implications honestly, and show that management has credible mitigation logic.

Use When

• Use when drafting or revising the risk analysis section for lenders, investors, grant funders, or internal review.
• Use when the business needs a transparent assessment of market, operational, financial, regulatory, or team risk.
• Use when mitigation and contingency planning are material to credibility.

Do Not Use When

• Do not use to produce a cosmetic risk table that avoids the real vulnerabilities.
• Do not bury severe risks behind vague language or optimistic tone.
• Do not present mitigation steps that the business cannot execute.

Required Inputs

• Core business model, funding logic, implementation plan, and operating assumptions
• Country, sector, and regulatory context shaping the main risk environment
• Known dependencies on people, suppliers, technology, licences, or external markets
• Adjacent plan sections whose claims create or mitigate material risks

Workflow

1. Identify the major risk categories from the actual business model and context.
2. Prioritise the highest-consequence and highest-likelihood risks.
3. State mitigation actions, contingencies, and ownership clearly.
4. Check that risk treatment aligns with implementation, operations, and funding capacity.
5. Reconcile the risk section with projections, compliance, and team realities.
6. Flag residual risks that should remain visible to the reader.

Quality Bar

• The section identifies the real threats to viability rather than generic business risks.
• Likelihood, impact, and mitigation logic are proportionate and believable.
• Risk language builds confidence through honesty, not through denial.
• Material residual risks remain explicit.

Anti-Patterns

• Risk registers full of low-signal generic items.
• Claiming strong mitigation where no budget, owner, or process exists.
• Hiding regulatory, concentration, or founder-dependence risk.
• Risk statements that contradict the financial model or implementation plan.

Outputs

• A finished or revised Section 12 risk analysis
• A prioritised risk register with mitigation and contingency logic
• Residual-risk notes and dependencies for funding or diligence review

Generate an honest risk assessment that builds investor confidence through transparency and preparedness.

What to Generate

Required Elements

1. Risk inventory Comprehensive list of risks by category
2. Probability/impact matrix Visual risk prioritisation
3. Mitigation strategies How each major risk is being addressed
4. Contingency plans What happens if a risk materialises
5. Insurance coverage Business insurance needs and plans
6. Regulatory risks Compliance obligations and penalties
7. Key person risk Dependency on specific individuals

Risk Categories

• Market risks Demand shifts, market saturation, timing
• Financial risks Cash flow, currency, interest rates, funding gaps
• Operational risks Supply chain, technology failure, quality issues
• Competitive risks New entrants, price wars, disruptive innovation
• Regulatory risks Law changes, licence requirements, compliance costs
• Team risks Key person departure, hiring difficulty, skill gaps
• Technology risks Obsolescence, security breaches, platform dependency
• External risks Economic downturn, pandemic, geopolitical instability

Risk Matrix Format

Risk	Probability	Impact	Risk Level	Mitigation
[Risk name]	Low/Med/High	Low/Med/High	Score	[Strategy]

Mitigation Strategy Types

• Avoid Eliminate the risk entirely by changing approach
• Reduce Lower probability or impact through preventive action
• Transfer Shift risk to third party (insurance, outsourcing)
• Accept Acknowledge and monitor (for low-impact risks)

Process Risk Identification

For operational risks, walk through each core process activity asking "What can go wrong?" (Page, 2015). Document findings in an internal controls table before developing solutions identify all risks first, solve second.

Use root cause analysis to move beyond symptoms to underlying causes:

• Ishikawa (Fishbone) diagram Brainstorm causes across the 6 Ms: Man (people/skills), Method (process design), Machine (equipment/systems), Material (inputs/data), Measurement (metrics/feedback), Milieu (environment/culture) (Dumas et al., 2013)
• 5 Whys For each identified cause, ask "Why?" repeatedly until reaching a root cause that, if eliminated, would prevent recurrence
• Pareto analysis Focus on the vital 20% of causes responsible for 80% of issues

Issue Register

For complex operational risks, maintain a structured issue register:

Field	Description
Issue ID	Unique identifier
Issue name	Short descriptive name
Impact dimension	Time / Cost / Quality / Flexibility affected
Quantitative impact	Estimated magnitude (e.g., "adds 3 days to cycle time")
Root causes	Underlying causes identified via Ishikawa/5 Whys
Suggested improvements	Potential solutions with trade-off assessment
Priority	High/Medium/Low based on impact and feasibility

Generation Process

1. Ask for: industry, business stage, key dependencies, known concerns
2. Brainstorm risks across all 8 categories
3. Assess probability and impact for each
4. Prioritise by risk level (probability x impact)
5. Develop mitigation strategy for all high and medium risks
6. Create contingency plans for top 5 risks
7. Identify insurance needs

Quality Criteria

• Risks are specific to this business, not generic lists
• High-impact risks have detailed mitigation plans
• Contingency plans include trigger conditions ("if X happens, we do Y")
• Analysis is honest investors distrust plans with no acknowledged risks
• Key person risk is addressed with succession or knowledge-sharing plans

Startup-Specific Risk Factors

For new ventures, actively check for the 9 Deadly Sins (Blank & Dorf, 2012) the most common startup failure modes:

1. Assuming "I know what the customer wants" without validation
2. Building features without customer feedback
3. Fixating on launch date over learning
4. Executing an untested plan
5. Static plans in dynamic markets
6. Hiring senior executives before finding a business model
7. Marketing to a plan without testing
8. Premature scaling the #1 startup failure mode (hiring/spending before validation)
9. Management by crisis instead of systematic discovery

Use the Assumptions Tracking Template to quantify risk: classify each assumption as Minor/Major/Critical, calculate Risk Score = (Minor1) + (Major5) + (Critical25), target below 100 (Alam). See references/startup-risk-frameworks.md.

Uganda-Specific Regulatory Risks (Standard Inclusions)

Every Uganda business plan risk analysis must include the following regulatory risks as standard items they affect most businesses and carry significant financial penalties:

Risk	Description	Impact if Materialised	Mitigation
EFRIS non-compliance	Failure to issue electronic fiscal receipts via URA's EFRIS system	UGX 8,000,000/month fine for not using EFRIS; UGX 6,000,000/month for not issuing e-receipts	Register for EFRIS before trading; train all sales staff; integrate EFRIS into POS system
NIN/BRN licensing gate	From 2025, individual NIN (for individuals) and BRN (for companies) are required before any licence can be issued	Inability to obtain trading licence, bank account, or government contracts	Ensure all directors have valid National IDs from NIRA; obtain BRN from URSB before applying for any licence
Import cost escalation	2025 Finance Act introduced 1.5% Import Declaration Fee + 1.0% Railway Development Levy on CIF value of all imports	2.5% additional cost on all imported inputs, equipment, raw materials	Prioritise local sourcing; factor import levies into COGS calculations; investigate EAC origin preferences
VAT anti-fragmentation	URA now treats artificially split transactions as single supplies for VAT threshold purposes	Unexpectedly crossing UGX 150M VAT threshold; back-taxes + penalties	Do not artificially split invoices; seek tax advice before approaching threshold
Late EFRIS filing	Late submission of EFRIS reports	UGX 200,000 or 2% of tax liability per month, whichever is higher	Calendar automated EFRIS submissions; use URA-integrated accounting software
EUDR compliance (coffee, cocoa, timber exporters)	EU Deforestation Regulation effective December 31, 2025	Loss of EU market access (67% of Uganda's coffee market)	Register farm GPS coordinates; obtain GlobalG.A.P. certification; implement supply chain traceability
NSSF default	Failure to remit employee social security contributions (5% employee + 10% employer)	Fine up to UGX 10M + up to 6 months imprisonment	Set up automatic NSSF payment schedule; treat NSSF as a fixed cost

For import-dependent businesses, also model the exchange rate depreciation scenario (see meta-financial-stress-test/references/stress-test-methodology.md) UGX 4,200/$ pessimistic, UGX 4,800/$ extreme scenario.

References

• Global trade risks 2025: See references/global-trade-risks-2025.md for 2025 US tariff policy and AGOA uncertainty, Suez Canal/Red Sea shipping disruptions (+23 weeks transit, +1525% freight cost), EU Deforestation Regulation (EUDR) compliance requirements, DRC instability and western Uganda trade corridor disruptions, global commodity price risks (coffee, gold, petroleum), and East African inflation context by country
• Strategic risk and scenario planning: See references/strategic-risk-scenarios.md for Suns & Clouds risk chart, risk containment strategies (avoid/transfer/reduce/accept), scenario planning methodology, hypothesis testing for strategy, risk-reward evaluation, risk mitigation plan template, and sensitivity analysis from Evans, Harris & Lenox, and Fahey & Randall
• Process risk and root cause analysis: See references/process-risk-root-cause.md for Ishikawa (fishbone) diagram methodology, 5 Whys technique, Pareto analysis (80/20 rule), internal controls framework ("what can go wrong?" walkthrough), issue register template, and process-related risk categories mapped to Devil's Quadrangle from Dumas et al. (Springer, 2013) and Page (AMACOM, 2015)
• Startup risk frameworks: See references/startup-risk-frameworks.md for 9 Deadly Sins of New Product Introduction, premature scaling risk assessment, Assumptions Tracking Template with Risk Score formula, reversible vs. irreversible decisions framework, and technology vs. market risk distinction from Blank & Dorf (2012) and Alam
• Uganda-specific risk context (202526): See references/uganda-risk-context.md for current Uganda macroeconomic risk data (inflation by category, exchange rate, interest rates), structural risks (informal economy competition, credit access), poverty/demand constraints by region, sector-specific risks (agriculture, manufacturing, services), regulatory compliance risks (URA, UNBS, NEMA, KCCA), political/security context, infrastructure risks, climate risks, a Uganda risk register template, and validated African business risk patterns from 25 years of pan-African operations (currency remittance delays, government payment risk, import competition, over-expansion, delegation/barony risk) from UBOS (CPI Feb 2026, UNHS 2023/24, NLFS 2021, KEI Q1 2025/26), World Bank (2023), and Sardanis (2007). Read this file for every Uganda business plan risk analysis.
• Enterprise Risk Management (ERM) frameworks: See references/enterprise-risk-management.md for the COSO ERM framework (mission risks appetite likelihood impact mitigation residual), five enterprise risk categories with identification checklists (strategic/operations/legal/credit/market), risk appetite and tolerance definitions with business-stage guidance, Balanced Scorecard risk KPIs, natural disaster risk framework (Mitroff's three crisis categories), ERM in projects, and risk maturity levels (15) from Olson & Wu (Springer, 2017) and Murray-Webster & Pullan

July 2026 Portable Contract

Required Inputs

Input artefact	Source/provider	Required	Behaviour when absent
Business model, assumptions, contracts, operating controls, risk evidence, scenario variables, and risk appetite for 12 risk analysis	All pipeline sections, client records, current research, and governance owners	Yes	If absent, probability, impact, control effectiveness, or scenario data is unavailable, mark the risk unassessed and use a bounded sensitivity rather than a false score.
Finalised business brief, target reader, country, and stage	Client intake and engagement owner	Yes	Stop section decisions and route the missing context to client intake.
Reconciled upstream assumptions that this section consumes	Named pipeline owners	Conditional	Record the dependency, affected claim, owner, and recovery step; do not substitute an invented value.

Outputs

Artefact	Consumer	Observable acceptance condition
Decision-ranked risk register, stress tests, mitigations, triggers, and contingency actions	Plan author and target decision-maker	The artefact answers the section decision and traces each material conclusion to the supplied evidence.
12 risk analysis exception and handoff note	Downstream section owners	Every blocked or conditional item names its consequence, owner, evidence request, and restart condition.
12 risk analysis release record	Reviewer or plan assembler	Records the checks completed, failures, unassessed items, professional review required, and release state.

Evidence Produced

Evidence	Format	Acceptance condition
Risk-source trace, scenario calculation, control-owner confirmation, and residual-risk decision	Source-linked table, calculation, or annotated prose	The evidence is reproducible from named inputs and distinguishes verified fact, management assumption, and inference.
12 risk analysis decision record	Decision note	States the selected action, rejected credible alternative, countercase, rationale, and risk accepted or avoided.
12 risk analysis review trace	Gate entry	Identifies the date, input versions, reviewer role, failed checks, recovery owner, and any check that remains not assessed.

Capability and Permission Boundaries

For 12 risk analysis, the controlling focus is enterprise risk prioritisation, control evidence, residual exposure, triggers, and contingency ownership. This skill may inspect evidence and challenge assumptions in read-only mode; it may not change controls, accept risk for management, trigger contingency spending, or certify compliance. Its normal mode is read-only analysis and drafting. Any mutation, external communication, spending, certification, or professional conclusion outside that boundary requires explicit authority and must remain traceable to the approving role.

Degraded Mode

For 12 risk analysis, loss of evidence about enterprise risk prioritisation, control evidence, residual exposure, triggers, and contingency ownership activates degraded mode. If the controlling 12 risk analysis evidence is unavailable, the same boundary applies. When probability, impact, control effectiveness, or scenario data is unavailable, mark the risk unassessed and use a bounded sensitivity rather than a false score. Return the verified subset, label the affected decision qualified or not assessed, explain the downstream consequence, and state the smallest evidence request or authorised action that permits recovery. Do not convert the missing check into a pass.

Decision Rules

Choice or condition	Action	Failure or risk avoided
For 12 risk analysis, a mitigation has no owner, trigger, budget, or evidence of effectiveness	treat it as planned rather than operating, raise residual risk, and define the test or owner needed	Decorative risk registers understate exposure and create false assurance
For 12 risk analysis, A current legal, regulatory, tax, accounting, market, or platform claim controls the 12 risk analysis decision	Verify the controlling source, effective date, jurisdiction, and reviewer status before release	Stale external facts become permanent plan assumptions
For 12 risk analysis, The evidence reconciles with neighbouring sections and the countercase does not overturn the choice	Complete decision-ranked risk register, stress tests, mitigations, triggers, and contingency actions, attach the evidence and release record, and hand off named dependencies	Premature release and repeated downstream rework

Workflow

1. Define the exact 12 risk analysis decision, intended reader, jurisdiction, business stage, and permission boundary.
2. Collect business model, assumptions, contracts, operating controls, risk evidence, scenario variables, and risk appetite and map each material conclusion to its source; stop the affected conclusion when an input could change it.
3. Apply the specialist methods and directly linked references already contained in this skill, retaining its domain thresholds, calculations, and Uganda or East Africa context where applicable.
4. Compare the credible alternatives, test the countercase and failure path, and apply the decision table rather than selecting a template default.
5. Produce decision-ranked risk register, stress tests, mitigations, triggers, and contingency actions with the evidence, exception, and handoff records; reconcile every shared assumption with its owning section.
6. Run the section quality checks, applicable finance or professional review, and anti-slop gate. If a gate fails, correct the evidence or decision and return to the responsible step.

Quality Standards

• Decision-ranked risk register, stress tests, mitigations, triggers, and contingency actions must answer a real decision for the named bank, investor, DFI, grant, board, or strategic-partner reader.
• Risk-source trace, scenario calculation, control-owner confirmation, and residual-risk decision must be source-linked, dated where facts can change, and sufficient for another reviewer to reproduce the conclusion.
• The section exposes its countercase, stop condition, recovery action, and effect on neighbouring sections.
• No unavailable source, calculation, tool, or professional review is reported as passed; finance and statutory judgements follow the governing doctrine.
• Language remains specific to 12 risk analysis, uses British English naturally, and passes the repository anti-slop gate without promotional filler.

Anti-Patterns

• In 12 risk analysis, treating an unavailable business model, assumptions, contracts, operating controls, risk evidence, scenario variables, and risk appetite as confirmed. Correction: qualify the affected conclusion and issue the named evidence request.
• Producing decision-ranked risk register, stress tests, mitigations, triggers, and contingency actions that restates the brief but makes no choice. Correction: record the choice, rejected alternative, rationale, countercase, and implication.
• Ignoring a conflicting upstream assumption. Correction: return it to its owning section and resume only from a reconciled version.
• Reporting an unavailable check as passed. Correction: mark it not assessed and narrow the release state.
• Claiming compliance, assurance, bankability, or investor readiness from narrative quality. Correction: run the applicable gate and retain its evidence.
• Copying the worked example into a client plan. Correction: use the method only and replace every fact with verified engagement evidence.

Worked Example

A key supplier failure is rated low because a backup is named, but the backup has never fulfilled an order. Treat the control as planned, test it, and raise residual risk until evidence exists.

References

• Use the verified project evidence register and the owning upstream pipeline section for 12 risk analysis; no local deep-dive reference is declared.
• For 12 risk analysis claims involving money, tax, grants, reserves, revenue, cost, valuation, or financial statements, apply the Chwezi finance doctrine and record the required professional-review state; illustrative figures never become client facts.