ISO 27001-certifiering: bygg ett ISMS som håller

En kund ber om ert ISO 27001-certifikat. Den kommersiella tidsfristen är tydlig; implementeringsarbetet är det kanske inte. Ledningens första beslut är om ni ska bygga ett ledningssystem för informationssäkerhet som verksamheten kan upprätthålla, eller organisera ett tillfälligt projekt kring ett revisionsdatum.

En användbar certifieringsplan börjar med att definiera det system ni behöver driva och ordnar därefter de belägg som visar det. Det innebär att besluta vilka tjänster certifikatet ska omfatta, vem som får fatta riskbeslut, vilka resurser kontrollägarna behöver och hur ledningen ska veta om kontrollerna fungerar.

Certifikatet är en viktig leverans. Den bestående affärstillgången är ett ledningssystem för informationssäkerhet, ett ISMS, som förblir användbart när medarbetare slutar, leverantörer byts ut, nya produkter lanseras och kunder ställer svårare frågor.

Vad en ISO 27001-certifiering faktiskt fastställer

ISO/IEC 27001 specificerar krav för att upprätta, införa, underhålla och ständigt förbättra ett ISMS. Syftet är att hantera risker för informationens konfidentialitet, riktighet och tillgänglighet i organisationens kontext.

Konfidentialitet handlar om otillbörligt röjande, till exempel att kunduppgifter blir åtkomliga för obehöriga användare. Riktighet handlar om felaktiga eller obehöriga ändringar, till exempel att någon ändrar betalningsinstruktioner. Tillgänglighet handlar om åtkomst när den behövs, till exempel att återställa en viktig tjänst efter ett infrastrukturfel.

Certifieringen gäller ledningssystemet inom dess angivna omfång. Den garanterar inte att varje produkt är fri från sårbarheter, att incidenter inte kan inträffa eller att varje affärsenhet har bedömts. Ett certifikat som omfattar en förvaltad tjänst bör inte presenteras som en försäkran för en orelaterad produkt.

ISO och IEC ger ut standarden; de certifierar inte er organisation. Ett oberoende certifieringsorgan genomför bedömningen och fattar certifieringsbeslutet. För att ge kunder trygghet är en praktisk rekommendation att välja ett organ som är ackrediterat för den aktuella ISMS-certifieringen och att bekräfta att dess certifiering uppfyller köparnas krav.

Skillnaden mellan överensstämmelse och certifiering spelar också roll. En organisation kan införa ett ISMS som uppfyller standarden utan att söka extern certifiering. Certifiering tillför en oberoende bedömning och ett formellt certifikat. Att köpa programvara, anställa en kvalificerad implementerare eller genomgå en utbildning ger inte organisationen någon certifiering.

Avgör om certifiering löser affärsproblemet

Certifiering är särskilt relevant när upphandlingskrav, avtalsåtaganden, känslig information eller operativa beroenden motiverar en oberoende försäkran. Det är inte en allmän rättslig skyldighet för alla företag.

Innan ni binder er, be sälj- och kundansvariga att identifiera det faktiska kravet. Kräver köparen ett certifikat före avtalsunderteckning, före produktionsåtkomst eller vid förnyelse? Måste det omfatta en namngiven tjänst eller juridisk person? Kommer köparen ändå att kräva ett säkerhetsfrågeformulär, testrapporter eller ytterligare avtalsmässiga kontroller?

Svaren påverkar investeringsprioriteringarna. Ett certifikat kan underlätta upphandling, men det eliminerar inte all granskning. Undvik att prognostisera intäkter utifrån antagandet att certifiering automatiskt avslutar varje kunds säkerhetsgranskning.

Håll isär certifiering och regulatorisk analys. Ett ISMS kan stödja belägg och styrning som är relevanta för andra skyldigheter, men certifiering fastställer inte efterlevnad av dataskyddsförordningen (GDPR) eller NIS2. Dessa regelverk har egna regler för tillämplighet och egna skyldigheter. NIS2 genomförs genom nationell lagstiftning; skyldigheterna enligt GDPR beror på behandlingsaktiviteter och organisatoriska roller.

Underlaget till ledningen bör därför identifiera tre saker: den försäkran kunderna behöver, de informationsrisker verksamheten måste hantera och den löpande driftskostnaden. Godkänn programmet på den grunden, snarare än på ett löfte om ett certifikat till ett godtyckligt datum.

Dra en gräns som kunderna kan förstå

Omfånget beskriver ISMS:ets gränser och tillämplighet. Det bör identifiera relevanta tjänster, organisatoriska enheter, platser, personer, information, system och beroenden. Det måste också ta hänsyn till gränssnitt mot verksamhet utanför dessa gränser.

Ett snävt omfång kan vara lämpligt, särskilt vid ett första införande. Det måste ändå spegla vad kunderna förväntar sig att certifikatet ska omfatta. Att utesluta teamet som administrerar produktionsåtkomst tar inte bort dess inflytande över en kundtjänst inom omfånget.

För en driftad applikation, granska hela tjänstekedjan: utveckling, driftsättning, produktionsdrift, supportåtkomst, identitetsadministration, säkerhetskopiering och betydande externa leverantörer. Gemensamma HR- eller IT-processer kan påverka säkerheten även när omfånget kretsar kring en produkt snarare än hela företaget.

En praktisk beskrivning av omfånget bör besvara:

• Vilken juridisk person driver tjänsten?
• Vilka kundnära tjänster och vilken information omfattas?
• Vilka platser och distansarbetsupplägg är relevanta?
• Vilka team och gemensamma processer påverkar tjänsterna?
• Vilka leverantörer tillhandahåller infrastruktur eller hanterar relevant information?
• Vad ligger utanför gränsen, och hur hanteras gränssnitten mot det?

Testa den föreslagna formuleringen på en kollega som möter köpare. Om hen inte kan förklara om kundens tjänst omfattas behöver formuleringen arbetas om.

Optimera inte omfånget enbart för att sänka revisionsavgifterna. En mindre gräns kan skapa komplicerade gränssnitt och lämna det kommersiella kravet obesvarat. Omvänt kan det skapa onödig samordning att direkt inkludera varje koncernbolag. Rätt gräns är försvarbar, begriplig och hanterbar i driften.

Dokumentera motiveringen och de händelser som ska föranleda en omprövning, till exempel ett företagsförvärv, en flytt av infrastruktur eller lanseringen av en väsentligt annorlunda tjänst. Omfånget ska förbli ett ledningsbeslut, inte ett bortglömt stycke.

Ge programmet mandat, inte bara en ägare

Utse en implementeringsansvarig och en ansvarig sponsor i ledningen. De har olika ansvar. Den implementeringsansvariga samordnar arbetet och upprätthåller överblicken; sponsorn löser prioriteringar, godkänner resurser och ser till att säkerhetsmålen passar in i affärsbesluten.

Ägarskapet för kontroller bör följa det operativa mandatet. HR kan äga anställningsrelaterade rutiner, IT kan äga enhetshantering, utveckling kan äga utvecklingspraxis och inköp kan samordna leverantörsbedömningar. Compliance-ansvarig bör inte bli formellt ansvarig för processer hen inte kan ändra.

Definiera vem som får acceptera kvarstående risk och på vilken nivå. En tjänsteägare kan rekommendera att en begränsad operativ exponering accepteras, medan en risk som påverkar viktiga kundåtaganden kan kräva godkännande av företagsledningen. Dokumentera beslutet, motiveringen, villkoren och datum för omprövning.

Ledningen måste också skydda kapaciteten för implementeringen. Att tilldela arbete utan att frigöra tid för det skapar förutsägbara förseningar. Be ägarna om den insats som krävs, beroenden och avvägningar; godkänn sedan en realistisk plan.

Ledningens genomgång är där ledningen utvärderar systemet och fattar beslut om förbättringar, förändringar och resurser. Ett undertecknat mötesprotokoll utan meningsfulla beslut har litet praktiskt värde. Genomgången bör synliggöra olösta vägval, inte bara godkänna en grön instrumentpanel.

Förstå kraven innan ni köper en checklista

Kraven i avsnitt 4–10 i ISO/IEC 27001 utgör kärnan i ledningssystemet. De kan inte uteslutas när man hävdar överensstämmelse. Deras praktiska resultat skiljer sig från införandet av enskilda säkerhetskontroller.

Bilaga A i 2022 års utgåva innehåller 93 referenskontroller: 37 organisatoriska, åtta personrelaterade, 14 fysiska och 34 tekniska kontroller. Tillämpligheten är riskbaserad; det finns inget universellt antal som varje företag bör införa.

Fastställ vilka kontroller som är nödvändiga för riskbehandlingen och jämför dem sedan med bilaga A för att kontrollera att inga nödvändiga kontroller har förbisetts. Kontroller kan också komma från avtalskrav, andra källor eller er egen utformning. Bilaga A är varken en ersättning för riskbedömning eller en uttömmande katalog över alla tänkbara säkerhetsåtgärder.

Uttalandet om tillämplighet (Statement of Applicability, SoA) dokumenterar nödvändiga kontroller, skälen till att de ingår, deras implementeringsstatus och motiveringen till att kontroller i bilaga A utesluts. Upprätthåll tillräcklig spårbarhet för att kunna förklara hur besluten hänger ihop med riskbehandlingen och andra krav.

ISO 27002 ger vägledning om informationssäkerhetskontroller; ISO 27001 innehåller de certifierbara kraven på ledningssystemet. Använd vägledningen för att förstå implementeringsalternativ, men anpassa rutinerna till er organisation i stället för att importera en driftmodell ni inte kan upprätthålla.

Bygg riskbehandlingen innan ni samlar belägg

Börja med en upprepbar metod för riskbedömning. Definiera hur risker identifieras, hur sannolikhet och konsekvenser bedöms, hur resultaten jämförs och vilka kriterier som avgör vad som är acceptabelt. Konsekvent tolkning är viktigare än en komplicerad poängformel.

Beskriv risker som scenarier. ”Molnrisk” är för vagt för att ligga till grund för ett beslut. ”Ett administratörskonto komprometteras och används för att exportera kunduppgifter” identifierar en händelse, berörd information och en affärskonsekvens.

Involvera personer som förstår tjänsten. De kan förklara befintliga skydd, supportåtkomst, leverantörsberoenden, begränsningar vid återställning och provisoriska lösningar som ett generiskt riskbibliotek kan missa. För en praktisk struktur för dokumentationen, se vår guide till ett operativt riskregister.

För varje betydande risk, dokumentera ägare, bedömning, befintliga kontroller, behandlingsbeslut, önskat utfall och bedömning av kvarstående risk. Möjliga behandlingsstrategier är att minska exponeringen, undvika en aktivitet, dela delar av risken eller acceptera den enligt definierade kriterier. Försäkring eller outsourcing tar inte bort alla konsekvenser eller allt ansvar.

Översätt behandlingen till arbete med tydligt ansvar. ”Förbättra åtkomstsäkerheten” är ingen genomförbar plan. Ange vilka system som berörs, vilken förändring som krävs, ägaren, kriterierna för slutförande och hur effektiviteten ska utvärderas.

Håll isär dessa dokument:

De bör stämma överens utan att bli kopior av varandra. Om en behandling bygger på leverantörsuppföljning men den tillhörande kontrollen är utesluten utan förklaring, lös motsägelsen innan revisionsförberedelserna.

Se över riskerna med planerade intervall och när betydande förändringar inträffar. En ny supportleverantör, utökad datainsamling, en incident eller en större arkitekturförändring kan göra ett tidigare beslut inaktuellt.

Gör kontrollerna till en del av den ordinarie driften

En policy anger förväntningar; en rutin förklarar hur arbetet går till; driftdokumentation visar vad som faktiskt skedde. Certifieringsförberedelserna kräver alla tre där de är relevanta.

En åtkomstpolicy bör till exempel kopplas till en införd process för nyanställda och avgående, stickprov på åtkomständringar och en genomgång av undantag. Ett policydokument ensamt lämnar större delen av den berättelsen obevisad.

Bygg processen kring de faktiska ansvarsområdena. Identifiera vem som begär åtkomst, vem som godkänner den, vem som tilldelar den, vad som händer när någons roll ändras och hur konton tas bort. Inkludera tjänstekonton och externa användare där de påverkar omfånget.

Tillämpa samma tänkande på andra viktiga processer:

• Leverantörsbedömning bör koppla samman tjänstens kritikalitet, åtkomst till information, avtalsmässiga förväntningar, granskningsresultat och olösta frågor.
• Incidenthantering bör koppla samman rapporteringsvägar, ansvar för hantering, eskalering, återställning och lärdomar.
• Säkerhetskopiering och återställning bör koppla samman verksamhetens behov, skyddade system, återställningsrutiner, testresultat och uppföljande arbete.
• Ändringshantering bör koppla samman godkännande, testning, driftsättningsdokumentation, akuta ändringar och undantag.

Fysiska och personalrelaterade kontroller spelar fortfarande roll i en molnbaserad organisation. Distansarbete, skydd av enheter, konfidentiella samtal, förändringar i anställningar och medvetenhet kan inte avfärdas bara för att servrarna är outsourcade.

Fastställ kontrollfrekvenser utifrån risk och driftbehov. Skriv inte in ett löfte om kvartalsvis genomgång i en policy om inte ägaren kan genomföra den och spara dokumentation. En policy som beskriver en process som ingen följer skapar ett onödigt glapp mellan avsikt och genomförande.

Utforma belägg för granskning, inte för volym

Bra belägg besvarar en definierad fråga om ett krav eller en kontroll. En stor mapp med skärmdumpar är inte i sig starkare än en mindre, väl förklarad uppsättning tillförlitliga dokument.

För varje viktig kontroll, ange källsystem, ägare, insamlingsmetod, täckning, förväntad frekvens och granskare. Skilj mellan belägg för utformning och belägg för drift. En identitetskonfiguration kan visa att flerfaktorsautentisering är aktiverad; godkännandeprotokoll och behörighetsgranskningar visar andra aspekter av åtkomststyrningen.

Belägg bör göra sin innebörd tydlig:

• Vilken tjänst, vilket system eller vilken population omfattar det?
• När togs det fram, och vilken period avser det?
• Är det tillräckligt fullständigt för den fråga som bedöms?
• Vem granskade det, och vilka undantag identifierades?
• Vilken uppföljning ledde undantagen till?

Spara även misslyckade utfall. Ett misslyckat återställningstest med dokumenterad utredning, åtgärd och ett lyckat omtest kan visa att uppföljning och förbättring fungerar. Att radera obekväma resultat skadar dokumentationens användbarhet.

Skydda belägg som information i sig. Exporter kan innehålla uppgifter om anställda, kundidentifierare eller känsliga konfigurationer. Begränsa åtkomsten, minimera onödigt innehåll och fastställ lagringstid utifrån relevanta skyldigheter och verksamhetsbehov. Ordna kontrollerad åtkomst för revisorer i stället för att lättvindigt dela ut omfattande arkiv.

Använd internrevision och ledningens genomgång för att testa beredskapen

Internrevisionen utvärderar om ISMS:et överensstämmer med tillämpliga krav och är effektivt infört och underhållet. Den bör omfatta ledningssystemet, inte bara kontrollera tekniska inställningar.

Planera revisionens omfång, kriterier, metoder och rapportering. Välj kompetenta revisorer och värna objektivitet och opartiskhet. En liten organisation kan använda externt stöd eller lämpliga tvärfunktionella upplägg i stället för att be en person utvärdera allt sitt eget arbete.

Användbar revisionstestning följer ett ärende genom processen. Välj en medarbetare som slutat och kontrollera underrättelse, borttagning av konton, hantering av utrustning och undantag. Välj en leverantör och granska om dess riskbedömning stämmer med dess faktiska åtkomst. Välj en behandlingsåtgärd och verifiera om det angivna slutförandet har stöd i driften.

Dokumentera iakttagelser korrekt, inklusive kravet, observerade belägg och glappet. Reducera inte revisionen till ett procentvärde för färdigställande som döljer saknade ledningsprocesser.

Ledningens genomgång behandlar sedan de obligatoriska underlagen, bland annat prestanda, revisionsresultat, förändringar, status för riskbedömning och riskbehandling samt möjligheter till förbättring. Förbered ett kortfattat beslutsunderlag med stödjande dokumentation tillgänglig. Förklara var ledningen behöver välja mellan åtgärder, ytterligare resurser, ändrade mål eller godkänd riskacceptans.

Vid avvikelser, skilj omedelbar korrigering från korrigerande åtgärd. Att inaktivera ett förbisett konto korrigerar det omedelbara problemet. Att reparera underrättelseprocessen och kontrollera senare avgångar motverkar att det upprepas. Dokumentera orsak, åtgärd, ägare och utvärdering av effektiviteten.

Förstå steg 1, steg 2 och certifieringsbeslutet

En första certifiering omfattar normalt två revisionssteg. Kom överens med certifieringsorganet om upplägg, förväntad dokumentation och förväntningar på beredskap i tillräckligt god tid för att kunna planera ordentligt.

Steg 1 granskar beredskap, omfång och ledningssystemets dokumentation. Det hjälper organet att förstå organisationen och bedöma beredskapen inför steg 2. Räkna med granskning av sambandet mellan omfång, riskbedömning, behandling, SoA och ledningsprocesser. Åtgärda identifierade frågor i stället för att behandla steg 1 som en administrativ bokning.

Steg 2 utvärderar införande och effektivitet. Revisorerna använder intervjuer, observationer och stickprov i dokumentationen för att testa om ISMS:et fungerar som det beskrivs. Medarbetare bör kunna förklara sina faktiska ansvarsområden, inte rabbla inövade svar.

Håll ordning på förfrågningarna under revisionen. Utse en samordnare, registrera förfrågningar, identifiera rätt ägare och lämna relevanta belägg med sammanhang. Om något saknas, förklara situationen korrekt. Skapa inte dokumentation i efterhand som felaktigt antyder att en process har genomförts.

En avvikelse innebär att ett krav inte har uppfyllts. Större avvikelser påverkar ledningssystemets förmåga att uppnå avsedda resultat; mindre avvikelser har inte den effekten. Klassificeringen beror på sammanhanget, så en enskild saknad uppgift kan inte på förhand ges en allmängiltig etikett.

Certifieringsorganet fastställer självständigt avvikelser, krav på åtgärder, verifieringsupplägg och certifieringsbeslut. Bekräfta dess tidsfrister och uppföljningskrav i förväg. En revisors rekommendation är inte i sig ett utfärdat certifikat, och olösta avvikelser kan fördröja beslutet.

Efter certifieringen omfattar en typisk cykel övervakningsrevisioner under mellanåren och omcertifiering innan det treåriga certifikatet löper ut. Bekräfta det specifika revisionsprogrammet och villkoren med ert organ. Övervakningen är inget tillstånd att pausa ISMS:et mellan besöken.

Planera tidslinje och budget utifrån beroenden

Tidsåtgången beror på mognad, omfång, olösta risker, tillgång till belägg, intern kapacitet och revisorernas schemaläggning. Det finns ingen universell period av driftbelägg enligt ISO 27001 som automatiskt gör varje organisation redo.

Fråga certifieringsorganet vad det behöver ta stickprov på i ert fall. En process som utförs månatligen ger dokumentation på ett annat sätt än en årlig övning. Vänta inte till revisionsbokningen med att upptäcka att en viktig kontroll aldrig har genomförts.

Skilj arbete ni kan påskynda – insamling, samordning, utkast och förberedelser för granskning – från arbete som kräver införande och påvisad drift. Kör oberoende uppgifter parallellt, men respektera beroendena: ett SoA kan inte färdigställas trovärdigt utan resonemang kring valet av kontroller, och effektiviteten kan inte utvärderas enbart utifrån en föreslagen policy.

Använd beredskapsgrindar i stället för ett enda optimistiskt slutdatum:

Budgetera för intern insats, åtgärder, verktyg, utbildning, eventuellt rådgivningsstöd och extern bedömning. Inkludera övervakningsrevisioner, omcertifiering och löpande underhåll, inte bara fakturan för den första revisionen.

Be certifieringsorganen förklara sina antaganden om personal, platser, verksamhet, komplexitet och revisionsupplägg. Jämför hela cykeln och avgifterna för uppföljning. Undvik att se en låg första offert som den fullständiga kostnaden för att driva ett certifierat ISMS.

Räkneexempel: en tjänst, en hållbar plan

Tänk dig ett illustrativt företag med 30 anställda som driver en tjänst för dokumentdelning. Anta att det redan har identitetshantering, godkännanden av driftsättningar och säkerhetskopiering, men att leverantörsgranskningar och dokumentation av behörighetsgranskningar är ojämna. Den presumtiva kunden vill ha en försäkran för den driftade tjänsten, inklusive supportåtkomst.

Ledningen avgränsar omfånget till tjänsten och de stödjande processerna för utveckling, drift och support. Den dokumenterar gränssnitten mot HR och gemensam IT i stället för att utesluta deras säkerhetspåverkan. VD är sponsor för programmet; en implementeringsansvarig samordnar det; verksamhetscheferna äger kontrollerna.

Teamet identifierar ett scenario där alltför omfattande supportbehörigheter exponerar kunddokument. Behandlingen omfattar begränsade supportroller, godkänd tillfällig behörighetshöjning, behörighetsgranskningar och övervakning anpassad till tjänsten. SoA dokumenterar de nödvändiga kontrollerna och deras implementeringsstatus.

Åtkomstägaren samlar sedan in en rollkonfiguration, stickprov på godkännanden, en genomförd granskning och belägg för att de alltför omfattande behörigheter som upptäcktes vid granskningen togs bort. Denna dokumentation visar mer än att en åtkomstpolicy finns.

Vid internrevisionen upptäcks att en konsult som avslutat sitt uppdrag fortfarande har ett aktivt konto. Teamet inaktiverar det, utreder den missade underrättelsen från HR till IT, lägger till ett uttryckligt steg för avslut av konsulter och kontrollerar senare avgångar för att utvärdera effektiviteten. Ledningens genomgång behandlar iakttagelsen, kvarstående risker och de resurser som behövs för löpande granskningar.

Enbart för budgetplanering: anta att åtta medarbetare vardera lägger två timmar i veckan under tolv veckor. Det blir 192 interna timmar, före specialiståtgärder och deltagande i revisionen. Detta är en illustrativ kapacitetsberäkning, inte en marknadsuppskattning eller ett löfte om certifiering.

Lärdomen gäller ledarskap: tilldela arbete till personer med mandat, reservera kapacitet och låt beredskapen avgöras av belägg. Befintliga tekniska skydd minskar en del av implementeringsarbetet, men de ersätter inte riskbeslut, internrevision eller ledningens genomgång.

Automatisera upprepbart arbete men behåll omdömet

Automatisering kan stödja uppdatering av förteckningar, insamling av belägg, påminnelser, tekniska kontroller och rapportering. Prioritera återkommande arbete med tillförlitliga källdata och en tydlig granskare, snarare än att automatisera en oklar process.

En automatiserad kontroll behöver definierad täckning och hantering av fel. Om en koppling slutar samla in data, skilj mellan ”inga problem upptäckta” och ”inga aktuella data”. Bekräfta att källan omfattar relevanta system, konton eller platser innan ni förlitar er på resultatet.

Håll det mänskliga omdömet uttryckligt för riskacceptans, kontrollers tillämplighet, slutsatser om belägg och ledningsbeslut. En konfigurationskontroll kan visa att kryptering är aktiverad; den fastställer inte att nyckelåtkomst, återställning och undantagsvägar för data hanteras på lämpligt sätt.

På samma sätt kan arbetsflödesautomatisering organisera förfrågningar och iakttagelser i internrevisionen, men den tillför inte revisionskompetens eller oberoende. AI-genererade sammanfattningar och mappningar bör förbli utkast tills en granskare har kontrollerat källorna och godkänt slutsatserna.

Mät både effektivitet och ändamålsenlighet: tid för att förbereda belägg, försenade korrigerande åtgärder, ofullständig täckning, upprepade fel och tiden det tar att lösa viktiga undantag. Vår guide till ISMS-mått förklarar hur man gör mått användbara för ledningens beslut.

Håll ägarskapet aktivt efter certifieringen

Upprätta underhållskalendern innan certifikatet kommer. Praktiska rekommendationer är regelbundna kontroller av ägare, riskgenomgångar som utlöses av väsentliga förändringar, planerade utvärderingar av kontroller, internrevisioner, ledningens genomgångar och förberedelser inför externa bedömningar. Välj frekvenser utifrån process och risk i stället för att göra varje aktivitet månatlig.

Fördela om ansvar när medarbetare byter roll eller slutar. Se över omfång och kontrollers tillämplighet när verksamheten förändras. Följ upp återkommande undantag: upprepade sena borttagningar av åtkomst tyder på ett processproblem även om varje enskilt fall till slut stängs.

Secani stöder detta arbetsflöde genom att koppla samman krav, kontroller, belägg, ägare, uppgifter och granskningsbeslut i en gemensam arbetsyta. Börja med en representativ tjänst, modellera dess system och beroenden, koppla befintliga belägg till det de visar och omvandla luckor till tilldelade uppgifter. Granska AI-assisterade förslag mot deras källor och bevara mänskliga godkännanden och beslutshistorik. Det hjälper teamet att behålla det det lär sig under certifieringen när systemen förändras; certifieringen är fortfarande det oberoende organets beslut.

Frågor som ändrar implementeringsplanen

Kräver ISO 27001 ett penetrationstest?

Det finns ingen universell bestämmelse i ISO 27001 som kräver att varje organisation genomför ett penetrationstest. Vilken testning som behövs beror på riskbehandling, tillämpliga kontroller, tjänstens egenskaper och avtalskrav. Där testning behövs, definiera täckning, åtgärder och omtestning i stället för att bara spara en rapport.

Borde vi satsa på SOC 2 i stället?

Fråga vad kunderna kräver och vilket omfång de förväntar sig. SOC 2 ger en attestrapport; ISO 27001 ger en certifiering av ledningssystemet. En del driftbelägg kan återanvändas, men inget av dem omvandlas automatiskt till det andra. Utvärdera de separata kraven innan ni binder er till båda.

Behöver vi en extern konsult?

Inte nödvändigtvis. Extern hjälp kan bidra med tolkning, kapacitet eller specialistkunskap. Behåll det interna ägarskapet och se till att rutinerna förblir användbara när uppdraget avslutas. En persons behörighet som implementerare eller revisor certifierar inte hens arbetsgivare.

Börja med ett beslut och ett spår av belägg

Godkänn en kort implementeringsstadga som anger det kommersiella behovet, avsett omfång, sponsor, ansvarig, kontrollägare, kapacitet och beredskapsgrindar. Ta sedan en viktig tjänst och följ en kontroll från krav till riskbehandling, införande, belägg och granskning.

Det första spåret kommer att avslöja otydliga ansvarsområden och saknad dokumentation innan de mångfaldigas. Använd vår checklista för ISO 27001 för att organisera det återstående arbetet, och håll samtidigt isär kraven på ledningssystemet och kontrollernas tillämplighet.

Ett bestående ISMS gör säkerhetsbeslut granskningsbara och upprepbara. Certifieringen erkänner systemet inom dess omfång; ledningen håller det i drift efter att revisionsteamet har gått.