A customer database leak: the order of actions

A customer database leaves quietly: a CRM export, an open file, an old backup in a public cloud, a hole in an API. Panic at that moment hurts twice. You can wipe the logs, and you can promise customers something you have not checked yet. Below is an order of work, not a legal memo. Deadlines and the form of notice to the regulator and to people have to be checked with a lawyer and with the data protection law of your country (GDPR in the EU), not with a blog.

What to do before any public text

• Stop further export: close the hole, revoke the key, take down the public link.
• Keep the logs. Who exported, when, from where. Without that you do not know the scale.
• Understand the contents: phones, email, passwords, orders, documents. The text depends on the contents.
• If the database held passwords, they need a reset, even if they were not in clear text. People reuse passwords on their own.
• Name one speaker. Five versions in chats are worse than one careful version.

Customers are told what is already known: what happened, which data is affected, what they should do (change a password if it might have been reused), where to write. The sentence "the attacker did not get the data" should not be published until it has been checked. It is later read as a lie, even if you were only in a hurry.

Lexora takes the technical part: find how the data left, close the entry, check neighbouring planes. The notice text and the decision of whom exactly to inform stay with your company and your lawyer. We do not replace that with a "message template".