The Startup Security Checklist: Seed to Series A

You don't need a CISO. You don't need a $200k security platform. You need a list and a couple afternoons. Here's the list.

I've watched startups burn weeks trying to figure out what security work actually matters at their stage. They read a SOC 2 guide, panic, hire a consultant who sells them a roadmap for a company three sizes bigger than theirs, and end up with a spreadsheet nobody looks at. I'm going to save you that trip. This is the startup security checklist I wish someone had handed me six years ago.

How to Use This

This is organized by stage. Find where you are. Do everything in that stage. Do NOT skip items in your current stage to start on the next one. A startup with automated vulnerability scanning but no MFA on its AWS root account is a house with a security camera and no front door.

Each item has a time estimate. These are real numbers from doing this work myself across multiple environments. Your mileage may vary slightly, but they're honest.

Seed Stage — The Absolute Minimum

This is the floor. If you have a product and users, every single one of these should be done. None of them are hard. Most of them are free.

• [ ] Enable MFA on everything — GitHub, AWS, Google Workspace, whatever else your team logs into. Hardware keys are best, authenticator apps are fine, SMS is better than nothing. ~30 minutes.

• [ ] GitHub branch protection on main — Require pull request reviews before merging. Require status checks to pass. Disable force pushes. This takes ten minutes and prevents the "I accidentally pushed to main" incident that every startup has exactly once. ~10 minutes.

• [ ] Stop using long-lived AWS access keys — This one is CRITICAL. I've seen production AWS keys sitting in .env files, committed to repos, pasted in Slack DMs. Use OIDC federation for CI/CD so your pipelines authenticate without permanent credentials. If you're deploying from GitHub Actions, AWS has a native OIDC identity provider setup. No more access keys in your repo secrets. ~2 hours.

• [ ] Run containers as non-root — If an attacker gets into your container, running as root means they own the host. Add a USER instruction to your Dockerfiles. It's three lines:

RUN addgroup --system app && adduser --system --ingroup app app
USER app
WORKDIR /home/app

Do this for every service. ~15 minutes per service.

• [ ] Enable GitHub dependency review and Dependabot — Dependabot will open PRs when your dependencies have known vulnerabilities. Dependency review will block PRs that introduce vulnerable packages. Turn both on. Review the PRs weekly. ~20 minutes.

• [ ] Stop storing secrets in code — Move everything to AWS SSM Parameter Store or Secrets Manager. Parameter Store is free for standard parameters. I had a client last year who had their database password in a docker-compose.yml that was committed to a public repo. They found out when someone dropped their tables. Don't be that client. ~1-2 hours.

Pre-Series A — "We Have Paying Customers"

You have revenue. You have data worth protecting. You probably have a small team and some infrastructure that grew organically. Time to tighten up.

• [ ] Kubernetes network policies (default deny) — If you're running K8s, set a default deny policy on all namespaces and explicitly allow only the traffic you need. Most startups running Kubernetes have every pod able to talk to every other pod. That's not a cluster, that's a flat network wearing a costume. ~2-3 hours.

• [ ] IAM least-privilege audit — Go through every IAM policy in your AWS account. Find the ones with "Effect": "Allow", "Action": "*", "Resource": "*". Remove them. Replace them with policies that grant only what's needed. This is tedious. Do it anyway. ~half day.

• [ ] Basic incident response plan — Write down what you do when something goes wrong. Who gets called. What gets shut down. Where the logs are. This can be a Google Doc. It does NOT need to be a 40-page playbook. When your database is leaking at 2am, you will not remember any of this unless it's written down somewhere your team can find it. ~2 hours.

• [ ] Centralized logging — Get your application logs, access logs, and AWS CloudTrail logs into one place. CloudWatch is fine. Datadog is fine. Whatever you pick, make sure you can actually search it when something goes wrong. Logs in five different places are the same as no logs. ~half day.

• [ ] Automated vulnerability scanning in CI — Add Trivy to your CI pipeline. It scans your container images for known CVEs and flags them before they hit production. Here's a GitHub Actions step that does it:

- name: Scan image for vulnerabilities
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: ${{ env.IMAGE_NAME }}:${{ github.sha }}
    format: table
    exit-code: 1
    severity: CRITICAL,HIGH

Set exit-code: 1 so the build fails on critical and high vulnerabilities. Don't set it to fail on medium — you'll never merge anything. ~1 hour.

• [ ] Access reviews — Make a spreadsheet. List every system, every person, what access they have. Do this quarterly. Remove access for anyone who left or changed roles. The first time takes a couple hours. After that it's 30 minutes if you keep it current. ~2 hours first time.

Series A — "Enterprise Prospects Are Asking"

You're going to start getting security questionnaires from potential customers. Enterprise buyers will ask if you have SOC 2. Your sales team will start pinging you about compliance. Here's what to get in place.

• [ ] SOC 2 readiness assessment — Don't jump straight into a SOC 2 audit. Do a readiness assessment first. Identify your gaps. Fix them. Then engage an auditor. Going straight to audit is like taking the final exam without attending the class. ~1-2 weeks (ongoing).

• [ ] Security questionnaire template — You're going to get the same 200 questions from every enterprise prospect. Pre-fill a template with your answers. Store it somewhere your sales team can find it. Update it when things change. This alone will save your team HOURS per deal. ~1 day first time, then maintenance.

• [ ] Formal change management — If you're already doing pull requests with required reviews, congratulations, you're already doing change management. Document it. Write down that all changes go through PRs, PRs require review, and reviews check for security implications. That's your change management process. ~2 hours to document.

• [ ] Vendor security assessment process — Before you plug in a new SaaS tool, ask basic questions. Where is data stored. Who has access. Do they have SOC 2. What happens to your data if you cancel. Keep a simple spreadsheet of vendors and their answers. ~2 hours to set up.

• [ ] Employee security training — This does not need to be a week-long course. A 30-minute annual session covering phishing, password hygiene, and how to report suspicious activity is enough to start. Record it so new hires can watch it during onboarding. ~half day to create, 30 minutes annually.

• [ ] Backup and disaster recovery testing — You have backups. You probably haven't tested restoring from them. Do it. Set a calendar reminder to do it quarterly. The backup you've never tested is not a backup. It's a hope. ~half day.

The Priority Matrix

Not sure where to start? Use this:

Start in the top-left quadrant. Work your way right, then down. The bottom-right items matter, but they don't matter MORE than the top-left items. I've seen a startup spend two months on SOC 2 prep while their production database had no password. Priorities.

Start Where You Are

Security isn't a destination. It's a direction. You don't wake up one morning and your infrastructure is secure. You wake up, do the next thing on the list, and keep going.

I spent years as an SRE watching incidents that could have been prevented by one afternoon of work somebody kept putting off. The items on this list aren't theoretical. They're the ones that would have stopped real incidents I've seen with real companies.

Pick the first unchecked item that matches your stage. Block two hours on your calendar. Do it today. Then do the next one tomorrow. In two weeks you'll have a security posture that puts you ahead of 90% of startups at your stage.

That's not a sales pitch. That's just what happens when you show up and do the work.