ESSENTIAL GUIDANCE · BUYER GUIDE · 3 min read

Part of Validate insights →

SOC 2 and penetration testing evidence

Prepare scoped technical-testing evidence for a SOC 2 assurance process without confusing the assessment with the auditor’s report.

Prepare scoped technical-testing evidence for a SOC 2 assurance process without confusing the assessment with the auditor’s report.

Need an acronym translated?Open the cyber glossary →

Separate the audit from the technical assessment

SOC 2 reporting concerns controls at a service organisation against the relevant Trust Services Criteria, within the auditor's agreed engagement. A penetration test can contribute technical evidence about selected systems and risks. It is not a SOC 2 report or certification. Establish what the independent auditor needs to evaluate before buying a test described only as a compliance package.

Define the service and system boundary

Map the service covered by the assurance work, the customer information involved, important supporting components and supplier dependencies. Compare that boundary with the proposed test scope. A test of one application may provide useful evidence without covering every system or control inside the assurance engagement. Make those relationships visible so an isolated assessment is not overinterpreted.

Agree the evidence expectations early

Discuss the relevant control objectives, assessment period and evidence format with the assurance team and auditor. Confirm whether the useful output is a scope statement, technical report, remediation record or follow-up confirmation. Do not assume every SOC 2 engagement creates an identical standalone penetration-testing requirement. The engagement's controls and audit context determine how technical work supports the overall conclusion.

Choose meaningful technical questions

Focus on the service's important trust boundaries, access roles, exposed interfaces and sensitive information paths. A useful question might concern tenant isolation or privileged administration rather than an arbitrary number of scanned addresses. Include the access and environment assumptions necessary to answer it. Active testing requires explicit written authorisation and an agreed scope and safety framework.

Preserve the response to findings

Retain the original finding, its owner, the corrective action and the evidence used to assess the change. Distinguish an implemented fix from a risk decision and a checked correction from an untested status update. If a follow-up is performed, record its scope and date. The assurance process benefits from a coherent evidence trail rather than a final PDF with no account of what happened afterwards.

Prepare a controlled customer-facing explanation

Use a suitable summary to explain the assessed service, period, limitations and relevant remediation state. Protect detailed technical and third-party information when sharing evidence. Refer questions about the SOC 2 opinion or auditor's conclusion to the proper reporting process. Present technical assurance and independent audit as connected activities with distinct responsibilities, rather than interchangeable badges.

Ready for the Pentesys point of view?

This guide covers the essentials. Continue into our technical analysis for a firmer position, practical implications and recommended action.

Read “Modern penetration testing should create decisions, not just findings” →
TALK TO PENTESYS

Apply this guidance to your environment.

Tell us what you need to understand, test or prove. We'll help you choose a proportionate next step—without forcing the conversation into a predefined package.

Request a proposal →Explore Validate

Keep reading

Assurance that joins up

Recognised expertise, built around your environment.

Pentesys combines independent assurance, qualified testers and practical integration with the systems your teams already use.