Writing Audit-Ready Penetration Test Findings

Most technical founders assume a pen test report is a thing you hand to your auditor and check off a box. That's not what's happening on the other side of the table. An auditor reading that report is tracing a chain: was the vulnerability actually found, was it proven (not just flagged), does someone own fixing it, did the fix happen, and was that fix confirmed. If a link anywhere in that chain is missing, the finding sits open in the auditor's eyes, no matter how confident the engineering team feels about it.

An audit and a pen test differ in a way that functions differently, not as trivia. An audit checks whether policies exist and controls are documented; a pen test checks whether those controls survive contact with someone actually trying to break them. Auditors need both, and they read the pen test as proof the controls work in practice.

That's why SOC 2 auditors looking at CC4.1, ISO 27001 auditors reviewing Annex A control 8.8, and PCI DSS assessors checking Requirement 11.4 all end up asking the same underlying question, even though the frameworks look different on paper. Does this report show vulnerabilities that were found, proven, assigned, fixed, and confirmed? If the report can't answer that, the framework it's attached to almost doesn't matter.

Why the "PDF on a shelf" pen test fails this chain-of-evidence test

Picture the standard cycle. Test runs once a year, a PDF lands in an inbox, a few issues get patched, the report gets filed away, and the cycle repeats next year. Plenty of organizations running this loop keep seeing the same vulnerability classes come back, which is a pretty clear sign the cycle isn't actually closing anything.

Part of the problem is what these reports contain, and part of it is what they quietly leave out. Findings usually appear with a severity rating pulled straight from a CVSS score, and that's often where the documentation stops. There's no proof the vulnerability was actually exploited, no named owner attached to the finding, no remediation record tied back to it, and no retest confirming the fix held. A CVSS number tells you how bad something could theoretically be. It says nothing about whether anyone actually broke in, who's responsible for fixing it, or whether the fix worked.

And the scale of what gets missed by shallow, scan-heavy testing is not small. Citadelo's 2025 review of 628 IT projects turned up 3,293 vulnerabilities, with a critical vulnerability showing up in 71% of infrastructure projects, the typical environment carrying real, exploitable risk. That's the typical environment carrying real, exploitable risk. That's most environments carrying real, exploitable risk, and a scan-based report skimming the surface is not going to catch the chained vulnerabilities that actually get organizations breached.

What each framework requires the finding record to demonstrate

The abstract argument turns into something a reader can hold their auditor to. Different frameworks phrase it differently, but they converge on the same demand: show the work.

SOC 2 doesn't explicitly mandate penetration testing, but auditors widely expect it as evidence supporting Trust Services Criteria, especially CC4.1 (monitoring activities) and CC7.1 (system operations). How the findings get documented carries as much weight as what got found in the first place. Every finding needs a named owner, a remediation record, and a retest that was actually verified.

ISO 27001 is more explicit about the mechanics. The ISO 27001:2022 standard requires a documented vulnerability management procedure, penetration testing of in-scope systems at least annually, and risk-based remediation prioritized according to the organization's risk treatment plan. The transition deadline for the old standard passed on October 31, 2025, and every ISO 27001:2013 certification has now expired. If a company is still operating under the old standard, that's not a minor administrative lag, that's a certification that no longer exists. Annex A control 8.8 governs vulnerability management, and penetration testing as a method sits under both 8.8 and 8.29 (Security Testing in Development and Acceptance). Auditors working ISO engagements tend to treat a well-documented pen test report as the single strongest piece of evidence in the whole audit package.

HIPAA sits in a different spot. Right now it requires ongoing risk analysis and risk management, but it doesn't set a specific testing cadence. HHS proposed a Security Rule update in January 2025 that would make annual penetration testing an explicit requirement, but as of this writing it remains a proposal, not a finalized rule. The closest existing reference is §164.308(a)(8), which calls for "technical evaluation," and even without a hard testing mandate, findings still need to tie back into the organization's risk management documentation.

Requirement 11.4 explicitly mandates annual external and internal penetration tests, plus a retest after any significant change to the environment. Service providers face an even tighter clock on segmentation testing, which has to happen at least every six months. Unlike the other three frameworks, the remediation-and-retest loop here is written into the requirement itself. It's written into the requirement itself.

The five components every audit-ready finding must contain

Once the framework requirements are clear, the actual writing of a finding comes down to five components. Skipping any one of them leaves the finding vulnerable to an auditor's follow-up question that has no good answer.

The first is a proven exploit. A finding without a working exploit is an allegation, and auditors, along with security-conscious enterprise buyers, are increasingly unwilling to take allegations at face value. Scanner output alone can't demonstrate chained vulnerabilities, privilege escalation, lateral movement, or business logic flaws, and a real pen test is supposed to surface exactly those things that automated vulnerability scanning misses entirely. The exploit record needs the exact payload or technique, the environment it ran in, and the specific impact observed, such as data accessed, a privilege level reached, or a path to lateral movement.

The second component is business impact, not just a CVSS score. A CVSS number tells you technical severity in the abstract. It doesn't tell an auditor, or a remediation team trying to prioritize a backlog, what an attacker could actually walk away with. A finding tied to concrete business impact does double duty: it tells engineering what to fix first, and it gives the auditor context for why the organization's risk decisions make sense.

Third is an assigned owner. Every finding needs a specific person or team on the hook for fixing it. SOC 2 auditors reviewing monitoring controls are specifically looking for evidence that findings landed in an accountable workflow rather than getting dumped into a shared backlog where nobody in particular is responsible for them.

Fourth is a remediation record with specific steps taken. "Fixed" is not a remediation record. What changed, when it changed, who changed it, and which version or deployment it landed in, that's a remediation record. Without a timestamp and a specific change reference, defending that finding under audit questioning gets a lot harder than it needs to be.

Fifth, and this is the one that trips up more organizations than any other, is a verified retest result. PCI DSS makes retesting mandatory after any significant change, and SOC 2 and ISO 27001 auditors will treat a finding with no retest record as still open, regardless of how confident the engineering team is that it's handled. The retest is what moves a finding from "we think we fixed it" to "someone independently confirmed it's fixed."

How whitebox access changes what a tester can put in a finding

The quality of everything described above depends heavily on how much access the tester actually had going in.

Blackbox testing gives the tester zero prior knowledge of the system, so findings are limited strictly to what's observable from the outside. That approach mirrors what an actual outside attacker faces, but it also misses internal attack paths, misconfigured IAM roles, hardcoded secrets sitting in source code, and logic flaws that are only visible once you're looking at the codebase itself.

Whitebox testing flips that. The tester gets source code, cloud configuration access, and documentation, so the attack surface is fully mapped and nothing is unknown going in. This appears directly in finding quality. A blackbox finding might say "SQL injection vulnerability exists in login form." A whitebox finding can name the exact vulnerable function, the file and line number, the unsanitized parameter, the specific payload that triggered the exploit, and the data it returned. SQL injection specifically targets applications that build queries using unsanitized user input, and a working exploit against that flaw shows precisely which query got modified and what came back out. An auditor has to take one finding on faith, but they can verify the other line by line.

Greybox sits in between. The tester gets some insider context, which covers part of the internal attack surface, but blind spots remain wherever access wasn't granted.

This gap is most visible in cloud infrastructure. Attackers are actively exploiting misconfigured cloud IAM roles to hop from test accounts into production data, and that's a class of finding that's nearly impossible to surface, let alone document properly, in a blackbox engagement. You can't cite a misconfigured role you never had permission to look at.

The retest record as the most commonly missing piece of audit evidence

Picture an engineering team that fixed every single finding from last year's report. Every one. They walk into their SOC 2 audit confident, and the auditor asks for retest documentation. There isn't any. From the auditor's chair, none of those fixes happened, because nothing independently confirms them.

That gap happens for a mundane reason: most providers treat the report delivery as the finish line. The client patches things internally, calls it closed, and nobody on either side produces documentation confirming the fix actually holds against the original exploit technique. Without that confirmation, the finding stays open in the auditor's eyes. The fix might be logged somewhere internal, but the chain of evidence breaks at the very last link, the one that matters most.

A retest record that will actually hold up needs a specific set of things in it. The same finding identifier as the original report. The same tester or team, or a documented handoff that preserves methodology continuity. The same exploit technique run against the same target, now post-remediation. An explicit pass or fail result, something like "vulnerability no longer exploitable," backed by evidence such as an error returned, access denied, or a payload getting blocked. And the date, along with the version or deployment context of the system at the time it was retested.

This is the exact loop PCI DSS makes mandatory after significant change, and the same loop SOC 2 auditors look for under CC4.1 and CC7.1. Without it, a vulnerability that's genuinely fixed still sits on the books as an audit liability. A provider that treats the engagement as closed the moment the report ships pushes the client into commissioning an entirely separate engagement just to get retest documentation, and that gap delays audit readiness at exactly the moment it's least convenient.

What the finding record should look like for common vulnerability classes

Two vulnerability classes make the five-component structure concrete enough to actually recognize in a report.

Take SQL injection. Applications that build queries using unsanitized user input let attackers reshape how that query behaves, and it's common enough that cross-site scripting and SQL injection together made up a large share of all weaknesses recorded in the first half of 2025. A weak finding reads like this: "SQL injection vulnerability detected in login endpoint, severity: High". That's a sentence, not evidence. An audit-ready version names the specific endpoint, the exact unsanitized parameter, the payload used (say, a time-based blind injection that demonstrated a measurable database response), the data or table structure it revealed, a screenshot or output log, an assigned owner such as the backend team responsible for that service, a remediation note (parameterized queries went into commit X), and a retest result confirming the same payload returned no differential response after the fix.

Broken access control follows a similar shape but appears even more often. OWASP's 2025 data found broken access control present across every application assessed, making it the single most common finding class in modern web application testing. An audit-ready finding for this class names the specific role or account used to demonstrate the bypass, the exact resource accessed without authorization, and the request/response pair proving the access actually succeeded, along with what that access exposed in business terms. Retesting it is straightforward in principle, even if getting there takes discipline: re-run the exact same unauthorized request after remediation and confirm it now returns a 403, or whatever the equivalent enforcement response is for that system. If that response doesn't come back clean, the finding remains open. It just looks closed.