# Nödkontakter: vem måste informeras och när?

> Nödkontakter vid IT-incidenter: vem som hör hemma på listan, när vem informeras, vilka uppgifter som behövs och hur listan hålls aktuell.

Källa: https://phpsos.de/sv/blog/notfallkontakte-liste/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** En lista över IT-nödkontakter anger för varje roll en person med ersättare, nåbarhet även utanför kontorstid, den händelse som utlöser information och de uppgifter man måste ha till hands vid samtalet. Den finns utskriven och på en separat enhet, testas regelbundet och omfattar även myndigheter med anmälningsfrister. Så går ingen tid förlorad på letande i ett skarpt läge.

## Numret som ingen har

En fredagskväll visar webbshoppen märkliga omdirigeringar och administratören har en misstanke. Vad nu? Ringa hostingleverantören, men vilket nummer gäller utanför kontorstid och vilket kundnummer behövs? Byrån, men vem där har åtkomst till servern? Försäkringen, men var står försäkringsnumret? Och vem avgör om webbshoppen tas ner?

Sådana ögonblick känner många företag igen, och PHP2Shell-veckan har mångdubblat dem. Krisplanen finns i bästa fall, men kontaktlistan i den är ofta den svagaste länken: föråldrad, ofullständig eller bara lagrad digitalt på just det system som inte är tillgängligt. Hur planen som helhet är uppbyggd beskriver [Ta fram en IT-krisplan för webbservrar](https://phpsos.de/sv/compliance/notfallplan-erstellen/). Här handlar det om själva listan.

## Vem hör hemma på listan över nödkontakter?

Följande tabell ordnar de typiska kontakterna efter den händelse som utlöser information och anger vad man bör ha till hands vid första kontakten.

| Kontakt | När informeras | Vad som ska finnas till hands |
|---|---|---|
| Krisledning (ofta ledningen) | vid varje misstanke om en incident | kort lägesbild, första bedömning |
| IT-ansvariga och administratörer | omedelbart, för teknisk prövning | berörda system enligt förteckningen |
| Hostingleverantör (nödkanal) | vid misstanke på servern, för avstängning eller loggar | kundnummer, avtalsnummer, lösenord för supporten |
| Byrå eller utvecklare | om applikationen berörs | projektnamn, åtkomster, kontaktperson |
| IT-säkerhetsleverantör | vid bekräftat eller sannolikt intrång | hittillsvarande iakttagelser, tidpunkter |
| Dataskyddsombud | så snart personuppgifter kan beröras | datatyper, tidsperiod, system |
| Cyberförsäkring | enligt försäkringsbrevets krav, oftast tidigt | försäkringsnummer, skadeanmälningsväg |
| Juridisk rådgivning | vid anmälningsplikt, utpressning, ansvarsfrågor | sakläge, hittillsvarande steg |
| Dataskyddsmyndighet | vid anmälningspliktig personuppgiftsincident, om möjligt inom 72 timmar | uppgifter enligt art. 33.3 GDPR |
| Zentrale Ansprechstelle Cybercrime (ZAC, polisens centrala kontaktpunkt för it-brott) | vid polisanmälan av ett brott | bevis, tidslinje |
| BSI (tyska förbundskontoret för informationssäkerhet) | vid anmälningsplikt enligt NIS2 | enligt BSI:s anvisningar |
| Kommunikation | före varje information utåt | avstämda fakta |

Den behöriga ZAC hittar ni via polisen i er tyska delstat; hur anmälan går till står under [Göra polisanmälan: centrala kontaktpunkter för it-brott](https://phpsos.de/sv/compliance/anzeige-polizei-zac/). Vilka frister och skyldigheter försäkringar typiskt sätter beskriver [Cyberförsäkring: vad som räknas vid skada](https://phpsos.de/sv/compliance/cyberversicherung/).

## Vad varje post måste innehålla

Ett namn och ett telefonnummer räcker inte. En fullständig post besvarar sex frågor:

1. **Roll:** Vad ansvarar personen för, vad får hen besluta?
2. **Namn och ersättare:** Vem hoppar in om den första personen inte kan nås?
3. **Nåbarhet:** Telefon, även mobil, och en andra väg. Gäller numret också nattetid och på helger?
4. **Utlösare:** Vid vilken händelse informeras personen?
5. **Legitimation:** Kundnummer, avtalsnummer, supportlösenord, så att samtalet inte strandar på identitetskontrollen.
6. **Datum:** När kontrollerades posten senast?

Särskilt punkt 5 underskattas ofta. Hostingleverantörer och registrarer kontrollerar per telefon om den som ringer är behörig, och det med rätta. Den som först måste leta efter kundlösenordet förlorar värdefull tid. Förvara sådana uppgifter säkert, men så att krisledningen kan komma åt dem i ett skarpt läge.

> **Tips:**
> Hämta leverantörers telefonnummer från avtalet eller den officiella webbplatsen, aldrig från ett e-postmeddelande. Bedragare utnyttjar gärna kända säkerhetslägen för falska meddelanden med ”nödnummer”.

## Ordningsföljden i ett skarpt läge

Alla kontakter behövs inte samtidigt. Ett stegvis tillvägagångssätt har visat sig fungera: Först krisledning och teknik, så att en första bedömning görs och ett beslut om avgränsning kan fattas. Därefter hostingleverantör, byrå och säkerhetsleverantör för det tekniska arbetet. Så snart personuppgifter kan beröras dataskyddsombudet, eftersom fristen enligt art. 33 GDPR löper från det att en personuppgiftsincident blir känd. Försäkring och juridisk rådgivning följer tidigt, innan viktiga beslut fattas. Kommunikation utåt kommer sist och bara med avstämda fakta.

Vilka steg som följer efter den första larmningen sammanfattar [checklistan efter ett hack](https://phpsos.de/sv/ratgeber/checkliste-nach-dem-hack/). Den här sidan ger allmänna anvisningar; anmälningsplikt och juridiska frågor klarlägger ni med dataskyddsombud och advokat.

Planera dessutom in en andra kommunikationsväg. Är e-postservern berörd eller finns misstanke om att en angripare läser interna brevlådor bör samordningen gå via en separat kanal, till exempel per telefon eller via en i förväg upprättad grupp hos en annan tjänst. Bestäm den kanalen i förväg och för in den i listan. Att i ett skarpt läge söka en ny väg kostar tid och skapar osäkerhet om vilket meddelande som är äkta.

## Håll listan levande

Kontaktlistor föråldras tyst. Medarbetare byter, leverantörer ändrar nödnummer, avtal löper ut. Planera därför två fasta kontrolltillfällen om året och ett tillfälle vid varje förändring. Ett kort testsamtal utanför kontorstid visar tillförlitligast om en nödkanal verkligen fungerar. Fråga då också om personen vet att hen står på listan och vad som förväntas av hen i ett skarpt läge.

## Hur hjälper PHP SOS konkret?

- Vi tar tillsammans med er fram listan över tekniska nödkontakter och kontrollerar om hostingleverantörer och byråer verkligen har en nödkanal.
- Vi fastställer vilka uppgifter som måste finnas till hands per kontakt så att ett samtal får effekt direkt.
- Vi följer en provkörning av larmningen och arbetar in luckorna i era underlag.
- I ett skarpt läge står vi på er lista som teknisk kontaktperson via [Incident Response](https://phpsos.de/sv/leistungen/incident-response/).

**Slutsats:** En bra kontaktlista är kort, komplett och testad. Den avgör om de första timmarna av en incident går åt till att agera eller till att leta.


## Vanliga frågor

**Vem hör hemma på en lista över IT-nödkontakter?**  
Internt ledning, IT, dataskyddsombud och kommunikation, externt hostingleverantör, byrå, IT-säkerhetsleverantör, cyberförsäkring, juridisk rådgivning, den behöriga dataskyddsmyndigheten och den centrala kontaktpunkten för it-brott (Zentrale Ansprechstelle Cybercrime) i er tyska delstat, vid NIS2-skyldighet dessutom BSI.

**Var förvarar jag nödkontakterna?**  
På minst två ställen, varav ett kan nås utan den egna IT:n, till exempel utskrivet i krismappen och på en separat enhet. En lista som bara ligger i e-postlådan eller på den drabbade servern är inte tillgänglig i ett skarpt läge.

**Hur ofta bör listan kontrolleras?**  
Minst två gånger om året och efter varje byte av personal eller leverantör. Ett kort testsamtal visar om numren stämmer och om personerna vet att de står på listan.

**Måste dataskyddsmyndigheten alltid informeras?**  
Inte vid varje incident. Art. 33 GDPR kräver en anmälan vid en personuppgiftsincident, om möjligt inom 72 timmar, såvida den sannolikt inte medför någon risk för de registrerade. Bedömningen gör ni tillsammans med dataskyddsombudet; den här sidan är ingen juridisk rådgivning.

## Källor

- [GDPR art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polisen: översikt över ZAC](https://www.polizei.de/)
- [BSI](https://www.bsi.bund.de/)
