ISO 27090 uitgelegd voor AI-securityteams

ISO/IEC 27090:2026 is een internationale norm met richtlijnen over beveiligingsdreigingen en compromitteringen die systemen voor kunstmatige intelligentie raken. De norm is gepubliceerd op 14 oktober 2026 en beschrijft hoe organisaties die dreigingen gedurende de hele AI-levenscyclus kunnen begrijpen, detecteren en beperken. De formele titel luidt Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Publicatiegegevens van ISO

Voor een securityteam is de praktische vraag eenvoudig: wat zou een aanvaller kunnen wijzigen of stelen, of een AI-systeem kunnen laten doen, en wat zou de schade die daaruit volgt beperken?

Deze gids legt uit wat de reikwijdte van de ISO 27090-norm is, wat de belangrijkste AI-beveiligingsdreigingen zijn, hoe de norm zich verhoudt tot ISO 27001 en ISO 42001, en hoe u de richtlijnen op een praktische manier omzet in beveiligingswerk met eigenaren, waarborgen en bewijs. Het onderliggende onderzoek is gecontroleerd op 18 oktober 2026.

Wat de ISO 27090-norm behandelt

ISO 27090 richt zich op de bescherming van AI-systemen. Het onderwerp gaat verder dan generatieve AI, grote taalmodellen en chatbots en omvat AI-systemen in bredere zin. Toelichting van ISO op ISO 27090

De gepubliceerde norm verbindt gevestigde praktijken voor informatiebeveiliging met AI-specifieke dreigingen. De inhoud behandelt governance, beveiliging van de toeleveringsketen, threat modelling en red teaming, gevolgd door soorten compromittering, waaronder poisoning, evasion, blootstelling van informatie en prompt injection. Ook wordt bekeken hoe maatregelen elkaar beïnvloeden en hoe ze in de loop van de tijd effectief blijven. Gepubliceerd fragment van ISO/IEC 27090

De reikwijdte omvat organisaties van elke omvang die AI ontwikkelen of gebruiken, waaronder bedrijven, overheidsinstanties en non-profitorganisaties. Wie een AI-dienst van een derde partij afneemt, valt dus niet buiten de beoogde doelgroep. Publicatiegegevens van IEC

Een nuttig startpunt is een gezamenlijke review met security, engineering, data, inkoop en de business-eigenaar. Ieder van hen moet kunnen uitleggen welk deel van het systeem hij of zij beheert en voor welke beslissingen hij of zij van anderen afhankelijk is.

Waarom AI-systemen aanvullende beveiligingsanalyse nodig hebben

Een AI-applicatie verbindt verschillende onderdelen die elk afzonderlijk onderzocht moeten worden: software, data, modelbestanden of -diensten, instructies, gebruikers en vervolgacties.

Neem een documentassistent die is gekoppeld aan een interne kennisbank. Een conventionele review kan authenticatie, versleuteling en kwetsbaarheden in software onderzoeken. Een AI-beveiligingsreview moet daarnaast vragen wat er gebeurt als een opgehaald document de instructies van de assistent probeert te wijzigen, of gebruikers materiaal buiten hun rechten kunnen ophalen en welke acties gegenereerde output kan activeren.

Die vragen wegen zwaarder wanneer een assistent records kan bijwerken of externe tools kan aanroepen. Een fout antwoord en een niet-geautoriseerde actie hebben verschillende gevolgen en vragen om verschillende waarborgen.

Breng voor uw eerste review drie vragen in kaart:

• Wat kan het systeem beïnvloeden? Neem trainingsdata, opgehaalde content, prompts, leveranciers en modelupdates mee.
• Wat kan het systeem verlaten? Neem antwoorden, logs, exports en modelassets mee.
• Wat kan het systeem wijzigen? Neem bestanden, tickets, accounts, transacties en andere gekoppelde diensten mee.

Dit is een praktische methode om de reikwijdte van de onderstaande voorbeelden af te bakenen, geen weergave van de clausules van de norm.

AI-beveiligingsdreigingen die u moet begrijpen

De volgende uitleg gebruikt de terminologie van NIST voor adversarial machine learning en de richtlijnen van OWASP voor LLM-applicaties. De scenario's zijn illustratief. NIST-taxonomie voor adversarial machine learning OWASP-richtlijnen over prompt injection OWASP-richtlijnen over outputverwerking

Houd de onderscheidingen helder tijdens een risicobeoordeling. Een kwaadaardig document dat een retrieval-augmented generation-applicatie (RAG) ophaalt, is niet automatisch poisoning van trainingsdata: ophalen werkt op zichzelf de modelgewichten niet bij. Het kan de applicatie wel blootstellen aan indirecte prompt injection.

Voor LLM-beveiliging zijn sterkere prompts alleen een onvolledige beheersstrategie. OWASP beveelt waarborgen aan zoals beperkte rechten en goedkeuring voor gevoelige acties, terwijl het NCSC benadrukt dat prompt injection als een doorlopend risico moet worden beheerst via het ontwerp en de exploitatie van het systeem. OWASP-richtlijnen over prompt injection NCSC-richtlijnen over het risico van prompt injection

ISO 27090 vergeleken met ISO 27001 en ISO 42001

Deze normen ondersteunen verschillende onderdelen van het beveiligings- en AI-governancewerk van een organisatie.

De onderscheidingen volgen de beschrijvingen van de uitgevers van ISO 27001, ISO 27002 en ISO 42001.

Voor een team dat al een ISMS heeft, is het een praktische aanpak om bestaande vastleggingen uit te breiden. Voeg relevante AI-systemen toe aan de inventaris van assets, beoordeel hun aanvalspaden, wijs eigenaren voor de risicobehandeling aan en koppel ondersteunend bewijs. Achtergrond over het organiseren van dat werk vindt u in de checklist voor de implementatie van ISO 27001.

Een praktische checklist voor de implementatie van ISO 27090

De onderstaande stappen vormen een implementatieaanpak die is opgebouwd uit de onderwerpen van de norm en openbare richtlijnen voor veilige AI. Ze zijn geen officiële ISO-checklist en geen opsomming van verplichte clausules.

1. Definieer het systeem en de eigenaar

Kies een AI-use case met een duidelijk bedrijfsdoel. Leg de verantwoordelijke eigenaar, de gebruikers, de modelaanbieder, de hostingregeling en de gekoppelde diensten vast.

Trek vervolgens de grens van de review. Neem de applicatie en haar afhankelijkheden mee, niet alleen het modelendpoint. Een klantgerichte assistent met toegang tot tools vraagt om een andere beoordeling dan een interne tekstsamenvatter zonder rechten om te handelen.

Nuttige output: een systeemvastlegging met het doel, de grenzen, de afhankelijkheden, de toegestane acties en de verantwoordelijke eigenaar.

2. Breng de herkomst van data en modellen in kaart

Leg vast waar datasets en modelartefacten vandaan komen, wie ze kan wijzigen en welke versies in gebruik zijn. Neem de fine-tuninginput, retrievalcollecties, prompts en feedbackkanalen mee die relevant zijn voor het systeem.

De ontwikkelrichtlijnen van het NCSC bevelen aan AI-assets en hun herkomst bij te houden, ze te beschermen en de informatie te bewaren die nodig is om betrouwbare versies te herstellen. NCSC-richtlijnen voor veilige AI-ontwikkeling

Vraag bij een ingekocht model aan de aanbieder welke verantwoordelijkheden hij op zich neemt en welke informatie hij beschikbaar stelt wanneer modellen of diensten veranderen.

Nuttige output: een geversioneerde inventaris met bronnen, toegangsregels, wijzigingshistorie en verantwoordelijkheden van leveranciers.

3. Maak een threat model van de werkelijke workflow

Bekijk het systeem vanuit het perspectief van een aanvaller. Identificeer toegangspunten, gevoelige assets, rechten en de gevolgen van een geslaagde compromittering. De NCSC-richtlijnen voor veilig ontwerp bevelen threat modelling aan, evenals aandacht voor componenten van derden en het principe van minimale rechten. NCSC-richtlijnen voor veilig AI-ontwerp

Schrijf concrete scenario's uit. “AI-risico” is te breed om tot een nuttige actie te leiden. “Een document dat een externe partij uploadt, overtuigt de assistent om een bewijsbestand met beperkte toegang op te vragen” geeft een team iets specifieks om te analyseren.

Stel prioriteiten op basis van blootstelling en mogelijke schade. Leg vast wie het restrisico accepteert en wanneer dat besluit opnieuw moet worden bekeken.

Nuttige output: een kort risicoregister dat aanvalsscenario's koppelt aan assets, gevolgen, waarborgen en eigenaren.

4. Plaats waarborgen op de relevante grenzen

Selecteer beheersmaatregelen voor het scenario dat u aanpakt. Voor modelassets kan dat beschermde opslag, toegangsbeperkingen en integriteitscontroles betekenen. Denk bij ingezette diensten aan authenticatie, scheiding tussen omgevingen en maatregelen die ongeautoriseerde toegang of exfiltratie beperken. Dit zijn thema's uit de NCSC-richtlijnen voor uitrol. NCSC-richtlijnen voor veilige uitrol van AI

Valideer en codeer gegenereerde output voor de bestemming ervan voordat een ander systeem ernaar handelt. De OWASP-richtlijnen over outputverwerking leggen uit waarom modeloutput geen autoriteit mag krijgen alleen omdat die van het model afkomstig is. OWASP-richtlijnen over outputverwerking

Nuttige output: een vastlegging van de beheersmaatregel met de grens die ze beschermt, de eigenaar en het bewijs waarmee ze wordt gecontroleerd.

5. Test de volledige applicatie

Ontwerp tests rond de gevolgen die u in uw threat model hebt vastgesteld. Gebruik voor een RAG-assistent adversarial documenten en gebruikers met verschillende rechten. Test voor een agent wat er gebeurt wanneer opgehaalde content hem vraagt verder te gaan dan zijn toegestane acties.

Bepaal het verwachte resultaat voordat u de test uitvoert. Een voorbeeld: de applicatie moet een verzoek om een bestand met beperkte toegang weigeren, ook als het model dat verzoek probeert te doen.

Leg de applicatieconfiguratie, de modelversie, de testinput, het resultaat en eventuele herstelmaatregelen vast. Kies testdata die niet onnodig echte vertrouwelijke informatie blootstellen.

Nuttige output: herhaalbare beveiligingstests die gekoppeld zijn aan specifieke risico's en releasebesluiten.

6. Monitor wijzigingen en bereid een respons voor

Beoordeel het effect van updates van modellen, data en prompts. Monitor relevante input en output en bescherm daarbij gevoelige informatie in logs. De operationele richtlijnen van het NCSC benadrukken gedragsmonitoring en de beveiligingsgevolgen van wijzigingen gedurende de hele exploitatie. NCSC-richtlijnen voor veilige exploitatie van AI

Bepaal vooraf wie een tool kan uitschakelen, een credential kan intrekken, een integratie kan isoleren of een release kan terugdraaien. Stel triggers voor een review vast, zoals een nieuwe aanbieder, uitgebreide rechten, een ingrijpende modelupdate of een beveiligingsincident.

Nuttige output: verantwoordelijkheden voor monitoring, criteria voor de review van wijzigingen, een procedure voor incidentrespons en een geteste herstelroute.

AI-beveiligingsrisico's omzetten in bewijs

De onderstaande tabel is een voorgesteld werksjabloon. De voorbeelden van bewijs zijn praktische aanbevelingen, geen lijst van documenten die ISO 27090 voorschrijft.

Stel u bijvoorbeeld een securityteam voor dat een assistent gebruikt om klantbewijs samen te vatten. Een document van een leverancier bevat instructies om het bewijs naar een extern adres te uploaden.

De test van het team moet de geprobeerde actie door de applicatie heen volgen. Beschikt de assistent over een tool die bestanden kan uploaden? Dwingt die tool de rechten van de gebruiker af? Zijn bestemmingen beperkt? Moet een verantwoordelijke persoon de overdracht goedkeuren?

Een nuttige reviewvastlegging zou het scenario benoemen, de grens die de overdracht verhindert, het testresultaat en de persoon die het restrisico heeft goedgekeurd. Als het systeem verandert, vertelt die vastlegging de volgende reviewer wat opnieuw moet worden gecontroleerd.

Deze aanpak geeft een beoordeling meer inhoud dan de bewering dat het systeem “verantwoorde AI” gebruikt. Ze verbindt het beveiligingsbesluit met iets wat een ander kan controleren. Meer over het ordenen van ondersteunend materiaal leest u in audit readiness structureren.

ISO 27090-certificering en -eisen

ISO 27090 biedt beveiligingsrichtlijnen en geen certificeringseisen voor een managementsysteem. De toelichting van ISO onderscheidt het doel ervan van de AIMS-eisen in ISO 42001. Toelichting van ISO op ISO 27090

Bepaal eerst welke zekerheid u nodig hebt: een beveiligingsreview, een assurance-antwoord voor een klant, een interne gap-analyse of certificering tegen een toepasselijke managementsysteemnorm.

Vraag iedereen die een beoordeling aanbiedt de reikwijdte, de criteria en het assurance-schema te benoemen. Dat maakt het resultaat beter te interpreteren en voorkomt dat een review van AI-beveiligingspraktijken wordt verward met de certificering van een managementsysteem.

Schaf voor een implementatieproject de gepubliceerde norm aan, toets de richtlijnen aan uw eigen systemen en leg vast waarom bepaalde waarborgen passend zijn. De voorbeelden in dit artikel bieden een eerste structuur voor dat werk.

ISO 27090 en de Europese AI-verordening

Het toepassen van een internationale norm leidt niet automatisch tot naleving van de AI-verordening (EU AI Act). Artikel 40 verbindt een vermoeden van conformiteit aan geharmoniseerde normen waarvan de referenties in het Publicatieblad van de EU zijn bekendgemaakt, en alleen voor zover ze de betreffende eisen of verplichtingen dekken. Artikel 40 van de AI-verordening

Gebruik een beveiligingsreview volgens ISO 27090 als één input voor een afzonderlijk afgebakende conformiteitsbeoordeling. Leg de beoordeelde wettelijke verplichting vast, het bewijs dat die ondersteunt en een eventueel resterend hiaat.

Veelgestelde vragen over ISO 27090

Wanneer is ISO 27090 gepubliceerd?

De eerste editie, ISO/IEC 27090:2026, is gepubliceerd op 14 oktober 2026. Controleer de actuele publicatiegegevens van de uitgever wanneer ouder materiaal naar een ontwerp of een eerder jaar verwijst. Publicatiegegevens van IEC

Behandelt ISO 27090 generatieve AI en LLM-beveiliging?

De gepubliceerde inhoud omvat prompt injection en gevoelige modeloutput, waardoor de norm relevant is voor de beveiliging van generatieve AI. De reikwijdte omvat ook andere AI-systemen. Gepubliceerd fragment van ISO/IEC 27090 Toelichting van ISO op ISO 27090

Kan een bedrijf dat AI van derden gebruikt de norm toepassen?

Ja. De genoemde doelgroep omvat organisaties die AI gebruiken, naast organisaties die AI ontwikkelen. Begin met de risico's en verantwoordelijkheden die binnen uw invloed liggen en bepaal wat u over uw leveranciers moet weten. Publicatiegegevens van IEC

Betekent een ISO 27001-certificering dat een AI-systeem veilig is?

Een certificering van een managementsysteem garandeert niet dat een afzonderlijke applicatie bestand is tegen elke aanval. Gebruik het managementsysteem om risicobesluiten te ordenen en beoordeel het werkelijke ontwerp, de configuratie en het gedrag van het AI-systeem. ISO 27090 kan helpen om dat beveiligingswerk richting te geven.

Waar kan ik de ISO 27090 als pdf krijgen?

Gebruik de officiële ISO-catalogus of de IEC Webstore voor de gepubliceerde norm en de licentieopties. Controleer of de aanduiding ISO/IEC 27090:2026 is. Een artikel of preview bevat slechts een deel van het materiaal.

Maak AI-beveiligingswerk toetsbaar

Begin met één AI-use case met gevolgen. Bepaal hoe die gecompromitteerd kan worden, kies waarborgen voor de relevante grenzen en leg vast welk bewijs aantoont dat die waarborgen werken. Geef elke actie een eigenaar en een trigger voor review.

Secani verbindt eisen, risico's, beheersmaatregelen, bewijs, eigenaren en reviewbesluiten in een gedeelde werkruimte voor security en compliance. Neem contact op met Secani over het organiseren van uw AI-beveiligingswerk, zodat teams zien wat is beoordeeld, wat aandacht nodig heeft en wie verantwoordelijk is.