Checklist: security before a SaaS launch
For: SaaS founders and engineering teams
Updated: 2026-10
Before launching a SaaS product, eight points must hold: tested tenant isolation at data level, secure authentication with multi-factor, secrets outside the code, up-to-date dependencies, backups with tested restoration, logging of security events, abuse protection and a prepared process for security incidents.
Most security problems of young SaaS products are not sophisticated attacks but gaps that arise when building under time pressure: a forgotten authorisation check, a key in the repository, a backup never tested. Before launch they are cheap to fix; afterwards they are expensive.
This checklist is written for products on a modern stack, such as Next.js with Postgres or Supabase, and applies analogously to other architectures.
The checklist
- 01
Test tenant isolation at data level
Ensure separation between customers is enforced not only in application logic but at database level, for example with row-level security. Automated tests try to access another tenant’s data with one account.
Done when: Every table with customer data has an active isolation rule, and an automated cross-tenant access test runs in the pipeline and fails if the rule is missing.
- 02
Secure authentication
Offer multi-factor authentication and enforce it for administrators, secure password reset, sessions with expiry, brute-force protection. Plan SSO for enterprise customers.
Done when: Admin accounts can only sign in with a second factor, and password reset and session expiry are tested.
- 03
Remove secrets from code
Provide API keys, database credentials and signing keys exclusively via environment configuration, never use keys with service privileges in the frontend, scan the repository for accidentally committed secrets.
Done when: A scan of the repository including history finds no secrets, and keys with elevated privileges are used only server-side.
- 04
Update dependencies
Check and fix known vulnerabilities in libraries and frameworks, enable automatic update alerts, pin versions.
Done when: The vulnerability report shows no open critical or high findings, and automatic update alerts are active.
- 05
Test backups and restoration
Set targets for data loss and recovery time, enable point-in-time recovery or regular backups, and carry out at least one full restoration into a separate environment.
Done when: A restoration has been performed and logged with duration and result, and the targets are documented.
- 06
Log security events
Capture sign-ins, failed sign-ins, permission changes, exports and administrative actions with time and acting person, protect logs against alteration and set retention.
Done when: The listed events appear in the log, and it is defined who reviews anomalies.
- 07
Limit abuse
Set rate limits on sign-in, registration, public APIs and expensive features such as AI calls, check uploads for type and size, sign and verify webhooks.
Done when: Rate limits are active and tested on these endpoints, and incoming webhooks are processed only with a valid signature.
- 08
Prepare the incident process
Decide who decides in a security incident, how customers are informed and how data protection notification duties are checked. Keep contacts and templates ready.
Done when: A written process with roles, contacts and templates exists and is known to the team.
Common mistakes
- —Tenant isolation is only checked in API routes, and a new route forgets the filter.
- —The database service key ends up in the frontend bundle.
- —Backups run, but nobody has ever attempted a restoration.
- —AI features have no rate limit and become a cost risk.
- —The penetration test is commissioned before the basics are right and mostly finds the obvious.
What this checklist does not cover
- —This checklist replaces neither a penetration test nor a comprehensive security review by specialists.
- —It covers basics; regulated sectors and customers with their own requirements impose more, for example certifications.
- —Organisational information security such as policies, training and supplier management is covered only in passing.
- —Infrastructure outside the application, such as the team’s network and devices, is outside its scope.
Parent service: SaaS Product Development
Matching offers
SaaS security & RLS audit
A SaaS security audit targets tenant isolation specifically: is row-level security watertight, does access control hold, are typical Supabase pitfalls (service role in the client, missing RLS) avoided? The output is a finding with concrete fixes.
SaaS launch package
The launch package takes a SaaS product from idea to market: a sound architecture, the decisive core features, billing, onboarding and deployment — guided, with a clear focus on the first paying customer. The result is not a prototype but a production-ready product that can generate revenue.
FAQ
Does a new SaaS product need a pentest before launch?
With sensitive data or enterprise customers it makes sense, but only once the basics of this list hold. Otherwise you pay specialists to find the obvious.
Is tenant isolation in application logic enough?
It works as long as nobody forgets a filter. Isolation at database level, for example with row-level security, holds even then and is therefore the more robust choice.
How often should restoration be tested?
At least before launch and then on a fixed cycle, as well as after major changes to the database or infrastructure.
What does security for AI features involve?
Rate limits and cost caps, server-side permission checks for tools and an architecture that limits prompt injection. Details are in our checklist on production readiness of LLM features.
More checklists
Checklist: an AI usage policy that people actually follow
An effective AI usage policy sets out, briefly and clearly: which tools are approved, which data may go into them and which may not, that people check and own outputs, when AI use is disclosed, how new tools are approved, what training exists, how incidents are reported and when the policy is reviewed.
Checklist: vetting AI vendors and AI features before use
Before using an AI service, clarify ten questions: is your data used for training, where is data processed, how long are inputs stored, is there a data processing agreement, how is security evidenced, what is your role under the AI Act, what documentation does the vendor provide, how are model changes announced, how are costs capped and how do you exit.
Checklist: using AI safely in law firms and fiduciary offices
AI can save law firms and fiduciary offices a lot of time but touches professional secrecy and data protection directly. Use becomes safe with clarified secrecy duties, tools with a contract and no training on client data, minimised data, checking of every statement and citation, transparency towards clients, and a policy with training.