De flesta team stöter på tillämplighetsförklaringen veckan före sin första ISO 27001-revision. Någon laddar ner en mall, klistrar in åtgärdslistan från bilaga A, markerar nästan allt som "tillämpligt", skriver en enrads motivering för varje och arkiverar den. Den klarar en snabb blick första gången. Sedan kommer uppföljningsrevisionen, revisorn öppnar den och frågorna börjar.

Tillämplighetsförklaringen är ingen ruta du bockar av en gång. Den är kartan mellan dina risker, dina säkerhetsåtgärder och bevisen som visar att åtgärderna fungerar. Gör du rätt blir den ryggraden i hela ditt informationssäkerhetsarbete. Gör du fel är den det första som får en revision att nystas upp. Den här guiden går igenom vad SoA faktiskt är, varför revisorer öppnar den först och hur du håller den aktuell i stället för att låta den glida ifrån verkligheten.

Vad tillämplighetsförklaringen är

Tillämplighetsförklaringen, ofta förkortad SoA efter engelskans Statement of Applicability, listar varje säkerhetsåtgärd i bilaga A till ISO 27001, anger om du har infört den och förklarar varför. För varje åtgärd svarar den på tre frågor: är den tillämplig eller inte, vad är motiveringen och hur vet du att den fungerar. Det är hela uppgiften. Strukturen är enkel. Disciplinen bakom är det inte, för det är i SoA:n din riskbedömning, din uppsättning åtgärder och dina bevis måste stämma överens.

Se den som innehållsförteckningen till ditt ledningssystem för informationssäkerhet. Din riskbedömning säger vad som kan gå fel. Din riskbehandlingsplan säger vad du tänker göra åt det. SoA:n registrerar vilka åtgärder från bilaga A du valde, kopplar varje åtgärd till de risker den hanterar och pekar på bevisen som visar att den är verklig. Det är den enda plats där någon kan ställa sig och se hela ditt program på en gång, vilket är precis därför den väger så tungt.

Varför revisorer öppnar den först

När en revisor sätter sig med ditt ledningssystem är SoA:n det dokument de öppnar först. Den berättar vad du påstår att du har på plats och ger dem en checklista att pröva dig mot. Allt annat i revisionen utgår från den. De väljer åtgärder ur din SoA, ber dig visa bevisen och jämför det du skrivit med det du faktiskt gör.

Därför är SoA:n mindre av ett formulär och mer av ett löfte. Varje rad säger "det här gör vi, här är varför, och här är beviset". Revisorns jobb är att hitta raderna där löftet och verkligheten inte stämmer. Om din SoA säger att du gör kvartalsvisa behörighetsgranskningar och du inte kan visa de tre senaste, står den luckan nu antecknad. SoA:n beskriver inte bara ditt program. Den sätter villkoren för din revision.

De 93 åtgärderna och de fyra temana

ISO 27001:2022 organiserade om bilaga A till 93 säkerhetsåtgärder samlade under fyra teman. Versionen från 2013 hade 114 åtgärder i 14 områden, så om du går över från den äldre standarden är kartläggningen viktig. De fyra temana är:

• Organisatoriska (37 åtgärder). Policyer, roller, leverantörsrelationer, incidenthantering och styrningen som håller ihop programmet.
• Personella (8 åtgärder). Bakgrundskontroller, anställningsvillkor, medvetenhetsutbildning och vad som händer när någon börjar, byter roll eller slutar.
• Fysiska (14 åtgärder). Säkra utrymmen, utrustning, rent skrivbord och ren skärm samt skydd mot fysiska och miljömässiga hot.
• Tekniska (34 åtgärder). Åtkomstkontroll, kryptering, loggning, säker utveckling och de tekniska åtgärder de flesta tänker på när de hör "säkerhet".

Du tillämpar inte alla 93 per automatik. Du tillämpar dem dina risker kräver och dokumenterar varför resten inte passar. Det beslutet är kärnan i SoA:n, och det är där tillämplig och ej tillämplig kommer in.

Att motivera tillämplig och ej tillämplig

Varje åtgärd på listan är antingen med eller utanför, och inget av svaren är gratis. Tar du med en åtgärd förbinder du dig att driva den och att hålla bevis på att den fungerar. Utesluter du en är du skyldig ett skäl som håller för granskning.

Bra motiveringar för tillämplighet kopplar åtgärden tillbaka till din riskbedömning. Du tar inte med åtkomstkontroll "för att ISO säger det". Du tar med den för att din riskbedömning pekade ut obehörig åtkomst till kunddata som ett verkligt hot, och den här åtgärden hanterar den risken. Linjen från risk till åtgärd till bevis ska vara synlig, för det är den linjen en revisor följer.

Uteslutningar är där team hamnar i trubbel. "Ej tillämplig" är ett giltigt svar, men bara med ett försvarbart skäl. Att utesluta fysiska åtgärder för ett datacenter du inte driver är okej, så länge du namnger molnleverantören som gör det och pekar på deras certifiering. Att utesluta en åtgärd för att den är obekväm är inte okej, och en revisor ser skillnaden. Skriv uteslutningar som om den som läser dem letar efter luckan, för det gör hen.

Varför en inaktuell SoA är en varningsflagga

Snabbaste sättet att förlora en revisors förtroende är en SoA som inte ändrats på ett år medan ditt företag har gjort det. Du lanserade en produkt, flyttade till ett nytt kontor, tog in tio leverantörer och rullade ut ett nytt identitetssystem, och SoA:n beskriver fortfarande företaget du var i våras. Den obalansen säger revisorn att ditt dokument och din verklighet har glidit isär, och nu gräver de i allt.

En inaktuell SoA är sällan en enda felaktig rad. Den är en signal. Den antyder att SoA:n är ett dokument du producerar inför revisioner snarare än en beskrivning av hur du faktiskt arbetar. När en revisor väl tror det blir varje grön bock en fråga. SoA:n ska spegla det aktuella läget för dina åtgärder, så när den släpar efter slutar den vara bevis och börjar bli en belastning.

Lösningen är inte att uppdatera den hårdare en gång om året. Det är att sluta behandla SoA:n som ett separat dokument över huvud taget.

Så håller OptiTech din SoA ärlig

Skälet till att SoA:er glider ifrån verkligheten är att de flesta team underhåller dem för hand, i ett kalkylark som lever skilt från åtgärderna det beskriver. Du ändrar en åtgärd på ett ställe och glömmer uppdatera SoA:n på ett annat. De två hamnar i otakt i samma stund som verkligt arbete sker.

OptiTech gör tvärtom. Din SoA genereras direkt från din uppsättning åtgärder och bevisen som är kopplade till dem, så att den speglar programmets faktiska läge i stället för en ögonblicksbild någon skrev för månader sedan. När du kopplar en åtgärd till en risk dyker den kopplingen upp i SoA:n. När bevis går ut eller en åtgärd byter ägare följer SoA:n med. Det finns inget separat dokument att hålla i takt, för SoA:n är en vy av arbetet du redan gör i OptiTech Console.

Det betyder också att besluten om tillämplig och ej tillämplig lever intill riskerna som motiverar dem. En revisor som granskar din SoA kan följa varje åtgärd till sin risk och sitt bevis utan att lämna sidan, och du kan publicera din säkerhetsställning till ett trust center så att köpare ser samma aktuella bild. SoA:n slutar vara det du stressar för att laga inför en revision och blir det som bevisar att du var redo hela tiden.

Kom igång

Du behöver inte bygga om allt på en gång. En realistisk första omgång ser ut så här:

1. Förankra SoA:n i din riskbedömning. Varje tillämplig åtgärd ska gå att spåra till en risk den hanterar.
2. Motivera varje uteslutning skriftligt. Namnge skälet och beviset som stödjer det, särskilt för åtgärder som täcks av en leverantör.
3. Koppla bevis till varje åtgärd så att SoA:n speglar verkligheten i stället för avsikten.
4. Anslut den till ditt trust center så att samma aktuella ställning besvarar köparnas säkerhetsgranskningar på begäran.

En bra SoA belönar de företag som behandlar den som en levande vy av sina åtgärder snarare än ett dokument de sätter ihop under tidspress. Bygg kopplingarna en gång, håll bevisen aktuella, så berättar din SoA samma sanna historia för varje revisor och varje köpare som frågar.

Redo att hålla din tillämplighetsförklaring ärlig? Boka en demo och se hur OptiTech genererar din SoA direkt från dina åtgärder och bevis.