You have just learned that data from your application has escaped. A customer reports an odd email, a provider alerts you, or you discovered yourself that information was reachable without a password.
The hours that follow matter, and not only for technical reasons. Here is what the regulation expects of you, in what order, and what most companies overlook.
This text describes the general framework. On a real case, a specialist lawyer remains the person who qualifies the situation legally.
The clock starts when you become aware
The window is 72 hours to notify the French data protection authority, and it runs from the moment you learned of the breach, not from the date it happened. The procedure is set out on the CNIL site, with an online form.
Notification is not automatic: it applies where the breach is likely to create a risk to the rights and freedoms of the people concerned. An exposed list of email addresses presents a risk. A file of identity documents or health data presents a high one.
If you go past 72 hours, notification is still owed and has to come with the reasons for the delay.
What is required even without notification
A breach that does not warrant notification still has to be recorded in an internal breach register: what happened, which data, how many people, the likely consequences, the measures taken. That duty admits no exception.
The register serves two purposes. It shows you treated the incident seriously, which counts during an inspection. And it forces you to document while the facts are fresh, which nobody does spontaneously three weeks later.
When the individuals have to be told
Beyond notifying the authority, informing the people concerned is required where the breach presents a high risk to them. In practice: passwords, banking details, identity documents, sensitive information.
That communication has to be understandable, describing the nature of the breach, its likely consequences and what you did. It also has to say what the person can do on their side, changing a password reused elsewhere for instance.
Many companies dread this step. A frank, prompt communication is almost always received better than a discovery through a third party several months later.
The first four hours, in practice
Shut the door without destroying the evidence. The reflex is to fix things immediately. Close the access, but do not delete the logs, do not reset the servers, do not destroy what will let you establish the extent. Those elements are what determine how many people are affected, which shapes everything after.
Establish the scope. Which tables, which data, and over what period was access possible? On a generated application, database access logs often answer this.
Revoke the keys. If an access key was exposed, it stays valid until revoked, and nobody knows who picked it up.
Write down what you know and what you do not. Notification accepts partial information, completed afterwards. Waiting until you know everything is the surest way to miss the deadline.
Where these leaks come from on generated applications
The dominant cause is nothing sophisticated. It is a missing access rule that lets the database answer any correctly formed request. That defect is the leading application risk category according to OWASP.
In 2025 it produced a flaw catalogued as CVE-2025-48757, affecting applications built with Lovable: insufficient security policies allowed reading from and writing to tables with no authentication at all. More than 170 applications were affected, and severity was rated 9.3 out of 10.
Two other causes recur: a file storage area left public, where any document stays reachable by anyone who knows its address, and a secret key left in the code sent to the browser.
What comes afterwards
Once the incident is handled, the question becomes: can this happen elsewhere in the application? A missing access rule on one table is rarely missing on only one.
This is the moment for a full sweep, table by table, file by file. It is the same work that should have been done beforehand, except that it now happens under pressure and with a declared incident on the record.
The reactions that make things worse
Some instinctive responses cost more than the incident itself.
Waiting until you know everything. The clock runs while you investigate. A partial notification, completed later, beats a complete one filed late. The form explicitly accepts information in stages.
Cleaning up before assessing. Deleting logs, resetting a server, removing suspicious records: these destroy what would establish the extent. Without that assessment you can neither notify properly nor know who to warn.
Playing it down internally. “They are only email addresses” leads to declaring nothing, until a phishing campaign aimed at your customers traces back to you.
Communicating before understanding. Telling customers about a scope that later turns out to be wider damages trust more than the initial silence did.
Treating the symptom. Closing the access that leaked without checking whether the same defect exists elsewhere leaves the other doors open. A missing access rule on one table is rarely missing on only one.
What we do
We handle the technical side: establishing what was exposed and for how long, closing the access without destroying what documents the incident, and giving you the facts you need for the notification.
We then rework the application’s access rules as a whole, with a fixed quote on a scope you approve, and we verify the result through testing rather than telling you it is fixed.