Require the vendor to tell you about a breach affecting your data without undue delay, ideally within a fixed number of hours, with enough detail to act on. The GDPR says a processor must notify the controller without undue delay after becoming aware of a personal data breach. A contract can be tighter. This is not legal advice.
Why a fixed number beats "promptly"
Under the GDPR a controller must notify the supervisory authority within 72 hours of becoming aware of a personal data breach, where feasible, unless the breach is unlikely to result in a risk to people. The processor's duty is to tell the controller without undue delay. If your vendor takes a week to tell you, your own clock is already in trouble.
"Without undue delay" has no number in it. A contract that names hours gives you something to plan around. For a longer view of the clocks different regimes use, see breach notification clocks compared.
What a good clause covers
| Term | What to ask for |
|---|---|
| Trigger | Notice on suspected or confirmed unauthorised access to your data, not only confirmed loss |
| Deadline | A fixed number of hours from awareness |
| Channel | A named mailbox and phone contact, monitored around the clock on your side |
| Content | Nature of the breach, data and categories affected, likely consequences, measures taken, a contact for questions |
| Updates | Further information in phases as it becomes known |
| Cooperation | Help with your own notifications and investigation |
| Sub-processors | The same duty flows down and is reported to you |
| Evidence | Logs and a root cause summary after the incident |
The content row follows the list in GDPR Article 33, which says the notification should describe the nature of the breach, give a contact point, describe likely consequences and describe measures taken or proposed. It also allows information to be provided in phases when it cannot all be given at once.
Security vendors are a special case
A scanner vendor's breach can hurt twice. Your personal data may be exposed, and so may your vulnerability list or access tokens that let the vendor reach your repositories. Add terms that cover those:
- Notice if any credential or token the vendor holds for your systems may have been exposed.
- A commitment to help you rotate those quickly.
- A description of what the vendor will do to confirm whether your tenant was in scope.
On your side, keep a runbook for revoking the vendor's access, so you can cut it within minutes of a notice. See breach patterns 2026: stolen credentials, vendors and old access.
Questions to ask in review
- What is your internal target for notifying customers, and how is it measured?
- Who decides that an incident is a notifiable breach, and how fast?
- Have you run a tabletop for a data exposure involving customer tenants?
- What logs would you share with us to scope impact?
- How do you tell customers: email, status page, direct call?
How Safeguard fits
Fewer external copies of your data means fewer breach paths. Safeguard supports SaaS, private VPC, on-prem and air-gapped deployment. You can see outputs with the free scan.
Quick check
Is 72 hours the vendor's deadline?
No. The 72 hours applies to the controller's notice to the authority. The processor must tell the controller without undue delay, so ask the vendor for a much shorter fixed time.
Do I need notice of incidents that did not reach my data?
You can ask for it, as many buyers do for security incidents with potential impact. Define the trigger clearly so it stays workable.
Sources
Last reviewed: 19 October 2026.
