Be tio företag att visa sin riskhantering och nio öppnar ett kalkylark. Det har några dussin rader, en färgkodad sannolikhetskolumn och ett senast-ändrat-datum från förra revisionen. Det ser ut som riskhantering. I själva verket är det en ögonblicksbild som slutade vara sann dagen efter att någon sparade den.

Riskhantering inom informationssäkerhet är inte ett dokument du tar fram åt en revisor. Det är processen som avgör var du lägger din begränsade säkerhetsbudget: vad som kan gå fel, hur illa det blir och vad du tänker göra åt det. ISO 27005 beskriver processen och ISO 27001 kapitel 6 gör den till ett krav. Den här guiden går igenom processen från början till slut och visar hur OptiTech håller den levande i stället för att låta den ruttna i ett kalkylark.

Börja med sammanhang och kriterier

Innan du listar en enda risk bestämmer du vad du bedömer och hur du ska döma det. Det är den delen team hoppar över, och det är därför deras riskregister blir listor av äpplen och päron som ingen litar på.

Att fastställa sammanhanget betyder att namnge omfattningen: vilka delar av verksamheten, vilka system och vilken information bedömningen täcker. Det betyder också att sätta dina kriterier i förväg. Du definierar skalan du använder för sannolikhet och konsekvens, så att ett "högt" från en person betyder samma sak som ett "högt" från en annan. Och du sätter dina acceptanskriterier: gränsen över vilken en risk kräver behandling och under vilken du är beredd att leva med den.

Skriv ner kriterierna en gång och återanvänd dem för varje riskbedömning. När skalan bor i OptiTech Console i stället för i varje analytikers huvud blir ditt register jämförbart mellan team och mellan år. Den samstämmigheten är vad som låter dig säga "det här är våra fem största risker" och faktiskt mena det.

Identifiera riskerna: tillgångar och scenarier

Det finns två ärliga sätt att hitta risker på, och mogna program använder båda.

Tillgångsbaserad identifiering

Utgå från det du skyddar. Lista dina informationstillgångar: kunddata, källkod, personalregister, systemen som håller dem och personerna och leverantörerna som rör dem. För varje tillgång, fråga vilka hot som gäller och vilken svaghet ett hot skulle kunna utnyttja. En bärbar dator med kunddata står inför stöld, skadlig kod och ett oförsiktigt klick. Tillgången gör risken konkret.

Scenariobaserad identifiering

Tillgångslistor missar riskerna som korsar flera system. Så du utgår också från scenarier: en nätfiskekampanj som samlar in administratörsuppgifter, en nyckelleverantör som ligger nere en vecka, en anställd som slutar men fortfarande har åtkomst. Scenarier fångar kedjorna av händelser som en platt tillgångslista slätar ut. Kör båda så täcker du betydligt mer mark än någon av dem gör ensam.

Analysera sannolikhet och konsekvens

För varje risk du identifierat uppskattar du två saker: hur sannolikt det är att den inträffar, och hur mycket det skulle svida om den gjorde det. Kombinera dem med kriterierna du satte tidigare, så får du en risknivå du kan rangordna.

Håll analysen ärlig snarare än exakt. Du räknar inte fram en sannolikhet på tre decimaler; du skiljer de risker som kan sänka dig från dem som skulle svida. Konsekvensen handlar inte bara om pengar heller. Ett intrång i kunddata bär rättslig, ryktesmässig och operativ kostnad, och en bra analys namnger alla tre. Poängen är en rangordnad lista, så att nästa beslut, vad du behandlar först, blir självklart.

Utvärdera mot din riskaptit

En risknivå säger i sig inte vad du ska göra. Du jämför den mot din riskaptit: hur mycket risk verksamheten är villig att acceptera för att nå sina mål. En risk som ligger över din aptit kräver behandling. En som ligger under den kan accepteras, medvetet och dokumenterat.

Riskaptit är ett ledningsbeslut, inte en analytikers gissning. När den är nedskriven och tillämpas konsekvent slutar utvärderingen vara en dragkamp. Registret sorterar sig självt i "behandla den här" och "acceptera den här", och alla kan se varför varje risk hamnade där den gjorde.

Välj en riskbehandling

När en risk klarar tröskeln för åtgärd väljer du ett av fyra svar:

• Reducera. Inför kontroller som minskar sannolikheten, konsekvensen eller båda. Det är den vanligaste vägen och den som knyter risken till ditt framework.
• Överföra. Flytta en del av risken till en tredje part, genom försäkring eller en avtalsklausul med en leverantör.
• Undvika. Sluta göra aktiviteten som skapar risken. Ibland är funktionen eller leverantören inte värd den.
• Acceptera. Bedöm att risken är tolerabel, och notera vem som accepterade den och varför.

Varje val kommer med en behandlingsplan: vad du ska göra, vem som äger den och till när. I ISO 27001-termer är det reduceringen som ger din tillämplighetsförklaring, eftersom kontrollerna du väljer för att behandla risker är precis de du förklarar tillämpliga.

Utse en riskägare och följ restrisken

En risk utan ägare är en risk ingen hanterar. Varje risk i ditt register behöver en namngiven person som är ansvarig för behandlingen, inte ett team eller en avdelning. Riskägaren avgör om planen fungerar och när risken kan stängas eller ombedömas.

Behandling driver sällan en risk till noll. Det som återstår när dina kontroller är på plats är restrisken, och det är den siffra ledningen faktiskt behöver. Du följer den bredvid den ursprungliga nivån, så att du kan visa att en hög risk nu är måttlig därför att specifika kontroller är i drift. När någon frågar "är det här hanterat" är restrisken svaret, och det ska backas av bevis på att kontrollerna är verkliga.

Därför dör kalkylarket, och vad du gör i stället

Ett kalkylarksregister havererar av en förutsägbar orsak: inget kopplar det till resten av ditt program. Riskerna sitter i en fil, kontrollerna i en annan och bevisen i en delad enhet ingen underhåller. Ägare byter jobb, skalan glider, och till nästa revision är halva raderna fiktion. Registret är inte fel för att folk är slarviga. Det är fel för att ett kalkylark inte kan hålla takten med en verksamhet i rörelse.

OptiTech håller registret levande genom att koppla ihop det med allt runtomkring. Varje risk länkas till kontrollerna som behandlar den, och varje kontroll länkas till bevisen som visar att den är i drift. När en kontrolls bevis blir inaktuellt är restrisken på varje risk den behandlar osäker, och du ser det. Riskägare får sina behandlingsplaner som spårat arbete, inte som en cell de glömde uppdatera. Eftersom risker, kontroller och bevis delar ett och samma program blir "visa mig våra största risker och bevisa att de är hanterade" en vy i OptiTech Console i stället för en vecka av arkeologi.

Kom igång

Du behöver ingen perfekt metodik för att börja. En realistisk första omgång ser ut så här:

1. Sätt dina kriterier. Definiera dina skalor för sannolikhet och konsekvens och din acceptansgräns innan du listar något.
2. Identifiera en första omgång risker. Kör en tillgångsbaserad genomgång och en scenariobaserad, och rangordna dem sedan.
3. Utse ägare och behandlingar. Ge varje risk över din aptit en namngiven riskägare och en daterad plan.
4. Länka risker till kontroller och bevis så att restrisken förblir ärlig och ditt framework och register rör sig tillsammans.

Riskhantering belönar de företag som behandlar det som en vana snarare än en årlig övning. Bygg kriterierna en gång, håll registret sammankopplat, så berättar samma process som nöjer din revisor exakt var din ledning ska satsa härnäst.

Redo att göra ditt riskregister till ett levande program? Boka en demo och se hur OptiTech knyter ihop dina risker, kontroller och bevis.