Skip to content

Data Breach 72-Hour Notification Tracker

Example prompt: "When someone files a security incident in our Jira 'Security Incidents' project with a label of 'personal-data', start a 72-hour clock from the discovery time on the ticket. Create a matching case in our 'Breach Register' Airtable with the case ID, discovery time, due time, and a status of 'assessing'. Draft a one-paragraph factual summary from the ticket description, post it in #breach-response on Slack, and email the DPO and our outside counsel. At 24 hours, 48 hours, and 60 hours before the deadline, post a reminder in the channel with the current status. If the status is still 'assessing' at 60 hours, also email the DPO directly flagging the slip."

The Problem

When a personal data breach is discovered, GDPR Article 33 gives controllers 72 hours to notify the supervisory authority — sometimes less under sector-specific rules. The clock starts at awareness, not at confirmation, and missing the deadline without good reason is a reportable failing on its own. In practice the incident lands in a security ticket, the DPO finds out by accident, and the team spends the first day arguing over whether it really is a breach instead of running the clock. By the time the notification is drafted, half the window is gone and people are working out of WhatsApp messages with no audit trail.

How GloriaMundo Solves It

We build a workflow triggered when a security incident is tagged as involving personal data. An integration step reads the ticket, a code step computes the 72-hour deadline and the three reminder timestamps, and an LLM step drafts a factual summary using only what is in the ticket — no speculation about scope or cause. The case is opened in a dedicated breach register, the summary is posted to the response channel, and the DPO and outside counsel are emailed. Three reminders fire at the 24, 48, and 60-hour marks before the deadline so the DPO knows where the assessment stands without having to chase. If the case is still in assessment at the 60-hour mark, the workflow escalates with a direct email to the DPO flagging the slip. Glass Box preview shows the deadline calculations, the summary text, and the recipient list before anything is sent, so the security lead can confirm the framing is correct before the response loop opens.

Example Workflow Steps

  1. Trigger (integration): Fires when a Jira issue in the 'Security Incidents' project is labelled 'personal-data'.
  2. Step 1 (integration): Fetch the full ticket, including the discovery timestamp, reporter, and current description.
  3. Step 2 (code): Compute the 72-hour notification deadline and the three reminder timestamps (24h, 48h, and 60h before the deadline).
  4. Step 3 (LLM): Draft a one-paragraph factual summary using only the ticket contents, avoiding speculation about scope or cause.
  5. Step 4 (integration): Create a row in the 'Breach Register' Airtable with the case ID, discovery time, deadline, reminders, and a status of 'assessing'.
  6. Step 5 (integration): Post the summary in #breach-response on Slack and email the DPO and outside counsel from Gmail.
  7. Step 6 (state): Persist the deadline and reminder timestamps so subsequent runs of the workflow can fire the reminders.
  8. Step 7 (conditional): At each reminder timestamp, post a status reminder in #breach-response. If the case is still 'assessing' at the 60-hour mark, also email the DPO with an escalation note.

Integrations Used

  • Jira — the security incident ticket that triggers the workflow
  • Airtable — the breach register holding case IDs, deadlines, status, and the audit trail
  • Slack — the response channel for the working group during the 72-hour window
  • Gmail — initial notification to the DPO and outside counsel, plus the deadline-slip escalation

Who This Is For

Data Protection Officers, security operations leads, and in-house counsel at companies subject to GDPR or the UK DPA — typically anyone holding personal data on UK or EU residents, where a missed notification deadline is a regulatory and reputational risk on top of the breach itself.

Time & Cost Saved

The first hour of a suspected breach is the most expensive — confusion about who owns the response, what counts as awareness, and where the deadline lands. This workflow does not replace the substantive assessment, but it removes every minute spent on logistics: deadline calculations, opening the case in the register, drafting the initial notice, paging the right people. For an organisation with one to two personal-data incidents a quarter, that is several hours per incident and a noticeably calmer first day. The audit trail produced — timestamps, status transitions, escalations — is the artefact a supervisory authority will ask for if the notification is late or contested.