1. AICPA SOC 2 Trust Services Criteria Mapping
In SOC 2 examinations, independent CPAs evaluate security controls against the AICPA's Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, and Privacy). Penetration testing directly validates the operational effectiveness of multiple Common Criteria (CC) series controls:
Vulnerability Identification & Boundary Defense
The entity uses detection and monitoring procedures to identify changes to configurations that result in the introduction of new vulnerabilities, and conducts vulnerability assessments to identify potential vulnerabilities in boundaries and application components. Penetration testing validates that boundary firewalls, API gateways, and authorization layers cannot be bypassed.
Real-Time Threat Monitoring & Anomaly Detection
The entity monitors system components and the operation of controls for anomalies that are indicative of malicious acts. Live penetration testing exercises your Security Operations Center (SOC), SIEM alerting rules, and Web Application Firewalls (WAF), generating essential audit evidence that adversarial activity triggers observable alerts.
Security Incident Evaluation & Remediation Validation
The entity evaluates security incidents and executes containment and remediation procedures. When a penetration test discovers vulnerabilities, auditors inspect the end-to-end ticketing, triage, patch deployment, and formal retest evidence proving the vulnerability was closed before the end of the audit window.
Separate Evaluations by Independent Parties
The 2022 revised AICPA points of focus explicitly list penetration testing among the separate evaluations management uses to determine whether controls are present and functioning. Auditors require the testing entity to be independent of the development and administration teams.
2. ISO/IEC 27001:2022 Annex A Controls
The 2022 revision of ISO/IEC 27001 consolidated and strengthened technical security controls. Penetration testing forms the empirical backbone for two essential Annex A requirements:
Management of Technical Vulnerabilities
Mandate: Information about technical vulnerabilities of information systems in use shall be obtained, the organization's exposure to such vulnerabilities evaluated, and appropriate measures taken.
Audit Implementation: Certification bodies (e.g., BSI, DNV, SGS, Bureau Veritas) look for regular penetration testing of all Internet-exposed assets, defined remediation SLAs based on CVSS severity, and documented retesting.
Security Testing in Development and Acceptance
Mandate: Security testing processes shall be defined and implemented in the development life cycle.
Audit Implementation: Verifies that security testing is integrated into release pipelines, testing new code, APIs, and authorization structures before or immediately upon deployment into production environments.
3. Type I vs Type II Audit Windows & Timing
Understanding the distinction between SOC 2 Type I and Type II audits is critical for scheduling penetration tests to ensure reports are accepted without auditor exceptions:
| Audit Type | Evaluation Mechanism | Penetration Test Timing Requirement | Required Artifacts |
|---|---|---|---|
| SOC 2 Type I | Design suitability of controls at a specific point in time (single calendar date). | Conducted within 30 to 60 days prior to the target report date. | Full technical assessment report and remediation plan for any critical/high findings. |
| SOC 2 Type II | Operating effectiveness of controls across an observation period (typically 6 or 12 months). | Must be executed strictly within the observation window dates. Any test falling outside the window will trigger an auditor exception. | Assessment report, remediation pull requests/tickets, and verified retest reports closing all critical/high issues. |
| ISO 27001 Surveillance | Annual surveillance audits in Years 1 & 2 of 3-year certification cycle. | Conducted annually or continuously prior to each surveillance visit. | ISMS Statement of Applicability (SoA), risk treatment log, recent test reports, and closure evidence. |
4. Technical Scoping & High-Risk Vectors
Auditors require that the scope of your penetration test matches the "System Description" (Section III) of your SOC 2 report and the boundaries of your ISO 27001 ISMS. Leaving core services out of scope will invalidate your testing evidence.
Authenticated Business Logic & Multi-Tenancy
Testing must authenticate as standard, privileged, and cross-tenant users to verify Broken Object Level Authorization (BOLA), horizontal tenant hopping, and unauthorized data leakage across shared database partitions.
Public & Partner APIs
Comprehensive testing of REST, GraphQL, and webhook interfaces against OWASP API Top 10 vulnerabilities, including rate limit circumvention, token hijacking, and object property tampering.
AI & Agentic System Workflows
If your system leverages LLMs, RAG, or autonomous agents, auditors increasingly evaluate prompt injection boundaries, data retrieval isolation, and tool-call authorization under CC6.1 and CC7.1.
Cloud Edge & Ingress Configurations
Validation of TLS configuration, CORS policies, CDN caching rules, DNS hygiene, and container/orchestrator ingress points exposing management interfaces.
5. Complete Auditor Evidence Checklist
When your compliance auditors review penetration testing documentation, they look for specific evidentiary components. Ensure your audit packet contains all six elements:
Formal Scope and Rules of Engagement (RoE)
Written confirmation of target domains, IPs, APIs, excluded components, and dates agreed upon prior to testing.
Comprehensive Technical Pentest Report
Detailed findings list with CVSS 3.1/4.0 severity scoring, deterministic reproduction steps, request/response traces, and root cause analysis.
Engineering Remediation Evidence
Jira/GitHub issue tickets, commit hashes, or pull requests confirming that engineering deployed patches within policy SLAs (e.g. 7 days for criticals).
Delta Retest Report
Verification re-execution against the patched endpoints demonstrating that previously identified vulnerabilities have been successfully closed.
Executive Summary & Letter of Attestation
A clean, signed Letter of Attestation suitable for sharing with enterprise customers, third-party risk reviewers, and board directors without disclosing internal code or vulnerability payloads.
Formal Risk Acceptance Sign-Offs (If Applicable)
Any low-severity finding that was accepted rather than remediated must include a documented CISO or executive sign-off justifying compensatory controls.
6. Continuous Automated Pentesting vs Annual Retainers
Traditional annual consulting retainers cost $25,000–$75,000 per assessment and provide a single snapshot that becomes outdated after the next sprint release. Infiltra replaces static point-in-time pentesting with continuous autonomous validation:
- ×Takes 3–6 weeks to schedule, execute, and deliver a PDF.
- ×Leaves 364 days of zero security validation across active CI/CD pipelines.
- ×Retesting is either billed as an expensive change order or skipped entirely.
- ×High friction with auditor observation window deadlines.
- ✓Launches on demand or continuously upon release deployment.
- ✓Empirical exploit validation eliminates triage noise and false positives.
- ✓Automated delta retests immediately confirm remediation in production.
- ✓Instant auditor-ready compliance reports and signed Letters of Attestation.
7. Frequently Asked Questions
Direct answers on AICPA Trust Services Criteria, ISO 27001:2022 surveillance, and auditor expectations.
AICPA SOC 2
Do SOC 2 Type II Auditors Mandate an External Penetration Test?
Do SOC 2 Type II Auditors Mandate an External Penetration Test?
While the AICPA Trust Services Criteria allow organizations discretion in control design, penetration testing is explicitly highlighted in the CC4.1 points of focus as an essential separate evaluation. Furthermore, CPA auditors standardly reject SOC 2 Type II reports that lack independent technical penetration testing conducted during the review window.
ISO 27001:2022
What Controls in ISO/IEC 27001:2022 Mandate Penetration Testing?
What Controls in ISO/IEC 27001:2022 Mandate Penetration Testing?
In ISO/IEC 27001:2022 Annex A, Control 8.8 (Management of technical vulnerabilities) requires organizations to obtain timely information about technical vulnerabilities, evaluate exposure, and take appropriate measures. Control 8.29 (Security testing in development and acceptance) requires verification of security functionality in production systems. Penetration testing is the primary audit evidence accepted for both controls.
Autonomous Testing
Can Autonomous or Automated Penetration Testing Be Used for SOC 2 and ISO 27001?
Can Autonomous or Automated Penetration Testing Be Used for SOC 2 and ISO 27001?
Yes, provided the platform performs deterministic, exploit-validated testing rather than superficial signature scanning, covers authenticated business logic and role authorization, and provides full reproduction evidence and retest logs. Autonomous platforms like Infiltra deliver continuous test evidence that satisfies both point-in-time and continuous observation audits.
Audit Frequency
How Often Should Penetration Testing Be Performed for SOC 2 Type II?
How Often Should Penetration Testing Be Performed for SOC 2 Type II?
At minimum, once per observation period (annually for 12-month periods, or every 6 months for semi-annual cycles), and immediately following significant architectural releases. Continuous automated penetration testing provides superior assurance by eliminating the blind spots between annual audits.
8. Regulatory & Framework References
Official guidelines for auditing security, availability, and confidentiality controls (CC7.1–CC7.3, CC4.1).
aicpa-cima.com →Information security, cybersecurity, and privacy protection — Information security management systems — Requirements.
iso.org →Controls 8.8 (Management of technical vulnerabilities) and 8.29 (Security testing in development).
iso.org/standard/75652 →