essay 10 min read

Zero to MVP Security

Your first enterprise customer will put you through a security review, and passing it is the floor, not proof you are safe. Here is the map from zero to MVP security: the checklist every buyer names, the five things that checklist cannot see, and the order to do them in.

securitystartupssoc2enterprise-salessupply-chainopsec

A cyberpunk chess king rendered in metallic black with glowing gold topographic lines and a lit base, on a dark background with bold red and white poster typography.

Your first serious enterprise customer is going to put you through a security review. It usually starts after the buyer already wants you, which is what makes it so maddening: the deal is sitting right there, and then it stalls for three weeks inside a questionnaire.

This is the map from zero to MVP security. Enough to clear that gate, and, more to the point, enough that clearing it actually means something. Most of what follows is good for your company whether or not an auditor ever asks.

One thing up front, because the whole piece turns on it. A checklist proves you have controls. It does not prove those controls stop the attack coming for you. We are going to do the checklist, because it is the floor. Then we are going to talk about the part that actually keeps you out of the headlines, which is the part the checklist skips.

Part 1. The checklist (do this, it is the floor)

Two artifacts your buyers will ask for by name:

  • SOC 2 Type II, in motion. Pick a compliance platform (Vanta, Drata, or similar) and start the clock. SOC 2 Type II attests that your controls actually operated over a period, not that they existed on one good day. That period is the catch: Type II needs an observation window, often three to six months, before the report exists. So the standard move is to ship a Type I first, the point-in-time version, to unblock the deal now, and let the Type II follow.
  • One recent independent penetration test, scoped to your actual application and its authentication and authorization logic, not a rebranded vulnerability scan, with the findings remediated rather than just filed. An open critical in a report a buyer can ask for is worse than no report.

Underneath those, the backbone is well settled. The cleanest version is Latacora’s SOC2 Starting Seven, and the reason it has aged so well is that every item is good for your company whether or not an auditor ever asks:

  1. Single sign-on. One identity provider, every app tied in, MFA forced.
  2. Mobile device management on every laptop (disk encryption, OS updates).
  3. A software and vendor inventory.
  4. Change management in version control.
  5. Protected deploy branches and CI/CD (review before merge, automated deploys).
  6. Centralized logging with alerts.
  7. Infrastructure as code.

Do the seven, write some basic policy docs, and you are roughly at the security maturity of a SOC 2 certified company.

Make the questionnaire a sales weapon

Most enterprise reviews are a standard questionnaire (SIG, CAIQ, or the buyer’s own). Answer it once, keep it current, and stand up a public trust page: a trust or security page, a security.txt, a security@ inbox, your subprocessor list. Most modern compliance platforms ship a trust center that does this for you. It can auto-share your SOC 2 status, gate the report behind a one-click NDA so prospects self-serve, and pull live control status, as long as you keep the integrations healthy. A green tile that is secretly stale is worse than no tile. Link it in your sales deck and your email footer, and security review starts before the buyer even asks.

And if the questionnaire is already open and blank, with a deal waiting on it, you do not need the whole program first. Answer what is true, and for every gap write “planned, target date,” never a blank and never a stretch. Then ask the buyer whether they will take a SOC 2 roadmap plus a signed security addendum in place of the finished report. At your size, most will. That is how you keep the deal moving while the program catches up.

If you do one thing this quarter for revenue, make it this. It turns a three-week deal-staller into a same-day attachment.

So far, so good. You can pass the review. Now the catch.

Part 2. Checklists only matter if they’re right

A passed audit feels like safety. It is not the same thing. The team that passed it did real, hard work, and the checklist is generic on purpose: the controls on it stop the attacks that hit the most companies, which is exactly why buyers ask for them. That is the floor, and the floor matters. The trouble is that the rubric is sized for the average company, and the adversary who targets you does not attack the average. None of what follows is a knock on the checklist. It is the part the checklist was never scoped to see. Here is what it misses.

Identity is the real perimeter, and the checklist checks the box, not the blast radius. The questionnaire asks whether you have MFA. It does not ask whether that MFA is phishing-resistant on the accounts that matter, whether a phished engineer holds a standing credential with a path to your production keys, or whether the person who left last month actually went dark everywhere instead of just in the identity provider. Presence is easy to prove. The identity graph is what gets exploited. The first move is not exotic: put phishing-resistant MFA, a passkey or hardware key and not an SMS code, on the accounts that matter most, email, your identity provider, cloud root, then trade standing keys to production for short-lived ones. Standing access is the part that turns one phished login into a bad week.

Your dependencies are your product, and the checklist asks but accepts a yes. It asks for a vulnerability scan and a change-management policy, and a checkbox answers both. It does not model that the code you pull runs where you run, and for a lot of companies where your customers run too. The xz backdoor, where an attacker spent roughly two years social-engineering his way into a maintainer’s trust before planting it in the build. The polyfill.io compromise that ran attacker code in the browsers of over 100,000 sites’ visitors after the domain changed hands. The tj-actions supply-chain attack that exposed CI secrets in the build logs of an action used by more than 23,000 repositories. The self-replicating npm worm that spread through the package registry with no human in the loop. Four different paths, a build pipeline, a browser, a CI runner, a registry, and not one of them is something a scan and a policy were built to see. The cheap first move is the one every postmortem repeats: pin your GitHub Actions to commit SHAs instead of tags, lock your dependencies, and shrink what a single poisoned package can reach.

The human layer is the live attack surface, and the checklist tests the system, not the people. It has a line for annual training, and a checkbox answers it. Most breaches are still boring: a reused password, a secret left in a public repo. But the one that walks past every control you just bought arrives as the warm inbound your growth runs on: the partnership Zoom, the investor intro, the too-good take-home test. That is the playbook state-level crews are running against developer and crypto teams right now, and it works because a human waved it in, not because a control failed. The first defense costs nothing: one written rule that no inbound recruiter or partner gets code run on a machine that can reach production, and out-of-band verification on anything that moves money or grants access.

Founder and principal exposure stops at the company boundary, and the checklist never crosses it. This one switches on at a moment, not at incorporation: when your name gets attached in public to money, custody, or a decision people resent. Then the household enters the picture. The home address rarely matters on its own. It matters as a step toward something the attacker actually wants: a SIM swap on a recovery number that unlocks a wallet, an extortion email timed to your raise, a pressure point aimed at the one person whose compromise unlocks the most. The exposure that hurts is often the pattern you publish yourself, the real-time location post, the recurring place at the recurring time. No compliance control asks whether your CEO’s home address and pattern of life are one search away. Most security advisors audit the castle. Almost nobody audits the king. It is rarely the most likely way you get hurt. It is the blind spot nobody is watching, which is what makes it worth a deliberate look. Three free first moves: run the data-broker opt-outs (or a removal service) for the founder and spouse, move account recovery off SMS, and search yourself once the way an attacker would.

Validation is the difference between faith and evidence. The checklist asks whether you have the control. It never asks whether the control fires against the attack if it ran on Monday. “We have endpoint protection” passes the audit. Nobody confirmed it catches the technique that already hit a team like yours. So generate the event and go look: replay a few real techniques against your live stack (Atomic Red Team is free and mapped to MITRE), then check your console for what actually alerted and how long it took. That will not prove you are safe. It finds the controls that are quietly broken before an adversary does, which is the only honest thing replaying an attack can claim, and most teams have never done it once.

Part 3. The sequence, so you’re not boiling the ocean

  1. Pre-answer the questionnaire and stand up a trust page. Unblocks deals now.
  2. Get SOC 2 Type II in motion and run one pentest. The artifacts buyers name.
  3. Fix identity, secrets, and CI hygiene. Passes review, and actually matters.
  4. Validate by replaying a real attack into a coverage map. Evidence, not faith.
  5. Close the human and operational-security gaps. The differentiator most teams skip, and the part real attackers count on going undone.

Most teams do steps 1 and 2 and call it done. The teams that win the big deals, and survive the bad day, do 3 through 5.

I have taken startups through this gauntlet from both sides of the table. If you are building toward your first enterprise deal and want to do it in the right order, find me on X or LinkedIn.

Sources

The checklist

Your dependencies are your product

The human layer

Founder and principal exposure