Making security decisions with less regret: A small team perspective | Softcat
Skip to main content

Making security decisions with less regret: A small team perspective

Practical ways small security teams can prioritise with confidence and reduce second-guessing
Softcat PPT Background Radial Aubergine Gradient RGB Softcat PPT Background Radial Aubergine Gradient RGB

Aoibhín Hamill

Cyber Security Sales Engineer

If you’re part of a small IT security team, this may sound familiar.

Picture it: dozens, maybe hundreds, of CVEs (common vulnerabilities and exposures) with a CVSS (common vulnerability scoring system) of nine or ten await your attention. A handful of users are requesting emails that have been marked as malicious. Your security tooling has flagged a possible Business Email Compromise (BEC) attempt. A few logins don’t quite line up with where you expect people to be. Are you panicked? Or is this just another Wednesday?

If this does resonate with you, I salute you. Most small security teams are relied upon by their entire organisation and are expected to make sharp prioritisation decisions every day. They also carry the responsibility and the consequences, good or bad, of those decisions. More often than not, being a member of a small security team is far more than monitoring dashboards and closing alerts. A range of valuable tools are managed by a band of hardworking individuals, and they’ve likely kept their organisation safe against potential threats more times than they’d care to count. If this is what your team looks like, you’re not at fault, and neither is your organisation. This is simply the hand security deals small teams: high stakes, limited heads, constant judgement.

Most teams aren’t underperforming. They’re simply carrying more decisions than any small group reasonably should. Recognising that isn’t an excuse, it’s the first step towards doing the work with less regret.

The responsibilities mentioned above are heavy, and they don’t rotate. The same two or three people make every call day-to-day. Any work-related stress is far more likely to come from this decision pressure than from complex technical tasks. One of the hardest decisions this team needs to make is knowing when not to act. Over time they’ve come to accept they can’t address everything, and some things are better left untouched. Sometimes it really is better to let sleeping dogs lie when there are countless other sirens competing for your attention.

And thus, “we’ll keep an eye on it” is born

Keeping an eye on it is not negligence. It’s a genuine attempt to buy time. It’s what prioritisation looks like when a small team is carrying the weight of an organisation’s risk decisions. Every “not now” leaves a small tab open. After a while, there are simply too many tabs to get back to effectively. That’s when uncertainty creeps in.

These teams don’t need louder signals or extra data sources. They need more certainty and confidence in the calls they’re making day-to-day and confidence that today’s decision won’t sneakily boomerang tomorrow.

So, how do teams build this certainty and confidence?

A common goal is to “mature” the cybersecurity posture to better support small teams. That maturity does matter, but it doesn’t come from wiping the slate clean and starting fresh. Most teams don’t get a pause button. Backlogs stay backlogged, decisions keep coming, and the work doesn’t stop just because you want to redesign. Focusing on maturity before stabilising the day-to-day is often a recipe for more problems, not fewer. More tools aren’t the answer, and automation alone won’t fix the decision pressure.

The stabilisers

You don’t need a full reset, you need a few stabilisers you can put to work while you’re still fighting these fires. A more practical approach is to stabilise what already exists, adding a few guardrails while you’re already in the thick of it. Small, deliberate changes that reduce second guessing and help teams feel more confident in their decision making.

1. Expiry dates

Anything that requires you to “keep an eye on” it requires a deadline. The risk doesn’t lie in deferring, it lies in deferring indefinitely.

If something is parked, such as delaying a patch on an internet facing system, document why it’s parked, what may cause it to become urgent, and when it will next be reviewed. That may look like setting a date, a threshold to be crossed, or the next scheduled review cycle. The goal is to ensure we avoid “how did we get here?” moments by turning open tabs into intentional, controlled ones. You may still worry about it, but you know it’s on a defined path, not lost in the noise.

2. Share the load

Small teams already help each other greatly, so this point may seem obvious. The opportunity here is to make that existing collaboration explicit around the toughest calls. Encourage a culture where tricky decisions routinely attract a second opinion before they escalate. Not to outsource responsibility, but to validate judgement.

Many find it useful to keep a short list of “high-regret” decisions, wherein stakes were high and certainty was low. Reviewing these together, even informally, helps build shared context and more consistent, reliable responses when similar scenarios arise again.

3. Clearly define the term “urgent”

Urgency is an overused word. Severities and CVSS scores have their place, but urgency needs to be defined in practical, operational terms that reflect how your team and organisation actually runs.

This is your urgency, your risk, your call. There’s a big risk in chasing the latest “urgent” alert or vulnerability, to then discover it’s being exploited in regions or sectors where you have no exposure.

Urgency normally comes from different places, like:

  • Temporal urgency – a calendar driven point that needs addressing, such as platform lifecycles and end of support dates.
  • Operational urgency – business activity is being disrupted, or about to be.
  • External urgency – pressure from outside the team or organisation such as regulations, leadership, customers, or public exposure.
  • Not all urgencies require the same response and not all of them need action right now. The important step is agreeing in advance what situations will demand true immediate action or attention. Identify the ones that are worth interrupting your day, waking up at 03:00, or overriding the queue, and what ones can be deferred, and how long you would defer it for.

With this detailed approach engrained in your working goals, we can expect to see less noise-based responses and more action with intent. Decisions become easier and quicker to meet, escalation is justified and 9-5 coverage begins to feel deliberate instead of reactive. Transform urgency into a guardrail, not constant pressure.

It’s worth saying plainly: the reality described here isn’t a secret, nor is it niche. It’s just rarely acknowledged in writing. We hear these challenges from small teams all the time, and I felt it important to reflect that the answer isn’t always another piece of technology. My aim here isn’t to criticise or dramatise. It’s to name what is already true, so teams have a clearer language for the work they’re doing and a little less guilt about the decisions they have to defer. If this helps anyone around them — leadership, peers, even sales teams — understand what small‑team security actually demands, then it’s served its purpose.

Find out more about Softcat’s cybersecurity services here.