Handling Pentest Evidence and Client Credentials Safely

Handle pentest evidence and client credentials as the most sensitive material your client owns: accounts created for the engagement and disabled on the end date, evidence kept in one controlled place and redacted at capture, tool output treated as evidence, and a disposal rule that actually runs. During an engagement a testing firm holds working credentials, network diagrams, screenshots of live customer data and a written list of the fastest ways into the business, and clients have started noticing.

None of what follows is novel. It is the discipline you are paid to assess, applied to yourself, which is a harder sell internally than it should be.

Credentials with an expiry from the moment they are issued

Ask for accounts created for the engagement rather than existing accounts shared with you, and ask for them to be disabled on the end date rather than at some later tidy-up that never happens.

Where a client insists on sharing an existing account, note it in the report. It is a finding about their process even when it never becomes one about their systems, and writing it down protects both of you if that account is later implicated in something.

The end date is the end of testing, not the report date. In practice test access frequently outlives the engagement by months, because revoking it is nobody's task and the account is not in anybody's joiners and leavers process. Ask for revocation explicitly at the end, in writing, and record that you asked. It protects the client, and it protects you from being the plausible explanation the next time something happens on their estate.

Do not let evidence live in two places

The common failure is not dramatic. It is a screenshot folder on a tester's desktop, a copy pasted into a channel so a colleague could look at it, and a third in a report draft, one of which never gets cleaned up.

Attach evidence to the engagement record once, and remove the local copy when the finding is written. The rule is easy to state and it only works if the primary location is genuinely convenient, which is worth spending money on.

Redact at capture time

Redacting later means holding the unredacted version in the meantime, and the unredacted version is the one that ends up in the archive. Review time is also deadline time, which is when a redaction pass gets shortened. Capture the smallest region that proves the point. Where a demonstration genuinely needs real customer data, capture one record rather than a page of them, and say in the finding that you did so deliberately. Evidence that survives peer review covers how to keep enough to prove the point.

Redaction that is actually redaction

Black boxes drawn in an image editor and flattened are fine. Black boxes drawn over live text in a document that keeps the text underneath are not, and neither is blurring, which has been reversed often enough to be a bad idea. Flatten the image, then check the flattened file.

Tool output is evidence, not scratch

Output from automated tools, proxy history and traffic captures is frequently more sensitive than the report, because it is complete rather than curated. A proxy log from an authenticated session routinely contains session tokens, personal data and internal hostnames in one file that nobody has read end to end.

It deserves the same storage, the same access control and the same disposal date as everything else, and it should never be attached to an email.

Decide retention, then make disposal run

Evidence accumulates by default. Screenshots of live records, recovered credentials, database extracts and request logs sit wherever they were first saved, and the decision to keep them is never taken, it just happens. Two questions decide most of it: how long do you need the evidence to defend a finding a client disputes, and how long does your contract say you may hold it? Where those disagree, the contract wins. How long a testing firm should keep client findings works through the periods in more detail.

1. Decide the period. How long you hold evidence after delivery, written into the engagement contract rather than assumed.
2. Attach deletion to closing. Make it a step in closing an engagement, not an annual clean-up that gets deferred every year.
3. Separate report retention from evidence retention. Professional obligations usually require the report for longer than the evidence needs to exist.
4. Know what a client can demand. And be able to do it without a week of archaeology across three storage systems.

The laptop is in scope

Full disk encryption, a screen lock measured in minutes, no shared local accounts, no personal machines, and a plan for a stolen device that does not begin with "we would tell the client and hope".

A supplier assessment will ask about all of this. Being able to answer without qualification is worth more in procurement than most certification logos, and it costs a weekend to get right.

Where the evidence actually lives

Most of the discipline above is about handling. The question underneath it is custody: whose infrastructure holds the material, and who could read it if they wanted to. For a testing firm this is not an abstract question, because it is the one your clients are increasingly asking you. Three answers exist and they are not equivalent.

Arrangement	Who could read a finding
A shared platform holding every customer in one database	Your staff, plus the vendor's staff, plus anyone who gets a tenant filter wrong.
Files on your own drives and a folder structure	Your staff, subject to whatever your file permissions actually are rather than what you think they are.
A database in your own account, with access decided by the database	Your staff, under rules enforced on every query rather than by the application remembering to ask.

Whichever you run, be able to describe it precisely. The firms that answer supplier assessments quickly are the ones whose answer is a mechanism rather than an intention.

Assume you will be assessed

The firms winning larger accounts are the ones that can describe their own handling as precisely as they describe their clients' weaknesses.

Write it down once, keep it true, and the questionnaire stops being a week of work every time one lands. Keeping it true is the hard part, and it is the part that makes the document worth anything. Answering a security questionnaire about your pentest platform shows what the finished answers look like.