
Bijlage A biedt securityteams een nuttige referentieset. De operationele waarde ervan ontstaat pas wanneer u laat zien waarom een beheersmaatregel van toepassing is, hoe die is geïmplementeerd en welk bewijs die in uw omgeving ondersteunt. Een register met 93 groene statusindicatoren volstaat niet als niemand kan uitleggen op welke systemen die indicatoren betrekking hebben.
Voor een CTO is de praktische uitdaging om de bedoeling van beheersmaatregelen te vertalen naar engineering- en operationeel werk, zonder van het managementsysteem voor informatiebeveiliging een parallelle bureaucratie te maken. Toegangsreviews moeten echte rechtengegevens gebruiken. Herstelplannen moeten de afhankelijkheden van diensten weerspiegelen. Leveranciersbeoordelingen moeten gaan over de diensten die het bedrijf daadwerkelijk afneemt.
Deze gids legt uit hoe u beheersmaatregelen selecteert, eigenaarschap verdeelt, implementaties vastlegt en de daaruit voortvloeiende claims test. De reviewfrequenties en implementatievoorbeelden hieronder zijn praktische aanbevelingen, geen universele termijnen die de norm voorschrijft.
ISO/IEC 27001:2022 bevat 93 beheersmaatregelen in bijlage A, verdeeld over vier thema's. De hoofdstukken 4 tot en met 10 bevatten de eisen aan het managementsysteem: context van de organisatie, leiderschap, planning, ondersteuning, uitvoering, evaluatie van de prestaties en verbetering. Bijlage A ondersteunt de selectie van beheersmaatregelen; ze vervangt die eisen of uw risicobeoordeling niet.
Dat onderscheid is van belang tijdens de implementatie. Een back-upconfiguratie kan een geselecteerde beheersmaatregel ondersteunen, maar toont niet aan dat u de reikwijdte van het ISMS hebt bepaald, risico's hebt beoordeeld, een interne audit hebt uitgevoerd of een directiebeoordeling hebt afgerond. Dat zijn afzonderlijke activiteiten met afzonderlijk bewijs.
De selectie van beheersmaatregelen is risicogebaseerd. Bepaal welke beheersmaatregelen nodig zijn om uw risico's te behandelen en vergelijk die vervolgens met bijlage A om na te gaan dat er geen noodzakelijke beheersmaatregelen zijn weggelaten. Aanvullende beheersmaatregelen buiten bijlage A kunnen nodig zijn. Omgekeerd is een gemotiveerde uitsluiting mogelijk; er bestaat geen regel dat elke organisatie iets moet uitsluiten of precies dezelfde selectie moet implementeren.
ISO/IEC 27002:2022 biedt implementatierichtlijnen voor de beheersmaatregelen. De attributen daarin helpen om ze te ordenen naar type beheersmaatregel, informatiebeveiligingseigenschap, cybersecurityconcept, operationele capaciteit en beveiligingsdomein. Dat zijn nuttige filterhulpmiddelen, geen aanvullende certificeringschecklists. Raadpleeg de gelicentieerde normen voor de gezaghebbende formulering.
De thema's bieden een navigatiestructuur, geen vier onafhankelijke werkstromen. Een uitdiensttredingsproces bijvoorbeeld verbindt verantwoordelijkheden uit het dienstverband, identiteitsbeheer, het inleveren van apparatuur en toegang tot applicaties.
| Thema | Verwijzingen | Aantal | Typische operationele betrokkenen |
|---|---|---|---|
| Organisatorisch | A.5.1–A.5.37 | 37 | Directie, security, inkoop, juridische zaken, diensteigenaren |
| Mensen | A.6.1–A.6.8 | 8 | HR, leidinggevenden, security, identiteitsbeheerders |
| Fysiek | A.7.1–A.7.14 | 14 | Facilitair, IT-beheer, eigenaren van apparatuur, aanbieders |
| Technologisch | A.8.1–A.8.34 | 34 | Engineering, infrastructuur, IT, security operations |
Deze beheersmaatregelen gaan over beleid, verantwoordelijkheden, functiescheiding, bedrijfsmiddelen, classificatie en behandeling van informatie, toegangsgovernance, leveranciers, incidenten, continuïteit, wettelijke verplichtingen en reviewactiviteiten.
Begin met vast te stellen waar besluiten worden genomen. Wie keurt een nieuwe clouddienst goed? Wie kent een informatieclassificatie toe? Wie beslist of een gemelde gebeurtenis een incident is? Een beleid moet die besluiten herhaalbaar maken en bevoegdheden toewijzen, in plaats van alleen steun voor beveiliging uit te spreken.
Leveranciersbeveiliging vraagt om een dienstspecifieke bewijsketen: het bedrijfsdoel van de dienst, de informatie die zij verwerkt, beoordeelde risico's, contractuele verantwoordelijkheden en doorlopende review. Een assurancerapport van een leverancier kan die beoordeling ondersteunen, maar de reikwijdte, de periode en de verantwoordelijkheden van de klant moeten aansluiten bij uw gebruik.
Ook incidentbeheer vraagt om meer dan een lijst met noodcontacten. Leg meldroutes, beoordelingscriteria, responsbevoegdheden, omgang met bewijs en leeractiviteiten vast. Registreer oefeningen of daadwerkelijke reacties, inclusief vervolgacties en eigenaren.
De acht beheersmaatregelen voor mensen gaan over screening, arbeidsvoorwaarden, bewustwording en opleiding, disciplinaire procedures, verantwoordelijkheden na wijzigingen in het dienstverband, geheimhouding, werken op afstand en het melden van gebeurtenissen.
Bouw deze in bestaande HR-processen in. Een nieuwe medewerker heeft passende verplichtingen, toegang en instructie nodig. Bij een functiewijziging moeten rechten opnieuw worden beoordeeld, niet alleen worden aangevuld. Bij vertrek zijn intrekking van toegang, het inleveren van bedrijfsmiddelen en duidelijkheid over blijvende geheimhoudingsverplichtingen nodig.
Eigenaarschap strekt zich vaak over meerdere teams uit. HR kan een vertrek in gang zetten, identiteitsbeheerders schakelen het centrale account uit, applicatie-eigenaren verwijderen lokaal beheerde toegang en een leidinggevende bevestigt de afronding. Wie het hele proces bij security legt, verbergt die afhankelijkheden.
Bruikbaar bewijs omvat goedgekeurde workflowregistraties, afgeronde opleidingen en de opvolging van achterstanden, ondertekende voorwaarden en steekproeven van wijzigingen in het dienstverband. Beperk de toegang tot gevoelig HR-bewijs; een reviewer van beheersmaatregelen heeft niet automatisch volledige personeelsdossiers nodig.
Fysieke beheersmaatregelen gaan over gebouwen, toegang, bewaking, omgevingsdreigingen, beveiligde ruimten, bureaus en schermen, apparatuur, opslagmedia, nutsvoorzieningen, bekabeling, onderhoud en afvoer.
Ook een cloud-first organisatie moet fysieke beveiliging overwegen. Een deel van de implementatie kan door een cloudleverancier worden geleverd, terwijl de toegang tot kantoren en de apparaten van medewerkers de eigen verantwoordelijkheid blijven. Leg die verdeling vast in plaats van het hele thema automatisch uit te sluiten.
Bepaal voor uw eigen locaties wie naar binnen mag, hoe toegang wordt gewijzigd, waar gevoelige apparatuur staat en hoe met bezoekers wordt omgegaan. Leg voor apparaten buiten de deur afspraken over opslag, transport, reparatie en afvoer vast die passen bij de risico's.
Bewijs kan bestaan uit registraties van toegangsautorisaties, bezoekersprocedures, inventarissen van apparatuur en afvoerregistraties. Bewijs van leveranciers moet uitleggen welke faciliteiten en diensten het dekt; het mag niet worden behandeld als bewijs voor de beheersmaatregelen rond uw kantoor of laptops.
Het technologische thema omvat endpoints, geprivilegieerde toegang, authenticatie, toegang tot broncode, capaciteit, malware, kwetsbaarheden, configuraties, gegevensverwerking, back-ups, veerkracht, logging, monitoring, netwerken, cryptografie, ontwikkeling en wijzigingsbeheer.
Begin met de systeemdekking. Een identiteitsbeleid is onvolledig als productietoegang, serviceaccounts of een apart beheerde applicatie buiten de implementatie vallen. Een loggingplatform is onvolledig als kritieke gebeurtenissen het nooit bereiken of als niemand op meldingen reageert.
Verbind bij softwareontwikkeling eisen en ontwerpbesluiten met code review, beveiligingstests, scheiding van omgevingen, omgang met testdata en goedkeuring van releases. Threat modeling kan helpen om beveiligingseisen vóór de implementatie te identificeren. De diepgang van testen moet risico's en verplichtingen volgen; ISO 27001 legt geen universeel schema voor penetratietests op.
Maak bij cryptografie onderscheid tussen data in opslag en data tijdens transport, en documenteer eigenaarschap van sleutels, toegang, herstel, rotatie en intrekking. ‘Versleuteling ingeschakeld’ laat belangrijke implementatievragen onbeantwoord.
De editie van 2013 had 114 beheersmaatregelen in 14 domeinen. De editie van 2022 heeft ze herschikt tot 93 beheersmaatregelen in vier thema's, waaronder 11 nieuwe. Een lager aantal betekent niet minder beveiligingswerk: door samenvoeging kunnen meerdere operationele verantwoordelijkheden onder één verwijzing vallen.
Behoud bij het bijwerken van een ouder register de onderliggende implementaties en het bewijs in plaats van alleen identificatoren te vervangen. Controleer of de nieuwe indeling de dekking, het eigenaarschap of de tests verandert die nodig zijn om uw status te onderbouwen.
De overgangstermijn voor geaccrediteerde certificering volgens ISO/IEC 27001:2013 liep af op 31 oktober 2025. Die certificaten zijn niet langer geldig; alleen het bijwerken van een register met beheersmaatregelen levert geen certificering volgens de editie van 2022 op.
Hieronder volgen praktische vertrekpunten voor de 11 nieuwe beheersmaatregelen, geen weergaven van hun gezaghebbende tekst.
| Beheersmaatregel | Implementatievraag | Bruikbaar bewijs |
|---|---|---|
| A.5.7 Informatie over dreigingen | Welke dreigingsinformatie is relevant en hoe verandert die besluiten? | Triageregistraties gekoppeld aan risico- of herstelacties |
| A.5.23 Informatiebeveiliging voor clouddiensten | Wie regelt aanschaf, gebruik, wijzigingen en beëindiging? | Verantwoordelijkheidsmatrix, beoordeling en overwegingen voor beëindiging |
| A.5.30 ICT-gereedheid voor bedrijfscontinuïteit | Kunnen systemen voldoen aan de herstelbehoeften van de business? | Hersteldoelstellingen, afhankelijkhedenplan en oefenresultaten |
| A.7.4 Monitoren van de fysieke beveiliging | Hoe worden pogingen tot ongeautoriseerde fysieke toegang gedetecteerd? | Bewakingsafspraken en responsregistraties |
| A.8.9 Configuratiebeheer | Wat is de goedgekeurde baseline en hoe wordt met afwijkingen omgegaan? | Geversioneerde baselines, driftreviews en uitzonderingen |
| A.8.10 Wissen van informatie | Wanneer en hoe wordt informatie uit relevante systemen verwijderd? | Bewaarregels, verwijderingsregistraties en uitzonderingsbesluiten |
| A.8.11 Maskeren van gegevens | Waar moet gevoelige informatie worden afgeschermd of vervangen? | Ontwerp van testdata, maskeringscontroles en toegangsbeperkingen |
| A.8.12 Voorkomen van datalekken | Welke paden voor openbaarmaking moeten worden beschermd? | Risicogebaseerde regels, meldingen en onderzoeksuitkomsten |
| A.8.16 Monitoren van activiteiten | Welk afwijkend gedrag leidt tot onderzoek? | Detectiedekking, afhandeling van meldingen en registraties van tuning |
| A.8.23 Webfiltering | Hoe wordt blootstelling aan kwaadaardige webinhoud beperkt? | Filterconfiguratie en beoordeelde uitzonderingen |
| A.8.28 Veilig coderen | Hoe passen ontwikkelaars relevante codeerpraktijken toe? | Codeerrichtlijnen, reviews en herstelregistraties |
Behandel deze niet als elf automatische productaankopen. Informatie over dreigingen vraagt bijvoorbeeld om analyse en actie, niet alleen om een abonnement op een feed. Het wissen van gegevens vereist inzicht in kopieën, back-ups en bewaarplichten, niet alleen een verwijderknop. Monitoring heeft een operationeel responspad nodig.
Uw Verklaring van toepasselijkheid (VvT, Engels: Statement of Applicability, SoA) moet de noodzakelijke beheersmaatregelen benoemen, toelichten waarom ze zijn opgenomen, vastleggen of ze zijn geïmplementeerd en uitsluitingen van beheersmaatregelen uit bijlage A motiveren. Deze eisen staan in de bepalingen over risicobehandeling van ISO/IEC 27001.
Alle 93 verwijzingen als reviewindex gebruiken is een praktische manier om de vergelijking controleerbaar te maken. Neem ook eventuele aanvullende noodzakelijke beheersmaatregelen op. De VvT is niet het risicoregister, het risicobehandelplan of de bewijsopslag, al moet zij waar relevant met elk daarvan verbonden zijn.
Leg per toepasselijke beheersmaatregel vast:
Houd toepasselijkheid los van de uitvoeringsstatus. ‘Van toepassing, gedeeltelijk geïmplementeerd’ is een eerlijke en nuttige registratie. ‘Niet van toepassing omdat we geen tool hebben gekocht’ is geen motivering voor toepasselijkheid.
Een uitsluiting moet de feiten over de reikwijdte beschrijven die de beheersmaatregel overbodig maken, en consistent blijven met de risicobeoordeling. ‘Wij ontwikkelen geen software’ verdient nader onderzoek als een externe partij uw klantportaal ontwikkelt. Uitbesteding verandert het implementatie- en bewijspad; het neemt het risico niet automatisch weg.
Leg bij verdeelde implementaties de verdeling vast. Een beheersmaatregel voor fysieke bescherming kan afhangen van hostingfaciliteiten van een leverancier, door het bedrijf beheerde kantoortoegang en de manier waarop medewerkers met apparaten omgaan. Eén eigenaar kan verantwoordelijk blijven voor de gecombineerde claim, terwijl verschillende teams de activiteiten uitvoeren.
Een bruikbare implementatieverklaring is specifiek genoeg om te testen: ‘Productiebeheerders krijgen benoemde, goedgekeurde toegang via de identiteitsdienst; noodtoegang wordt afzonderlijk gelogd en beoordeeld.’ ‘Toegang wordt veilig beheerd’ kan een engineer of reviewer niet sturen.
Een beleid beschrijft beoogd gedrag. Het kan ontwerp en goedkeuring aantonen, maar niet op zichzelf de werking. Bouw een bewijsketen van de eis naar het geïmplementeerde mechanisme en vervolgens naar een waargenomen resultaat.
Vergelijk bij toegangsbeheer de goedgekeurde regels met de daadwerkelijke gebruikersrechten en uitdiensttredingsregistraties. Neem waar relevant geprivilegieerde identiteiten, niet-menselijke accounts en applicaties buiten het centrale identiteitsbeheer mee. Leg de populatie, de steekproef en de uitzonderingen vast in plaats van één handige schermafdruk te presenteren.
Bekijk bij back-ups de configuratie en een herstelresultaat. Een geslaagde back-uptaak bewijst minder dan een geslaagd herstel van bruikbare informatie. Controleer rechten, afhankelijkheden en hersteldoelstellingen; een herstelde database zonder de bijbehorende encryptiesleutels herstelt de dienst mogelijk niet.
Verbind bij leveranciersbeveiliging de beoordeling met de specifieke dienst en de contractuele verantwoordelijkheden. Ga na of het bewijs de dienst dekt die u gebruikt en of de geïdentificeerde verantwoordelijkheden aan klantzijde zijn geïmplementeerd.
Een praktische testregistratie bevat het verwachte resultaat, de methode, de reikwijdte, de datum van het bewijs, de reviewer, het resultaat en het vervolgbesluit. Maak onderscheid tussen:
Bewijs kan bestaan uit configuraties, exports, tickets, contracten, interviews en fysieke waarnemingen. Kies bewijs dat de daadwerkelijke claim ondersteunt. Een configuratie-export kan de huidige instellingen tonen; historische tickets kunnen laten zien of uitzonderingen in de loop van de tijd zijn afgehandeld.
Bewaar de herkomst: bronsysteem, verzameldatum, gedekte periode en eventuele filtering. Bescherm bewijs met geheimen of persoonsgegevens met toegangsbeperkingen en passende weglakking. Het verzamelen van bewijs mag geen nieuwe, ongecontroleerde opslagplaats voor gevoelige gegevens opleveren.
Neem ter illustratie een SaaS-bedrijf met 45 medewerkers, één kantoor, cloudhosting, centraal beheerde identiteiten en twee applicaties met lokale accounts. Dit zijn aannames voor het voorbeeld, geen resultaten van klanten van Secani.
Het risico is voortdurende toegang tot informatie van klanten of het bedrijf na vertrek. Relevante beheersmaatregelen zijn onder meer verantwoordelijkheden bij wijzigingen in het dienstverband, identiteitsbeheer, toegangsrechten en het inleveren van bedrijfsmiddelen. Technische authenticatie en toegangsbeperkingen ondersteunen de implementatie eveneens.
Het bedrijf registreert de beheersmaatregel als van toepassing. HR is eigenaar van de vertrektrigger; IT van de acties voor identiteiten en apparaten; elke applicatie-eigenaar van het verwijderen van lokale accounts. De leidinggevende van de medewerker bevestigt het vereiste vertrekmoment. De security-eigenaar beoordeelt het proces en onopgeloste uitzonderingen.
De implementatie omvat een geautoriseerd vertrekticket, geplande uitschakeling van het centrale account, intrekking van sessies waar dat wordt ondersteund, verwijdering van lokale accounts, het inleveren van bedrijfsmiddelen en controles op inloggegevens die de persoon beheerde. Gedeelde geheimen worden waar nodig gewijzigd; persoonlijke accounts worden niet zomaar aan een opvolger overgedragen.
Het bewijspakket verbindt de goedgekeurde procedure, het vertrekticket, registraties van accountacties, bevestigingen voor lokale applicaties en de registratie van apparatuur. Elk item ondersteunt een afgebakend deel van de claim.
Tijdens een illustratieve review bekijkt het team vier vertrekken. Centrale accounts zijn volgens planning uitgeschakeld, maar in één lokale applicatie bleef de toegang twee dagen bestaan. De beheersmaatregel wordt niet volledig doeltreffend verklaard op basis van alleen het bewijs uit het centrale identiteitsbeheer.
De applicatie-eigenaar verwijdert het account, beoordeelt of er toegang heeft plaatsgevonden en legt de uitkomst vast. Het team voegt de applicatie toe aan de vertrekchecklist en wijst een afstemmingsstap toe. De behandelactie krijgt een eigenaar en een deadline; een latere test controleert of de herziene werkwijze werkt.
Dit voorbeeld laat zien waarom bewijs de afhankelijkheden moet volgen. Vier systemen die ‘afgerond’ melden, tonen geen afronding aan als een vijfde systeem nooit is meegenomen.
Beheersmaatregelen veranderen wanneer systemen, leveranciers, mensen en bedrijfseisen veranderen. Stel naast geplande reviews triggers in voor belangrijke releases, nieuwe diensten, wijzigingen in kantoren, incidenten en herziene verplichtingen.
Kies een ritme dat past bij de veranderlijkheid en het risico. Uitzonderingen op geprivilegieerde toegang kunnen een snelle review vergen, terwijl een stabiel beleid een langere cyclus kan volgen, aangevuld met wijzigingstriggers. Dit zijn managementkeuzes, geen universele frequenties uit bijlage A.
Volg een klein aantal nuttige indicatoren: achterstallig herstel, niet-gedekte systemen, onopgeloste bewijsuitzonderingen en mislukte tests van beheersmaatregelen. Houd die gescheiden van het aantal documenten. Een grote bewijsbibliotheek kan nog altijd een kritieke productieomgeving ongetest laten.
De interne audit levert een afzonderlijke evaluatie van het ISMS; routinematige reviews door eigenaren van beheersmaatregelen vervangen die niet. De directiebeoordeling vraagt evenmin alleen om een ingevulde spreadsheet met beheersmaatregelen, maar om besluiten van de directie over prestaties, wijzigingen, middelen en verbetering. Certificering wordt uitgevoerd door een onafhankelijke certificatie-instelling, niet door ISO of een softwareleverancier.
Veelgemaakte fouten zijn alles bij security beleggen, uitsluitingen van een andere organisatie kopiëren, vertrouwen op certificaten van leveranciers zonder de reikwijdte te controleren, en bevindingen afsluiten zodra een beleid wijzigt in plaats van wanneer het herziene proces is getest.
Kies een representatieve dienst en breng de systemen, aanbieders, informatie en operationele eigenaren in kaart. Selecteer een kleine set samenhangende beheersmaatregelen, zoals toegang, wijzigingsbeheer, logging en herstel, en maak elke implementatie controleerbaar voordat u het register uitbreidt.
Secani ondersteunt deze werkwijze door systemen en afhankelijkheden te modelleren, bewijs te verbinden met eisen, beheersmaatregelen en besluiten, en lacunes als taken te volgen. Wijs een eigenaar en een reviewer toe, voeg bestaande registraties toe en bewaar reviewopmerkingen en goedkeuringen. Behandel door AI ondersteunde koppelingen of samenvattingen als concepten: valideer de bronnen en houd menselijke goedkeuring expliciet. Gestructureerde auditgereedheid legt het onderliggende bewijsmodel uit.
Het eerste resultaat moet een samenhangende keten zijn van risico naar beheersmaatregel, implementatie, bewijs, testresultaat en vervolgbesluit. Die keten kan daarna over de rest van de reikwijdte worden herhaald, zonder voor elke verwijzing uit bijlage A een nieuw proces te bedenken.
Ja. Een vertrekticket kan meerdere samenhangende beheersmaatregelen ondersteunen. Leg per beheersmaatregel uit welke claim het ondersteunt; gedeeld bewijs maakt de beheersmaatregelen niet identiek.
Nee. Organiseer beleid en procedures rond begrijpelijke operationele processen. Eén document kan meerdere beheersmaatregelen behandelen, zolang verantwoordelijkheden en implementatie duidelijk blijven.
Gebruik de gelicentieerde norm ISO/IEC 27001 voor de formulering van bijlage A en ISO/IEC 27002 voor implementatierichtlijnen. Operationele samenvattingen zijn nuttige navigatiehulpmiddelen, geen vervanging voor de normen.
Secani verbindt scopes, bewijs, taken en AI-agents in één gedeelde werkruimte.
Een praktische route van scope en risicobeoordeling naar certificering, met realistische mijlpalen en bewijs dat ook na de audit bruikbaar blijft.
ISO 27001-checklists bieden houvast, maar vervangen geen kennis van de norm. Een gids over hun grenzen en beschikbare hulpmiddelen.
Verbind kritieke diensten met hersteldoelen, afhankelijkheden, oefeningen en corrigerende maatregelen, zodat continuïteitsplannen het werkelijke vermogen weerspiegelen.