Data Incident Postmortem Template (Lineage, GDPR Breach Check)

Data Incident Postmortem: [Incident title]

Blameless postmortem for a data incident: bad, late or missing data, a schema break, silent duplication, or personal data exposed in an analytics environment. It records detection, the blast radius traced through lineage (OpenLineage specification 2-0-2), the consumers and decisions affected, restatement and backfill, data contract and service level breaches, the personal data notification check (GDPR Articles 33 and 34, handled through the Incident Response Plan), root cause, data quality rule gaps and actions. Severity uses SEV1 to SEV4 from the Incident Severity Matrix. Replace every [bracketed] value and every row marked Example. The notification section is a documentation format, not legal advice.

Document control

Approvals

Revision history

Contents

1. Summary
2. Classification and scope
3. Impact
4. Timeline
5. Detection
6. Blast radius and lineage
7. Response, containment and communication
8. Restatement and backfill
9. Personal data and notification check
10. Root cause analysis
11. Data quality rule gaps
12. What went well and what did not
13. Action items
14. Glossary and references
15. Standard and licence note

1. Summary

Example: A payments change-data-capture connector replayed about 45 minutes of payment events at each of two restarts, on 2026-10-13 and 2026-10-14. The staging model for payments had no uniqueness test, so duplicated payment rows fanned out in the join that computes order net amounts. For business dates 2026-10-13 and 2026-10-14, net revenue in the Orders data product was overstated by EUR 412,600 (3.10%), and the inflated figures reached the finance daily flash report and the marketing bid-optimisation export for about 42 hours. The daily reconciliation rule failed on both mornings, but its alert went to a ticket queue and nobody acted until a finance analyst noticed the mismatch. We deduplicated payments in staging, backfilled the two partitions and issued a restated flash report. The main follow-up is a Critical uniqueness rule in staging and paging on reconciliation failures for Tier 1 data.

2. Classification and scope

2.1 Type and severity

2.2 Data-specific severity guidance

Classify with the Incident Severity Matrix (ops/incident-severity-matrix); each criterion is evaluated on its own and the most severe result wins. The examples below show how data incidents map to the matrix criteria. Wrong figures already used in external, regulatory or investor reporting may justify the crisis flag of the matrix on top of the level; record that decision in section 2.1. Raise the level as soon as a criterion is met, never lower it to avoid an obligation, and record both the level at declaration and the peak.

2.3 When to use which postmortem

3. Impact

3.1 Data impact

Per business date (Example):

3.2 Consumers and decisions affected

3.3 Contract and service level breaches

Error budget arithmetic (Example): 90 partitions x (1 - 0.99) = 0.9 failing partitions allowed; 2 / 0.9 = 2.22, so 222% of the budget was consumed and the error budget policy freezes non-reliability changes to the Orders product until it recovers.

4. Timeline

4.1 Key durations

5. Detection

Detection category: consumer-detected after automated signal ignored. This counts against the "consumer-detected defects" metric of the Data Quality Standard (data/data-quality-standard).

6. Blast radius and lineage

6.1 Method

Lineage is collected as OpenLineage run events (specification 2-0-2) from the orchestrator and from dbt. Each run event names the job, the run, and its input and output datasets with facets such as the schema; input datasets can also carry data quality assertion results. To find the blast radius:

1. Start from the dataset where the defect entered (here stg_payments_api__payments).
2. Walk output datasets of every job that read it, recursively, for runs between the defect time and the fix.
3. For each downstream dataset, list the runs that wrote affected partitions, and the readers (jobs, dashboards, exports) of those partitions.
4. Confirm each reader with its owner; record readers that lineage missed and add them to lineage collection (action item).

6.2 Lineage graph

The graph below combines the lineage events for the incident window with consumers confirmed by owners (Example). The marketing bid export was not in lineage and was found only by asking owners (section 6.3).

6.3 Affected assets

7. Response, containment and communication

7.1 Containment options considered

7.2 Key decisions

7.3 Communication

Use Incident Communication (dev/incident-communication) for message templates and cadence.

8. Restatement and backfill

8.1 Backfill plan

8.2 Restatement of decisions and reports

9. Personal data and notification check

Personal data exposure in analytics happens more often than teams expect: email addresses in event properties, free text in search terms, identifiers in URLs, or a restricted table copied into an open sandbox. Whenever personal data may be involved, hand the breach assessment to the process in the Incident Response Plan (compliance/incident-response-plan) immediately; this postmortem records the outcome and does not replace that process.

Apply these points when you assess the incident (check the consolidated text and your own legal advice):

• Is it a personal data breach (Art. 4(12))? A personal data breach is a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. It covers confidentiality (data seen by people who should not see it), integrity (data altered) and availability (data lost or unreachable).
• Confidentiality in analytics is a breach. Personal data that becomes visible to people without authorisation is a personal data breach, also when the viewers are employees, when the data sits in an internal analytics zone, and when the identifiers are pseudonymous. Pseudonymised data remains personal data. Do not argue such an exposure away; record it as a breach and assess the risk.
• Assess the risk, then decide on notification (Art. 33). The controller notifies the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of the breach, unless the breach is unlikely to result in a risk to people's rights and freedoms. Pseudonymisation, encryption, a short exposure to a small group of trusted staff, and prompt deletion can lower the risk; they are factors in the assessment, not reasons to skip it. A processor informs the controller without undue delay.
• Communicate to people when the risk is high (Art. 34). When the breach is likely to result in a high risk to the people concerned, the controller also tells them without undue delay, unless an Art. 34(3) condition applies.
• Document every breach (Art. 33(5)). Record the facts, effects and remedial action in the internal breach register, whether or not it is notified. Record a "not a breach" decision and its reasoning too.
• Other regimes. Other jurisdictions and sector rules have their own triggers and deadlines; the Incident Response Plan lists them.

If the answer to the confidentiality question had been yes (for example the marketing export had carried customer_id to an advertising partner without a legal basis), the incident would be a personal data breach and SEV1 under the security criterion of the Incident Severity Matrix. Complete the risk assessment below in that case and follow the Incident Response Plan for the notification decision.

If the analytics data is listed in the Record of Processing Activities (compliance/gdpr-ropa), check whether the incident shows that the record is out of date.

10. Root cause analysis

10.1 Causal chain

1. Example: Broker maintenance caused the payments CDC connector to restart and resume from an earlier offset (trigger).
2. The connector delivers at-least-once; replayed events were appended to the raw payments table.
3. The staging model selected all raw rows without deduplicating on payment_id.
4. The intermediate model joined order lines to payments assuming at most one payment per line, so duplicates multiplied amounts.
5. fct_orders summed the joined amounts, overstating net_amount for affected orders while order_id stayed unique, so DQ-ORD-001 passed.
6. DQ-ORD-004 detected the difference, but its Major severity routed the alert to an unwatched queue, and downstream consumers ignored the provisional flag.

10.2 Five whys

10.3 Contributing factors

11. Data quality rule gaps

12. What went well and what did not

Went well (Example):

• Lineage events let the team list most downstream assets within 15 minutes of declaration.
• Write-audit-publish made the backfill safe and atomic; consumers never saw a half-corrected state.
• Finance raised the issue in the shared channel instead of correcting figures locally.

Did not go well (Example):

• The first of two automated signals went unanswered for 31 h 35 min (2026-10-14 06:00 to declaration at 2026-10-15 13:35).
• The bid export was missing from lineage, so marketing was informed late.
• The provisional flag existed but no consumer used it.

Where we were lucky (Example):

• The weekly forecast retrain was scheduled after the backfill.
• The month-end close was not in the incident window.

13. Action items

Track completion in the quarterly data quality review (Data Quality Standard section 13.3). The postmortem status moves to "Actions complete" when every Prevent and Detect action is done.

14. Glossary and references

14.1 Glossary

14.2 References

Standard and licence note

Based on the OpenLineage specification 2-0-2 (Apache-2.0, openlineage.io) for lineage concepts, the Bitol Open Data Contract Standard (ODCS) v3.2.0 (Apache-2.0, github.com/bitol-io/open-data-contract-standard) for contract and service-level concepts, and Articles 4(12), 33 and 34 of Regulation (EU) 2016/679 (GDPR), paraphrased in original words. This is a documentation format, not legal advice. Severity levels follow this library's Incident Severity Matrix. The structure and text are original, written for this collection; Corvid Commerce and the incident are fictional. Check the current official versions and the consolidated legal text before use. Template licence: MIT.