Gap-analyse versus interne audit: wat heeft u nu nodig?

"Kunnen we niet gewoon een gap-analyse doen in plaats van die interne audit?" Het is een vraag die we regelmatig terugkrijgen, en het is een logische vraag: beide klinken als een controle van uw informatiebeveiliging, beide leveren een rapport op, en beide worden vaak door dezelfde partij aangeboden. Toch beantwoorden ze een fundamenteel andere vraag, op een fundamenteel ander moment in uw traject. Door ze door elkaar te gebruiken, loopt u het risico dat u óf te vroeg audit-achtige stappen zet op een systeem dat er nog niet is, óf denkt aan een verplichting te voldoen die u in werkelijkheid heeft overgeslagen.

Onze bredere vergelijking van interne audit, gap-analyse en certificatieaudit zet alle drie auditvormen naast elkaar. Dit artikel zoomt specifiek in op de vraag die daarbinnen het vaakst voor verwarring zorgt: wanneer kiest u voor een gap-analyse, wanneer voor een interne audit, en wat als u eigenlijk allebei nodig heeft?

Twee vragen, geen synoniemen

Een gap-analyse is een nulmeting. U legt uw huidige situatie naast een doelnorm of raamwerk — ISO 27001, NIS2, of een ISAE/SOC-controleraamwerk — en brengt in kaart wat er nog ontbreekt. De gap-analyse stelt de vraag: wat moet er nog gebouwd worden? Ze wordt typisch uitgevoerd vóór of vroeg in een implementatietraject, wanneer er nog geen volwaardig werkend managementsysteem staat om te toetsen.

Een interne audit stelt een andere vraag: werkt wat er staat, in de praktijk? Dat veronderstelt dat er al iets staat om te toetsen — een operationeel ISMS met beleid, maatregelen en vastgelegde processen. Bij ISO 27001 is de interne audit bovendien geen vrijblijvende exercitie: de norm vereist een terugkerende, minstens jaarlijkse interne audit als vast onderdeel van de PDCA-cyclus (Plan-Do-Check-Act) waarmee u het systeem continu bijstuurt.

Het verschil zit dus niet in de zwaarte of de diepgang, maar in het onderwerp: de gap-analyse kijkt naar een norm en een nog-niet-bestaand of nog-onvolledig systeem, de interne audit kijkt naar een bestaand systeem en de norm. Die volgorde — eerst weten wat ontbreekt, dan bouwen, dan periodiek toetsen of het werkt — is precies waarom de twee elkaar niet vervangen.

Scenario 1: u begint bij nul

Stel, uw organisatie heeft nog geen ISMS en overweegt voor het eerst ISO 27001-certificering, bijvoorbeeld omdat een klant of aanbesteding erom vraagt. In dat geval heeft een interne audit simpelweg geen onderwerp: er is nog niets operationeels om te toetsen. Wat u wel nodig heeft, is een gap-analyse. Die brengt in kaart welke maatregelen, documentatie en processen u al heeft — vaak meer dan gedacht, denk aan bestaande IT-beveiliging of een informeel toegangsbeleid — en welke nog ontbreken ten opzichte van de norm. De uitkomst is een prioriteitenlijst en een realistische routekaart, niet een oordeel over of iets "werkt", want er is nog niets om te laten werken.

Scenario 2: u bent al gecertificeerd

Aan de andere kant van het traject staat de organisatie die al ISO 27001-gecertificeerd is en toewerkt naar de jaarlijkse surveillance-audit van de certificerende instelling. Hier is de gap-analyse allang gedaan, jaren geleden misschien, aan het begin van het traject. Wat nu nodig is, is een interne audit: een toetsing van het draaiende ISMS, met bewijsvoering, interviews en steekproeven, die aantoont dat de maatregelen niet alleen op papier staan maar ook daadwerkelijk worden nageleefd. Dit is precies de verplichte, terugkerende stap uit de PDCA-cyclus — geen eenmalige exercitie, maar een vast onderdeel van in stand houden wat u heeft opgebouwd.

Scenario 3: u heeft geïmplementeerd, maar nooit een auditritme opgezet

De derde situatie komt in de praktijk vaker voor dan u zou verwachten: een organisatie heeft ooit een implementatietraject doorlopen, misschien zelfs met een certificaat op zak, maar heeft de interne audit nooit als terugkerend ritme ingericht. Beleid is gedateerd, verantwoordelijkheden zijn niet meer actueel, en niemand kan met zekerheid zeggen of de maatregelen nog aansluiten op hoe het bedrijf nu werkt. In dat geval heeft u eigenlijk allebei nodig, in de juiste volgorde: eerst een frisse, gap-analyse-achtige health-check om te zien hoever het systeem is weggezakt van de norm, en pas daarna een volwaardig, terugkerend interne-auditprogramma om vanaf dat moment structureel te bewaken dat het systeem blijft werken. Een gap-analyse alleen fixt hier niets structureels; een interne audit zonder eerst de achterstand in kaart te brengen, toetst tegen een systeem dat mogelijk al niet meer aan de norm voldoet.

Wie voert wat uit — en waarom onafhankelijkheid vooral bij de interne audit telt

Bij de interne audit geldt hetzelfde onafhankelijkheidsprincipe dat ook elders in onze uitleg over de interne audit terugkomt: een partij die het ISMS heeft opgebouwd of geadviseerd, mag dat systeem niet ook zelf auditen. Dat risico op zelfcontrole ondermijnt de waarde van de interne audit als borgingsinstrument — de auditor beoordeelt dan mogelijk zijn eigen werk. Daarom besteden veel organisaties de interne audit uit aan een onafhankelijke Lead Auditor.

Bij de gap-analyse ligt dat anders. Een gap-analyse is diagnostisch, geen formele attestatie: ze levert een inschatting op van hiaten en een routekaart, niet een oordeel dat ergens aan wordt getoetst als bewijs richting een certificerende instelling. Datzelfde bedrijf dat straks de implementatie begeleidt, kan dus prima ook de gap-analyse hebben uitgevoerd, zonder dat er een belangenconflict ontstaat zoals bij de interne audit wél het geval is.

Veelgemaakte fouten

Een gap-analyserapport laten doorgaan voor de verplichte interne audit. Dit is de meest voorkomende misvatting. Een gap-analyse toetst een norm tegen een (nog) niet-werkend systeem; de interne audit toetst of een wél werkend systeem in de praktijk functioneert. Ze zijn niet uitwisselbaar, en een certificerende instelling accepteert een gap-analyserapport niet als vervanging van het verplichte interne-auditbewijs.

Direct audit-achtige toetsing doen zonder eerst een gap-analyse. Zonder nulmeting weet u niet tegen welke uitgangssituatie u toetst. Dat leidt tot een audit die vooral bevestigt wat u eigenlijk al vermoedde — dat er nog te veel ontbreekt — in plaats van een audit die zinvolle, gerichte verbeterpunten oplevert op een systeem dat al een basisniveau heeft.

Denken dat het onderscheid alleen voor ISO 27001 geldt. Ook bij NIS2 of een ISAE/SOC-controleraamwerk geldt dezelfde logica: eerst een gap-analyse tegen het relevante raamwerk, dan implementatie, dan een terugkerende interne-auditcyclus zodra er een operationeel systeem staat.

ISO/IEC 27001 — officiële normpagina (officiële bron).