How Certificate Failures Become GDPR Incidents

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.

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.

Practical steps to reduce certificate-related GDPR risk

1. 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 certificate monitoring. This is the asset mapping that feeds both GDPR compliance and ISO 27001.
2. 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.
3. 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.
4. 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.