After the report goes out
The report is delivered: a PDF with an executive summary, a list of findings rated by severity, and remediation guidance for each one. The client's IT manager thanks you and says they will get on with it. Then the report disappears into their world. Findings are copied into a spreadsheet, some into their developers' Jira board, some into an email to their hosting provider.
Three months later the client emails: they think they have fixed everything, can you retest next week? Your account manager asks which findings. The client sends back a spreadsheet with their own numbering, some rows merged, some marked 'done' with no detail, and a note that one finding 'was not applicable'. Your tester spends the first morning of the retest working out what the client actually did.
In between, the client's developers had questions about two findings and emailed the tester directly. The tester answered, but the answers are in their inbox, not on any record.
Meanwhile your firm has no idea which clients are making progress and which have not touched their report, which is exactly the information that would tell you who needs a nudge and who is ready for a retest.
Why remediation goes dark
- The report is a static document, so the moment it is delivered, its status is frozen.
- Clients track remediation in their own tools, with their own numbering, and your firm cannot see them.
- Questions about findings go to whoever the client knows, by email, and answers are not recorded against the finding.
- Risk acceptance decisions ('we will not fix this') are made by the client but not documented in a way your retest can rely on.
- Retest requests arrive without a clear list of what changed.
The client owns the fixing. Your firm owns the findings and the retest. The gap between the two is where time and clarity get lost.
What the gap costs your firm
| Gap | Cost |
|---|---|
| No visibility of progress | Retests booked too early or not at all |
| Client's numbering differs from yours | Retest time spent reconciling lists |
| Answers to client questions not recorded | Same question answered twice, inconsistently |
| Risk acceptance undocumented | Arguments at retest about what was in scope |
| No follow-up after the report | Client drifts, next year's test goes elsewhere |
The shared findings tracker we build
- Findings are taken straight from your reporting platform (by API from tools such as Dradis or PlexTrac, or from your report export) so each one keeps your reference, severity and description.
- The client gets access to a tracker for their engagement. They can assign each finding to someone on their side, add notes, set their own target dates, and change the status: open, in progress, fixed and ready for retest, or risk accepted.
- Risk acceptance requires a reason and the name of the person accepting it on the client side, recorded against the finding.
- Clients can ask a question on a finding. It goes to the tester who wrote it, and the answer is stored on the finding for everyone to see.
- Where the client wants it, findings can be pushed into their own ticketing system (for example Jira or ServiceNow) with a link back, so their developers do not work in two places.
- Your account manager sees progress across all clients: who has started, who is stalled, and who is ready for a retest. Gentle reminders go to stalled clients on a schedule you choose.
Access is limited to named people at the client and your own team, and the tracker holds only what is needed to manage remediation. We design storage and access with you, given how sensitive findings are.
What your team sees afterwards
Account managers know which clients need a nudge and which are ready to book a retest. Testers see questions against the finding they wrote, with context, instead of stray emails. Retest requests come with a clear list of findings marked fixed, in your own numbering, and risk-accepted items are documented before anyone arrives.
Clients benefit too. Their IT manager can show their board progress against the report without building their own spreadsheet, and next year's test starts from a clean record of what was found and fixed.
Is this how remediation runs for you?
- You have no idea what clients have fixed until they ask for a retest.
- Retests start with reconciling the client's list against your report.
- Client questions about findings arrive in testers' personal inboxes.
- Risk acceptance decisions are not recorded.
- Clients go quiet after the report, and some do not come back.