A risk matrix is a table that sorts the things that can go wrong by two questions: how likely is it, and how badly would it hurt? Each risk gets a position in the grid, and the position decides how much attention and budget it deserves right now.
Most teams use a five-by-five grid. You rate probability from 1 (very unlikely) to 5 (almost certain) and impact from 1 (annoying) to 5 (business-ending), then multiply the two. A score of 20 to 25 needs a plan this month. A score of 1 to 4 goes on a list you review twice a year.
An example with three risks. Main supplier fails: probability 2, impact 5, score 10. Lead developer leaves: probability 3, impact 4, score 12. New competitor undercuts your price: probability 4, impact 3, score 12. Two risks tie at 12, so you compare what a fix would cost. Documenting your codebase and training a second developer takes a few weeks of work. Preventing a competitor from entering the market is not something you control. So you act on the developer risk and only monitor the price risk.
A matrix is useful only with four columns next to it: the risk, the score, the countermeasure, and the person responsible with a date. Without an owner it is a decorative table.
A generated business plan usually contains a risk matrix in the risk section, because banks and investors expect one. That is where founders make two mistakes. They rate everything as high, which flattens the ranking and helps nobody. Or they list only obvious external risks, such as a recession, and skip the specific internal ones they could fix, such as one person holding the only administrator password. Update the matrix every quarter.
