Requirements - Decision Making & Governance
-
DM03 - Risk and Issues
Architecture risks and issues should be managed effectively with the appropriate level of visibility and ownership.
Requirement description
This requirement is concerned with the identification, ownership, monitoring and management of architecture-related risks and issues.
Architecture risks and issues should be visible to the appropriate stakeholders, regularly reviewed, and managed through agreed governance processes. Significant risks should not depend on individual knowledge or informal communication.
Ownership should be clear, mitigation actions tracked, and escalation routes used where required.
In simple terms:
Known architecture risks and issues should be documented, owned, visible and actively managed until they are resolved or formally accepted.
Scoring rubric table – DM03 Architecture Risk and Issue Management
| Score | What it looks like | Typical evidence | Key gaps / risks |
|---|---|---|---|
| 0 | No evidence that architecture risks or issues are identified or managed. |
No RAID log. No architecture risk register. No documented ownership. No governance reporting. |
Significant service risk. Architecture weaknesses may remain unknown, unmanaged or unresolved. |
| 1 | Limited awareness of architecture risks and issues. Management activities are informal and inconsistent. |
Occasional discussion in meetings. Informal notes. Verbal awareness of risks. Actions not formally tracked. |
High-risk gaps. Risks may be overlooked, forgotten or managed inconsistently. |
| 2 | Some architecture risks and issues are documented and tracked, but coverage and management are inconsistent. |
Partial RAID log. Some assigned owners. Risk descriptions recorded. Limited evidence of reviews. |
Significant notable gaps. Important risks may be missing, poorly quantified or lack mitigation plans. |
| 3 | Much of the architecture risk position is understood and actively managed. Most significant risks and issues are documented and reviewed. |
Maintained architecture risk or RAID register. Named owners. Documented impact assessments. Mitigation actions recorded. Evidence of governance review. |
Notable gaps remain. Some risks may lack target dates, escalation paths, acceptance decisions or regular review. |
| 4 | Most architecture risks and issues are effectively controlled through established governance and management processes. |
Maintained risk and issue register. Regular review cadence. Clearly assigned ownership. Defined mitigation plans. Governance reporting. Evidence of escalation where appropriate. |
Minor gaps only. Remaining weaknesses present limited risk and are actively monitored. |
| 5 | Comprehensive and exemplar architecture risk management. Risks and issues are proactively identified, managed and used to inform decision-making. |
Comprehensive risk management process. Architecture-specific risk reporting. Evidence of trend analysis. Governance dashboards. Documented risk acceptance decisions. Clear linkage between risks, roadmap activities and investment decisions. |
Minimal or no significant gaps. Risk management is embedded within delivery and governance processes. |
What assessors should look for
- Identification – Are architecture risks and issues formally documented and maintained?
- Ownership – Does every significant risk or issue have a clearly assigned owner?
- Visibility – Are risks visible to the appropriate stakeholders, governance groups and decision-makers?
- Mitigation – Are actions defined, tracked and reviewed to reduce or manage risk?
- Governance – Is there evidence that significant risks and issues are reviewed, escalated or accepted through appropriate governance processes?
- Lifecycle management – Are risks regularly reviewed, updated and closed when appropriate?
What separates a 3 from a 4 or 5
A score of 3 normally means that the majority of important risks and issues are identified and being managed, but weaknesses remain in governance, ownership, consistency, visibility or review frequency.
A score of 4 requires evidence that risk and issue management is established, maintained and routinely embedded within governance processes. Ownership, mitigation and review activities should be consistent and demonstrable.
A score of 5 requires risk management to be proactive rather than reactive. Risks are used to influence architecture decisions, prioritisation, investment planning and roadmap development. Evidence should show continuous monitoring and improvement rather than simple record keeping.
Suggested evidence examples (not SAF-mandated artefacts)
- Architecture risk register
- RAID log containing architecture risks and issues
- Programme or portfolio risk reports
- Governance and Design Authority papers
- Risk review meeting minutes
- Architecture remediation plans
- Escalation records
- Risk acceptance decisions
- Product roadmap items linked to risk mitigation
- Management dashboards or reporting packs
Updated: 04 September 2026 (SAF Version 1.1)