# Nødkontakter: Hvem skal informeres hvornår?

> Nødkontakter ved it-hændelser: hvem der hører på listen, hvornår hvem informeres, hvilke oplysninger der skal ligge klar, og hvordan listen holdes opdateret.

Kilde: https://phpsos.de/da/blog/notfallkontakte-liste/  
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:** En liste over it-nødkontakter nævner for hver rolle en person med stedfortræder, tilgængeligheden også uden for arbejdstiden, den anledning, hvor personen informeres, og de oplysninger, man skal have klar ved opkaldet. Den foreligger udskrevet og på en adskilt enhed, testes regelmæssigt og indeholder også myndigheder med anmeldelsesfrister. Så går der i en nødsituation ingen tid tabt med at lede.

## Nummeret, som ingen har

En fredag aften viser shoppen mærkelige omdirigeringer, og administratoren har en mistanke. Hvad nu? Ringe til hostingudbyderen, men hvilket nummer gælder uden for arbejdstiden, og hvilket kundenummer skal man bruge? Bureauet, men hvem dér har adgang til serveren? Forsikringen, men hvor står policenummeret? Og hvem beslutter, om shoppen skal tages af nettet?

Sådanne øjeblikke kender mange virksomheder, og PHP2Shell-ugen har mangedoblet dem. Nødplanen foreligger i bedste fald, men kontaktlisten deri er ofte det svageste led: forældet, ufuldstændig eller kun gemt digitalt på netop det system, som lige nu ikke er tilgængeligt. Hvordan planen er opbygget som helhed, beskriver [Udarbejd en it-nødplan for webservere](https://phpsos.de/da/compliance/notfallplan-erstellen/). Her handler det om selve listen.

## Hvem hører på listen over nødkontakter?

Den følgende tabel ordner de typiske kontakter efter den anledning, hvor de informeres, og nævner, hvad man bør have klar ved første kontakt.

| Kontakt | Hvornår informeres | Hvad der skal ligge klar |
|---|---|---|
| Nødledelse (ofte direktionen) | ved enhver mistanke om en hændelse | kort situationsbeskrivelse, første vurdering |
| It-ansvarlige og administratorer | straks, til teknisk kontrol | berørte systemer ifølge oversigten |
| Hostingudbyder (nødkanal) | ved mistanke på serveren, til nedlukning eller logs | kundenummer, kontraktnummer, adgangskode til support |
| Bureau eller udvikler | når applikationen er berørt | projektnavn, adgange, kontaktperson |
| It-sikkerhedsleverandør | ved bekræftet eller sandsynligt indbrud | hidtidige observationer, tidspunkter |
| Databeskyttelsesrådgiver | så snart personoplysninger kan være berørt | datatyper, periode, systemer |
| Cyberforsikring | efter policens krav, som regel tidligt | policenummer, vej for skadesanmeldelse |
| Juridisk rådgivning | ved anmeldelsespligter, afpresning, ansvarsspørgsmål | sagsforhold, hidtidige skridt |
| Databeskyttelsesmyndighed | ved anmeldelsespligtigt databrud, helst inden for 72 timer | oplysninger efter art. 33, stk. 3, GDPR |
| Central kontaktstilling for cyberkriminalitet | ved politianmeldelse af en strafbar handling | beviser, tidslinje |
| BSI | ved anmeldelsespligt efter NIS2 | efter BSI's krav |
| Kommunikation | før enhver information udadtil | afstemte fakta |

Den kompetente centrale kontaktstilling for cyberkriminalitet finder I via politiet i jeres tyske delstat; hvordan anmeldelsen forløber, står under [Anmeld: Centrale kontaktstillinger for cyberkriminalitet](https://phpsos.de/da/compliance/anzeige-polizei-zac/). Hvilke frister og forpligtelser forsikringsselskaber typisk fastsætter, beskriver [Cyberforsikring: Hvad der tæller i skadestilfælde](https://phpsos.de/da/compliance/cyberversicherung/).

## Hvad hver post skal indeholde

Et navn og et telefonnummer er ikke nok. En fuldstændig post besvarer seks spørgsmål:

1. **Rolle:** Hvad er personen ansvarlig for, hvad må vedkommende beslutte?
2. **Navn og stedfortræder:** Hvem træder til, hvis den første person ikke kan nås?
3. **Tilgængelighed:** Telefon, også mobil, og en anden vej. Gælder nummeret også om natten og i weekenden?
4. **Udløser:** Ved hvilken begivenhed informeres denne person?
5. **Legitimation:** Kundenummer, kontraktnummer, supportadgangskode, så opkaldet ikke strander på identitetskontrollen.
6. **Status:** Hvornår blev posten sidst kontrolleret?

Især punkt 5 undervurderes ofte. Hostingudbydere og registrarer kontrollerer telefonisk, om den, der ringer, er berettiget, og det med rette. Den, der først skal lede efter kundeadgangskoden, taber værdifuld tid. Opbevar sådanne oplysninger sikkert, men således at nødledelsen kan få adgang til dem i en nødsituation.

> **Tip:**
> Overtag leverandørers telefonnumre fra kontrakten eller det officielle website, aldrig fra en mail. Svindlere bruger gerne kendte sikkerhedssituationer til falske beskeder med "nødnumre".

## Rækkefølgen i en nødsituation

Ikke alle kontakter er nødvendige på samme tid. Et trinvist forløb har vist sig at fungere: Først nødledelse og teknik, så der opstår en første vurdering, og der kan træffes beslutning om inddæmning. Derefter hostingudbyder, bureau og sikkerhedsleverandør til det tekniske arbejde. Så snart personoplysninger kan være berørt, databeskyttelsesrådgiveren, for fra det tidspunkt, hvor et databrud bliver kendt, løber fristen efter art. 33 GDPR. Forsikring og juridisk rådgivning følger tidligt, før vigtige beslutninger træffes. Kommunikation udadtil kommer til sidst og kun med afstemte fakta.

Hvilke skridt der følger efter den første alarmering, opsummerer [Tjeklisten efter et hack](https://phpsos.de/da/ratgeber/checkliste-nach-dem-hack/). Denne side giver generelle anvisninger; anmeldelsespligter og juridiske spørgsmål afklarer I med databeskyttelsesrådgiveren og en advokat.

Planlæg desuden en anden kommunikationsvej. Er mailserveren berørt, eller er der mistanke om, at en angriber læser med i interne postkasser, bør koordineringen foregå over en adskilt kanal, f.eks. telefonisk eller via en på forhånd oprettet gruppe på en anden tjeneste. Fastlæg denne kanal på forhånd, og tag den med på listen. At lede efter en ny vej i en nødsituation koster tid og skaber usikkerhed om, hvilken besked der er ægte.

## Hold listen levende

Kontaktlister forældes i det stille. Medarbejdere skifter, leverandører ændrer nødnumre, kontrakter udløber. Planlæg derfor to faste kontroltidspunkter om året og et anlediget tidspunkt ved hvert skifte. Et kort testopkald uden for arbejdstiden viser mest pålideligt, om en nødkanal virkelig fungerer. Spørg i den forbindelse også, om personen ved, at vedkommende står på listen, og hvad der forventes af vedkommende i en nødsituation.

## Hvordan hjælper PHP SOS konkret?

- Vi udarbejder sammen med jer listen over tekniske nødkontakter og kontrollerer, om hostingudbydere og bureauer faktisk har en nødkanal.
- Vi fastlægger, hvilke oplysninger der skal ligge klar for hver kontakt, så et opkald straks får virkning.
- Vi ledsager et testforløb for alarmeringen og indarbejder hullerne i jeres dokumenter.
- I en nødsituation står vi som teknisk kontaktperson via [Incident Response](https://phpsos.de/da/leistungen/incident-response/) på jeres liste.

**Konklusion:** En god kontaktliste er kort, fuldstændig og testet. Den afgør, om hændelsens første timer går med at handle eller med at lede.


## Ofte stillede spørgsmål

**Hvem hører på en liste over it-nødkontakter?**  
Internt direktion, it, databeskyttelsesrådgiver og kommunikation, eksternt hostingudbyder, bureau, it-sikkerhedsleverandør, cyberforsikring, juridisk rådgivning, den kompetente databeskyttelsesmyndighed og den centrale kontaktstilling for cyberkriminalitet (Zentrale Ansprechstelle Cybercrime, ZAC) i den tyske delstat, ved NIS2-pligt desuden BSI (det tyske forbundsagentur for informationssikkerhed).

**Hvor opbevarer jeg nødkontakterne?**  
Mindst to steder, hvoraf det ene kan nås uden egen it, f.eks. udskrevet i nødmappen og på en adskilt enhed. En liste, der kun ligger i mailpostkassen eller på den berørte server, er ikke tilgængelig i en nødsituation.

**Hvor ofte bør listen kontrolleres?**  
Mindst to gange om året og efter hvert skifte af medarbejdere eller leverandører. Et kort testopkald viser, om numrene passer, og om personerne ved, at de står på listen.

**Skal databeskyttelsesmyndigheden altid informeres?**  
Ikke ved hver hændelse. Art. 33 GDPR kræver en anmeldelse ved et brud på sikkerheden for personoplysninger, helst inden for 72 timer, medmindre bruddet næppe indebærer en risiko for de berørte. Vurderingen foretager I sammen med databeskyttelsesrådgiveren; denne side er ikke juridisk rådgivning.

## Kilder

- [GDPR art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Politiet: ZAC-oversigt](https://www.polizei.de/)
- [BSI](https://www.bsi.bund.de/)