Proving What You Tested When a Client Asks

Here is an uncomfortable fact about our industry. 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. The only thing that distinguishes them is whether you can say what was actually exercised.

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 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 scanner 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.
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.

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

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.