Incident Response

How GL detects, responds to, and communicates about security and availability incidents. ← Back to G-Layer

Last reviewed: 17 August 2026

Scope

This plan covers any event that affects the confidentiality, integrity, or availability of GL or the data it processes: a security vulnerability being actively exploited, a bug that exposes data it shouldn't, unauthorised access, a data breach, or an outage that stops GL working as expected for a client. Routine bugs with no security or availability impact are handled through GL's normal, documented change process instead.

Severity and response targets

These targets are aspirational commitments, not a contractual SLA. GL is currently maintained by a small team without a 24/7 on-call rotation; severity is judged using the best information available at the time.

Detection

Incidents are currently identified through:

• Direct reports from a client or user, via the security contact below.
• The team's own testing and review, including fixture-based testing of security-sensitive features such as PII masking.
• Dependency vulnerability scanning, per GL's vulnerability management process.
• Cloudflare's own platform-level alerting, where applicable to the underlying infrastructure.

There is no automated intrusion detection or SIEM system in place today. This is disclosed honestly rather than implied to exist; see the security page for the fuller picture of what is and isn't built today.

Response process

1. Confirm the issue is real and assess its severity using the table above.
2. Contain it, for example by rotating a credential, disabling an affected feature for a specific client, or rolling back a bad deployment using GL's documented rollback mechanisms.
3. Fix the underlying cause through GL's normal change process: a reviewed, version-controlled change, tested against real fixtures where the issue is security sensitive.
4. Independently verify the fix actually closes the issue, rather than assuming it worked because the change looked right, in line with GL's design principle that a failure must never be silently reported as a success.
5. Record what happened in GL's internal change history, so there is a durable, honest record of what went wrong and what was done about it.

Communication

Affected clients are notified directly as soon as the issue and its impact are reasonably well understood, rather than waiting for a full fix. Communication is honest about what is and is not yet known: GL does not overstate confidence about scope or root cause while it is still being investigated.

Data breach notification

If an incident involves personal data and rises to the level of a personal data breach under UK GDPR, GL follows the ICO's own notification duty: the ICO must be notified within 72 hours of becoming aware of the breach where it is likely to result in a risk to individuals, and affected individuals are told directly where the risk is high. This is not legal advice; it describes GL's own process, and each client remains responsible for their own regulatory obligations regarding their own data.

Post-incident review

After any Critical or High severity incident, a short written review covers what happened, how it was detected, how it was fixed, and what should change to prevent a repeat. This plan, along with GL's vulnerability management process, is reviewed at least annually, or immediately after any incident that reveals a gap in it.

Reporting a security issue

If you believe you've found a vulnerability in GL, please report it via the contact in /.well-known/security.txt rather than a public channel, so it can be addressed before disclosure.