Incidentplan för småföretag: mall för hemsida och kunddata

En incidentplan är ingen teknisk lösning utan en kort, skriftlig ordning för vem som gör vad de första timmarna efter att något gått fel. Enligt Nationellt cybersäkerhetscenter (NCSC) bör en incidenthanteringsplan förbereda roller, kontaktvägar, resurser och kommunikation i förväg, så att teamet inte behöver komma på allt samtidigt som problemet pågår. För ett litet företag behöver planen inte vara mer avancerad än ett dokument på en sida: en kontaktlista och fyra korta ordningar för de situationer som faktiskt kan inträffa. Den här sidan är en mall att fylla i med era egna namn, telefonnummer och inloggningar, och länkar vidare till fördjupningarna för de vanligaste enskilda händelserna.

Roller och ansvar: vem gör vad

Utse en huvudansvarig för incidentplanen, oftast den person i teamet som redan har mest kontakt med webbhotellet, utvecklaren eller CMS-plattformen. Rollen innebär inte att lösa allt själv, utan att sätta igång planen: bedöma vad som hänt, kalla in rätt kontakt och hålla i tidslinjen. Utse också en ersättare, så att planen fungerar även om huvudpersonen är på semester eller sjuk. I ett riktigt litet företag kan samma person hålla i både den tekniska biten och GDPR-bedömningen, men skriv ändå ner vem som gör vad, så att ingen av delarna glöms bort i stressen. Om ni har en extern utvecklare eller IT-konsult, klargör i förväg om den personen förväntas rycka in samma dag eller om det tar längre tid, så att ni vet vad ni kan räkna med.

Kontaktlista-mall att fylla i

Spara listan nedan tillsammans med övrig dokumentation, gärna både digitalt och utskriven, eftersom ett driftstopp ibland även påverkar tillgången till er egen e-post.

Fyra situationer: definierade steg

Orden för det som kan hända används ofta blandat, men det finns en skillnad värd att känna till. En driftincident handlar om att tjänsten inte fungerar som den ska, till exempel att sajten är nere eller svarar fel, oavsett om orsaken är säkerhetsrelaterad. En informationssäkerhetsincident är bredare och gäller allt som hotar sekretess, riktighet eller tillgänglighet i informationen, till exempel ett intrång, även om inga personuppgifter är inblandade. En personuppgiftsincident är den del av informationssäkerhetsincidenterna som specifikt rör personuppgifter, och är den enda av de tre som kan utlösa anmälningsplikt till IMY. I praktiken överlappar de ofta: ett intrång som exponerar kunduppgifter är både en informationssäkerhetsincident och en personuppgiftsincident.

De fyra vanligaste händelserna nedan delar samma kontaktlista men börjar olika. Läs igenom ordningen innan något har hänt, och fördjupa er i respektive guide vid behov.

Gemensamt för alla fyra är att klockan börjar räkna redan vid upptäckten, inte när utredningen är klar. Enligt Integritetsskyddsmyndigheten (IMY) ska en personuppgiftsincident anmälas inom 72 timmar från det att ni fick vetskap om den, om det inte är osannolikt att den medför risk för de registrerades rättigheter och friheter. Den tidsgränsen gäller även om ni fortfarande är mitt i den tekniska saneringen, så påbörja riskbedömningen parallellt med det akuta arbetet i stället för att vänta tills allt är löst.

När CERT-SE eller extern hjälp behövs

De flesta driftstopp och mindre intrång går att hantera med webbhotellet och en utvecklare. CERT-SE ger stöd vid pågående eller redan inträffade it-säkerhetsincidenter och kan vara relevant att kontakta vid större eller mer komplexa angrepp, och en frivillig rapportering dit kan vara värdefull även för er som inte har någon särskild rapporteringsplikt. Har ni ingen fast IT-konsult sedan tidigare, notera i kontaktlistan vem som skulle kunna anlitas med kort varsel, så att ni inte behöver leta efter hjälp mitt under en pågående incident. Är ni osäkra på om en personuppgiftsincident ska anmälas till IMY, väger en kort avstämning med en dataskyddskunnig rådgivare ofta tyngre än att gissa, eftersom en felaktig bedömning av 72-timmarsregeln kan vara svårare att rätta till i efterhand.

Efter incidenten: dokumentera och öva igen

När det akuta är löst, skriv färdigt tidslinjen för vad som hände. Punkterna nedan går att kopiera in i ett eget dokument som en enkel incidentrapport-mall:

• Datum och klockslag: när incidenten upptäcktes, och av vem.
• Vad hände: kort beskrivning av händelsen och hur den märktes.
• Berörda system och uppgifter: vilka delar av sajten, kontona eller kunduppgifterna som är inblandade.
• Åtgärder hittills: vad som redan gjorts, i tidsordning.
• Personuppgiftsbedömning: om personuppgifter är berörda, och i så fall en kort riskbedömning.
• Vem som informerats: internt och externt, och när.
• Ansvarig för uppföljning: vem som håller i eventuell IMY-anmälan och de sista stegen.

Den ifyllda rapporten är underlag om en kund, ett försäkringsbolag eller IMY frågar i efterhand, och den är samtidigt det bästa materialet för att förbättra planen till nästa gång. Gå igenom hela mallen minst en gång per år även om inget har hänt, och alltid direkt efter en faktisk incident. Testa gärna kontaktlistan genom att faktiskt ringa eller mejla en gång om året i stället för att bara läsa igenom den, eftersom ett nummer som slutat gälla annars upptäcks först mitt i en skarp incident. Kontrollera samtidigt att kontaktuppgifter, inloggningar och ansvarsfördelning fortfarande stämmer, särskilt om någon i teamet har slutat eller bytt roll sedan förra genomgången, och att en säkerhetskopia faktiskt går att återställa och inte bara skapas (se backupstrategi för webbplats). En del av den återkommande rutinen är att se till att delade inloggningar till adminpanel, webbhotell och domänkonto faktiskt är unika och byts när någon lämnar teamet. En lösenordshanterare som NordPass gör det enklare att hålla ordning på vilka konton som är delade och att rotera dem snabbt, utan att lösenord behöver skickas i klartext mellan kollegor.

Vanliga frågor

Annonslänkar: Cronaweb kan få provision om du går vidare via länkarna på sidan.