Architecture Risk Register
A structured log of risks specifically related to architectural decisions, technology choices, and technical design, tracking their likelihood, impact, and mitigation strategies.
Purpose
The architecture risk register ensures that technical risks are identified, assessed, and actively managed throughout the project lifecycle. It provides visibility to governance boards and helps prioritise mitigation activities.
When to Use
Create at the start of alpha and maintain throughout the project. Review at each sprint or iteration. Present to Architecture Review Boards and programme governance.
How to Build
Identify architectural risks through workshops, architecture reviews, and threat modelling. Consider risks in categories: technology maturity, integration complexity, scalability, security, skills availability, vendor dependency, and technical debt.
For each risk, assess the likelihood (1-5) and impact (1-5) to calculate a risk score. Define the risk appetite — what level of risk is acceptable without mitigation?
For risks above the appetite threshold, define mitigation actions with owners and target dates. Distinguish between actions that reduce likelihood and those that reduce impact.
Review the register regularly — at least fortnightly during active delivery. Update risk scores based on new information and close risks that are no longer relevant.
Escalate risks that cannot be mitigated at the project level to programme or portfolio governance.
Tips
- Focus on architecture-specific risks — general project risks belong in the project risk register.
- Use risk workshops with the whole team to identify risks — architects do not see everything.
- Track risk trends over time — are risks increasing or decreasing as the project progresses?
- Link risks to specific architectural decisions or components for traceability.
- Include positive risks (opportunities) as well as threats.
Common Mistakes
- Identifying risks but never reviewing or updating them.
- Not assigning clear owners for mitigation actions.
- Conflating architecture risks with general project risks.
- Setting all risks to high impact/high likelihood, making prioritisation impossible.
- Not escalating risks that are beyond the project's ability to mitigate.
Government Context
In UK government, architecture risks should be escalated through departmental governance structures. Major technology risks may need to be reported to CDDO or included in departmental risk registers. The Government Functional Standard for Digital, Data and Technology (GovS 007) requires active risk management. Risks related to legacy IT, cyber security, and data protection are particularly scrutinised.