SaaS Pre-Launch Security Checklist: What to Audit Before Your First Enterprise Deal

A SaaS pre-launch security checklist is not a compliance checkbox—it is the document that decides whether your first enterprise prospect signs the contract or sends you a rejection after a 90-day security review. Enterprise buyers now run detailed vendor security assessments before any production deployment, and they routinely disqualify products that lack basic controls like enforced MFA, documented data isolation, or a vulnerability disclosure process. Getting this right before launch is far cheaper than retrofitting it after a $200K deal stalls on a security questionnaire.

This guide covers six security layers every SaaS product must harden before launch: authentication and session management, authorization and multi-tenant data isolation, API security, secrets management, infrastructure hardening, and audit logging. For each layer we cover the specific checks, the tools to run them, and the findings that enterprise security teams flag most often. This is the same review process a Belsoft security engineer works through when a SaaS team arrives three weeks before their first enterprise pitch.

If you built with an AI coding tool like Lovable, Bolt, Cursor, v0, or Replit, read our post on vibe-coded app security risks for enterprise teams first—AI-scaffolded apps have a specific set of default misconfigurations that this checklist assumes you have already addressed before running the deeper review below.

Why Pre-Launch Security Review Determines Enterprise Sales Velocity

Enterprise security review has changed. Five years ago, a startup could win a mid-market deal on product functionality alone and address security requirements in a follow-up statement of work. Today, most companies with more than 500 employees have a mandatory security questionnaire—often 150–300 questions—that vendors must complete before procurement can proceed. Many use third-party platforms like SecurityScorecard, BitSight, or Vanta-connected supplier portals that automatically scan your external attack surface alongside your questionnaire answers.

The consequences of failing this review are not just losing the deal. A single critical finding—an open S3 bucket, an exposed admin route, an unauthenticated API endpoint—can trigger a mandatory remediation period with a defined SLA, a third-party penetration test at your cost, or permanent disqualification from the procurement process. The fastest SaaS sales teams invest in security before the first enterprise conversation, not after the first rejection.

• →Pre-launch security investment: 40–80 engineering hours to harden existing code and write the documentation a questionnaire requires.
• →Post-rejection remediation: 200–400 engineering hours to retrofit controls, run a penetration test, produce a remediation report, and re-engage the prospect—if they re-engage at all.
• →The hidden cost of a delayed deal: a $150K ARR enterprise contract that takes 6 extra months to close because of security gaps costs $75K in delayed revenue plus the engineering time spent on the fix.
• →Security as a sales accelerator: a SOC 2 Type II report, a clear data processing addendum, and a documented vulnerability disclosure process turn a 90-day security review into a 2-week fast track at a growing share of buyers.

Layer 1 — Authentication and Session Management

Authentication is the first thing an enterprise security reviewer checks and the layer where SaaS products most frequently have gaps. The most common findings are not exotic vulnerabilities—they are missing MFA enforcement, sessions that never expire, and password reset flows that are trivially enumerable.

• →Multi-factor authentication: MFA must be enforced for all user accounts, not just admin accounts. Many enterprise procurement policies require MFA as a hard requirement. Using an identity provider like Auth0, Clerk, or Supabase Auth makes enforcement easier than implementing it yourself.
• →SSO support: larger enterprise buyers require SAML 2.0 or OIDC-based SSO so they can manage user provisioning through their identity provider. You do not need SSO at pre-launch, but you need a documented roadmap and a cost estimate when they ask.
• →Session expiration: sessions must expire after inactivity—typically 15–30 minutes for admin interfaces, 1–4 hours for standard interfaces—and must be invalidated server-side on logout. A JWT that never expires is one token-leak away from permanent account compromise.
• →Password policy and breach detection: require passwords of at least 12 characters, reject common passwords using Have I Been Pwned (the API is free), and enforce account lockout after 5–10 failed login attempts with exponential backoff.
• →Account enumeration prevention: return identical error messages for 'email not found' and 'incorrect password'. Differentiated messages allow an attacker to enumerate valid email addresses from your sign-up or login form.
• →Brute-force protection: rate-limit authentication endpoints independently of your global API rate limit. An attacker who bypasses your CDN rate limit should still hit a per-endpoint limit before testing more than a few hundred passwords.

Layer 2 — Authorization and Multi-Tenant Data Isolation

Data isolation is the layer where multi-tenant SaaS applications have the highest-severity vulnerabilities. A single insecure direct object reference (IDOR) in a resource endpoint can allow any authenticated user to read or modify any other tenant's data. If you use Supabase, read our Supabase RLS security guide alongside this section—RLS misconfiguration is the leading cause of data exposure in Supabase-backed SaaS products.

• →Authorization on every endpoint: every API endpoint that reads or writes user or tenant data must verify that the authenticated user has permission to access the specific resource being requested—not just that the user is authenticated. Check resource ownership or org membership at the handler level, not at the routing level.
• →IDOR testing: for every endpoint that accepts a resource ID (UUID, integer, or any identifier), test whether a user from tenant A can access resources belonging to tenant B by substituting IDs in requests. This test catches the most common critical-severity finding in SaaS security reviews.
• →Row-level security in the database: if your database supports row-level security (Postgres, MySQL 8 with views), enforce tenant isolation at the database layer rather than relying solely on application code. Application-layer authorization is one missed check away from a bypass; database-layer RLS is a much harder line to cross.
• →Privilege escalation: test whether a standard user can grant themselves admin rights through any API endpoint. Specifically check role assignment endpoints, invitation flows, and any endpoint that updates user metadata.
• →Horizontal privilege escalation: test whether a user can modify their own role or org membership by crafting a direct request to an update endpoint that your UI does not expose but that exists in the API.

Layer 3 — API Security and Input Validation

API security covers input validation, rate limiting, and the endpoints and data you expose to the public internet. Enterprise security questionnaires specifically ask about your input validation practices and whether you have OWASP Top 10 protections in place.

• →Input validation and schema enforcement: validate and sanitize all user input at the application boundary. Use a schema validation library (Zod, Joi, class-validator) and reject requests that fail schema checks with a 400 error. Never trust input from the client, never try to sanitize malformed input rather than rejecting it.
• →SQL injection: use parameterized queries or an ORM for all database operations. Never concatenate user input into a SQL string. Even if you use an ORM, verify that any raw query calls (Prisma's $queryRaw, TypeORM's query, Knex's raw) pass parameters correctly.
• →Rate limiting: apply rate limits at three levels—per IP, per authenticated user, and per API key. Use a sliding window algorithm rather than a fixed window, which is trivially bypassed by timing requests around window resets.
• →Authentication on every route: verify that your router has no accidentally public endpoints. In Next.js API routes, middleware can be bypassed if a handler omits the auth middleware call. Write an integration test that sends an unauthenticated request to every route that should require authentication.
• →Dependency vulnerabilities: run npm audit or Snyk before launch. Critical and high-severity CVEs in your direct or transitive dependencies are flagged by the automated scanners enterprise security teams run against your domain.

Layer 4 — Secrets Management and Environment Configuration

Exposed secrets are the most common critical finding in automated security scans. An API key committed to a repository, embedded in a Docker image, or returned in an API response gives an attacker immediate authenticated access to the service it protects. Our security audit service finds exposed secrets in roughly 40% of first-time SaaS assessments—often in a .env file committed months ago and forgotten.

• →Git history scanning: run truffleHog, gitleaks, or DeployReady against your full git history—not just the current HEAD. A secret deleted from the latest commit remains in git history and is fully recoverable. If a secret was ever committed, rotate it immediately regardless of whether it still appears in the latest code.
• →Environment variable management: never commit .env files. Use a secrets manager (AWS Secrets Manager, Doppler, 1Password Secrets Automation) to inject secrets at runtime. Your .gitignore should explicitly block .env, .env.local, .env.production, and every environment file variation your framework uses.
• →Principle of least privilege for API keys: each service in your stack should have its own API key with only the permissions it needs. A single admin key shared across services means one compromised service can affect all others. Rotate keys after any suspected exposure.
• →Service account credentials in CI/CD: audit your CI/CD pipeline configuration for hardcoded credentials. CI environment variables with access to production systems should be stored in your CI provider's encrypted secrets store and scoped to the specific pipelines that need them.
• →Public cloud storage: verify that every storage bucket (S3, GCS, Azure Blob) containing user data is private. Run a bucket policy audit and check that no ACLs grant public read access. Misconfigured S3 buckets remain one of the most frequently disclosed breach causes in SaaS products.

Layer 5 — Security Headers, TLS, and Infrastructure Hardening

Infrastructure security is the fastest layer to fix and the layer that automated scanners catch most reliably. These are configuration changes, not code changes—most can be resolved in hours rather than days.

• →TLS everywhere: all traffic must use HTTPS with TLS 1.2 or higher. Redirect HTTP to HTTPS with a 301. Verify your TLS certificate configuration with SSL Labs' server test—a misconfigured certificate chain or weak cipher suite is a common automated-scan finding.
• →Security headers: add Content-Security-Policy, Strict-Transport-Security (max-age of at least 31536000 with includeSubDomains), X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, and Permissions-Policy. In Next.js, set these in next.config.js headers(). Verify with securityheaders.com.
• →CORS policy: define your CORS allowed-origins explicitly and do not use wildcard (*) origins for authenticated endpoints. Verify that CORS headers are set at the application layer and that your API does not rely on server defaults that could allow cross-origin requests from any domain.
• →Admin interfaces: never expose admin interfaces on the public internet without IP allowlisting, VPN, or strong authentication separate from your standard user auth flow. An admin panel accessible at /admin with only password protection is a brute-force target.
• →Attack surface minimization: remove unused dependencies, open ports, and debug endpoints before launch. Run a port scan against your production IP range and verify that only the expected ports are accessible.

Layer 6 — Audit Logging and Incident Response Readiness

Enterprise buyers routinely ask whether you log security-relevant events, how long you retain those logs, and what your incident response process looks like. These questions appear in security questionnaires and in due diligence reviews for SOC 2 compliance. The difference between a SaaS product that fails due diligence and one that passes is often not the security posture itself—it is the documentation of that posture.

• →Security event logging: log authentication events (login success and failure, password reset, MFA enrollment and removal), authorization decisions (access denied), administrative actions (role changes, user deletion, config changes), and API access with timestamps and IP addresses.
• →Log integrity and retention: ship logs to a separate, append-only store (CloudWatch, Datadog, or a managed SIEM). Do not let application servers write to their own log store—a compromised server can delete or modify its own logs. Retain logs for a minimum of 90 days; 1 year is required for SOC 2 evidence.
• →Incident response plan: write a two-page document that defines who gets paged, how the team communicates during an incident, and what the SLA for customer notification is. Enterprise buyers ask for this. It does not need to be elaborate—it needs to exist and be signed off.
• →Vulnerability disclosure program: create a security.txt file at /.well-known/security.txt and a /security page describing how external researchers can report vulnerabilities. A documented channel for responsible disclosure signals that you take security seriously and prevents researchers from going public without warning you.
• →Penetration testing: if you are targeting enterprise buyers above $50K ACV, plan for an annual penetration test by an external firm. A penetration test report from the last 12 months turns most security questionnaires from lengthy investigations into simple evidence reviews.

Running DeployReady as Your Automated Security Baseline

Before you begin a manual security review, run DeployReady to get an automated baseline across the OWASP Top 10, exposed secrets, missing security headers, and environment configuration checks. DeployReady is Belsoft's open-source CLI—free, MIT-licensed, and entirely local. No data leaves your machine. A single npx deployready command in your project root returns a 0–100 readiness score and a prioritized finding list.

DeployReady covers what automation can catch: missing headers, exposed keys in committed files, permissive CORS configuration, npm audit findings, and configuration patterns that indicate RLS is likely disabled. What it cannot catch is logic-level vulnerabilities—an IDOR in your resource endpoints, a Supabase RLS policy that says USING (true) without restricting by user, or a rate limit that applies globally but not per-user. Those require a human engineer to trace the request paths in your specific application. Run DeployReady first to clear the automated baseline, then bring in a manual reviewer for the logic-level work.

• →Run: npx deployready in your project root. The tool reads your source files and environment configuration locally with no data sent anywhere.
• →Review the 0–100 score and the findings list. A score below 70 indicates issues that an automated scanner will also catch—fix these before investing in a manual audit.
• →Re-run after each fix pass to confirm the finding is resolved. DeployReady re-checks every control on each run.
• →Add npx deployready --ci to your CI/CD pipeline as a pre-deploy gate. This prevents new regressions from shipping to production between manual review cycles.

What Enterprise Security Questionnaires Actually Ask

Most enterprise security questionnaires follow the same structure, derived from frameworks like CAIQ (CSA), SIG (Shared Assessments), or vendor-specific templates built on NIST 800-53. Knowing what they ask lets you build documentation that passes these reviews quickly rather than drafting answers under deadline pressure.

• →Data handling: where is data stored (region, cloud provider), who has access, how is it encrypted at rest and in transit, what is your data retention and deletion policy, and do you have a data processing agreement (DPA) available.
• →Access control: how do you enforce MFA, what is your privileged access management policy, do you conduct background checks on employees with production access, and how quickly can you deprovision a terminated employee.
• →Vulnerability management: how often do you run vulnerability scans, do you have a penetration test report from the last 12 months, what is your SLA for patching critical CVEs, and how do you handle third-party dependency vulnerabilities.
• →Incident response: do you have a documented incident response plan, what is your SLA for notifying customers of a data breach (GDPR requires 72 hours), who is your data protection officer if required, and have you had a breach in the last 3 years.
• →Business continuity: what is your RTO and RPO, do you have a documented disaster recovery plan, how do you test it, and what is your uptime SLA.
• →Third-party risk: do you use subprocessors that handle customer data, how do you vet those subprocessors, and are they listed in your DPA.

Frequently Asked Questions

What security checks should I do before launching a SaaS product?

Before launching a SaaS product, audit six layers: (1) authentication—enforce MFA, expire sessions, rate-limit login attempts; (2) authorization—verify every API endpoint checks resource ownership, not just authentication status; (3) API security—validate all input, run npm audit, test for IDOR vulnerabilities; (4) secrets management—scan git history for committed secrets and rotate any that were exposed; (5) infrastructure—set security headers, enforce HTTPS-only, lock down admin interfaces; (6) logging—ensure security events are shipped to a separate, append-only store. Run DeployReady to automate the baseline checks, then bring in a manual reviewer for logic-level vulnerabilities.

How do I pass a security questionnaire from an enterprise customer?

Enterprise security questionnaires evaluate your policies and documentation as much as your technical controls. To pass one efficiently: have a written information security policy, a data processing agreement (DPA) ready to sign, an incident response plan on paper, a list of subprocessors, and documented answers to data residency and encryption configuration questions. If you have a SOC 2 Type II report or a recent penetration test report from a recognized firm, most questionnaires fast-track to approval. Without those, expect 150–300 individual questions. Building this documentation before your first enterprise deal shortens your sales cycle by 4–12 weeks.

What does a SaaS security audit cover?

A SaaS security audit covers manual review of authentication and session management, authorization logic (including IDOR testing across all resource endpoints), data isolation between tenants, API security and input validation, secrets management and environment configuration, security headers and TLS configuration, logging and audit trail completeness, and any AI features for prompt injection and tool-call authorization. A reputable audit returns a report with findings ranked by severity—critical, high, medium, low—plus a remediation guide for each finding and a retest after you deploy the fixes.

How long does a pre-launch SaaS security audit take?

A pre-launch security audit for a typical SaaS product—10–30 endpoints, one or two user roles, standard web stack—takes 3–5 business days for the initial assessment and report. Remediation of critical and high findings typically requires 1–2 weeks of engineering time. A retest to confirm fixes is another 1–2 days. Budget 4–6 weeks end-to-end from first contact to a clean retest report, and start the process at least 6 weeks before your target enterprise sales motion.

What is a good readiness score for a SaaS application using DeployReady?

DeployReady returns a 0–100 readiness score. A score of 85 or above means the automated checks pass—no exposed secrets, security headers configured correctly, no critical npm audit findings, and no obvious environment configuration gaps. A score below 70 indicates findings that an automated scanner like SecurityScorecard will also report to any enterprise prospect who scans your domain. Before a manual security audit, aim to clear 85+ so the engineer you bring in focuses on logic-level vulnerabilities rather than configuration work that a scanner could have caught.

How Belsoft Helps SaaS Teams Prepare for Enterprise Security Review

The Belsoft security audit is designed specifically for SaaS teams preparing for their first enterprise deals—and for founders who shipped with an AI coding tool and have not yet had their security posture reviewed. Every engagement starts with a DeployReady baseline scan, then moves to a manual review of your authentication and authorization logic, data isolation model, API endpoints, secrets configuration, and any AI features. We return a prioritized findings report, work through the fixes with your engineering team, and retest critical and high-severity items before the engagement closes.

If your team is 3–6 weeks away from an enterprise pitch and has not run a security review, the fastest path is to book a call and we will scope the engagement to your timeline. We deliver the initial report in 3–5 days and can turn around a retest within a week of receiving your fixes. The Belsoft security audit service includes the initial assessment, the remediation guide, retest support, and the documentation package most enterprise questionnaires ask for.

“A deal lost to a security review is almost always a deal that could have been won—with six weeks and the right engineer.”