Data breach: what to do in the first 72 hours, and how to prevent it

Monday morning. Someone from support reports that something strange is going on in the system: requests from unknown addresses, accounts nobody recognises, traffic at three in the morning. Within a few hours it is clear that someone has access they shouldn’t have.

At that moment, nobody asks who it was. Everybody asks the same thing: what did they see?

The clock starts ticking at once

If personal data of customers or users is involved, GDPR requires you to report the breach to your data protection authority without undue delay and no later than 72 hours after you became aware of it. If the risk to people is high, you have to tell them too.

To do that, you need the answer to three questions: what data the attacker could reach, what they actually reached, and whether they are still inside. If you don’t know, the only honest thing to do is assume the worst: that they saw everything. And “everything” means writing to all your customers.

The difference between “they saw ten records” and “we had to notify every customer” isn’t decided on the day of the attack. It is decided months earlier, in the way the application was built.

The holes attackers really use

Attacks on business applications rarely look like the movies. Most of the time they don’t take any genius, just a way in through a door someone left open:

• Passwords stored as plain text. Whoever gets to the database has every password. And users reuse those passwords for their email and bank, so the leak doesn’t end with you. Passwords are never stored, only a fingerprint of them from which the password can’t be recovered.
• The application sends more than the screen shows. The screen shows a name and an email, but behind it the application sends the whole record, with fields nobody sees unless they look. Attackers always look.
• Someone else’s data by changing a number. Change the order number in the address and you see someone else’s order. It sounds too simple to be true, yet broken access control sits at the top of OWASP’s list of the most common security risks for web applications.
• Unlimited attempts. Without a limit, an attacker can try passwords or numbers thousands of times a minute until something works.
• Open self-registration. If anybody can sign up, the attacker doesn’t need to break in. They open an account and look at everything a user can fetch from the inside.
• Admin pages reachable from the whole internet. An interface five people in the company need, and anybody in the world can get to.
• Logs that show nothing. The application records errors, but not who fetched what. On the day of an incident, that is the difference between an answer and a guess.

When it happens: the order

1. Close the doorCut off access, rotate the keys
2. Find out what was seenFrom the logs, not by guessing
3. NotifyThe authority and, if needed, people
4. Fix the causesSo it doesn't happen again

1. Close the door. Cut off access that shouldn’t exist: disable the suspicious accounts, change the passwords, keys and tokens the attacker could have seen. Quickly, but without wiping the traces.
2. Find out what was seen. Use the logs to reconstruct what the attacker did, what data they reached and since when. This step decides everything else.
3. Notify. The authority within the deadline, and the people affected when the risk is high. Clearly and honestly: what happened, which data was affected and what you are doing about it.
4. Fix the causes. Not just the hole they came through, but every similar one. An attacker who found one open door certainly tried the others.

10 questions you can ask your team today

You don’t need to know how to code to ask them. You only need to insist on a clear answer:

1. How do we store user passwords? The right answer: as a fingerprint (hash), never as text.
2. Does the application return only the data the screen actually needs?
3. Does the application check on every request whether this user may see this particular record?
4. How many login attempts do we allow before blocking?
5. Can anyone sign up, and what can they see after that?
6. Who can get to the admin pages, and from where?
7. Do administrators log in with two-step verification?
8. If someone got in tomorrow, would our logs tell us what they saw? How long do we keep logs?
9. When did we last update libraries with known vulnerabilities?
10. Who is responsible if an incident happens at three in the morning, and do they know what to do?

If you get “I don’t know” or “it should be fine” to more than two of these, you know where to start.

How we work

ProCoding is a .NET studio from Split, Croatia. We do security reviews of business applications built on .NET, ASP.NET Core, Blazor and SQL Server. We go through the code, the APIs, login and permissions, the logs and the configuration, and you get a list of holes ranked by risk, with a proposed fix for each.

And when an incident has already happened, we help with what is most urgent: closing the door, using the logs to find out what the attacker saw, and fixing the causes. The first step is a free 30-minute call.

Sources

• General Data Protection Regulation (GDPR), Articles 33 and 34, EUR-Lex
• OWASP Top 10:2025, OWASP Foundation