Penetration Testing for B2B SaaS

B2B SaaS companies sell trust before they sell features. When a prospect's security team asks "have you had a recent penetration test," a vague answer stalls the deal. A specific one, backed by a report you can hand over under NDA, moves it forward. That is the practical reason penetration testing keeps showing up as a checkbox in vendor security reviews, and why it belongs in your compliance program well before an auditor asks for it.

Why B2B SaaS is a different animal

Penetration testing exists across every industry, but SaaS companies carry a specific set of risks that generic scanning tools miss. Multi-tenant architecture means a single authorization bug can expose one customer's data to another. API-first products expose more attack surface than a typical website, often with authentication logic that has never been tested by anyone outside the engineering team. And because SaaS companies iterate fast, the attack surface from six months ago may already be gone, replaced by new endpoints, new integrations, and new assumptions nobody has stress-tested.

Add in the reality that most SaaS buyers now run a vendor security review before signing, and the stakes compound. Enterprise procurement teams, especially in the US, expect a recent penetration test report as standard due diligence, not a nice-to-have. If you are trying to sell up-market and your last test was two years ago (or never happened), that gap gets noticed.

Automated scanning is not a penetration test

A lot of vendors sell vulnerability scans and call them penetration tests. They are not the same thing. An automated scanner can tell you a library is out of date. It cannot tell you that your API lets User A modify User B's records by changing an ID in the URL, that your SSO implementation has a logic flaw an attacker could chain into account takeover, or that your cloud storage buckets are misconfigured in a way that only shows up when someone actually tries to access them from the outside.

That is the gap human-led testing closes. A skilled tester thinks like an attacker: chaining small issues together, testing business logic rather than just known vulnerability signatures, and pursuing the paths an automated tool would never think to try. This is the standard traztech holds testing to, led by Jacob Masse, a published security researcher with five CVEs to his name, including CVE-2024-45163, a CVSS 9.1 finding that functioned as a kill-switch against the Mirai botnet. Testing at that level of rigour is what separates a report that satisfies a checkbox from one that actually tells you where you are exposed.

How traztech scopes a test for SaaS

Scope is where most penetration tests go wrong, either too narrow to mean anything or too broad to finish on budget. For B2B SaaS, we typically structure testing across three layers:

• Web application. Authentication, authorization, session management, and business logic testing against your production or staging environment, including the multi-tenant boundaries that matter most to your customers.
• Network. External and, where relevant, internal network testing to identify exposed services, misconfigurations, and lateral movement paths.
• Cloud infrastructure. Configuration review of your AWS, Azure, or GCP environment, since a growing share of real-world breaches trace back to a misconfigured storage bucket or an overly permissive IAM role rather than a code vulnerability at all.

For larger engagements or when a client needs more testing bandwidth in a compressed window, we co-deliver with Lorikeet, our offensive-security partner, so the depth of testing does not get sacrificed to a deadline. Every engagement wraps up with a report written for two audiences at once: technical detail your engineering team can act on, and an executive summary your customers' security reviewers can actually read.

One test, two purposes

The report from a well-scoped penetration test does double duty. If you are pursuing a SOC 2 report, a penetration test is standard supporting evidence for your Type II audit, and auditors expect to see one on a regular cadence, typically annually. If your product touches payment card data, PCI DSS has an explicit penetration testing requirement under Requirement 11. Rather than commissioning a generic test and hoping it satisfies whoever asks for it later, we scope engagements upfront with those downstream uses in mind, so the same report can support a compliance audit and a customer's vendor security questionnaire without a second engagement.

This is part of why penetration testing sits inside our broader security services rather than as a one-off product. Testing in isolation tells you what is broken today. Testing tied to your compliance roadmap and your sales cycle tells you what to fix, in what order, and how to prove you fixed it to the people who are asking.

What to expect from the process

A typical engagement starts with scoping: what is in bounds, what environments are involved, what is off-limits, and what timeline you are working against (a looming enterprise deal or audit deadline changes the plan). Testing itself runs over an agreed window, with critical findings flagged to you immediately rather than held for the final report. You get a written report with severity ratings, reproduction steps, and remediation guidance, plus a walkthrough call to make sure your engineering team understands what needs fixing first. Retesting after remediation is available so your final report reflects the fixed state, not just the findings.

If you are further along in building out a full compliance program, penetration testing is one piece of a larger picture that also includes policy, access control, and evidence management, covered in more detail on our compliance solutions page.

Get a test that actually moves deals forward

If enterprise prospects are asking for penetration test results you do not have, or your last test is too old to satisfy a buyer's security team, it is worth scoping a new engagement before that gap costs you a deal. Contact traztech to talk through your product, your compliance timeline, and what a properly scoped test looks like for your stage of growth.

How a buyer's security team reads your report

Most founders think of the report as a technical document. The people who decide whether it unblocks your deal are not reading it technically. A vendor security reviewer at an enterprise buyer typically spends fifteen minutes on it, and they are checking five things in a predictable order.

The date. Anything older than twelve months gets flagged, and many programmes hard-fail at eighteen. This is the most common reason a real report fails to satisfy a review.

The scope statement. They are looking for the name of the product they are buying. A report scoped to "the marketing website and corporate network" does not cover the application their data will sit in, and reviewers notice this more often than vendors expect. If your report's scope section is vague, they will ask you to clarify in writing, which costs you a week.

The severity distribution. Zero findings reads as a weak test, not a strong product. Reviewers who do this for a living know that a real assessment of a real SaaS platform produces findings, and a clean report with no methodology detail suggests a scan rather than an assessment. A handful of mediums and lows with a couple of highs remediated is a more credible artefact than a blank one.

Remediation status. Open highs and criticals are the thing that stops a deal. Not because the finding is fatal, but because it forces the reviewer to escalate, and escalation adds weeks. This is why the retest matters commercially rather than just technically.

Who performed it. Independent third party, named firm, stated methodology. Self-assessment does not count.

Design what you buy around that reading. If the deal you are chasing involves your core multi-tenant application, the scope statement needs to name it explicitly.

Proving tenant isolation, specifically

Multi-tenancy is the risk your buyers care most about and the one most tests cover shallowly. Testing it properly requires setup that many companies do not think to provide.

The minimum viable configuration is two separate tenant organisations, each with at least an admin user and a limited user, plus a third tenant that shares something with the first: a similar name, a user with the same email domain, an object with a sequential identifier adjacent to one in the first tenant. That third tenant exists to catch the boundary bugs that only appear in near-collision cases.

With that in place, the test drives at the paths where isolation actually fails in practice, and they are rarely the obvious ones. Direct object references in the API are the first pass and usually well defended on primary endpoints. The failures cluster elsewhere. Export and reporting endpoints built later, where the tenant filter was applied in the UI query but not the CSV generation path. Search indexes shared across tenants where the filter is applied at query time and can be manipulated. Caches keyed on object identifier without a tenant component, so a request served from cache returns another tenant's record. Webhook and integration configuration where an identifier from another tenant is accepted at write time and never validated. Support impersonation features that let staff enter a tenant, which are perfectly reasonable and become severe when a customer-facing role can reach them.

The tenant lifecycle seams deserve deliberate attention too. Remove a user from a tenant and check whether their existing session and API tokens die. Delete a tenant and check whether its data is actually gone or merely hidden. That last one gets asked in DPAs constantly and is answered honestly by very few vendors.

What to hand a prospect, and what not to

Do not send your full technical report to prospects. It contains reproduction steps for the issues in your product, and once you email it you have no control over where it travels or how long it sits in someone's shared drive.

Ask your testing firm for a summary letter alongside the technical report. One or two pages: who tested, when, what was in scope, what methodology was followed, the count of findings by severity, and the remediation status. That is the artefact that goes to prospects, ideally under NDA, and it satisfies the great majority of vendor security reviews without exposing anything exploitable.

Keep the full report for your engineering team, your auditor, and the occasional enterprise buyer whose security team insists and will sign for it. When that happens, redact reproduction detail for anything still open, note the redaction, and share the rest. Reviewers accept this readily. The vendors who get into trouble are the ones who either refuse to share anything, which reads as evasion, or share everything immediately, which reads as inexperience.

Publishing the summary letter's existence in a trust centre, alongside your policies and subprocessor list, cuts a meaningful amount of email out of every deal. Our free traztech Workspace is one place to keep those artefacts organised so the answer to "can you send us your latest test" takes a minute rather than a day of hunting.

Findings we see repeatedly in B2B SaaS

Patterns recur, and knowing them lets you fix cheaply before the test rather than expensively during it.

SSO implemented but not enforced. The enterprise tenant has SAML configured, and the password login path still works for the same accounts, so the customer's offboarding of an employee does not actually remove access to your product. This is a high in every report and it is a configuration fix.

API tokens with no scoping or expiry. Long-lived bearer tokens with full account privilege, generated once, stored in a customer's CI system, never rotated. Adding scopes and expiry is product work, so this one takes real roadmap time. Start it before the test.

Role definitions that drifted. The permission model was designed for three roles two years ago and now has nine, several of which quietly hold capabilities nobody intended. The test finds this; the fix is a permission audit you were going to have to do anyway.

File upload handling. Content type trusted from the client, files served from the same origin as the application, no scanning. Serving user content from a separate origin is the single highest-value change here.

Timing the test against your release cycle

Testing during a heavy release window produces a report about code that no longer exists. Testing against a frozen staging environment that has drifted from production produces a report about a system nobody uses. Neither is useful and both are common.

The workable pattern is to test against production or a production-faithful environment, in a window where you are shipping normally but not mid-migration, and to freeze nothing except the specific subsystems under test on the days they are being tested. If a major architectural change is landing in six weeks, either test before it and plan a targeted retest after, or wait. Testing the week before a re-platform is money spent on a report with a two-month shelf life.

Align the window with your audit period too. If your SOC 2 Type II observation window runs to the end of Q3, a test completed in Q1 with remediation evidence by Q2 sits comfortably inside it. A test finished the week the window closes leaves you with findings and no time to show they were addressed, which is a worse position in front of an auditor than not having tested.

What drives the price

Penetration testing starts from $1,000 for tightly scoped work. What moves a SaaS engagement above that is mostly structural, and most of it is under your control.

Role and tenant count drives the authorization test matrix directly. Number of distinct applications matters more than number of endpoints, because each application carries its own authentication and session model. Whether the cloud environment is in scope adds a configuration review workstream. Whether you want internal network testing in addition to external roughly doubles the network portion. Retesting is usually priced separately and is worth buying up front rather than negotiating later under deadline pressure.

The cheapest thing you can do to reduce cost is provide documentation. A current API specification, a data flow diagram, a list of roles with intended permissions, and working credentials at every tier can remove days from an engagement, because the tester spends those days attacking rather than reverse-engineering your permission model. Companies that hand over nothing and expect the tester to discover everything pay for that discovery time and get less depth for the same budget.

When you should not buy a penetration test

There are several situations where our answer is that this is not the right purchase yet, and saying so is cheaper for both of us than an engagement that disappoints.

You have never run a vulnerability scan. If nothing has ever been scanned, a cheap automated pass will surface the outdated dependencies and exposed services first, and fixing those before a manual test means you are paying skilled testers to find interesting things rather than to write up missing patches you already knew about.

Your last report's findings are still open. A second test will find the same issues and you will have paid twice to learn the same thing. Remediate, retest, then widen the scope next cycle.

The product is pre-launch and the architecture is unsettled. Design review and threat modelling of the authentication and tenancy model gives you more per dollar at that stage. Black-box testing earns its value once the surface is real and stable.

What the buyer actually asked for is something else. Read the request. Sometimes the questionnaire asks for evidence of vulnerability management rather than a penetration test, and a documented scanning and patching process satisfies it. Sometimes it asks specifically for the cloud configuration review, which is a smaller and cheaper engagement. Buying the biggest thing on the menu because the question sounded serious is a common and expensive mistake.

Nobody has capacity to fix anything. If your engineering team is fully committed for the next two quarters, a report full of findings you cannot action creates a documented, unremediated risk position. That is worse than not testing, because it is now written down. Either free the capacity or wait until you can.

The retest is the part that closes the loop

The remediation walkthrough and retest are what turn a report into evidence. Findings get fixed, we verify each one, and the report gets a dated addendum showing what was closed and how it was confirmed. That addendum is what a buyer's reviewer and an auditor both want to see, and it is why we treat retesting as part of the engagement rather than an upsell.

Verification also catches partial fixes, which are more common than complete ones. A patched endpoint with the same flaw on a sibling route. An authorization check added at the controller and missing on the background job that processes the same object. A fix deployed to production and never merged to the branch that serves your single-tenant enterprise deployment. None of those show up in a ticket marked done, and all of them show up in a retest.

If your platform ships weekly, one annual test plus a retest still leaves ten months of new surface unexamined. A retainer that lets you point testing at a specific feature for a few days, without re-scoping from scratch, keeps pace with a real release cadence better than a single large engagement each year. We set that out on our engagement models page, and it sits naturally alongside the compliance calendar rather than fighting it. If you want to work out which shape fits your stage, tell us what you are building and who is asking for what.