SaaS data breach: who has 72 hours under GDPR?

Your customer-management software provider emails to say someone accessed your customer database. Your own systems are running normally. The affected records include names, email addresses and order histories. Who needs to notify the regulator?

Where your company determines why those personal data are processed, it generally carries the controller’s notification obligation. Under GDPR, notification to the competent supervisory authority is required without undue delay and, where feasible, within 72 hours of becoming aware of the breach. The exception is where the breach is unlikely to result in a risk to people’s rights and freedoms.

A provider processing those data on your behalf must notify you without undue delay. It does not have a separate 72-hour allowance to pass on the news. These are distinct duties under GDPR Article 33.

Which role does each company have?

Imagine a software company using an online customer relationship management system, or CRM. The company chooses what customer details to collect and why it needs them. For that processing, it is the data controller.

The provider stores and handles the records on the company’s behalf. For those activities, it is a data processor. SaaS means software delivered as a service, usually accessed online.

Hosting the database does not automatically transfer the controller’s duties to the provider. Roles depend on the particular processing: the provider may be a processor for the customer database and a controller for its own billing records. The European Commission’s breach guidance uses a cloud-provider incident to explain this division.

If your business runs a SaaS product and handles data on customers’ instructions, you may be the processor in this situation. You notify the affected customer controllers. If a subcontractor is involved, the relevant reporting chain must reach those controllers. Choosing and authorising that subcontractor is a separate issue, covered in our guide to SaaS subprocessor changes and objections.

When does the 72-hour period start?

The trigger is awareness of the breach: a reasonable degree of certainty that a security incident has compromised personal data. You do not need the final number of affected people or a complete account of how the attacker got in.

Suppose the CRM provider tells your company at 10:00 on Thursday that an unauthorised person opened a file containing your customers’ records. That is specific information about a breach. Forwarding the email to the person responsible for privacy on Friday does not move the start of the period to Friday.

An alert saying only “we are investigating suspicious activity” may require a short initial investigation to establish whether personal data have been compromised. That investigation should start promptly. Waiting days for a vendor’s final report cannot be used to postpone awareness. See EDPB Guidelines 9/2022, paragraphs 31 to 40 and 44. The EDPB is the European Data Protection Board, which brings together the national data protection authorities.

The period is measured in hours, not business days. Your response arrangements need to work over weekends. And 72 hours is not a reason to wait until the deadline: the obligation to act without undue delay still applies.

What if the provider has not finished investigating?

An initial notification can be followed by updates. The provider should send the information available about the established breach promptly. It does not first need to decide whether the controller must report it to a regulator. That risk assessment belongs to the controller.

Ask the provider for:

• the affected data categories, customer accounts and available scope information;
• what happened, when it was detected and when the breach was established;
• whether records were accessed, copied, altered, destroyed or made unavailable;
• the relevant safeguards and actions taken to limit the impact;
• a contact for the incident and the next update time.

If your company must notify the authority but some facts are still missing, GDPR allows information to be supplied in phases without undue further delay. The notification must describe the breach, including categories and approximate numbers of people and records where possible, a contact point, likely consequences and measures taken or proposed. Explain what remains unknown. A notification made after 72 hours must include reasons for the delay. These requirements appear in GDPR Article 33(3) and (4).

Must every incident be reported to the authority?

A personal data breach is a security breach leading, for example, to unauthorised disclosure, alteration, loss or destruction of personal data. Availability can also be affected. An ordinary service outage does not automatically establish a personal data breach, but the absence of evidence of a database download does not settle the question either.

The controller assesses the risk to the people concerned. In the CRM example, that includes whether the exposed order histories and contact details could enable fraud, impersonation or disclosure of sensitive information. Record count alone does not determine the outcome.

Where the breach is unlikely to result in a risk to people’s rights and freedoms, regulatory notification is not required. The controller must still document the breach, its effects, remedial action and the reasoning behind its decision. Article 33(5) requires breach documentation.

A likely high risk generally also requires communication to the affected individuals without undue delay. That is a separate decision, without a universal 72-hour limit. GDPR Article 34 provides exceptions, including effective protection that makes the data unreadable to unauthorised people, or subsequent measures making the high risk no longer likely to materialise. Where individual communication would involve disproportionate effort, an equally effective public communication or similar measure is required.

What should the contract settle before an incident?

The data processing agreement, or DPA, should describe the provider’s assistance with breaches. The duty to provide that assistance is part of GDPR Article 28(3)(f).

Agree an incident channel, backup contacts, the contents of the initial notice and an update schedule. If the contract says, for example, “no later than 12 hours after becoming aware”, retain the requirement to notify without undue delay. Twelve hours is an example of a negotiated limit, not a statutory deadline or permission to wait. Address cooperation on risk assessment, preserving evidence and communications too.

A notice sent only after the technical investigation closes can arrive too late for the customer’s decisions. A generic status-page update may not identify that customer’s data as affected. Review this alongside liability and support arrangements when arranging legal support for your SaaS contracts.

With proper authorisation and contractual arrangements, a processor can submit a notification on the controller’s behalf. The controller retains legal responsibility for notification, as paragraph 48 of the EDPB guidelines explains. Confirm who is doing what before relying on “the provider is handling it”.

Does the proposed 96-hour period change anything today?

Legal status checked on 22 October 2026: the Council agreed its negotiating position on the Digital Omnibus on 21 October. Its mandate, page 137, includes a proposed 96-hour period and a high-risk threshold for notification to the authority.

That is a proposed change, not the applicable deadline. The Council announcement describes further negotiations with the European Parliament. It does not justify switching the current procedure to 96 hours or reporting only high-risk breaches.

What can you check now?

Check that the provider has a current incident contact at your company. Read the DPA’s initial-notice provision. Identify who assesses risk and prepares a notification when the usual person is unavailable.

For the company using the CRM, those arrangements let the response start as soon as the provider’s message arrives. Technical staff contain the incident while the person handling the legal assessment gathers facts and manages notification decisions. Neither workstream needs to wait for the other to finish.

Terms and legal references explained

Data controller

The organisation that determines the purposes and essential means of processing personal data. In this example, the company using the customer-management system decides why it collects and uses its customers' details.

Data processor

An organisation processing personal data on the controller's behalf. For the entrusted customer data, the SaaS provider must notify the controller of a breach without undue delay. It does not wait for the controller's assessment of whether regulatory notification is necessary.

Becoming aware of a breach

Having a reasonable degree of certainty that a security incident has compromised personal data. Full technical findings are not required. Initial investigation should start promptly; a detailed report can follow later.