Most seed-stage startups do too much security or too little. Both end badly. The teams who do too little end up with a public incident, a lost customer, or an awkward call with their first enterprise prospect. The teams who do too much spend six months of a seven-person team on SOC 2 Type 2 and ship their actual product five months late. Neither failure is dramatic. Both are expensive.

What follows is the shape of what I call the security floor: the minimum posture a seed-stage startup should ship with. Anything below it is negligence. Anything above it, at your stage, is theater. The floor itself takes a few weeks of focused work to put in place, not a quarter.

What “The Floor” Actually Means

A seed-stage team of three to seven engineers has a specific operational shape. You have a small number of production systems, a small number of secrets, a small number of people who touch production, and roughly zero spare engineering hours for security theater. The floor is designed around those constraints. It is not “lite security.” It is the full set of controls that actually matter for your real risk profile, with the controls that only matter at Series B scale explicitly left out.

Teams miss the floor in two directions. The common failure is drifting below it: the team was going to add MFA, was going to move secrets out of the repo, was going to retire the admin AWS key. None of it happened because none of it was anyone’s job. The less common but more interesting failure is overshooting: the team committed to a SOC 2 Type 2 audit before they had five paying customers, and spent the next two quarters implementing controls that would not have changed any real outcome.

Below the Floor

What I see at teams who are below the floor, in rough frequency order:

  • MFA is not enforced on GitHub, cloud, email, or Slack. At least one of them has at least one account that could be taken over with a reused password.
  • Production secrets live in a .env file that was once pasted in a Slack DM. The DM was never deleted.
  • Every engineer has prod admin credentials, because setting up least-privilege IAM felt like it would slow onboarding.
  • Staging and production share a database, because the migration to split them was always next sprint.
  • Backups run every night, and nobody has ever restored one. The “backup” is a snapshot, not a verified restore.
  • There is no audit log of who did what in production. If a bad action happened at 3am, there is no record of who ran it.
  • Dependency updates happen when something breaks. Nobody is scanning for known CVEs in dependencies.
  • There is no plan for the first vulnerability report. When a researcher emails security@, nobody owns the response.

 

Each one of those is small. Together they are the shape of a team that will have an incident, and when it happens, will handle it badly.

The Floor

This is the posture I tell seed-stage teams to ship with. Not aspirationally. Actually ship with. A focused two-engineer week handles most of it.

1. MFA everywhere that touches production

Every account on every service that can affect production. GitHub, cloud provider, email, Slack, 1Password, the DNS registrar, the domain registrar, every third-party tool with an API key that can read customer data. Enforce it at the org level where possible, so a new hire cannot opt out. The number of real-world incidents I have seen that would have been stopped by universal MFA is uncomfortably high.

2. A secrets manager, not a .env file

AWS Secrets Manager, GCP Secret Manager, Doppler, 1Password Secrets Automation, HashiCorp Vault’s cloud offering. Pick one. The important thing is that no production secret lives in a repository, in a Slack message, or on an engineer’s laptop in plaintext. Rotation becomes possible once this is in place. Rotation is impossible before it.

3. Least-privilege IAM

Nobody uses the root cloud account. Every human has their own identity. Every service has its own identity. Every identity has only the permissions it actually uses. The CI pipeline does not have admin. The staging environment cannot write to production. These are configuration choices, not projects. They take a day each to put in place and save you from a very specific class of 3am incident.

4. Verified backups

Nightly backups of your production database. A quarterly restore drill where you actually spin up the backup in an isolated environment and prove it works. “We have backups” and “we have working backups” are different sentences. Teams that have had an incident know which one they shipped with.

5. Dependency scanning on

Dependabot, Renovate, or your language ecosystem’s equivalent. Default settings. No cleverness required. The point is that known CVEs in your dependencies get flagged and show up as pull requests. The team can then triage. Without this, you are relying on nobody noticing the vulnerability.

6. An audit log on production access

Who logged into the production database. Who ran a shell on the production server. Who assumed the production IAM role. Every modern cloud provider gives you this for free, you just have to turn it on and point it at a bucket that is not in the same account you are auditing. Six-month retention is enough at seed stage.

7. A security.txt and a one-page response plan

A security.txt file at your domain root tells well-meaning researchers how to reach you. A one-page document tells your team what to do when a report comes in: who triages, who confirms, who patches, who talks to the reporter, how long each step should take. You will get your first vulnerability report. Having the plan written down turns the hour you receive it from chaos into a workable morning.

Above the Floor at Seed Stage

These are all legitimate security investments. They are also, at seed stage with a team of five, almost always theater.

  • SOC 2 Type 2. Legitimate at the point where you have an enterprise customer who will not sign without it, or several in the pipeline who will. Premature when you are still finding product-market fit. The six months of controls work does not change your real security posture by much once the floor is in place. It just produces an auditor’s report.
  • A full-time Chief Security Officer. This hire pencils out at roughly fifteen engineers for a security-adjacent product and roughly thirty engineers for one that is not. Hiring one earlier produces a function with nothing to do except invent process that slows the team.
  • Custom WAF rules and bot management. Default rules from your cloud or CDN handle ninety-plus percent of what WAFs catch at your stage. Custom rules are a Series B investment.
  • Penetration testing. Useful once you have paying enterprise customers who want to see the report. Not useful as a self-driven exercise before you do.
  • Custom DLP and insider-threat tooling. Below Series B, these solve problems you do not have yet.

 

If you are reaching for any of these before you can honestly say the floor is in place, you are optimizing for the wrong failure mode.

The AI-Era Addition

Three things to add to the floor at an AI-first startup in 2026.

First, treat your LLM provider API keys like production secrets. They are production secrets. They go in the secrets manager, they rotate on a schedule, and they live in short-lived environments where possible. A leaked LLM API key with your organization’s billing attached is a very bad week.

Second, if you ship agents that take tool actions on behalf of users, keep an explicit allowlist of tools per agent and per user tier. Tool descriptions are not a security boundary. The runtime check is.

Third, assume prompt injection is possible in any input you treat as model-visible. The specific controls here are still evolving, but the baseline posture is: treat untrusted model-visible input the way you treat untrusted HTML. Sanitize at the boundary. Do not pass through tool-call outputs as instructions.

A Five-Minute Diagnostic

Walk through these questions out loud with your team. If you cannot say a clean yes to any of them, that is your next week of work.

  • Does every account that touches production require MFA, enforced at the org level?
  • Is there any production secret, anywhere, that is not in your secrets manager?
  • Can anyone on the team describe, from memory, who has prod admin and why?
  • When was the last time you restored a backup to an isolated environment and verified it works?
  • If a researcher emailed [email protected] this afternoon, does anyone know who owns the response?

 

Teams who answer five clean yeses are at the floor. Teams who answer four are typically one short, focused week from it. Teams who answer two or fewer have a backlog.

Let’s Talk

If you are a seed-stage founder trying to figure out whether your team is at the floor, over it, or still below it, and want a second pair of eyes before you commit to a quarter of SOC 2 work or a full-time security hire, that is exactly the kind of decision I help work through with founders. No pitch. Happy to walk your current posture and tell you what I would do. Reach out.