Overview
Penetration Testing is a controlled security assessment where authorized testers simulate real-world attacks to identify exploitable weaknesses in systems and applications. This process ensures the organization meets SOC 2 CC7.1 by proactively detecting and remediating vulnerabilities on an annual basis.
Step-by-Step Process
Define scope and objectives
The Security Lead defines the systems, applications, environments, and testing depth (e.g., network, web app, API) to be included in the penetration test. Scope must align with in-scope SOC 2 systems and clearly document exclusions. The output is an approved penetration testing scope document.
Role: Security Lead
Select testing approach and provider
The Security Lead selects the testing method (bug bounty platform, managed pentest, or internal team) based on risk, budget, and coverage needs. Contracts, rules of engagement, and tester authorization are finalized. The output is a signed statement of work or internal authorization memo.
Role: Security Lead
Prepare systems and access
IT and Engineering teams prepare test environments, ensure asset inventories are accurate, and provide required credentials or IP allowlists if applicable. Monitoring and incident response teams are notified of testing windows. The output is confirmation of system readiness and access provisioning.
Role: IT Manager
Execute penetration testing
Authorized testers perform penetration testing within the approved scope and timeframe using manual and automated techniques. All testing activities are logged by the provider or internal team. The output is raw testing results and identified vulnerabilities.
Role: External Tester or Security Analyst
Review and validate findings
The Security Lead reviews reported findings for accuracy, severity, and business impact, rejecting false positives where justified. Findings are categorized using a defined risk rating methodology. The output is an approved and validated penetration test report.
Role: Security Lead
Remediate identified vulnerabilities
Engineering teams remediate accepted findings according to severity-based SLAs. Fixes are tracked in a ticketing system with evidence of completion. The output is closed remediation tickets with references to fixes or configuration changes.
Role: Engineering Manager
Perform retesting and closure
High and critical findings are retested to confirm remediation effectiveness. Retest results are documented and attached to the original findings. The output is a finalized penetration test report with remediation status.
Role: Security Analyst
Archive evidence and report to stakeholders
The Security Lead stores all reports, approvals, and remediation evidence in the compliance repository and provides a summary to executive stakeholders. Evidence is retained according to the SOC 2 retention policy. The output is an audit-ready evidence package.
Role: Security Lead
What You Need Before Starting
- Approved asset inventory identifying SOC 2 in-scope systems
- Annual security testing plan
- Contract or authorization for penetration testing provider
- Access credentials or IP allowlisting details (if applicable)
Evidence Your Auditor Expects
- Approved penetration test scope document dated within the audit period
- Signed statement of work or internal authorization memo with execution dates
- Final penetration test report showing findings and severity ratings with report date
- Remediation tickets with timestamps showing closure before or after test date
- Retest confirmation report or screenshots dated after remediation
How This Looks In Your Tools
HackerOne
Log in to the HackerOne dashboard and navigate to Programs > Your Programs, then select the relevant private or managed program. Under Program Settings > Scope, review and update in-scope assets and testing rules, then publish changes.
During the testing period, monitor submissions via the Inbox tab and review reported vulnerabilities. Use the Severity and State fields to triage findings, then export the final report by navigating to Reports > Program Reports and downloading the report with the testing date range.
Cobalt
Access the Cobalt platform and go to Pentests > Active Pentests, then select or create a new pentest. Define scope under the Scope tab, upload authorization documents, and schedule the testing window.
After completion, navigate to Findings > All Findings to review validated issues. Download the final penetration test report by selecting Reports > Final Report, ensuring the report includes dates, scope, and remediation guidance.
Internal team
The Security Lead creates a penetration testing plan document and stores it in the internal documentation repository (e.g., GRC or document management tool). Testing activities are tracked in the vulnerability management or ticketing system.
Testers record findings directly in the ticketing system with evidence attachments. A final report is generated using the internal report template and saved with a filename including the test year and system name.
Common Audit Findings
- Penetration testing not performed annually
- This occurs when testing is delayed or not formally scheduled. Prevent this by including penetration testing in the annual security calendar and assigning an accountable owner.
- Scope does not match SOC 2 in-scope systems
- Auditors see this when asset inventories are outdated. Prevent it by validating scope against the SOC 2 system description before testing begins.
- Lack of remediation evidence
- Findings are remediated but not documented. Prevent this by requiring remediation tickets with timestamps and evidence attachments.
- No retesting of critical findings
- Organizations close findings without confirming fixes. Prevent this by mandating retesting for high and critical vulnerabilities.