By requirement
SOC 2 penetration testing, scoped to your audit
SOC 2 does not name a mandatory penetration test, yet most auditors and enterprise buyers expect one. We scope it to your system description and audit period, then retest so the evidence holds up.
What it asks for
Does SOC 2 require a penetration test?
Not in so many words. SOC 2 reports are issued by CPA firms against the AICPA Trust Services Criteria, and no criterion states that a service organisation must commission a penetration test. Penetration testing appears in a point of focus under CC4.1, which lists it among the types of ongoing and separate evaluations management may use to check that controls are present and functioning. Points of focus illustrate how a criterion can be met; they are not individual requirements that must each be satisfied.
In practice the test is expected anyway. CC7.1 asks the entity to detect configuration changes that introduce vulnerabilities and newly discovered weaknesses, and CC4.2 asks for deficiencies to be evaluated and passed to those who fix them in good time. An independent penetration test, with tracked remediation and a retest, is one of the clearest ways to show those controls working. Many enterprise customers also ask for a recent test in security reviews. Your auditor decides what evidence is sufficient.
CC4.1 Ongoing and separate evaluations
Management selects and performs evaluations to confirm controls are present and functioning. A point of focus names penetration testing among the evaluation types, so an independent test is a natural way to evidence this criterion.
CC7.1 Detection of new vulnerabilities
Detection and monitoring should catch configuration changes that introduce vulnerabilities and newly discovered weaknesses. A point of focus covers periodic vulnerability scanning; a penetration test complements it by showing which issues are actually exploitable.
CC4.2 Evaluating and communicating deficiencies
Deficiencies must be evaluated and reported in good time to those responsible for corrective action. Test findings feed this loop, and a remediation plan followed by a retest shows the corrective action was completed.
CC3.2 Risk identification and analysis
Risks to objectives are identified and analysed, with points of focus covering threats and the vulnerability of system components. Test results give the risk assessment current, concrete input rather than assumptions about exposure.
CC7.2 Monitoring for anomalies
System components are monitored for anomalies that indicate malicious acts. Running the test while your monitoring is live, and comparing what was detected with what was done, shows whether detection works in practice.
What to test
Scoping the test to your SOC 2 system
Start from the system description
The boundary in your SOC 2 system description defines what the auditor examines. We align targets to it: the production application, its APIs, the supporting cloud accounts and the identity services that control access to them.
Application and API testing
For most SaaS providers the customer-facing application is the main exposure. We test authentication, authorisation, tenant isolation, business logic and API endpoints with authenticated roles, not just an unauthenticated scan.
Cloud and infrastructure
Externally exposed hosts and services, cloud configuration and IAM, and where relevant internal networks or Active Directory. Cloud review concentrates on paths an attacker could use, such as over-permissive roles and exposed storage.
Timing within the audit period
For a Type 2 report, a test performed and remediated inside the examination period lets the auditor see the control operating. For a Type 1, testing before the report date supports control design. Agree timing with your auditor early.
What you receive
What we hand over for the audit
Full technical report
Methodology, scope and dates, tester independence, and each finding with risk rating, evidence of exploitation and remediation guidance, written so the auditor can trace what was tested and when.
Criteria mapping
An appendix mapping findings and test activities to relevant Trust Services Criteria, such as CC4.1, CC7.1 and CC4.2, to shorten the auditor's walkthrough. The mapping is guidance; your auditor makes the determination.
Remediation retest and letter
Once findings are fixed we retest them and issue a dated letter recording which issues were verified as resolved. This is the evidence that closes the corrective-action loop under CC4.2.
Customer-shareable summary
A shorter executive summary or attestation letter for enterprise security reviews, confirming an independent test took place and outlining scope and outcome without disclosing exploitable detail.
Common pitfalls
Where SOC 2 testing goes wrong
Mistakes that cost time at audit, and how to avoid them.
A scan presented as a pentest
Automated scanner output labelled as a penetration test rarely satisfies an experienced auditor or a customer's security team. Manual testing of authorisation and business logic is where SaaS risk usually sits.
Scope that misses the system
Testing a marketing site while the production application and cloud control plane are left out produces evidence that does not match the system description, and auditors and customers notice.
A test outside the period
A test dated before the Type 2 examination period starts, or remediation finished after it ends, weakens the evidence. Plan the test date around your audit window.
Findings left open
Auditors may ask what happened to high-risk findings. Unresolved issues with no documented risk decision can raise questions under CC4.2, so retest before fieldwork where you can.
Who decides what counts
PXL Security is an independent offensive-security firm, not an auditor, assessor, certification body or regulator. We deliver the testing and the evidence; your auditor, assessor or competent authority decides what they accept. This page is general guidance, not legal advice.
FAQ
Questions we're often asked
Is a penetration test mandatory for SOC 2?
No criterion in the Trust Services Criteria explicitly requires one. Penetration testing is named in a CC4.1 point of focus as one type of evaluation, and points of focus are illustrative rather than mandatory. In practice many auditors and most enterprise customers expect an independent test, so plan for one unless your auditor agrees otherwise.
Does PXL Security issue SOC 2 reports?
No. PXL Security is a penetration testing firm, not a CPA firm or auditor, and we do not issue SOC 2 reports, opinions or certificates. SOC 2 examinations are performed by licensed CPA firms. We provide independent testing evidence that your auditor can consider.
When should the test happen for a Type 2 report?
Ideally inside the examination period, early enough to remediate and retest before the period ends. That lets the auditor see both the evaluation and the corrective action taking place. Confirm the timing with your auditor during planning.
Do we need a test for a Type 1 report?
A Type 1 report looks at control design at a point in time, so the auditor focuses on whether your evaluation and vulnerability management controls are suitably designed. A recent test before the report date is useful evidence and customers often ask for one anyway.
How often should we test?
SOC 2 sets no fixed frequency. Annual testing aligned to the audit cycle is common, with additional testing after significant changes to the application or infrastructure. Your risk assessment and customer commitments should set the cadence.
Is this audit advice?
No. This page is general guidance on how penetration testing relates to SOC 2, based on the published criteria and common audit practice. Your auditor decides what evidence is sufficient, so agree scope and timing with them.
Services that deliver this
Scope your SOC 2 test.
Send a short description of your environment and goals. A senior tester, not a salesperson, will reply with questions, a proposed approach and a quote.