Security posture for small teams

Small companies get security wrong in one of two directions, and the second one is more common than people admit.

Either they do nothing, on the theory that nobody's interested in them yet, which is wrong because most attacks aren't targeted at all. Or they do a diffuse amount of everything: a scanning tool, a policy document, a pen test, a compliance project, none of it finished, all of it consuming attention, and the actual holes still open.

The answer is a short list, done completely. Not partially, not eventually. Five things, closed, and then stop.

The list

Identity. Single sign-on for everything, enforced multi-factor, and a real offboarding process that removes access the same day someone leaves. The overwhelming majority of small-company breaches start with a credential, and the overwhelming majority of those would have been stopped by these three things. Nothing else on this list is worth doing before this one.

Secrets. No credentials in the repository, in environment files committed by accident, or in a shared document. A secrets manager, injected at runtime, with automated scanning that blocks a commit containing something that looks like a key. Then rotate everything that has ever been in a place it shouldn't have been, which is more than you think.

Dependencies. Automated updates for security patches, applied continuously rather than in an annual project. The realistic threat here isn't a novel exploit, it's a publicly known vulnerability in a package you're four versions behind on, exploited by a script that found you by scanning.

Backups that have been restored. Not backups that exist. Restore one, on a schedule, into a real environment, and time it. Untested backups fail at roughly the rate you'd expect from anything that's never been tested, and you find out at the worst possible moment. This is also your ransomware answer, and it's the only one that works.

Access review. Once or twice a year, list who has access to production, the customer database, and the cloud account, and remove everyone who doesn't currently need it. Access accumulates silently, especially for people who changed roles rather than leaving.

That's the list. It's achievable in a few weeks of deliberate work at a small company, and it prevents most of what realistically happens to companies your size.

Threat modelling in an hour

You don't need a methodology. Get three or four people in a room with a whiteboard and answer four questions.

What would hurt us most if it got out or got broken? Usually customer data, sometimes the ability to move money, occasionally a specific system whose downtime is contractual.

Where does that live, and what touches it? Draw it. The diagram will be wrong in an interesting way, and the wrongness is a finding.

Who could realistically reach it? Not a nation-state. A stolen laptop, a phished credential, a contractor's account nobody disabled, a public bucket, an API without authorisation checks on one endpoint.

What would we notice, and how? This is the one that consistently produces silence, and the silence is the point. Most small companies would not detect a quiet exfiltration at all, and the cheap fix is alerting on a handful of specific things: logins from unusual places, bulk data exports, changes to who has admin.

Do this once a year, and after any architectural change worth the name. An hour, four questions, three findings you'll act on.

Compliance, described honestly

SOC 2 and its relatives are a sales unblock. That's the honest framing, and it's not cynical: enterprise customers require it, so it converts into revenue, and that's a legitimate reason to do work.

What it is not is a security programme. A company can pass an audit with the controls documented and the actual posture mediocre, because the audit checks that you do what you said you do. Plenty of breached companies were compliant.

So sequence it deliberately. Do the five-item list first, because it's most of the real security and a decent chunk of the evidence you'll need anyway. Then, when a deal actually requires certification, run the compliance project as the sales project it is, with a real cost attached (a compliance platform, an auditor, and a meaningful slice of someone's quarter) and a real revenue number justifying it.

The failure I'd avoid: starting compliance early because it feels responsible. It consumes months, it produces policies nobody follows, and it makes the organisation feel secure while the five real things sit undone.

Building it into the work

The controls above are one-time projects. The ongoing part has to be cheap or it won't survive a busy quarter.

Put as much of it as possible into the paved road, so teams get security by using the platform rather than by remembering. Authentication handled by shared infrastructure, secrets injected automatically, the default deployment already locked down, dependency updates automated.

Then a small number of things a human has to do: a security review for changes touching authentication, payments, or personal data (a real review, not a checkbox), and a norm that anyone can flag a change as needing one.

The cultural piece matters as much as the controls, and it's the same principle as everything else in this track: the cost of reporting a mistake has to be near zero. The engineer who realises they committed a key needs to be able to say so immediately, loudly, without anything bad happening to them. A company where that's embarrassing is a company that finds out about exposed credentials from a third party.

Preparing for the one you hope never happens

Decide three things now, while nothing is wrong, and write them down where you can find them.

Who's in charge during a security incident, which is often a different person from your usual incident commander, and who has authority to take systems offline.

Who you call. External incident response firm, your lawyer, your insurer. Have the names and numbers before you need them, because the first hour is not when you want to be evaluating vendors.

And what your disclosure obligations actually are, in your jurisdictions, with the clocks attached. Some of them are measured in hours from the point of awareness, which is a fact worth learning in advance rather than on the day.

Then run a tabletop exercise, once, for ninety minutes. Someone describes a scenario ("a customer emails saying their data appeared in a paste site") and the group talks through what happens next. It's cheap, it's uncomfortable, and it will find at least two things that would have cost you a day.

The one thing to do this week

Check offboarding. Take three people who left in the last year and go through every system, one at a time, confirming their access is gone.

It takes an hour and, in my experience, it almost never comes back clean.