A GDPR breach in a small SaaS: what a personal data breach makes you report, to whom, and within how long

Write down the time you became aware, because under Article 33 of the GDPR the 72 hours to notify the supervisory authority run from that moment, not from when the intrusion began. A GDPR breach then asks a small SaaS for three decisions inside that window: is it reportable, are you the controller or the processor, and must the people affected be told.

GDPR breach: what to do right now, in order

A GDPR breach response has 7 steps in the first 72 hours: record when you became aware, contain it, preserve the logs, work out whose data and which fields, decide whether you are controller or processor, assess the risk to those people, then notify or document the decision not to.

This page explains what the law asks of the company; it is not legal advice, and a breach that looks reportable is the point to bring in a data protection lawyer.

The breach decision is the one part of how to manage SaaS data compliance that comes with a deadline. The EU GDPR’s list of definitions in Article 4 does not define “aware”, so the clock question comes first. The EDPB’s guidelines on breach notification fill the gap: a controller “should be regarded as having become ‘aware’ when that controller has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised”. A short investigation to establish that is allowed, and during it you “may not be regarded as being ‘aware’”, but the board expects it to “begin as soon as possible”.

1. 01 Record the date and time you became aware, and how you found out. Keep the alert, email or message that told you, and the name of whoever saw it first.
2. 02 Contain it without destroying evidence: close the open policy, rotate the leaked key, take the export link down. Keep a note of each change, when it was made and by whom.
3. 03 Preserve logs and a copy of the affected configuration before you change anything else. Keep the exported database, API and hosting logs for the period, and the policy or setting as it stood.
4. 04 Scope it: which tables and fields, whose records, how many people, and for how long. Keep the queries you ran and the counts they returned.
5. 05 Decide your role for that data, controller or processor. Keep one line saying which, and why.
6. 06 Assess the risk to the people concerned: what the data is, how sensitive, how many people, how easily they can be identified, and what could happen to them. Keep the assessment and the name of the person who made it.
7. 07 Notify the authority or record the decision not to, and open the breach register entry either way. Keep the notification reference, or the written reasons for not notifying.

The technical half of steps 2 and 3, containing an incident without erasing what happened, is the subject of what to do when a vibe-coded app is hacked. Step 4 is quickest when a GDPR data map already lists each kind of personal data, the table it lives in and the vendors that touch it. Who does which step when the company is two people belongs in an incident response plan template, written before you need it.

What counts as a GDPR personal data breach, and what does not

A personal data breach under GDPR Article 4(12) is “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data”. Regulators sort it into 3 types: confidentiality, integrity and availability. A lost laptop or an email sent to the wrong person counts, not only an attack.

The General Data Protection Regulation judges a breach by what happened to the data, not by who caused it or whether anyone meant it. The EDPB’s three types, in its own words: a confidentiality breach is “an unauthorised or accidental disclosure of, or access to, personal data”, an integrity breach is “an unauthorised or accidental alteration of personal data”, and an availability breach is “an accidental or unauthorised loss of access to, or destruction of, personal data”. One incident can be all three at once. The ICO’s guide for the UK uses the same three words for the same idea.

So the GDPR data breach definition is wider than “we got hacked”. The table below applies it to incidents a small SaaS actually has. Each row is my illustration of how the definition reads, not a ruling on anyone’s incident.

The first row comes from a real audit. In a food-delivery app I audited, a notifications table added after the rest of the schema never had row level security switched on, so the public key in the browser could list or delete the whole table; the full telling is under a table added after the rest of the schema. My reading is that a table like that is the condition for a confidentiality breach and an availability breach at once, and whether either happened is what the logs have to show.

My June and July 2026 audits covered 21 third-party apps, and 7 of them had confirmed cross-user or cross-tenant authorization failures, where a logged-in user could read or write another customer’s data. In the same audits, 11 of the 21 third-party apps had unauthenticated endpoints doing privileged work. Those 21 apps are a selected set rather than a random sample, so the figures are no rate for AI-built apps in general, and a condition is not a breach: neither number says anyone’s data was taken.

The same test applies when the incident starts somewhere else. When a builder platform reports an exposure, every app owner on it has to run it for their own data, as with the Lovable data breach and whether your app was exposed. The reporting duties start in Article 33 of the GDPR as adopted, and the next two sections work through them.

People also say a company is breaching GDPR when it has no lawful basis for its marketing emails or ignores a deletion request. That is a breach of GDPR in the sense of an infringement, and it starts no 72-hour clock. Those general duties are set out in GDPR for a small SaaS; this page stays with a personal data breach.

Why this happens: deciding whether it is reportable, and who the controller is

A breach is reportable to the supervisory authority under Article 33 unless it is unlikely to result in a risk to the rights and freedoms of natural persons, and the deadline is without undue delay and, where feasible, 72 hours after becoming aware. Every breach, reportable or not, goes in your own register with its facts, effects and remedial action.

Everything else on this page follows from that test. The GDPR breach notification requirement has a second sentence for when the deadline slips: “Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”

Risk here means risk to the people, not to the company. The EDPB asks for both “the likelihood and severity of the risk” and lists what to weigh, among them “The type of breach”, “The nature, sensitivity, and volume of personal data”, “Ease of identification of individuals”, “Severity of consequences for individuals”, “Special characteristics of the individual” and “The number of affected individuals”.

Applied to versions of the incidents above, each with one fact that changes the answer, the decisions usually fall like this. Every row is an illustration, not a ruling; your own facts decide.

The encrypted-laptop row carries conditions. The EDPB’s example holds only if the key “was not compromised in any security breach”, the data were made “essentially unintelligible to unauthorised parties”, and “a copy or a backup exists”; “if the key is subsequently found to be compromised”, notification “may still be required”.

Breach notification under GDPR also depends on your role for the data involved. For your own users’ account data you are usually the controller, and the notice to the authority is yours. For data your customers put into your product about their own customers, you are usually their processor, and EU GDPR Article 33(2) gives you a different duty: “The processor shall notify the controller without undue delay after becoming aware of a personal data breach.” A processor does not need to assess the risk first; the EDPB says “it is the controller that must make this assessment”. Under the same guidelines, the contract, the data processing agreement, “should specify how the requirements expressed in Article 33(2) should be met”. What a DPA agreement is, and what it should say about breaches, is a topic of its own. If one incident hits several of your customers, the EDPB says a processor “will have to report details of the incident to each controller”. Which role you hold for each kind of data is a wider question, covered in GDPR for a small SaaS; here it only decides who tells whom.

The reverse matters as much. When a vendor’s incident email reaches you, the EDPB’s position is that “in principle, the controller should be considered as ‘aware’ once the processor has informed it of the breach”, so that email can start your own clock. And whatever you decide, write it down: “if a breach is not notified, a justification for that decision should be documented”. Every article quoted here can be checked against the GDPR on EUR-Lex, the Union’s own legal database.

How to fix it: GDPR notification requirements, from the authority to the people affected

GDPR notification requirements mean a notice to the supervisory authority with at least 4 items: the nature of the breach with approximate numbers of people and records, a contact point, the likely consequences, and the measures taken or proposed. Information that is not ready in 72 hours can follow in phases without undue further delay.

GDPR reporting requirements do not stop at the authority. When the risk is high, the people whose data it was must be told too, and the two notices have different thresholds and different readers. They get separate subsections below, followed by the UK version and everyone else who may need to hear.

Report a data breach under GDPR: which authority, and what the notice must contain

Article 33(3) of the EU GDPR says the notification shall “at least” do four things, with the regulation’s own qualifiers.

1. 01 Describe the nature of the breach, including where possible the categories and approximate number of people concerned and the categories and approximate number of records concerned.
2. 02 Give the name and contact details of the data protection officer, or of another contact point where more information can be obtained.
3. 03 Describe the likely consequences of the breach.
4. 04 Describe the measures taken or proposed to deal with the breach, including, where appropriate, measures to reduce its possible adverse effects.

Reporting a data breach under GDPR does not wait for a finished investigation. Article 33(4) says the information “may be provided in phases without undue further delay”, and a notice sent after 72 hours must carry reasons for the delay. Under the GDPR, a security breach notification goes to one authority or to several, depending on where the company is established.

Ireland’s regulator shows what an intake looks like: the Data Protection Commission’s breach notification page says “All breach notifications must be notified using the ‘Breach Notification Form’”, asks for a self-declared risk rating from Low to Severe, takes later details as “a new version of the appropriate form”, and asks you not to include “the personal information of affected individuals”. The same page expects an internal record even when you decide there is no risk, including “who decided there was no risk”.

The data map is what makes the first version of that GDPR notification of a breach possible in the first hours: it already names the categories of data, the systems holding them and the vendors involved. One habit that is good practice, not a legal requirement: keep a short internal timeline from step 1 onward, so the “reasons for the delay” sentence, if you need it, is easy to write.

Telling the people affected: the Article 34 test

Individuals must be told without undue delay under Article 34 when a breach is likely to result in a high risk to their rights and freedoms, in clear and plain language. Article 34(3) sets 3 exemptions, including data rendered “unintelligible to any person who is not authorised to access it, such as encryption”.

The threshold is higher than for the authority: risk triggers Article 33, high risk triggers Article 34. Under EU GDPR Article 34(2), the message describes the nature of the breach and contains at least the contact point, the likely consequences and the measures taken or proposed, the same items as Article 33(3)(b), (c) and (d). Good practice adds what people can do about it, such as changing a password or watching for phishing that uses the leaked details; the ICO’s guide also says you “should provide advice to help them protect themselves”.

The other two exemptions are measures taken afterwards that mean the high risk “is no longer likely to materialise”, and cases where telling each person “would involve disproportionate effort”, which then require “a public communication or similar measure” instead. If you have not told people, the authority “may require it to do so” under Article 34(4).

Send the message from your normal domain, through the channel your users already get mail from, in a plain tone with no marketing in it. Forcing a password reset for the affected accounts is a separate control, covered under NIST minimum password length.

UK GDPR and the ICO: the same clock, a different regulator

The UK GDPR keeps both duties in the same words: notify without undue delay and, where feasible, within 72 hours of becoming aware unless the breach is “unlikely to result in a risk”, and tell individuals when it is “likely to result in a high risk”. What changed in 2026 is the recipient’s name; the 72-hour duty and the high-risk test did not. Since 30 September 2026, UK Articles 33 and 34 say “the Commission”, which the UK text defines as “the Information Commission”. The regulator’s own site still calls itself the ICO, and the ICO’s guide to personal data breaches points to its reporting pages, which include “a self-assessment tool and some personal data breach examples”. Of the regulator texts, it is the one I’d hand a two-person team first.

An app with users in both the EU and the UK may owe two notifications. The ICO’s guide says that “a breach affecting individuals in EEA countries will engage the EU GDPR” and that you should work out your EU lead authority in advance. Fines for missing either UK duty fall under the UK GDPR’s Article 83, whose paragraph 4 allows fines of up to £8,700,000 or, for an undertaking, up to 2 percent of total worldwide annual turnover, whichever is higher. Every quotation on this page is labeled EU GDPR or UK GDPR because the two texts are separate laws, even where the words match. Other countries’ breach laws, United States state laws among them, are outside this page.

Who should cybersecurity incidents be reported to, beyond the regulator

The authority and the people affected are the two notices the GDPR asks of a controller. A small SaaS usually has more parties to tell, and this table is my working list, except where a row cites the law.

My working rule: when an enterprise customer’s contract sets a shorter clock than 72 hours, treat the contract’s clock as the one for that customer, and read it before you write to them. The wider notification questions outside the GDPR, state laws and sector rules, stay with the “Decide who must be notified and when” section of the hacked-app guide above, and with counsel.

When the data is health data or card data, the clock is somebody else’s

A breach of health or card data brings in a second set of rules with its own deadlines, and the GDPR still applies in parallel to EU residents’ data. HIPAA and data breaches meet when the app holds protected health information for a United States covered entity; card data brings in the card brands’ and acquirers’ own rules.

What is a HIPAA breach, and the HIPAA breach notification timeline

A HIPAA breach is an impermissible acquisition, access, use or disclosure of protected health information that compromises its security or privacy, presumed unless a risk assessment shows a low probability of compromise. Individuals get notice without unreasonable delay, 60 calendar days after discovery at the latest; 500 or more people also means notice to HHS at the same time.

The jurisdiction is the United States, and the text is the Breach Notification Rule, 45 CFR 164.400 to 164.414. Section 164.402 says a breach under HIPAA “means the acquisition, access, use, or disclosure of protected health information in a manner not permitted under subpart E of this part which compromises the security or privacy of the protected health information”, and any such use “is presumed to be a breach” unless a risk assessment shows “a low probability that the protected health information has been compromised”. If you think of a HIPAA breach as an outside attacker, that is only one case: a record sent to the wrong person can count too, because disclosure is in the definition. The rule covers unsecured PHI, meaning data not rendered “unusable, unreadable, or indecipherable to unauthorized persons” by a method HHS specifies.

The HIPAA breach notification timeline, with each threshold copied from the rule:

A small SaaS is usually the business associate, so when a PHI data breach occurs the first call is to the covered-entity customer, not to HHS. My reading is that the business associate agreement may set a shorter time than the rule’s 60 days, and that clock is the one to watch. The HIPAA data breach notification duty itself comes from section 13402 of the HITECH Act, which in HHS’s 2009 words “requires HHS to issue interim final regulations” for breach notices; the subpart’s source notes cite that 2009 rule and its 2013 amendment. HHS issued that 2013 HIPAA rule to implement HITECH amendments “to strengthen the privacy and security protection for individuals’ health information”, and the same rule modified the breach notification requirements. Under the Breach Notification Rule, the statute and the regulation agree on the outer limit, 60 calendar days after discovery. PHI breach notification requirements only apply if the app holds protected health information at all, and whether your app holds protected health information is the question to settle first.

Card data: the card brands’ path, and why most apps here never hold a card number

With a hosted payment page or the payment provider’s embedded fields, card numbers do not reach your servers; that is my reading of how those designs work, and the scope question is a separate topic: PCI DSS requirements. If card data may be involved anyway, the path runs through the card brands and your acquirer. Guidance from the PCI Security Standards Council says to “Be prepared to alert necessary parties immediately”, names “payment card brands, acquirers (merchant banks), and any other entities that may require notification, whether by contract or law”, and warns against powering systems off, because that “may make the investigation more difficult and result in lost evidence or data”. Whether a forensic investigator is needed is for the acquirer or the card brand to say: they “each have their own rules and thresholds”. The guidance prints no notification deadline, so neither does this page.

Data breach costs for a small SaaS: what the headline number measures

Data breach costs quoted in headlines come from IBM’s annual study of 602 breached organizations and run to millions of dollars per incident. A small SaaS meets different costs: engineering time, customer notification and legal advice, and, for failing the notification duties, an EU fine ceiling of 10 million euros or 2 percent of turnover, whichever is higher.

IBM’s Cost of a Data Breach Report 2026 puts the global average at USD 4.99 million. It was conducted by the Ponemon Institute and is based on breaches at 602 organizations between March 2025 and February 2026. That figure is an average across those organizations, and it does not describe a two-person SaaS.

The consequences of a data protection breach that a small team actually meets are days of engineering diverted from the roadmap, the work of notifying customers and answering their follow-up questions, a lawyer’s time, and sales that slow down while a security questionnaire’s breach question gets an honest answer.

Data breach fines for the notification duties have a ceiling. Failing the Article 33 or 34 duties falls under EU GDPR Article 83(4)(a), with fines “up to 10 000 000 EUR, or in the case of an undertaking, up to 2 % of the total worldwide annual turnover of the preceding financial year, whichever is higher”. The UK figure is in the UK section above. Under Article 83(2), authorities weigh the circumstances, including “the degree of cooperation with the supervisory authority” and “the manner in which the infringement became known to the supervisory authority, in particular whether, and if so to what extent, the controller or processor notified the infringement”. Whether a company this size should worry about penalties at all is one of the questions answered in GDPR for a small SaaS. Of everything on this page, late or missing notification is the avoidable part.

How to stop it happening again

A small SaaS shortens the next breach response with 5 things prepared in advance: a current data map, a breach register with one owner, security logs that show who accessed what, a retention schedule that leaves less data to lose, and access rules tested from outside.

This is my working list for a small team, in the order I’d build it.

1. 01 A current data map, so scoping takes an hour instead of a week.
2. 02 A breach register with one named owner, holding every incident, including the ones you decided not to report.
3. 03 Security logging that can answer who accessed which records, and when.
4. 04 A retention schedule, because data you have already deleted cannot be breached.
5. 05 Access rules tested from outside the app, as an anonymous visitor and as a second customer.

The register is a legal duty, not only a habit: EU GDPR Article 33(5) says the controller “shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken”. The data map is the one from step 4. The logging side is covered under how to prevent insufficient logging and monitoring, and retention under what a data retention policy is. The last item matters most in these apps: my reading of the audit numbers earlier on this page is that access rules are where they most often leave data open, and whether you need an AI app security audit covers when an outside review makes sense. Once a year or so, I’d run the seven steps against a pretend incident and time the scoping step; that number tells you whether the map is current.

Common questions about reporting a data breach under GDPR

Is there a legal obligation to notify a data breach?

Yes, under the GDPR: a controller must notify the supervisory authority unless the breach is unlikely to result in a risk to people’s rights and freedoms (EU GDPR Article 33(1)), and a processor must notify the controller without undue delay (Article 33(2)). The people affected must be told as well when the risk to them is high (Article 34(1)), and a breach you decide not to report still goes in your own register (Article 33(5)).

Is a GDPR breach serious?

A GDPR breach is as serious as the risk it creates for the people whose data was involved, and that risk decides what you owe: notice to the authority unless the risk is unlikely (EU GDPR Article 33(1)), and notice to the people when it is high (Article 34(1)). The fine ceiling is a separate question, covered in the costs section above.

What happens if I accidentally breach GDPR?

The same steps apply, because the definition in EU GDPR Article 4(12) already includes “accidental” destruction, loss, alteration, disclosure or access. Authorities deciding on a fine look at “the intentional or negligent character of the infringement”, at what you did to reduce the damage, and at whether you notified (Article 83(2)), so a fast, documented response can count in your favor.

Is breaching GDPR a criminal offence?

Not under the EU regulation itself: it sets administrative fines in Article 83 and leaves “other penalties” to each member state under Article 84. In the UK, the Data Protection Act 2018 makes it an offense under section 170 “for a person knowingly or recklessly” to obtain or disclose personal data “without the consent of the controller”, an offense that, as I read it, is aimed at whoever takes the data rather than at a company that reports its own breach.

Can I sue for a GDPR breach?

Yes: EU GDPR Article 82(1) gives “Any person who has suffered material or non-material damage as a result of an infringement” the right to compensation from the controller or processor. For the company, that is why the register and the notification record matter: Article 82(3) exempts a controller or processor that “proves that it is not in any way responsible for the event giving rise to the damage”, and proof starts with what you wrote down at the time.

What are the three exceptions to HIPAA breach?

Section 164.402 excludes three things from the definition: an unintentional access or use by a workforce member “made in good faith and within the scope of authority” that goes no further; an “inadvertent disclosure” between two people both authorized to access PHI at the same covered entity, business associate or organized health care arrangement; and a disclosure where there is “a good faith belief that an unauthorized person to whom the disclosure was made would not reasonably have been able to retain such information”.