Which risk assessment approach fits a technical architecture review, and where do the common methods go wrong?

Where qualitative matrices go wrong

The likelihood-times-impact matrix is ubiquitous and weak. Ordinal categories are multiplied as though they were numbers, "medium" means different things to different assessors, and the output ranks risks with a precision the inputs do not support.

Its worst property is that it produces agreement without producing understanding — everyone signs off on a number nobody can explain.

What works better for architecture

• Threat modelling on the design, walking the data flows and asking what an attacker would do at each trust boundary. It produces specific, actionable findings rather than a score.
• Scenario analysis. "The primary region is unavailable for four hours" — what happens, what does it cost, what would we do. Concrete enough to drive design decisions.
• Quantified estimation where the numbers exist: expected loss ranges with stated uncertainty, which supports a cost-benefit comparison that a matrix cannot.
• Failure mode analysis for operational risk, enumerating what breaks and what the detection and recovery look like.
• Pre-mortems. "It is a year from now and this failed" — reliably surfaces risks that structured methods miss, because it removes the social cost of raising a concern.

The properties that matter more than the method

• Calibration. Assessors who have never been scored against outcomes are systematically overconfident, and no framework corrects for that.
• Specificity. "Data breach — high" is not actionable. "An engineer's standing production access could export the customer table with no alerting" is.
• Traceability to a decision. A risk assessment that does not change what gets built is a document.
• Revisit conditions, since a risk assessed once at design time and never revisited describes a system that no longer exists.