Managing Risk When Everything Competes for Resources
Putting the old teacher hat back on.
We learn early in our careers to assess risk in terms of the likelihood of an adverse event and the impact if it occurs. That gives us a useful starting point, but it does not tell us how to act when several important problems compete for the same people, time, and funding.
Managing risk requires recognizing those constraints. They shape what we address, how we address it, and how quickly we can act.
A limited budget does not make a risk smaller. A shortage of people does not reduce its potential impact. These constraints limit our response options and force us to decide what will be addressed now, what will wait, and what risk will remain in the meantime.
The Magic Nugget: Defensive Execution
I use defensive execution to describe the discipline of turning our understanding of risk into timely and effective action within the resources we actually have.
The goal is straightforward:
- Reduce the likelihood that vulnerabilities will be exploited.
- Limit the potential harm if exploitation occurs.
- Act within the available people, time, and funding.
- Reassess as the environment and available information change.
The difficult part is execution.
In our daily game of whack-a-mole, new vulnerabilities appear while yesterday’s problems are still being addressed. Some are urgent. Some appear urgent because of a severity rating, an escalation, or the person asking. Others receive little attention even though exploitation could have serious consequences within our specific environment.
We cannot fix everything at once. We must make decisions.
Critically, each decision commits resources that are then unavailable for something else.
The engineer investigating one finding cannot spend that same hour correcting another. An emergency change can displace a planned architectural improvement. A new security tool consumes more than its purchase price. Someone must implement it, tune it, maintain it, investigate what it finds, and respond to the results.
That is the opportunity cost of defensive execution, and it belongs in the risk decision.
Risk Scores Are Inputs, Not Decisions
Consider a team facing two competing priorities: a vulnerable service reachable from the internet and a backlog of higher-scoring findings on tightly restricted internal systems.
The scores are useful, but they do not make the decision for us. Prioritization requires context.
- Is the vulnerable function reachable?
- Is exploitation occurring or likely?
- What access would an attacker gain?
- What business capability could be disrupted?
- Which existing controls reduce the likelihood or potential impact?
- How confident are we that those controls work?
If a permanent fix for the internet-facing service will take several days, restricting access or disabling the affected function may reduce the immediate risk. That temporary mitigation still needs an owner, evidence that it works, and a date for reconsideration.
Meanwhile, the deferred internal findings still need a plan. Moving work down the queue does not resolve the underlying risk.
Making the Tradeoffs Visible
A few questions can improve the discussion:
- What credible harm are we trying to prevent, and how soon could it occur?
- Which available action can meaningfully reduce that risk?
- What people, time, and funding will the response require, including ongoing support?
- What other work will wait, and what risk remains while it does?
- How will we verify the result?
- What new information would cause us to change the decision?
Uncertainty is part of the job. We rarely have perfect information about the likelihood of an event or the effectiveness of a proposed response. We can still make a reasoned decision, document our assumptions, and define the evidence that would cause us to reconsider.
When the remaining risk exceeds someone’s authority to accept it, the decision must move to the accountable risk owner.
Why Do the Same Moles Keep Coming Back?
There is also a longer-term question: Why do the same problems keep returning?
If every urgent fix consumes the time intended for secure defaults, automation, architectural improvements, or root-cause correction, the team can remain extremely busy without materially improving its position.
Defensive execution includes protecting enough capacity to prevent recurring problems. Sometimes the best use of resources is fixing today’s vulnerability. Sometimes it is changing the conditions that keep producing the vulnerability.
The tradeoffs among speed, resources, and risk reduction are real, but they are not always a rigid “pick two” proposition. Better engineering can improve all three. A reusable fix or automated control may require more effort today while reducing future risk, response time, and operational cost.
Reward the Judgment, Not Just the Activity
This is what security organizations should recognize and reward: sound judgment, effective action, and verified reductions in risk.
The number of tickets closed tells us how much work moved through a process. It does not necessarily tell us whether the organization is better protected.
Every defensive decision spends part of our ability to respond. We should be able to explain what that investment protects, what it leaves waiting, what risk remains, and when we will reconsider the choice.
That is defensive execution.
