Hoeveel maatregelen heeft ISO 27001?

De versie uit 2022 heeft 93 maatregelen in Annex A, verdeeld over vier thema's. De versie uit 2013 had er 114 in 14 domeinen. Het lagere aantal komt vooral door samenvoegen, niet door schrappen.

Moet ik alle 93 maatregelen invoeren?

Nee. Je beoordeelt ze allemaal, maar je voert in wat je risico's vragen. Per maatregel leg je in de Verklaring van Toepasselijkheid vast of hij van toepassing is en waarom.

Welke maatregelen zijn nieuw in ISO 27001:2022?

Elf, onder meer threat intelligence (5.7), informatiebeveiliging bij clouddiensten (5.23), configuratiebeheer (8.9), monitoring (8.16) en secure coding (8.28).

Wat is het verschil tussen Annex A en ISO 27002?

Annex A van ISO 27001 noemt de maatregelen kort. ISO/IEC 27002:2022 gebruikt dezelfde nummering en geeft per maatregel uitleg en implementatierichtlijnen. Certificeren doe je tegen ISO 27001, niet tegen ISO 27002.

Geldt de oude lijst met 114 maatregelen nog?

Nee. Certificaten op basis van ISO 27001:2013 zijn uiterlijk op 31 oktober 2025 verlopen of ingetrokken. Sindsdien wordt tegen de versie uit 2022 gecertificeerd.

ISO 27001-maatregelen: de 93 maatregelen van Annex A, gegroepeerd zoals een IT-bedrijf ze ervaart

ISO 27001:2022 bevat in Annex A 93 maatregelen, verdeeld over vier thema's, 37 organisatorische, 8 mensgerichte, 14 fysieke en 34 technologische. Elf daarvan zijn nieuw ten opzichte van de versie uit 2013. Annex A is een referentielijst, geen verplichte checklist: welke maatregelen je toepast, volgt uit je risicobeoordeling en staat in de Verklaring van Toepasselijkheid.

ISO 27001:2022 bevat in Annex A 93 maatregelen, verdeeld over vier thema's. Dat is een referentielijst, geen checklist die je van boven naar beneden afwerkt. Je loopt elke maatregel langs, je kiest wat je risico's vragen, en je legt die keuze vast in de Verklaring van Toepasselijkheid. Een auditor kijkt vooral of die keuzes kloppen met wat je bedrijf werkelijk doet.

Wat er in 2022 veranderde

De versie uit 2013 had 114 maatregelen in 14 domeinen. De versie uit 2022 heeft er 93 in vier thema's. Het lagere aantal komt vooral doordat maatregelen zijn samengevoegd; daarnaast zijn er 11 nieuwe bijgekomen. Certificaten op basis van de oude versie zijn uiterlijk op 31 oktober 2025 verlopen of ingetrokken.

Annex A noemt elke maatregel in één regel. De uitleg en implementatierichtlijnen staan in ISO/IEC 27002:2022, dat dezelfde nummering volgt. Wie een maatregel wil begrijpen, leest daar verder.

De vier thema's

Thema	Nummers	Aantal	Waar het over gaat
Organisatorisch	5.1 t/m 5.37	37	Beleid, rollen, assets, toegang, leveranciers, incidenten, continuïteit, wetgeving.
Mensgericht	6.1 t/m 6.8	8	Screening, arbeidsvoorwaarden, bewustzijn, thuiswerken, melden van gebeurtenissen.
Fysiek	7.1 t/m 7.14	14	Kantoor en ruimtes, apparatuur, opslagmedia, afvoer.
Technologisch	8.1 t/m 8.34	34	Endpoints, authenticatie, logging, netwerk, back-ups, cryptografie, ontwikkeling.

De indeling is praktisch voor een auditor, maar niet hoe een softwarebedrijf over zijn werk praat. Daarom hieronder eerst de nieuwe maatregelen en daarna een indeling naar hoe je ze in de praktijk tegenkomt.

De 11 nieuwe maatregelen

Nr.	Onderwerp	Wat het bij een softwarebedrijf betekent
5.7	Threat intelligence	Bijhouden welke dreigingen relevant zijn, bijvoorbeeld via NCSC-adviezen en meldingen over je eigen stack.
5.23	Clouddiensten	Afspraken over hoe je AWS, Azure of een Nederlandse hoster kiest, gebruikt en weer verlaat.
5.30	ICT-gereedheid voor continuïteit	Aantonen dat je platform binnen de afgesproken tijd terug kan komen, niet alleen dat er een plan ligt.
7.4	Fysieke beveiligingsmonitoring	Toezicht op ruimtes met gevoelige apparatuur; bij volledige cloudhosting vaak via de leverancier afgedekt.
8.9	Configuratiebeheer	Vastgelegde en bewaakte configuraties van servers, containers en cloudaccounts.
8.10	Informatie verwijderen	Klantdata aantoonbaar wissen als die niet meer nodig is, ook uit back-ups en logs waar dat kan.
8.11	Datamaskering	Persoonsgegevens afschermen, bijvoorbeeld in test- en supportomgevingen.
8.12	Voorkomen van datalekken	Maatregelen tegen onbedoeld weglekken van data, van e-mail tot publieke buckets.
8.16	Monitoring	Afwijkend gedrag op netwerk en systemen signaleren en opvolgen.
8.23	Webfiltering	Beperken welke websites vanaf bedrijfsapparaten bereikbaar zijn.
8.28	Secure coding	Veilig programmeren als vaste werkwijze, met afspraken, reviews en tooling.

Zoals een softwarebedrijf ze ervaart

De nummers hieronder zijn eigen groeperingen, geen indeling uit de norm. Sommige maatregelen horen bij meer dan één groep.

Ontwikkeling

Voor een SaaS- of zorgsoftwareleverancier is dit het zwaartepunt. Het gaat om beveiliging in projecten (5.8), toegang tot broncode (8.4), een veilige ontwikkelcyclus (8.25), beveiligingseisen aan applicaties (8.26), veilige architectuurprincipes (8.27), secure coding (8.28), testen (8.29), uitbesteed ontwikkelwerk (8.30), gescheiden omgevingen (8.31), wijzigingsbeheer (8.32) en testdata (8.33). Een auditor vraagt hier naar pull requests, reviewregels en hoe productiedata uit test blijft.

Hosting en cloud

Clouddiensten (5.23), capaciteit (8.6), malware (8.7), kwetsbaarhedenbeheer (8.8), configuratiebeheer (8.9), back-ups (8.13), redundantie (8.14), logging (8.15), monitoring (8.16), kloksynchronisatie (8.17), netwerkbeveiliging (8.20 t/m 8.22) en cryptografie (8.24). Een hostingpartij of SaaS-bedrijf toont hier het meeste bewijs uit de eigen systemen.

Mensen en toegang

Het hele mensthema (6.1 t/m 6.8), plus toegangsbeleid (5.15), identiteiten (5.16), wachtwoorden en andere authenticatiegegevens (5.17), toegangsrechten (5.18), laptops en telefoons (8.1), beheerrechten (8.2) en veilige authenticatie (8.5). Bij een team van 10 tot 100 mensen draait het om in- en uitdienst: wie krijgt wat, wie trekt het weer in, en waar staat dat.

Leveranciers

Beveiliging in leveranciersrelaties (5.19), afspraken in contracten (5.20), de ICT-keten (5.21), toezicht op leveranciers (5.22) en clouddiensten (5.23). Voor een softwarebedrijf zijn dat vooral de hoster, de e-maildienst, de ticketingtool en externe ontwikkelaars. Je eigen klanten stellen dezelfde vragen aan jou.

Incidenten en continuïteit

Voorbereiding op incidenten (5.24), beoordelen van gebeurtenissen (5.25), reageren (5.26), leren (5.27), bewijs verzamelen (5.28), beveiliging tijdens verstoring (5.29), ICT-gereedheid (5.30) en melden door medewerkers (6.8). Threat intelligence (5.7) voedt dit blok.

Wat vaak klein blijft

Bij een bedrijf zonder eigen serverruimte zijn veel fysieke maatregelen beperkt tot het kantoor en de apparatuur: toegang tot het pand (7.1 t/m 7.3), clear desk en clear screen (7.7), apparatuur buiten kantoor (7.9), opslagmedia (7.10) en veilige afvoer (7.14). De rest leg je vaak neer bij de hoster, met een verwijzing naar diens certificaat. Dat is een onderbouwde keuze, geen uitzondering.

De overige organisatorische maatregelen, zoals inventarisatie (5.9), classificatie (5.12), wetgeving en contracten (5.31), privacy (5.34) en onafhankelijke beoordeling (5.35), raken het hele bedrijf en passen in geen enkel vakje.

Van lijst naar werkwijze

Een lijst van 93 nummers helpt een auditor, maar niet de ontwikkelaar die wil weten wat er van hem verwacht wordt. Het werkt beter om maatregelen te beschrijven in de taal van je eigen processen, en de nummers erachter te hangen. Trustbird werkt op die manier: één set maatregelen in bedrijfstaal, gemapt op de nummers van ISO 27001 en, waar van toepassing, NEN 7510. Welke vorm je ook kiest, de keuzes en de onderbouwing blijven van de organisatie zelf.