Startup Security

• Do these in order. A checklist without priority is a way of feeling busy while the highest-risk items stay open.
• The first four items are identity, backups, dependency updates, and secrets. Nothing else beats them on risk reduced per hour.
• Most incidents at small companies come from credentials and forgotten assets, not exotic exploits.
• Security awareness training is worth doing and is nowhere near the top - culture beats a checklist, but neither beats MFA.

If you do only four things, do these: enforce multi-factor authentication everywhere, verify that your backups restore, keep dependencies patched, and get secrets out of your code. Those four remove more real risk per hour spent than anything else on any list, and they are all achievable in a week.

What follows is ordered. That is the entire value of it - a two-hundred-item checklist with no priority is a way of feeling productive while the important items stay open.

Tier 1: this week

1. MFA on everything, enforced not encouraged. Email, cloud console, source control, production access, payment systems. Credential theft is the most common way small companies get breached, and this is the single highest-value control in existence. Phishing-resistant factors where you can.
2. Test a restore, not a backup. Everyone has backups. Far fewer have restored one. An untested backup is a belief, and ransomware is precisely the situation where you discover which you had.
3. Automated dependency updates. Turn on the automated pull requests and actually merge them. Known-vulnerable libraries in your own build are the cheapest possible way to be compromised.
4. Secrets out of the repository. Move keys and tokens into a secrets manager or your platform's encrypted environment variables. Then rotate anything that was ever committed, because git history is forever and scanners crawl it constantly.

Tier 2: this month

1. Least privilege, roughly. Nobody needs production admin by default. Perfect role design can wait; removing standing admin from people who do not need it cannot. We go deeper on this model in zero trust for startups.
2. Centralised logging. You cannot investigate what you did not record. Get authentication events, access logs and application errors into one place before you need them.
3. Offboarding that actually revokes. A checklist for departures covering every system, including the ones bought on someone's personal card. Revoked users whose sessions or API tokens keep working is a finding we see repeatedly.
4. Know what you have. A simple inventory of applications, environments and domains. Forgotten assets - a staging environment nobody decommissioned, an internal tool exposed to the internet - are a recurring cause of real incidents.

Tier 3: this quarter

1. Test the application properly. Once your product holds customer data, you need to know whether someone can reach it. That is a penetration test rather than a scan, and if you are multi-tenant it needs to cover tenant isolation specifically.
2. Incident response on one page. Who decides, who communicates, who has the vendor phone numbers, what gets logged. One page beats a formal plan nobody has read.
3. Security awareness training. Worth doing, and notice where it sits. Training your team not to click things is real value that MFA largely makes survivable anyway.
4. Vendor review, proportionate. For any third party touching customer data: what access do they have, what happens if they are breached, can you revoke them quickly.

What is mostly theatre at your stage

Some things feel like security and mostly consume the attention you need for the list above. Writing extensive policy documents nobody reads. Buying a tool that produces a dashboard nobody watches. Pursuing a certification before you have the controls it certifies. Quarterly password rotation, which modern guidance has moved away from because it produces predictable passwords.

The pattern in nearly every small-company incident: stolen credentials, an unpatched dependency, or an asset nobody remembered. Sophisticated exploitation is rare; the top four items on this list address the common cases.

Where compliance fits

If a framework is driving this - SOC 2, ISO 27001 or NIS2 - the ordering above still holds, because those frameworks are largely asking for these controls in more formal language. Doing the work first and documenting it second is considerably cheaper than the reverse.

Which framework expects what, including whether a penetration test is required or merely expected, is mapped on our compliance hub.

← Back to all posts