The minimum viable security posture for a 10-person SaaS

Security advice has a distribution problem. Most published content either targets enterprises — complete security programs, CISO hiring guides, SOC 2 readmaps — or developers who have never thought about it at all. The 10-person SaaS team sits in an uncomfortable middle: past the basics, carrying real customer data, starting to see enterprise leads ask about your security posture, but with no dedicated engineer, no consultancy budget, and a product roadmap that cannot pause for a six-week compliance project.

The eight controls below are sorted by a single metric: how much attack surface do you close per engineer-hour spent? They address the four vectors that account for most small-SaaS breaches: credential theft, secrets exposure, vulnerable dependencies, and cloud misconfiguration. Do them in order.

Why compliance-first advice does not help at this stage

The security content that gets traction in search is almost entirely compliance-driven: SOC 2, ISO 27001, NIST CSF. These frameworks are valuable at scale, when you have staff to maintain controls, budget for annual audits, and enterprise contracts that require the certification. They are the wrong starting point for a team of 10.

The framing mistake is treating compliance as a security outcome rather than a signal. A company that is SOC 2 Type II compliant can still be breached through a single compromised developer laptop. A company with none of those certifications but strong foundational controls is materially safer. At your stage, foundational controls are what you are buying.

Security guides are also mostly written by people whose incentive is scope expansion: more controls, more policies, more tooling. A 10-person team does not need 40 policies. It needs the specific things that stop the specific attacks that happen to companies your size.

The framework: coverage per engineer-hour

Your actual threat model is narrower than you might think. Automated credential stuffing, opportunistic supply-chain exploits, and misconfigured cloud resources swept by bots account for most incidents at companies your size. The breach vectors that matter, roughly in frequency order:

• Credential theft: compromised accounts from reused passwords or phishing
• Secrets exposure: API keys and credentials committed to code repositories
• Supply-chain exploits: running libraries with known CVEs
• Cloud misconfiguration: overly permissive IAM roles, publicly exposed storage
• Cross-tenant data exposure: broken access control between customer accounts

The controls below map to these five vectors. The time estimates are for initial implementation on a single-product startup, not ongoing maintenance cost.

Week one: four controls, roughly a day of work in total

1. MFA on every internal account (one hour)

Enforce multi-factor authentication on every account that can reach your production environment or customer data. Google Workspace or Microsoft 365 admin console, AWS root and all IAM users, GitHub organisation members, and anything connecting to production databases. Enforce it at the IdP level, not as a personal preference.

TOTP is sufficient. Hardware security keys add value for high-privilege accounts but are a later optimisation. The return from no MFA to TOTP is enormous; the marginal return from TOTP to hardware keys is much smaller. Take the large return now.

2. Secrets out of version control (two hours)

Run this across every repository you own:

git log --all -p | grep -iE '(password|secret|api_key|token|private_key)' | head -200

You will find something. Every team does. Rotate every secret that appears in the output before anything else. Then move all secrets to a dedicated manager: AWS Secrets Manager, Google Secret Manager, Doppler, or HashiCorp Vault all work. Once you have a manager, add a pre-commit hook or CI step that fails on any commit matching credential patterns.

The rotation step is what teams skip. Removing a secret from Git history without rotating the actual credential is cosmetic work. The credential is still valid if someone already has a copy of the commit. Rotate first.

3. Dependency scanning in CI (two hours)

Enable Dependabot on GitHub or Snyk's free tier on every repository. Configure it to block merges when it detects high or critical CVEs. This covers supply-chain exposure with near-zero ongoing maintenance: you review automated PRs and merge them.

Most supply-chain attacks at the scale you are at exploit publicly known vulnerabilities with published patches. Automated scanning closes the gap between 'CVE disclosed' and 'you shipped the patch'. It does not prevent zero-days. Zero-days targeting 10-person teams are uncommon. Known-CVE exploitation is not.

4. IAM least privilege (four hours)

Pull every IAM role in your cloud provider and delete any with wildcard permissions that are not attached to a specific, named, justified purpose. Each service should have its own role with exactly the permissions it needs. Developer accounts should not have production database access by default; that should require a separate, logged, time-limited escalation.

Four hours covers an initial cleanup pass. Use AWS IAM Access Analyzer or the equivalent in your cloud provider to surface roles with excessive permissions automatically. The first pass eliminates the highest-risk configurations; a thorough review can come later.

Month one: four more controls that close most remaining gaps

5. Encryption at rest and in transit (one day)

Verify that your production database and any object storage holding customer data has encryption at rest enabled. For managed cloud databases — RDS, Cloud SQL, Managed PostgreSQL — this is typically a toggle rather than a migration. Check the configuration; do not assume the default was set correctly when the instance was provisioned.

Separately, verify TLS 1.2+ across all public endpoints. SSL Labs' free server test surfaces the common issues: misconfigured certificates, weak cipher suites, broken certificate chains. A one-hour audit often finds real problems.

6. Auth event logging with alerting (two days)

Log every login attempt, privilege escalation, and production database connection. Ship those logs to a centralised sink your application does not have delete access to: CloudWatch, Datadog, Papertrail, or Logtail all work. Retain for 90 days minimum.

Set alerts on three patterns: more than three failed login attempts in 60 seconds from a single IP, any root account login, and any production database connection outside business hours. These three alerts surface most active intrusions.

The average breach dwell time for small companies is measured in weeks. That is not because detection is technically hard. It is because most teams have no alert configured to catch it.

7. Tenant isolation in your data model (one week)

For B2B SaaS: every query touching customer data should filter by tenant_id at the application layer, enforced by middleware or a base model that makes the filter structurally impossible to omit. Test this explicitly by trying to read tenant A's data while authenticated as tenant B. If it works, you have a data isolation bug regardless of what your code review shows.

8. A two-page incident response plan (half a day)

Not a 40-page CISO handbook. A shared document every team member can find in under 60 seconds, answering six questions: Who calls first if a customer reports a potential breach? Who decides whether to take the service down? What is your notification timeline. India's DPDP rules require notification to CERT-In within 72 hours for significant personal data breaches? Who owns customer communication? Where are the centralised logs? How do you revoke all active sessions immediately?

Write it in two hours. Review it every six months. The value is not in the document itself; it is in having had the conversation about those six questions before 2 a.m. when you actually need the answers.

All eight controls at a glance

What to defer until you have a dedicated security function

Skip these for now, and ignore anyone who tells you otherwise at this stage:

• SOC 2 Type II is relevant when enterprise sales requires it. Most Series A companies have not started this yet. A first audit runs $30,000 to $80,000 all-in and requires staffing controls you probably do not have.
• Penetration testing is worth it once you have addressed the foundational controls and want to find what you missed. A pentest before you have done the eight controls above returns a list of things you already know about.
• A web application firewall is worth it at scale. At 10 people, rate limiting in your application and a basic DDoS protection tier from your cloud provider cover the same attack surface at a fraction of the cost.
• Security awareness training platforms do not beat a 30-minute internal session on phishing and credential hygiene outperforms a $15/user/month platform that developers resent and do not log into.

The test for deferral: does this control address one of the five breach vectors in the framework section? If not, it waits.

The quarterly review that matters most

Once the eight controls are in place, most ongoing maintenance is automated: Dependabot runs on its own, IAM Access Analyzer runs continuously, alerting fires when something happens. There is one manual review worth a calendar slot every 90 days: which of your top ten secrets were last rotated, and when?

Block an hour. If you cannot answer that question in under five minutes, secrets hygiene has drifted. Most breach post-mortems at small companies include the finding that credentials used had not been rotated in over a year. The quarterly rotation review is the one thing that does not automate cleanly and that teams reliably skip.

Security at 10 people is not a project you finish — but it is also not a treadmill. Get the eight controls in, automate what you can, review secrets rotation quarterly. The compliance programme can come when the revenue and enterprise contracts justify it.