SOC 2 penetration testing requirements for SaaS startups

Every SaaS founder preparing a first SOC 2 audit hears the same sentence from a prospect's procurement team: "send us your latest pentest report". So the question "what are the SOC 2 penetration testing requirements" gets asked as if there were a checklist item with that name. There is not. This article explains what SOC 2 actually says, what auditors look for in practice, what a report needs to contain to serve as evidence, how to scope a test of a multi-tenant SaaS, and how to make the test a repeatable part of your pipeline rather than a yearly scramble.

What SOC 2 says, and does not say, about penetration testing

SOC 2 is an attestation framework defined by the AICPA. The auditor examines your controls against the Trust Services Criteria (TSC): the Common Criteria (the CC series, present in every SOC 2 report and covering security) and the optional categories Availability, Processing Integrity, Confidentiality and Privacy. The criteria describe control outcomes, not procedures. No criterion states that the entity performs a penetration test, and none sets a frequency.

What the CC series does require is that the organisation identifies and manages vulnerabilities and evaluates whether its controls are present and functioning. In practice two criteria carry most of the weight: CC4.1, on ongoing and separate evaluations of controls, and CC7.1, on detecting configuration changes and newly discovered vulnerabilities. A penetration test is one of the most direct ways to evidence both, which is why most auditors ask for one and why most SOC 2 reports describe one. The test is evidence. Whether it is sufficient evidence is the auditor's call, for your system and your period.

What the report must contain to work as evidence

• Scope and dates. The exact systems, environments, URLs, API hosts and accounts tested, and when. The auditor maps this to your system description. An untested production component is a gap, not a footnote.
• Methodology. Black, grey or white box; authenticated or not; which reference was used (OWASP ASVS, OWASP API Security Top 10, PTES, NIST SP 800-115).
• Findings with reproducible evidence. Each finding needs the request, the payload, the response or screenshot, and a severity with its rationale (CVSS 3.1 is the common language). A score without proof is weak evidence.
• Status of each finding over time. Open, fixed, accepted risk, with dates. For a Type II report the remediation and retest record matters as much as the findings themselves.
• Who tested, and their independence. Internal testing is acceptable in many audits; what matters is that the tester is independent of the team that built the system and that the method is documented.

Darkmoon's reports are built around these points: findings qualified EXPLOITED, CONFIRMED or UNCONFIRMED by an adversarial rubric, with the evidence kept; Markdown and JSON output in the Community edition; branded PDF and web reports with CVSS 3.1, MITRE ATT&CK and ISO 27001 mapping in Pro. The criterion is machine-verified exploitation, not a probability score, which is precisely the distinction an auditor wants to see.

Scoping a multi-tenant SaaS test

A SaaS estate has a shape that generic scopes miss. Six areas belong in every scope document.

• Tenant isolation. Can tenant A read, write or enumerate tenant B's data by changing an identifier, a JWT claim, a subdomain or a webhook target? This is the finding that ends sales conversations, and testing it needs at least two test tenants and two roles per tenant.
• Authentication and session. SSO and OIDC flows, invitation links, password reset, API keys, personal access tokens, service accounts. A misconfigured OIDC redirect is as common as a weak password.
• The API behind the UI. Most SaaS vulnerabilities live in the API: broken object-level authorisation, mass assignment, missing rate limits on expensive endpoints, GraphQL introspection and batching.
• Cloud configuration. The AWS, Azure or GCP account the product runs in: storage buckets, IAM roles, metadata endpoints, secrets in environment variables and CI logs.
• CI/CD and the software supply chain. Pipeline secrets, runner permissions, container registries, infrastructure-as-code state files.
• Admin and support tooling. Internal back-offices and impersonation features are often the weakest authenticated surface, and the one with the broadest reach into customer data.

Exclude what you do not own (your identity provider's SaaS, your payment processor) and document the exclusion. Test against a dedicated tenant on production-like infrastructure, not a developer laptop.

Make the test repeatable, not annual

A Type II period covers months. One test at the start proves little about the state of the system at the end, after hundreds of deploys. The pattern that works: a scheduled or per-change autonomous test gated in CI, plus a deeper engagement before the audit period closes. Darkmoon's CI integrations (GitHub Actions, GitLab CI/CD, Jenkins) run a campaign from a pipeline, write a severity summary to the job, emit SARIF for code-scanning views, and fail the job on findings according to your policy. Each run leaves a dated report. That record, a finding opened on one date, fixed on another, retested on a third, is the Type II evidence a single PDF cannot give.

Data residency: your customers will ask

A pentest of a SaaS is a pentest of your customers' data path, so where the testing tool sends what it sees matters, especially for EU customers and for anyone bound by GDPR Article 28 processor terms. Darkmoon is self-hosted by default under GPLv3, and its Privacy Gateway tokenizes IPs, hostnames, URLs, emails, credentials and internal paths on your machine before anything reaches the model, with a local-model option via Ollama or llama.cpp. We explain the mechanism and its honest limits in Inside the Privacy Gateway.

Where NIS2 fits for a SaaS vendor

SaaS and software publishers are not a sector listed in NIS2 Annex I or II as such. A SaaS company falls within Directive (EU) 2022/2555 only if its actual activity matches a listed type: cloud computing service provider, data centre or content delivery network provider (Annex I, digital infrastructure), managed service provider or managed security service provider (Annex I, ICT service management), or online marketplace, search engine or social networking platform (Annex II, digital providers), and only once it is at least a medium-sized enterprise. Otherwise NIS2 reaches a SaaS vendor indirectly, through customers that are essential or important entities and must manage supply-chain security under Article 21(2)(d). Those customers will ask the same questions a SOC 2 auditor asks, and a pentest report is the usual answer. Our NIS2 guide covers the sector lists and the size rule. As of 4 October 2026, the French transposition law is not in force.

Where to start

If you are a SaaS team preparing a SOC 2 audit, start with the SaaS and startups page for how teams self-host Darkmoon and wire it into CI so every deploy leaves evidence. If you need a report produced for you, with the legal framework, scoping and debrief handled by ASC-IT's experts, Pentest on Demand is a flat €799 per engagement, indicative and adjusted to the final scope.