Incident Response Policy

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This policy defines how Glassbreak detects, classifies, contains, eradicates, recovers from, and learns from security incidents and operational outages. It applies to all events that affect — or could affect — the confidentiality, integrity, or availability of Glassbreak systems, customer data, or workforce information.

2. Scope

Any of the following constitute an incident in scope of this policy:

Suspected or confirmed unauthorised access to Glassbreak systems or customer data.
Suspected or confirmed unauthorised modification of customer data, audit logs, or production systems.
Loss of availability of any production service beyond defined SLOs.
Loss, theft, or compromise of any device or credential that has access to Glassbreak systems.
Discovery of a previously unknown vulnerability that affects Glassbreak systems.
Receipt of a coordinated-disclosure report under /trust/disclosure.
Any event reasonably believed to be a personal-data breach under GDPR Art. 4(12).

3. Severity classification

Every incident is assigned an initial severity at triage. Severity may be re-classified as the picture clarifies.

3.1 SEV-1 — Critical

Confirmed unauthorised access to customer data, even if no plaintext was disclosed.
Confirmed tampering with audit log entries.
Full loss of availability of the primary production surface (glassbreak.io) where cross-vertical failover has also failed.
Confirmed compromise of a production signing key.
Active exploitation of a remote-code-execution vulnerability.

Initial response: immediate. Customer notification within 24 hours. Public status-page update within 1 hour.

3.2 SEV-2 — High

Suspected unauthorised access pending investigation.
Loss of availability of one vertical with degraded service on the other.
Authentication bypass affecting a non-critical surface.
Exposure of secret-management metadata (org structure, member list) without plaintext disclosure.
Critical-severity vulnerability disclosed by a researcher with no known active exploitation.

Initial response: within 1 hour. Customer notification within 72 hours per the DPA. Public status-page update within 4 hours.

3.3 SEV-3 — Moderate

SLO violation lasting beyond the alert threshold but with no customer impact reported.
Successful brute-force or credential-stuffing pattern against a single account.
High-severity vulnerability disclosed with patch already in flight.
Loss of a non-critical sub-processor.

Initial response: within 4 business hours. Customer notification only if data subjects are affected.

3.4 SEV-4 — Low

Cosmetic issues, minor regressions, low-severity vulnerability reports.
Smoke-test failure cleared by retry.
Dependabot alerts in development-only dependencies.

Initial response: next business day.

4. Detection sources

Automated — observability alerts (5xx rate, p95 latency, apex probe), 30-minute smoke-test heartbeat, daily security-posture snapshot probes, Dependabot, CI failures on the DR scenario suite.
Manual — workforce reports (security@glassbreak.io), customer-support tickets, abuse reports.
External — coordinated-disclosure reports, public advisories, sub-processor incident notices.

5. Response phases

5.1 Detect

An event is logged, given a unique incident identifier, and a Severity is assigned at triage. The on-call responder acknowledges within the SLA above.

5.2 Triage

Confirm the event is in scope.
Assign initial severity.
Identify probable systems and data affected.
Open a private incident channel for coordination.
Notify additional responders as needed (engineering, legal, leadership).

5.3 Contain

Stop the bleed — disable affected accounts, revoke credentials, isolate compromised infrastructure, take the affected vertical offline if necessary (cross-vertical failover is automated for most paths).
Preserve forensic evidence (logs, memory captures where feasible, audit-log snapshots) before destructive remediation.
For credential compromise: rotate the affected secret per the runbook for that secret class.

5.4 Eradicate

Identify and remove the root cause: the vulnerability, the misconfiguration, the malicious account, the compromised sub-processor link.
Patch, redeploy, rotate keys, update infrastructure, re-issue credentials.
Verify with focused testing that the cause is removed and not masked.

5.5 Recover

Bring affected services back into operation, verifying with the smoke-test suite and the DR scenarios most relevant to the incident.
Restore data from backups where required, using the procedures in the BCP/DR plan.
Confirm SLO metrics are back within tolerance before declaring resolved.
Update the public status page.

5.6 Learn

Conduct a blameless post-mortem within 5 business days of resolution.
Publish the post-mortem internally; publish externally for SEV-1 and SEV-2 incidents unless customer privacy requires redaction.
Track every action item to closure in the standard issue tracker.
Update this policy or any dependent procedure if a structural weakness is identified.

6. Roles during an incident

Incident Commander — owns the response, makes the calls, decides when to escalate or de-escalate severity, decides when the incident is resolved.
Communications Lead — handles customer notifications, status-page updates, supervisory-authority notifications, and coordination with legal.
Technical Lead — drives containment, eradication, and recovery. Coordinates additional engineers as needed.
Scribe — maintains the incident timeline, captures decisions and their rationale for the post-mortem.
Subject-matter experts — pulled in as needed.

At smaller scale, one responder may carry multiple roles. The Incident Commander role must always be explicitly held.

7. Customer notification

Personal-data breaches affecting customer data are notified to affected controllers without undue delay, and in any event within 72 hours of becoming aware, per the DPA at /legal/dpa.
For SEV-1, customers are notified within 24 hours regardless of whether plaintext data was involved.
Notification includes: nature of the incident, categories and approximate volume of records affected, likely consequences, mitigations taken and proposed, and a contact point for follow-up.
If full detail cannot be provided in the initial notification it is provided in phases without further undue delay.

8. Supervisory-authority notification

Where Glassbreak acts as controller and is required to notify a supervisory authority under GDPR Art. 33, that notification is made within 72 hours of becoming aware. Where Glassbreak acts as processor, the customer controller carries the supervisory-authority notification obligation; Glassbreak supports the customer with the information described in section 7.

9. Post-mortem

Every SEV-1 and SEV-2 incident produces a written post-mortem. Post-mortems follow this structure:

Incident identifier, dates, severity, duration.
Customer impact.
Timeline of detection, triage, containment, recovery.
Root cause (technical and organisational).
What went well.
What went badly.
Action items, each with an owner and a closure deadline.
How we will detect this earlier next time.

Post-mortems are blameless: their purpose is to improve the system, not to assign personal fault.

10. Testing

Tabletop exercises are run at least annually.
The 22 disaster-recovery scenarios in dr-tests/ run in CI nightly and provide continuous regression assurance on the technical-recovery path.
Communication templates and the status-page update flow are exercised at least quarterly with a no-impact test.

11. Records

All incidents are recorded in the incident register regardless of severity.
Records are retained for at least 5 years.
Records of personal-data breaches are retained for at least the period required by applicable law and never less than 5 years.

12. Review

This policy is reviewed at least annually and after every SEV-1 incident. The next scheduled review is 27 May 2027.

To report a security incident, email security@glassbreak.io. For non-urgent disclosure reports see /trust/disclosure.