Hoe schrijf je een informatiebeveiligingsbeleid (ISO 27001 clausule 5.2)

Het informatiebeveiligingsbeleid dat ISO 27001 in clausule 5.2 eist, is één overkoepelend document dat door de directie wordt vastgesteld. Het zegt waaraan de organisatie zich committeert en waarom — en het is bewust kort. Eén tot twee pagina's is normaal. Tien is een teken dat er iets in geslopen is dat in deelbeleid hoort.

Dit is het document dat het vaakst wordt verward met een complete beleidsbibliotheek. Als je eigenlijk de hele set beleidsdocumenten nodig hebt — acceptabel gebruik, toegangsbeheer, incidentrespons en de rest — begin dan bij de minimale beleidsset gekoppeld aan de Trust Services Criteria of bij onze negen interne bedrijfsbeleidsdocumenten met sjablonen. Dit artikel gaat over het ene beleid dat boven alle andere staat.

Wat clausule 5.2 eist

De norm is hier ongewoon concreet. De directie moet een informatiebeveiligingsbeleid vaststellen dat:

• Past bij het doel van de organisatie. Een betaalbedrijf en een designbureau horen niet hetzelfde beleid te hebben. Generieke tekst is de snelste manier om te laten zien dat niemand uit de leiding zich ermee bemoeid heeft.
• Doelstellingen voor informatiebeveiliging bevat, of het kader biedt om die vast te stellen. Of je noemt de doelstellingen, of je legt vast hoe en door wie ze worden bepaald en beoordeeld. De meeste organisaties kiezen voor het kader en houden de doelstellingen zelf bij in een apart document dat vaker wordt bijgewerkt.
• Een verbintenis bevat om te voldoen aan de van toepassing zijnde eisen rond informatiebeveiliging — wettelijk, regelgevend en contractueel.
• Een verbintenis tot continue verbetering bevat van het managementsysteem voor informatiebeveiliging.

En het beleid zelf moet:

• beschikbaar zijn als gedocumenteerde informatie
• binnen de organisatie worden gecommuniceerd
• beschikbaar zijn voor belanghebbenden, voor zover van toepassing

Die laatste drie regels zijn waar audits echt misgaan. Het beleid schrijven is de makkelijke helft; aantonen dat het mensen bereikt heeft, is de helft die teams vergeten. Daarover verderop meer.

Een opzet, sectie voor sectie

Een structuur die aan clausule 5.2 voldoet zonder uit te dijen:

1. Doel en reikwijdte — één alinea over waarom het beleid bestaat en waarop het van toepassing is, in lijn met je scope statement van het ISMS. Herhaal de scope niet; verwijs ernaar.
2. Verklaring van commitment — wat de organisatie belooft te beschermen, in gewone taal: de vertrouwelijkheid, integriteit en beschikbaarheid van klant- en bedrijfsinformatie.
3. Doelstellingen of het kader om ze vast te stellen — of de doelstellingen zelf, of één zin die uitlegt dat doelstellingen jaarlijks in de directiebeoordeling worden vastgesteld en als gedocumenteerde informatie worden bijgehouden.
4. Verbintenis aan de van toepassing zijnde eisen — wettelijke, regelgevende en contractuele verplichtingen die relevant zijn voor informatiebeveiliging.
5. Verbintenis tot continue verbetering — van het ISMS, in de praktijk verwijzend naar clausule 10, ook als je het nummer niet noemt.
6. Rollen en verantwoordelijkheden — wie eigenaar is van het ISMS, wie beleid goedkeurt, wat er van elke medewerker wordt verwacht. Noem rollen in plaats van namen, zodat het document niet bij elke aanname verandert.
7. Ondersteunend beleid — een lijst van het deelbeleid dat onder dit document hangt, zodat een lezer weet waar de details staan.
8. Gevolgen van niet-naleving — een korte, eerlijke passage die aansluit op je arbeidsvoorwaarden.
9. Goedkeuring en beoordeling — wie het heeft goedgekeurd, wanneer, en met welke frequentie het wordt beoordeeld.

Wat er niet in hoort

De duidelijkste manier om dit document kort te houden, is streng zijn over wat elders thuishoort. Operationele details horen in deelbeleid en procedures:

• Wachtwoordlengte en MFA-details → toegangsbeleid
• Wat medewerkers op een laptop mogen installeren → beleid voor acceptabel gebruik
• Severityniveaus en escalatiepaden → incidentresponsplan
• Back-upschema's en bewaartermijnen → back-up- en continuïteitsdocumentatie
• Hoe leveranciers worden beoordeeld → leveranciersbeveiligingsbeleid

De reden is niet netheid. Het is veranderingssnelheid. Het overkoepelende beleid hoort stabiel genoeg te zijn dat de directie het één keer per jaar opnieuw kan goedkeuren zonder een diff te lezen. Alles waarvan je verwacht dat het per kwartaal verandert, moet ergens leven waar dat per kwartaal kan, zonder directiebeoordelingscyclus. Voor het draaien van die levenscyclus over de hele set, zie intern beleidsbeheer.

De test die de moeite waard is

Geef het beleid aan een founder of senior manager die het niet geschreven heeft, wacht een week en vraag om samen te vatten waaraan het bedrijf zich committeert. Lukt dat — accuraat, zonder het document erbij — dan past het bij het doel van de organisatie op de manier die clausule 5.2 bedoelt. Volgt er een schouderophalen, dan heb je een sjabloon met je logo erop, en een auditor die diezelfde persoon interviewt komt tot dezelfde conclusie.

Dit is geen hypothetische audittechniek. Auditors interviewen echt medewerkers, en "de directie toont leiderschap en betrokkenheid" wordt deels beoordeeld op de vraag of de mensen aan de top over hun eigen beleid kunnen praten. Zie clausule 5 over leiderschap voor wat er verder onder die noemer valt.

Communiceren — en aantonen dat je het deed

"Binnen de organisatie gecommuniceerd" is een eis, en een auditor vraagt je om bewijs. Het document op een gedeelde schijf zetten is geen communicatie; dat is beschikbaarheid. Het zijn niet voor niets twee losse eisen in de clausule.

Wat werkt als bewijs:

• Bevestigingsregistraties — per medewerker een vastlegging dat die de huidige versie heeft gelezen, met datum en de bevestigde versie.
• Dekking in de onboarding — het beleid is onderdeel van het inwerktraject, met een registratie voor elke nieuwe medewerker.
• Opnieuw bevestigen bij inhoudelijke wijziging — verandert het beleid wezenlijk, dan bevestigen mensen de nieuwe versie in plaats van dat de oude stilletjes "geaccepteerd" blijft.
• Beschikbaarheid voor belanghebbenden — waar passend een publieke samenvatting of een versie die klanten onder NDA krijgen. Een trust center is een gebruikelijke manier om hieraan te voldoen zonder interne details te publiceren.

Versiebeheer telt hier zwaarder dan teams verwachten. Zijn bevestigingen niet aan een versie gekoppeld, dan kun je niet laten zien wie wat heeft geaccepteerd en houdt de registratie op bewijs te zijn.

Goedkeuring en beoordelingsfrequentie

Het beleid wordt goedgekeurd door de directie — in een startup een founder of de CTO, wie er ook echt zeggenschap heeft over het ISMS. Jaarlijkse beoordeling is de gebruikelijke frequentie, meestal meegenomen in de directiebeoordeling onder clausule 9.3, plus een tussentijdse beoordeling als er iets wezenlijks verandert: een nieuwe wettelijke verplichting, een ernstig incident, een scopewijziging of een overname.

Leg de goedkeuring vast. Beleid waarvan de goedkeuringshistorie bestaat uit "laatst gewijzigd door"-metadata in een tekstverwerker is mager bewijs dat de directie iets heeft vastgesteld.

De kern

Schrijf één of twee pagina's die klinken als jouw bedrijf, dek de vier dingen af die clausule 5.2 noemt, en verwijs naar het deelbeleid waar de details staan. Steek de rest van je energie in het deel waarop audits echt stuklopen: het laten bevestigen, versioneren en beoordelen op een frequentie die je kunt aantonen.

Verder: clausule 5 in het geheel, de minimale beleidsset voor wat er onder dit document hangt, of de complete doorloop van clausules 4–10.