Customer Data Leak: How to Respond and Notify Users and Regulators

The first hours: what to do

When customer data leaks, the order of actions matters more than speed alone. A short plan:

1. Contain the leak without destroying evidence.
2. Scope what data leaked, whose and how.
3. Assess legal duties and notify the regulator if required.
4. Inform affected customers with clear instructions.
5. Fix the root cause and document everything.

Appoint one incident lead immediately. Without a single owner, people duplicate work and send contradictory messages.

Step 1. Containment

• Close the hole: revoke leaked API keys and tokens, change passwords, block compromised accounts, restrict access to the affected server or bucket.
• If a database was publicly exposed, close public access first, then investigate.
• Preserve evidence: take snapshots of servers, export logs, record timestamps. Do not wipe or reinstall a server before copying what you need.
• Check whether attackers still have access: new admin accounts, unknown SSH keys, changed cron jobs.

Step 2. Scoping what leaked

Answer these questions in writing:

Use access logs, database query logs and cloud audit trails. If logs are missing, say so honestly and assume the worse scenario.

Step 3. Legal notification duties

Uzbekistan. The Law "On Personal Data" requires owners and operators of personal data to protect it and to cooperate with the authorized state body for personal data. The law also requires personal data of citizens of Uzbekistan to be processed and stored on servers physically located in the country. Notification rules and deadlines are updated over time, so confirm the current procedure with a lawyer at the very start of the incident and keep a record of when and how you informed the authorized body.

GDPR applies if you process data of people in the EU, for example by offering them goods or services:

• Notify the supervisory authority within 72 hours of becoming aware of the breach, unless it is unlikely to result in a risk to people's rights and freedoms. If not all facts are known, send what you have and add details later.
• Notify affected individuals without undue delay if the breach is likely to result in a high risk to them.
• Document every breach internally, even ones you did not have to report.
• A processor (for example, your hosting or development contractor) must inform the controller without undue delay.

Step 4. Communication templates

Write plainly, without downplaying. A customer message should contain:

• What happened and when.
• Which of their data was affected, and which was not.
• What you have already done.
• What they should do now: change the password, enable 2FA, watch for phishing calls and messages.
• A contact for questions.

Example opening:

On [date] we discovered unauthorized access to part of our customer database. Names, phone numbers and order history may have been exposed. Passwords and payment card data were not affected. We have closed the access and are working with specialists. We recommend that you be cautious with calls and messages asking for codes or personal data on our behalf.

Prepare a short internal version for staff and a script for support, so everyone gives the same answers.

Step 5. Preventing repeat incidents

• Run a post-incident review without searching for a scapegoat: what failed technically and in processes.
• Close the specific vulnerability and look for similar ones across other systems.
• Introduce least privilege, 2FA for staff, secrets management and log monitoring with alerts.
• Minimize data: do not store what you do not need, and delete old data on schedule.
• Write and rehearse an incident response plan with contacts of the lawyer, hosting provider and responsible people.