stakeholder-reportinglisted

# Stakeholder Reporting for Data Incidents ## The Communication Problem When data is late or wrong, two conversations need to happen simultaneously: the technical one (what broke and how to fix it) and the business one (what does this mean for decisions being made right now?). Data engineers are trained for the first conversation and often skip the second — which is how a 2-hour pipeline delay turns into a 2-day trust crisis. The goal of stakeholder communication is not to explain the technology. It's to answer: *What can stakeholders rely on right now? What should they not rely on? When will this be resolved?* --- ## Incident Communication Structure Every data incident notification should answer these four questions, in this order: 1. **What is affected?** — Which reports, dashboards, or decisions are impacted 2. **What do we know?** — The current state in plain language, no jargon 3. **What are you doing?** — The action being taken (not the technical details) 4. **When will it be resolved?** — A specific time estimate or next update time ### Template: Initial incident notification ``` Subject: [Data Alert] [Dashboard/Report Name] — Data delayed as of [TIME] Hi [team], We're experiencing a delay with [specific dashboard/report]. Data that should reflect activity through [expected time] is currently showing data through [actual time] — approximately [N hours] behind. Impact: [Sales dashboard / Churn model / Finance report] is showing incomplete numbers for toda