PTaaS for SOC 2 and PCI-DSS: What Auditors Actually Want to See
A pen test report that satisfies your security team is not the same as a pen test report that satisfies an auditor. Auditors and Qualified Security Assessors (QSAs) read the report through a specific lens: did this testing demonstrate that the controls in scope are present, effective, and continuously evaluated? If the report cannot answer that question cleanly, it comes back with follow-up requests, and your audit timeline slips.
This post covers what SOC 2 auditors look for in pen test evidence, what PCI-DSS QSAs check against Requirement 11.4, the common ways pen test reports fail audits, and how Penetration Testing as a Service (PTaaS) makes the evidence trail easier to produce on demand.
What SOC 2 Auditors Look For
SOC 2 does not explicitly require penetration testing in the Trust Services Criteria. Auditors expect it anyway. A pen test is the most direct evidence that several common criteria are operating as designed.
The criteria most often supported by a pen test:
CC4.1 (Monitoring Activities)
The entity selects, develops, and performs evaluations to confirm internal controls are present and functioning. Pen testing is explicitly cited as one of these "ongoing and separate evaluations" in the AICPA points of focus.
CC6.1 and CC6.6 (Logical Access and External Threats)
Pen testing validates that access controls hold up against attempted exploitation.
CC7.1 and CC7.2 (System Operations and Anomaly Detection)
Pen testing surfaces vulnerabilities and exploitation paths that automated scanning misses.
CC9.1 (Risk Mitigation)
Findings and remediation evidence feed your risk management program.
For SOC 2 Type I audits, which evaluate control design at a point in time, a pen test is helpful but not essential. For Type II audits, which evaluate operating effectiveness over a 6-to-12-month observation period, the pen test is effectively required. The report has to fall inside the observation window.
When an auditor reviews your pen test, they look for these specific elements.
Scope mapped to the system description
The systems tested must match the systems in your SOC 2 system description. If your system description includes your customer-facing application, your production cloud environment, and your authentication provider, all three need to appear in the pen test scope. Vague scope language is a common reason auditors push back.
Engagement dates inside the audit window
A pen test report dated three months before the observation period started does not count for that period. Schedule pen tests so the report dates fall inside the window.
Documented methodology
The report should explicitly reference an industry-standard methodology like OWASP, PTES (Penetration Testing Execution Standard), or NIST SP 800-115. Testing without a defined methodology is a red flag.
Tester independence and qualifications
Auditors expect a qualified third party. Internal teams testing their own environment is generally not accepted as the primary pen test. Tester certifications such as Offensive Security Certified Professional (OSCP), GIAC Penetration Tester (GPEN), or Offensive Security Experienced Penetration Tester (OSEP) should appear in the report.
Findings with severity, evidence, and remediation guidance
Each finding needs a Common Vulnerability Scoring System (CVSS) rating, a description, evidence of exploitation, and a prioritized remediation recommendation. A list of vulnerabilities without exploit evidence reads like a vulnerability scan, which auditors treat differently.
Remediation and retest evidence
Findings rated critical or high should show evidence of remediation, or documented risk acceptance with management sign-off. Retesting evidence proves the fix actually worked.
Mapping to Trust Services Criteria
Many auditors prefer pen test reports that explicitly map findings to the criteria they affect (CC4.1, CC6.1, CC7.1, and so on). This is not always required, but it speeds the audit considerably.
What PCI-DSS QSAs Look For
PCI-DSS is far more prescriptive. Requirement 11.4 in PCI-DSS 4.0 and 4.0.1 spells out what penetration testing must include. QSAs check the report line by line against it.
Documented methodology (Requirement 11.4.1)
The report must reference an industry-accepted methodology, typically NIST SP 800-115, PTES, OSSTMM (Open Source Security Testing Methodology Manual), or OWASP. The methodology must cover testing from inside and outside the network and address the entire Cardholder Data Environment (CDE) perimeter and critical systems.
External penetration testing (Requirement 11.4.2)
Annual external testing of internet-facing systems is required. The report must demonstrate that the tester attempted to identify and exploit vulnerabilities from outside the network. Under Requirement 11.4.2b, the QSA may interview the tester to verify how the testing was performed.
Internal penetration testing (Requirement 11.4.3)
Annual internal testing of the CDE and connected systems is required. The same interview expectation applies under Requirement 11.4.3b.
Application-layer testing (Requirement 11.4.3 and Requirement 6.4.1)
Public-facing web applications and APIs must be tested annually and after significant changes. The report should show authentication, authorization, input validation, and business logic testing, not just network-layer findings.
Segmentation testing (Requirements 11.4.5 and 11.4.6)
All entities using segmentation must validate it at least annually under 11.4.5. Service providers must validate every six months under 11.4.6. The report must show that the tester attempted to cross from out-of-scope systems into the CDE and document every method tested.
Retesting on remediation (Requirement 11.4.4)
When vulnerabilities are remediated, the tester must verify the fix. Reports should show original finding, remediation action, and retest result for every exploitable issue.
Tester qualifications and independence (Requirements 11.4.2b and 11.4.3b)
The tester must be a qualified internal resource or a qualified external third party. QSAs may interview involved personnel to verify the work was performed appropriately.
Risk-rated findings
CVSS scoring is the expected format. Each finding needs evidence of exploitation, not just a description of the vulnerability.
Customized Approach documentation
If your organization is using the customized approach for any control, the pen test must demonstrate that the alternative controls actually work.
The Most Common Ways Pen Test Reports Fail Audits
A pen test report can be technically sound and still fail an audit. The most common failure modes:
Scope drift
The pen test scope does not match the SOC 2 system description or the PCI-DSS CDE. Auditors compare the two documents directly.
Out-of-window reports
The pen test report is dated outside the audit observation period or outside the PCI-DSS annual cycle.
Vulnerability scans labeled as pen tests
A report that lists CVEs and severity scores without evidence of exploitation, chained findings, or business logic testing reads like a scan, not a pen test. Auditors will not accept it as pen test evidence.
Missing methodology
The report does not reference an industry-standard methodology, or references one in a sentence without showing how it was applied.
No retest evidence
Findings show as "remediated" in tracking systems, but no retest occurred. PCI-DSS Requirement 11.4.4 explicitly requires retesting. SOC 2 auditors expect it for critical and high findings.
Vague tester qualifications
The report does not name the testers or list their credentials. QSAs and SOC 2 auditors push back when they cannot verify independence and qualification.
Stale findings
The report references vulnerabilities that have not been addressed across multiple audit cycles. This signals a risk management failure.
Incomplete CDE coverage (PCI-DSS specific)
The pen test misses systems that touch the CDE or connect to it. QSAs catch this by comparing the test scope to the CDE diagram.
Segmentation testing skipped (PCI-DSS specific)
Many organizations run an annual pen test and forget the segmentation test, which has a separate requirement and a separate cadence for service providers.
How PTaaS Makes the Evidence Trail Easier
A traditional pen test gives you a single report at a single moment. PTaaS gives you a continuous evidence stream that maps cleanly to what auditors and QSAs check for.
Reports always inside the audit window
With ongoing testing, you have current findings and recent reports any time an auditor asks. You stop scrambling to schedule a pen test before audit kickoff.
Retesting is built in
Findings are retested as remediation completes. The evidence chain (find, fix, verify) lives in one place. PCI-DSS Requirement 11.4.4 evidence is always available.
Methodology is documented and consistent
PTaaS providers operate against a defined methodology that gets referenced in every report. There is no question about whether last year's tester used the same approach as this year's.
Findings map to scope continuously
Because the engagement is ongoing, the test scope evolves with your environment. The pen test scope and your SOC 2 system description, or your PCI-DSS CDE, stay aligned without manual reconciliation each audit.
Segmentation testing on the right cadence
A PTaaS engagement can schedule segmentation testing annually for non-service-providers and every six months for service providers automatically, so you do not miss the requirement.
Tester qualifications documented in the platform
The portal shows who is testing, what credentials they hold, and what tests they ran. Auditor questions about independence and qualification answer themselves.
Application-layer testing aligned to release cadence
New features and major releases get tested as they ship rather than once a year. PCI-DSS Requirement 6.4.1 evidence accumulates naturally.
How APT Does PTaaS for Compliance-Driven Buyers
APT Security Management offers PTaaS through a prepaid token model and a flat-rate package option. Both include manual testing by OSCP- and CISSP-certified testers, retesting on remediated findings, and reporting formatted for SOC 2, PCI-DSS, HIPAA, and ISO 27001 auditor review.
Reports include:
Scope clearly mapped to your system boundaries or CDE
Methodology aligned with NIST SP 800-115, OWASP, and PTES
CVSS-rated findings with evidence of exploitation
Retesting documentation as remediation completes
Tester qualifications and engagement dates
Mapping to relevant Trust Services Criteria for SOC 2 engagements
Mapping to specific Requirement 11.4 sub-requirements for PCI-DSS engagements
If your audit is in the next six months, a 30-minute consultation will tell you whether your current pen test posture will survive the audit, and what to do if it will not.
Frequently Asked Questions
Does my SOC 2 pen test need to be performed by an external company?
Does my SOC 2 pen test need to be performed by an external company?
Most auditors expect an external, independent third party for the primary pen test. Internal testing may be accepted as supplementary evidence but rarely as the only pen test for Type II audits.
Can a single pen test cover both SOC 2 and PCI-DSS requirements?
Can a single pen test cover both SOC 2 and PCI-DSS requirements?
Sometimes, if the scope is constructed carefully. The SOC 2 system boundary and the PCI-DSS CDE often overlap but rarely match exactly. A combined engagement requires a scope that explicitly covers both. Talk to your QSA and SOC 2 auditor before assuming one report covers both audits.
What if a pen test finds a critical vulnerability right before an audit?
What if a pen test finds a critical vulnerability right before an audit?
Document the finding, remediate it, retest, and provide the full evidence chain to the auditor. A critical finding that is found, fixed, and verified shows that controls are working. A critical finding that is found and ignored is the actual audit risk.
Will a vulnerability scan satisfy SOC 2 or PCI-DSS pen test requirements?
Will a vulnerability scan satisfy SOC 2 or PCI-DSS pen test requirements?
No. Vulnerability scanning supports both frameworks but neither accepts scanning as a substitute for pen testing. PCI-DSS Requirement 11.4 explicitly calls for penetration testing, not scanning. SOC 2 auditors expect human-driven testing to satisfy CC4.1 and related criteria.
How current does a pen test report need to be for audit?
How current does a pen test report need to be for audit?
For SOC 2 Type II, the report must fall inside the audit observation period, typically 6 to 12 months. For PCI-DSS, the most recent annual test must be on file, plus any tests triggered by significant changes since.
Audit-ready pen testing for SOC 2 and PCI-DSS
Book a free 30-minute consultation. We will look at your current pen testing posture, your audit timeline, and the gaps your auditor or QSA is most likely to flag.
