Building an Audit Evidence Package From a Pen Test Report

Building an audit evidence package from a pen test report means proving more than the fact that testing happened. For technical founders and engineering leaders, the job is to connect the authorized scope and methodology to findings, fixes, and verified retests. Auditors need that whole chain to see whether controls worked and whether the organization dealt with the failures.

Why a pen test report alone is not audit evidence

The pen test is finished, the PDF has arrived, and the report has gone to the auditor. Then the questions come back. Who approved the scope, and when? Who owns the high-risk finding, and where is the evidence that the fix worked? The report describes the assessment, but it does not prove what happened before or after it.

That is the gap between a security assessment and a compliance audit. The assessment checks whether controls worked when they came under attack. The audit asks whether the organization can prove that testing and its response happened in the right order, with a clean evidence chain. A report without remediation and retest records remains a diagnostic artifact and an incomplete compliance artifact.

Three recurring failures make that gap worse. Testing outside the audit observation window is inadmissible for that period, regardless of the report’s quality. Automated scan output is no substitute for human-attacker exploitation. And a finding without a named remediation owner, a retest timestamp, and verified closure remains open in the auditor’s view. None of these failures disappears because the final PDF looks thorough.

What each major framework actually demands from a pen test engagement

SOC 2 does not explicitly mandate penetration testing. But auditors treat it as primary evidence that monitoring and detection controls work when they face real-world attacks. They connect testing to CC4.1 for ongoing and/or separate evaluations, CC6.1 for logical access, CC7.1 for system operations and vulnerability detection, and CC7.2 for anomaly monitoring. The date is part of that evidence. For a Type II audit, a test outside the observation window cannot show how controls worked during that period.

HIPAA’s current Security Rule at §164.308(a)(8) calls for technical and nontechnical evaluation from time to time, but it does not name penetration testing. HHS proposed a rule in January 2025, still awaiting entry into force, that would explicitly require annual penetration testing for covered entities and business associates handling ePHI. As of October 2026, HHS targets July 2027 for final action, while auditors and enterprise customers already treat annual testing as the expected standard. The distinction is important because an expected practice is not the same as an enacted requirement.

ISO 27001:2022 also does not name penetration testing as a requirement. Auditors consistently expect it as evidence for Annex A 8.8, management of technical vulnerabilities, and 8.29, security testing in development and acceptance. The transition deadline is no longer ahead. The October 31, 2025 deadline has passed, ISO 27001:2013 certifications have expired, and the 2022 standard is now the only valid version.

These frameworks do not prescribe an identical pen test deliverable, so acceptance depends on the quality and completeness of the evidence. One well-scoped, documented engagement can satisfy SOC 2 CC4.1, ISO 27001 Annex A 8.8 and 8.29, and PCI DSS Requirement 11.4. But the report itself must map findings to the relevant controls rather than leave the auditor to infer the connection.

The seven components every audit evidence package must contain

The first component is the authorization memo and rules of engagement. Written approval from named stakeholders must precede testing and cover scope boundaries, the test window, permitted tools, and legal authorization. The date establishes that testing was governed from the outset.

The second component is tester qualifications and independence attestation. It names the testers, records certifications such as OSCP and equivalents, and includes a signed statement that they had no involvement in designing or building the controls being tested. Credentials alone do not establish that independence. The qualification attestation is one of the two artifacts auditors most often find missing.

The third component is a precise scope register. It enumerates the systems, applications, APIs, cloud configurations, and network segments included in testing. The register gives the auditor a defined boundary against which to read the findings, rather than an assurance that the provider tested “the application.”

The fourth component is the full findings report with exploitation evidence. Each finding needs reproducible steps, affected assets, root cause, a CVSS or equivalent risk rating, and business impact. Screenshots, payloads, and configuration diffs provide tangible proof of exploitation. Without that proof, a finding remains an allegation. Reproducibility also gives the later retest something specific to verify.

The fifth component is framework control mapping. Each finding must point to the control or criterion it implicates, such as SOC 2 CC6.1 or CC7.2, or ISO 27001 Annex A 8.8 or 8.29. This is the report’s bridge to the audit. It allows the auditor to cross-reference technical evidence with the control being evaluated.

The sixth component is a remediation plan that names who owns the work. It assigns each finding an owner, a priority tier, and a deadline alongside suggested fixes. A recommendation is not an accountable plan. If no owner is named, the auditor still sees the finding as open, even if the report explains exactly how to fix it.

The seventh component is the retest report. It records whether remediation worked, with timestamped evidence of verified closure rather than an internal claim that a fix was deployed. This is the other commonly missing artifact. Supporting material, including raw tool output, system logs, and timestamped screenshots, belongs in a central repository with access logging and immutable or checksum-validated storage.

Why remediation timing is itself audit evidence

Auditors read both the timestamps and the findings. Discovery, assignment, the attempted fix, and confirmed closure show how the organization handled an identified risk. A critical or high finding that stays open through the observation period weakens the claim that controls operate effectively. This is especially true of findings that could allow initial access or lateral movement, because they pose an active risk.

For that reason, the package should record four timestamps for each finding, which are discovered, assigned to owner, fix deployed, and retest confirmed. Each gap should be defensible given the severity. This turns remediation from work done after the assessment into evidence evaluated as part of it. It also distinguishes security activity, such as running a test, from the outcome of finding, fixing, and verifying an exploitable path.

Under SOC 2 Type II, a finding opened and closed within the observation window, with a documented retest, is stronger evidence of functioning controls than a clean report with no findings. A clean report can raise questions about testing depth. The finding that was fixed shows both detection and response, as long as there is proof of the order in which they happened. Preserving that sequence is the purpose of the audit trail.

How to build and maintain the audit trail that holds the package together

To preserve that sequence, store all test artifacts in one central location with access logging enabled from the first day of the engagement. Do not reconstruct the record at audit time. The trail must link each finding to every action that followed so an auditor can follow what happened without help. A folder of PDFs may hold the documents without showing those links.

Tie every finding to a remediation ticket in the organization’s issue tracking system. That ticket connects the report to the closure event. Keep the discovery, assignment, fix, and retest timestamps in the same system rather than scattering them across spreadsheets that need manual reconciliation.

Preserve raw artifacts with immutable storage or checksum validation. Access logs alone do not establish that a screenshot is unchanged. If its integrity is questioned, a hash that matches the original provides the definitive check. This protection belongs with both the original evidence and the polished report built from it.

Retention must match the applicable framework’s requirements. The periods given here are at minimum one year for PCI DSS, five years for SOC 2 working papers under AICPA standards, six years under HIPAA, and seven years under SOX/PCAOB. A blanket one-year policy is not enough. Some frameworks require longer retention, and the cost of keeping evidence longer is lower than the cost of a gap.

Who found what? What was done about it? Can the record prove the fix worked? Apply all three to every finding. If any answer depends on an unrecorded explanation, the package is incomplete regardless of how strong the original report looks.

What a pen test engagement needs to produce from the start to make the evidence package possible

Most failures in an evidence package start during the engagement, before the documents are put together. Missing exploitation evidence, incomplete scope, or unnamed and uncredentialed testers cannot be repaired by rewriting the final report. The underlying test must produce the required proof. So the engagement terms must spell out what evidence is needed before the contract is signed.

Require named testers with verifiable certifications before signing. Their qualifications will appear in the attestation, so their identity should not be deferred until after the purchase. Require a methodology mapped to a named standard, such as PTES, NIST SP 800-115, OWASP WSTG, or MITRE ATT&CK. A list of tools is not a testable process. The methodology must explain what the assessment is based on as well as which tools the provider will run.

Require proof of every finding through a working exploit, steps that can be reproduced, and exploitation artifacts. A vulnerability described only as “possible” or “likely” does not provide the required proof. Retesting must also be included in the engagement scope and fee. Otherwise, the contracted deliverable stops at diagnosis while the evidence package still needs verified closure.

Require critical findings to be reported within hours of discovery. A critical vulnerability held for weeks while testing continues is a governance failure that the timestamps will expose. Prompt reporting makes the response timeline possible. It gives the organization the opportunity to act while the engagement is still underway.

Complete attack surface coverage also depends on access. Whitebox access to source code, cloud configurations, and product documentation makes that coverage possible. Without access to code and configuration, testers can only estimate the internal trust boundaries and logic flaws that an attacker with insider knowledge would target. That scope gap remains even when the documentation carefully describes the work that was done.

The final requirement is the audit letter of attestation. A credentialed expert signs it to confirm the engagement’s scope, methodology, findings, and remediation for auditors and enterprise customers. It can only be issued when the work has been conducted and documented to the required standard.