Post-incident root cause analysis

Root cause analysis is the inquiry that starts from the trigger of an incident and traces back the process, control or technical failures that made it possible. On August 6, 2024, CrowdStrike published its root cause analysis of the July 19 outage that had sent more than eight million Windows machines into boot loops. The sensor expected twenty input fields, the Channel File 291 update supplied twenty-one, producing an out-of-bounds memory read. The document also states what changes: staged deployment of content updates, added testing, and customer control over the rollout schedule. DORA makes it an obligation. Article 17 of Regulation (EU) 2022/2554 requires an incident management process, and Article 13(2) requires a review after any major incident that disrupts core activities, examining its causes, checking whether procedures were followed and identifying required improvements; changes are communicated to the authority on request. The Article 19 final report comes once the root cause analysis is complete. Under NIS2, the final report of Article 23(4), due one month after the notification, describes the type of threat or root cause likely to have triggered the incident. For the underwriter, this is the most useful document in the file. At renewal, it shows whether the cause was fixed or merely worked around. At claim time, it feeds three disputes. The first is subrogation, when the cause is a software vendor's update or a managed service provider's error. Then come the unpatched known vulnerability exclusion, when it names a flaw published months earlier, and the minimum security measures clause, when it records missing multifactor authentication on remote access. Hence the temptation to have it drafted under breach counsel's direction. One caveat: a document owed to the supervisor is hard to shield, and one month is rarely enough, so the NIS2 final report often speaks of a probable cause that forensics corrects later.