SaaS security checklist · auth, isolation, data, infra, vendors

Ship a SaaS you can actually defend.

A practical security checklist for SaaS teams, covering authentication, tenant isolation, data protection, infrastructure, secrets, logging, and vendor risk. Most breaches are not exotic zero-days — they are a missing authorization check, a leaked key, or a tenant boundary nobody tested. This is the baseline that closes those gaps.

7 sections, ~40 controls

Review in an afternoon

For founders & engineering leads

Why a SaaS security baseline matters

Most SaaS incidents are not sophisticated. They are an authorization check that was never written, a database query that forgot to scope by tenant, an API key committed to a repo, or a database left reachable from the public internet. Each one is mundane in isolation; each one has ended companies. The job of a security baseline is to make the mundane mistakes hard to make and easy to catch.

This checklist gathers the controls we apply on every SaaS platform we build. It is organized so you can hand it to your team and work top to bottom. If you want formal definitions of the terms here, the zero trust and encryption at rest glossary entries are quick primers, and the SOC 2 report entry explains what auditors expect.

1. Authentication & access control

Enforce strong authentication: support multi-factor authentication, and require it for admin and privileged accounts without exception.
Use a vetted identity mechanism — OAuth 2.0, OIDC, or a reputable auth provider — rather than rolling your own password and session handling.
Hash passwords with a modern, slow algorithm (bcrypt, scrypt, or Argon2) and never store or log them in plaintext.
Enforce authorization on the server for every request; never trust a client-supplied role, and never rely on an unguessable URL as access control.
Apply least privilege to user roles and to internal service accounts, and review elevated access on a recurring schedule.
Expire and rotate sessions sensibly, invalidate them on logout and password change, and rate-limit login and password-reset endpoints.

2. Tenant isolation

Scope every database query by tenant, and verify isolation server-side on each request rather than assuming the UI hides other tenants' data.
Test cross-tenant access deliberately: attempt to read and modify another tenant's records by ID and confirm the request is refused.
Isolate tenant data in storage, caches, and background jobs, not just in the primary database, so an export or async task cannot leak across tenants.
Avoid global identifiers that are guessable or sequential where they grant access; pair them with an authorization check every time.
Where the threat model demands it, consider stronger isolation — separate schemas or databases — and document the trade-off you chose.

3. Data protection & privacy

Encrypt data in transit with TLS everywhere, and encrypt sensitive data at rest using managed keys.
Classify what data you hold, minimize collection of sensitive fields, and define retention so you are not storing data you no longer need.
Protect personally identifiable and regulated data according to the rules that apply to you, and support deletion and export requests.
Mask or tokenize the most sensitive fields, and never expose secrets, tokens, or full payment details in logs or error responses.
Restrict and audit access to production data; engineers should not query customer data casually or without a logged, justified reason.

4. Infrastructure & network

Define infrastructure as code so configuration is reviewable, reproducible, and not changed by hand in a console under pressure.
Lock down network access with private subnets, security groups, and the principle of least exposure; do not put databases on the public internet.
Patch operating systems, runtimes, and dependencies on a schedule, and track known-vulnerable packages with automated scanning.
Harden cloud accounts: enforce MFA on the root and admin identities, separate environments, and avoid long-lived broad-scope credentials.
Put a web application firewall and rate limiting in front of public endpoints, and design for graceful degradation under abuse.

5. Secrets management

Store secrets in a dedicated secrets manager, never in source control, environment files committed to a repo, or plaintext config.
Scope each credential to least privilege and support rotation, so a single leaked key can be revoked without taking down every integration.
Scan repositories and CI logs for accidentally committed keys, and rotate immediately if one is exposed.
Use short-lived, automatically issued credentials for service-to-service access where your platform supports it.
Separate secrets per environment so a development key can never touch production data.

6. Logging, monitoring & recovery

Log authentication events, authorization failures, and administrative actions, and retain logs long enough to investigate an incident.
Centralize logs and alert on the signals that matter — repeated auth failures, privilege changes, and unusual data access — not on noise.
Protect logs from tampering and ensure they do not themselves capture passwords, tokens, or sensitive payloads.
Maintain an incident response plan with named owners, communication steps, and a path to notify affected customers when required.
Run backups, encrypt them, and test restoration so a ransomware event or bad deploy does not become permanent data loss.

7. Third-party & vendor risk

Inventory every third-party service and subprocessor that touches your data, and review their security posture before you onboard them.
Prefer vendors that can produce a SOC 2 report or equivalent evidence, and record the data each one processes on your behalf.
Limit what each integration can access, use scoped API keys, and remove access promptly when a vendor relationship ends.
Track your dependency on critical vendors and have a plan for an outage or a breach on their side, not just on yours.

How to apply the checklist

Do not try to do everything at once. Walk the list and mark each item as done, partial, or missing, then triage. For a small team, the highest-leverage trio is authentication, tenant isolation, and secrets management — weak auth, a leaking tenant boundary, or a hardcoded credential is where a single mistake becomes an existential incident. Fix those first, then work outward to infrastructure, logging, and vendor review.

Treat the checklist as living. Re-run it before a major launch, after a big architectural change, and on a recurring cadence so controls do not quietly decay. It pairs naturally with a deliberate threat-modeling exercise and with the OWASP Top 10, which catalogs the application-level failures this list is designed to prevent.

How this connects to our work

Security is not a phase we bolt on at the end; it is how we build. The controls here are the default starting point for every SaaS platform development engagement, and they are what our penetration testing work validates from an attacker's point of view. When we run a web application pentest, this is the kind of baseline we expect to find — and the gaps we find are usually somewhere on this list.

If you are preparing for a customer security review or a SOC 2 audit, or you want an independent look at how defensible your SaaS really is, see how we scope and price the work or reach out to talk it through.

Frequently asked questions

Is this checklist enough to pass a SOC 2 audit?

No checklist replaces an audit, but these controls map closely to the technical security expectations a SOC 2 examiner looks for. Treat this as the engineering groundwork: implement the controls, document them, and an auditor has far less to push back on. Formal compliance still needs policies, evidence collection, and an independent assessor.

We are a small team. Which items matter most first?

Start with authentication, tenant isolation, and secrets management. Weak auth, leaking one tenant's data into another, and a hardcoded credential in a repo are the three failures most likely to end a startup. Everything else is important, but those three are where a single mistake becomes an existential incident.

How is SaaS security different from a one-time pentest?

A penetration test is a point-in-time check of how an attacker could break in today. This checklist is about the ongoing controls that keep you defensible between tests — least privilege, encryption, logging, patching, and vendor review. The two are complementary: the checklist builds the baseline, the pentest validates it.

Does multi-tenant SaaS need special security attention?

Yes. The defining risk of multi-tenant SaaS is one customer seeing another customer's data through a missing authorization check or a query that forgets to scope by tenant. Tenant isolation has to be enforced server-side on every request and tested deliberately, not assumed because the UI hides the data.

Related resources & reading

Web App Pentest Checklist

The attacker's-eye view of the controls in this list.

Vendor Security Questionnaire Template

Vet the third parties that touch your data.

Incident Response Plan Template

What to do when a control fails and an incident hits.

Cybersecurity for SaaS Startups

How early-stage SaaS teams should sequence security work.

Want a second opinion on your SaaS security?

Whether you are hardening a baseline before a launch or preparing for a customer security review, we can pressure-test your controls and tell you where the real risk is. See how engagements are priced or book a call.