Pentest report version control
never ship the wrong PDF again

The first generation of the report from the live engagement record, before any reviewer or client has read it. Internal drafts iterate quickly as the test runs and findings land. The version exists so the engagement lead can see the report taking shape against the live findings rather than waiting until the test closes to discover that key evidence is missing or that the executive summary cannot reconstruct the test arc.

The draft after a peer reviewer has walked the findings, severity calls, and remediation guidance, with comments captured against the version. The reviewed draft is the gate to the client-issued version: nothing leaves the firm until a named reviewer has signed off on a specific reviewed-draft version with the comments either resolved or explicitly accepted.

The first version the client sees through the branded portal, with the engagement lead sign-off recorded against it. v1.0 is the version that anchors all subsequent revisions; if you need to defend what was issued to the client three months later, v1.0 is the artefact you point at.

A point-release reissue of the client-issued report for a typo, a clarification, an additional reviewer correction, or a small evidence update that does not change findings or severity. The reissue lands as a new version with a short change log and a fresh PDF cover so a forwarded copy is identifiable; the prior version remains accessible in version history rather than being silently overwritten.

A new major version of the same report after a retest cycle closes findings. v2.0 carries the closed-on-retest status, regressions logged during retest, findings carried forward unchanged, and any new findings opened during retest. The retest delta is a version of the same report rather than a separate document so the version history of the engagement reads as one continuous record.

A version that pairs an attestation letter with the underlying report, where compliance, customer procurement, or insurance asks for one. The attestation companion derives from the same versioned source as the report so the counts, the scope wording, and the retest verification on the letter cannot drift from the report it is attesting to.

The engagement lead emails the client a final report; the attached PDF is actually v0.3 instead of v1.0 because the file name was reused and the latest export landed in the same folder. The client either accepts the report without noticing or escalates because severity language reads differently than the debrief promised. Either outcome damages confidence and forces a re-issue that should never have been needed.

The senior reviewer comments on v0.2; the engagement lead opens v0.3 in parallel and adds comments there. The tester reconciles the two comment sets manually, drops one, and ships a v1.0 that resolves only half the review. The lost comment surfaces months later when the client raises the issue the missing reviewer caught.

A v1.1 reissue ships with no recorded change log. Three weeks later the client asks why a finding severity moved between v1.0 and v1.1; the only person who knows the answer is the tester who made the change, and the rationale lives in their head rather than against the version. The fix retroactively reconstructs the rationale, which always reads weaker than a contemporaneous note.

The retest closes findings; instead of generating a v2.0 of the original report, the team writes a separate retest report. The client now holds two PDFs that disagree on counts and status. The attestation letter, where one is required, picks one of the two as the source and contradicts the other. The reissue cycle that follows is more expensive than running version control would have been.

A reissue lands as a new file in the client portal alongside the old one without removing or marking the older version. The client downloads the older file (it is the first one in the list) and acts on outdated severity language. The fix is for the portal to surface a single live version with prior versions in a clearly labelled history rather than as parallel attachments.

The engagement file shows a final report and an issue date, with no record of which named reviewer signed off on which version. An auditor reading the file later cannot tell whether the report passed peer review before issue or whether sign-off was reconstructed retrospectively. The fix is recording reviewer comments and engagement lead approval against the specific version they apply to so the trail is provable rather than implied.

Every generation lands as a numbered version (v0.1 internal draft, v0.2 reviewer pass, v1.0 client-issued, v1.1 reissue, v2.0 retest delta) with a server-side timestamp and the named author. Numbers and timestamps live on the engagement record, not in the PDF file name.

A short note attached to each version explaining what moved since the previous one (added findings, severity recalibration, new evidence, scope expansion, contested-finding rewrite, retest delta, typo). The change log lets reviewers and auditors read the version history without diffing two PDFs by hand.

Comments from peer reviewers attach to the specific version they apply to, with status (open, resolved, accepted with rationale). Resolution lands on the next version so the audit trail records what changed in response to which review pass.

Engagement lead sign-off is recorded against the specific version that ships, with date and rationale. The question "who signed off the version we sent the client?" has one provable answer rather than a reconstructed one.

Every PDF export carries the version number on the cover page and footer so a forwarded copy is identifiable outside the portal. A stakeholder reading a forwarded PDF can tell at a glance whether they are looking at v1.0 or v1.1 without comparing file metadata.

The client portal shows a single live version with prior versions accessible in a labelled history, not as parallel attachments. The client cannot accidentally download an older version because the live version is the default; the history is one click away for anyone who needs to compare.

Version control depends on pentest quality assurance running the review pass that produces the reviewer comments scoped to a version. It feeds pentest report delivery because the version that ships is the one published in the portal, and retesting because retest deltas land as new versions rather than as separate documents.

Finding dispute resolution relies on versioned reports to show what was issued at the time of the dispute. Pentest evidence management keeps the screenshots and request captures attached to the findings each version references, so a v2.0 retest delta cannot lose the evidence base of v1.0.

The client portal shows one live version; the PDF cover and footer carry the version number; the engagement record stores the lineage. The path where a draft accidentally becomes the issued version simply does not exist because issue is a deliberate sign-off action against a specific version.

CREST, ISO 27001, SOC 2, PCI DSS, and client procurement reads can point at a specific version, see who approved it, what changed since the prior version, and which findings each version reflects. The deliverable trail is provable rather than implied.

v2.0 is a continuation of v1.0 on the same engagement. The client reads one report with a retest history rather than two PDFs that disagree on counts. The attestation companion, where one is required, derives from the same versioned source.

Typo fixes, clarifications, and evidence updates land as v1.1 with a recorded rationale. Forwarded PDFs are identifiable; prior versions remain accessible in the history. No silent overwrites of issued reports.