# Skapa en IT-beredskapsplan för webbservrar

> Skapa en IT-beredskapsplan för webbservrar: roller, kontakter, systemförteckning, beslutsregler och rapporteringsvägar, så att allt sitter i skarpt läge.

Källa: https://phpsos.de/sv/compliance/notfallplan-erstellen/  
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 IT-beredskapsplan för webbservrar fastställer i förväg vem som beslutar i skarpt läge, vem man når, vilka system som kan vara berörda och vilka steg som följer i vilken ordning. Den som vill skapa en IT-beredskapsplan behöver ingen tjock handbok utan några få aktuella sidor som går att nå även utan fungerande IT. Läget kring PHP2Shell är en bra anledning att göra det nu.

## Varför en beredskapsplan sparar tid och skada

I skarpt läge går de första timmarna ofta förlorade på att leta: Vem har åtkomst till webbhotellet? Var finns säkerhetskopiorna? Vem beslutar om butiken ska gå offline? Vem måste informeras? En beredskapsplan besvarar de frågorna i förväg, i lugn och ro.

PHP2Shell har visat hur kort tiden kan vara. Den 20 oktober 2026 aviserade php.net patcharna, den 21 oktober klockan 16:00 tysk tid publicerades de, och BSI (den tyska förbundsmyndigheten för informationssäkerhet) rekommenderade omedelbar uppdatering eller tillfällig avstängning. Företag med en plan visste vem de skulle ringa och vilka servrar de behövde kontrollera. Andra var först tvungna att ta reda på var PHP över huvud taget körs.

## Skapa IT-beredskapsplan: byggstenarna

En praktikduglig plan för webbservrar omfattar följande delar:

**1. Roller och beslut.** Vem leder i en nödsituation, vem är ersättare, vem får stänga av system, vem talar utåt? Anteckna namn och ersättare.

**2. Kontaktlista.** Interna kontaktpersoner, webbhotell, byrå, IT-leverantör, dataskyddsombud, juridisk rådgivning, cyberförsäkring med försäkringsnummer, behörig dataskyddstillsyn, den centrala kontaktpunkten för cyberbrott (ZAC) i er delstat. Den här listan måste finnas utskriven.

**3. Systemförteckning.** Varje webbplats, butik och portal med server, webbhotell, driftläge, PHP-version, applikation, ansvarig och typ av behandlade uppgifter.

**4. Beslutsregler.** Under vilka villkor tar vi ett system offline? Vem får besluta det? Vad gäller på natten och på helger?

**5. Förlopp.** Korta stegföljder för typiska fall: kritisk sårbarhet känd, misstanke om intrång, webbplats vanställd, uppgifter läckta, utpressning.

**6. Rapporteringsvägar.** Vem prövar en anmälningsplikt enligt art. 33 GDPR, om möjligt inom 72 timmar från det att ni fick kännedom? Vem rapporterar till BSI vid NIS2-plikt? Vem informerar försäkringsgivaren?

**7. Återställning.** Var finns säkerhetskopiorna, vem kan återställa dem, hur lång tid tar det, när testades det senast?

## Exempel: förloppet ”kritisk PHP-sårbarhet”

Så kan ett förlopp se ut, som det behövdes vid PHP2Shell:

| Steg | Vem | Resultat |
|---|---|---|
| Bedöma meddelandet (php.net, BSI) | IT-ansvariga | berörda system enligt förteckningen |
| Installera uppdatering, starta om alla workers | Admin eller leverantör | Belägg med paketstatus och processtid |
| Där ingen uppdatering är möjlig: tillfälliga åtgärder eller offline | Ledningen beslutar | dokumenterat beslut |
| Säkra loggar, kontrollera spår | Admin eller forensik | Fynd eller inget fynd |
| Vid fynd: starta incidentförloppet | Beredskapsledning | pröva rapporteringsvägar |

Viktigt här: en patch stänger sårbarheten men tar inte bort skadlig programvara som fördes in tidigare. Därför hör spårsökningen fast till förloppet.

> **Tips:**
> Fastställ hur länge webbserverloggar sparas och var de ligger utanför servern. Vid PHP2Shell rekommenderade facktidningarna att spara loggar från och med den 20 oktober 2026. Den som bara behåller loggar några få dagar kan inte följa sådana rekommendationer.

## Förberedelser som gör planen verksam

En plan är bara så bra som förutsättningarna bakom den. Kontrollera om säkerhetskopior enligt 3-2-1-regeln finns och är testade, se [Säkerhetskopior enligt 3-2-1-regeln](https://phpsos.de/sv/ratgeber/backups-3-2-1/). Klargör skriftligt med webbhotell och byrå vem som tar över vad vid kritiska sårbarheter. Förvara inloggningsuppgifter för nödsituationer säkert men nåbart, till exempel i ett skyddat lösenordsvalv med nödåtkomst.

Förbered dessutom textmallar: intern information, kundmeddelande, meddelande på en statisk underhållssida. Anvisningar om det finns under [Kriskommunikation efter ett angrepp](https://phpsos.de/sv/compliance/krisenkommunikation/).

## Öva och hålla planen aktuell

En plan som aldrig har övats innehåller nästan alltid luckor. Spela en gång om året igenom ett scenario, till exempel ”kritisk PHP-sårbarhet fredag eftermiddag”, och anteckna var det hakar upp sig. Ett enkelt test räcker till att börja med: kan en andra person utan hjälp av den första nå webbhotellet, återställa en säkerhetskopia och försätta webbplatsen i underhållsläge? Om inte saknas något i planen, oftast en åtkomst, ett telefonnummer eller en beskrivning. Just sådana luckor ska övningar synliggöra innan det blir allvar. Uppdatera planen efter varje övning och varje väsentlig förändring. Som metodiskt ramverk passar BSI:s IT-Grundschutz och BSI-Standard 200-4 om Business Continuity Management.

Rättsliga frågor, till exempel om anmälningsplikter, klarar planen inte ut slutgiltigt. Den ser till att rätt personer kopplas in i tid. Den här sidan är allmän information och ingen juridisk rådgivning.

## Hur hjälper PHP SOS konkret?

- Vi upprättar tillsammans med er systemförteckningen över era webbservrar, inklusive driftläge och PHP-version.
- Vi skriver de tekniska förloppen för typiska scenarier och samordnar dem med webbhotell och byrå.
- Vi genomför en övning och arbetar in insikterna i planen.
- I skarpt läge tar vi över den tekniska sidan via [Incident Response](https://phpsos.de/sv/leistungen/incident-response/), på begäran säkrat genom ett [säkerhetsunderhållsavtal](https://phpsos.de/sv/leistungen/security-wartungsvertrag/).


## Vanliga frågor

**Hur omfattande måste en IT-beredskapsplan vara?**  
Så kort som möjligt, så utförlig som nödvändigt. För webbservrar räcker det ofta med några få sidor med kontakter, systemlista, beslutsregler och förlopp. Viktigare än omfånget är att den är aktuell och hittas i skarpt läge.

**Var förvarar jag beredskapsplanen?**  
På minst ett ställe som går att nå även utan fungerande IT, till exempel utskriven eller på en fristående enhet. En plan som bara ligger på den drabbade servern eller i det spärrade företagsnätet hjälper inte i skarpt läge.

**Hur ofta bör planen kontrolleras?**  
Minst en gång om året och efter varje väsentlig förändring, till exempel byte av webbhotell eller ny programvara. Meningsfullt är en kort övning där ett scenario spelas igenom.

**Finns det mallar från BSI?**  
BSI behandlar beredskapshantering inom ramen för IT-Grundschutz och i BSI-Standard 200-4 om Business Continuity Management. De passar som ramverk; för webbservrar lönar sig en kortfattad, praktiknära version.

## Källor

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [BSI](https://www.bsi.bund.de/)
- [GDPR art. 33](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [Polisen: ZAC-översikt](https://www.polizei.de/)