API-beveiligingsgovernance: ISO 27001-bewijsvoering voor 2026

De API-auditbevinding die vóór de inbreuk komt

Maria, CISO van een snelgroeiend fintech-SaaS-bedrijf, opent drie weken vóór de jaarlijkse beoordeling een e-mail van de hoofdauditor. Het bericht is direct:

“Wij voeren een diepgaande beoordeling uit van uw kader voor ICT-risicobeheer voor derden en de afstemming daarvan op DORA, NIS2 en GDPR, met specifieke aandacht voor uw API-ecosysteem. Verstrek de inventaris, het authenticatiemodel, bewijs voor rate limiting en de dekking van logging voor productie- en partner-API’s.”

Twee dagen later stuurt internal audit een tweede bericht:

“We hebben 47 publieke API-endpoints gevonden die niet in de inventaris van bedrijfsmiddelen staan. Vier accepteren API-sleutels zonder bewijs van rotatie. Eén partnerintegratie heeft geen rate limiting. Logging is inconsistent over productiediensten heen. Verstrek uiterlijk vrijdag bewijs voor ISO 27001, GDPR en NIS2.”

Er is geen ransomwarebericht. Geen publieke inbreuk. Geen klantklacht. Toch is de bevinding ernstig, omdat zij het governancehiaat blootlegt dat aanvallers al misbruiken. API’s vormen inmiddels de feitelijke perimeter. Zij verbinden betalingen, onboarding, identiteit, klantportalen, leveranciersdiensten, mobiele apps, cloudworkloads, analyseplatformen en uitbestede risico-engines.

Een bijna-incident maakt het probleem moeilijker te negeren. Een junior ontwikkelaar, werkend onder tijdsdruk, maakte een staging-API zonder authenticatie vanaf internet bereikbaar. Deze bevatte realistische, gepseudonimiseerde klantgegevens. Het red team vond de API als eerste, maar het management stelde de voor de hand liggende vraag: wat staat er nog meer open?

In 2026 is API-beveiligingsgovernance niet alleen een checklist voor ontwikkelaars. CISO’s, complianceverantwoordelijken, interne auditors en raden van bestuur moeten aantonen dat API’s bekend zijn, een eigenaar hebben, geauthenticeerd worden, gemonitord zijn, onder rate limiting vallen, getest zijn, op risico zijn beoordeeld en zijn opgenomen in incidentmelding. Hetzelfde bewijs moet vaak voldoen aan assuranceverwachtingen die zijn afgestemd op ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT.

De meeste organisaties beschikken al over technische tooling: API-gateways, identityproviders, SIEM-platformen, WAF’s, cloudlogboeken, service meshes, CI/CD-pijplijnen en ticketsystemen. Wat vaak ontbreekt, is het verhaal rond de beheersmaatregelen. Welke API’s vallen binnen het toepassingsgebied? Wie keurt nieuwe API’s goed? Welke logboeken tonen authenticatiefouten aan? Welk register toont API-afhankelijkheden van derden? Waarom verschillen rate limits voor klant-, beheer- en machine-to-machine-API’s?

De aanpak van Clarysec is om API-beveiligingsgovernance te behandelen als een bewijssysteem over meerdere compliancekaders heen, niet als een eenmalige engineeringactiviteit. Als een API gegevens kan blootstellen, een bedrijfsproces kan wijzigen, een gebruiker kan authenticeren, een betaling kan starten, een leverancier kan aanroepen of een gereguleerde dienst kan ondersteunen, hoort deze API thuis in het ISMS-bewijsmodel.

Waarom API-governance nu een bestuurskwestie is

NIS2 maakt cyberbeveiligingsgovernance tot een verantwoordelijkheid van het bestuursorgaan. Article 20 vereist dat bestuursorganen cyberbeveiligingsrisicobeheermaatregelen goedkeuren, toezicht houden op de implementatie en training ontvangen zodat zij cyberrisico’s en hun impact op diensten kunnen begrijpen. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, beveiligingsbeleid, incidentenafhandeling, bedrijfscontinuïteit, beveiliging van de toeleveringsketen, veilige verwerving en ontwikkeling, behandeling van kwetsbaarheden, beoordeling van de doeltreffendheid, cyberbeveiligingshygiëne, cryptografie, toegangscontrole, beheer van bedrijfsmiddelen en, waar passend, multifactorauthenticatie of continue authenticatie.

Voor API-governance betekent dit dat publieke API’s, partner-API’s, beheer-API’s en interne microservice-API’s deel kunnen uitmaken van gereguleerde dienstverlening. NIS2 kan van toepassing zijn op aanbieders van cloudcomputingdiensten, datacentrumdiensten, content delivery networks, vertrouwensdiensten, openbare elektronische communicatienetwerken en -diensten, en aanbieders van ICT-dienstbeheer zoals MSP’s en MSSP’s, afhankelijk van sector, omvang, criticaliteit en classificatie door de lidstaat.

DORA voegt daar het perspectief van de financiële sector aan toe. DORA is van toepassing vanaf 17 januari 2025 en stelt uniforme eisen vast voor ICT-risicobeheer, rapportage van ICT-gerelateerde incidenten, testen van digitale operationele weerbaarheid, informatie-uitwisseling en ICT-risicobeheer voor derden. Article 5 vereist dat het bestuursorgaan het ICT-risicobeheerkader definieert, goedkeurt, er toezicht op houdt en er verantwoordelijk voor blijft. Article 8 vereist identificatie, classificatie en documentatie van door ICT ondersteunde bedrijfsfuncties, informatieactiva, ICT-activa, afhankelijkheden, door derden ondersteunde processen, kritieke activa, inventarissen en legacy-ICT-risico.

In API-termen is een API voor betalingsinitiatie, fraudescore, klantonboarding of uitbestede KYC niet zomaar een endpoint. Het is een ICT-asset en afhankelijkheid die een bedrijfsfunctie ondersteunt.

GDPR maakt het beeld compleet. API’s die identificatoren, accountgegevens, apparaat-ID’s, gedragstelemetrie, biometrie, gezondheidsgerelateerde gegevens of financiële profielen verzenden, kunnen persoonsgegevens verwerken. Het verantwoordingsbeginsel van GDPR vereist dat verwerkingsverantwoordelijken naleving kunnen aantonen van rechtmatigheid, doelbinding, gegevensminimalisatie, opslagbeperking, integriteit en vertrouwelijkheid. Article 32 vereist beveiliging van de verwerking, terwijl Articles 33 and 34 afhankelijk zijn van betrouwbaar bewijs wanneer zich een datalek voordoet.

De raad van bestuur heeft geen packet captures nodig, maar wel zekerheid dat de organisatie weet welke API’s ertoe doen, welke gegevens zij verwerken, van welke leveranciers zij afhankelijk zijn, hoe misbruik wordt voorkomen, hoe incidenten worden gedetecteerd en hoe compliance kan worden aangetoond.

Begin met de API-inventaris

De meeste API-fouten beginnen als inventarisatiefouten. Een verouderde mobiele backend draait nog steeds in productie. Een tijdelijke partnerintegratie wordt permanent. Een cloudfunctie stelt een nieuw endpoint bloot. Een interne API wordt vanaf internet bereikbaar na een wijziging in een load balancer. Niets daarvan staat in de CMDB, waardoor niets ervan een authenticatiebeoordeling, loggingstandaarden, drempelwaarden voor rate limiting, leveranciersbeoordeling of classificatie voor bewaartermijnen krijgt.

De eerste auditvraag is meestal eenvoudig: “Mag ik uw API-inventaris zien?”

Clarysec behandelt de API-inventaris als onderdeel van de ISMS-inventaris van bedrijfsmiddelen. In de Zenith Blueprint: 30-stappenroutekaart voor auditors Zenith Blueprint, fase Controls in Action, stap 22, legt de toelichting op ISO/IEC 27002:2022-beheersmaatregel 5.9 uit:

“Geen organisatie kan beschermen waarvan zij niet weet dat zij het heeft. Beheersmaatregel 5.9 formaliseert dit fundamentele principe en vereist het opzetten en onderhouden van een actuele inventaris van alle informatie en daaraan gekoppelde bedrijfsmiddelen die relevant zijn voor het ISMS.”

Dezelfde stap omvat logische activa zoals “gebruikersaccounts, referenties, sleutels, softwarelicenties, API’s” en dienstgerelateerde activa zoals SaaS-platformen en uitbestede opslag. De Zenith Blueprint noemt de inventaris “het centrale zenuwstelsel van uw ISMS”, omdat deze richting geeft aan toegangsverlening, encryptie, back-up, logging, classificatie en bewaartermijnen.

Clarysec’s enterprise Beleid inzake beheer van bedrijfsmiddelen Beleid inzake beheer van bedrijfsmiddelen zet dit om in een governancevereiste:

“De IT Asset Manager moet een volledige en gecentraliseerde inventaris van bedrijfsmiddelen onderhouden die alle informatieactiva omvat die door de organisatie worden gebruikt of ermee verbonden zijn.”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.

Voor mkb-organisaties neemt Clarysec’s Beleid inzake beheer van bedrijfsmiddelen - mkb Beleid inzake beheer van bedrijfsmiddelen - mkb expliciet API-relevante digitale activa op:

“Digitale referenties en diensten: domeinnamen, digitale certificaten, API-sleutels, e-mailaccounts, cloudlogins”

Uit sectie “Reikwijdte”, beleidsclausule 2.2.4.

Die formulering is belangrijk. Bij veel audits staat het API-endpoint in een gateway, het token in een secrets vault, het certificaat in een cloudaccount en de gegevensstroom in een privacyregistratie. Een verdedigbare API-inventaris verbindt deze elementen.

In Zenith Controls: The Cross-Compliance Guide Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 5.9, Inventaris van informatie en andere daaraan gekoppelde bedrijfsmiddelen, geclassificeerd als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt. Het cyberbeveiligingsconcept is Identify, de operationele capaciteit is beheer van bedrijfsmiddelen en de beveiligingsdomeinen zijn Governance, Ecosystem en Protection. Dit helpt auditors de API-inventaris te zien als een preventieve governancebeheersmaatregel, niet als administratieve huishouding.

Toon aan dat elke API-identiteit bewust is ingericht

Zodra de inventaris bestaat, is de volgende vraag voorspelbaar: wie of wat mag deze API’s aanroepen?

Moderne API’s authenticeren menselijke gebruikers, mobiele apps, serviceaccounts, CI/CD-jobs, partnersystemen, workloads, bots, integraties, datapijplijnen en platforms van derden. Zwakke API-sleutels, langlevende bearer tokens, ontbrekende mutual TLS, OAuth-scopes met te ruime rechten en hardcoded secrets veroorzaken allemaal auditblootstelling.

De Zenith Blueprint, fase Controls in Action, stap 19, behandelt ISO/IEC 27002:2022-beheersmaatregel 8.5, Beveiligde authenticatie:

“Authenticatie is de eerste en meest kritieke verdedigingslinie tussen een dreigingsactor en uw systemen, gegevens en diensten. Als authenticatie zwak is, kan al het andere — encryptie, monitoring, segmentatie — worden omzeild.”

Dezelfde stap benadrukt machine-to-machine-authenticatie. Sleutels, certificaten en tokens moeten strikt worden beschermd, referenties mogen niet in code worden opgenomen en secretsmanagement of vaults moeten worden gebruikt voor veilige opslag en rotatie.

Clarysec’s enterprise Beleid inzake vereisten voor applicatiebeveiliging Beleid inzake vereisten voor applicatiebeveiliging brengt dit rechtstreeks in API-governance:

“Alle API’s (application programming interfaces), microservices en externe integraties moeten worden beveiligd door middel van:”

Uit sectie “Governancevereisten”, beleidsclausule 5.3.

Daarna wordt gespecificeerd:

“Afdwinging van sterke authenticatie, zoals OAuth 2.0 en mutual TLS”

Uit sectie “Governancevereisten”, beleidsclausule 5.3.1.

Voor kleinere organisaties biedt Clarysec’s Beleid inzake vereisten voor applicatiebeveiliging - mkb Beleid inzake vereisten voor applicatiebeveiliging - mkb de basislijn:

“Authenticatiebeheersmaatregelen: toepassingen moeten sterke authenticatie afdwingen, waaronder minimale wachtwoordsterkte, accountvergrendeling na mislukte pogingen en sessietime-outs.”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.2.

Zet deze vereisten voor API’s om in een bewijspakket voor authenticatie:

1. API-inventaris gefilterd op internetgerichte, partnergerichte, beheer- en interne API’s.
2. Authenticatiematrix met OAuth 2.0, mTLS, ondertekende verzoeken, gateway-authorizers of service mesh-identiteit.
3. OAuth-client- en scoperegister met eigenaar, doel, vervaldatum, goedkeuring en datum van laatste beoordeling.
4. Bewijs van secretsmanagement waaruit opslag, toegang, rotatie en intrekking blijken.
5. Beoordeling van geprivilegieerde API-toegang voor beheerendpoints en productie-serviceaccounts.
6. Logboeken van mislukte authenticatie en waarschuwingsregels.
7. Testresultaten voor scenario’s met ontbrekend token, verlopen token, verkeerde audience, verkeerde scope en replay.

In Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 8.5, Beveiligde authenticatie, gemapt als een preventieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt. Het cyberbeveiligingsconcept is Protect, de operationele capaciteit is identiteits- en toegangsbeheer en het beveiligingsdomein is Protection.

NIS2 Article 21 ondersteunt dit via toegangscontrole, cryptografie en waar passend multifactorauthenticatie of continue authenticatie. DORA verwacht dat financiële entiteiten beheersmaatregelen onderhouden die authenticiteit, integriteit, beschikbaarheid en vertrouwelijkheid beschermen. GDPR Article 32 maakt zwakke API-authenticatie tot een aandachtspunt voor beveiliging van de verwerking, vooral waar persoonsgegevens worden blootgesteld.

Behandel rate limiting als bewijs voor weerbaarheid

Sterke authenticatie is noodzakelijk, maar niet voldoende. Een geauthenticeerde client kan een API nog steeds misbruiken. Aanvallers gebruiken API’s voor credential stuffing, enumeratie, scraping, token spraying, bombardementen op wachtwoordresets, transactiemisbruik en denial-of-service.

Rate limiting werd vroeger gezien als een prestatievoorziening. In 2026 is het bewijs voor beveiliging, privacy en weerbaarheid.

Clarysec’s Beleid inzake vereisten voor applicatiebeveiliging stelt:

“Rate limiting en preventie van misbruik”

Uit sectie “Governancevereisten”, beleidsclausule 5.3.2.

De Zenith Blueprint, fase Controls in Action, stap 20, voor ISO/IEC 27002:2022-beheersmaatregel 8.26, Vereisten voor applicatiebeveiliging, legt uit dat vereisten voor applicatiebeveiliging precies en uitvoerbaar moeten zijn. De stap vraagt of een toepassing weerbaar moet zijn tegen injectieaanvallen, brute-force-aanmeldingen of denial-of-service-pogingen. Ook wordt het API-specifieke voorbeeld gegeven dat een nieuwe API validatie van toegangstokens en invoersanering moet bevatten, en wordt opgemerkt dat publieke platforms strengere validatie, analyse van gebruikersgedrag en rate limiting kunnen vereisen.

Een verdedigbare registratie van rate limiting moet niet alleen uitleggen dát throttling bestaat, maar ook waarom drempelwaarden zijn gekozen, wie uitzonderingen heeft goedgekeurd en hoe waarschuwingen worden gemonitord.

Voor NIS2 ondersteunt dit veilige ontwikkeling, beoordeling van de doeltreffendheid, bedrijfscontinuïteit en incidentpreventie. Voor DORA verbindt rate limiting zich met ICT-risicobeheer, anomaliedetectie, weerbaarheidstesten en continuïteit van kritieke of belangrijke functies. Voor GDPR ondersteunt het gegevensminimalisatie en bescherming tegen buitensporige of onrechtmatige toegang, met name waar API-scraping persoonsgegevens kan blootstellen.

Maak van logging de bewijslaag

Wanneer zich een API-incident voordoet, is de eerste echte vraag niet: “Heeft u een SIEM?” De vraag is: “Kunt u reconstrueren wat er is gebeurd?”

API-logboeken moeten authenticatiefouten, autorisatieweigeringen, tokenclaims, clientidentiteit, bron, endpoint, methode, resultaat van verzoeken, beheerwijzigingen, toegang tot hoogrisicogegevens, rate limit-gebeurtenissen, afwijkende volumes, configuratiewijzigingen en beveiligingsrelevante fouten vastleggen. Zij mogen geen secrets, bearer tokens of onnodige persoonsgegevens loggen.

De Zenith Blueprint, fase Controls in Action, stap 19, voor ISO/IEC 27002:2022-beheersmaatregel 8.15, Logging, stelt:

“Logging is de levensader van elke veilige IT-omgeving. Zonder logging blijven incidenten onzichtbaar, vervaagt verantwoordingsplicht en verdwijnen oorzaak-gevolgrelaties in het niets.”

De stap legt ook uit dat logging draait om traceerbaarheid en dat bruikbare logboeken veilig moeten worden opgeslagen, gemonitord, beoordeeld en beschermd tegen manipulatie.

Clarysec’s Beleid inzake vereisten voor applicatiebeveiliging - mkb vereist:

“Auditlogging: toepassingen moeten authenticatiegebeurtenissen loggen (aanmeldingen, afmeldingen en mislukte pogingen), gegevenstoegang en beheerwijzigingen.”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.1.1.7.

Clarysec’s Beleid voor logging en bewaking - mkb Beleid voor logging en bewaking - mkb stelt de governancecategorie voor logging vast:

“Vereiste logtypen”

Uit sectie “Governancevereisten”, beleidsclausule 5.4.

Voor in de cloud gehoste API’s versterkt Clarysec’s enterprise Beleid inzake gebruik van cloudservices Beleid inzake gebruik van cloudservices de vereiste:

“Logboeken moeten vastleggen:”

Uit sectie “Vereisten voor beleidsimplementatie”, beleidsclausule 6.5.2.

In Zenith Controls wordt ISO/IEC 27002:2022-beheersmaatregel 8.15, Logging, gemapt als een detectieve beheersmaatregel die vertrouwelijkheid, integriteit en beschikbaarheid ondersteunt. Het cyberbeveiligingsconcept is Detect, de operationele capaciteit is beheer van informatiebeveiligingsgebeurtenissen en de beveiligingsdomeinen zijn Protection en Defense. Daarmee vormt logging de brug tussen beleid en bewijs.

NIS2 Article 23 vereist gefaseerde melding van significante incidenten: een vroegtijdige waarschuwing binnen 24 uur na kennisname, een incidentmelding binnen 72 uur, tussentijdse rapportages indien gevraagd en een eindrapport binnen één maand na de melding. Voor aanbieders van vertrouwensdiensten die worden geraakt in de verlening van vertrouwensdiensten is kennisgeving binnen 24 uur na kennisname vereist.

DORA Articles 17 to 19 vereisen beheer van ICT-gerelateerde incidenten met vroegtijdige waarschuwingsindicatoren, classificatie naar ernst en criticaliteit, escalatie, logging, follow-up van oorzakenanalyse en rapportage van majeure ICT-gerelateerde incidenten via initiële, tussentijdse en eindrapportages. Ook de beoordeling van datalekken onder GDPR is afhankelijk van logboeken om vast te stellen of persoonsgegevens zijn geraadpleegd, welke betrokkenen zijn geraakt en of meldplichten worden geactiveerd.

Bouw in vijf werkdagen een API-bewijspakket

Het doel van een snelle sprint is niet om alle API-beveiliging in één week te herstellen. Het doel is een verdedigbare baseline te creëren, hiaten te identificeren en risicobehandeling te starten.

Dag 1: stel het API-register op

Exporteer routes uit API-gateways, service meshes, cloudloadbalancers, serverless functies, OpenAPI-repositories en CI/CD-uitrolmanifesten. Normaliseer deze naar één API-register met endpoint, omgeving, eigenaar, bedrijfsproces, gegevensclassificatie, indicator voor persoonsgegevens, authenticatiemethode, rate limit, loggingstatus, leveranciersafhankelijkheid, criticaliteit en datum van laatste beoordeling.

Gebruik clausule 6.1.1 van het Beleid inzake beheer van bedrijfsmiddelen en stap 22 van de Zenith Blueprint als governance-anker.

Dag 2: classificeer authenticatiehiaten

Maak een authenticatiematrix. Markeer API’s die statische API-sleutels, langlevende tokens, geen audience-validatie, geen scopevalidatie, ontbrekende mTLS voor partnerintegraties, gedeelde serviceaccounts of ontbrekend bewijs van rotatie gebruiken.

Map bevindingen naar clausule 5.3.1 van het Beleid inzake vereisten voor applicatiebeveiliging en stap 19 van de Zenith Blueprint. Registreer elk hiaat als risico met een eigenaar, behandelroute en streefdatum.

Dag 3: toon rate limiting en beheersmaatregelen tegen misbruik aan

Leg voor publieke, partner- en beheer-API’s gatewaybeleid, WAF-regels, botbeheersmaatregelen, quota-instellingen en waarschuwingsdrempels vast. Waar beheersmaatregelen ontbreken, registreert u compenserende beheersmaatregelen of openstaande risicobehandeling.

Gebruik clausule 5.3.2 van het Beleid inzake vereisten voor applicatiebeveiliging als beleidsautoriteit. Verbind drempelwaarden voor kritieke API’s met dienstimpact, klantnadeel en weerbaarheidsverwachtingen onder DORA of NIS2.

Dag 4: valideer de dekking van logging

Neem steekproeven van logboeken voor API’s met een hoog risico. Bevestig dat logboeken succesvolle authenticatie, mislukte authenticatie, autorisatieweigering, gegevenstoegang, beheerwijziging, rate limit-gebeurtenis, bronidentiteit en correlatie-ID vastleggen. Verifieer tijdsynchronisatie, bewaartermijnen, toegangscontrole en bescherming tegen manipulatie.

Als logboeken tokens, secrets of buitensporige persoonsgegevens bevatten, registreer dan herstelmaatregelen voor privacy en beveiliging.

Dag 5: lever het auditrespons-pakket op

Lever een beknopte set bewijs op:

• Export van de API-inventaris en samenvatting van eigenaarschap.
• API-risicoregister met risicobehandelingsplan.
• Authenticatiematrix en bewijs van tokenbeoordeling.
• Bewijs voor rate limiting en goedgekeurde uitzonderingen.
• Rapportage over loggingdekking en screenshots van SIEM-dashboards.
• Incidentclassificatiedraaiboek voor API-misbruik.
• Mapping over meerdere compliancekaders heen naar auditperspectieven die zijn afgestemd op ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT.

De belangrijke verschuiving is dat elk artefact een verhaal rond de beheersmaatregel heeft. Het API-register ondersteunt beheer van bedrijfsmiddelen. Authenticatie ondersteunt toegangscontrole. Rate limits ondersteunen applicatiebeveiliging en weerbaarheid. Logboeken ondersteunen detectie, incidentrespons en verantwoordingsplicht.

Cross-compliance-mapping voor API-governance

De grootste fout is het bouwen van afzonderlijke bewijssets voor elk raamwerk. API-governance werkt beter als één model voor beheersmaatregelen met meerdere regelgevende invalshoeken.

ISO/IEC 27001:2022 biedt het managementsysteem dat het bewijs bij elkaar houdt. Clauses 4.1 to 4.4 vereisen dat de organisatie ISMS-context en -scope definieert, inclusief belanghebbenden, wettelijke, regelgevende en contractuele verplichtingen, en interfaces of afhankelijkheden met andere organisaties. Clauses 5.1 to 5.3 leggen de verantwoordingsplicht bij het topmanagement. Clauses 6.1.1 to 6.1.3 vormen het proces voor risicobeoordeling, risicobehandeling en de Verklaring van Toepasselijkheid. Clause 8.1 vereist operationele planning en beheersing, inclusief beheersing van extern geleverde processen, producten of diensten die relevant zijn voor het ISMS.

Voor API-governance betekent dit dat een API voor betalingen door derden, een cloudidentiteits-API of een uitbestede fraudedetectie-API niet buiten compliance valt omdat deze extern is. Het is een interface en afhankelijkheid die binnen scope moet worden gebracht, op risico moet worden beoordeeld en moet worden beheerst.

NIST CSF 2.0 voegt een nuttig bestuursperspectief toe. De GOVERN-functie helpt organisaties verwachtingen van stakeholders, wettelijke verplichtingen, risicobereidheid en risico’s in de toeleveringsketen te definiëren. De Profiles-aanpak ondersteunt een Current Profile, Target Profile, geprioriteerd hiaatplan en cyclus voor voortdurende verbetering. Dat is precies hoe een API-governancesprint moet werken.

COBIT 2019 kan het managementperspectief ondersteunen door API-beheersmaatregelen te verbinden met governancedoelstellingen, eigenaarschap van beheersmaatregelen, continuïteit van dienstverlening, beveiligingsmonitoring, risicorapportage en issue tracking. De kern is niet om API’s in één raamwerk te dwingen, maar te tonen dat één bewijsmodel meerdere assurancevragen beantwoordt.

Hoe auditors API-governance toetsen

Een sterk programma anticipeert op het perspectief van de auditor. Hetzelfde bewijs wordt verschillend getoetst, afhankelijk van het raamwerk.

Clarysec adviseert bewijstriangulatie. Toon niet alleen het beleid. Toon het beleid, implementatiebewijs en operationeel bewijs.

Bijvoorbeeld:

• Beleid: API’s moeten waar passend OAuth 2.0 of mTLS gebruiken.
• Configuratie: de API-gatewayroute toont JWT-validatie en toegestane audience.
• Operationeel bewijs: mislukte tokenpogingen worden gelogd en actieve waarschuwing is ingericht.
• Beoordelingsbewijs: OAuth-clientbeoordeling afgerond met formele goedkeuring door de eigenaar.
• Risicobewijs: een legacy-API-uitzondering heeft compenserende beheersmaatregelen en een behandeldeadline.

Dit is veel sterker dan een reactie die alleen uit screenshots bestaat.

Veelvoorkomende valkuilen in API-governance

Het meest voorkomende probleem is niet dat API’s volledig onbeveiligd zijn. Het probleem is dat beveiliging inconsistent is.

Het ene team gebruikt OAuth-scopes goed, een ander team gebruikt een gedeelde API-sleutel. De ene dienst logt gegevenstoegang, een andere dienst logt alleen serverfouten. Eén partnerintegratie heeft mTLS, een andere vertrouwt op een langlevend bearer token. Rate limits bestaan voor publieke endpoints, maar niet voor geauthenticeerde klant-API’s waar scraping kan plaatsvinden. De CMDB vermeldt de toepassing, maar niet de bijbehorende API’s, tokens, certificaten, gegevenscategorieën of leveranciers.

Terugkerende valkuilen zijn onder meer:

• Shadow-API’s die via serverless functies of tijdelijke testroutes zijn uitgerold.
• API-sleutels die in CI/CD-variabelen zijn opgeslagen zonder gedocumenteerde rotatie.
• Logging die tokens, secrets of onnodige persoonsgegevens vastlegt.
• Geen correlatie-ID over gateway-, applicatie- en databaselogboeken heen.
• Rate limit-uitzonderingen die informeel aan grote klanten worden toegekend.
• Partner-API’s zonder contractuele incidentmelding of auditrechten.
• Geen API-specifieke incidentclassificatie voor enumeratie, scraping of tokenmisbruik.
• Geen mapping tussen API-gegevensstromen en GDPR-verwerkingsregistraties.
• Beveiligingstesten gericht op de web-UI terwijl API’s ongetest blijven.
• Bestuursrapportages die “applicatiebeveiliging” tonen zonder API-specifieke risicometrieken.

Dit zijn oplosbare problemen, maar alleen als de organisatie API-governance behandelt als een beheerd domein van beheersmaatregelen.

Zet API-beveiliging om in auditgereed governance

Als uw volgende audit vraagt om bewijs voor API-beveiliging, begin dan niet met het verzamelen van willekeurige screenshots. Begin met het verhaal rond de beheersmaatregelen.

Clarysec kan u helpen dit op te bouwen met:

• Zenith Blueprint Zenith Blueprint om implementatie te structureren over de inventaris van bedrijfsmiddelen, beveiligde authenticatie, vereisten voor applicatiebeveiliging en logging.
• Zenith Controls Zenith Controls om ISO/IEC 27002:2022-beheersmaatregelen zoals 5.9, 8.5, 8.15 en 8.26 te mappen naar cross-complianceverwachtingen en auditperspectieven.
• Clarysec-beleid, waaronder Beleid inzake beheer van bedrijfsmiddelen Beleid inzake beheer van bedrijfsmiddelen, Beleid inzake vereisten voor applicatiebeveiliging Beleid inzake vereisten voor applicatiebeveiliging, Beleid inzake gebruik van cloudservices Beleid inzake gebruik van cloudservices, Beleid inzake beheer van bedrijfsmiddelen - mkb Beleid inzake beheer van bedrijfsmiddelen - mkb, Beleid inzake vereisten voor applicatiebeveiliging - mkb Beleid inzake vereisten voor applicatiebeveiliging - mkb en Beleid voor logging en bewaking - mkb Beleid voor logging en bewaking - mkb.

Een praktische volgende stap is het uitvoeren van een Clarysec API Governance Evidence Sprint: inventariseer uw API’s, classificeer authenticatie, verifieer rate limiting, valideer logging, breng afhankelijkheden van derden in kaart en produceer een ISO 27001-gereed bewijspakket met auditperspectieven die zijn afgestemd op NIS2, DORA, GDPR, NIST CSF 2.0 en COBIT.

API’s zijn het punt waar bedrijfslogica, klantgegevens en afhankelijkheden van derden samenkomen. In 2026 verdienen zij meer dan technische bescherming. Zij hebben governance nodig die een audit kan doorstaan, een respons aan toezichthouders kan ondersteunen en uw teams helpt misbruik te detecteren voordat klanten dat doen.