Öva kommunikation, inte bara teknik och beslut

Det är inte fel att öva så, men det missar en stor del av verkligheten. Under en riktig cyberincident uppstår kommunikationsproblemen parallellt med den tekniska osäkerheten, inte efter att den är löst. Journalisten ringer medan forensikerna fortfarande försöker förstå vad loggarna betyder, en kund kräver svar innan legal är klar med sin bedömning, en medarbetare lägger ut en skärmdump på sociala medier och en leverantör säger något offentligt som inte riktigt stämmer med den egna lägesbilden. Det som kommunicerades för två timmar sedan kan dessutom behöva nyanseras när organisationen vet mer.

Det är den verkligheten kommunikationsdelen av en cyberövning behöver efterlikna.

NCSC rekommenderar att intern och extern kommunikation byggs in i cyberövningsscenarier och att realistiska händelser, så kallade injects, används för att pröva hur organisationen reagerar och fattar beslut. Men det viktiga är inte hur dramatisk övningen blir. Det är vilka förmågor den faktiskt sätter på prov.

01 Bestäm vad ni vill lära er om kommunikationen

"Vi ska öva kriskommunikation" är ungefär lika precist som "vi ska öva IT". Innan scenariot byggs behöver ni bestämma vilken kommunikativ förmåga ni faktiskt vill pröva.

Kanske vill ni se hur lång tid det tar innan kommunikationsfunktionen får en tillräckligt stabil lägesbild för att kunna säga något. Kanske är det godkännandeflödet mellan kommunikation, säkerhet och legal som behöver stressas. Kanske vill ni pröva om account managers får rätt information när stora kunder börjar ringa, om organisationen kan kommunicera när Microsoft 365 ligger nere eller om vd kan hantera en intervju där journalisten sitter på mer information än organisationen har publicerat.

Målet kan också vara smalare: Kan vi få ut en viktig instruktion till alla medarbetare om de ordinarie kanalerna ligger nere? Kan kundservice få ett uppdaterat budskapsunderlag inom femton minuter? Kan organisationen korrigera felaktig information utan att skapa ännu mer förvirring?

När målet är konkret blir övningen bättre, eftersom scenariot kan byggas för att skapa just det problem ni vill förstå. Varje större inject bör därför ha ett syfte. Vad är det tänkt att deltagarna ska upptäcka, besluta eller göra när det inträffar?

02 Låt kommunikationen börja innan ni har svaren

En bra kommunikationsövning bör göra deltagarna lite obekväma på rätt sätt. Inte genom att vara elak eller konstruerat dramatisk, utan genom att ge dem den informationsbrist som verkliga incidenter nästan alltid innehåller.

Klockan 09.10 vet IT att ett antal system inte fungerar men inte varför. Klockan 09.25 hör en journalist av sig och säger att en ransomwaregrupp påstår sig ha attackerat organisationen. Klockan 09.40 börjar kunder skriva om problemen på LinkedIn. Teknikteamet har fortfarande inte verifierat om angriparen faktiskt finns i miljön.

Vad kommunicerar ni nu?

Om övningen istället väntar tills klockan 11.30, när scenarioteamet generöst har berättat exakt vad som hänt, hur många system som är drabbade och vilken data som exfiltrerats, testar ni främst deltagarnas förmåga att skriva en text när underlaget är färdigt. Det är användbart, men det är inte samma sak som cyberkriskommunikation.

Öva istället på att säga det ni faktiskt vet, skilja verifierade fakta från antaganden och vara tydliga med vad som fortfarande undersöks. Låt också deltagarna behöva avgöra när det är bättre att kommunicera ett begränsat besked än att fortsätta vänta på fullständig information.

03 Ge olika deltagare olika information

I verkligheten sitter inte alla runt samma bord och tittar på samma PowerPoint. Säkerhetsteamet vet saker som kommunikationsfunktionen ännu inte fått, kundservice märker problem som incidentledningen inte hunnit koppla till incidenten och en extern leverantör kan ha publicerat en uppgift som legal ser först.

En bra övning kan därför ge olika injects till olika roller. Kommunikationschefen får en medieförfrågan, IT får ett nytt forensiskt fynd, vd får ett sms från en stor kund och HR får höra att en medarbetare publicerat något om incidenten privat. Nu måste organisationen skapa informationsflöden, inte bara reagera på ett gemensamt manus.

Det är ett effektivt sätt att upptäcka om den organisatoriska kartan är felritad. Kanske förväntar sig kommunikation att säkerhet automatiskt kommer med verifierade fakta, medan säkerhet antar att kommunikation sitter med i incidentledningen och hör allt. I en plan kan båda antagandena se rimliga ut. I en övning blir luckan snabbt tydlig.

Testa också informationsflödet åt andra hållet. Om kundservice får fem samtal om samma symptom, flera medarbetare rapporterar oväntade MFA-förfrågningar eller en journalist frågar om något incidentteamet trodde var okänt utanför organisationen, når den informationen tillbaka till incidentledningen?

Kommunikationsfunktionen är inte bara mottagare av den tekniska lägesbilden. Under en incident kan kommunikation, kundservice, chefer och andra verksamhetsnära funktioner också bli sensorer som fångar upp nya signaler. Det är värt att öva.

04 Öva riktiga leverabler och riktiga kanaler

Diskussion är användbar, men den kan göra oss generösare mot vår egen förmåga än verkligheten kommer vara. "Då skulle vi förstås informera alla kunder" låter enkelt runt ett konferensbord.

Låt därför deltagarna faktiskt göra delar av arbetet. Skriv det första medarbetarbudskapet med den information som finns just då. Ta fram ett holding statement. Gör en treminuters briefing till vd. Uppdatera en fejkad krissida. Ge kundservice ett budskapsunderlag och låt någon spela journalist och ställa följdfrågor.

Inget behöver publiceras på riktigt. Poängen är produktionen, eftersom den synliggör sådant som diskussionen missar. Hur lång tid tar faktagranskningen? Vem måste godkänna? Vilka formuleringar blir konfliktpunkter? Vilken information saknas för att kunden över huvud taget ska få ett användbart svar?

Öva också själva distributionsvägen. Om planen säger att ni använder en alternativ kanal när Microsoft 365 ligger nere, använd den under övningen. Om chefer ska få en briefing via en särskild väg, skicka den den vägen. Om en krissida ska kunna publiceras utan den vanliga webbmiljön, pröva hur det faktiskt går till.

En reservkanal som står i en plan men som ingen hittar, kommer in i eller har aktuella kontaktuppgifter till är inte mycket till reservkanal.

05 Lägg in verkliga kommunikationsproblem, inte bara fler dramatiska fakta

Ett kommunikativt inject behöver inte vara "BBC ringer". Det kan vara mycket mer vardagligt och därför mer avslöjande.

En chef vidarebefordrar gammal information till sitt team efter att läget förändrats. Kundservice använder fortfarande en FAQ från förmiddagen. En leverantör publicerar att "ingen kunddata har påverkats", trots att er egen analys ännu inte kan fastställa det. En medarbetare frågar om hen får gå hem eftersom de digitala passersystemen ligger nere. Styrelseordföranden vill ha ett definitivt besked om återställningstid eftersom en viktig kund ska ringas om tio minuter.

Lägg gärna också in problem som handlar om prioritering. Tre målgrupper behöver information samtidigt, men kommunikationsfunktionen har bara kapacitet att hantera en sak först. En tekniskt korrekt uppdatering är för svår för kundservice att använda. Ledningen vill publicera något snabbt medan incidentteamet tycker att faktaläget är för osäkert. En ny uppgift gör att gårdagens formulering fortfarande är sann men riskerar att bli missvisande.

Sådana situationer testar om kommunikationen fungerar som system, inte bara om kommunikationschefen kan skriva pressmeddelanden.

De hjälper också organisationen se vilka delar som behöver förberedas som struktur snarare än färdig text. En mall för lägesuppdateringar, ett tydligt format för known/unknown, förberedda målgrupper och kontaktvägar och ett etablerat sätt att distribuera verifierade fakta internt kan visa sig betydligt mer värdefullt än fem färdigskrivna pressmeddelanden om incidenter som sannolikt aldrig kommer se ut exakt som övningsscenariot.

06 Utvärdera systemet, inte bara snabbheten

"Tid till första uttalande" kan vara ett användbart mått, men ett snabbt felaktigt uttalande är ingen imponerande krisförmåga.

Utvärdera därför hela kommunikationsflödet. När kopplades kommunikation in? Hur snabbt fick funktionen tillgång till verifierad information? Prioriterades rätt intressenter? Kunde organisationen skilja mellan verifierat och osäkert? Hur många versioner av samma fakta började cirkulera? Var fastnade godkännanden? Fungerade reservkanalerna? Kom frågor och signaler från verksamheten tillbaka till incidentledningen? Fick mottagaren faktiskt ett begripligt svar på vad incidenten innebar för just dem?

Var också försiktig med slutsatsen att en enskild person "kommunicerade dåligt". Om kommunikationschefen behövde vänta fyrtio minuter på verifierade fakta, tre personer behövde godkänna ett enkelt driftbesked eller cheferna saknade en fungerande väg för att få svar är det framför allt systemet ni har lärt er något om.

Det betyder inte att individuell förmåga aldrig spelar roll. Talespersoner behöver kunna svara på frågor och kommunikatörer behöver kunna formulera sig under press. Men övningen bör hjälpa er skilja mellan ett kompetensproblem och ett problem i organisationens förutsättningar för att kommunicera.

Bestäm gärna redan före övningen några saker ni vill kunna observera, men undvik att skapa tjugo mätpunkter bara för att det går. Tre eller fyra bra frågor kan räcka: Hur snabbt skapade vi en användbar gemensam lägesbild? Kunde vi nå de viktigaste mottagarna? Fungerade informationsflödet åt båda håll? Kunde vi kommunicera korrekt trots att viktiga saker fortfarande var osäkra?

Och framför allt: bestäm vem som tar hand om det ni hittar efteråt. Ett otydligt godkännandeflöde ska få en ägare. En reservkanal som inte fungerade ska testas och åtgärdas. Ett informationsbehov som ingen funktion ansvarade för ska placeras någonstans i organisationen. Övningsrapporten är inte slutprodukten. Förändringen efter övningen är slutprodukten.

En lyckad cyberövning är trots allt inte den där alla ser duktiga ut. Det är den som hittar sådant som fortfarande är dumt medan det bara är en övning.

Och kommunikationsproblem är ovanligt mycket trevligare att upptäcka då.