SaaS Security Audit vs Penetration Test: What Each Covers and Which One You Need
Most requests for a SaaS security audit start the same way. An enterprise prospect sent a questionnaire, a lawyer asked for "proof of security testing", or a founder got nervous after reading about a breach at a company with a similar stack. The email that arrives says "we need a security audit, can you also do a pen test, or is that the same thing?"
It is not the same thing, and the difference matters for what you pay, what you get back, and whether the result satisfies the person who asked for it. This post separates the two, explains when each is the right purchase, and walks through what a security audit of a SaaS application covers when it is done properly.
The short version
A security audit is a review. Someone reads your code, your configuration, your access controls and your processes, and tells you where they fall short of what a well-run system should have. The auditor does not need to break in to tell you that your password reset tokens never expire. They can see it in the code.
A penetration test is an attack. A tester is given a target, a scope and a time box, and tries to get in. The output is a list of things they managed to do that they should not have been able to do, with evidence.
Both are useful. They answer different questions. An audit answers "how well is this system built and operated, and where are the weak points?" A pen test answers "can a motivated attacker with this much time and this level of access get past what you built?"
What a SaaS security audit covers
An audit is broad by design. The point is to look at every layer where a SaaS product typically leaks data or grants access it should not. For a Symfony or Next.js application, the areas below are the ones that come up in almost every engagement.
Authentication and session management
How users prove who they are, and how the system remembers that. The audit checks password hashing (bcrypt or argon2id, with sane cost parameters), rate limiting on login and password reset, token expiry and rotation, session fixation protection, and whether "remember me" cookies are scoped and signed correctly. Multi-factor support and its recovery flow get checked too, because recovery is where most MFA implementations fall apart.
Authorization logic
This is the section that finds the most serious problems in SaaS products, and it is the one automated scanners are worst at. Can user A read user B's invoice by changing an ID in the URL? Can a member of one tenant see data from another? Does the admin role check happen on the server, or only in the React component that hides the button? In a code audit, the reviewer reads the voters, the middleware and the query layer to see where tenant scoping is enforced and where it is assumed. In AI-assisted codebases this section alone often justifies the whole engagement. We wrote about that pattern in securing vibe-coded API access control.
API security
Input validation at the boundary, output encoding, mass assignment protection on write endpoints, correct use of HTTP methods, CORS configuration, and whether internal endpoints are reachable from outside. For public APIs, the audit also looks at how API keys are issued, stored, rotated and revoked.
Dependency and supply chain review
Which packages are installed, which have known vulnerabilities, which are abandoned, and whether the lockfile is actually used in the build. Composer audit and npm audit are the starting point. The more useful part is checking whether the build pipeline pins versions, verifies integrity, and would notice if a dependency changed under it.
Secrets management
Where credentials live. The classic findings are a .env file committed to the repository three years ago and still in history, database passwords in Docker Compose files, and API keys hardcoded in a client bundle where anyone can read them from the browser. The audit also checks how secrets reach production: environment variables, a vault, or copied by hand onto the server.
Data storage and encryption
What is encrypted at rest, what is encrypted in transit, and what personal data is stored that does not need to be. For European SaaS this overlaps heavily with GDPR work: retention periods, deletion paths, and whether backups honour erasure requests. Column-level encryption for sensitive fields gets reviewed, as does key management for that encryption.
Logging and monitoring
Would you notice a breach? The audit checks whether authentication events, permission changes and admin actions are logged, whether logs contain secrets or personal data they should not, and whether anyone would be alerted if a single account started hitting the API ten thousand times an hour. Absence of logging is a finding in its own right.
Infrastructure and configuration
Exposed ports, TLS configuration, security headers, cookie flags, and whether the debug toolbar or a profiler is reachable in production. In a Symfony app this includes APP_ENV, the firewall configuration and what access_control rules allow. In Next.js it includes middleware behaviour and what ends up in the client bundle.
Process
The last section is not about code. Who can deploy to production? Is there a review step? How are vulnerabilities reported and handled? Is there an incident plan? For teams heading toward SOC 2 or dealing with NIS2 obligations, this is the part that determines whether the technical findings will stay fixed.
What a penetration test covers
A pen test is narrower and deeper. The tester agrees a scope with you (the web application, the public API, maybe the mobile app, usually not the office network) and a level of access (unauthenticated, a normal user account, an admin account). Then they spend a fixed number of days trying to achieve specific outcomes: read data belonging to another tenant, escalate to admin, execute code on the server, exfiltrate the database.
The methodology typically follows the OWASP Testing Guide or a similar framework, and a good tester combines automated scanning with manual work. The manual part is what you pay for. Scanners find reflected XSS and outdated jQuery. Humans find that the CSV export endpoint accepts a tenant ID parameter that nobody validated.
What a pen test does not do is tell you about problems the tester did not reach. If they spent their three days on the API and never looked at the deploy pipeline, the pipeline is not covered. A clean pen test means your system withstood that tester, for that long, within that scope. It does not mean the system is well built.
Side by side
| Security audit | Penetration test | |
|---|---|---|
| Approach | Review of code, config and process | Simulated attack against a running target |
| Breadth | Wide, covers all layers | Narrow, follows the agreed scope |
| Access | Full source code and infrastructure access | Black box, grey box or white box, as agreed |
| Finds | Design weaknesses, missing controls, bad practices | Exploitable vulnerabilities with proof |
| Misses | Whether the weakness is actually exploitable in practice | Anything outside the scope or time box |
| Typical output | Prioritised findings plus a remediation roadmap | Findings with reproduction steps and severity ratings |
| Best timing | Before launch, before certification, after major changes | Before enterprise onboarding, when a customer asks for it, annually |
| Satisfies | Internal risk management, SOC 2 readiness, due diligence | Customer security questionnaires, regulators, contractual requirements |
When you need an audit
Get an audit when the question is "is this system built properly?" Concrete situations where that is the question:
You are about to launch a product that handles sensitive data, whether that is health records, payment details or HR information, and nobody outside the team has ever looked at the code. The audit is cheaper than the incident.
You are preparing for SOC 2, ISO 27001 or a similar certification. The certification auditors will ask for evidence that controls exist. A security audit tells you which controls are missing before you spend money on the certification process. We covered the engineering side of this in the SOC 2 Type II readiness checklist.
Your codebase was largely written by AI coding assistants, or by a contractor who has since left, and you do not know what security assumptions were made. The authorization section of an audit is built for exactly this.
An investor or acquirer is running technical due diligence. They want to know about structural risk, and a pen test report alone will not answer that. The audit report will.
When you need a pen test
Get a pen test when the question is "can you prove it?" Situations:
An enterprise customer's procurement process requires a recent third-party penetration test report. This is the most common trigger. They usually want it less than twelve months old and covering the parts of the product they will use. Our post on the enterprise security questionnaire goes into what else they will ask.
A regulator or a contractual framework demands adversarial testing. DORA, for fintech vendors, is explicit about threat-led penetration testing for certain firms. PCI DSS requires it for cardholder data environments.
You have a specific attack surface you want validated. You built a new public API, a new SSO integration or a new file upload feature, and you want someone to try to break it before customers do.
Doing both, and in which order
Audit first, then pen test, is the order that gets the most out of the budget. The audit finds the structural gaps: missing tenant scoping in a query layer, secrets in the repository, no rate limiting anywhere. You fix those. Then the pen tester goes in against a system that no longer has the obvious holes, and their time gets spent finding the subtle ones instead of documenting the same missing rate limit for the fifth time.
Running a pen test first against a system that has never been reviewed usually produces a long report of things a code reader would have spotted in an afternoon, at pen test day rates.
Some vendors sell a bundled "security assessment" that is a vulnerability scan with a pen test label on it. The tell is a report full of CVE numbers and TLS cipher warnings with no reproduction steps and no evidence of manual testing. If the report could have been generated by pointing a tool at your domain, that is what happened.
What the audit deliverable looks like
When we run a security audit as part of our code quality consulting, the engagement runs in roughly three phases and the report is structured to be acted on rather than filed.
Discovery takes a day or two: repository and infrastructure access, an architecture walkthrough, and a conversation about what data the product handles and who the customers are. A B2B tool used by three enterprise clients has a different risk profile from a consumer app with a hundred thousand accounts, and the review priorities follow from that.
The review itself runs one to two weeks depending on codebase size. Tooling runs first (static analysis, dependency audit, configuration scanners) to clear the mechanical findings. The manual pass follows: reading authentication and authorization code end to end, tracing how a request from an unauthenticated user reaches the database, checking every place tenant context is supposed to be enforced, reviewing the deploy pipeline and the production configuration. For a PHP application this overlaps with the general audit methodology we use, with the security sections weighted up.
The report has a two-page summary a non-engineer can read, then findings grouped by area and ranked by severity. Each finding names the file and line or the configuration key, explains the risk in plain terms, and gives a specific fix. Critical and high findings come with an estimate of effort. The last section is a remediation roadmap: what to fix this week, what to fix this quarter, and what to build into the process so the same class of issue does not come back.
A follow-up review of the fixes is usually part of the engagement. That review is also the natural handover point to a pen tester if a customer or regulator needs one.
Frequently asked questions
Can a security audit replace a penetration test for a customer questionnaire?
Usually not, if the questionnaire specifically asks for a penetration test. Some customers accept an audit report plus evidence of remediation, particularly if the audit followed a recognisable methodology. Ask the customer before assuming.
How much does a SaaS security audit cost compared to a pen test?
Both depend on scope. A security audit of a mid-size SaaS application is typically priced by the size and complexity of the codebase and runs one to three weeks of senior engineering time. A pen test is priced by days of testing and scope, commonly three to ten days. Pen test day rates from specialist firms tend to be higher. Our post on PHP code audit cost in Germany has more on how audit pricing works.
Our code was generated with Cursor or Claude Code. Does that change the audit?
It changes the emphasis. AI-generated code tends to be clean on the surface and weak on authorization, tenant isolation and error handling. The audit spends more time in those areas and less on style. See the vibe code audit for how that review is structured.
Next step
If you are not sure which one you need, describe the situation that triggered the question, whether that is a customer request, a launch, a certification or a bad feeling about the code, and we will tell you which engagement fits and what it would cover. Write to hello@wolf-tech.io or see the security audit scope on wolf-tech.io.