Customer-required testing
Use the original customer request to clarify the expected activity and evidence.
Read nextSOC 2 and assurance
Start with the SOC 2 request you received.
The need may come from an auditor, customer, adviser, control, risk process, or internal policy. We’ll keep those sources distinct and define testing around the actual expectation.
Does SOC 2 require a penetration test?
No—not in every case. SOC 2 does not create one universal penetration-testing requirement. A specific need may come from your control design, risk assessment, auditor or adviser guidance, customer commitments, or internal policy.
Confirm who raised the requirement, the exact wording, the systems involved, the evidence period, and what they expect to receive. Penetration testing does not guarantee a SOC 2 result, certification, audit outcome, or customer acceptance.
Primary references: AICPA Trust Services Criteria
Confirm the request
Find out who needs the test and what they want to receive.
- Who asked
An auditor, adviser, customer, control owner, risk team, internal policy owner, or another party.
- What they called it
A penetration test, vulnerability assessment, scan, independent test, periodic assessment, or general evidence request.
- Which systems
The products, applications, infrastructure, environments, locations, or controls involved.
- When it is needed
The audit period, evidence date, customer deadline, remediation window, or internal milestone.
- What they want to receive
A full report, executive summary, scope statement, completion evidence, finding status, or answers to follow-up questions.
What Trespass reviews
The audit request and the technical scope are not the same thing.
We use the guidance to understand why testing is needed, then work with your team to list the systems, environments, roles, access, exclusions, limitations, authorization, report, and retesting.
What to send
A non-sensitive summary is enough for initial contact.
- The control, questionnaire item, auditor note, customer request, or adviser guidance
- The Trust Services Categories or business systems involved, if known
- The examination or evidence period, if relevant
- Who will receive the evidence and what they asked for
- Known applications, APIs, networks, environments, or third parties
- Internal ownership and any testing restrictions
Scope
List the systems and access needed for the test.
Systems
Applications, APIs, infrastructure, identity paths, environments, integrations, and network boundaries involved in the request.
User roles
Standard users, administrators, tenant roles, support access, and other privilege levels.
Restrictions
Production conditions, change windows, third-party approvals, sensitive data, monitoring, and prohibited techniques.
Report
The scope statement, testing methods, limitations, findings, remediation status, and what the recipient may receive.
Reporting
The report should say exactly what was tested.
It should state the authorized scope, methods, work performed, findings, evidence, limitations, and retest status.
Important: Trespass can perform and document an authorized penetration test. It does not set the scope of a SOC 2 examination, act as the auditor, issue a SOC 2 report, or decide whether another party will accept the evidence.
Next step
Send the assurance guidance you have.
Tell us who raised the expectation, what they said, which systems may be involved, and when the evidence may be needed.