GDPR Article 32 requires that organisations implement appropriate technical measures to ensure security appropriate to the risk — explicitly including encryption of personal data. TLS is the primary mechanism for encrypting personal data in transit for web-based services. When TLS fails — whether through certificate expiry, misconfiguration, or compromise — the security of personal data in transit may be affected.
The notification obligation under GDPR Article 33 is triggered when a personal data breach occurs — defined as a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data transmitted, stored or otherwise processed. Certificate failures can trigger this in several ways.
How certificate failures create data protection risk
Expired certificate — service refuses connections. When a certificate expires and a browser refuses to connect, no data is exchanged. From a GDPR perspective, this is primarily an availability incident — personal data is not accessible, but it is not being exposed either. This is unlikely to trigger a notification obligation on its own, though it may constitute a breach of confidentiality or availability depending on the nature of the service.
Expired certificate — clients fall back to HTTP. Some client applications, particularly older mobile apps, API clients, and IoT devices, may fall back to unencrypted HTTP when TLS fails. If the service continues to be reachable over HTTP and handles personal data, those communications are now transmitted without encryption. This is a data protection failure — personal data is being transmitted in a way that violates the encryption requirement of Article 32.
Certificate with weak cryptography — ineffective encryption. A certificate using deprecated algorithms (RSA-1024, SHA-1) or weak cipher suites does not provide meaningful encryption against a motivated attacker. Regulators have taken the position that encryption that is technically present but practically ineffective does not satisfy Article 32. This is a risk that certificate monitoring should surface and remediate.
Compromised private key — passive interception. If a TLS private key is compromised, an attacker positioned on the network path can decrypt all communications. This is a direct data breach for any personal data transmitted. Revocation should happen immediately, but as discussed in our article on OCSP, revocation effectiveness is limited — the primary response is to rotate the certificate and key immediately, not to rely on revocation to stop ongoing exploitation.
Fraudulent certificate — active interception. If an attacker obtains a certificate for your domain — through CA compromise, domain validation vulnerability, or a misconfigured DNS record — they can intercept communications between users and your service. Users see a valid padlock for your domain; the certificate is just not yours. This is the scenario certificate transparency monitoring is designed to detect.
The 72-hour clock
GDPR Article 33 requires notification to the supervisory authority without undue delay and where feasible no later than 72 hours after becoming aware of a personal data breach. The 72-hour window starts when the organisation becomes aware — not when the breach started. But investigations need to establish the scope and nature of the breach before notification, which means incident response processes need to work quickly. The same 72-hour discipline underpins NIS2 certificate management, so organisations subject to both frameworks can build one process that serves both.
Certificate-related incidents are particularly prone to delayed detection. An expired certificate on an API endpoint that serves a mobile application may go unnoticed for hours if monitoring does not cover that endpoint. A weak cipher negotiated with older clients may never generate an obvious alert. Establishing that a breach involving in-transit data has occurred often requires reviewing TLS configurations and client connection logs — which takes time if the inventory and tooling are not already in place.
What regulators look for in assessments
Data protection authorities conducting post-incident assessments or proactive audits look at technical security measures as part of their review. For TLS specifically, assessors may look for:
- Evidence that TLS is enforced (HTTPS redirect, HSTS headers) and that HTTP fallback is not possible
- Current, valid certificates on all services processing personal data
- TLS configuration that uses approved protocols (TLS 1.2 minimum, TLS 1.3 preferred) and strong cipher suites
- Monitoring processes that ensure certificate expiry is detected before it causes failures
- Evidence that certificate monitoring covers all services handling personal data, not just the primary public website
An organisation that has experienced a certificate-related incident and cannot demonstrate that it had functioning monitoring in place is in a significantly worse position with the supervisory authority than one that can show the alert fired, the response process was followed, and the certificate was renewed without data protection impact. See the certificate audit checklist for a practical guide to the evidence auditors expect.
Practical steps to reduce certificate-related GDPR risk
- Map your personal data flows to TLS endpoints. Every system that transmits personal data over a network should be identified, and the TLS configuration of that transmission path should be in scope for TLS certificate monitoring. This is the asset mapping — a complete TLS certificate inventory — that feeds both GDPR compliance and ISO 27001.
- Enforce HTTPS strictly. HSTS (HTTP Strict Transport Security) with a long max-age tells browsers to refuse HTTP connections to your services. This prevents the fallback-to-HTTP failure mode that turns a certificate expiry into a data protection incident.
- Monitor all personal data processing endpoints, not just the primary website. APIs, internal tools handling personal data, partner integrations, and data processing systems all deserve monitoring. The ones most likely to fall through the gaps are the ones not visible to a simple external scan.
- Include certificate incidents in your data breach assessment process. When a certificate-related incident occurs, the response process should include a data protection impact assessment — determining whether personal data was potentially affected and whether notification obligations are triggered.
How CertControl reduces GDPR certificate risk
CertControl monitors TLS configuration across all endpoints — checking not just expiry but also protocol versions, cipher suites, HSTS configuration, and chain validity. Findings that create data protection risk — disabled HSTS, expired certificates, weak protocols — surface as security findings with appropriate severity ratings.
The platform covers both external endpoints and internal systems via the on-premise agent, ensuring that personal data processing systems not reachable from the internet receive the same monitoring coverage as public-facing services. Alert thresholds are configurable per endpoint, so systems processing sensitive personal data can be set to alert earlier than systems with lower data protection significance.
Frequently asked questions
Does an expired certificate count as a GDPR data breach?
It depends on the failure mode. If the certificate simply expires and browsers refuse to connect, no data is exchanged and it is primarily an availability incident. If clients fall back to unencrypted HTTP and personal data is then transmitted in clear text, that is a data protection failure that can trigger an Article 33 notification obligation.
When does the GDPR 72-hour notification clock start?
Article 33 requires notification to the supervisory authority without undue delay and where feasible within 72 hours of becoming aware of a personal data breach. The clock starts when the organisation becomes aware, not when the breach began, but the investigation to establish scope and nature still has to happen inside that window.
Can weak cipher suites by themselves be a GDPR problem?
Yes. A certificate using deprecated algorithms such as RSA-1024 or SHA-1, or weak cipher suites, does not provide meaningful encryption against a motivated attacker. Regulators have taken the position that encryption that is technically present but practically ineffective does not satisfy Article 32.
How does HSTS reduce certificate-related GDPR risk?
HTTP Strict Transport Security with a long max-age tells browsers to refuse plain HTTP connections to your services. This prevents the fallback-to-HTTP failure mode that turns a certificate expiry into a data protection incident, because clients will not transmit personal data in clear text.
What do data protection authorities look for after a TLS incident?
Assessors look for evidence that TLS is enforced and HTTP fallback is not possible, current valid certificates on all services processing personal data, approved protocols and strong cipher suites, and monitoring that covers every personal data endpoint rather than just the primary website. Being able to show the alert fired and the response process was followed materially improves your position.