Release day
The report has passed QA. It is time to send it. Your operations coordinator exports the PDF, puts it in an encrypted archive, emails it to the client's contact and texts them the password. The client contact is on leave, so their colleague asks for it to be resent. The coordinator resends it, and texts the password to a new number they have been given by email.
A month later the client's managing director asks for a copy. Then their developer does. Then an external auditor. Each time, someone at your firm has to decide whether the person asking should have it, find the file, and go through the process again. Some clients simply forward the original email and password around their business.
Nobody at your firm could say, if asked, who has a copy of any given report.
Report delivery is the moment your client gets what they paid for. It is odd that it is also the least organised step in the whole engagement.
Why delivery is clumsy
- Email is the only channel everyone has, but it is not where you want a sensitive report to live.
- Password-by-another-channel depends on having a verified phone number for the right person.
- Requests for copies come from people you have not dealt with, and deciding who is entitled is left to whoever answers.
- Once a file is sent, it can be forwarded without any record.
- Reports, retest reports and certificates for the same client are sent separately, over time, and scattered.
What the current method costs
| Problem | Effect |
|---|---|
| Resending reports and passwords | Coordinator time on every engagement |
| No list of authorised recipients | Judgement calls about who gets a copy |
| No record of access | Cannot say who has the report |
| Clients forward the email | Report travels further than intended |
| Documents scattered over time | Client asks for 'everything from last year' |
Handling client reports carefully is part of what clients pay a security firm for. A delivery method that relies on text messages and forwarding does not reflect the care that went into the testing.
The delivery portal we build
- Each client has a list of named contacts who may receive reports, confirmed by the client's lead contact, who can add or remove people.
- Released reports are placed in the portal, and authorised contacts receive a notification that a document is ready. The report itself never travels by email.
- Contacts sign in with multi-factor authentication to view or download. You can choose whether a report can be downloaded or only viewed, and whether downloaded copies carry the recipient's name as a watermark.
- Access expires after a period you set, and can be extended by your team on request.
- Every view and download is recorded with the person and the time.
- The same portal holds retest reports, certificates, and, if you use one, the remediation tracker for that engagement, so the client has one place for everything.
We build it on your domain and your branding, using a secure file storage service such as Azure Blob Storage or Amazon S3 behind it, with access and retention designed with you.
What delivery looks like afterwards
Releasing a report is one step. Requests for copies are handled by pointing people to the portal, where the client's own lead decides who is on the list. Your firm can say exactly who has accessed a report and when. And the client finds last year's report, retest and certificate in one place when their auditor asks.
Consider the auditor request again. Instead of a new round of zip files and text messages, the client's lead adds the auditor as a contact with view-only access that expires in a month. The auditor signs in, reads the reports, and the record shows they did. Nobody at your firm had to be involved at all.
Is this how you deliver reports?
- Reports go out as encrypted zips with passwords sent separately.
- Your team resends reports and passwords regularly.
- Nobody decides consistently who may receive a copy.
- You cannot say who has accessed a report.
- Clients ask you to resend old reports for auditors.