Proving What You Tested When a Client Asks

To prove what you tested, keep a coverage list for each phase, written during the work rather than afterwards, at a level of detail between "we tested the application" and "we sent this request", and put it in the report. From the client’s side, a thorough test that found nothing and a superficial test that missed everything produce the same artefact, a report with no critical findings, and only the coverage record tells them apart.

That question is being asked more often, and not by the technical contact. It comes from procurement, from auditors, and increasingly from a client’s own customers, who want to know that the assessment behind an attestation was more than a vulnerability scan.

Why "we follow the standard" is not an answer

Naming a methodology tells a reviewer what you intended to do. It does not tell them what happened on this engagement, on those dates, against that application. Two firms can name the same standard and deliver work that differs by a factor of five in depth.

The gap matters most exactly when there is nothing to show for the work. A report full of critical findings speaks for itself. A clean report is the one that needs evidence of coverage, and it is the one where firms most often have none.

What coverage evidence actually looks like

It is narrower than people fear. Nobody wants a transcript. What a reviewer wants is a list of the things that should have been checked and confirmation that they were, at a level of granularity somewhere between "we tested the application" and "we sent this specific request".

Too vague	About right	Too granular
Authentication was tested	Password policy, lockout behaviour, session fixation, second-factor bypass and reset flows were each exercised	Every individual request sent against the login endpoint
Access control was reviewed	Horizontal and vertical checks across the four defined roles, on all administrative functions	A matrix of every endpoint against every role
The infrastructure was assessed	Service enumeration, version identification, default credential checks and patch-level review on all in-scope hosts	Raw tool output

Making it a by-product rather than paperwork

The reason coverage tracking fails is always the same: it is done afterwards. A tester who has finished the work and is asked to fill in a coverage document will produce something accurate in outline and invented in detail, because they are reconstructing rather than recording.

It only works when ticking is part of doing. Which means the list has to be in front of the tester during the engagement, attached to the phase they are working on, short enough to be read, and specific enough to be worth reading.

1. Write the list per assessment type, not per engagement. A web application checklist, an internal infrastructure checklist. Reused, so improving one improves every future engagement; a web application penetration testing checklist is a reasonable starting point to adapt.
2. Keep it to what must be covered. Twenty meaningful items beat two hundred that get ticked in a block at the end.
3. Separate the how from the what. A checklist says what must be covered. A runbook says how your firm does a particular procedure. Conflating them makes both unusable.
4. Attach it to the phase. An internal phase and a web phase carry different lists, and a multi-phase engagement should show coverage per phase.
5. Review it at handover, not at delivery. An unticked item found during review is still testable. Found at delivery, it is an awkward conversation, and the same list is what makes handing over a penetration test mid-engagement cost an hour rather than a day.

A coverage list written during the work is evidence. The same list written afterwards is a memory with ticks on it.

Answering the question months later

The question rarely arrives during the engagement. It arrives six months on, from somebody who was not involved, usually after something has happened: "did your test cover the export function?" How you answer that is a test of the record, not of your memory.

Look it up rather than recall it. Then answer in one of three ways, and only three. Tested, with the date and the phase, and what was tried. Not tested, and why: out of scope, not reached in the time available, blocked by access. Or in scope but not on the list, which is the honest answer when it is the true one, and a prompt to fix the list. What you never do is reconstruct coverage from memory, or imply an area was exercised because the report says nothing about it. A precise "not tested, because" protects the client's decisions and your firm's credibility; a vague reassurance protects neither, and unravels at exactly the moment it is relied on.

What to do with it commercially

Most firms treat coverage as a defensive artefact, produced when challenged. The firms that do best with it treat it as part of the deliverable.

• Show it in the report. An appendix listing what was covered turns a clean result from an anticlimax into a demonstration.
• Show it during the engagement. A client watching coverage progress is a client who can see they are getting what they paid for.
• Use it in scoping. Handing a prospect the list of what a phase covers is a far better answer to "what do we get" than a day count.
• Use it in review. Coverage gaps found at review are the cheapest defects your QA process will ever catch.

The uncomfortable fact at the top does not go away. The best you can do is make the difference visible, which happens to be the same thing as making it easier to do the work well.