The enterprise deal has been progressing for six weeks. The commercial terms are agreed. Legal has reviewed the contract. Then the buyer's security team sends a vendor security questionnaire with question 47: has your organisation conducted a third-party penetration test in the last twelve months? The answer is no. The deal stops.
This scenario is playing out across hundreds of B2B SaaS sales cycles. It also plays out mid-audit, when an auditor asks for penetration test evidence, and the team has 30 days to find a provider, schedule a test, fix findings, and package everything for review.
For ANZ SaaS companies, the dynamic has a specific character. AU and NZ enterprise buyers in financial services, government supply chains, and critical infrastructure carry stricter vendor security assessment requirements than many US counterparts. CREST certification is commonly expected in ANZ enterprise procurement. Privacy Act obligations in both AU and NZ mean that a SaaS platform handling customer PII carries regulatory obligations that make the penetration test evidence question more than a commercial preference. For ANZ SaaS founders, a penetration test is the document that determines whether the enterprise pipeline moves.
What Makes a SaaS Penetration Test Different from a Web App Test
A standard web application penetration test validates authentication, input handling, and authorisation for the tested application. A SaaS penetration test has a different central question: can one customer of your platform reach another customer's data?
For a SaaS company, the penetration test finding that matters most is whether one tenant can reach another tenant's data, and a test that never attempts this is testing the wrong threat model entirely.
The mechanism is not exotic. OWASP's API Security Top 10 lists Broken Object Level Authorisation (BOLA) as the number one API risk: an endpoint accepts an object identifier from the caller and fails to check whether the caller's tenant actually owns that object. In a single-tenant application, that finding is a bug. In a multi-tenant SaaS platform, it is a direct line into every other customer's account. Every ANZ enterprise buyer who sends a vendor security questionnaire is implicitly asking: have you tested whether this is possible? A test that never attempts cross-tenant access cannot answer that question.
Standard web and mobile penetration tests often miss cloud and SaaS-specific paths: APIs, identity flows, multi-tenancy, and admin tools. SOC 2-focused tests must target these critical surfaces and realistic attack chains.
Five Testing Areas Specific to SaaS Platforms
Tenant isolation testing is the first and highest priority. Two test accounts in separate tenants are used to attempt cross-tenant data access through API parameter manipulation, ID enumeration, batch export endpoints, and database query injection techniques. A test engagement that does not provision separate tenant accounts and attempt cross-tenant access has not tested the architecture risk that multi-tenant SaaS creates.
Identity provider and SSO security is the second. OAuth2 and OIDC flows require testing for PKCE compliance, state parameter handling, scope minimisation, redirect_uri whitelist validation, and refresh token rotation. ANZ enterprise buyers expect SSO integration through Okta or Entra ID. An SSO integration that has never been adversarially tested is one where an attacker can potentially bypass the authentication model the enterprise buyer's security team assumes is protecting their tenant.
Role-based access control validation is the third. Every user role requires a dedicated test pass confirming that access controls are enforced at the API layer, not only in the front-end interface. Horizontal privilege escalation and vertical privilege escalation both require explicit test cases that a standard web app test scope does not include. The guide to API penetration testing and securing the backbone of modern applications covers what a well-scoped API assessment examines beyond surface-level authentication testing.
CI/CD pipeline and secrets management is the fourth. SaaS companies shipping code continuously accumulate configuration exposure risk across deployment pipelines, container registries, environment variables, and cloud IAM credentials. A test examining only the running application leaves the deployment environment untested. The guide to the best secret scanning tools covers the preventative controls that reduce pipeline exposure risk that a penetration test should also validate.
Admin and support portal access is the fifth. SaaS platforms frequently have an internal admin interface with elevated access across all tenant data. This portal is rarely in scope for standard penetration tests and is consistently one of the highest-severity finding locations when it is. An admin portal that allows a customer support user to query any tenant's data without logging, or that lacks MFA enforcement, represents a far larger exposure than most application-layer vulnerabilities.
Testing Cadence for ANZ SaaS Teams
Annual testing leaves a significant gap for SaaS companies with active development cycles. Testing is recommended after every major feature release, after infrastructure migrations, after adding new third-party integrations, and whenever a new user role or permission model is introduced.
SOC 2 and ISO 27001 both expect annual penetration testing at minimum. An ANZ SaaS company shipping weekly product releases with a new API integration each quarter has a materially different attack surface by month six than the one the annual test assessed. Continuous or quarterly testing aligns the evidence with the platform that actually exists.
For ANZ SaaS companies facing an imminent enterprise deal or SOC 2 audit, the fastest path from no evidence to evidence is a scoped engagement covering the five areas above, delivered in seven days. Capture The Bug's Startup Launch Program is fixed price, CREST-certified, and structured for SOC 2, ISO 27001, and ANZ enterprise vendor security review evidence.
The guide to what happens after a penetration test covers the confirmed closure evidence that ANZ enterprise buyers and SOC 2 auditors actually check.
Book a scoping consultation to scope a SaaS penetration test mapped to your tenant architecture, SSO configuration, and ANZ enterprise buyer requirements.
Book a Scoping ConsultationPlan Your Annual Pentesting Strategy the Right Way
Learn how modern SaaS companies structure pentesting across the year to reduce risk, stay compliant, and avoid last-minute panic before audits.
Your Last Pentest Is Already Out of Date
Every week you ship without continuous testing is a week a vulnerability goes unseen. See what Capture The Bug finds in your first engagement.
Frequently Asked Questions
Q1: Why do ANZ enterprise buyers require penetration testing from SaaS vendors?
A: ANZ enterprise buyers in financial services, government supply chains, and regulated industries include penetration test evidence requests in standard vendor security questionnaires before finalising SaaS contracts. This is driven by AU and NZ Privacy Act obligations requiring reasonable security safeguards for customer data, APRA CPS 234 expectations for financial service entities assessing their vendors, and enterprise procurement standards that treat a missing penetration test as a vendor risk flag. CREST certification of the testing provider is commonly expected in ANZ enterprise procurement.
Q2: What does a SaaS penetration test scope include?
A: A SaaS penetration test scope specifically includes: tenant isolation testing with two separate tenant accounts attempting cross-tenant data access, identity provider and SSO security testing (OAuth2, OIDC, PKCE, redirect validation), role-based access control validation for every user role, CI/CD pipeline and secrets exposure testing, and admin or support portal security. A standard web application penetration test does not automatically include all five areas. Confirm explicitly which areas are covered before scoping.
Q3: What is tenant isolation testing and why is it the most important SaaS security test?
A: Tenant isolation testing uses two accounts in separate tenants to attempt cross-tenant data access through API parameter manipulation, ID enumeration, batch export endpoints, and query injection techniques. For multi-tenant SaaS platforms, broken object-level authorisation on tenant-scoped endpoints is the highest-impact vulnerability class because it is a direct line into any other customer's account. A penetration test that does not provision separate tenant accounts and attempt cross-tenant access cannot answer the question every enterprise buyer is implicitly asking: can one of your customers reach another customer's data?
Q4: How often should an ANZ SaaS company do penetration testing?
A: At minimum annually, satisfying SOC 2 and ISO 27001 requirements. In practice, SaaS companies with active release cycles should test after every major feature release that changes the authentication model, adds new user roles, or introduces new third-party integrations. A platform shipping weekly releases with quarterly new API integrations has a materially different attack surface at month six than the annual test assessed. Continuous or quarterly testing aligns the evidence with the platform that actually exists.
Q5: Does a SaaS penetration test satisfy SOC 2 requirements in ANZ?
A: A CREST-certified SaaS penetration test from a provider with ANZ regulatory experience produces compliance evidence that satisfies SOC 2 Type II auditor expectations for security control testing. SOC 2 auditors look for annual testing at minimum, with report evidence confirming scope, methodology, findings, and remediation. The test must cover the SaaS-specific attack surfaces: tenant isolation, API authorisation, SSO security, and role escalation. A generic web application scan does not satisfy this requirement. A structured manual penetration test from a CREST-certified provider does.
