Learn · SOC 2 Evidence
SOC 2 and
Penetration Testing
No Trust Services Criterion names a penetration test as a mandatory activity. The obligation comes from the controls you describe: if your system description says you perform an annual independent penetration test, the auditor will test that you did.
The sentence is the standard. SOC 2 has no prescriptive control list. You describe your controls; the CPA firm evaluates whether that description is fairly presented and whether those controls operated.
Plain-English explainer · TSC 2017 (rev. 2022) · AT-C 205 examination · Last reviewed August 2026
SOC 2 does not require a penetration test. No criterion in the 2017 Trust Services Criteria says an organisation must perform one. What creates the requirement is your own system description: the moment management writes “an independent penetration test is performed annually” into Section 3, that sentence becomes a control the service auditor is obliged to evaluate. That inverts the usual question. The one worth asking is “what did we commit to?” A SOC 2 is an attestation performed by a licensed CPA firm under AT-C sections 105 and 205 — an examination of what you said against what you did. In practice, most control sets do describe independent technical testing, because a mature vulnerability programme is hard to evidence without one.
Where the requirement comes from
Three layers, and only one of them binds you
A SOC 2 obligation is assembled from three documents, and people argue about the wrong one.
Layer 1 — the criteria
TSC 2017 (rev. points of focus 2022)
Sets outcomes and leaves the activities to management. No criterion says “perform a penetration test.” Vulnerabilities must be identified, changes managed and internal control evaluated — by means you choose.
Layer 2 — your description
Section 3, prepared under DC section 200
Where the obligation is created. State that an independent test runs annually and high findings close in 30 days, and you have written a testable commitment into an audited document.
Layer 3 — the examination
AT-C 105 and AT-C 205
The auditor evaluates whether the description is fairly presented, whether controls were suitably designed and — in a Type 2 — whether they operated throughout the period. Your words become the test programme.
The riskiest moment in a pen-testing control is the drafting of it, rather than the running of it. “Penetration testing is performed periodically” cannot be tested; “quarterly” is testable and expensive. Most organisations land on annual testing plus testing after material change. See the SOC 2 controls list for how the surrounding control set is worded.
Criteria mapping
Where a pen test actually attaches
Mapping is convention — the criteria do not assign activities to themselves. Which criterion a control lands under changes the evidence requested. Criterion text below is paraphrased; the authoritative wording is the AICPA’s.
CC4.1
Ongoing and/or separate evaluations to ascertain that internal control is present and functioning (COSO Principle 16).
The only place the criteria name penetration testing: a point of focus listing it among the ongoing and separate evaluations management may use — beside internal audit assessments, compliance assessments, vulnerability scans and third-party assessments. Points of focus illustrate how a criterion might be met; the criterion itself is what the auditor evaluates.
CC7.1
Detection and monitoring procedures to identify configuration changes that introduce vulnerabilities, and susceptibility to new ones.
The natural home for vulnerability identification. A point of focus here names vulnerability scans — periodically and after significant change, with timely remediation. Most control sets put scanning here and the penetration test alongside it.
CC8.1
Changes to infrastructure, data, software and procedures are authorised, tested, approved and implemented.
Where “after significant change” lives. Commit to retesting after material architectural change and the auditor reconciles the change register against the testing record, then asks why a change did or did not trigger a test.
CC6.6 / CC6.8
Logical access protects against threats outside the boundary; malicious software is prevented or detected.
Where external-facing findings land. In practice, unresolved perimeter issues tend to draw more attention than internal ones of equal severity, because the criterion is explicitly about threats originating outside the boundary. A test that produced no detections also invites a question about CC7.2.
CC3.2
Risks to the achievement of objectives are identified and analysed as a basis for deciding how they are managed.
The upstream justification. The answer to “why this scope, this frequency, this test type” should be a risk assessment rather than a customer request.
Scanning vs testing
Why an auditor may expect both
Neither is required by the criteria. Both are commonly described, and once described, both are tested.
| Dimension | Vulnerability scanning | Penetration testing |
|---|---|---|
| What it is | Automated interrogation of hosts, images or code against a signature and configuration database. | A human-led attempt to reach an objective, chaining weaknesses a scanner scores individually as low. |
| Typical cadence | Continuous to quarterly. Pipeline scanning often runs on every build. | Annual, or semi-annual in higher-risk environments, plus after significant architectural change. |
| Who performs it | Normally the platform or security engineering team, using a licensed tool. | A third-party testing firm, or an internal testing team whose reporting line sits outside engineering. |
| Cost order of magnitude | A tooling subscription, amortised across the year and largely fixed regardless of estate size. | A professional-services engagement priced in tester-days — roughly an order of magnitude higher per occurrence. |
| What it structurally cannot find | Broken authorisation logic, business-logic abuse, chained privilege escalation, anything with no signature. | Drift in the eleven months after it ends. It is a snapshot of one configuration on one set of dates. |
| Artefact the auditor receives | Scheduled scan exports with run dates, target counts and severity breakdowns, plus the ticket trail behind them. | A dated report naming the firm, the testers, the methodology, the test window, each finding and its severity. |
| Population it creates | A population of cycles to sample across the period — a strong operating-effectiveness artefact. | One or two events in twelve months. High weight per event, no sampling depth. |
| Where it usually sits | CC7.1, with remediation timeliness tested against the window your policy states. | CC4.1 as a separate evaluation, and CC8.1 where the trigger is a significant change. |
| Independence | Run in-house as a matter of course; rarely a question. | Where the description says “independent”, the auditor asks who tested and whether they are separate from those who build and run the system. |
| Failure mode | Findings accumulate faster than the stated window closes them — the exception sits in the remediation control. | Scope drifts from the boundary, or the retest never happens and closure rests on a ticket status. |
The sampling asymmetry is why auditors gravitate towards both. An annual penetration test is a population of one: a single event, with no view of whether the discipline held for the other eleven months. Scanning supplies that continuity, and a scanning-only programme is exposed on independence and on the issues no signature detects — broken authorisation logic, business-logic abuse, chained privilege escalation.
Test types and quality
What kind of test, and how to tell a real one
The criteria specify no test type, so the answer comes from your boundary. The column that matters most is the last one: every carve-out has to be visible in the scope statement, or the target list will look thinner than the boundary it serves.
| Test type | Inside a SaaS boundary? | What it evidences | When it is a carve-out |
|---|---|---|---|
| External network | Usually | Exposure of internet-facing hosts, services and edge configuration. Supports CC6.6. | Where the perimeter is entirely the cloud provider’s and you operate no public addresses of your own. |
| Internal network | Sometimes | Lateral movement and privilege escalation from an assumed-breach position. Supports CC6.1 and CC6.3. | Fully managed or serverless estates with no corporate-operated network inside the boundary. |
| Web application | Almost always | Authorisation logic, session handling, injection and business-logic abuse in the product itself. | Rarely carved out, because the application is usually the system being described. |
| API | Almost always for API-first products | Object- and function-level authorisation, rate limiting, token handling, mass assignment. | Where the API is internal-only and unreachable from any customer network. |
| Cloud configuration review | Commonly, as a companion | IAM policy, key management, network segmentation, logging and storage exposure. | It reviews configuration rather than exploiting it, so it supports a penetration test without replacing one. |
| Mobile application binary | Only where a mobile client is described | Local storage, certificate handling, hardcoded secrets, client-side control bypass. | Where the described system is the backend and the mobile client belongs to the customer. |
| Social engineering / phishing simulation | Occasionally | Whether awareness training and reporting channels work. Supports the awareness and communication criteria in CC1 and CC2. | Frequently excluded on legal and HR grounds. Say so explicitly in the scope statement. |
| Full red team | Rare at SOC 2 scope | Detection and response end to end. Supports CC7.2 through CC7.4. | Usually out of scope, because the objective is detection maturity rather than the vulnerability programme. |
Methodology is the second half of the answer. For application and API scope the reference works are the OWASP Web Security Testing Guide and the OWASP API Security Top 10; for the technical process, NIST SP 800-115, Technical Guide to Information Security Testing and Assessment; for engagement structure, the Penetration Testing Execution Standard. A report that cites none of them is the first signal you are looking at tooling output with a cover page.
Six markers the auditor and the buyer both look for.
- ·Named testers, with the credentials they hold — OSCP, CREST registration, GPEN or equivalent — rather than a firm logo alone.
- ·Tester-days, so a reader can judge depth against the size of the target list.
- ·Test start and end dates, stated separately from the report date.
- ·A methodology section naming the standard followed and the phases performed.
- ·Reproduction steps for each finding, sufficient for an engineer to reproduce and a retester to verify.
- ·An explicit statement of what was out of scope, and why.
Control language
The sentence, rewritten
Every word in the middle column costs you an artefact in the right-hand one. That is the trade: a testable control is a control you have to feed. Draft it with the evidence request already in view.
| Weak wording | Testable wording | What it now obliges you to evidence |
|---|---|---|
| “Penetration testing is performed periodically.” | “An independent penetration test of the production application and supporting infrastructure is performed at least annually, and within 30 days of a significant architectural change as defined in the change management policy.” | A dated test in every twelve-month period; a written definition of “significant” that the change register can be filtered against; and a reconciliation showing which changes met it and what each one triggered. |
| “Findings are remediated in a timely manner.” | “Findings rated High or Critical are remediated within 30 days of triage completion and verified by tester retest.” | A triage date and a severity per finding; a technical fix artefact per finding; and a retest letter naming which findings were verified closed and when. |
| “An independent penetration test.” | “A penetration test performed by a third-party testing firm engaged under a signed statement of work” — or “by an internal testing team reporting to the CISO, outside the function that builds and operates the system.” | A choice. Independence becomes an assertion the auditor evaluates, against a contract in the first case and against reporting lines in the second, so the description has to say which one you mean. |
| “The production environment is tested.” | “The production web application, its public API, the administrative console and the cloud accounts hosting them are tested.” | A target list that reconciles line by line to the boundary in Section 3, plus a documented reason for anything named there and absent from the test. |
| “Significant findings are escalated.” | “Findings rated Critical are reported to the Security Steering Committee at its next scheduled meeting, and to the CTO within two business days of triage.” | Minutes or a dated notification for every Critical finding — an artefact carrying a name, a forum and a date, rather than an assurance that escalation happens. |
Worked example
One control sentence, three obligations
A payments platform runs a twelve-month Type 2 from 1 July 2026 to 30 June 2027, describing its control as: “An independent penetration test of the production application and supporting infrastructure is performed at least annually and following significant architectural change. Findings rated high or critical are remediated within 30 days and retested.” That sentence creates three obligations — annual, change-triggered, remediation — evidenced separately.
12 Mar 2026
Penetration test #1 performed; report dated 27 Mar 2026.
Before the period. Relevant to design and context; evidences nothing about operation inside it.
1 Jul 2026
Observation period opens (1 Jul 2026 – 30 Jun 2027).
Both limbs of the control must now be evidenced inside this window.
4 Nov 2026
Production re-platformed into a second cloud region.
A significant architectural change on the register. It triggers the second limb, independently of the annual cadence.
8 Feb 2027
Test #2 performed; two high findings; report dated 22 Feb 2027.
Satisfies the annual limb. Whether a test three months after the re-platform satisfies “after significant change” depends on how management defined timeliness.
6 – 19 Mar 2027
Both high findings remediated; retest letter issued 19 Mar 2027.
26 days measured from report delivery on 22 February, the clock start management defined in its remediation policy. Had the policy measured from finding identification on 8 February, the same remediation would have run to 39 days and breached the 30-day window — which is why the definition matters more than the fix date.
The interesting failure sits in the gap between 4 November and 8 February: management never defined how soon “following significant architectural change” means, so the auditor must ask what the organisation considers timely and whether that view was applied consistently. Defining the window removes the argument.
When to book it. Work backwards from period end. Report delivery, your stated remediation window and the retest all have to land inside the period for the control to close inside it. With a 30-day window and a typical two-to-three week reporting turnaround, testing has to start at least eight to ten weeks before period end — and booking lead time with a reputable firm is commonly four to eight weeks on top of that, so the decision is really made a quarter ahead. Typical engagement length for a single-application SOC 2 scope is one to two testing weeks plus one to two weeks of reporting. A test performed in the final month of the period usually leaves the remediation limb with nowhere to close, which is how a perfectly workable control becomes an exception.
Budget for three separate invoices. The testing firm is engaged and paid separately from both TCSA and the CPA firm; the CPA firm’s attestation fee is billed separately again. Where TCSA runs readiness, our fee is fixed from $4,000 for early-stage startups, quoted after scoping.
Timing and reliance
Can a test from before the period be relied on?
It depends on the frequency you stated, on whether the test remains relevant to the system as it now exists, and on which report you are producing. No rule fixes a number of months.
| Scenario | Type 1 treatment | Type 2 treatment | What the auditor asks for |
|---|---|---|---|
| Annual frequency; the most recent test predates the period start. | Usually sufficient. A Type 1 addresses design and implementation as of a date, so evidence that the process exists and the most recent required test occurred generally carries. | Acceptable only where the period is short, this is the most recent occurrence the stated cadence requires, and nothing material has changed. | The report, the stated frequency in Section 3, and the change register for the period. |
| A full twelve-month period with no test inside it, against an annual commitment. | Still workable if the control is designed and the last test remains current against the stated cadence as of the report date. | Hard to sustain. A full period with no occurrence of an annual control leaves nothing to test — an operating-effectiveness deficiency rather than a design one. | The date of the last test, the next scheduled date, and management’s written explanation of the gap. |
| A significant architectural change occurred inside the period, and the description commits to testing after such changes. | An as-of-date question: is the trigger defined, is the process in place, and did any qualifying change before that date go untested? | A pre-period test cannot cover it. The change creates a second, separate occurrence with its own evidence, and “we test annually” is no answer to it. | The change register filtered to your definition of significant, and the test each qualifying change triggered. |
| The test ran inside the period, but the report was issued after period end. | Rarely an issue; the as-of date governs and the test window sits before it. | Generally fine. The control is performance of the test; the report is the artefact that evidences it. | The report available to the service auditor before the report is dated, plus the tester’s test dates confirming the work fell inside the period. |
| The test ran inside the period; high findings were still open at period end. | A design question — is the remediation control written with a defined window, an owner and an escalation path? | Turns on your own window. Inside it, the control is operating. Past it, expect an exception unless a dated risk acceptance exists. | The findings register with triage dates, the policy defining the window, and any risk acceptance with its approver and review date. |
The pattern across the rows is that a Type 1 asks a narrower question — design and implementation as of one date — so evidence that the process exists and the most recent required test occurred is usually enough. A Type 2 asks whether this operated throughout the period, which is where a pre-period test runs out of road. See choosing your observation period.
Evidence
What the CPA firm actually requests
The request list as it typically arrives, and the version of each artefact that comes back.
| Requested | What is accepted | What gets rejected |
|---|---|---|
| Engagement letter or SOW | Signed and dated, naming the firm, test window, methodology and environments in scope. | An undated proposal or a PO with no scope statement. |
| Scope definition | The explicit target list — applications, APIs, IP ranges, cloud accounts, mobile builds — mapped to the boundary in Section 3. | A scope naming a product the description omits, or omitting one it covers. |
| The final report | Dated, attributed to a named firm, with test dates, methodology, named testers, findings and severities. | A one-page “attestation of testing” with no findings section; PDFs with no test dates. |
| Tester independence | A third-party firm, or an internal team reporting separately from those who build and run the system. | The engineering team that wrote the code, where the description claims independence. |
| Findings register | Every finding with severity, owner, triage date, target date and status, reconciled to the report. | A register holding fewer findings than the report. |
| Severity rating methodology | A dated, pre-existing basis for rating and re-rating — commonly CVSS base scores with documented environmental adjustment. | A downgrade applied after the fact, by the finding owner, with no methodology behind it. |
| Remediation per sampled finding | Ticket with dates, change record and the technical artefact — configuration diff, merged code, patch version, updated rule. | A ticket marked Closed with no artefact; a screenshot with no timestamp. |
| Retest confirmation | A retest letter from the same firm confirming which findings were verified closed, and when. | Self-attested closure where the description or the tester’s methodology promised verification. |
| Risk acceptance for open items | Dated acceptance at the authority level your policy names, with rationale, compensating controls and a review date. | An open high finding at period end with no acceptance and no revised date. |
Population first, then sample.
The population is set by the commitment you stated, rather than by the activity you happened to perform. Describe an annual test and the population inside a twelve-month period is one occurrence. Describe quarterly scanning and it is four cycles. The AICPA publishes no mandatory sample-size table for SOC 2; firms set sizes under their own methodology. The ranges below are what those methodologies commonly produce, and they are market practice rather than a rule you can cite back at an auditor.
| Frequency described | Population in 12 months | Sample commonly taken |
|---|---|---|
| Annual | 1 | 1 of 1. No sampling relief — the single occurrence is examined in full, and a missed cycle is a failed control. |
| Semi-annual | 2 | 2 of 2. Both occurrences, for the same reason. |
| Quarterly | 4 | 2 to 4. At this population size many firms simply take all four, because the effort saved by sampling is negligible. |
| Monthly | 12 | 2 to 5, selected across the period rather than clustered. |
| Weekly | ~52 | 5 to 15. |
| Daily | ~250 | 15 to 40. |
| Continuous or automated | >250 | 25 to 60, or a full-population extract accompanied by a completeness reconciliation. |
Remediation carries two populations of its own, and they are tested separately. The first is the findings population: every finding at the severities your policy commits to closing. Below roughly twenty-five findings most firms test the lot; above that they sample and the sizes in the table start to apply. The second is the retest population, which is every finding drawn in the first sample — retest evidence is examined for each sampled finding rather than sampled again on top. One deviation rarely stops at the sample it appeared in: firms typically extend the sample or conclude the control failed, depending on what caused it.
Completeness comes before sampling. Before any selection is made, the auditor establishes that the population is complete. For pen-test remediation that means reconciling three counts: the row count in your findings register, the finding count printed in the tester’s report, and a ticketing-system export filtered to the same severities and dates. Where the three disagree, a sample drawn from that register proves nothing about the rest of it, so the request comes back before testing starts. This is the commonest reason a well-remediated programme still generates a follow-up: the register was maintained by hand, three low findings were never entered, and the reconciliation fails on arithmetic rather than on security.
Two dates decide most of these tests: when the remediation clock starts — report delivery, finding identification or triage completion, whichever your policy names, because the auditor measures against the definition you published — and the retest date, the only artefact that independently confirms a fix.
Findings and disclosure
Does every finding end up in the report?
Generally, no. A SOC 2 report is an examination of controls, and readers do not normally see your finding list — publishing exploitable detail to a customer distribution list would be a poor security decision. What appears is second-order, and more consequential.
If findings at the severity your policy covers were not remediated inside your stated window, the deficiency sits in the remediation control and appears in Section 4 as a testing exception. Whether that exception is significant enough to modify the auditor’s opinion is their judgement — most exceptions do not qualify an opinion, but a pattern of unremediated high findings can. Management may respond alongside the exception in Section 4 or in Section 5; in either case that response is unaudited context rather than assurance.
Separately, DC section 200 requires management to disclose identified system incidents that resulted from controls that were not suitably designed or operating effectively, or that otherwise caused a significant failure to meet service commitments during the period. A vulnerability you found and fixed sits inside vulnerability management; the same one exploited before you closed it may well qualify as an incident. Findings, then, are not the risk. Silence about findings you committed to fixing is — and so is a description promising a standard of testing you do not meet, because an inaccurate description is a problem with the report itself rather than with one control inside it.
Scope
Matching the test to the system boundary
The commonest scoping error is testing something adjacent to what the report covers, then finding the mismatch during fieldwork when neither can be changed.
Build the target list from Section 3. Everything inside the described boundary — the production application, its APIs, the supporting infrastructure, the administrative interfaces used to operate it — is fair game. Everything carved out belongs to somebody else’s report: where a subservice organisation is carved out, its infrastructure is covered by its own examination and the complementary controls it expects of you sit with you. The mapping below is where most SaaS boundaries land.
| Boundary component | Typically in scope? | Usual test type | Common reason it is carved out |
|---|---|---|---|
| Production web application | Yes — usually it is the system described | Authenticated and unauthenticated web application test | Rarely carved out. |
| Public API | Yes, where customers call it | API test against the OWASP API Security Top 10 | Where the API is internal-only and unreachable from customer networks. |
| Admin / back-office console | Yes — it operates the described system | Authenticated web application test with role-escalation cases | Where it is third-party SaaS you configure but do not run. |
| Identity provider or SSO tenant | Your configuration is in; the vendor’s platform is theirs | Configuration review plus authentication and session-flow testing | The provider’s own infrastructure sits in its own examination. |
| CI/CD pipeline and artefact registry | Usually, where deployment affects the described system | Configuration review, secrets exposure, build-pipeline abuse paths | Where the pipeline is fully managed and the description scopes runtime only. |
| Cloud account configuration | Yes | Configuration review against the provider’s own published benchmarks | The provider’s hypervisor, physical estate and managed-service internals. |
| Mobile application binary | Only where a mobile client is described | Binary and client-side storage review | Where the described system is the backend alone. |
| Internal network and VPN | Where the boundary includes corporate-managed infrastructure | Internal network test from an assumed-breach position | Serverless estates with no corporate network in scope. |
| Corporate endpoints | Usually out — they support the entity rather than the system | Endpoint configuration and detection validation, where included at all | Commonly excluded; the description should say so explicitly. |
Three checks before the test is booked. Does the target list name every environment the description implies is tested, including administrative planes and the identity provider? Does the test window sit inside the observation period, or is there a documented reason? And does the tester’s scope statement use the same names as the description? That reconciliation is where audit preparation earns its keep.
Cross-framework
Which frameworks actually mandate a penetration test
SOC 2 is unusually permissive here, which is easy to mistake for laxity until you see what a prescriptive framework looks like. The comparison also has a commercial use: where you run SOC 2 alongside PCI DSS or FedRAMP, you inherit a hard cadence from the other framework, and the sensible move is to describe the stricter one once and satisfy both.
| Framework | Mandated? | What the text actually says |
|---|---|---|
| SOC 2 (TSC 2017, rev. points of focus 2022) | No | Outcome-based criteria with no prescribed activity list. Penetration testing appears once, in an illustrative point of focus under CC4.1. The obligation is whatever your Section 3 description commits to. |
| PCI DSS v4.0 / v4.0.1 | Yes | Requirement 11.4: a defined and documented testing methodology (11.4.1); external and internal penetration testing at least once every 12 months and after significant infrastructure or application change (11.4.2 – 11.4.3); exploitable vulnerabilities corrected and testing repeated (11.4.4); and segmentation-control testing at least every 12 months, or every six months for service providers (11.4.5 – 11.4.6). |
| ISO/IEC 27001:2022 | No explicit mandate | Annex A 8.8 requires management of technical vulnerabilities; A.8.29 requires security testing in development and acceptance. Method is left to the organisation. Many certified organisations use a penetration test to evidence 8.8, and certification bodies do not require one as such. |
| ISO/IEC 42001:2023 | No | The AI management system standard addresses AI-specific risk, impact assessment and lifecycle governance. Technical security testing is inherited from whatever security management system runs alongside it. |
| HIPAA Security Rule | No explicit mandate | 45 CFR 164.308(a)(8) requires periodic technical and non-technical evaluation of safeguards, and 164.308(a)(1)(ii)(A) requires a risk analysis. Neither names a penetration test or a frequency. A proposed rule published in January 2025 would add explicit testing requirements; as at August 2026 it had not been finalised. |
| FedRAMP (Rev. 5 baselines) | Yes | Penetration testing forms part of the annual assessment, performed by an accredited 3PAO and covering the mandatory attack vectors in FedRAMP’s published Penetration Test Guidance. NIST SP 800-53 CA-8 is the underlying control. |
Verify each of these against the primary document before you build a control around it — framework text moves, and a requirement number carried over from somebody’s blog post is the easiest way to describe a control you are not actually running. For the ISO comparison in full, see ISO/IEC 27001.
Edge cases
Where this gets contested
The straightforward cases resolve themselves. These generate the calls.
The test found nothing
A clean report prompts questions about depth and scope rather than applause. Keep the methodology section, the tester-days and the target list beside it, so the result reads as coverage rather than as a shallow engagement.
A scan branded as a penetration test
Apply the report-quality markers above. No named testers, no tester-days, no distinct test window, no reproduction steps and no named methodology means you are holding tooling output with a cover page. Where the description says “penetration test” and the evidence is a scanner export, the mismatch sits in the description.
We disagreed with the tester’s severity
CVSS v3.1 base scores, increasingly v4.0, are the market convention, and environmental or temporal re-scoring against your own architecture is legitimate. The auditor asks something narrower than whether the downgrade was right: was there a documented, dated methodology in place before the finding arrived, was it applied consistently across findings, and did someone other than the finding owner approve the re-rating? An undocumented downgrade that happens to move a High out of the 30-day window is the version that becomes an exception.
Continuous testing platforms and bug bounties
A PTaaS subscription can satisfy a described periodic independent test where the vendor issues a discrete, dated, scoped report for each cycle, with named testers and a methodology section. The delivery model is irrelevant; the artefact is what gets tested. A rolling findings dashboard with no dated per-cycle report fails, because there is no occurrence to test and no population to define. A bug bounty evidences continuous coverage and cannot evidence a stated periodic test — and describing both means evidencing both.
The full report cannot be released
Some firms restrict distribution. The auditor needs enough to evaluate the control, under the engagement’s confidentiality terms. Redacting technical detail works; withholding dates, scope, severities and status does not.
A finding was exploited before it was fixed
That moves out of vulnerability management into incident response under CC7.4 and CC7.5 — and into the DC section 200 disclosure requirement if it caused a significant failure to meet service commitments.
The cloud provider’s own infrastructure
You test what you operate. As at August 2026, AWS permits customer testing of a published list of services without prior approval under its Customer Support Policy for Penetration Testing, and requires a simulated-events submission for stress- or DDoS-style testing; Google Cloud requires no notification but holds testing to its Acceptable Use Policy and terms; Microsoft publishes Penetration Testing Rules of Engagement covering customer-operated Azure resources. All three prohibit testing of their own infrastructure, and all three change their terms — read the current policy before booking. The consequence for the audit: the carve-out language in Section 3 has to match the provider’s terms, or your target list will look as though it under-covers the boundary.
The CPA firm offered to run the test as well
A discrete penetration test the firm did not remediate can be permissible under the AICPA Code’s nonattest-services provisions, where the general requirements are met and management makes every decision. The practical problem sits downstream: the resulting report becomes evidence for a control the same firm must then test. Most enterprise buyers, and many firms, avoid the pairing for that reason.
The last of those is worth reading in full before you sign anything, because the AICPA Code draws the line by activity rather than by label: assessing the design or operating effectiveness of your security sits among the permitted nonattest services, while accepting responsibility for maintaining the security of your systems is a management responsibility no safeguard cures. Our guide to SOC 2 auditor independence works through the relevant ET 1.295 sections case by case.
Objection handling
What a buyer’s security team pushes back on
These arrive in vendor-risk questionnaires and security-review calls. The answers that work are specific and dated, so each one below carries a model response you can adapt and paste. Swap the dates for yours, and delete anything you cannot evidence.
“Your penetration test is more than a year old.”
Answer with the stated cadence and the next booked date. If you commit to annual testing and the last test is thirteen months back, the buyer is right, and the only good answer is a booking reference.
Model response
Our stated cadence is annual, plus testing after significant architectural change. The last test completed on 8 February 2027 and the next is booked for the week of 2 February 2028. I can share the summary letter under NDA today.
“Send us the penetration test report.”
Most organisations share a summary under NDA and reserve the full technical report for the auditor. That holds up where the summary carries scope, test dates, severity counts by rating, remediation status and retest confirmation, and where the finding count matches the report. Refusing outright reads worse than offering a supervised read.
Model response
We share a summary letter under NDA covering scope, test dates, severity counts and remediation status. If your team needs more, we can walk you through the full report on a screen-share under the same NDA.
“Was the tester certified?”
The criteria are silent on tester credentials, so this is a statement of fact rather than a defence. Name the credentials held and the methodology followed, and point at the page of the report where both appear.
Model response
The engagement was led by two testers holding OSCP and CREST registration, following the OWASP Web Security Testing Guide for the application scope and NIST SP 800-115 for the technical process. Both are named in section 1 of the report.
“The test only covered one application.”
The comparison is against your system boundary rather than your product catalogue. If the boundary in Section 3 is one platform, single-application scope is correct. If it is broader, the answer is the rotation plan and its dates.
Model response
Our SOC 2 boundary is the platform named in Section 3, and the test scope maps to it line by line. The other products sit outside that boundary and outside this report.
“You only tested the perimeter. What about the internal network?”
Answer against the boundary first, then the risk rationale. Where the described system is a managed cloud estate with no corporate-operated network inside the boundary, an internal network test would examine something the report does not cover.
Model response
The boundary is the production application, its API and the cloud accounts hosting it — there is no corporate network in scope. Our CC3.2 risk assessment drove that scope, and lateral movement was covered by an assumed-breach segment of the same engagement.
“Do you retest after every release?”
Separate the release-gate scanning control from the periodic independent test. They are two controls with two evidence sets, and claiming both while describing one is the failure mode here.
Model response
Every release is gated by automated static and dependency scanning, with the build failing on High findings. Independent penetration testing runs annually and after significant architectural change. Both are described separately in Section 3 and tested separately in Section 4.
“You had two high findings. Why should we accept that?”
Findings are the output of the control working, not evidence of failure. What matters is whether they closed inside the window you committed to, and whether an independent retest confirmed it.
Model response
Both were remediated within our stated 30-day window and verified closed by the testing firm on 19 March 2027. The retest letter is in the evidence pack we can share under NDA.
“Your auditor also ran the pen test — isn’t that a conflict?”
A fair question, and the AICPA Code addresses it directly. A discrete test the firm did not remediate can be permissible where the general nonattest-service requirements are met; a standing arrangement in which the firm maintains your security is a management responsibility and impairs independence outright.
Model response
The penetration test was performed by an unrelated testing firm engaged under its own statement of work. Our CPA firm performed the examination only, with no role in scoping remediation or fixing findings.
Where TCSA sits: we run readiness, stress-test the control language, build the evidence set and coordinate the examination with the CPA firm that issues the opinion. We do not certify, attest or sign a SOC 2 report — no consultancy can.
Frequently Asked Questions
Does SOC 2 require a penetration test?
The standard itself is silent. No criterion in the 2017 Trust Services Criteria names a penetration test as a mandatory activity; the criteria describe outcomes — vulnerabilities identified and remediated, changes managed, internal control evaluated — and leave the method to management. The AICPA mentions penetration testing once, in an illustrative point of focus under CC4.1 that lists it among the ongoing and separate evaluations management may use, beside internal audit assessments, compliance assessments and vulnerability scans. The requirement appears when your own system description commits to one: write it into Section 3 and the service auditor must test that it happened, on the cadence and with the remediation window you stated. In practice most control sets describe independent testing.
What kind of penetration test does SOC 2 need?
The criteria specify no test type, so the answer comes from your system boundary. For a typical SaaS platform that means an authenticated and unauthenticated test of the production web application, an API test against the OWASP API Security Top 10, and a configuration review of the cloud accounts hosting it. Internal network testing matters where corporate-managed infrastructure sits inside the boundary; a mobile binary review matters where a mobile client is described. Social engineering and red-team exercises are usually out of scope, and the description should say so. Judge the report on six markers: named testers with credentials, tester-days, test dates stated separately from the report date, a named methodology, reproduction steps per finding, and an explicit out-of-scope statement.
Which Trust Services Criteria does a penetration test map to?
There is no official mapping — the criteria do not assign activities to themselves. Conventionally, testing supports CC4.1 (evaluations of internal control), CC7.1 (identifying vulnerabilities and the changes that introduce them) and CC8.1 where the control commits to testing after significant change. External findings bear on CC6.6 and CC6.8; an exploited one moves into incident response at CC7.4 and CC7.5. The upstream justification for scope, frequency and test type belongs in your CC3.2 risk assessment. Only CC4.1 names penetration testing, and it does so in an illustrative point of focus rather than in the criterion itself.
Is vulnerability scanning enough, or do we need both?
Both are optional as far as the criteria go, and both become mandatory the moment you describe them. Scanning produces a population of cycles across the period, which is what lets an auditor test operating effectiveness with any depth — quarterly scanning gives four occurrences, monthly gives twelve. A penetration test produces one or two high-value events and supplies independence plus the findings no signature detects: broken authorisation logic, business-logic abuse, chained privilege escalation. If you describe only one, check that the description does not imply the other, because an implied control is still a control the auditor will look for.
Can we use a penetration test performed before the observation period?
Sometimes. It depends on the frequency you stated and on continued relevance. If your description commits to annual testing, the period is short, the pre-period test is the most recent occurrence that cadence requires and nothing material has changed, an auditor may accept it. A twelve-month period with no test inside it is much harder to sustain, and a pre-period test can never answer a commitment to test after a significant change during the period. The planning rule follows from the arithmetic: report delivery, your remediation window and the retest all have to land inside the period, so with a 30-day window and a two-to-three week reporting turnaround, testing must start eight to ten weeks before period end.
Do penetration test findings have to be disclosed in the SOC 2 report?
Individual findings are almost never reproduced, and readers do not receive your finding list. What surfaces is the consequence: findings left unremediated beyond your stated window become a deficiency in the remediation control and appear as an exception in Section 4, with management free to respond alongside it in Section 4 or in Section 5, in either case as unaudited context. Separately, DC section 200 requires disclosure of identified system incidents caused by controls that were not suitably designed or operating effectively, or that otherwise caused a significant failure to meet service commitments during the period.
What evidence does the auditor want for the pen test control?
A dated engagement letter naming the testing firm and window; the target list reconciled line by line to the boundary in Section 3; the report with test dates, methodology, named testers, findings and severities; a findings register reconciled to that report; remediation artefacts for sampled findings — ticket, change record and technical evidence of the fix; retest confirmation; and dated risk acceptance for anything left open. Sample sizes follow the frequency described: an annual test is a population of one examined in full, quarterly scanning commonly two to four of four, monthly two to five of twelve. Before anything is sampled, the auditor reconciles your register row count to the report finding count and to a ticketing export.
Can our SOC 2 auditor also run the penetration test?
Often permissible in principle, and frequently avoided in practice. The AICPA Code treats a discrete penetration test the firm did not remediate as a nonattest service that can be acceptable where the general requirements are met and management makes every decision — while a standing arrangement in which the firm maintains the security of your systems is a management responsibility that impairs independence outright. The practical objection sits downstream: the resulting report becomes evidence for a control the same firm must then test, which is an awkward thing to explain to a buyer reading the report. Most enterprise security teams would rather see an unrelated testing firm, and our auditor independence guide sets out the relevant code sections in detail.
What if we still have open high findings when the period ends?
Open is workable; late is the problem. If a high finding is still open but inside the remediation window your policy states, the control is operating and the auditor records it as such. If it is past that window, expect an exception unless there is a formal, dated risk acceptance at the authority level your policy names, with rationale, compensating controls and a review date. Severity re-rating is where this gets contested: CVSS v3.1 and v4.0 base scores are the market convention, environmental re-scoring against your own architecture is legitimate, and the auditor asks whether the methodology was documented and dated before the finding arrived, applied consistently across findings, and approved by someone other than the finding owner.
Related reading: the SOC 2 controls list, auditor independence, opinions and exceptions, how to read a SOC 2 report, penetration testing services, and the SOC 2 hub.
Written By Expert Auditors
Keep Exploring
Related Reading
SOC 2 Controls List
No official list exists — illustrative controls by criteria series (CC1–CC9).
Read moreA Security Incident During Your Observation Period
An incident does not automatically qualify the opinion — what does, and what the auditor asks for.
Read moreVAPT / Penetration Testing
Manual-first web, API, network and mobile testing with retest included.
Read moreSOC 2 Compliance Checklist
Six phases from scoping to annual maintenance, with concrete checkpoints.
Read moreSOC 2 Knowledge Hub
Type 1 vs Type 2, criteria, timelines and audit prep — all guides.
Read moreSOC 2 Scope & System Boundary
What may legitimately be excluded, and the DC 200 test that stops a boundary flattering the vendor.
Read moreGet in touch
Book a free consultation or send us your requirements. We respond within 24 hours.
Quick Call
Pick a time slot
Send Requirements
Get a custom quote in 24 hours