Incident Response

A security incident is any event that compromises the confidentiality, integrity, or availability of Castline or its data. A personal data breach is the regulated subset where personal data is involved — and where Article 33 of GDPR starts a 72-hour clock from the moment of awareness.

This skill describes what happens from "something looks wrong" to "incident closed, post-mortem published, lessons absorbed." The goal is that everyone knows their role before the incident, so we're not learning the runbook while customers are waiting.

The 72-hour clock

GDPR Article 33 requires notification to the relevant supervisory authority within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons.

"Awareness" is a low bar. It begins when we have a reasonable degree of certainty that a breach has occurred — not when we've finished investigating. The clock is not paused by ongoing analysis. When in doubt, notify and amend later. The supervisory authorities prefer over-notification to under-notification.

For Castline, the Danish Data Protection Authority (Datatilsynet) is the lead supervisory authority for the EU one-stop-shop. Notification is via virk.dk using the prescribed form.

Severity tiers

• S1 — Critical. Active exfiltration, ransomware, or service outage exceeding 1 hour. Trigger the full response chain immediately.
• S2 — High. Confirmed exposure of Restricted data, even if contained. Authentication bypass discovered in production. Public-facing vulnerability with proof of exploitability.
• S3 — Moderate. Suspected exposure that has not been confirmed. Authentication bypass in staging. Vulnerability discovered through external disclosure with no evidence of exploitation.
• S4 — Low. Near-miss. Internal mistake caught before customer impact.

Escalation chain

The on-call engineer is the First Responder. On detecting an event they:

1. Open an incident channel in Teams with the incident ID.
2. Page the Incident Commander (rotating role — current schedule pinned in the channel).
3. Begin the containment runbook for the system in question.

The Incident Commander owns the response from declaration to closure. They make the call on severity, escalation, and external notification. They are not also doing the technical work — that's the on-call engineer plus reinforcements pulled in as needed.

For any S1 or S2 the Commander immediately notifies the Head of Compliance and Head of Legal. Compliance owns the regulator-notification decision; Legal owns customer and partner notification.

For incidents touching customer data the CEO is notified within one hour, regardless of severity.

Containment, eradication, recovery

In that order, every time. Containment first — stop the bleeding. Eradication second — remove the cause. Recovery last — restore service and verify. Reversing the order is how incidents become incidents-plus-collateral-damage.

External notification

Regulator. Within 72 hours when notification is required. Filed by the Head of Compliance using the Article 33 template, which captures: nature of breach, categories and approximate number of data subjects, likely consequences, measures taken or proposed.

Affected individuals. Where the breach is likely to result in a high risk to rights and freedoms (Article 34), without undue delay. Plain-language email, no jargon, with concrete advice on what the individual should do.

Customers and partners. Per contractual breach-notification clauses in master service agreements and DPAs. Legal manages outbound.

Monthly tabletop

The first Monday of each month, the Incident Commander rotation runs a 45-minute tabletop exercise. A pre-written scenario (kept in a sealed folder Legal maintains) is read out, and the assigned Commander walks through declaration, escalation, containment, and notification with the team present. No production system is touched. The exercise produces a one-page write-up filed in runbooks/incident-tabletops/.

The tabletop is the most reliable predictor of how well we'll respond to a real incident. Skipping it is the single biggest mistake an organisation makes in this space.

Post-incident

Every S1 and S2 gets a written post-mortem within five business days. The post-mortem is blameless — it asks how the system allowed the situation, not which individual made the mistake. Corrective actions are tracked in monday.com against named owners with due dates.

Owned by

Head of Compliance, with the Head of Legal as co-owner. Audited by the Master skill on a 30-day cadence.