SOC 2 penetration test: scope, timing and the report

Scope comes from the system description, not from a price list

A SOC 2 report describes a system: what the service does, where its boundaries are, which subservice organizations sit inside it, and what commitments you have made to customers. Everything the examination touches is defined by that description, and your test scope should be traceable to the same document.

The practical test is simple. If a reviewer holds the system description in one hand and the test scope statement in the other, can they see which parts of the described system were examined and which were not? If not, the report is interesting but it is not evidence, because nobody can tell what it covers.

Write the scope statement before asking for quotes. A tester quoting against "our SaaS platform" will price a different engagement from one quoting against "the multi-tenant web application, its public and partner APIs, the customer-facing admin console and the AWS account hosting them, excluding the marketing site and the corporate network".

What belongs in scope, and what usually does not

Typical scope decisions for a SOC 2 program

Component	Usually in scope	Why
The multi-tenant application	Yes	Tenant isolation is the question your customers are actually asking, and nothing else in the evidence pack answers it.
Public and partner APIs	Yes	Often broader than the interface, and frequently missing the authorization checks the interface enforces.
Administrative consoles	Yes	Privilege escalation into an admin role is the highest-impact finding available in most products.
Cloud account configuration	Usually	Identity policy, storage exposure and network segmentation carry more real risk than most application findings.
CI/CD and source control	Consider	A pipeline that can deploy to production is production. Include it if it is in the system description.
Corporate IT and workstations	Rarely	Relevant to your risk assessment, but usually outside the boundary of the described service.
Marketing website	No	Outside the system, and it consumes budget that belongs on the product.
Subservice organizations	No	You cannot test your cloud provider. Their controls are covered as complementary subservice organization controls and by their own assurance report.

Production or a copy?

Test the environment your customers use, or an environment you can demonstrate is identical to it. A staging environment with a different identity provider, relaxed network rules and synthetic data does not answer questions about production, and an experienced reviewer will spot the substitution in the scope statement.

Where production testing genuinely carries unacceptable risk – a payment flow, a medical workflow, a system with irreversible side effects – the honest approach is a documented hybrid: destructive classes of testing on a mirrored environment, everything else against production, with the split explained in the report. A documented compromise is defensible; an undocumented one is a finding waiting to be raised.

Authenticated testing is the point

An unauthenticated external test tells you what an anonymous internet user can reach. For a SaaS product, that is the least interesting question available, because the interesting attacker is a paying customer.

Provide accounts. At minimum two separate tenants and, within one of them, one account per privilege level. The findings that decide whether your report is useful – reading another tenant's data, escalating from a read-only role, reaching an administrative function through an API that the interface hides – can only be produced with credentials in hand.

Where the test lands in the calendar

The two report types are defined by what they opine on. In the international standard for service organization assurance the distinction is set out in the report titles themselves: a type 1 is a "report on the description and design of controls at a service organization", and a type 2 is a "report on the description, design and operating effectiveness of controls at a service organization". The AICPA suite follows the same split.

That single difference drives the schedule. A type 1 is a point in time: the test needs to exist and be reasonably current when the report is dated. A type 2 covers a period, and evidence has to belong to that period. A test performed before the observation window opened describes a system that the examination is not looking at.

• Run readiness and remediation first. Testing an environment you already know is unfinished converts your own backlog into report findings, each of which then has to be tracked and retested at report prices.
• Schedule the test so that testing, remediation and retest all fall inside the observation window for a type 2.
• Leave four to six weeks between the test and the end of the window. Remediation and retest take longer than anyone plans, and a critical finding fixed after the window closes is a critical finding that was open throughout it.
• For a first type 2, three months is the shortest window most auditors will accept. Twelve is what a mature enterprise buyer expects to see on the second cycle.

What the report has to contain

Most penetration test reports are written for engineers. A report bought for a SOC 2 program has to survive two other readers as well, and the structure below is the minimum that lets it.

Report sections, and who each one is for

Section	What it must contain	Who reads it
Scope statement	Named systems, environments, account types and tenants; the exclusions; the traceability back to the system description	The auditor, first. The customer's reviewer, first.
Dates	When testing ran, not only when the report was issued, and the date of any retest	Everyone. This is the field that decides whether the report is current.
Methodology	The approach, the tooling class, and what was manual rather than automated	The reviewer deciding whether this was a scan with a cover page.
Severity scale	The scale, its definitions, and how it relates to the risk scale used elsewhere in your evidence	The auditor, who has to reconcile "high" here with "high" in your risk register.
Findings	Reproduction detail sufficient to verify the fix, and evidence of exploitation rather than an assertion	Your engineers, and any reviewer who doubts the finding.
Remediation status	What was fixed, what was accepted, and by whom the risk was accepted	The auditor, who will look for an accepted risk that contradicts your own policy.
Retest evidence	Independent confirmation that the fix works, with its own date	The customer's reviewer. This is the section they check first.
Executive summary	A plain account a procurement reader can act on without over- or under-reacting	The person who decides whether the deal moves.

Retest: the difference between a claim and evidence

A finding marked "remediated" on the strength of a client email is a claim. A finding retested by the same firm, with a date and a short note on what was verified, is evidence. The cost difference is a few hours; the credibility difference is the whole point of buying an independent test.

It also matters to the examination. The service auditor is looking at whether your vulnerability handling actually closes things, over the period. A test report with an open critical finding and no follow-up is, read carefully, evidence against the control it was bought to support.

What you may hand to a customer

Three documents, in decreasing order of detail.

• The full report, under a non-disclosure agreement, to a customer whose review genuinely needs it. Most enterprise reviewers will accept this and many require it.
• A redacted report, where reproduction detail for unfixed findings is removed but the scope, dates, methodology, severity distribution and retest evidence remain. Redaction that removes the scope statement or the dates is not redaction, it is a leaflet.
• An attestation letter: a short signed statement from the testing firm naming the scope, the dates, the methodology and the fact that findings were remediated and retested, with no finding detail at all. This is the document to attach to a questionnaire before an NDA is in place.

The same logic exists on the SOC side. A SOC 2 report is restricted to specified parties who understand the system, which is why it travels under agreement. A SOC 3 addresses the same subject matter in far less detail and is a general use report that can be freely distributed, so if a customer simply wants something to file, ask your CPA firm to issue one from the same examination.

The questionnaire questions one test closes

A properly structured report is the cheapest way to answer a whole block of a security questionnaire. Typically it settles: whether independent testing is performed and how often; who performs it; whether testing covers the production environment; whether authenticated and multi-tenant testing is included; how findings are risk-rated; the remediation timescales by severity; whether fixes are verified; and when the most recent test was performed.

That is eight to ten questions, answered by attaching one document. It is worth structuring the report so that a reviewer can find each answer without reading the finding detail, because the reviewer will not read the finding detail.

Testing again after a change

The annual cadence is a convention, not a rule, and it is the wrong trigger on its own. The right trigger is significant change to the described system: a new tenancy model, a new identity provider, a migration between cloud accounts, a new public API surface.

The EU's own technical rules for NIS2 entities describe testing in exactly these terms rather than as a calendar item. Point 6.5 of the Annex to Commission Implementing Regulation (EU) 2024/2690 requires entities to establish "the need, scope, frequency and type of security tests" from a risk assessment, to test "according to a documented test methodology", to "document the type, scope, time and results of the tests, including assessment of criticality and mitigating actions for each finding", and to "apply mitigating actions in case of critical findings". A risk-driven retest after a major change is precisely what that describes, and it reads well in an evidence pack.

For the underlying question of why a test is expected at all, see does SOC 2 require a penetration test?. For who signs which document at the end of it, see who can issue a SOC 2 report in the EU.