A test finds a flaw that would have exposed customer data. Nothing suggests anybody used it, and your contract requires notification of security issues affecting the customer. The instinct is to fix it quietly and say nothing. That instinct is understandable and it is usually the wrong call, because the question you will be asked later is not whether you fixed it but when you knew.
A vulnerability is not automatically a breach
Under UK GDPR a personal data breach requires an actual breach of security leading to unauthorised access, loss or disclosure. A flaw that could have permitted access, with no evidence it did, is generally not notifiable to the Information Commissioner’s Office on its own. The distinction matters and it depends entirely on your evidence: if logging is thin enough that you cannot rule out exploitation, the position shifts, which is one of the practical reasons application logging pays for itself. Document the reasoning either way, because the accountability principle expects you to show how you decided.
When customers should be told
Three triggers cover most cases. The contract requires it, which is increasingly common in enterprise agreements. There is evidence, or a real possibility, that their data was accessible to somebody outside your organisation. Or the customer needs to act, for example by rotating a credential they hold or checking their own logs. Where none of those apply and the flaw is fixed, a note in your next security update is usually proportionate. Where any of them apply, tell them promptly rather than after remediation completes.
“Say what you know, what you do not know yet, and what you are doing about it, then give a date for the next update and keep it. Customers accept problems and they do not accept discovering that you sat on one for a month. I have seen a well handled disclosure strengthen a relationship, and I have never seen concealment survive contact with a later audit.”
William Fieldhouse, Director, Aardwolf Security Ltd
What the message should contain
Keep it factual and short. What was found, in language a non-technical reader understands. What data or systems were potentially affected. What evidence you have about whether it was exploited. What you have done and by when the fix will be complete. What, if anything, the customer needs to do. Who to contact for more detail. Send it from a named person with authority rather than from a general mailbox, and brief your support team beforehand so the first customer to reply is not met with confusion.
Handling the follow-up
Expect requests for evidence and be ready with a retest result rather than a promise. A short attestation confirming the finding was remediated and independently verified closes most conversations, and it is far better than sending the original report. Where a customer escalates, offer a call with the person who ran the remediation. If you need help preparing that evidence, an accredited penetration testing team can produce a verification letter, and it is worth talking to us about testing and remediation before the disclosure rather than while a customer is waiting.
Frequently asked questions about disclosing findings
These questions come up whenever a serious finding lands in a report.
Should you tell customers about every finding?
No. Routine findings fixed in the normal cycle are part of running a service. Reserve customer communication for issues affecting their data, requiring action from them, or covered by a contractual notification clause.
Does telling customers create legal risk?
Take advice on the wording where the finding is significant. Concealment carries considerably more risk, particularly where a contract obliges disclosure or where a regulator later reviews what you knew and when.
