En internrevision enligt ISO 27001 som förbättrar systemet

En internrevision ger organisationen en möjlighet att upptäcka var dess ledningssystem för informationssäkerhet (ISMS) skiljer sig från avsikterna. Det användbara resultatet är en underbyggd bedömning och en tydlig förbättringsväg för varje väsentligt fynd, inte bara en mapp med skärmbilder som förberetts inför certifieringen.

För en teknisk chef är den centrala frågan om systemet fungerar i verkliga tjänster, med verkliga människor och överlämningar. En policy kan vara godkänd medan genomförandet brister. En revision bör blotta den skillnaden utan att göra varje operativ ofullkomlighet till ett ounderbyggt fynd om bristande efterlevnad.

Fastställ vad revisionen måste visa

ISO/IEC 27001, avsnitt 9.2, kräver internrevisioner med planerade intervall för att bedöma överensstämmelse med organisationens egna krav på ISMS:et och med standarden, samt om ISMS:et har införts och underhålls på ett effektivt sätt. Revisionsprogrammet måste ta hänsyn till processernas betydelse och resultaten från tidigare revisioner, och revisorerna ska väljas så att objektivitet och opartiskhet säkerställs.

En internrevision kan utföras av anställda eller av en extern specialist som anlitas för ändamålet. Den utfärdar inget certifikat: certifiering är en separat bedömning som görs av ett oberoende certifieringsorgan. Internrevisioner är en del av driften av ISMS:et även efter certifieringen, inte bara en förberedelse inför den första bedömningen.

ISO 27001 föreskriver ingen universell årlig frekvens för internrevisioner. Som praktisk rekommendation, använd ett dokumenterat schema som speglar risker, förändringar och tidigare fynd, med tätare uppmärksamhet på instabila eller kritiska processer.

Kom överens om kriterier, gränser och ansvar

En enskild revision behöver inte granska allt på en gång. Programmet bör ge täckning av det avgränsade ISMS:et under den planerade cykeln, i stället för att gång på gång granska bara välbekanta kontroller.

Dokumentera följande beslut innan ni begär in underlag:

Bilaga A är inget krav på att införa varje kontroll på samma sätt. Kontrollera om besluten om tillämplighet och uteslutningar är motiverade och testa sedan de åtaganden som organisationen faktiskt har gjort.

Välj kompetenta revisorer som förstår både kraven på ledningssystemet och de kontroller som granskas. Undvik att låta personer revidera sitt eget arbete. I ett litet utvecklingsteam kan en extern revisor eller en granskare från en annan funktion lösa konflikter, förutsatt att de har tillräcklig kompetens och tillgång till underlag.

Bygg underlagen kring operativa frågor

Börja med omfattningen, riskbedömningen, riskbehandlingsplanen, uttalandet om tillämplighet, policyerna, tidigare fynd och relevant operativ dokumentation. De förklarar vad som borde hända och var brister skulle få störst betydelse.

Formulera sedan testbara frågor. För privilegierad åtkomst, fråga om godkännanden föregår åtkomst, om granskningarna omfattar den relevanta populationen av konton och om återkallade behörigheter faktiskt försvinner. En undertecknad åtkomstpolicy visar avsikten; kontoexporter, godkännandeprotokoll och loggar över borttagning visar driften.

Upprätta en urvalsplan som omfattar nyliga förändringar, kritiska tjänster, tidigare svagheter och undantag. Dokumentera populationen, urvalsmetoden, perioden och motiveringen. Praktiska urval behöver inte använda en enda fast urvalsstorlek, men de måste kunna förklaras. En handfull bekväma skärmbilder representerar sällan en hel driftperiod.

Triangulera dokumentation med intervjuer och observation. Om ägarna beskriver en manuell överlämning, granska genomförda överlämningar. Om underlagen motsäger en intervju, utred saken i stället för att välja den mer lugnande versionen. Dokumentera begränsningar när ett system inte kan tillhandahålla historiska underlag; dra inte i det tysta slutsatser om tidigare funktion utifrån den nuvarande konfigurationen.

Följ en kontroll genom ett exempel

Illustrativa antaganden: ett SaaS-företag reviderar avslut av anställningar under tre månader. Dess rutin kräver att åtkomsten tas bort senast vid den anställdes avgångstidpunkt. HR-uppgifterna visar 12 avslut; revisorn granskar alla tre privilegierade användare och fyra ytterligare avslut från olika team.

Revisorn jämför HR:s tidsstämplar för avgång med händelser hos identitetsleverantören, kontostatus i applikationerna och ärenden för avslut. En tidigare utvecklares konto hos identitetsleverantören inaktiverades i tid, men ett separat hanterat konto i kodförrådet förblev aktivt i två dagar.

Innan fyndet klassificeras ska ni fastställa om kontot kunde autentisera sig, vilka behörigheter som fanns kvar och om ett godkänt undantag fanns. Intervjua HR och applikationsägaren för att förstå överlämningen. Utöka testningen till andra avslut som berör separat hanterade applikationer om försummelsen verkar vara systematisk.

Ett försvarbart fynd anger den rutin som inte följts, det observerade förhållandet, stödjande dokumentation, berörd omfattning och möjlig konsekvens. Det bör inte påstå att obehörig åtkomst har skett om inte underlagen stöder den slutsatsen.

Skilj fynd från antaganden

En avvikelse kräver underlag som visar att ett krav inte har uppfyllts. En förbättringsmöjlighet identifierar en användbar förbättring utan att påvisa en överträdelse. En olöst fråga förblir öppen tills tillräckliga underlag stöder en slutsats.

Använd konsekventa klassificeringar och prioritera fynd utifrån exponering, återkommande och bredd. Låt inte en etikett för allvarlighetsgrad ersätta resonemanget. Ge processägarna möjlighet att rätta faktafel, men behåll revisorns ansvar för slutsatsen.

Rapporten bör ange omfattning, kriterier, metoder, begränsningar, fynd och den övergripande bedömning som stöds av det utförda arbetet.

Gör korrigerande åtgärder till mer än ett avslut

En åtgärdsplan bör ange en ägare, ett förfallodatum, en omedelbar rättelse, grundorsaken och den förändring som ska förhindra att felet upprepas. Att ta bort kontot i kodförrådet rättar just det fallet. Att åtgärda den ofullständiga applikationsförteckningen och överlämningen från HR till IT hanterar processen.

Undvik att godta ”mänskligt misstag” som hela grundorsaken när arbetsflödet bygger på minnet eller saknar ägarskap. Definiera kriterier för effektivitet innan åtgärden stängs: till exempel att efterföljande avslut måste omfatta avstämda kontroller mot den relevanta applikationsförteckningen.

Ett avslutat ärende visar att åtgärden har utförts, inte nödvändigtvis att den är effektiv. Granska ett nytt urval efter genomförandet och spara resultatet av verifieringen. Öppna åtgärden igen om samma brist återkommer.

För in resultaten i ledningen och i det dagliga arbetet

Rapportera återkommande svagheter, försenade åtgärder, resursbehov och betydande riskbeslut till relevant ledning. Resultaten från internrevisionen är ett underlag till ledningens genomgång enligt ISO 27001; genomgången är en separat aktivitet med andra obligatoriska underlag, inte bara ett möte för att godkänna revisionsrapporten.

Secani kopplar ihop krav, underlag, ägare, uppgifter och granskningsbeslut så att bedömning och uppföljning förblir i sitt sammanhang. Håll stödjande dokumentation kopplad till de relevanta kontrollerna och bevara mänskligt godkännande av slutsatser om underlag. Använd vår guide om revisionsberedskap för att organisera dokumentationen före fältarbetet.

Ett praktiskt nästa steg är att välja en kritisk process, utse en opartisk revisor och skriva ned kriterierna och urvalsplanen. Schemalägg kontrollen av effektiviteten när de korrigerande åtgärderna tilldelas, inte efter att alla anser att de är klara.