Whether you’re preparing for a SOC 2 audit, a customer’s vendor security questionnaire, or a penetration test, the goal is the same: show that security findings get caught and fixed as a matter of routine, not as a last-minute scramble. The checklist below covers what auditors actually check and what you should clean up before anyone external looks.
What auditors actually check
A SaaS security audit covers four main areas:
- Code-level vulnerabilities. Hardcoded secrets, injection bugs, missing authentication, insecure cryptography, outdated dependencies with known CVEs. This is where most findings land, and where automated scanning does the most work.
- Access control. Who can access what data, whether least-privilege is enforced, whether admin access requires MFA and is logged, whether API routes check the caller’s permissions server-side.
- Infrastructure and configuration. HTTPS enforced everywhere, database not publicly accessible, secrets stored in a vault or environment variables (not plaintext config files), logging and alerting in place.
- Process and evidence. Can you show a repeatable system for finding and fixing issues? Do you have CI scan results, PR review records, and a remediation log? This is the part most teams skip, and it is what separates a one-time cleanup from an audit-ready posture.
Scan your own app for issues like these
Paste your live URL. We check what your app serves publicly for exposed keys and misconfigurations. No account, no install.
Pre-audit checklist
Work through this before the auditor arrives. Fix what you can; document what you cannot.
Secrets and credentials
- Run a secrets scan across the full codebase and git history — not just the current branch
- Rotate any key that was ever in a source file, even briefly, even in a private repo
- Confirm all secrets are in environment variables or a secrets manager, with no NEXT_PUBLIC_ prefix on server-only keys
- Verify
.env,.env.local, and.env.productionare in.gitignore - Check that no credentials appear in logs, error messages, or API responses
Authentication and authorization
- Add a server-side auth check to every API route that reads or modifies user data — the UI hiding a route is not access control
- Confirm JWT tokens are verified with a signature check (
jwt.verify()), not just decoded (jwt.decode()) - Enable MFA on admin accounts and any account with production database access
- Verify session tokens are
HttpOnly,Secure, andSameSite=LaxorStrict - If using Supabase, confirm RLS is enabled on every table and policies are scoped to the authenticated user — test with a logged-out request to verify no data leaks
Input handling and injection
- Use parameterized queries or an ORM for all database access — no string-concatenated SQL
- Validate and sanitize all user input that reaches a shell command, file path, or HTML output
- Check that file upload endpoints restrict type, size, and destination path
- Confirm CORS is configured to allowlist your specific origins, not a wildcard with credentials
Dependencies and infrastructure
- Run
npm auditorpip-auditand fix or document all HIGH and CRITICAL findings - Confirm your database is not publicly accessible — it should only accept connections from your app server or VPC
- Verify all endpoints are served over HTTPS with a valid certificate and HTTP redirects to HTTPS
- Check that security headers are present:
Content-Security-Policy,X-Frame-Options,Strict-Transport-Security
Special attention for AI-generated code
If your team uses Cursor, Copilot, Claude Code, or similar tools, the AI-generated portions of your codebase are statistically more likely to contain the issues auditors check first: hardcoded credentials, missing server-side authorization, and JWT tokens that are decoded but never verified. In our scan of 976 real AI-built apps, 1 in 8 had at least one high-severity flaw. Treat AI-generated code as a distinct risk category and run it through the same checklist.
Build the evidence trail before the audit
Fixing issues is only half the job. Auditors also want to see that your process catches them automatically going forward. The most valuable thing you can do three to six months before an audit is wire a scanner into your CI pipeline:
- Every pull request gets a scan comment flagging new findings before merge
- The CI log becomes a timestamped record of what was found and when it was fixed
- By audit day, you hand over months of evidence instead of a one-week scramble
This matters especially for SOC 2 Type II, which requires continuous evidence over a 6-12 month observation period. A CI scanner that ran on every deploy is exactly the kind of automated control auditors want to see.
What you cannot fix, document honestly
Some findings — an open dependency CVE with no upstream patch, a known architectural limitation — cannot be resolved immediately. Auditors respond far better to a documented risk register with honest severity assessments and compensating controls than to a report that claims zero findings and turns out not to be true. Document what you know, what you are doing about it, and why the residual risk is acceptable.
Common questions
How do I prepare my SaaS for a security audit?
Start by running a baseline scan of your codebase and live app to find hardcoded secrets, missing auth checks, and injection vulnerabilities before the auditor does. Then document what you found and how you fixed it — auditors want to see a repeatable process, not a clean snapshot. Wire a scanner into your CI pipeline so findings are logged automatically going forward. Three to six months of CI evidence is far better than a one-time scramble the week before the audit.
What do auditors look for in a SaaS security audit?
Auditors check four main areas: (1) code-level vulnerabilities — hardcoded secrets, injection bugs, missing authentication, insecure dependencies; (2) access control — who can access what data, whether least-privilege is enforced, whether admin access is logged; (3) infrastructure and config — HTTPS everywhere, database not publicly accessible, secrets in a vault not plaintext; (4) process and evidence — do you have a repeatable way to find and fix issues, with documented proof.
What is a SaaS security audit?
A SaaS security audit is a formal review of your product's code, infrastructure, and processes to identify vulnerabilities and verify that security controls are in place. It may be conducted by an external auditor (for SOC 2, ISO 27001, or a customer's vendor review), a penetration testing firm, or your own security team. The output is a findings report with severity ratings and remediation recommendations.
How much does a SaaS security audit cost?
External penetration tests typically run $5,000–$30,000 depending on scope. A full SOC 2 Type II audit including the auditor's time runs $30,000–$100,000 or more. Automated code scanning (like Prbl) is much cheaper and is typically done first to eliminate the low-hanging fruit so the expensive auditor's time is spent on harder problems.
What is SOC 2 and does my SaaS need it?
SOC 2 (Service Organization Control 2) is an auditing standard from the AICPA that certifies your organization handles customer data securely. Enterprise buyers increasingly require SOC 2 Type II compliance before signing contracts. If your SaaS sells to enterprise customers or handles sensitive data, you will likely be asked for SOC 2. Type I is a point-in-time assessment; Type II covers a period (usually 6-12 months) and is the one enterprise buyers want.
What are the most common findings in a SaaS security audit?
The most frequent findings in SaaS code audits are: hardcoded API keys and secrets in source code; missing server-side authorization checks on API routes; JWT tokens decoded without signature verification; missing input validation leading to injection vulnerabilities; overly permissive CORS configuration; session tokens without HttpOnly or Secure flags; and outdated dependencies with known CVEs. AI-generated code shows higher rates of hardcoded secrets and missing auth than hand-written code.
How long does it take to prepare for a security audit?
Allow at least 30 days for the initial remediation sprint — run a baseline scan, fix the findings, and document the process. For SOC 2 Type II you need 6-12 months of evidence that your controls are running continuously, so start well before your target audit date. The CI pipeline is what generates that evidence automatically; the sooner it is running, the more evidence you accumulate.