Knowing where the gaps are is one problem. Deciding what to do about them, in what order, with the hours you actually have, is a separate one.
Most security guidance stops at identification. Here is the gap, here is why it matters, go and fix it. That advice assumes a team with the capacity to act on everything at once. Very few mid-market organisations have that, and the ones managing security alongside infrastructure, service desk and everything else certainly do not.
So once you have a list in front of you, the practical question is what to do first, and what can wait until next quarter.
Severity Ratings Describe the Vulnerability, Not Your Environment
A high severity score tells you how dangerous a weakness is in the abstract. It does not know whether the affected system is internet-facing, whether it holds anything sensitive, or whether exploiting it would require access an attacker does not have.
A critical-rated flaw on an isolated internal system with no route in from outside is genuinely less urgent than a moderate-rated one on an exposed service. Working down a severity-sorted list is a reasonable starting point, and it is defensible. It also means a scoring system with no knowledge of your environment is deciding where your scarce hours go.
Start with exposure. What could someone touch from outside your network, or from a standard user account inside it? That subset is where remediation effort earns the most.
Ask What Sits Behind the Control
The second filter is blast radius. Two identical findings can carry completely different consequences depending on what they protect.
Missing multi-factor authentication on a shared meeting-room device is a housekeeping item. The same finding on an account with domain administrator rights is a different category of problem entirely. The control is the same. What sits behind it is not.
This is the filter that most often reorders a list built purely on technical severity, and it is one an internal team is well placed to apply, because it depends on knowing your own environment rather than on specialist security expertise.
Separate the Instance From the Pattern
A single missed patch on a single device is a task. A patch policy that silently excludes an entire class of devices is a process failure that will keep producing findings no matter how many times you clear them.
When you review a set of findings, the useful question is whether each one is a one-off or evidence of something structural. Remediating instances feels productive because the count goes down. If the underlying process is what produced them, the count comes back.
Fixing the pattern takes longer and shows less immediate progress. It is almost always the better use of the time.
Look for Fixes That Close More Than One Gap
Some remediation work resolves a single finding. Some resolves a category.
Enforcing multi-factor authentication consistently, with no standing exceptions, closes every finding related to inconsistent enforcement in one action. Removing local administrator rights as a default closes a class of privilege findings rather than a list of individual ones. Both take real effort and both need care, but the leverage is significant.
When two items compete for the same week, the one that closes a category usually wins over the one that closes an instance, even when the instance carries a higher severity rating.
Be Honest About the Risk of the Fix Itself
Not all remediation is safe to rush. Tightening application control can break a business process that nobody documented. Restricting a service account can take a production integration offline. Removing administrative rights can stop a team from doing work they have done the same way for years.
None of these are reasons not to proceed. They are reasons to sequence deliberately: test, communicate, stage the rollout. A change that causes an outage does more visible damage than the risk it removed, and it makes the next security change politically harder to get approved. Sequencing is part of the remediation plan, not an afterthought to it.
What "Can Wait" Actually Means
Some things genuinely can wait, and saying so out loud is more useful than pretending everything is urgent.
A finding can reasonably wait when it is not externally reachable, does not protect anything of consequence, and is not evidence of a broader process problem. What it should not do is disappear. The difference between a considered deferral and a quietly ignored risk is whether it is written down, given a date, and revisited.
That distinction matters most in the conversation you have afterwards, whether with leadership, an auditor or an insurer. “We knew, we assessed it, we scheduled it” is a defensible position. “We did not get to it” is not, and the record of the decision is what separates them.
The Order That Usually Works
For most mid-market environments, working through findings in roughly this sequence produces the most risk reduction per hour spent:
- Anything externally reachable and exploitable without credentials
- Anything protecting privileged access or your ability to recover
- Process failures producing repeat findings, rather than the findings themselves
- Fixes that close an entire category of gap in one action
- Everything else, scheduled and recorded rather than left open
Â
This is not a formula and it will not survive contact with every environment unchanged. What it does is give you a defensible reason for the order you chose, which is more than a severity-sorted list provides.
Where This Leaves You
Prioritisation only works if the findings you are prioritising are accurate. A list built on incomplete or dated information will produce a confident plan aimed at the wrong things, and there is very little value in sequencing work carefully against a picture that has moved on. That is a separate problem from this one, and we have written about why periodic assessment struggles to keep up elsewhere.
If you have a set of findings and are working out where to start, our team is happy to talk it through with you.
FAQs
How should an organisation decide which security gaps to fix first?
Start with what an attacker could actually reach: anything externally exposed or exploitable without credentials. Then work through gaps protecting privileged access and recovery capability, followed by process failures that keep producing repeat findings. Severity ratings are a useful input but they describe the vulnerability in isolation, not its significance in your specific environment.
Is it acceptable to defer a security finding?
Yes, provided the decision is deliberate and recorded. A finding that is not externally reachable, does not protect anything significant, and is not evidence of a wider process problem can reasonably be scheduled rather than actioned immediately. The difference between a considered deferral and an ignored risk is whether it has been assessed, dated and documented.
Why is a high severity rating not always the top priority?
Severity ratings assess a vulnerability generically, without knowledge of your environment. A critical-rated issue on an isolated internal system with no external route to it can carry less real risk than a moderate-rated issue on an internet-facing service. Exposure and blast radius usually reorder a severity-sorted list significantly.
What is the difference between fixing an instance and fixing a pattern?
An instance is a single occurrence, such as one device missing a patch. A pattern is the underlying process that produced it, such as a patch policy that excludes a class of devices. Remediating instances reduces the count temporarily. Remediating the pattern stops the findings recurring.
