One month after the 72-hour notification the entity owes a final report containing a detailed description of the incident including its severity and impact, the type of threat or root cause likely to have triggered it, the mitigation measures applied and ongoing, and where applicable the cross-border impact. If the incident is still ongoing when that month expires, the entity provides a progress report at that point and then a final report within one month of finishing its handling of the incident. Root cause is the demanding element: a report that names the immediate technical trigger without reaching the reason the condition existed does not meet the standard, and it is also the element that determines whether the entity learns anything. The mitigation section must distinguish what is already done from what is still in progress.
This control maps to 12 controls across 7 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.
Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.
NIS2 Directive Art.23.4.d is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of NIS2 Directive your existing evidence covers. Hold DORA and 17 of 28 NIS2 Directive controls already carry evidence.
Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 0 were rejected on the DORA pair alone.
The graph holds this control, the 12 it maps to, and the evidence behind each claim, over MCP and REST.