PTaaS for SOC 2 and PCI DSS: What Auditors Want

Companies buy penetration tests for audits far more often than they buy them out of curiosity. That is fine, and it is worth knowing what the auditor is actually going to look at, because a technically excellent test can still fail to satisfy one.

What the frameworks require

SOC 2 does not mandate penetration testing anywhere in the Trust Services Criteria. Auditors ask for it because it is the most common evidence for monitoring and risk assessment controls, particularly CC4.1 and CC7.1. That means your auditor’s expectations matter more than any written rule.

PCI DSS is explicit. Requirement 11.4 mandates internal and external testing at least annually and after significant change, using an industry accepted methodology, performed by a qualified party who is organizationally independent of the tested system.

ISO 27001 treats testing as one way of satisfying Annex A technical review controls, again with the auditor deciding what suffices.

The five things an auditor checks

Scope matches the audited environment. The most common failure. Your SOC 2 covers a production application; your test covered a staging instance, or two of the five services in scope. The auditor will compare the two documents.

Methodology is stated. PTES, OWASP Testing Guide, NIST SP 800-115, or a described internal approach. An auditor is checking that the test followed something rather than being improvised.

The date is inside the window. Within the last twelve months for most frameworks, and PCI DSS also wants one after significant change.

Independence. The tester cannot be the person who built or maintains the system. For PCI DSS this is a hard requirement rather than a preference.

Remediation is evidenced. Findings, what was done, and verification. An open critical finding with no plan is worse in an auditor’s eyes than a critical finding with a dated remediation record.

Where subscription testing trips people up

Continuous testing makes “within the last twelve months” harder to point at. A platform showing a rolling stream of findings does not obviously answer the question “when was the test.”

Two practical fixes:

• Ask your provider for a point in time attestation letter naming the scope, the methodology, the dates and the tester. Most will issue one on request, and it is the document your auditor actually wants
• Make sure the platform can export a report as of a date rather than only a live view

What to hand over

A complete package is usually:

1. The report, including scope and methodology
2. An attestation letter naming dates and independence
3. Your remediation tracker showing what was fixed and when
4. Retest evidence for anything high or critical

One thing worth saying

An auditor accepting your report is a lower bar than the report being useful. It is possible to pass with a document that told you nothing.

If you are buying a test anyway, it costs no more to buy one that would survive being read by an engineer rather than filed by a compliance manager.