Pentest Strategy for SaaS Before SOC 2 / ISO 27001 Audit

Enterprise procurement teams have standardised on two questions: Do you have SOC 2 Type II? Do you have ISO 27001? For a SaaS company selling to regulated industries, healthcare, or large enterprises, the answer to both is increasingly a precondition to being considered, not a differentiator once shortlisted.

Penetration testing sits inside the evidence set for both frameworks. It also consistently generates the most confusion during audit preparation. The test is ordered, the report is received, and then the auditor asks questions the report cannot answer.

This article covers what SOC 2, ISO 27001, and PCI DSS actually require from a pentest engagement, the most common scoping failures, and what a report must contain to be useful as audit evidence.

Why SaaS Pentest Is Not the Same as Generic Web Pentest

A standard web application pentest assesses a defined application surface: authentication, session management, input handling, access controls, API endpoints, common vulnerability classes (OWASP Top 10 and similar).

A SaaS pentest has the same starting point, but the scope that matters for audit purposes extends further:

Multi-tenancy isolation. The defining security property of a SaaS platform is that tenant A cannot access tenant B's data. This isolation must be explicitly tested — not assumed from the architecture. A pentest that does not test tenant boundary enforcement is missing the most important test for a SaaS product.

Infrastructure layer. SaaS products run on cloud infrastructure. Misconfigurations in storage permissions, IAM policies, container orchestration, or CI/CD pipeline access can expose customer data without touching the application layer. Infrastructure-level testing must be in scope.

API security beyond OWASP API Top 10. Most SaaS platforms expose APIs to customer integrations, webhooks, and third-party connections. Rate limiting, authentication token handling, scope enforcement, and horizontal privilege escalation across API endpoints are frequently under-tested.

Developer and deployment pipeline access. Supply chain attacks on SaaS products increasingly target the build and deployment pipeline rather than the production application. A SaaS pentest should include assessment of whether the CI/CD environment could be used as a vector.

A generic web application test delivered by a provider unfamiliar with SaaS architecture will miss the multi-tenancy and infrastructure elements. These are often where the most significant findings occur.

What Each Framework Requires

SOC 2

SOC 2 is an attestation standard managed by the American Institute of Certified Public Accountants (AICPA). Penetration testing relates primarily to the Availability, Confidentiality, and Security Trust Services Criteria.

The SOC 2 criteria do not prescribe a specific frequency or methodology for penetration testing. What the auditor examines is whether the organisation has a defined policy for security testing, whether tests are conducted according to that policy, and whether findings are remediated within defined timelines.

For SOC 2 Type II (the audit most enterprise buyers require), the audit period is typically 6 or 12 months. A pentest conducted before the audit period began, with no testing during the period itself, is unlikely to satisfy auditor expectations. The test must fall within the audit period, and the remediation evidence must show closure of findings within that same period.

The SOC 2 auditor will also assess whether the scope of testing was appropriate. An application pentest that excluded the infrastructure layer, with a SaaS product that runs on cloud infrastructure, will prompt questions.

ISO 27001:2022

ISO 27001 Annex A Control 8.8 requires vulnerability management — identification and remediation of vulnerabilities in systems. Control 5.37 and related controls address documented operating procedures for security operations.

Penetration testing maps specifically to ISO 27001:2022 Annex A Control 8.26 (application security requirements) and supports the risk treatment framework in Clause 6. Unlike SOC 2, ISO 27001 certification auditors evaluate the management system, not individual controls in isolation. The pentest is evidence that your organisation systematically identifies and addresses technical vulnerabilities.

Annual penetration testing is the common industry baseline and aligns with ISO 27001 audit cycle expectations. Certification auditors conducting surveillance audits (typically annual after initial certification) will look for test results as part of the continuous improvement evidence.

PCI DSS v4.0

PCI DSS v4.0 (effective as the sole active version from March 2024) has specific penetration testing requirements under Requirement 11.4.

• 11.4.1: A penetration testing methodology exists and is documented

• 11.4.3: External penetration testing is performed at least annually and after any significant infrastructure or application upgrade

• 11.4.4: Exploitable vulnerabilities found during penetration testing are corrected, and testing is repeated to verify correction

• 11.4.5: If segmentation is used to isolate the cardholder data environment (CDE), penetration testing must validate that segmentation controls are effective, at least every six months

The PCI DSS scope question — what is in the CDE and what reduces scope — must be resolved before planning the pentest. A test that does not validate segmentation controls will not satisfy Requirement 11.4.5 for organisations using segmentation.

Five Common Scoping Failures

1. Excluding production in favour of a staging environment. Staging environments rarely mirror production configuration accurately enough to produce valid findings. Auditors from all three frameworks will ask whether the tested environment reflects what customers actually use. Where testing production directly creates operational risk, the mitigation is careful timing and coordination, not substituting an inaccurate environment.

2. Testing the application but not the infrastructure. For a cloud-hosted SaaS product, infrastructure misconfigurations are a significant attack surface. An application-only scope produces an incomplete picture of actual exposure.

3. Defining scope too narrowly around the primary application, missing adjacent systems. Audit management portals, customer-facing APIs, internal dashboards with privileged access, and developer tooling are frequently out of scope in initial engagements and frequently where meaningful vulnerabilities are found.

4. Not specifying multi-tenancy testing. Unless tenant isolation testing is explicitly included in the scope document, most providers will not conduct it. This must be specified, and the provider must demonstrate experience testing isolation in architectures similar to yours.

5. No retesting budget. ISO 27001 and PCI DSS (Requirement 11.4.4) require verification that findings have been remediated. A pentest engagement that does not include retesting produces an open question at audit time: were the vulnerabilities fixed correctly? Budget for retesting when scoping the initial engagement.

Planning the Test Cycle

Annual testing as a single large engagement is the minimum. SaaS companies that treat pentest as a one-time pre-certification event create a compliance gap for every year after the initial audit.

A more defensible approach for SaaS products with active development:

• Annual full-scope engagement (external network, application, infrastructure, multi-tenancy, API)

• Targeted testing after significant releases or architectural changes — scope limited to the changed components

• Continuous automated vulnerability scanning between manual test cycles — this is not a substitute for manual testing, but it shortens the window between manual engagements during which undetected vulnerabilities could exist

For SOC 2 Type II, the goal is to have test results and remediation evidence that cover the audit period. Map your test cycle to your expected audit dates, not to a calendar year that may not align.

What the Report Must Contain

An audit is satisfied by documentation that demonstrates your security controls are operating as intended. A pentest report that is useful as audit evidence contains:

Scope description. Explicit statement of what was tested (systems, environments, methodologies) and what was explicitly excluded and why.

Methodology statement. Which testing methodology was applied — PTES (Penetration Testing Execution Standard), OWASP Testing Guide, NIST SP 800-115, or equivalent. Auditors look for recognised methodology, not proprietary frameworks.

Findings with severity ratings. Each finding must include: description of the vulnerability, evidence of exploitation or proof of concept, CVSS score or equivalent severity rating, affected systems, and recommended remediation.

Executive summary. A narrative suitable for board and management review that characterises overall risk posture without requiring technical expertise to interpret.

Remediation tracking. For audit purposes, the report itself is not sufficient — there must be a remediation log showing: finding reference, assigned owner, target remediation date, and closure evidence (retesting result or configuration change record).

A report from a provider that does not include all of these elements will generate auditor findings. Review the report structure before accepting the engagement deliverable.

Working with Findings: Remediation vs Risk Acceptance

Not every finding from a pentest requires immediate remediation. A formally documented risk acceptance, approved by the appropriate authority, is a valid audit response for findings that cannot be remediated within the audit period or where the cost of remediation is disproportionate to the risk.

Risk acceptance is not a workaround. It is a documented management decision that acknowledges the finding, assesses the likelihood and impact, and accepts the residual risk with defined conditions (compensating controls, review date, owner). For ISO 27001, this connects to the Statement of Applicability and the risk treatment process. For SOC 2, the auditor will assess whether the risk acceptance is reasonable and whether compensating controls are in place.

Undocumented risk acceptance — where a finding is simply not remediated and not formally accepted — is the worst outcome. It signals to the auditor that the organisation's vulnerability management process does not function end-to-end.

If you are planning a pentest ahead of SOC 2 or ISO 27001 certification this year, we help SaaS companies define scope, select appropriate methodology, and prepare the evidence documentation auditors expect. Reach out to discuss your timeline.