What you can safely skip before Series B

A friend at a bigger company sends you their security checklist, the one their team runs every quarter. It is 60 lines long. There is a row for a vulnerability management program, a row for a third-party risk committee, a row for annual penetration testing, a row for a data loss prevention rollout. You read it on your phone between two meetings, and the feeling it gives you is not clarity. It is a low, specific dread, because every line is plausibly your job and there are 28 of you.

So you do one of two things. You try to do all of it, badly, and burn a month you did not have on a program no one your size needs yet. Or you close the tab, tell yourself security is a problem for after the round, and quietly carry the worry that you have skipped something that will surface in due diligence at the worst possible moment.

Both reactions come from the same mistake. The list was sized for a company 10 times your age, with a security team to run it and auditors to satisfy. You are reading enterprise homework as if it were yours. The useful question is not how do I do all of this. It is which few of these earn their place at my stage, and which can wait without quietly turning into risk while I am not looking.

The thing that separates the two piles is not how serious the control sounds. It is whether skipping it lets a problem compound silently.

A formal vulnerability management program can wait. Multi-factor authentication on every account cannot, because the day you skip it is the day a reused password becomes someone else's access to your environment, and you find out weeks later. A third-party risk committee can wait. Knowing who has access to what, and removing it the day someone leaves, cannot, because dormant access is the kind of thing that sits quietly until it does not.

So the sorting rule is simple. Ask of each line: if I skip this, does the gap stay the same size, or does it grow on its own while I am busy with something else? The controls that stop silent compounding are the ones that earn their place now. Most of the 60-line list does not pass that test at your stage. A short handful does.

Early on, you are not buying a security program. You are buying the few things that stop a small mistake from becoming an expensive one.

The short list is shorter than the checklist made you fear, and most of it runs on tools you already pay for. If you are on Microsoft 365 and Amazon Web Services (AWS), the capability is already in the bill; what is missing is someone turning it on and tending it.

These are the few that pass the compounding test for an early team:

• Identity, locked down. Multi-factor authentication enforced on every account, not just the admins. Microsoft Entra ID can enforce Conditional Access policies that block a sign-in from an untrusted device or an impossible location. (Microsoft documents Conditional Access in Entra.)
• Access that matches reality. People get the access their role needs, and leavers lose it the day they leave, not the Friday someone remembers. The damage from stale access is slow and invisible until it is neither.
• Detection that a human reads. AWS includes Amazon GuardDuty, a threat detection service that watches your account for suspicious activity. (AWS documents GuardDuty.) A finding nobody opens is not coverage; it is a notification you pay to ignore.

That is close to the whole list at your size. It is unglamorous on purpose. The boring controls are the ones that stop most incidents, and they are exactly what gets dropped when one person is doing everything.

The larger pile is real work, and most of it belongs to a later, bigger you. A formal penetration testing cadence, a data classification program, a vendor risk committee, a written incident response runbook tested quarterly: these matter when you have the scale and the obligations to justify them. Reaching for them at 28 people mostly buys you a binder nobody maintains.

Waiting well is not the same as ignoring. Waiting well means you decided on purpose, you wrote down why, and you set the trigger that pulls each item off the shelf. The trigger is usually a fact about the business: a regulated customer, a SOC 2 commitment in a contract, headcount past a line where memory stops working as an access control. When the trigger fires, the item moves from can-wait to do-now, and you are not surprised by it in a due diligence call.

This is also where to be honest about fit. If you handle a genuinely sensitive data type, or you have a contractual security obligation already in hand, some of the can-wait pile is not optional, and we will tell you so plainly. The point is not to do less for its own sake. It is to do the right few things now and put a date on the rest, so the long list stops living in your head as undated guilt.

Go back to that 60-line list on your phone. The dread it caused was never about security. It was about not knowing which lines were yours yet, so all of them felt like a verdict on whether you were running the company responsibly.

You are. Running it responsibly at your stage means a short list done reliably and a long list scheduled on purpose, not an enterprise program performed badly by people who have other jobs. Founders do not want a longer list of controls. They want to know the floor is solid and the rest is parked on purpose, with a date, so it cannot drift into the thing that surfaces at the worst moment. Confidence, not completeness, is what closes the tab.

So before you forward that checklist to yourself as a weekend project, sit with the smaller question it was hiding: of everything on this list, which lines would grow into a problem if you left them alone for another quarter, and which are just someone else's homework you have been grading as your own?