# Lessons learned: Bliv bedre efter hændelsen

> Lessons learned efter en it-hændelse: Hvornår eftergennemgangen finder sted, hvilke spørgsmål der tæller, og hvordan erkendelser bliver til foranstaltninger med frist.

Kilde: https://phpsos.de/da/blog/lessons-learned-nach-vorfall/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** Lessons learned efter en it-hændelse betyder: Efter den tekniske afslutning sætter alle involverede sig sammen, rekonstruerer forløbet, benævner uden skyldsfordeling, hvad der gik godt, og hvad der ikke gjorde, og udleder deraf foranstaltninger med ansvarlige og frister. Det gælder også for nær-hændelser som en PHP2Shell-uge, der forløb lempeligt. Det afgørende er ikke protokollen, men den senere kontrol af, om foranstaltningerne blev gennemført.

## Hvorfor ugen efter hændelsen er så vigtig

Når serveren kører igen, og patches er indspillet, er fristelsen stor til hurtigt at vende tilbage til hverdagen. Netop da går den mest værdifulde viden tabt: Hvem har lagt mærke til hvad hvornår? Hvor manglede en oplysning? Hvilken beslutning tog for lang tid? Om nogle uger ved ingen det længere præcist.

Oktoberugen 2026 er et godt eksempel på det. Mange virksomheder har patchet PHP-servere, skrevet til hostingudbydere, forebyggende lukket websites ned eller sikret logs. Selv om der ikke blev konstateret noget indbrud, ligger der meget læring heri. Hvor lang tid gik der, før det stod fast, hvilke systemer der var berørt? Hvem skulle godkende nedlukningen, og var denne person tilgængelig?

De tekniske skridt efter selve et angreb behandler [Tjeklisten efter et hack](https://phpsos.de/da/ratgeber/checkliste-nach-dem-hack/). Dette indlæg tager fat bagefter: Hvad lærer vi af det?

## Lessons learned i it-hændelsen: Grundregler for eftergennemgangen

En eftergennemgang er ikke en domstol. Den, der frygter, at fejl får personlige følger, fortæller kun halvdelen af historien. Derfor gælder princippet: Vi leder efter årsager i forløb, værktøjer og oplysninger, ikke efter skyldige. Mennesker har handlet med den viden, de havde i det øjeblik.

Inviter alle, der var involveret, også eksterne som hostingudbyder, bureau eller leverandør, så vidt muligt. Afsæt to timer. Bed på forhånd om materiale: tickets, chatforløb, e-mails, noter, logudtræk. Heraf opstår tidslinjen, mødets rygrad. Hvordan I opbygger den rent, beskriver [Opstil tidslinjen for en hændelse](https://phpsos.de/da/blog/zeitleiste-eines-vorfalls/).

Faciliteringen bør ikke overtages af den person, der har ledet hændelsen operativt. Vedkommende ville ellers vurdere sine egne beslutninger. Neutral er for eksempel en person fra en anden afdeling eller en ekstern partner.

## Forløbet i seks trin

1. **Præsentér tidslinjen:** Hvad skete der hvornår, fra den første melding til afslutningen? Markér huller i tidslinjen, gæt ikke.
2. **Hvad gik godt?** Begynd bevidst med det positive. Det viser, hvad der skal bevares, og afspænder runden.
3. **Hvor hakkede det?** Hver forsinkelse, hver manglende oplysning, hver usikkerhed samles, først uden diskussion om løsninger.
4. **Afklar årsager:** Til de vigtigste punkter spørger I flere gange efter hvorfor. "Patchen kom sent" er et fund, "ingen vidste, at der stadig kører PHP på den gamle server" er en årsag.
5. **Fastlæg foranstaltninger:** Til hver årsag en konkret foranstaltning, en ansvarlig person og en frist.
6. **Aftal efterkontrol:** En termin om fire til otte uger, hvor det kontrolleres, hvad der er gennemført.

## Typiske spørgsmål og foranstaltninger efter en PHP-situation

Den følgende tabel viser spørgsmål, som ofte stilles efter en situation som PHP2Shell, og mulige svar i form af foranstaltninger. Ikke alle passer til enhver virksomhed; tabellen skal skærpe blikket.

| Spørgsmål i eftergennemgangen | Typisk fund | Mulig foranstaltning |
|---|---|---|
| Hvordan fik vi kendskab til sårbarheden? | Tilfældigt fra nyhederne | Abonnér målrettet på sikkerhedsmeddelelser fra php.net og BSI |
| Vidste vi, hvilke systemer der var berørt? | Liste ufuldstændig, ældre system glemt | Oversigt over alle websites og servere med PHP-version |
| Hvem måtte beslutte nedlukningen? | Uklart, beslutning forsinket | Fastskriv beslutningsbeføjelsen i nødplanen |
| Har hostingudbyderen bekræftet patchen? | Kun mundtligt eller slet ikke | Indhent skriftlig bekræftelse, udvid kontrakten |
| Blev alle PHP-processer genstartet? | Ikke kontrolleret | Optag genstart og kontrol som fast trin |
| Var logs fra og med 20.10. tilgængelige? | Delvis allerede overskrevet | Forlæng opbevaringstiden, sikr logs centralt |
| Hvordan forløb kommunikationen indadtil og udadtil? | Medarbejdere hørte det i pressen | Forbered en intern førstinformation |

Fasthold også, hvad I bevidst ikke ændrer. Nogle gange er et fund kendt, men foranstaltningen ville være uforholdsmæssig. En dokumenteret beslutning er bedre end en stille glemsel.

> **Tip:**
> Adskil i protokollen dokumenterede kendsgerninger, sandsynlige antagelser og åbne spørgsmål. Netop efter PHP2Shell, for hvilken der ikke findes offentliggjorte, bekræftede Indicators of Compromise, er denne adskillelse vigtig.

## Fra protokol til forandring

Det hyppigste svigt ved lessons learned er banalt: Protokollen sendes rundt, og så sker der intet. Tre vaner hjælper imod det. For det første hører hver foranstaltning hjemme i det system, hvor der alligevel arbejdes, altså ticketsystemet eller opgavelisten, ikke i et separat dokument. For det andet får efterkontrollen en fast termin i direktionens kalender. For det tredje indgår resultaterne i nødplan, kontaktliste og øvelser.

Den, der vil afprøve erkendelserne uden at vente på den næste rigtige hændelse, kan gennemspille dem i en [Nødøvelse ved bordet](https://phpsos.de/da/blog/notfalluebung-am-tisch/). Og hvor eftergennemgangen viser, at opdateringer afhang for meget af tilfældigheder, kan det betale sig at ombygge til [Patch management som proces](https://phpsos.de/da/blog/patch-management-prozess/).

For databeskyttelse, forsikring og eventuelt myndigheder er slutrapporten desuden et vigtigt dokument. Den juridiske vurdering, f.eks. om en anmeldelse efter art. 33 GDPR var nødvendig, hører dog hjemme hos databeskyttelsesrådgiver eller advokat, ikke i den tekniske eftergennemgang.

## Hvordan hjælper PHP SOS konkret?

- Vi udarbejder ud fra logs, tickets og noter en tidslinje for hændelsen og markerer huller.
- Vi faciliterer eftergennemgangen som neutral instans og sørger for, at der søges efter årsager i stedet for skyldige.
- Vi omsætter tekniske fund til foranstaltninger med indsatsskøn og prioritet.
- Vi ledsager efterkontrollen og gennemfører på ønske selv tekniske foranstaltninger, som det er forudset i vores [Incident Response](https://phpsos.de/da/leistungen/incident-response/).

## Konklusion

En hændelse er dyr nok. Den, der ikke evaluerer den, betaler en gang til næste gang. En ærlig eftergennemgang uden skyldsfordeling, en ren tidslinje og foranstaltninger med navn og frist gør en vanskelig uge til en varig gevinst i sikkerhed.


## Ofte stillede spørgsmål

**Hvornår bør lessons learned-mødet finde sted?**  
Når hændelsen er teknisk afsluttet, men erindringen stadig er frisk. I praksis har en termin ca. en til to uger efter afslutningen vist sig at fungere. Før mangler ofte afstanden, senere bliver detaljerne udvisket.

**Skal man også holde en eftergennemgang efter en nær-hændelse?**  
Det kan betale sig. En situation som PHP2Shell, hvor der til sidst ikke skete noget, viser alligevel, hvor forløb hakkede. Disse erkendelser er særligt værdifulde, fordi de opstod uden skade.

**Hvem leder eftergennemgangen?**  
Bedst en, der ikke selv har ledet hændelsen operativt. Så forbliver faciliteringen neutral, og ingen skal forsvare sine egne beslutninger. Det kan også være en ekstern leverandør.

**Hvad sker der med resultaterne?**  
Hver erkendelse bliver til en foranstaltning med ansvarlig person og frist. Nødplan, kontaktliste og dokumentation tilpasses. Efter nogle uger kontrollerer nogen, hvad der faktisk blev gennemført.

## Kilder

- [BSI: Oplysninger til virksomheder](https://www.bsi.bund.de/)
- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)
- [GDPR art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)