ISO 27001 bilaga A: gör de 93 säkerhetsåtgärderna operativa

Bilaga A ger säkerhetsteamen en användbar referensuppsättning. Dess operativa värde kommer av att visa varför en säkerhetsåtgärd är tillämplig, hur den är införd och vilket underlag som stöder den i er miljö. Ett register med 93 gröna statusindikatorer räcker inte om ingen kan förklara vilka system indikatorerna omfattar.

För en CTO är den praktiska utmaningen att översätta säkerhetsåtgärdernas syfte till tekniskt och operativt arbete utan att göra ledningssystemet för informationssäkerhet till en parallell byråkrati. Behörighetsgranskningar bör använda verkliga behörighetsdata. Återställningsplaner bör spegla tjänsternas beroenden. Leverantörsbedömningar bör avse de tjänster som verksamheten faktiskt använder.

Den här guiden förklarar hur ni väljer säkerhetsåtgärder, fördelar ägarskap, definierar införanden och testar de påståenden som blir resultatet. Granskningsfrekvenserna och exemplen på införande nedan är praktiska rekommendationer, inte universella intervall som föreskrivs i standarden.

Förstå vad bilaga A gör och vad den inte gör

ISO/IEC 27001:2022 innehåller 93 säkerhetsåtgärder i bilaga A fördelade på fyra teman. Avsnitten 4–10 innehåller kraven på ledningssystemet: organisationens förutsättningar, ledarskap, planering, stöd, verksamhet, utvärdering av prestanda och förbättring. Bilaga A stöder valet av säkerhetsåtgärder; den ersätter inte dessa krav eller er riskbedömning.

Skillnaden spelar roll under införandet. En konfiguration för säkerhetskopiering kan stödja en vald säkerhetsåtgärd, men den visar inte att ni har definierat ISMS-omfattningen, bedömt risker, genomfört en internrevision eller slutfört ledningens genomgång. Det är separata aktiviteter med separata underlag.

Valet av säkerhetsåtgärder är riskbaserat. Fastställ de säkerhetsåtgärder som behövs för att behandla era risker och jämför dem sedan med bilaga A för att kontrollera att inga nödvändiga åtgärder har förbisetts. Ytterligare åtgärder utöver bilaga A kan vara nödvändiga. Omvänt är ett motiverat undantag möjligt; det finns ingen regel om att varje organisation måste undanta något eller införa exakt samma urval.

ISO/IEC 27002:2022 ger vägledning för införandet av säkerhetsåtgärderna. Dess attribut hjälper till att ordna dem efter typ av åtgärd, informationssäkerhetsegenskap, cybersäkerhetsbegrepp, operativ förmåga och säkerhetsdomän. De är användbara filtreringshjälpmedel, inte ytterligare checklistor för certifiering. Använd de licensierade standarderna för den auktoritativa lydelsen.

Använd de fyra temana för att hitta rätt ägare

Temana ger en navigeringsstruktur, inte fyra oberoende arbetsströmmar. En process för avslutad anställning kopplar till exempel ihop ansvar i anställningen, identitetsadministration, återlämning av utrustning och åtkomst till applikationer.

Organisatoriska säkerhetsåtgärder: koppla styrningen till operativa beslut

Dessa säkerhetsåtgärder omfattar policyer, ansvar, uppdelning av arbetsuppgifter, tillgångar, klassificering och hantering av information, styrning av åtkomst, leverantörer, incidenter, kontinuitet, rättsliga skyldigheter och granskningsaktiviteter.

Börja med att identifiera var besluten fattas. Vem godkänner en ny molntjänst? Vem tilldelar en informationsklassning? Vem avgör om en rapporterad händelse är en incident? En policy bör göra dessa beslut upprepbara och tilldela befogenheter, inte bara uttrycka stöd för säkerhet.

Leverantörssäkerhet behöver en tjänstespecifik kedja av underlag: tjänstens affärssyfte, den information den hanterar, bedömda risker, avtalsenligt ansvar och löpande granskning. En leverantörs granskningsrapport kan stödja bedömningen, men dess omfattning, period och kundens ansvar måste motsvara er användning.

Incidenthantering behöver på samma sätt mer än en lista över nödkontakter. Definiera rapporteringsvägar, bedömningskriterier, befogenheter vid hantering, hantering av bevis och aktiviteter för lärande. Dokumentera övningar eller faktiska insatser, inklusive uppföljande åtgärder och ägare.

Personrelaterade säkerhetsåtgärder: gör händelser i anställningen till pålitliga utlösare

De åtta personrelaterade säkerhetsåtgärderna behandlar bakgrundskontroll, anställningsvillkor, medvetenhet och utbildning, disciplinära processer, ansvar efter ändrad anställning, sekretess, distansarbete och rapportering av händelser.

Bygg in dem i befintliga arbetsflöden för anställning. En nyanställd behöver lämpliga skyldigheter, åtkomst och instruktioner. En medarbetare som byter roll behöver få sina behörigheter omprövade, inte bara utökade. En medarbetare som slutar behöver få åtkomsten borttagen, lämna tillbaka tillgångar och få klarhet i sitt fortsatta sekretessansvar.

Ägarskapet sträcker sig ofta över flera team. HR kan initiera ett avslut, identitetsadministratörer inaktiverar det centrala kontot, applikationsägare tar bort lokalt hanterad åtkomst och en chef bekräftar att allt är klart. Att lägga hela processen på säkerhetsfunktionen döljer dessa beroenden.

Användbara underlag omfattar godkända poster i arbetsflödet, genomförd utbildning och uppföljning av försenade moment, bekräftade villkor och stickprov på förändringar i anställningar. Begränsa åtkomsten till känsliga HR-underlag; den som granskar en säkerhetsåtgärd behöver inte automatiskt fullständiga personalakter.

Fysiska säkerhetsåtgärder: dokumentera er gräns och leverantörens gräns

Fysiska säkerhetsåtgärder behandlar lokaler, tillträde, övervakning, miljöhot, säkra områden, skrivbord och skärmar, utrustning, lagringsmedier, försörjning, kablage, underhåll och kassering.

En organisation som är molnbaserad i första hand behöver ändå beakta fysisk säkerhet. En del av införandet kan tillhandahållas av en molnleverantör, medan tillträdet till kontoret och de anställdas enheter förblir organisationens eget ansvar. Dokumentera den fördelningen i stället för att automatiskt undanta hela temat.

För era egna lokaler, identifiera vem som får komma in, hur tillträde ändras, var känslig utrustning finns och hur besökare hanteras. För enheter som används på distans, definiera förvaring, transport, reparation och kassering på ett sätt som är lämpligt för riskerna.

Underlag kan vara uppgifter om tillträdesbehörigheter, besöksrutiner, förteckningar över utrustning och uppgifter om kassering. Leverantörens underlag bör förklara vilka anläggningar och tjänster som omfattas; det bör inte behandlas som bevis för säkerhetsåtgärderna för ert kontor eller era bärbara datorer.

Tekniska säkerhetsåtgärder: definiera täckningen innan ni väljer verktyg

Det tekniska temat omfattar slutpunkter, privilegierad åtkomst, autentisering, åtkomst till källkod, kapacitet, skadlig kod, sårbarheter, konfigurationer, datahantering, säkerhetskopior, motståndskraft, loggning, övervakning, nätverk, kryptografi, utveckling och ändringshantering.

Börja med systemtäckningen. En identitetspolicy är ofullständig om produktionsåtkomst, tjänstekonton eller en separat hanterad applikation hamnar utanför dess införande. En loggplattform är ofullständig om kritiska händelser aldrig når den eller ingen reagerar på larm.

För programvaruutveckling, koppla krav och designbeslut till kodgranskning, säkerhetstester, separation av miljöer, hantering av testdata och godkännande av releaser. Hotmodellering kan hjälpa till att identifiera säkerhetskrav före införandet. Testdjupet bör följa risker och skyldigheter; ISO 27001 föreskriver inget universellt schema för penetrationstester.

För kryptografi, skilj mellan data i vila och data under överföring och dokumentera ägarskap, åtkomst, återställning, rotation och återkallelse för nycklar. ”Kryptering aktiverad” lämnar viktiga frågor om införandet obesvarade.

Vad som ändrades 2022 och var ni ska leta efter brister

2013 års utgåva hade 114 säkerhetsåtgärder i 14 domäner. 2022 års utgåva omorganiserade dem till 93 säkerhetsåtgärder i fyra teman, inklusive 11 nya åtgärder. Ett lägre antal innebär inte mindre säkerhetsarbete: en sammanslagning kan placera flera operativa ansvarsområden under en och samma referens.

När ni uppdaterar ett äldre register, bevara de underliggande införandena och underlagen i stället för att bara byta ut identifierarna. Kontrollera om den nya grupperingen ändrar täckning, ägarskap eller de tester som behövs för att stödja er status.

Övergångsfristen för ackrediterad certifiering enligt ISO/IEC 27001:2013 var den 31 oktober 2025. Dessa certifikat är inte längre giltiga; att uppdatera ett register över säkerhetsåtgärder räcker inte i sig för att uppnå certifiering enligt 2022 års utgåva.

Följande är praktiska utgångspunkter för de 11 nya säkerhetsåtgärderna, inte återgivningar av deras auktoritativa text.

Undvik att behandla dessa som elva automatiska produktinköp. Hotunderrättelser kräver till exempel analys och åtgärder, inte bara ett prenumererat flöde. Radering av data kräver förståelse för kopior, säkerhetskopior och lagringsskyldigheter, inte bara en raderingsknapp. Övervakning behöver en operativ väg för åtgärder.

Dokumentera tillämplighet och införande separat

Ert uttalande om tillämplighet, Statement of Applicability (SoA), bör identifiera nödvändiga säkerhetsåtgärder, förklara varför de ingår, ange om de är införda och motivera undantag av säkerhetsåtgärder i bilaga A. Dessa krav finns i bestämmelserna om riskbehandling i ISO/IEC 27001.

Att använda alla 93 referenser som granskningsindex är ett praktiskt sätt att göra jämförelsen granskningsbar. Ta också med eventuella ytterligare nödvändiga säkerhetsåtgärder. SoA är inte riskregistret, riskbehandlingsplanen eller arkivet för underlag, även om det bör kopplas till vart och ett av dem där det är relevant.

För varje tillämplig säkerhetsåtgärd, dokumentera:

• De risker eller skyldigheter som motiverar att den ingår.
• Relevanta system, platser, information och processer.
• Det faktiska införandet och den ansvariga ägaren.
• Stödjande underlag och dess granskningsperiod.
• Beroenden, undantag och oavslutat arbete.
• Nästa granskningsdatum eller utlösande händelse.

Håll tillämpligheten oberoende av genomförandestatusen. ”Tillämplig, delvis införd” är en ärlig och användbar uppgift. ”Ej tillämplig eftersom vi inte har köpt något verktyg” är ingen motivering av tillämplighet.

Ett undantag bör beskriva de fakta om omfattningen som gör säkerhetsåtgärden onödig och förbli förenligt med riskbedömningen. ”Vi utvecklar inte programvara” behöver granskas om en konsult utvecklar er kundportal. Utkontraktering ändrar vägen för införande och underlag; den tar inte automatiskt bort risken.

För distribuerade införanden, dokumentera fördelningen. En säkerhetsåtgärd för fysiskt skydd kan bero på hostinganläggningar som drivs av leverantören, tillträde till kontoret som hanteras av företaget och de anställdas hantering av enheter. En ägare kan förbli ansvarig för det samlade påståendet medan olika team utför aktiviteterna.

En användbar beskrivning av införandet är tillräckligt specifik för att kunna testas: ”Produktionsadministratörer får namngiven, godkänd åtkomst via identitetstjänsten; nödåtkomst loggas och granskas separat.” ”Åtkomst hanteras säkert” kan inte vägleda en tekniker eller granskare.

Testa påståendet bakom statusen

En policy beskriver avsett beteende. Den kan visa utformning och godkännande, men kan inte ensam visa drift. Bygg en kedja av underlag från kravet till den införda mekanismen och vidare till ett observerat resultat.

För åtkomsthantering, jämför godkända regler med faktiska användarbehörigheter och uppgifter om avslutade anställningar. Ta med privilegierade identiteter, icke-personliga konton och applikationer utanför den centrala identitetshanteringen där det är relevant. Dokumentera populationen, stickprovet och undantagen i stället för att visa en enda bekväm skärmbild.

För säkerhetskopior, granska konfigurationen och ett återställningsresultat. Ett lyckat säkerhetskopieringsjobb bevisar mindre än en lyckad återställning av användbar information. Kontrollera behörigheter, beroenden och återställningsmål; en återställd databas utan sina krypteringsnycklar kanske inte återställer tjänsten.

För leverantörssäkerhet, koppla bedömningen till den specifika tjänsten och det avtalsenliga ansvaret. Granska om underlaget omfattar den tjänst ni använder och om identifierat ansvar på kundsidan är infört.

Ett praktiskt testunderlag bör innehålla förväntat utfall, metod, omfattning, datum för underlaget, granskare, resultat och beslut om uppföljning. Skilj mellan:

• Utformning: den föreslagna mekanismen hanterar den identifierade risken.
• Införande: mekanismen finns inom hela den angivna omfattningen.
• Drift: underlag visar att den har fungerat under den relevanta perioden.
• Effektivitet: tester tyder på att den uppnår det avsedda resultatet.

Underlag kan omfatta konfigurationer, exporter, ärenden, avtal, intervjuer och fysiska observationer. Välj underlag som stöder det faktiska påståendet. En konfigurationsexport kan visa aktuella inställningar; historiska ärenden kan visa om undantag har hanterats över tid.

Bevara ursprunget: källsystem, insamlingsdatum, omfattad period och eventuell filtrering. Skydda underlag som innehåller hemligheter eller personuppgifter genom åtkomstbegränsningar och lämplig maskering. Insamlingen av underlag bör inte skapa ett nytt okontrollerat arkiv med känsliga uppgifter.

Exempel: gör en process för avslutad anställning granskningsbar

Tänk dig som illustration ett SaaS-företag med 45 anställda, ett kontor, molnhosting, centralt hanterad identitet och två applikationer med lokala konton. Detta är antaganden för exemplet, inte resultat från Secanis kunder.

Risken är fortsatt åtkomst till kund- eller företagsinformation efter att någon har slutat. Relevanta säkerhetsåtgärder omfattar ansvar vid ändrad anställning, identitetshantering, åtkomsträttigheter och återlämning av tillgångar. Teknisk autentisering och åtkomstbegränsningar stöder också införandet.

Företaget dokumenterar säkerhetsåtgärden som tillämplig. HR äger utlösaren för avslutet; IT äger åtgärderna för identitet och enheter; varje applikationsägare äger borttagningen av lokala konton. Den anställdes chef bekräftar den tidpunkt som krävs för avslutet. Säkerhetsansvarig granskar processen och olösta undantag.

Införandet omfattar ett godkänt ärende för avslutet, schemalagd inaktivering av det centrala kontot, återkallelse av sessioner där det stöds, borttagning av lokala konton, återlämning av tillgångar och kontroller av inloggningsuppgifter som personen har haft kontroll över. Delade hemligheter byts vid behov; personliga konton överlåts inte lättvindigt till en efterträdare.

Paketet med underlag kopplar ihop den godkända rutinen, ärendet för avslutet, uppgifterna om kontoåtgärder, bekräftelserna för de lokala applikationerna och uppgifterna om utrustningen. Varje del stöder en definierad del av påståendet.

Under en illustrativ granskning undersöker teamet fyra avslut. De centrala kontona inaktiverades enligt schemat, men en lokal applikation behöll åtkomsten i två dagar. Säkerhetsåtgärden förklaras inte fullt effektiv enbart på grundval av underlaget från den centrala identitetshanteringen.

Applikationsägaren tar bort kontot, bedömer om åtkomst har skett och dokumenterar resultatet. Teamet lägger till applikationen i checklistan för avslut och inför ett avstämningssteg. Åtgärden får en ägare och ett slutdatum; ett senare test kontrollerar att det reviderade arbetsflödet fungerar.

Exemplet visar varför underlaget måste följa beroendena. Fyra system som visar ”klart” bevisar inte att arbetet är slutfört om ett femte system aldrig togs med.

Håll säkerhetsåtgärderna operativa mellan granskningarna

Säkerhetsåtgärder förändras när system, leverantörer, personer och verksamhetskrav förändras. Fastställ utlösare för granskning vid betydande releaser, nya tjänster, förändringar av kontor, incidenter och ändrade skyldigheter, parallellt med schemalagda granskningar.

Använd en frekvens som är anpassad till föränderlighet och risk. Undantag för privilegierad åtkomst kan behöva granskas snabbt, medan en stabil policy kan ha en längre cykel kompletterad med utlösare vid förändringar. Detta är ledningsbeslut, inte universella frekvenser i bilaga A.

Följ ett litet antal användbara indikatorer: försenade åtgärder, system som inte täcks, olösta undantag i underlaget och misslyckade tester av säkerhetsåtgärder. Skilj dessa från antal dokument. Ett stort bibliotek med underlag kan ändå lämna en kritisk produktionsmiljö otestad.

Internrevisionen ger en separat utvärdering av ISMS; rutinmässiga granskningar av åtgärdsägare ersätter den inte. Ledningens genomgång behöver på samma sätt beslut från ledningen om prestanda, förändringar, resurser och förbättringar, inte bara ett ifyllt kalkylblad med säkerhetsåtgärder. Certifiering utförs av ett oberoende certifieringsorgan, inte av ISO eller en programvaruleverantör.

Vanliga misstag är att lägga allt på säkerhetsfunktionen, kopiera en annan organisations undantag, förlita sig på leverantörscertifikat utan att kontrollera omfattningen och stänga avvikelser när en policy ändras i stället för när den reviderade processen har testats.

Börja med en tjänst och en fullständig kedja av underlag

Välj en representativ tjänst och spåra dess system, leverantörer, information och operativa ägare. Välj ett litet antal relaterade säkerhetsåtgärder, till exempel åtkomst, ändringshantering, loggning och återställning, och gör varje införande granskningsbart innan ni utökar registret.

Secani stöder detta arbetsflöde genom att modellera system och beroenden, koppla underlag till krav, säkerhetsåtgärder och beslut och följa brister som uppgifter. Utse en ägare och en granskare, bifoga befintliga underlag och bevara granskningskommentarer och godkännanden. Behandla AI-stödda mappningar eller sammanfattningar som utkast: validera källorna och håll det mänskliga godkännandet uttryckligt. Strukturerad revisionsberedskap förklarar den underliggande modellen för underlag.

Det första resultatet bör vara en sammanhängande kedja från risk till säkerhetsåtgärd, införande, underlag, testresultat och beslut om uppföljning. Den kedjan kan sedan upprepas i resten av omfattningen utan att uppfinna en ny process för varje referens i bilaga A.

Praktiska frågor

Kan ett underlag stödja flera säkerhetsåtgärder?

Ja. Ett ärende för en avslutad anställning kan stödja flera relaterade säkerhetsåtgärder. Förklara vilket påstående det stöder för var och en; att dela underlag gör inte säkerhetsåtgärderna identiska.

Måste varje säkerhetsåtgärd ha en egen policy?

Nej. Organisera policyer och rutiner kring begripliga operativa processer. Ett dokument kan behandla flera säkerhetsåtgärder, förutsatt att ansvar och införande förblir tydliga.

Var ska den auktoritativa listan över säkerhetsåtgärder komma ifrån?

Använd den licensierade standarden ISO/IEC 27001 för lydelsen i bilaga A och ISO/IEC 27002 för vägledning om införandet. Operativa sammanfattningar är användbara navigeringshjälpmedel, inte ersättningar för standarderna.