Aurora Health: a hidden data leak and a postmortem process that punishes honesty
Aurora Health's patient app has 40,000 active users. An engineer discovered that a third-party analytics SDK bundled in the last release was sending medication reminder text, including drug names, to an external endpoint. Five months earlier another engineer had flagged the same SDK in a risk review; the note was logged and the team was told to move on. The product director wants to fix it quietly and not notify users unless legal requires it. The postmortem template asks 'who introduced the change' and 'who will be held accountable', and managers have cited postmortem findings in performance reviews. Two engineers privately say they now fix small issues themselves rather than raise them. Legal confirms that notification is required only for confirmed breaches of identifiable records, which is arguable here. The CTO wants a decision within 48 hours.
1. Diagnose why engineers are not raising defects, using high-velocity IT culture concepts. Address the role of the postmortem template and the dismissed SDK warning.
Read the worked answer
The pattern is systemic, not individual. A template that asks who introduced a change and who is accountable, combined with managers citing findings in performance reviews, teaches that raising a problem is personally dangerous. That is the opposite of psychological safety, which high-velocity IT treats as a precondition for fast, safe delivery: people must be able to report errors and near misses without punishment. The dismissed SDK warning is the second lesson - reporting produces no action, so engineers rationally stop reporting and self-fix. This is a just-culture failure: behaviour is a response to incentives, not a character flaw. The leadership preference for a quiet fix repeats the same pattern one level up: protecting the appearance of quality instead of quality. Ethics sits inside high-velocity culture, not beside it; concealment damages trust with users, regulators and staff, and destroys the information flow the organization needs.
2. Recommend how the company should handle disclosure and the internal review, and what accountability should look like.
Read the worked answer
Containment first: disable the SDK, establish exactly what data left, and stop further transmission. On disclosure, the legal minimum is a floor, not the standard. With health-adjacent data and 40,000 users, high-velocity ethics favours prompt, plain-language notification; the credibility needed to keep receiving internal reports depends on not being seen to hide things. Internally, the review should be blameless in method but rigorous in scope: why the SDK was approved, why the earlier warning was logged and dropped, why the template asks who, and who owned third-party data risk. Accountability should attach to decisions and system conditions - missing risk ownership, no data-flow review, blame-oriented metrics - not to the engineer who found the defect or the one who flagged it. Publish the actions and report progress; visible follow-through is what changes beliefs about speaking up.
3. Which measures would show the culture is improving, and why is 'zero incidents' a poor target?
Read the worked answer
Track signals of voice, not just outcomes: number of risk and near-miss reports per team, time from raising an issue to acknowledgement, share of postmortems with system-level actions, repeat incident rate, and anonymous survey scores for psychological safety. Early on, a rising report count is a good sign - it means people believe reporting works. Zero incidents is a poor target because it rewards silence and under-reporting, and it contradicts the high-velocity view of incidents as learning material; an organization with no reported problems usually has a reporting problem, not a quality miracle. Also check that nobody has suffered retaliation after raising a concern. Review trends quarterly and share results openly, including the bad news.