The Startup Security Baseline: 15 Things Every Seed-Stage Company Should Have

Security at seed stage is a genre where the advice tends to go in one of two directions. The first is "you are too small to worry about security" — which is wrong, because attackers do not care about your headcount, and a credential-stuffing bot does not know or respect your Series A timing. The second is "you need enterprise-grade security posture" — which is also wrong, because you will burn half your engineering team implementing controls you do not yet need.

The middle path is a specific, boring, 15-item baseline. Every seed-stage company I work with as a fractional CTO gets this list installed in the first month, usually over a single focused two-week sprint, and it covers roughly 90% of the actual security risk a 5–15 person SaaS startup faces. This article is the list.

The principle: baseline first, then differentiate

The 15 items below are not comprehensive. A mature security program has hundreds of controls, threat models, penetration tests, red team exercises, and dedicated staff. You are not going to have any of that at seed stage, and you do not need to.

What you need is the baseline that closes the obvious attack surfaces an attacker actually uses — credential theft, exposed secrets, misconfigured cloud resources, unpatched dependencies, and weak account recovery. Getting the baseline right is worth more than any fancy control you might add on top.

The 15 items

Identity and access (items 1–4)

1. MFA on everything. Every service your team uses — email, source control, cloud providers, hosting platforms, payment processors, analytics — has MFA enabled for every account. No exceptions, no "we will do it later." Use an authenticator app or hardware keys, not SMS. This alone prevents the majority of compromises.

2. SSO for every tool that supports it. Use a single identity provider (Google Workspace, Okta, or similar) and connect every SaaS tool to it via SSO. When an employee leaves, you offboard them in one place and they lose access to everything. Without SSO, your offboarding process is "delete the user in 17 places and hope you did not miss one."

3. Role-based access, least privilege. Nobody has admin access to production by default. Access is granted for a specific purpose, reviewed quarterly, and removed when no longer needed. This sounds like overhead at 5 people, but installing the habit early is the only way it actually happens at 50 people.

4. Password manager for everyone. 1Password, Bitwarden, or equivalent. Company-issued, every employee, no shared logins in spreadsheets. Shared credentials are a compliance disaster and a security disaster in equal measure.

Secrets and code (items 5–8)

5. No secrets in the repo. Install a pre-commit hook (gitleaks, trufflehog, or similar) that blocks commits containing API keys or credentials. Scan the existing history for secrets that have already landed and rotate anything you find.

6. Secrets stored in a secret manager. Production secrets live in your hosting platform's secret manager (Vercel environment variables, AWS Secrets Manager, Doppler, or equivalent). Developers cannot see production secrets on their laptops. Rotation is a one-click operation.

7. Dependency scanning in CI. Snyk, Dependabot, or GitHub's built-in dependency scanning. Every PR that adds a vulnerable dependency is flagged. You do not have to fix every finding immediately, but you should know about them.

8. Branch protection and PR reviews. Main branch requires at least one approving PR review before merge. Force-pushes are disabled. This is not just code quality — it is a security control. It means a single compromised developer account cannot silently push malicious code to production.

Infrastructure and cloud (items 9–11)

9. Infrastructure as code. Your production infrastructure is defined in code (Terraform, Pulumi, CloudFormation) and version-controlled. Not because you need fancy ops, but because "hand-configured in the console" is where silent misconfigurations live and how S3 buckets end up public.

10. Encryption at rest and in transit. HTTPS everywhere with a valid certificate. Databases have encryption at rest enabled (it is a checkbox on every managed Postgres provider). Backups are encrypted. This is boring, easy, and non-negotiable.

11. Cloud security posture basics. If you are on AWS, enable GuardDuty, CloudTrail, and S3 public-access blocks. If you are on GCP, enable the equivalents. These are near-free services that will detect obvious misconfigurations and suspicious activity without any effort from you.

Observability and response (items 12–13)

12. Centralized logging with retention. Application logs, infrastructure logs, and access logs go somewhere you can search them later, with at least 30 days of retention. Without logs you cannot investigate incidents, answer auditor questions, or debug weird production issues.

13. A written incident response plan. One page. Who is the incident commander, how do you convene the response, who talks to customers, how do you decide whether to notify regulators, and where do you keep the runbook. You do not need a polished SOC 2 policy — you need something your team can follow at 2am on a Sunday.

People and process (items 14–15)

14. Security training for the team. A one-time, 30-minute session for every new hire on the basics — phishing, password hygiene, reporting suspicious activity, what to do if they lose a device. Plus a refresher once a year. This is the cheapest control on the list and one of the highest-ROI.

15. Vendor security baseline. When you onboard a new SaaS vendor, you spend 10 minutes asking three questions: do they have SOC 2 or equivalent, where is the data stored, and how does termination work. For vendors that touch customer data, those 10 minutes will save you hours when a customer does a vendor security review of you.

Implementing it in a two-week sprint

Here is the sequence I run at client engagements.

Day 1: Inventory. List every service your team uses, every cloud account, every repository, every admin user. Most teams are surprised by how long this list is. You cannot secure what you have not inventoried.

Days 2–3: Identity sprint. Enable MFA on every service. Connect SSO everywhere it is supported. Deploy a password manager to the whole team. Audit admin access and cut anything not actively needed.

Days 4–6: Secrets and code sprint. Install the pre-commit hook. Scan history for secrets and rotate. Move production secrets into a secret manager. Turn on branch protection. Install dependency scanning.

Days 7–8: Cloud sprint. Enable GuardDuty/equivalent. Turn on S3 public-access blocks. Verify encryption at rest. Write or update your Terraform for the pieces that exist.

Days 9–10: Observability. Stand up centralized logging with 30-day retention. Make sure admin actions on the cloud account are being logged.

Days 11–12: Response plan and training. Write the one-page incident response plan. Schedule the security training session for the team.

Days 13–14: Vendor audit and loose ends. Go through the SaaS vendor list. Fill in the last items that slipped. Write a short report for the founder: what you did, what remains, what happens next.

Two weeks. One focused engineer (or fractional CTO) plus part-time contribution from the rest of the team. The result is a security posture that is dramatically better than where most seed-stage startups are, and it costs you almost nothing in ongoing overhead.

What this does not cover

Being honest about scope is part of credibility. The baseline does not cover:

Threat modeling of your specific product. Do this separately, once, when the product architecture stabilizes.
Penetration testing. Worth doing once a year starting from Series A or when a customer requires it.
SOC 2 or similar compliance. The baseline is a prerequisite, not a substitute. See my separate post on SOC 2.
Regulatory compliance in specific verticals (HIPAA, PCI, GDPR). These impose additional controls the baseline does not include.
Advanced monitoring like SIEM, EDR, or dedicated detection engineering. Leave these until you have a security owner.

If any of the above applies to your specific context, the baseline is where you start, not where you stop.

The common failure modes

Three ways I see seed-stage security programs go wrong despite good intentions.

Doing compliance without doing security. The team adopts policies from a SOC 2 platform but nobody actually enforces them. They pass the audit the first year. The second year something breaks and nothing has been maintained.

Buying tools instead of installing habits. A team buys five security tools, configures none of them properly, and has worse security than a team that just turned on MFA and called it a day. Tools are easier to purchase than habits are to install, so founders over-buy.

Hiring a security engineer too early. At 10 engineers, a dedicated security engineer is usually underused. At 30 engineers, you probably need one. Between those numbers, a fractional security advisor or a fractional CTO who understands security is enough.

Counterpoint: the baseline is not static

A caveat. The 15 items above are the baseline as of 2026. The list changes as technology and threats change. Five years ago, dependency scanning was optional; today it is not. Five years from now, there will be new items and possibly different ones. Revisit the list annually against whatever the current consensus is — do not treat this post or any other as permanent truth.

Your next step

Print the 15 items. Go through them today with your engineering lead. For each one, mark it green (done), yellow (partially done), or red (not done). Any reds get scheduled into the next two weeks. Any yellows get a ticket. You will almost certainly find at least three reds, and fixing them is the best use of a focused sprint you can make.

Where I come in

Installing the 15-item baseline is one of the most common first-month deliverables I do at fractional CTO engagements. Two weeks, one clear report, and a security posture you can confidently describe to a customer or an investor. Book a call if you want help getting there fast.