A clear system boundary
List the applications, APIs, identities, environments, and exclusions. Explain how the tested scope relates to the system described in your audit.
Manual testing. Human-verified findings.
SOC 2 penetration testing
SOC 2 penetration testing assesses the applications and systems in your audit boundary and produces evidence for your control evaluation. Balhence confirms findings by hand, explains their business impact, and documents agreed re-tests. Your auditor determines how that evidence supports the Trust Services Criteria.
Does SOC 2 require a penetration test?
SOC 2 uses risk-based criteria, rather than a universal list of prescribed tests. Penetration testing can support your monitoring and vulnerability-management controls, but the appropriate scope, cadence, and evidence depend on your systems, risks, and control commitments. Confirm these with your auditor before booking.
A scanner can help identify issues. Manual testing adds review of business logic, permissions, and the impact of a confirmed weakness. Read how to plan pentest evidence for SOC 2.
What auditors look for in a pentest report
Evidence a reviewer can follow
Document test dates, access levels, manual coverage, confirmed impact, and the limitations of the assessment.
A remediation record
Keep findings, owners, decisions, and re-test outcomes together. An untested fix must remain marked as unverified.
What we test for SOC 2
The agreed boundary determines the work. Typical starting points include:
How pentest evidence can support SOC 2 criteria
| Control area | Possible supporting evidence |
|---|---|
| CC4.1 - control evaluation | An independent technical assessment can inform evaluations of whether controls are functioning. |
| CC7.1 - vulnerability and change detection | Confirmed weaknesses and scope details can inform vulnerability-identification and monitoring activities. |
| Remediation and follow-up | Document the control owner, corrective action, and re-test result against the controls in your own program. |
This is an illustrative mapping, not an attestation. The AICPA Trust Services Criteria define the criteria; your controls and audit determine how the evidence is used.
Prepare your SOC 2 pentest brief
Bring the system description, the controls the assessment should support, and the date your reviewer needs the evidence. Identify the applications, APIs, user roles, tenants, environments, and supporting systems that belong in the boundary.
Agree who can authorize testing, who owns remediation, and how much time engineering needs before a re-test. Share your reviewer's reporting requirements during scoping so the proposal records them explicitly.
A useful brief separates the test window, report delivery, remediation period, and re-test deadline. These milestones help your team compare proposals on the same basis. When your milestones are clear, request a scoped SOC 2 proposal.
A SOC 2 pentest timeline that fits your audit window
Reserve time for access setup, fieldwork, the report, engineering fixes, and the agreed re-test. Share the review date and observation period during scoping. We confirm availability after reviewing the boundary and access; an enquiry does not reserve a start date.
SOC 2 pentest reports and audit evidence
- An executive summary linking tested systems, roles, environments, fieldwork dates, and exclusions to the agreed SOC 2 audit boundary.
- Human-verified findings with impact, prerequisites, evidence, severity reasoning, and practical fixes.
- A report walkthrough and an agreed route for urgent findings.
- A bounded re-test of agreed fixes when included in the agreement, with each finding recorded as fixed, partially fixed, not fixed, or not re-tested.
- The observation period supplied by your team and agreed evidence requirements, so your auditor can assess the report's relevance.
The re-test record describes the checks performed and their outcome. It does not certify that the system is free of vulnerabilities.
SOC 2 penetration testing FAQ
Does the pentest guarantee we pass SOC 2?
No. A pentest supplies technical evidence for your audit. Your auditor evaluates the overall controls and determines the audit outcome.
SOC 2 Type 1 or Type 2: does timing matter?
Yes. Type 1 addresses controls at a specified date; Type 2 also examines their operation over a period. Agree when the assessment and re-test should occur with your auditor.
Can scoping start before the audit boundary is final?
Yes. We can discuss the proposed boundary and dependencies, then confirm the written scope and authorization before testing.
How often should we run a SOC 2 pentest?
Set the cadence from your risk assessment, documented controls, customer commitments, and auditor input. Review it after significant changes. SOC 2 does not impose one universal annual pentest schedule.
Plan your SOC 2 penetration testing scope
Tell us about the systems, roles, integrations, and deadline. We will confirm scope, availability, written authorization, and deliverables before testing.