{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"security/lessons-learned","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/security/lessons-learned/","da":"https://cmaintz.github.io/tech-atlas/da/terms/security/lessons-learned/"},"term":{"en":"Lessons learned","da":"Lessons learned"},"aka":{"en":["post-incident review","post-mortem"],"da":["erfaringsopsamling","evaluering"]},"domain":["security"],"cluster":"incident-response","layer":"governance","status":"current","summary":{"en":"Looking back after an incident or exercise to see what worked, what failed and what to change next time.","da":"At se tilbage efter en hændelse eller øvelse for at finde ud af, hvad der virkede, hvad der fejlede, og hvad der skal ændres."},"body":{"formal":{"en":"The closing step of incident response, in which the people involved review the timeline and decisions without blame and turn findings into owned, dated changes to plans and controls.","da":"Det afsluttende trin i hændelseshåndteringen, hvor de involverede gennemgår forløb og beslutninger uden at placere skyld og gør fundene til ændringer i planer og kontroller, hver med en ansvarlig og en frist."},"plain":{"en":"Like a football team watching the match again on video to see why they let in that goal.","da":"Ligesom et fodboldhold, der ser kampen igen på video for at forstå, hvorfor de lukkede det mål ind."},"inPractice":{"en":"A week after a ransomware outage, staff at an accounting firm meet for an hour, note that the backup key sat on the very server that was locked, and task the IT manager with moving it by Friday.","da":"En uge efter et ransomware-nedbrud mødes medarbejderne i et revisionsfirma en time og finder ud af, at nøglen til backuppen lå på netop den server, der blev låst, og giver IT-chefen til opgave at flytte den inden fredag."},"whyItMatters":{"en":"Without it the same mistakes return in the next incident, and the organisation pays twice for the same lesson.","da":"Uden den vender de samme fejl tilbage ved næste hændelse, og organisationen betaler to gange for den samme lærdom."}},"deepDive":{"en":"NIST SP 800-61 Rev. 2 (§3.4.1) placed the lessons-learned meeting in the post-incident activity phase, to be held within several days of the end of a major incident, and suggested questions that are still widely used: exactly what happened and at what times, how well staff and management performed, whether documented procedures were followed and adequate, what information was needed sooner, which actions inhibited recovery, what would be done differently, how information sharing could be improved, what corrective actions could prevent similar incidents, which precursors or indicators should be watched for, and which tools or resources are missing. Revision 3 (2025) moves improvement into the Cybersecurity Framework 2.0 Identify function's Improvement category and treats it as continuous, so lessons can be captured during an incident and after exercises and assessments, not only at the close.\n\nThe blameless post-incident review, popularised by site reliability engineering practice, assumes that people acted reasonably given the information and pressures they had at the time. The aim is to explain why decisions made sense then, avoiding hindsight bias and a search for a single root cause. Complex incidents usually have several contributing factors, such as an unpatched system, a missing alert, an unclear mandate and a stale contact list, and naming only one of them leaves the others in place. Techniques include timeline reconstruction from logs and chat records, five whys, fishbone diagrams and structured frameworks for contributing factors.\n\nThe output is a written report with a factual timeline, impact, what went well, what did not, and a list of actions, each with an owner, a deadline and a way to verify completion. Actions typically change detection rules, playbooks, contact lists, architecture, training or contracts with suppliers. Tracking closure is the step most often skipped; organisations that report the same finding across several reviews have documented rather than learned. The report can also supply material for the NIS2 final report on root cause and mitigation, but the two have different audiences and should not be the same document.\n\nIn ISO/IEC 27001:2022 the practice is required through Annex A control 5.27, learning from information security incidents, and connects to clause 10 on continual improvement and corrective action, which is why the term maps naturally to the Act step of the PDCA cycle. Lessons learned differs from incident reporting in purpose and timing: reporting passes facts to others during and shortly after the event, while lessons learned is an internal analysis aimed at change.","da":"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.\n\nDen 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.\n\nResultatet 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.\n\nI 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."},"edges":[{"type":"part-of","to":"security/incident-response","confidence":"high","strength":"normal"},{"type":"implements","to":"security/pdca","confidence":"high","strength":"normal"},{"type":"used-with","to":"security/security-culture","confidence":"high","strength":"normal"}],"depth":0,"sources":[{"title":"Cyber Security Fast Track - Ordliste","tier":"course-material"},{"title":"NIST SP 800-61 Rev. 3 - Incident Response Recommendations and Considerations for Cybersecurity Risk Management","url":"https://doi.org/10.6028/NIST.SP.800-61r3","tier":"standard","publisher":"NIST"}],"draft":true}