Mapping Your Penetration Test to Certification Requirements as Evidence

A penetration test report becomes compliance evidence only when its scope matches what the standard asks about. When the scope is right, a PCI assessor (a QSA) or a SOC 2 auditor can work from the report directly. When it is not, even strong testing does not count. For a leadership team, that is the difference between a report that moves an enterprise deal forward and one that starts another round of questions.

The two decisions that determine whether your report counts both happen outside the testing window. The first is scope: what was included, what was excluded, and whether the reasoning is written down. The second is remediation: whether someone independently confirmed the fixes worked, or whether a ticket got closed and everyone moved on.

What your PCI assessor looks for under Requirement 11.4

PCI DSS 4.0.1 is specific about penetration testing. Requirement 11.4 expects the test to cover the systems that handle card data, to prove those systems are properly separated from everything else, to follow a recognized method, and to show that serious findings were fixed and then re-tested.

What that means for leadership is simple. PCI scope follows the systems that handle card data, so it is less flexible than SOC 2. In our engagements that has not been a problem, and agreed PCI scopes have held up. The point to hold on to is that a report scoped to the wrong systems would not satisfy Requirement 11.4, however thorough the testing was. That is why scope gets settled before testing starts.

What a SOC 2 auditor needs the same report to do

SOC 2 works differently. The Trust Services Criteria do not require a penetration test by name the way PCI DSS 4.0.1 does. Instead, your company describes its own controls, and the auditor checks whether those controls worked throughout the observation period.

If your controls say you run an annual independent penetration test and fix findings on a defined schedule, the report is your proof. The auditor wants to see three things: the test happened inside the observation period, it covered the systems your controls describe, and fixes landed on the timelines you committed to.

This has a consequence people underestimate. The report has to make sense to someone who is not a penetration tester. An auditor needs scope, dates, severity ratings, fix status, and who confirmed each fix, up front. When that information is buried in technical appendices, your team spends the observation period writing explanatory memos instead of running the business.

Findings tied back to the relevant Trust Services Criteria save your team and your auditor time.

How one test covers both

One penetration test can serve both standards, and matching the scopes is the simplest way to get there. SOC 2 can be limited in scope, which makes it easy to match. PCI is different, because its scope follows the systems that handle card data. We recommend matching the two scopes because it makes everything easier.

If you are inside both a PCI assessment window and a SOC 2 observation period, say so at scoping. Lining the work up with both calendars is a scheduling problem, and it is solvable when you raise it early rather than in month ten.

Write the scope reasoning down

We have not had to tell a client that their agreed scope would not hold up for PCI or SOC 2. Writing down why things are in scope, and why anything is out, keeps it that way.

A list of what was tested shows coverage. The reasoning behind it makes scope defensible: these systems handle card data, these are walled off and here is how the wall was tested, this application controls logins for the platform under review.

Exclusions matter as much as inclusions. An assessor who finds an in-scope system missing from the test will ask about it. A one-line note explaining a documented exclusion ends that conversation. A verbal agreement from six months ago does not.

Scope should also account for everything connected to your network, not only what appears on the asset list. Two of our internal network engagements surfaced unmanaged devices running factory default credentials: a leased Xerox multifunction printer, which enabled silent interception of documents sent to it, and a networked APC UPS, which enabled attacker-controlled disruption of a data centre. Both were remediated. You can read the full write-up in The Threat Is Inside the Network.

Published standards make coverage defensible

When an assessor asks how the testing firm decided what to test, “we ran a scanner” and “we followed a published standard” land very differently.

Our testing follows published, industry-recognized standards, so an assessor can check what our coverage includes rather than take it on faith.

This is also where manual testing earns its place. Automated scanners find known weaknesses in off-the-shelf software. They miss flaws in how your own product works, small issues that combine into a serious one, and risks specific to your business. Those are exactly the findings an enterprise customer’s security team looks for when they review your report alongside the auditor’s. We cover the distinction in detail on our comparison against automated vulnerability scanners.

Our firm-level CREST accreditation and ISO 27001:2022 certification give assessors a third-party reference for how the work is governed. Team certifications include OSCP, OSWP, CISSP, and CISM.

Remediation counts as evidence only when someone re-tests it

PCI DSS 4.0.1 asks for serious findings to be re-tested once they are fixed, so an internal sign-off is not enough. SOC 2 auditors will accept your internal verification, but an enterprise prospect reviewing the same report will notice which one they are looking at.

This is where the standard commercial model works against you. Most penetration testing engagements include one re-test. That gives you a single window to prove fixes worked, and anything remediated after the window closes carries no independent verification until the next annual cycle.

We include five free re-tests within 12 months of every engagement. A mid-market SaaS team fixes issues across several releases. Five windows let you confirm fixes as they ship, so when an assessor, an auditor, or an enterprise customer asks, the record of verified fixes is already complete.

One report, three audiences

The same document goes to your assessor, to your enterprise prospect’s security review team, and to your board. Writing it for one of them creates rework for the other two.

Assessors need scope justification, methodology, and remediation verification. Enterprise security reviewers need technical depth and evidence that manual testing happened. Boards need risk framed in business terms with a clear path to resolution. A report built for all three from the start puts each audience’s answers where they will look first. We cover the board conversation in How to Tell Your Board What Your Pentest Actually Found.

For exactly this reason, we share sample reports on request, within one business hour. You should see the structure before you commission the work.

Decide who owns evidence readiness

For leadership, the question is who in your organization owns evidence readiness. That person makes sure scope matches both your assessment and your controls, that the test lands inside the right window, and that every fix gets re-tested before someone outside the company asks.

In a company without a dedicated security team, that role has no obvious home. Naming an owner before you commission the test is a leadership decision.

If you are earlier in the cycle and not sure where the gaps are, our free Pentest Readiness Assessment will show you where you stand before you scope the work.

One boundary worth stating plainly: we run the test and produce the evidence. Your QSA or your SOC 2 auditor makes the determination.

Request a sample report to see what assessor-legible findings look like. If you already know your dates, book a 30-minute consultation and we will map scope and timelines against the window you are working toward, including whether one test can serve both standards. John Svazic has personally led every engagement since 2019, and he runs that call.

Headquartered in Canada. Independent. Certified. Trusted.