Så skriver ni en Statement of Applicability (SoA) i ISO 27001

Vid certifieringsrevisionen är SoA:n kartan revisorn arbetar efter. Den visar vad ni uppger är på plats, vilket i praktiken talar om vad som ska kontrolleras: dokumentgranskningen prövar att SoA, riskbedömning och policyer stämmer överens med varandra, och den efterföljande implementeringsrevisionen testar att verkligheten matchar det SoA:n säger. Varje diskrepans mellan de två är en iakttagelse som väntar på att skrivas ner.

Utanför revisionen betalar en välskött SoA sig som det ärliga enkelsidiga svaret på frågan ”vad gör ni egentligen åt säkerheten?”: för ny ledning, för interna revisioner och för kunder som gör sin due diligence.

SoA:n går igenom samtliga 93 kontroller i bilaga A (plus eventuella ytterligare kontroller ni har hämtat från andra källor) och registrerar för var och en:

• Kontrollen själv, med kod och namn, så att raden är entydig.
• Om kontrollen är tillämplig för er organisation.
• Motiveringen: varför kontrollen ingår (oftast vilka risker den hanterar eller vilket krav som kräver den) eller, vid uteslutning, varför den legitimt inte gäller.
• Implementeringsstatus: implementerad, delvis implementerad eller planerad. Ange den ärligt, eftersom revisorn kommer att testa den.

Att utesluta en kontroll är helt legitimt när motiveringen håller. En organisation som inte utvecklar någon egen programvara kan rimligen utesluta kontroller för utvecklingslivscykeln; en organisation utan egna fysiska kontor avgränsar på motsvarande sätt flera fysiska kontroller. Testet är om uteslutningen går att härleda till ert tillämpningsområde och er riskbild.

Det som inte överlever en revision är att utesluta en kontroll för att den är dyr, obekväm eller helt enkelt inte gjord än. ”Inte implementerad” och ”inte tillämplig” är olika rader i SoA:n, och att byta ut den ena mot den andra är det snabbaste sättet att förvandla en brist till en avvikelse.

SoA:n skrivs inte utifrån magkänsla; den är det dokumenterade resultatet av ert riskarbete. Ordningen är: bedöm riskerna, välj hur de ska hanteras, härled vilka kontroller hanteringen kräver, och jämför sedan dessa nödvändiga kontroller mot bilaga A för att bekräfta att inget väsentligt förbisetts. SoA:n dokumenterar resultatet av den jämförelsen.

Det är också här revisorer letar efter motsägelser. Om ert riskregister pekar ut en risk som en kontroll uppenbart hanterar, men er SoA markerar samma kontroll som inte tillämplig, är ett av de två dokumenten fel, och nu står det svart på vitt. Att hålla SoA:n och riskbedömningen samstämda betyder mer än hur välputsat något av dokumenten är.

En SoA beskriver er organisation den dag den skrevs, och organisationer står inte still. Nya system, nya leverantörer, ett ändrat tillämpningsområde eller en incident som förändrar er riskbild: vart och ett kan ändra vilka kontroller som är nödvändiga och hur långt implementeringen kommit. SoA:n bör versionshanteras, granskas med jämna mellanrum och uppdateras när riskbedömningen förändras.

Det klassiska misslyckandet är kalkylarks-SoA:n som tyst glider ifrån verkligheten tills veckorna före en revision förvandlas till arkeologi: att rekonstruera vad som ändrats, när och varför. Mer disciplin kring kalkylarket löser inte det. Lösningen är att hålla SoA:n där bedömningsarbetet faktiskt sker.

I Aquils Compliance Assistant är bedömningen ni underhåller SoA:ns levande källa. Varje kontroll har en status (inklusive inte tillämplig) med en skriftlig motivering, ett godkännandesteg så att varje svar signeras av en namngiven person med tidsstämpel, samt länkar till de dokument och processer som styrker det. Eftersom bedömningen är där det dagliga efterlevnadsarbetet sker hålls SoA-datan aktuell som en bieffekt istället för som en separat syssla.

När revisorn efterfrågar dokumentet exporterar ni SoA:n direkt från bedömningen som ett kalkylblad: varje kontroll med sitt område, status, motivering, godkännandestatus och attribuering. Veckan av febril hopsamling inför revisionen blir en nedladdning.