Every security team I've worked with has had more work than people. The requests keep coming: a new tool to evaluate, an audit finding to close, a vendor questionnaire, an engineer asking for an exception. So, how do you decide what to do first, and how do you explain that decision to the people who don't get what they asked for?
My answer is to start with the risks that can really hurt the business, and work backwards to the controls that reduce them. It sounds obvious, but it changes how you plan, how you say no, and how you talk to the board.
Name the risks that matter
Start by writing down a small number of high-level risks: the events that would cause serious damage if they happened. For most companies, the list will include ransomware, financial crime (fraud, payment abuse) and denial of service. Your list might have a few more, depending on what you sell and who you sell it to.
Keep it short. The value of the list comes from forcing a choice, and a list of thirty "top risks" forces nothing. If you can't explain each risk to your CEO in one sentence, it's probably too detailed for this level.
Map the controls to each risk
For each risk, list the controls that reduce it. Take ransomware. The controls that matter most are usually offline backups that you restore regularly, MFA on every account that can reach production or the corporate network, endpoint detection and response, fast patching of anything facing the internet, and an incident response plan that the team has actually rehearsed.
Once you have this map for every risk, prioritisation becomes much easier. When a new request comes in, you ask one question: which of our top risks does this reduce, and by how much? If the answer is "none of them", it goes to the back of the queue, and you can explain why in a sentence.
The map also shows you the gaps. A big risk with only one or two weak controls against it is where the next pound (and the next hire) should go. And a control that doesn't map to any risk is worth a hard look, because someone is paying for it.
Inherent risk and residual risk
Two terms help keep this honest. Inherent risk is the risk before any controls: how likely an event is, and how bad it would be, if nothing stood in the way. Residual risk is what's left once the controls are in place and working.
The gap between the two is what your controls are worth. So, when I compare two pieces of work, I look at how much each one lowers the residual risk on one of our top risks. Residual risk is also what matters for decisions: it's what we compare against the level of risk the business is willing to carry, and it's what we formally accept when we decide to stop there.
Both of them move over time. Inherent risk goes up when the threat grows or the business changes (more payment volume means more for fraudsters to go after). Residual risk goes up when a control quietly stops working, which brings us to the next point.
Check your controls still work
Controls age, and threats move faster than most control reviews. A control that was effective two years ago may be doing very little today, and nobody notices because nothing is visibly broken.
Captchas are a good example. For years, they were a decent way to stop bots from creating fake accounts or trying stolen credentials at scale. Today, AI-driven browser automation can solve many captchas cheaply and quickly, so attackers get through while real customers still pay the cost in friction. The captcha is still there and the dashboard still shows it as "in place", but is it still reducing the risk we bought it for? If it isn't, the residual risk has gone up, even though nothing on the control list has changed.
So, evaluate every control on a regular schedule, against the threats you see today. The questions I ask are simple:
- What risk does this control reduce?
- What would an attacker need to get past it today?
- When did we last test it, and how?
- What would we lose if we switched it off tomorrow?
The last question is the most useful one. If nobody can answer it, we probably don't understand what the control is doing for us.
Write down the risks you accept
You won't fix everything, and that's fine, as long as the decision is deliberate and written down. What we accept is always the residual risk: whatever is left once our controls are in place. When we decide to accept a risk, we record the risk in plain words, why we're accepting it (cost, timing, low likelihood), who agreed to it, and when we'll look at it again.
The business owns the risk, so the acceptance has to be agreed with the business and with the people who own the technical controls that mitigate it. Security makes sure everyone understands what they're signing up to.
A written acceptance also protects everyone involved. If the risk turns into an incident six months later, nobody has to argue about who knew what, and the conversation can move straight to fixing it. The review date matters as much as the signature: a risk that was acceptable last year may look very different once the threats change (the captcha example above is exactly that).
Give the board what the board needs
Board time is short, so I focus on two things:
- Material risks. These are the risks that could cause serious financial loss, regulatory action or permanent closure. Ransomware sits here for most companies, and most companies are not prepared adequately for it. The board needs to know where we stand against each material risk, whether that position is getting better or worse, and what we need from them.
- Emerging risks. These are the risks that weren't on the register last year. Geopolitical risk is one I bring up more and more, and the concentration of infrastructure in AWS US East is a good way to make it concrete.
What October 2025 taught us about US East
On 20 October 2025, AWS's US East region (Northern Virginia, us-east-1) had one of the largest outages in years. At 07:48 UK time, a latent race condition in DynamoDB's automated DNS management left the service's regional endpoint with an empty DNS record. Every system trying to reach DynamoDB in that region simply couldn't find it, and that included many of AWS's own internal services.
AWS restored the DNS records in under three hours, but the knock-on effects lasted much longer. New EC2 instances failed to launch until early evening UK time, network load balancers started failing health checks and taking healthy capacity out of service, and services like Lambda, ECS and EKS were disrupted until around 22:20. From start to finish, the disruption lasted around fifteen hours, and some Redshift clusters took until the following day to recover.
In the UK, the impact was very visible. Customers of Lloyds, Halifax and Bank of Scotland couldn't log in to online banking, and HMRC's Government Gateway was down for part of the day. Plenty of small businesses lost access to the tools they run on. The Treasury Committee wrote to the Treasury the same day, asking why Amazon hadn't yet been designated a critical third party for the financial sector.
The cause was a software bug in AWS's own automation. But the effect is exactly what a board should picture when we talk about geopolitical risk to infrastructure: a region we depend on becomes unavailable, and so does everything we didn't realise depended on it. Now imagine the trigger is sanctions, export controls, a conflict affecting a data centre, or a new law on where our customers' data can live. The disruption could last weeks, with a far less predictable end.
Concentration in US East is a risk like any other, so it goes on the register with an owner, a set of controls and a review date.
A word on heat maps
As Eric Staffin observed in a LinkedIn comment, a risk can move across a heat map (or the heat map itself can be redrawn with more squares so the movement shows) while the real exposure stays exactly where it was. A board gains nothing from that. What it needs to know is whether leadership decisions are driven by risk, whether those decisions are reducing what the business stands to lose, and whether the worst outcomes stay within the level of risk the organisation has agreed to carry.
So, when I report progress on a material risk, I back it up with evidence that the exposure has changed:
- What has changed in the threat since the last update?
- What has changed in our exposure, and which controls made that happen?
- Which consequences are now less likely or less severe, and are they within the level of risk we've agreed to carry?
- Which decisions did we take, who took them, and did they have the authority to?
The board can then judge the progress for itself, and the colour on the slide becomes a summary of changes they can see.
In short
- Start with a short list of the risks that matter.
- Map controls to each risk and prioritise the work by how much it lowers the residual risk.
- Re-test your controls as the threats change.
- Write down every risk you accept, who accepted it and when you'll review it.
- Give the board the material and emerging risks, and the decisions you need from them.
It's simple on paper. The hard part is doing it consistently, quarter after quarter, while the queue of urgent requests keeps growing.