SaaS security checklist for product teams: ten areas to check before launch and at every release

This checklist is for product managers, engineering leads and founders who ship a multi-tenant product and must answer customer security questionnaires. Our SaaS platform engineering guide lists the security basics in a short section; this page turns them into items a team can tick, with the evidence to attach.

In this guide

• How to use the checklist
• Ten areas at a glance
• Tenant isolation: where SaaS products fail
• Identity, API and business-logic checks
• Data, secrets and the supply chain
• Logging, recovery and incident response
• Security for AI features
• Who does the review: alternatives and selection criteria
• A review plan
• How Netbase builds and checks SaaS products
• What delivery record exists, and what does not
• Limits of this guide
• Frequently asked questions
• Next step

How to use the checklist

Treat each item as a question with three parts: who owns it, what proof exists today, and when it was last checked. An item without an owner is not done, whatever the code does. Keep the answers in one place, such as the repository, so a customer's security review can be answered from the record instead of from memory.

Two rules keep the list honest. Tick an item only when a test, a log, a setting or a document shows it, and run the list against the product you operate today, not the architecture diagram.

Ten areas at a glance

Tenant isolation: where SaaS products fail

Access control is the area where web applications fail most often: the OWASP Top 10:2025 lists Broken Access Control first. For a multi-tenant product one missing tenant check can show one customer's data to another. The OWASP Multi-Tenant Security Cheat Sheet turns that into concrete controls:

• Bind the tenant to a verified identity. Take the tenant from the server-side session, not from a value the client sends, and check membership on every request.
• Scope every lookup. Include the tenant in database queries, or enforce it in the database with row-level policies, so a guessed identifier does not return another tenant's record.
• Key caches by tenant. A cache entry without the tenant in its key can serve one customer's page to another.
• Carry the tenant through queues and jobs. A background job must re-check the tenant it runs for, and storage paths and signed file links need the same scope and a short life.
• Offboard cleanly. Revoke credentials and apply the retention rule to backups and file storage when a tenant leaves.

Our multi-tenant SaaS architecture guide compares the isolation models behind these controls.

Identity, API and business-logic checks

Identity and access. Require multi-factor authentication for administrators and offer it to every user; support single sign-on for business customers who ask for it. Keep roles few and specific, expire sessions, and review administrator rights each quarter.

API security. Most SaaS features are APIs, so the OWASP API Security Top 10 (2023) is a practical test list. Start with object level authorisation (API1), authentication (API2), property level authorisation (API3), unrestricted resource consumption (API4) and function level authorisation (API5). Keep an inventory of every endpoint, including old versions: improper inventory management is API9.

Business logic. Some flaws are not bugs in one request but in a sequence: skipping a payment step, reusing an invite, or exporting more than a plan allows. API6 names this unrestricted access to sensitive business flows. Write down the intended flows for sign-up, invitations, billing and export, and test that each step is enforced on the server, not only hidden in the interface.

Data, secrets and the supply chain

• Encrypt in transit and at rest, and keep keys outside the application code with a named owner for each key.
• Classify the data. Know which fields are personal or sensitive, where they are copied, such as logs, exports and analytics, and how long each copy lives.
• Keep secrets out of repositories. Scan for them, use a secret store, give each environment its own credentials and rotate them when people leave.
• Know your dependencies. Scan packages and container images, review code before merge, and keep a record of what version runs where. The NIST Secure Software Development Framework (SP 800-218) describes the practices behind this, and OWASP's Application Security Verification Standard lists requirements you can reference in tickets.
• Treat third-party services as part of your attack surface. Each integration key is scoped to the least it needs, and OWASP calls out unsafe consumption of APIs (API10) when you trust an upstream response too far.

Logging, recovery and incident response

A product that cannot answer "who accessed this tenant's data, and when?" cannot investigate or prove anything. Log sign-ins, permission changes, exports and administrator actions with the tenant and user, protect the logs from the people they describe, and alert on repeated failures and on any denied cross-tenant attempt.

Backups only count when restored. Restore a whole environment and also a single tenant into a clean environment, record the date and the outcome, and repeat after major changes. For incident response, write a short plan with named roles, a decision on when customers are told, and a template for the notice; run a tabletop exercise before the first real incident.

Who does the review: alternatives and selection criteria

Choose by four criteria: what customers require in contracts, how sensitive the data is, how often you release, and whether anyone on the team can own security. Most products need the first two together: a routine checklist, and a test by outsiders before a major launch.

How Netbase builds and checks SaaS products

Netbase builds multi-tenant products for clients and runs its own. Its published security practices are secure code review and version control, TLS in transit and AES at rest, role-based access control, MFA for admin dashboards, vulnerability scanning and penetration testing, and disaster recovery; NDAs, data processing agreements and SLAs are available on request. Netbase holds ISO 27001 certification and a SOC 2 Type II attestation. Both cover how Netbase itself works, not a client's product or hosting, which still needs its own controls, evidence and, where customers require it, its own audit. Netbase works on AWS, Google Cloud, DigitalOcean and Cloudflare, and claims no cloud partner tier. Most Netbase projects are delivered on fixed-price contracts agreed after discovery. See SaaS development, the SaaS product accelerator for reusable accounts, tenants and roles, and application security assurance for testing. The MVP roadmap places these checks in the first weeks; to judge a vendor's answers, see security questions for a software development partner.

What delivery record exists, and what does not

• What exists. Netbase builds and operates Cloodo Workspace, a multi-tenant digital workplace, and Printcart, a SaaS serving many merchants. Since 2020 it has worked as offshore development and managing partner on a multi-tenant cloud ERP for a US client, whose name is withheld.
• What does not. No Netbase record publishes penetration test results, incident history, audit findings, vulnerability counts or response times, and none is offered as evidence that a particular control works. Nothing on this page certifies any product.

Limits of this guide

• It is a working checklist, not a compliance programme; regulated sectors such as payments or healthcare add their own requirements, so take specialist advice.
• Standards change: check the current OWASP, NIST and provider guidance on the day you review.
• A checklist cannot find unknown flaws; that is the job of testing and independent review.

Next step

Share your tenancy model, your current evidence and the questionnaires customers send you, and we will book a solution review to map gaps to the ten areas. You can also see SaaS development or more Netbase insights.

Related services and solutions