What makes a physical pentest report defensible to auditors

Traceable evidence, framework mapping, reproducible findings · 2026

A physical pentest report rarely stops at the client's security team. It travels on to auditors, to a board, to an insurer, sometimes to a regulator. This guide sets out what makes such a report stand up to that scrutiny: traceable evidence, mapping to recognised frameworks, and findings another tester could reproduce.

What "defensible" means

A report is defensible when it survives a reader who is paid to be sceptical. For a physical security assessment that reader is usually an auditor, working through an ISO 27001 surveillance visit, a NIS2 obligation, an insurance review, or an IEC 62443 assessment of an operational site. They are not interested in the story of how the team got in. They test four things, and a report that cannot answer them gets discounted:

• Is the evidence real, and can it be shown not to have been altered.
• Can each finding be traced back to a specific piece of evidence.
• Does each finding map to a control the organisation is actually measured against.
• Could a competent third party reproduce the finding from what is written.

A polished narrative PDF that says the team cloned a badge and reached the server room fails all four. It is a claim, not a record.

Traceable evidence

The first thing an auditor pulls on is the link between a claim and its proof. In a defensible report, every finding is tied to the exact capture file behind it, and that file carries a SHA-256 custody record with its own evidence identifier. The auditor can follow a finding down to a specific artefact, see the digest recorded for it, and re-verify that digest independently. This is the difference between "the report asserts a clonable badge" and "the report points at capture VP-2026-0042, whose hash the auditor just reproduced with sha256sum". The detail of how that integrity is established is covered in the chain-of-custody and capture-integrity guides. For the report, the point is that traceability is built in, finding by finding, rather than reconstructed afterwards from memory.

Mapping to frameworks the auditor already uses

An auditor does not think in findings. They think in controls. A finding that is not connected to the framework they are assessing against is, to them, an orphan. A defensible report does the mapping for them, the same way every time, for each finding. Vaultprobe maps each finding to the standards a UK and EU assessor is most likely to be held to:

• ISO 27001:2022 Annex A. Each finding subtype is mapped to the relevant Annex A control, so a clonable access credential lands against the physical and access-control clauses an ISO auditor is checking.
• NIS2 Article 21(2). Findings map to the specific risk-management measures named in the directive, which matters for the essential and important entities now in scope.
• IEC 62443-3-3. For physical-access and credential findings on operational sites, such as NFC and RFID badge cloning, Sub-GHz replay against gates and barriers, and iButton contact keys, findings map to the relevant system security requirements, the language an OT or ICS assessor works in.

Because the mapping is done per finding subtype and applied consistently, it stays the same across reports and across testers, rather than depending on whoever wrote the document remembering which control applies. An auditor can read from a finding straight to the clause they are signing off, which is the single thing that makes a pentest report useful to them rather than merely interesting.

Reproducible findings

The last test an auditor applies is whether the finding stands on its own, or only inside the tester's head. Reproducibility in a report means recording enough that someone else could understand and re-check the finding without a phone call: the hardware and capture behind it, the identified device or vendor where fingerprinting applies, and a reference to the underlying weakness rather than just an adjective like "critical". Vaultprobe attaches a citation to each finding from a built-in library that ties the weakness to a CVE and to primary sources, including NIST, IEC, ETSI, CISA, and academic literature, printed in an appendix the reader can check without coming back with a question.

Output the auditor's tools can read

Defensibility is partly about the human reader and partly about the systems behind them. Alongside the PDF, Vaultprobe emits structured JSON and NIST OSCAL 1.1.2 assessment-results output, so findings can be ingested into the GRC and compliance platforms an auditor or a larger client already runs, rather than retyped. The report a person reads and the data a system ingests come from the same evidence, so they cannot drift apart.

What a defensible report does not do

It is worth being clear about the boundary. A report is made defensible by traceable evidence, consistent framework mapping, and reproducible findings. It is not made defensible by the vendor's badges. Vaultprobe does not stand in for a certification the testing firm does not hold, and it does not assert one. What it does is make the firm's own work checkable: every finding anchored to verifiable evidence, mapped to a control, and backed by a source. That is what an auditor can actually sign against.