ISO/IEC 27001 Lead Implementer vs Lead Auditor: så väljer du rätt spår för ditt ISMS

En ISO/IEC 27001 Lead Implementer är en personcertifierad yrkesperson som vill kunna etablera, underhålla och förbättra ett ledningssystem för informationssäkerhet enligt ISO/IEC 27001.

Den rollen ska inte förväxlas med en organisations ISO/IEC 27001-certifiering. Organisationen certifieras mot standardens krav, medan individen certifierar sin kompetens att arbeta med kraven i praktiken. För svenska verksamheter handlar det ofta om att översätta standardens struktur till fungerande styrning, riskhantering, leverantörskrav och uppföljning, snarare än att enbart ta fram dokument inför en revision.

Valet mellan Lead Implementer och Lead Auditor beror därför på vilken uppgift personen ska lösa. Den som ska bygga, införa och driva ett ledningssystem för informationssäkerhet behöver en annan tyngdpunkt än den som ska planera, genomföra och rapportera revisioner. Båda spåren kräver förståelse för ISO/IEC 27001:2022, men de tränar olika arbetssätt och leder ofta till olika ansvar i organisationen.

Skillnaden mellan Lead Implementer och Lead Auditor

Lead Implementer-spåret är inriktat på att få ett ledningssystem för informationssäkerhet att fungera i verksamheten. Det innebär att tolka krav, definiera omfattning, etablera riskprocesser, välja kontroller, dokumentera motiveringar i en Statement of Applicability och skapa rutiner som kan följas över tid. Rollen arbetar nära ledning, IT, juridik, HR, inköp och verksamhetsägare, eftersom informationssäkerhet nästan alltid påverkar fler delar av organisationen än säkerhetsfunktionen själv.

Lead Auditor-spåret har en annan logik. Där ligger tyngdpunkten på revision enligt ISO 19011 och ISO/IEC 27001, med fokus på revisionsplanering, objektiv evidens, intervjuer, avvikelsehantering och rapportering. En Lead Auditor behöver kunna bedöma om ett ledningssystem uppfyller kraven, men ska inte samtidigt bli ägare av de lösningar som granskas. Den rollskillnaden är viktig, särskilt i mindre organisationer där samma person ibland förväntas både bygga och oberoende granska systemet.

En enkel beslutsram är att utgå från frågan personen ska besvara i vardagen. Om frågan är ”hur ska organisationen utforma och införa styrningen?” pekar valet mot Lead Implementer. Om frågan är ”hur kan organisationen bedöma om styrningen är effektiv och följer kraven?” pekar valet mot Lead Auditor. I många säkerhets- och compliancefunktioner behövs båda kompetenserna, men det är sällan klokt att börja med revisionsspåret om det saknas ett fungerande ledningssystem att granska.

Vad ISO/IEC 27001:2022 förändrar i praktiken

ISO/IEC 27001:2022 behåller grundidén med ett ledningssystem som bygger på risk, ledningens ansvar, uppföljning och ständig förbättring. Den mest synliga förändringen för många verksamheter är kopplingen till den uppdaterade kontrollstrukturen i ISO/IEC 27002:2022. Bilaga A i ISO/IEC 27001:2022 innehåller 93 kontroller grupperade i fyra teman: organisatoriska, personrelaterade, fysiska och tekniska kontroller.

För en verksamhet som tidigare arbetat mot 2013 års struktur innebär detta mer än en kosmetisk ommappning. Statement of Applicability behöver uppdateras så att varje kontroll har en tydlig status, motivering och koppling till riskbehandling. Gap-analysen behöver också visa om gamla kontrollbeskrivningar fortfarande är relevanta, om nya kontrollområden kräver beslut och om befintliga rutiner faktiskt fungerar under den nya strukturen.

Det är vanligt att organisationer underskattar arbetet med motiveringarna. En SoA som bara markerar ”tillämplig” eller ”inte tillämplig” utan verksamhetsspecifik förklaring blir svår att försvara vid revision och ännu svårare att använda som styrdokument. En bättre SoA förklarar varför kontrollen behövs, vilken risk den behandlar, vem som äger den och var bevisningen finns.

Svensk kontext: ISO 27001, NIS2 och leverantörsstyrning

I Sverige används ISO/IEC 27001 ofta som en praktisk struktur för att möta krav från kunder, koncerner, myndigheter och reglerade branscher. Standarden är inte samma sak som NIS2, men den hjälper organisationer att skapa den systematik som krävs för styrning, riskhantering, incidenthantering, kontinuitet och leverantörskontroll. MSB:s vägledning och ENISA:s material kan användas som kompletterande stöd, men ISO/IEC 27001 ger själva ledningssystemramen.

Den kopplingen märks särskilt i leverantörsledet. En medelstor svensk organisation som hanterar kunddata, driftstjänster eller samhällsviktiga beroenden kan behöva visa att säkerhetskrav finns i avtal, att leverantörer bedöms före upphandling och att uppföljning sker under avtalstiden. Lead Implementer-rollen blir då praktisk: den översätter generella styrningskrav till inköpsrutiner, due diligence-frågor, avtalsbilagor och återkommande kontroller.

Det är också här ett ledningssystem skiljer sig från ett dokumentpaket. En policy kan säga att leverantörer ska bedömas, men ISMS:et behöver visa hur bedömningen görs, vem som godkänner risker, hur undantag hanteras och vilka mätetal som visar om processen används. Den skillnaden är central både för intern styrning och för extern revision.

Riskhantering som fungerar utanför teorin

Riskhantering är kärnan i ISO/IEC 27001, men många implementationer blir svaga eftersom riskkriterierna definieras för sent eller för allmänt. Innan organisationen börjar poängsätta risker behöver den besluta vad som räknas som acceptabel risk, vilka konsekvensnivåer som ska användas, hur sannolikhet bedöms och vem som får acceptera kvarvarande risk. Utan dessa beslut blir riskregistret lätt en samling subjektiva bedömningar utan tydlig styrning.

Ett praktiskt arbetssätt är att börja med verksamhetens mest kritiska informationsflöden och tillgångar. Därefter identifieras hot, sårbarheter och konsekvenser med stöd från tillgångsägare och processägare. Varje risk får en ägare, ett beslut om behandling och en tidsatt åtgärd. När riskbehandlingen leder till val av kontroller dokumenteras sambandet i SoA:n.

1. Definiera riskkriterier och beslutsnivåer innan risker värderas.
2. Inventera tillgångar och informationsflöden med tydliga ägare.
3. Dokumentera risker, behandling, ansvar och kvarvarande risk i ett riskregister.
4. Koppla valda kontroller till riskbehandlingsplan och SoA.
5. Följ upp åtgärder och riskacceptanser vid ledningens genomgång.

Vanliga icke-uppfyllelser vid revision följer ofta samma mönster. Tillgångsförteckningen är ofullständig, riskkriterierna är otydliga, SoA:n saknar motivering eller mätetalen visar inte om ledningssystemet fungerar. Åtgärden är sällan att skriva mer dokumentation. Det viktiga är att skapa spårbarhet mellan verksamhetens informationsvärden, riskbeslut, valda kontroller och faktisk uppföljning.

Ett förenklat exempel på SoA och kontrollmotivering

Följande exempel är förenklat, men visar hur en SoA kan bli ett användbart styrdokument snarare än en revisionsbilaga. Anta att en svensk SaaS-leverantör hanterar kunddata i en molnbaserad produkt och är beroende av flera underleverantörer för drift, support och övervakning. Verksamheten har identifierat risker kopplade till obehörig åtkomst, bristande leverantörskontroll och otillräcklig incidentrapportering.

Poängen är inte att varje organisation ska formulera sig likadant. Tvärtom bör motiveringarna visa hur kontrollen hänger ihop med organisationens egna risker och krav. En revisionsbar SoA är därför både specifik och levande: den uppdateras när riskbilden, leverantörerna, tekniken eller verksamhetens omfattning förändras.

Ett realistiskt införandeupplägg för en medelstor organisation

En vanlig missuppfattning är att ISO/IEC 27001 måste införas som ett stort engångsprojekt. I praktiken fungerar ett fasat upplägg ofta bättre, särskilt i en medelstor svensk organisation där säkerhetsfunktionen är liten och verksamheten redan har pågående förändringsprojekt. Ett rimligt upplägg börjar med grundläggande styrning, fortsätter med operativ förankring och avslutas med förfining inför intern och extern revision.

I grundfasen fastställs omfattning, intressenter, informationsflöden, riskkriterier och ansvar. Denna fas avgör om resten av arbetet blir styrbart. Om omfattningen är otydlig, eller om tillgångsägare inte utses, kommer riskanalysen och SoA:n att vila på svag grund.

I styrningsfasen omsätts riskbehandlingen i kontroller, processer och beslut. Här byggs exempelvis leverantörsstyrning, åtkomstgranskningar, incidenthantering, kontinuitetsplanering och utbildningsaktiviteter in i ordinarie arbetssätt. Från ett praktiskt perspektiv är detta ofta den mest krävande fasen, eftersom den kräver förändring i flera delar av organisationen.

I förfiningsfasen testas om ledningssystemet fungerar. Internrevisioner, ledningens genomgång, mätetal och avvikelsehantering används för att justera processerna innan extern certifieringsrevision blir aktuell. Den fasen ska inte betraktas som en sista kontrollruta, utan som beviset på att organisationen kan upptäcka och förbättra brister själv.

Mätetal och ledningens genomgång

ISO/IEC 27001 kräver att organisationen följer upp ledningssystemets prestanda och effektivitet. Det leder ibland till mätetal som är enkla att ta fram men svåra att använda, till exempel antal genomförda utbildningar utan koppling till risk eller beteendeförändring. Bättre mätetal hjälper ledningen att fatta beslut om prioriteringar, resurser och riskacceptans.

Exempel på användbara indikatorer är andel kritiska leverantörer med aktuell säkerhetsbedömning, tid till stängning av högriskåtgärder, täckning i åtkomstgranskningar, antal återkommande incidentorsaker och status för internrevisionsavvikelser. Mätetalen behöver inte vara många, men de ska kunna visa om centrala ISMS-processer fungerar och om riskerna rör sig i rätt riktning.

Vid ledningens genomgång bör mätetalen kopplas till beslut. Om leverantörsuppföljningen halkar efter kan ledningen behöva prioritera inköpsresurser eller förändra avtalsprocessen. Om återkommande incidentorsaker visar brister i förändringshantering kan riskbehandlingsplanen behöva uppdateras. På så sätt blir ledningens genomgång en styrningsmekanism, inte ett årligt mötesprotokoll.

Förberedelse inför Lead Implementer-certifiering

Förberedelse bör utgå från hur standarden används i verkliga beslut. Det räcker inte att kunna återge klausuler och kontrollrubriker. Kandidaten behöver förstå skillnaden mellan ISO/IEC 27001-krav och ISO/IEC 27002-kontroller, kunna bygga en riskbaserad motivering för kontroller och kunna förklara hur ett ISMS förbättras över tid.

Typiska misstag är att hoppa över tillgångsinventeringen före riskanalysen, använda generiska kontroller utan SoA-motivering, sakna mätetal för uppföljning, lämna roller och ansvar otydliga eller inte koppla förändringsstyrning till riskbehandling. Dessa misstag påverkar både provförberedelse och praktisk implementation, eftersom de bryter sambandet mellan krav, risk, kontroll och evidens.

En strukturerad utbildning kan vara användbar när den kombinerar standardförståelse med övningar i riskregister, SoA, riskbehandling och förbättring. Readynez beskriver sitt ISO/IEC 27001 Lead Implementer-spår som ett sätt att arbeta igenom dessa delar samlat, men värdet i förberedelsen ligger ytterst i att kandidaten kan omsätta begreppen i ett fungerande ledningssystem.

Att välja rätt spår och göra kompetensen användbar

Lead Implementer är rätt val när målet är att bygga, införa eller förbättra ett ledningssystem för informationssäkerhet. Lead Auditor är rätt val när uppdraget är att granska, samla evidens och rapportera om systemets överensstämmelse och effektivitet. Ett moget säkerhetsarbete behöver båda perspektiven, men de bör inte blandas ihop.

Det mest praktiska nästa steget är att utgå från organisationens behov: finns det ett tydligt ISMS att granska, eller behöver styrningen först etableras och förankras? Om uppgiften är att skapa riskkriterier, bygga SoA, knyta kontroller till NIS2-relaterade styrningskrav och få ledningen att använda mätetal, är Implementer-spåret ofta den mest relevanta starten. När den grunden finns blir revisionskompetensen mer träffsäker, och Readynez kan då fungera som ett strukturerat stöd för den som vill formalisera sin ISO/IEC 27001-kompetens.