Security at a startup feels like an impossible task. You're a small team, you're moving fast, and "we'll deal with security later" is the mantra. But "later" often means "after the breach."

I've helped several organizations bootstrap their security posture from zero. Here's the checklist I will often use.

The Non-Negotiables

These are the things you do first, no matter what. They're high impact and relatively low effort. I use AWS as examples but a lot of the same could be applied to GCP, Azure, etc.

Enable MFA Everywhere

Multi-factor authentication on every account your team uses. AWS root account, GitHub, Google Workspace, Slack, all of it. This single step prevents the majority of account takeover attacks.

If someone complains about the inconvenience, remind them that resetting every credential after a breach is significantly more inconvenient.

Use an Identity Provider

Centralize authentication with an IdP (Okta, Google Workspace, Microsoft Entra ID). This gives you:

  • Single sign-on across all your tools
  • One place to revoke access when someone leaves
  • Audit logs for who accessed what and when

Encrypt at Rest and in Transit

  • In transit: TLS everywhere. No exceptions. Use AWS Certificate Manager for free certs (if you're on AWS).
  • At rest: Enable encryption on S3 buckets, RDS instances, EBS volumes. In AWS, this is usually a checkbox.

Least Privilege IAM

Stop using AdministratorAccess for everything. Create specific IAM roles for specific tasks:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-app-uploads/*"
    }
  ]
}

Yes, it's more work upfront. But when (not if) a credential leaks, the blast radius is contained.

The Next Layer

Once the non-negotiables are in place, move to these.

Dependency Scanning

Use Dependabot or Snyk (other options exist) to scan your dependencies for known vulnerabilities. Enable auto-merge for patch-level updates. This runs in the background and catches issues before they hit production.

Secret Management

No secrets in code. Ever. Use AWS Secrets Manager, HashiCorp Vault, or even AWS SSM Parameter Store. Rotate secrets on a schedule.

If you find a secret in a git commit, consider it compromised. Rotate it immediately and rewrite the git history.

Network Segmentation

Put your database in a private subnet. Put your application servers in a different subnet. Use security groups as firewalls. The default should be "deny all" with explicit allow rules.

Logging and Monitoring

You can't detect what you can't see. At minimum:

  • AWS CloudTrail for API activity
  • VPC Flow Logs for network traffic
  • Application logs shipped to a central location (better if in a separate account with limited access)
  • Alerts for suspicious patterns (failed logins, unusual API calls, privilege escalation)

Close Behind

None of these are far behind the list above. Once the basics hold, these are some of the close next steps worth picking up.

  • Back up your data and test the restores. A backup you have never restored is a guess, not a safety net.
  • Train the humans. Most breaches start with a person, so a little phishing awareness goes a long way.
  • Have a basic incident response plan. A one-page runbook and knowing who to call beats improvising at 2 AM.
  • Turn on managed threat detection. Something like GuardDuty turns the logs you are already collecting into actual alerts.

The Mindset

You'll never be "done" with security, and that's okay. The goal is to continuously reduce risk while still shipping product.

Start with the non-negotiables. Build from there. Realistically threat model. Review quarterly. And if you need help, reach out.