Penetration testing evidence for audit: what PCI DSS, ISO/IEC 27001:2022 and SOC 2 reviewers ask for

A penetration testing report can be technically strong and still leave a gap in your audit file. Reviewers look past the findings. They want to see how the test was planned, who ran it, what it covered and whether the fixes were confirmed.

When that record is missing, the cost is time. Sign-off slips, and evidence has to be rebuilt after the fact. The remedy is a decision you make before testing starts: agree on the evidence standard first, then test against it.

What auditors ask for

Penetration testing (pen test) is a controlled attack on your systems by a qualified tester, run to find weaknesses an attacker could use. For an audit, the report is only one part of the evidence. Reviewers usually ask for six things:

  • Method: the documented approach the tester followed.
  • Scope: the systems, networks and applications covered, and anything left out with the reason.
  • Dates: when testing took place, so the reviewer can check it against the required frequency.
  • Independence: who ran the test and how they are separate from the people who run the systems.
  • Findings with severity: each weakness, the proof that it is real and a severity score.
  • Proof of fix: a retest that shows exploitable findings were corrected.

Each framework weighs these differently. The table shows where they meet.

Framework What it asks Evidence to keep
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 independent tester, and repeat testing to verify fixes Method document, scope, test dates, tester details, report, retest result
ISO/IEC 27001:2022 No set test type or cadence. Annex A 8.8 and 8.29 cover technical vulnerabilities and security testing; your risk assessment sets the rest The risk assessment entry that sets the test, a report mapped to 8.8 and 8.29, fix records
SOC 2 CC4.1 lists penetration testing among example separate evaluations The report, the evaluation it supports, management’s response
MAS TRM and APRA CPS 234 Testing under technology risk rules (MAS TRM section 13.2; APRA CPS 234, with CPG 234 as guidance) The same pack, mapped to the regulator’s guideline

PCI DSS v4.0.1 sets the clearest rules

PCI DSS is the security standard for organizations that store, process or transmit payment card data. Version 4.0 was retired on December 31, 2024. Version 4.0.1 is now the only active version, and it adds or deletes no requirements. The future-dated requirements have been mandatory since March 31, 2025. If your last test was planned against older wording, check it against the current text before the next assessment.

Requirement 11.4 covers penetration testing in five parts.

Requirement 11.4.1 asks for a documented penetration testing methodology based on industry-accepted approaches. It covers the perimeter of the cardholder data environment and critical systems. Testing runs from inside and outside the network, at both the application and network layers, and the results are retained.

Requirements 11.4.2 and 11.4.3 ask for internal and external testing at least every 12 months and after any significant change. A qualified tester with organizational independence must run it. That tester does not have to be a Qualified Security Assessor (QSA) or an Approved Scanning Vendor (ASV).

Requirement 11.4.4 asks that exploitable findings be corrected based on risk, and that testing be repeated to verify the fix. A report without a retest shows the problem but not the repair.

Requirement 11.4.5 applies where segmentation isolates the cardholder data environment. Segmentation controls are tested at least every 12 months and after changes to them. Service providers test segmentation more often.

For the person who owns the audit file, the useful point is simple. Every one of these parts leaves a record. If you decide up front which records you need, the test produces them as it runs.

ISO/IEC 27001:2022 and SOC 2 leave the cadence to you

ISO/IEC 27001:2022 was published on October 25, 2022. Certificates issued against the 2013 edition were not valid after October 31, 2025, so surveillance and recertification audits now test against the 2022 controls.

The standard sets no test type and no test cadence. Your risk assessment does. Two Annex A controls are related: 8.8, “Management of technical vulnerabilities,” and 8.29, “Security testing in development and acceptance.” An auditor will look for a clear line from the risk you identified to the test you chose and how often you run it. Write that reasoning down in the risk assessment, and the report becomes evidence for a decision you already made.

SOC 2 works in a similar way. Criterion CC4.1 covers monitoring through separate evaluations, and its points of focus list penetration testing as one example. Vulnerability scanning sits under CC7.1. Points of focus are illustrative, so they do not fix a frequency. Your auditor will ask how the test supports your monitoring and what management did with the results.

NIST CSF 2.0 gives the board a common frame

Boards and executives often prefer a single frame over a list of standards. NIST released the Cybersecurity Framework 2.0 on February 26, 2024, with six Functions: Govern, Identify, Protect, Detect, Respond and Recover. It does not set a testing requirement. It does give leadership a plain way to discuss what a pen test told them and what changed as a result. A one-page summary in the report, written for that audience, saves a second meeting.

Regional regulators publish testing guidance

Banks in Asia-Pacific also answer to regulators that publish technology risk rules (MAS, APRA, BNM, HKMA). Two examples show the pattern. The MAS Technology Risk Management Guidelines (January 2021) cover penetration testing in section 13.2. APRA CPS 234 expects a systematic testing program run by functionally independent specialists, and its guidance, CPG 234, names penetration testing. Map findings to the regulator’s guideline in the same report.

Methods the report should name

The PCI DSS requirement text does not name a specific method. Naming the method in the report lets a reviewer check the work against a public reference. Common choices are:

  • OWASP WSTG, ASVS and MASVS for web, API and mobile applications.
  • PTES and NIST SP 800-115 for the overall testing process.
  • CVSS, the Common Vulnerability Scoring System, for severity.
  • MITRE ATT&CK for describing attacker techniques in a way security teams recognize.

Agree on the method in the scope document before testing, and name it again in the final report.

A pen test evidence pack: checklist

Use this list when you plan the next test. If each item exists before the auditor asks, the review moves faster.

  1. A scope statement, approved by the system owner, with exclusions and the reason for each.
  2. The named testing method and the frameworks the findings will map to.
  3. Test dates and the tester’s details, including how the tester is independent.
  4. Findings with a CVSS score and proof that each one is real.
  5. A mapping of each finding to the controls your auditors use.
  6. A fix owner and a target date for every finding.
  7. The retest result, with dates, for every exploitable finding.
  8. A one-page summary for leadership.
  9. Sign-off by the risk or audit owner.

What to decide this quarter

If your audit or budget cycle falls in Q4 or Q1, plan now. Before you sign a test order, agree on what is in scope and who accepts the method. Then fix the retest date in the plan, so proof of the repair arrives before the audit does.

Next step

Snipeyes is a CREST Member and certified to ISO/IEC 27001:2022. Every finding we report is proven. One report serves leadership, engineers and auditors, with findings mapped to ISO/IEC 27001:2022, SOC 2, PCI DSS, OWASP ASVS and your regulator. Your assessor or certification body makes the final decision; our job is to give them a clear and complete record. Retest included.

If you are planning your next annual or post-change test, book a free 90-minute scoping session and we will plan it around the evidence pack described above. Already know the scope? Request a scoped proposal. You can also read more about our penetration testing provider for banks in APAC and our banking and financial services security testing.