Penetration Testing for Compliance: Evidence Required for PCI DSS, ISO 27001, and SOC 2 Audits
Most teams treat the penetration test report as the evidence. The auditor treats it as one page of the evidence, and usually not the page they ask about first. They want to know why the test covered what it covered, who did the work, and whether the problems it found were actually fixed. When those answers live in someone’s inbox instead of the audit file, the review slows down at exactly the moment you need it to finish.
We see this from the tester’s side of the table. In our experience the technical work is seldom what holds a review up. The gap sits in the paperwork around it, and that paperwork is far easier to produce while the test is being planned than to rebuild months later.
A finding is only evidence once it is closed
Take one of our open-banking API tests for a bank. We tested 27 endpoints and found a flaw that let a caller divert funds, together with signed requests we could replay. Those two weaknesses chained into a critical path. The bank fixed it in four days.
From an engineer’s point of view, the story ends there. From an auditor’s point of view it has barely started. The report proves the weakness existed. What the auditor will look for next is the scope that put those endpoints in the test, the dates, the independence of the people who found it, and a retest that shows the fix held. A critical fix with no retest on file is just a claim.
Here is the trail that one finding needs before it counts as closed evidence:
| Record | What it answers for the reviewer |
|---|---|
| Scope letter listing the API and its endpoints | Why these endpoints were tested at all |
| Test dates and the testers’ independence statement | When it happened, and that the people who found it do not run the system |
| The finding with its proof and severity | That the weakness was real, and how serious |
| The control it maps to | Which requirement or Annex A control the finding is evidence for |
| Fix owner, fix date and what changed | Who closed it and when |
| Retest date and result | That the fix held |
The test itself produced only the third row. The other five come from decisions made around it.
What reviewers actually read
The frameworks ask for this in different language, and some ask for very little in writing. That is part of the problem, because teams read “not specified” as “not needed”.
| Framework | What it says about testing | What the reviewer will want to see |
|---|---|---|
| PCI DSS v4.0.1, requirement 11.4 | A documented method, internal and external testing at least every 12 months and after significant change, a qualified tester with organizational independence, and repeat testing to verify fixes | The method, the scope, test dates, who tested, the report and the retest |
| ISO/IEC 27001:2022 | No set test type or cadence; your risk assessment decides. Annex A 8.8 and 8.29 cover technical vulnerabilities and security testing | The risk assessment entry that justifies the test, and findings tied back to those controls |
| SOC 2 | Penetration testing appears among example separate evaluations under CC4.1; scanning sits under CC7.1. Points of focus are illustrative | How the test fits your monitoring, and what management did with the results |
PCI DSS is the most specific of the three, and it changed recently. Version 4.0 was retired on December 31, 2024, and the requirements that were future-dated became mandatory on March 31, 2025. If your last test was planned against older wording, check it against the current text. We cover requirement 11.4 in detail in PCI DSS 11.4 penetration testing requirements explained.
ISO/IEC 27001:2022 works the other way round. It does not tell you to run a penetration test at all. It tells you to manage technical vulnerabilities based on risk, so the evidence starts in your risk assessment: why this system, why this kind of test, why this often. If that reasoning is written down before the test, the report slots straight into it. If it is written afterwards, it tends to read like a justification. Since October 31, 2025, certificates issued against the 2013 edition are no longer valid, so surveillance audits now look at the 2022 controls.
Plan the evidence before you plan the test
The cheapest time to build the audit trail is the scoping call. A few decisions made there save weeks later.
Agree the method in writing. PCI DSS asks for an industry-accepted approach without naming one, so name it yourself: OWASP WSTG or ASVS for applications, PTES or NIST SP 800-115 for the overall process, CVSS for rating severity. The reviewer can then check the work against something public.
Write down why the scope is what it is. If segmentation keeps your card data environment small, say so and test the segmentation. If a system is out of scope, record the reason next to it.
Ask how the tester is independent of the team that runs the systems, and keep the answer. It is only a short paragraph, which is exactly why it gets forgotten.
Book the retest when you book the test. A retest planned for “when the fixes are done” has no date, and an audit always does.
To take into that scoping call, our one-page penetration testing control map lays out PCI DSS 11.4, ISO/IEC 27001:2022 Annex A, SOC 2, NIST CSF 2.0, MAS and APRA side by side: what each one asks of a penetration test, and which part of the report answers it.
What a usable evidence pack looks like
When we hand over a test, the file we would want to receive as an auditor holds the approved scope and its exclusions, the named method, test dates and the testers’ independence, each finding with its proof and severity, the control each finding maps to, an owner and a date for every fix, and the retest result. On top sits a one-page summary written for leadership, because a board member reads a different section from the engineer who fixes the code.
Banks across Asia-Pacific also answer to regulators that publish their own technology risk rules. The MAS Technology Risk Management Guidelines cover penetration testing, and APRA’s CPS 234 expects testing by functionally independent specialists. The same pack serves those reviews too, as long as the findings are mapped to the regulator’s guideline in the same report rather than in a second document.
How we work
We build that trail into every engagement. If we cannot reproduce a weakness, it never reaches the report, so the auditor is not asked to take anything on trust. Each finding already carries its control mapping for ISO/IEC 27001:2022, SOC 2, PCI DSS, OWASP ASVS and your regulator’s rules, the report arrives within 10 business days of testing, and the retest is part of the engagement rather than an extra. Your assessor or certification body still makes the call. Snipeyes is a CREST Member and certified to ISO/IEC 27001:2022.
If an annual or post-change test is coming up, book a free 90-minute scoping session and we will plan the scope and the evidence together. If you already know the scope, request a scoped proposal. You can also read how we approach API penetration testing and security testing for banks.