Waarom ISO 27001-controls falen als verantwoordelijkheden niet duidelijk zijn
De meeste organisaties weten vrij goed welke ISO 27001-controls ze nodig hebben. De uitdaging zit vooral in de dagelijkse uitvoering en opvolging ervan. Een risicoanalyse bepaalt bijvoorbeeld dat toegangsrechten periodiek moeten worden gecontroleerd, in de Statement of Applicability staat dat de control geïmplementeerd is en een procedure beschrijft hoe back-ups worden uitgevoerd. Dat is de basis, maar daarmee weet je nog niet of die controls in de praktijk ook effectief en consequent werken.
Wie controleert of de toegangsreview werkelijk is uitgevoerd? Wie volgt op wanneer een restoretest mislukt? Wie beoordeelt een uitzondering? En welk bewijs toont aan dat een control niet alleen ooit werd ingevoerd, maar vandaag nog altijd correct wordt toegepast?
Een control is dus niet geïmplementeerd omdat hij in een register staat. Hij moet ook aantoonbaar werken in de praktijk. Dat is een belangrijk verschil.
Van risico naar een werkende control
ISO 27001 vertrekt vanuit risico’s.
Je bepaalt welke risico’s relevant zijn, hoe je ermee wilt omgaan en welke beheersmaatregelen daarvoor nodig zijn. Maar het selecteren van een control is nog maar het begin.
Daarna moet die control onderdeel worden van de dagelijkse werking.
Iemand moet activiteiten uitvoeren, resultaten beoordelen, afwijkingen opvolgen en nagaan of de control nog steeds passend is wanneer systemen, medewerkers, leveranciers of risico’s wijzigen.
Daar loopt het vaak fout.
Organisaties kunnen perfect antwoorden op vragen zoals:
- Welke control hebben we geselecteerd?
- Welk risico willen we ermee beperken?
- Welke procedure beschrijft de werkwijze?
Maar veel moeilijker wordt het wanneer je vraagt:
- Wie is verantwoordelijk voor de goede werking?
- Wat moet er concreet gebeuren?
- Wie voert het uit?
- Hoe vaak?
- Welk resultaat verwachten we?
- Welk bewijs moet beschikbaar zijn?
- Wat gebeurt er wanneer iets niet of te laat gebeurt?
Als die vragen niet duidelijk beantwoord kunnen worden, bestaat de control misschien wel in het managementsysteem, maar daarom nog niet in de dagelijkse werking.
Waarom gedeelde verantwoordelijkheid vaak tot onduidelijkheid leidt
Bij informatiebeveiliging zijn bijna altijd meerdere afdelingen betrokken. Bij het beheer van toegangsrechten bijvoorbeeld meldt HR wanneer iemand start, van functie verandert of uit dienst gaat. De leidinggevende bepaalt welke toegang nodig is, IT voert de wijzigingen uit en soms beheert een externe partner een deel van de infrastructuur.
Dat is op zich geen probleem. Verschillende partijen kunnen perfect een rol hebben in dezelfde control. Maar er moet wel één duidelijke verantwoordelijke zijn die het overzicht bewaart en de opvolging verzekert.
Wie controleert bijvoorbeeld of de periodieke toegangsreview effectief werd uitgevoerd? Wie beoordeelt uitzonderingen? Wie volgt een mislukte restoretest op? En wie controleert of een leverancier een vastgesteld beveiligingsprobleem daadwerkelijk heeft opgelost?
De verantwoordelijke hoeft al die taken uiteraard niet zelf uit te voeren. Hij of zij moet er wel voor zorgen dat duidelijk is wat moet gebeuren, wie het uitvoert, wanneer het moet gebeuren en wat er gebeurt wanneer het resultaat niet voldoet.
Een naam naast een control zetten is dus niet voldoende. De verantwoordelijke moet ook over de nodige informatie en bevoegdheid beschikken om die control effectief op te volgen.
Meerdere mensen kunnen bijdragen aan de uitvoering. De verantwoordelijkheid voor de opvolging moet duidelijk zijn.
Wat moet je voor iedere ISO 27001-control minstens vastleggen?
We hoeven dit niet ingewikkelder te maken dan nodig.
Voor iedere relevante control moet minstens duidelijk zijn:
- welk risico, vereiste of doel ermee wordt beheerst;
- wie verantwoordelijk is voor de control;
- welke activiteiten moeten worden uitgevoerd;
- wie die activiteiten uitvoert;
- wanneer of hoe vaak dit moet gebeuren;
- welk resultaat aanvaardbaar is;
- welk bewijs moet worden bijgehouden;
- wat gebeurt bij een afwijking;
- hoe de doeltreffendheid wordt beoordeeld.
Dat maakt van een abstracte control een beheersbaar proces.
En het voorkomt een fout die ik regelmatig zie:
“Implemented” aanvinken en ervan uitgaan dat het daarmee geregeld is.
Dat een maatregel ooit werd ingevoerd, betekent niet dat hij zes of twaalf maanden later nog steeds correct wordt toegepast.
Bewijs moet tonen dat de control werkt
Bij ISO 27001 komt onvermijdelijk de vraag naar bewijs.
Ook daar wordt het soms verkeerd aangepakt.
Een procedure is bewijs dat je een werkwijze hebt vastgelegd. Ze bewijst niet dat die werkwijze consequent wordt uitgevoerd.
Een screenshot toont een configuratie op één bepaald moment. Hij zegt weinig over wat er de maanden daarvoor gebeurde.
Een lijst met gebruikers toont wie toegang heeft. Maar als je een periodieke toegangsreview wilt aantonen, wil je ook weten wie de lijst heeft beoordeeld, welke rechten werden aangepast, welke uitzonderingen werden aanvaard en of de gevraagde wijzigingen effectief werden uitgevoerd.
Bewijs moet dus niet alleen aantonen dat iets bestaat. Het moet aantonen dat de control heeft gewerkt.
Dat betekent niet dat je voor iedere control zoveel mogelijk documenten en logs moet bewaren. Meer bewijs is niet automatisch beter.
Je hebt voldoende betrouwbare informatie nodig om te kunnen aantonen:
- wat er gebeurd is;
- wanneer;
- door wie;
- wat het resultaat was;
- welke afwijkingen werden vastgesteld;
- en hoe die werden opgevolgd.
Het doel is uiteindelijk niet zoveel mogelijk bewijs verzamelen.
Het doel is een doeltreffende control. Het bewijs maakt dat zichtbaar.
Enkele praktische voorbeelden
Dat verschil wordt duidelijker met een paar voorbeelden.
Toegangsreviews
Een gebruikerslijst is op zich geen bewijs van een goede toegangsreview.
Je wilt kunnen aantonen wie de rechten beoordeeld heeft, welke criteria werden gebruikt, welke toegangen gewijzigd of verwijderd moesten worden en of die wijzigingen ook effectief werden uitgevoerd.
Back-up en recovery
Een geslaagde back-up betekent dat gegevens werden gekopieerd.
Dat bewijst nog niet dat je ze binnen de gewenste termijn kunt herstellen.
Daarom is een restoretest belangrijk. En wanneer zo’n test problemen aan het licht brengt, moeten die problemen worden geregistreerd en opgevolgd.
Security awareness
Een aanwezigheidslijst bewijst dat iemand een opleiding heeft gevolgd.
Maar begrijpt die persoon wat van hem verwacht wordt? Heeft de opleiding effect gehad? Zijn er specifieke risico’s voor bepaalde functies? Wat leren phishing-simulaties of andere controles ons?
Vulnerability management
Een vulnerability scan kan honderden bevindingen opleveren.
De control zit niet in het produceren van die lijst. De echte beheersing zit in het beoordelen van de risico’s, prioriteiten bepalen, acties toewijzen, uitzonderingen goedkeuren en uiteindelijk controleren of kritieke kwetsbaarheden werden opgelost.
Leveranciersbeveiliging
Een securityclausule in een contract is nuttig.
Maar een leverancier blijft veranderen. Diensten veranderen. Risico’s veranderen. Incidenten kunnen optreden.
Leveranciersbeveiliging vraagt daarom ook verdere evaluatie en opvolging.
De bronlogica is telkens dezelfde: het bewijs moet niet alleen documentatie tonen, maar de effectieve werking en opvolging van de control.
Als je voor iedere audit bewijs moet beginnen zoeken, zit er iets fout
Ook dit is herkenbaar.
De externe audit komt eraan en plots begint de zoektocht.
Screenshots opvragen.
E-mails terugzoeken.
Teams contacteren.
Excelbestanden reconstrueren.
Controlverantwoordelijken vragen wat er zes maanden geleden gebeurd is.
Dat kost enorm veel tijd.
Maar het grotere probleem is dat je informatie pas verzamelt nadat ze managementwaarde had kunnen hebben.
Stel dat een toegangsreview vier maanden te laat werd uitgevoerd. Als je dat pas ontdekt wanneer je bewijs verzamelt voor de audit, heb je vier maanden lang geen controle gehad over dat proces.
Hetzelfde geldt voor een mislukte restoretest, een niet opgevolgde kwetsbaarheid of een ontbrekende leveranciersreview.
Audit readiness zou het gevolg moeten zijn van een goed beheerst proces. Niet van een grote schoonmaak vlak voor de auditor komt.
Koppel risico, control, actie en bewijs
Daar ligt ook de meerwaarde van digitalisering.
Niet simpelweg een Excelregister vervangen door een online register.
De relevante informatie moet met elkaar gekoppeld zijn.
Een risico leidt tot een beslissing over behandeling. Daaruit volgen één of meerdere controls. Voor die controls zijn verantwoordelijkheden, activiteiten en termijnen vastgelegd. De uitvoering genereert bewijs. Een afwijking leidt waar nodig tot een actie of CAPA.
In eenvoudige vorm:
risico → control → verantwoordelijke → uitvoering → bewijs → afwijking → actie → opvolging
Dan krijg je ook zicht op wat vandaag belangrijk is:
- welke controles nog moeten worden uitgevoerd;
- welke deadlines naderen;
- waar bewijs ontbreekt;
- welke afwijkingen openstaan;
- welke acties hun termijn hebben overschreden;
- welke controls opnieuw moeten worden beoordeeld.
Een control failure verdwijnt dan niet ergens in een e-mail of auditrapport, maar wordt onderdeel van de normale opvolging.
Digitaliseren lost een slechte control niet op
Ook hier geldt hetzelfde als bij CAPA en audits.
Een slecht ontworpen control wordt niet goed omdat je hem digitaliseert.
Software kan verantwoordelijkheden zichtbaar maken, herinneringen versturen, bewijs centraal bewaren, acties opvolgen en rapporten genereren.
Maar eerst moet de organisatie zelf begrijpen:
Welk risico willen we beheersen? Wat moet deze control bereiken? Wie is verantwoordelijk? Hoe weten we of hij werkt?
Als die basis niet duidelijk is, ga je vooral een onduidelijk proces digitaliseren.
Technologie moet de beheersing ondersteunen.
Niet proberen ze te vervangen.
Een eenvoudige test voor iedere ISO 27001-control
Je hoeft daar eigenlijk geen ingewikkeld model voor te maken.
Neem iedere control en stel deze vragen:
- Welk risico of doel beheerst deze control?
- Wie is verantwoordelijk voor het resultaat?
- Wat moet concreet gebeuren?
- Wanneer of hoe vaak?
- Wat is een aanvaardbaar resultaat?
- Welk bewijs ontstaat daarbij?
- Wat gebeurt er wanneer de control faalt?
- Hoe beoordelen we of de control doeltreffend blijft?
Kun je die vragen duidelijk beantwoorden?
Dan heb je waarschijnlijk een behoorlijk beheerste control.
Kun je dat niet?
Dan zou ik eerst daar beginnen voordat je je zorgen maakt over wat de auditor zal vragen.
Conclusie
ISO 27001 draait niet om het verzamelen van controls.
Het gaat erom dat de juiste beheersmaatregelen betrouwbaar werken en blijven werken.
Daarvoor moeten risico, verantwoordelijkheid, uitvoering, bewijs en opvolging met elkaar verbonden zijn. En wanneer een control niet werkt zoals verwacht, moet dat zichtbaar worden en leiden tot actie.
De sterkste organisaties beginnen daarom niet enkele weken voor een audit bewijs te verzamelen. Het bewijs ontstaat gewoon als onderdeel van de dagelijkse werking.
Een control is pas onder controle wanneer je weet wie verantwoordelijk is, wat er moet gebeuren en kunt aantonen dat het ook werkelijk gebeurt.
Maak ISO 27001 beheersbaar in de dagelijkse praktijk
Met Phronesys verbind je risico’s, audits, verantwoordelijkheden, documenten, vaststellingen en corrigerende maatregelen binnen één digitaal managementsysteem. Zo blijft niet alleen zichtbaar welke controls zijn bepaald, maar ook hoe ze worden uitgevoerd en opgevolgd.