Most teams think of GDPR as a privacy framework — about consent banners, data subject access requests, and where data lives geographically. That's true, but it's only part of the picture.
Article 32 of the GDPR explicitly requires controllers and processors to implement "appropriate technical and organisational measures" to ensure "the ongoing confidentiality, integrity, availability and resilience of processing systems and services." That word — availability — is the bridge between privacy law and uptime monitoring.
If your service goes down and a user can't exercise their rights (access, rectification, erasure), that's a compliance issue, not just an outage. If your monitoring is so weak that a breach takes 96 hours to detect, your 72-hour notification clock has already run out before you knew anything was wrong.
This guide explains what GDPR actually requires from a monitoring perspective, what auditors and DPOs (Data Protection Officers) look for during assessments, and how to set up monitoring that produces the evidence you need.
Disclaimer: This guide is general technical guidance, not legal advice. For binding interpretations of GDPR for your specific business, consult a qualified data protection lawyer or your DPO.
Where GDPR Touches Monitoring
Three areas of GDPR put monitoring squarely in scope:
Article 32 — Security of processing
Article 32 lists factors that controllers and processors must consider, including:
- Confidentiality, integrity, availability, and resilience of processing systems
- The ability to restore availability and access in a timely manner after an incident
- A process for regularly testing, assessing, and evaluating the effectiveness of measures
Translated into operations: you need to monitor uptime, you need to detect incidents quickly, and you need evidence that your monitoring actually works.
Article 33 — Breach notification (72 hours)
Article 33 requires notifying the supervisory authority of personal data breaches within 72 hours of becoming aware. Note: aware, not occurring. The clock starts when you know — and the regulator's first question after a late notification is "why didn't you know sooner?"
Strong monitoring shortens the gap between breach occurrence and breach awareness. That gap is one of the most material risk factors auditors examine.
Article 30 — Records of processing activities
While Article 30 is about the records of processing, the supervisory authority can request evidence that the technical measures listed in your records actually exist and operate as described. Your monitoring records — uptime logs, incident timelines, alert history — become part of that evidence base.
What "Availability" Means Under GDPR
The GDPR doesn't define a numeric uptime target. It does require appropriate measures — proportional to:
- The state of the art (what's reasonably available technically)
- The cost of implementation
- The nature, scope, context, and purposes of processing
- The risk to the rights and freedoms of natural persons
For a high-traffic SaaS storing health data, "appropriate" is dramatically different than for a small marketing site with no special category data. But for any service that processes personal data, supervisory authorities expect at least:
- Continuous availability monitoring of customer-facing systems
- Alerting that reaches a person who can act
- A documented incident response process
- Evidence of incident detection time and resolution time
- Periodic review of monitoring effectiveness
Monitoring for SOC 2 Compliance and Audit Requirements covers a related framework with overlapping evidence requirements.
What to Monitor for GDPR Evidence
1) Customer-Facing Systems
The systems users interact with — your app, your auth flow, your data subject rights portal — are core "processing systems" under Article 32:
- Uptime monitoring with check intervals tight enough to support your incident detection SLO (typically 1–5 minutes)
- Multi-region checks — Confirm the service is reachable from every jurisdiction you serve
- TLS / SSL monitoring — Encryption in transit is a baseline Article 32 measure; expired certs are an availability and a confidentiality issue
- Authentication flow monitoring — A broken login means users cannot exercise their rights (see How to Monitor Your Login and Authentication Flow)
2) Data Subject Rights Endpoints
If users have an in-app data export, account deletion, or rights request flow, those endpoints need their own monitoring:
- HTTP checks on the rights request portal
- Synthetic flow monitoring on the data export feature
- Alerting on increased error rate on these endpoints specifically
A subject rights flow that's been quietly broken for two weeks is a documentable compliance issue — and easily detectable with synthetic monitoring.
3) Backup and Restore
Article 32(1)(c) requires "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident." That means your backups must work and you must be able to prove it:
- Backup completion monitoring — Heartbeat from the backup job; alert when missed (see Cron Job Monitoring)
- Restore testing — Periodic restore drills with logged evidence
- Backup integrity — Alert if backup size deviates from expected ranges
4) Encryption at Rest
While not itself a monitoring concern in real time, encryption status changes (database TLS dropped, disk encryption disabled) should be alertable. Monitor:
- Database connection encryption status
- KMS / key management service availability
- Certificate validity for any internal mTLS
5) Incident Detection Time
GDPR auditors care about time to detection more than aggregate uptime. Track and report:
- Mean Time To Detect (MTTD) — How long between incident start and alert firing?
- Mean Time To Acknowledge (MTTA) — How long until a human responds?
- Mean Time To Recover (MTTR) — How long to full restoration?
How to Reduce MTTR and Recover from Incidents Faster covers the operational side.
6) Third-Party Processors
Article 28 makes you responsible for sub-processors. If your processors go down, your service goes down — and you owe an explanation:
- Monitor third-party APIs your service depends on (see Third-Party Dependency Monitoring)
- Track processor incidents in your incident log even when their resolution wasn't yours
- Maintain awareness of processor status pages and incidents
Evidence Auditors and DPOs Look For
When you're being audited or your DPO is preparing a compliance report, the questions tend to follow this pattern:
| Question | Evidence to Provide |
|---|---|
| How is service availability monitored? | Monitoring tool, check intervals, list of checks |
| Who gets alerted when something breaks? | Escalation policy, on-call rotation |
| What was your average detection time last quarter? | Incident records with detect/ack/resolve timestamps |
| Show me the incident response process | Documented runbook, post-mortem template |
| When was your last restore drill? | Drill log, results, action items |
| How do you handle third-party processor incidents? | Processor inventory, incident communications |
| What changed after your last incident? | Post-mortem actions, follow-up tickets |
| How do you ensure monitoring itself is working? | Heartbeat / synthetic checks on the monitoring system |
You don't need fancy software to produce most of this — you need consistency. A simple incident log with timestamps, owners, and resolutions is dramatically more valuable than scattered Slack threads.
Common GDPR Monitoring Gaps
| Gap | Risk | Fix |
|---|---|---|
| No uptime monitoring on rights request flows | Cannot demonstrate Article 12 responsiveness | Synthetic checks on rights endpoints |
| Alert noise causes ignored real incidents | Late detection, late breach notification | See Alert Fatigue |
| Backups complete but never tested | Cannot demonstrate Article 32(1)(c) | Quarterly restore drill with evidence |
| No record of incident detection time | Auditor cannot assess responsiveness | Standardized incident log with timestamps |
| Monitoring runs from one region | Outages in other regions invisible | Multi-region checks |
| Third-party outages not logged | Article 28 oversight gaps | Incident log includes processor incidents |
| No certificate expiry monitoring | TLS lapses risk confidentiality | SSL monitoring with multi-week notice |
| Monitoring tool itself is unmonitored | Silent monitoring failure | Heartbeat from monitoring to a second system |
Setting Up GDPR-Aligned Monitoring
Minimum baseline
- Uptime monitoring of all customer-facing services with at least 5-minute checks
- TLS certificate monitoring with at least 14-day expiry warnings
- Multi-region monitoring matching your customer geography
- Documented escalation policy so alerts reach someone who acts
- Incident log with timestamps for detection, acknowledgment, and resolution
- Heartbeat monitoring of backup jobs
Audit-ready setup
Add:
- Synthetic monitoring of rights request flows
- Authentication flow monitoring
- Third-party processor health in your monitoring dashboard
- Quarterly restore drills with logged evidence
- Periodic monitoring effectiveness review (e.g., every 6 months)
- Status page that becomes your customer-facing incident communication record
A public status page is unusually valuable for GDPR compliance: it doubles as evidence of transparent incident communication, which weighs favorably in supervisory authority assessments.
What to Do When Monitoring Detects a Potential Incident
GDPR-aware incident response differs from purely technical incident response in three ways:
1) Triage with personal data in mind
For every detected incident, ask early: does this involve personal data?
- If unauthorized access is possible — the breach notification clock may have started
- If data integrity might be compromised — note the time of detection precisely
- If availability is impacted but no breach — still document for your records
2) Document the timeline rigorously
Auditors will want minute-by-minute records:
- Time of first alert (from monitoring)
- Time of acknowledgment (from your alerting tool)
- Time of escalation
- Time of containment
- Time of resolution
Your monitoring system already produces most of these timestamps automatically. Capture them.
3) Loop in the DPO early
Whether or not the DPO is on the technical incident bridge, they need to know quickly. The 72-hour clock for breach notification is unforgiving, and the DPO is the one who decides whether notification is required.
Incident Communication: Status Updates During Outages covers the customer-facing side; the DPO communication is internal but equally time-sensitive.
How Webalert Helps
Webalert provides the technical foundation for GDPR-aligned monitoring:
- 24/7 uptime monitoring with check intervals as tight as 30 seconds
- Multi-region checks — confirm availability across every jurisdiction you serve
- SSL monitoring — catch certificate issues that affect both availability and confidentiality
- DNS monitoring — detect resolution failures that block users from exercising their rights
- Heartbeat monitoring — confirm backups, scheduled jobs, and rights-flow processors are running
- Multi-channel alerts — Email, SMS, Slack, Discord, Microsoft Teams, webhooks
- Status pages — transparent customer communication during incidents (a core GDPR-favored practice)
- Incident records — timestamped detection, acknowledgment, and resolution data for audits
- 5-minute setup — start producing audit-ready monitoring evidence today
See features and pricing for details.
Summary
- GDPR Article 32 requires availability and resilience of processing systems — monitoring is how you prove you've implemented "appropriate measures."
- Article 33's 72-hour breach notification clock makes detection time a compliance metric, not just an operational one.
- Auditors care about process and evidence: monitoring coverage, escalation, incident records, and restore drills.
- Monitor your customer-facing service, rights request flows, authentication, backups, and third-party processors.
- Track detection time, acknowledgment time, and resolution time for every incident.
- Use a public status page as both customer communication and audit evidence.
- Treat your monitoring system itself as in-scope — heartbeats, redundancy, and effectiveness reviews matter.
GDPR turns availability into a legal requirement. Monitoring is how you prove you take it seriously.