Lessons learned

NIST SP 800-61 Rev. 2 (§3.4.1) placerede lessons learned-mødet i fasen efter hændelsen, afholdt inden for få dage efter afslutningen af en større hændelse, og foreslog spørgsmål, der stadig bruges bredt: præcis hvad der skete og hvornår, hvor godt medarbejdere og ledelse klarede sig, om de dokumenterede procedurer blev fulgt og var tilstrækkelige, hvilke oplysninger der var brug for tidligere, hvilke handlinger der hæmmede genopretningen, hvad man ville gøre anderledes, hvordan informationsdeling kunne forbedres, hvilke korrigerende handlinger kunne forhindre lignende hændelser, hvilke forvarsler eller indikatorer man skal holde øje med, og hvilke værktøjer eller ressourcer der mangler. Revision 3 (2025) flytter forbedring ind i kategorien Improvement under funktionen Identify i Cybersecurity Framework 2.0 og ser den som løbende, så erfaringer kan opsamles under en hændelse og efter øvelser og vurderinger, ikke kun til sidst.

Den skyldfri gennemgang efter en hændelse, som er gjort udbredt af site reliability engineering, bygger på antagelsen om, at folk handlede fornuftigt ud fra de oplysninger og det pres, de havde på tidspunktet. Målet er at forklare, hvorfor beslutningerne gav mening dengang, uden bagklogskab og uden at lede efter én enkelt grundårsag. Komplekse hændelser har som regel flere medvirkende faktorer, fx et upatchet system, en manglende alarm, et uklart mandat og en forældet kontaktliste, og nævner man kun én af dem, bliver de andre stående. Teknikker omfatter rekonstruktion af tidslinjen ud fra logs og chatbeskeder, fem gange hvorfor, fiskebensdiagrammer og strukturerede rammer for medvirkende faktorer.

Resultatet er en skriftlig rapport med en faktuel tidslinje, konsekvenser, hvad der gik godt, hvad der ikke gjorde, og en liste over handlinger, hver med en ansvarlig, en frist og en måde at verificere, at den er gennemført. Handlingerne ændrer typisk detektionsregler, playbooks, kontaktlister, arkitektur, uddannelse eller leverandørkontrakter. Opfølgning på, at handlingerne lukkes, er det trin, der oftest springes over; organisationer, der noterer det samme fund i flere gennemgange, har dokumenteret frem for lært. Rapporten kan også levere materiale til den endelige NIS2-rapport om grundårsag og afhjælpning, men de to har forskellige modtagere og bør ikke være det samme dokument.

I ISO/IEC 27001:2022 kræves praksissen via kontrol 5.27 i bilag A, læring af informationssikkerhedshændelser, og hænger sammen med afsnit 10 om løbende forbedring og korrigerende handlinger, hvilket er grunden til, at begrebet passer naturligt til Act-trinnet i PDCA-cyklussen. Lessons learned adskiller sig fra hændelsesrapportering i formål og timing: rapportering sender fakta videre til andre under og kort efter hændelsen, mens lessons learned er en intern analyse, der sigter mod forandring.