När det inträffar en avvikelse eller en säkerhetsincident i företaget är det sällan själva händelsen som är det största problemet. Den verkliga risken uppstår när ingen vet vad som ska göras, vem som fattar beslut och hur situationen dokumenteras. ISO 27001 kräver ingen perfektion, utan ett kontrollerat sätt att upptäcka, hantera och förhindra liknande situationer i framtiden.
I denna artikel går vi igenom vad avvikelse och säkerhetsincident praktiskt betyder, hur de relaterar till kraven i ISO 27001 och hur ni bygger en fungerande hanteringsmodell för små och medelstora företag. Ni får också en tydlig handlingsplan som ni kan tillämpa direkt i ert ledningssystem.
Vad betyder avvikelse och säkerhetsincident i praktiken?
En avvikelse är en situation där en överenskommen arbetsmetod, krav eller kontroll inte uppfylls. Det kan till exempel vara att en medarbetares användarrättigheter inte togs bort inom 24 timmar efter anställningens slut, trots att detta är angett i riktlinjerna.
En säkerhetsincident är en allvarligare avvikelse där konfidentialiteten, integriteten eller tillgängligheten av information äventyras. Exempel är kunddata som når fel mottagare, ransomware på en server eller driftstörning i ett kritiskt system.
I praktiken är det klokt för företaget att särskilja dessa två åtminstone på följande sätt:
| Situation | Exempel | Påverkan | Hanteringstid |
|---|---|---|---|
| Avvikelse | Kontroll av backup missades | Potentiell risk, ingen omedelbar skada | Hantering påbörjas inom 5 arbetsdagar |
| Allvarlig avvikelse | Adminkonto utan multifaktorautentisering | Ökad risk för missbruk | Hantering påbörjas inom 24 timmar |
| Säkerhetsincident | Skadlig kod krypterar filer | Direkt påverkan på tillgänglighet | Reaktion omedelbart, senast inom 1 timme |
| Personuppgiftsincident | Kundlista skickades till fel mottagare | Möjlig GDPR-anmälningsplikt | Bedömning omgående, myndighetsbedömning ofta inom 72 timmar |
I många små och medelstora företag är problemet att alla händelser benämns "störning". Då blir brådskan, ansvarsfördelningen och rapporteringen otydliga. Fråga er alltså: Känner personalen igen när det är en vanlig avvikelse och när det rör sig om en säkerhetsincident?
Observera
ISO 27001 kräver inte att avvikelser eller säkerhetsincidenter aldrig ska inträffa. Det kräver att organisationen har ett upprepat sätt att identifiera händelser, reagera på dem, åtgärda grundorsakerna och kunna visa detta även vid revision.
Varför betonar ISO 27001 process för hantering snarare än bara reaktion?
ISO 27001 bygger på tanken om ständig förbättring. Därför är en enskild händelse ur standardens perspektiv inte bara en "släckt brand" utan också en signal om att någon kontroll, rutin eller ansvarsfördelning inte fungerar tillräckligt bra.
Bra avvikelsehantering ger minst tre fördelar:
- ni identifierar återkommande problem innan de blir allvarliga
- ni kan visa för ledning och kunder att situationen är kontrollerad
- ni får material för att förbättra riskbedömningar och kontroller
Om hanteringen blir enbart en teknisk reaktion förloras lärandet. Till exempel kan en server återställas från backup på 4 timmar, men om ingen undersöker varför återställningen överhuvudtaget behövdes kan samma situation upprepas nästa månad.
I en ISO 27001-miljö bör ni minst skriftligt definiera följande:
- vad som räknas som avvikelse
- vad som räknas som säkerhetsincident
- vem som tar emot rapporter
- vem som beslutar om eskalering
- inom vilken tid hantering påbörjas
- hur händelsen dokumenteras och avslutas
En fungerande hanteringsmodell för små och medelstora företag
SMF behöver inte bygga en tung SOC-verksamhet eller ett komplicerat ticketsystem. Ofta räcker en tydlig modell där anmälningskanal, ansvar, klassificering och efterhantering är överenskomna i förväg.
En enkel modell fungerar vanligen bättre än en avancerad men oanvänd process. Om personalen inte minns hur man ska göra på 30 sekunder är den troligen för komplicerad.
Nedan en praktisk ansvarsfördelning som ni kan anpassa:
| Roll | Ansvar vid avvikelse | Ansvar vid säkerhetsincident | Måltid |
|---|---|---|---|
| Personal | Rapportera observation | Rapportera omgående och bevara bevis | Inom 15 minuter från observation |
| IT / systemansvarig | Bedömer teknisk påverkan | Isolerar, avgränsar och återställer | Start inom 1 timme |
| Informationssäkerhetsansvarig / utsedd ansvarig | Klassificerar och dokumenterar | Koordinerar hantering och rapportering | Klassificering inom 4 timmar |
| Ledning | Godkänner korrigerande åtgärder | Beslutar om kommunikation och resurser | Beslut inom 24 timmar |
En konkret miniminivå för SMF är denna:
- en anmälningskanal, t.ex. en särskild e-postadress eller formulär
- en utsedd ansvarig och en ersättare
- en klassificeringsmodell, t.ex. låg–medel–hög
- en avvikelserapport där alla ärenden registreras
Tips
Testa anmälningskanalen omedelbart. Skicka ett testmeddelande och säkerställ att ansvarig kvitterar det inom 15 minuter under arbetstid. Om kvittens inte kommer fungerar inte processen praktiskt än.
Bestäm anmälningskanal och klassificeringsregler
Välj ett primärt sätt att rapportera avvikelse eller säkerhetsincident. Registrera samtidigt tre klasser, t.ex. låg, betydande och kritisk, samt tydliga kriterier som påverkan på kunder, driftstörningens längd och mängden personuppgifter.
Reagera snabbt och begränsa skada
När anmälan kommer är målet att förhindra förvärring. Det kan innebära att stänga användarkonto, koppla bort en enhet från nätverk, kontakta fel mottagare eller återställa tjänst med reservlösning inom 1–4 timmar beroende på allvarlighetsgrad.
Dokumentera händelseuppgifter omgående
Registrera minst vad som hände, när det upptäcktes, vilka som påverkades, vilka system är inblandade och vilka första åtgärder som vidtagits. Vänta inte med dokumentationen till nästa dag, tidslinjen suddas snabbt ut redan efter 2–3 timmar.
Identifiera grundorsak och beslut om åtgärder
När situationen stabiliserats, ta reda på varför händelsen inträffade. Granska t.ex. saknad kontroll, otydlig instruktion, bristande utbildning eller tekniskt fel och ange ansvarig och deadline per korrigerande åtgärd, t.ex. 14 dagar eller 30 dagar.
Avsluta ärendet först när lärandet är infört i praktiken
Markera inte ärendet som klart direkt efter teknisk åtgärd. Avsluta först när korrigerande åtgärd är genomförd, påverkan verifierad och vid behov riskbedömning, instruktioner eller utbildning är uppdaterade.
Vad bör man notera i avvikelserapporten?
Många företag gör misstaget att enbart notera rubrik och datum. Det hjälper inte mycket vid revision och intern utveckling. En bra avvikelserapport synliggör om samma problem återkommer, t.ex. i användarrättigheter, leverantörer eller säkerhetskopiering.
Anteckna för varje ärende minst:
- identifierare eller ärendenummer
- datum och tid för observation
- anmälare
- klassificering och allvarlighetsgrad
- påverkat objekt, t.ex. kunddata, tjänst eller utrustning
- omedelbara åtgärder
- grundorsak
- korrigerande åtgärder
- ansvarig person
- förfallodatum
- avslutsdatum
Vill ni göra registret till ett verkligt ledningsverktyg, lägg till två mått:
| Mätvärde | Hur mäts det | Mål |
|---|---|---|
| Reaktionstid | Tid från observation till första kvittens | Under 1 timme i kritiska fall |
| Avslutstid | Tid från observation till färdig korrigerande åtgärd | 14–30 dagar för vanliga avvikelser |
| Frekvens | Hur många händelser av samma typ under 12 månader | Max 1–2 upprepningar per grundorsak |
| Försenade åtgärder | Hur många korrigerande åtgärder som överskrider deadline | Under 10 % |
Med dessa nyckeltal ser ledningen snabbt om processen är verkligt under kontroll eller bara finns på papper.
Vanligaste misstagen i hantering av avvikelser
Ofta är problemet inte tekniskt utan organisatoriskt. Händelsen upptäcks, men ingen tar ägarskap. Resultatet blir en snabb åtgärd men grundorsaken lever kvar.
Undvik särskilt dessa misstag:
- avvikelser registreras inte om de "åtgärdades snabbt"
- säkerhetsincident förväxlas med vanlig driftstörning
- korrigerande åtgärd anges för generellt, t.ex. "förbättra instruktion"
- inga deadlines sätts eller följs upp
- ledningen får information först i efterhand
Ett konkret exempel: en medarbetare skickar en offert till fel kund. Om ärendet bara kvittas med en påminnelse "vara noggrannare" sker ingen verklig förbättring. En bättre korrigerande åtgärd kan vara:
- införa mottagarbekräftelse för externa utskick
- uppdatera instruktion inom 7 dagar
- utbilda säljteamet på nästa veckomöte
- följa liknande misstag under 3 månader
Varning
Ett vanligt misstag är att avsluta ärendet direkt när den tekniska problemen är åtgärdade. Vid revision syns detta snabbt: händelsen är registrerad, men grundorsak, korrigerande åtgärd och effektbedömning saknas.
Hur kopplas avvikelser och incidenter till ständig förbättring?
Värdet i ISO 27001 kommer av att enskilda händelser förbättrar hela informationssäkerhetens ledningssystem. Varje betydande avvikelse ger information om riskbedömning, kontrollernas effektivitet eller personalens instruktioner.
I praktiken innebär detta att ni efter hanteringen bör granska åtminstone dessa fyra punkter:
- behövs riskbedömningen uppdateras?
- behövs någon kontroll läggas till eller skärpas?
- behövs instruktion eller process uppdateras?
- behövs riktad utbildning för en viss grupp?
En bra månadsrytm för SMF kan vara följande:
| Frekvens | Vad görs | Tid |
|---|---|---|
| Veckovis | Gå igenom öppna ärenden med ansvarig | 15–30 min |
| Månadsvis | Granska trender och försenade åtgärder | 30 min |
| Kvartalsvis | Utvärdera återkommande grundorsaker och uppdatera risker | 60 min |
| Årligen | Använd observationer i ledningens genomgång och intern revision | 1–2 tim |
Om ni använder Tietoturvapankki blir det enklare att koppla avvikelser, korrigerande åtgärder och ansvar till samma helhet som riskhantering, dokumentation och ISO 27001-krav. Det minskar det välkända problemet där information sprids i e-post, Excel och enskilda personers minnen.
Så här kommer ni igång utan tungt projekt
Om ni ännu inte har en tydlig modell, försök inte bygga allt på en gång. Börja i liten skala men gör det grundligt. På en månad kan ni ha en fungerande grundnivå i bruk.
Startlista för kommande 30 dagar:
- utse ansvarig och ersättare
- definiera en anmälningskanal
- skapa en enkel klassificeringstabell
- börja använda avvikelserapport
- kom överens om reaktionstider, t.ex. 1 timme, 24 timmar och 30 dagar
- hantera de första ärendena med denna modell
Detta räcker för att hanteringen av avvikelser inte ska vara slumpmässig. Därefter kan processen utvecklas t.ex. mot leverantörshantering, bedömning av personuppgiftsincidenter och tekniska övervakningslarm.
Sammanfattning
- Avvikelse och säkerhetsincident bör skiljas åt eftersom deras brådskande karaktär, påverkan och rapporteringskrav skiljer sig.
- En fungerande ISO 27001-modell inkluderar anmälningskanal, klassificering, ansvar, deadlines och avvikelserapport.
- Ärendet bör avslutas först när grundorsaken är klarlagd och korrigerande åtgärder är praktiskt genomförda.
- Följ åtminstone reaktionstid, avslutningstid, frekvens och försenade åtgärder.
- SMF kan komma igång lätt när processen är tydlig och används konsekvent.
Behöver ni hjälp med informationssäkerhet?
Våra experter hjälper er vidare.