GDPR Article 32 requires controllers and processors to implement technical and organisational measures appropriate to risk, including—as appropriate—ongoing availability and resilience, timely restoration, and regular testing. It does not prescribe an uptime tool, universal interval, or availability percentage.
Monitoring can support those measures and incident awareness, but monitoring alone does not demonstrate GDPR compliance. An outage is not automatically a personal data breach, and a breach is not automatically notifiable: legal triage must determine whether personal data suffered a confidentiality, integrity, or availability breach and whether the Article 33 risk threshold is met. Read the official GDPR text on EUR-Lex, especially Articles 4(12), 28, 32, and 33.
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
Operationally, the organization should select and test measures that fit the risks of its processing. Availability monitoring may be one measure among access control, resilience, backups, incident detection, restore testing, and governance.
Article 33 — Breach notification (72 hours)
Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours after awareness unless the personal data breach is unlikely to result in a risk to people's rights and freedoms. Monitoring should feed prompt legal and privacy triage; it should not make the notification decision.
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:
- Risk-appropriate availability monitoring of relevant processing 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 broken rights flow needs prompt investigation because it can impede the organization's processes for handling requests. Synthetic checks can detect some failures, but legal impact depends on the request, deadlines, alternatives, and response.
3) Backup and Restore
Article 32(1)(c) identifies the ability to restore availability and access in a timely manner as an appropriate measure to consider. Backups, tested restore procedures, redundancy, and recovery ownership may contribute, depending on the processing risk:
- 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 governs controller-processor terms and a processor's use of sub-processors. Availability monitoring can support supplier oversight where a processor is material to the processing:
- 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 |
Build Monitoring From Article 32 Risk
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 status page can support operational transparency, but it is not a GDPR requirement and must not disclose personal data or sensitive incident details.
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 a personal data breach may have occurred — escalate immediately for awareness and risk assessment
- 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
Escalate potential personal data breaches through the organization's privacy process without delay. Notification decisions follow the organization's governance and legal analysis; involve the DPO where applicable and preserve the facts needed to assess risk and awareness.
Incident Communication: Status Updates During Outages covers the customer-facing side; the DPO communication is internal but equally time-sensitive.
Where External Monitoring Can Contribute
External monitoring can contribute availability, certificate, DNS, heartbeat, and incident-timeline evidence to a wider Article 32 program:
- 24/7 uptime monitoring with a cadence chosen from risk and the detection objective; Webalert's published plans currently offer one-minute checks on paid tiers and ten-minute checks on Free
- Multi-region checks — sample availability from locations relevant to the processing and user population
- 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 — Webalert lists Email and Slack on all plans; SMS, webhooks, Discord, and Microsoft Teams are paid-plan channels
- Status pages — optional operational communication, configured to avoid personal-data disclosure
- Incident records — timestamped detection, acknowledgment, and resolution data for audits
- Timestamped history — retain selected availability evidence under the organization's accountability and retention approach
See features and pricing for details.
Summary
- GDPR Article 32 calls for measures appropriate to risk; monitoring can support availability and resilience but is not proof by itself.
- Article 33 makes timely awareness and triage important, while notification depends on the personal data breach and risk threshold.
- 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 status page only when it fits the communication plan and does not expose personal data.
- Treat your monitoring system itself as in-scope — heartbeats, redundancy, and effectiveness reviews matter.
Monitoring can support risk-appropriate availability and incident measures. Compliance depends on the full technical and organisational program and its documented operation.