ISO/IEC 27090 maakt AI-beveiliging een eigen dreigingslaag naast ISO/IEC 42001 en ISO 27001

ISO en IEC hebben na vier jaar ISO/IEC 27090 afgerond: richtlijnen voor de beveiliging van AI-systemen tegen aanvallen zoals promptinjectie, data- en modelvergiftiging, informatie-extractie en modeldiefstal. De standaard vervangt ISO/IEC 27001 en 27002 niet, maar vult die aan met een AI-gerichte dreigings- en controlelaag die u verankert in uw bestaande managementsysteem voor informatiebeveiliging.

De publicatie van ISO/IEC 27090 werd gerapporteerd in berichtgeving over de AI-beveiligingsstandaard van ISO en IEC. Onze duiding: er is nu een internationaal document dat de beveiliging van AI-systemen systematisch benadert vanuit hun specifieke aanvalsvlakken, naast de bestaande klassieke cybersecuritybenadering.

Wat regelt ISO/IEC 27090 precies en wat voegt het toe aan ISO 27001 en 27002?

ISO/IEC 27090 geeft richtlijnen om AI-specifieke beveiligingsdreigingen te identificeren en te behandelen, met bijbehorende tegenmaatregelen. Het is opgezet als aanvulling op ISO/IEC 27001, de standaard die volgens ISO de eisen stelt voor het opzetten, uitvoeren, onderhouden en verbeteren van een managementsysteem voor informatiebeveiliging, en op ISO/IEC 27002, dat de algemene beveiligingsmaatregelen beschrijft.

De verhouding is naar onze inschatting eenvoudig samen te vatten: ISO/IEC 27001 levert het bestuurlijke fundament met risico-eigenaarschap en continue verbetering, ISO/IEC 27002 levert de generieke maatregelen, en ISO/IEC 27090 voegt daar een bril voor AI-beveiliging aan toe. Het verschilt daarmee van ISO/IEC 42001, dat het bredere AI-managementsysteem beschrijft, en van het NIST AI Risk Management Framework (AI RMF 1.0), dat AI-risico breed kadert; ISO/IEC 27090 richt zich specifiek op beveiligingsdreigingen. De officiële omschrijving van ISO/IEC 27001 door ISO maakt dat fundament concreet.

• ISO/IEC 27001: eisen aan het managementsysteem, risico-eigenaarschap en verbetering.
• ISO/IEC 27002: algemene richtlijnen voor informatiebeveiligingscontroles.
• ISO/IEC 42001: het bredere AI-managementsysteem waarin AI-governance wordt belegd.
• NIST AI RMF 1.0: een breed kader voor het kaderen van AI-risico's.
• ISO/IEC 27090: AI-specifieke beveiligingsdreigingen en manieren om die te detecteren en te beperken.

Belangrijk: de publicatie van een standaard certificeert geen product en bewijst niet dat een AI-systeem veilig is. En zolang een afzonderlijke regel het niet voorschrijft, is ISO/IEC 27090 geen wettelijke verplichting.

Welke AI-specifieke dreigingen beschrijft de standaard en waarom volstaan generieke controles niet?

De kern is dat AI-systemen specifieke aanvalsvlakken hebben waarvoor een gewone firewall of toegangscontrole op zichzelf niet volstaat. Het Europese agentschap voor cyberbeveiliging ENISA benoemt in zijn opiniestuk over de rol van het agentschap bij cyberbeveiliging voor AI onder meer modelvergiftiging, adversariële aanvallen, promptinjectie, informatie-extractie, modellekkage, membership inference en modeldiefstal.

Die dreigingen vragen om specifieke taal. Promptinjectie — waarbij verborgen instructies in invoer of externe inhoud het gedrag van een model sturen — en datavergiftiging raken de werking van het systeem zelf, niet alleen de infrastructuur eromheen. ENISA stelt in zijn analyse van cyberbeveiliging voor AI dat passende maatregelen pogingen moeten adresseren om het gebruik, gedrag of de prestaties van een AI-systeem te veranderen. Naar onze analyse is dat precies het gat dat een AI-specifieke beveiligingslaag vult.

Onze toevoeging, als interpretatie: wie uitsluitend met klassieke controles werkt, beschrijft deze dreigingen te globaal om ze te kunnen toetsen. Externe inhoud behandelen als onvertrouwde data is daarbij een praktisch uitgangspunt — zie onze bespreking van verborgen instructies in externe documenten en retrieval.

Wat betekent de publicatie van ISO/IEC 27090 voor bestuurders, juristen en CISO's?

Onze analyse: omdat ISO/IEC 27090 AI-dreigingen expliciet benoemt als aparte categorie, verschuift de verantwoordelijkheid van "we passen onze cybersecurity toe op AI" naar "we tonen aan dat we deze specifieke dreigingen beheersen"; daarom adviseren wij dat de CISO per AI-systeem een dreigingsbeoordeling opneemt in het risicoregister van het bestaande ISO/IEC 27001-systeem in plaats van AI onder algemene IT te scharen. Omdat de standaard een aanvulling is en geen vervanging, ontstaat het risico dat teams hem als los project draaien zonder bestuurlijke verankering; daarom adviseren wij dat de bestuurder bij de eerstvolgende managementreview een risico-eigenaar aanwijst voor elk productief AI-systeem. Omdat publicatie van een standaard geen veiligheid of certificering bewijst, blijft de claim "we voldoen aan ISO/IEC 27090" leeg zonder bewijs; daarom adviseren wij dat de jurist in leverancierscontracten vastlegt dat getoetste maatregelen en logbewijs opvraagbaar zijn, niet alleen een verwijzing naar de norm. En omdat de standaard geen wettelijke plicht is tenzij een andere regel dat vereist, adviseren wij dat de compliancefunctie onderscheidt welke verplichting werkelijk uit wetgeving volgt en welke uit eigen beleid, zodat toezeggingen aan toezichthouders kloppen.

Als samenvatting van die analyse, als onze aanbevelingen in stappen:

1. Wijs per productief AI-systeem een risico-eigenaar aan binnen het ISO/IEC 27001-register.
2. Neem de AI-dreigingsbeoordeling op in de reguliere managementreview.
3. Leg in contracten toetsbare maatregelen en logbewijs vast, niet alleen normverwijzingen.
4. Scheid wettelijke verplichtingen van eigen beleidskeuzes.

Hoe bouwt u een AI-systeeminventaris met dreiging-naar-controle-koppeling?

Begin niet bij een modellijst alleen, maar bij een inventaris van het hele AI-systeem. Noteer per onderdeel welke dreigingen gelden, wie eigenaar is en welke maatregelen u preventief en detectief treft. Toets die maatregelen tegen de werkelijke productie-configuratie en herzie de beoordeling na elke wijziging aan model, data, prompt, tool of infrastructuur.

• Modelversies en herkomst, plus trainings-, fine-tuning- en retrievaldata.
• Prompts en externe inhoud die het model binnenkomt.
• API's, plug-ins en tools, met identiteiten en rechten.
• Deploy-infrastructuur, logging en monitoring.
• Menselijke goedkeurings- en noodstoppunten.

Koppel aan elk onderdeel concrete dreigingen — promptinjectie, data- of modelvergiftiging, informatie-extractie, modeldiefstal, privacy-aanvallen en ongeautoriseerde toolacties — en bewaar bewijs van de uitgevoerde toetsen. Deze werkwijze sluit aan bij bredere AI-securitypraktijk en dreigingsbeheersing en bij het inrichten van AI-governance met risico-eigenaarschap. Voor incidenten die ontstaan wanneer een model buiten zijn taakgrenzen handelt, adviseren wij een apart responsplan naast het cyber-draaiboek en AI-incidentrespons.

Bronnen: Het artikel steunt op berichtgeving over de voltooiing van ISO/IEC 27090, op de officiële omschrijving van ISO/IEC 27001 door ISO en op het opiniestuk van ENISA over cyberbeveiliging voor AI.