Personal data leaked from your server? First steps and legal duties

Updated November 2026

If personal data on your server may have been seen, copied, changed or lost by someone who should not have it, stop the leak first and keep the evidence. Then find out what data and whose it was, because under the GDPR the organization responsible must usually notify the data protection authority within 72 hours of becoming aware, and must tell the people affected when the risk to them is high.

General information, not legal advice. This page summarizes the rules in plain words. Whether you must notify, whom and how depends on the facts and the law that applies to you. Get advice from your data protection officer (DPO) or a lawyer as early as you can; the deadline keeps running while you wait.

Do this first.

Close the hole: take the exposed file, database or endpoint offline, and change the passwords and keys that may be known to the attacker.
Do not wipe or rebuild yet. Archive logs and copies of the affected files somewhere safe.
Start a written timeline now: when you found out, what you saw, what you did, with times. The 72-hour clock may already be running.
Tell the person responsible for data protection (DPO, owner, management). If you host or run the system for a client, tell that client without delay; the duty to notify is theirs.

What counts as a breach

The GDPR defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data”. The European Data Protection Board (EDPB) groups breaches into three kinds:

Confidentiality: someone saw or copied data, for example a database dump downloadable from the web root, an open Elasticsearch or MongoDB port, or an attacker who stole the customer table.
Integrity: data was changed without permission.
Availability: data was lost or locked, for example by ransomware with no usable backup (Ransomware).

Step 1: contain the leak

# Database ports listening on all interfaces (should be 127.0.0.1 or a private network)
sudo ss -tlnp | grep -E ':(3306|5432|6379|9200|27017)\b'

# Dumps, backups and archives inside the web root
sudo find /var/www \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.dump' \
  -o -name '*.bak' -o -name '*.zip' -o -name '*.tar.gz' \) -ls

# Archive logs before rotation deletes them
sudo mkdir -p /root/evidence
sudo tar -czpf /root/evidence/logs-$(date +%F).tar.gz /var/log

Move exposed files out of the web root (do not delete them yet), bind databases to 127.0.0.1 or block their ports with the firewall, and rotate database passwords, API keys and application secrets. If the cause was an intrusion, follow Incident response and Leaked credentials. The US Federal Trade Commission’s breach guide adds: do not destroy evidence, and if personal data was posted on your website, remove it immediately and ask search engines and other sites to drop copies.

Step 2: work out what happened

You need rough answers fast, not a finished forensic report:

Which data: types (contact details, passwords, payment, health, ID documents) and whether it was encrypted or hashed.
Whose data, and roughly how many people and records.
When it started and when it stopped.
Whether it was actually accessed or copied, or only exposed.

# Was the exposed file downloaded, and by whom?
sudo zgrep -h 'backup.sql' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null

# Large responses in combined log format (field 9 = status, field 10 = bytes)
sudo zcat -f /var/log/nginx/access.log* | awk '$10 > 50000000 {print $1, $4, $7, $9, $10}'

Clean logs only help if they cover the whole exposure period. If logs are missing, assume the data may have been taken.

Article 33 requires the controller (the organization that decides why the data is processed) to notify the competent supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to people’s rights and freedoms. A late notification must give reasons for the delay.

When you become “aware”. The EDPB says it is when the controller has a reasonable degree of certainty that a security incident has compromised personal data. A short investigation to establish that is allowed, but it should start at once. Do not wait for a detailed forensic examination before assessing the risk.
What to include (Art. 33(3)): the nature of the breach, including categories and approximate numbers of people and records; a contact point such as the DPO; the likely consequences; and the measures taken or planned.
In phases. If you do not have everything, send what you have and add the rest later without further undue delay (Art. 33(4)). The EDPB says missing exact numbers should not hold up a notification.
Processors. A hosting company, agency or freelancer running the system for someone else must inform the controller without undue delay (Art. 33(2)).
Which authority. Supervisory authorities have online notification forms. For cross-border processing, the EDPB says to notify the lead authority or, at a minimum, the local one where the breach took place.

The GDPR’s two thresholds: “risk” for the authority, “high risk” for the people affected. Every breach goes in the register.

Step 4: inform the people (Art. 34)

When a breach is likely to result in a high risk to people’s rights and freedoms, the controller must also tell them without undue delay, in clear and plain language: what happened, a contact point, the likely consequences and what has been done. Article 34(3) lists three exceptions: the data was protected so that it is unintelligible to others (for example strong encryption with the key not compromised); later measures mean the high risk is no longer likely; or individual messages would take disproportionate effort, in which case a public announcement must be used instead. The authority can still order you to inform people.

The EDPB advises dedicated messages (email, SMS, a website banner), not a line in a newsletter, and not through a channel the breach compromised. Give practical advice, such as changing a reused password or watching for phishing that uses the leaked details. Law enforcement may ask you to delay telling people if it would harm an investigation; notify them as soon as that reason ends.

Step 5: keep records

Article 33(5) requires the controller to document every personal data breach, including ones it does not report: the facts, the effects and the remedial action, so the authority can check compliance. A simple register entry covers:

Date and time of the breach, of discovery, and of each notification.
What happened, which systems, which data and how many people.
Your risk assessment and, if you did not notify, why.
Actions taken to contain it and prevent a repeat.

Outside the EU

United Kingdom: the UK GDPR keeps the same 72-hour rule; the authority is the Information Commissioner’s Office (ICO).
United States: the FTC notes that all states, the District of Columbia, Puerto Rico and the Virgin Islands have breach notification laws, and federal rules such as HIPAA or the FTC’s Health Breach Notification Rule may apply. Which law applies usually depends on where the affected people live. The FTC also advises contacting law enforcement.
Elsewhere: many countries have their own rules, with different thresholds, deadlines and authorities. Sector rules (payments, health, telecoms) and contracts can add duties. Check every jurisdiction where affected people live.

If the breach came from a crime, report it to the police as well; the EDPB points to Europol’s list of national reporting procedures in the EU.

Confirm it is contained

The exposed file, port or endpoint is no longer reachable from outside (test from another network).
All exposed passwords, keys and tokens have been changed.
The way in has been closed and patched.
Notifications, if required, have been sent and the register entry is complete.

Prevent it

Never keep dumps or backups in the web root; store backups encrypted and off the server.
Bind databases to localhost or a private network and require authentication (MySQL and MariaDB, MongoDB and Elasticsearch).
Keep only the personal data you need, and delete old exports.
Keep logs long enough to answer “was it downloaded?” (Logging and monitoring).

When to get help

Involve a lawyer or your DPO before you decide not to notify, whenever special categories of data (health, for example), payment data, passwords or large numbers of people are involved, or when people in several countries are affected. Call a forensic firm or your cyber insurer if you cannot tell what was taken.