Delivering Pentest Reports Without Emailing PDFs

Deliver a pentest report through an authenticated portal with named accounts, deliberate release and access you can withdraw, not as a PDF attached to an email. The deliverable is a structured, prioritised, reproducible list of every way into a client’s systems, and the industry standard for handing it over is still an attachment, occasionally with a password sent in a second email to the same inbox.

What goes wrong, specifically

• It multiplies. The recipient forwards it to two colleagues, one forwards it to an outside consultant, somebody puts it in a shared drive so the team can see it. Within a fortnight nobody knows how many copies exist or who holds them.
• It outlives its relevance. A findings list from two years ago is still a findings list. Half of it may still be accurate, and it will sit in inboxes indefinitely.
• It cannot be corrected. Issue a revision and the old one is still out there. Two people on the same call can be reading different versions and not know.
• It cannot be revoked. When somebody leaves the client, their copy leaves with them.
• You cannot answer the question. "Who has seen our report?" is a question you will eventually be asked. With email the honest answer is that you have no idea.

Password-protecting the file addresses almost none of this. It stops the mail server reading it, which was not the threat, and it adds a password to be forwarded alongside the document.

What clients have started asking for

Security teams have worked this out, and it is now turning up in the paperwork. The pattern of request is consistent:

They ask for	What they are really checking
A named list of who can access findings	That access is a decision somebody made rather than a side effect of a mailing list
Access that can be withdrawn	That a leaver stops being able to read it
A single current version	That there is one authoritative document rather than a family of them
Retention with an end date	That findings do not accumulate indefinitely on somebody else’s systems
Authentication with a second factor	That a stolen password does not open the map

Every one of those is straightforward with a delivery surface and impossible with an attachment. The retention row deserves its own answer, and how long a testing firm should keep client findings sets out how to give one.

The part nobody puts in the business case

The security argument is the one that gets a portal approved. The commercial argument is the one that makes it worth having.

When findings live somewhere the client signs into, that place becomes the record of your relationship. Every report you have released, every finding and its current state, every retest outcome. A year later, when their auditor wants evidence of testing or a customer asks whether they assess their applications, your client goes to a page with your name on it rather than searching their inbox, and often asks for an attestation letter an auditor will accept while they are there.

An attachment is delivered once and forgotten. A place they return to is a relationship they renew.

What a delivery surface has to get right

• Release is deliberate. Findings reach the client when you release them, not when you save them. Nobody should read a half-written finding.
• Access is per person. Named accounts, not a shared link and not a shared password.
• A second factor gates the data, and the check is recent rather than something that happened at enrolment.
• Questions land in context. A query about a finding should attach to that finding, not arrive as an email thread somebody has to reconcile.
• History persists. Past engagements stay available, because the value of the record is that it is complete.
• It looks like you. Your domain, your brand. A client should not be sent into somebody else’s product to read their own vulnerabilities.

It is worth walking through the surface as a client would before you switch it on. What your clients see is a useful checklist for that walk-through.

Corrections and the version of record

Every firm eventually has to correct a released report: a hostname transposed, a severity changed after a client supplied context, a finding withdrawn after a dispute. With attachments, a correction is a second file chasing the first, and the first one always wins because it was forwarded more widely.

A delivery surface turns this into a non-event, provided you treat it properly. Correct the finding where it lives, reissue the report, and say what changed and why in a short revision note, so a reader comparing versions does not have to diff two documents. Never edit silently. A client who notices a severity has moved without explanation will assume the worst about every other number, and their auditor will ask which version the remediation plan was based on.

Managing the transition

Clients who have received attachments for years will ask for one anyway. That is fine, and worth handling deliberately rather than by exception.

1. Make the portal the default for new engagements rather than trying to migrate everyone at once.
2. Say why in one sentence, framed around their control rather than your convenience: access you can withdraw, one current version, and a record their auditor can be pointed at.
3. Keep a signed-off PDF available for the clients who genuinely need one for their own document management. The point is not to abolish files, it is to stop the file being the only copy.
4. Invite the right people, not a generic address. Named accounts are what makes the rest of it true.
5. Agree retention up front, so the answer exists before somebody asks for it.

The firms that made this change describe the same outcome. The security argument opened the conversation, and the thing they would not now give up is that clients come back to a page with their name on it.