Small Teams Don't Need a Security Program. They Need a Short List.

I’ve watched a lot of small engineering teams try to adopt a security program the way the blogs describe it. I haven’t seen it work once. Not because the people were lazy, and not because the advice was technically wrong. The model itself assumes a staffing reality that doesn’t exist at small companies.

There’s a version of that advice, the one aimed at small teams, that starts with threat modeling frameworks, ends with a twelve-month roadmap, and is completely useless for anyone who has actual work to do. This is not that.

Written for someone else’s organization

Most security guidance is written for organizations with a security team. It assumes someone owns this full-time, has budget, and can spend a quarter instrumenting observability before they do anything else.

If you’re a three-person engineering team at a fifty-person company, that organization is not yours. There’s a product to ship, incidents to handle, and somewhere between zero and four hours a week that could plausibly be called discretionary time. A security program isn’t something you adopt. It’s something you’d have to become, and you’re not going to become it.

Five to eight things, reviewed quarterly

Not a checklist. Checklists get long, go stale, and create the illusion of coverage without the reality of it.

I think of a short list as five to eight things that, if they’re all in order, mean you’re not going to have a bad day for the most common reasons. You revisit it quarterly. You keep it somewhere everyone on the team can find it. When something breaks or changes, you update it.

For most small teams running production workloads on AWS, the list looks roughly like this:

1. Secrets are rotated and rotation is actually working. Not just configured. Working. There’s a difference, and it’s easy to miss.

2. MFA is on every human account that can do anything consequential. Root account. IAM users. Your AWS SSO setup if you have one. No exceptions for convenience.

3. You know what’s public. S3 buckets. Security groups. Load balancers. Anything with an inbound rule wider than it needs to be. You don’t have to lock everything down, but you should know what you’ve made a deliberate choice about versus what defaulted into that state.

4. Unused access is removed. The former employee’s IAM user. The contractor’s credentials. The service account for the integration you deprecated. Gone, not dormant.

5. You’d know if something changed. CloudTrail is on. You have at least one alert that would fire if someone logged in from an unexpected location or made a sensitive API call. It doesn’t have to be sophisticated. It has to exist.

6. Your dependencies aren’t obviously compromised. A quick look at critical packages every few weeks. Dependabot or equivalent running. You don’t need to audit everything. You just need to know you’d catch something obvious.

Programs are harder to own than they look

A program requires maintenance as a program. Policies, ownership, review cycles, tooling. All of that is real work, and for a small team it competes directly with the work that keeps the company running.

A short list requires maintenance as a list. Six items. Quarterly review. An hour, maybe two.

Short lists also make the delta visible. When something gets added to your infrastructure or your team changes, the question isn’t “does this comply with our security program?” It’s “does this affect anything on the list?” A busy engineer can answer that in five minutes.

What I’m not telling you to do

Almost everything, and that’s fine.

Penetration testing. A SIEM. A formal incident response plan with defined roles and communication trees. These are real things that matter at a certain scale. If you’re not there yet, pretending otherwise doesn’t make you more secure. It just makes you feel like you’re failing at something you were never going to do.

When you get to that scale, you’ll hire someone who knows how to build the program.

If you don’t have a list yet

Start with secrets. It’s the highest-return first step for most AWS-based teams. The exposure surface is real, the configuration drift is common, and it’s entirely auditable in an afternoon.

From there, work outward. IAM. Network exposure. Dependency hygiene. It’s not a program. It’s a list that’s actually accurate.

Starting with secrets is what Redactus is built for. It’s in development. Get notified when it launches.