Topical requirements ontrafeld

Vanaf 2026 moeten internal auditors rekening houden met topical requirements. Het eerste over cybersecurity wordt op 5 februari 2026 van kracht. Katleen Seeuws, vicepresident Standards & Guidance bij IIA Global, en Peter Hartog, directeur Vaktechniek van IIA Nederland, delen hun visie op het doel, de totstandkoming en de praktische toepassing van de topical requirements.

Wat zijn topical requirements en welk doel hebben ze?

Katleen Seeuws: “Topical requirements zijn verplicht voorgeschreven minimumvereisten voor assuranceopdrachten op specifieke risicodomeinen, zoals cybersecurity, third party risk en organizational behavior. Ze vormen samen met de Global Internal Audit Standards (GIAS) en Global Guidance het vernieuwde IPPF. Waar de GIAS beschrijft wat internal audit is, hoe de auditfunctie moet worden georganiseerd en hoe audits moeten worden uitgevoerd, gaan topical requirements in op inhoudelijke aspecten en criteria van specifieke risicodomeinen. Ze zijn ontstaan vanuit de behoefte om wereldwijd meer richting te geven en consistentie te borgen voor de risicogebieden die al langer op de radar staan. De topical requirements vormen een baseline waaraan auditors in elk land en elke sector minimaal moeten voldoen. Daarmee willen we vanuit het IIA ook relevant blijven als normerende organisatie.”

Hoe kwamen de topical requirements tot stand?

Katleen: “Tijdens de ontwikkeling van de GIAS hebben we onderzocht of er behoefte bestond aan aanvullende guidance op risicodomeinniveau. In dat onderzoek bleek dat auditfuncties wereldwijd vooral behoefte hadden aan meer duidelijkheid in volwassen risicodomeinen die complex zijn en waar veel variatie in auditkwaliteit bestaat. Cybersecurity is daarvan het bekendste voorbeeld: het staat al jaren bovenaan als risicofactor, maar in auditplannen kreeg het niet altijd dezelfde prioriteit. De selectie van risicodomeinen gebeurt op basis van onderzoek naar volwassenheid: er moeten voldoende breed aanvaarde basispraktijken bestaan om tot een wereldwijde minimum baseline te komen. Vanuit die behoefte zijn we begonnen aan een ontwikkelingsproces dat vergelijkbaar is met dat van de GIAS. Een belangrijk onderdeel was de openbare consultatie. Bij het eerste topical requirement ontvingen we meer dan negenhonderd reacties van auditors, instituten, consultants en toezichthouders.”

Peter Hartog: “In de dagelijkse praktijk zie ik topical requirements vooral als een hulpmiddel”

Peter Hartog: “Vanuit IIA Nederland hebben we per consultatie een team van experts op het betreffende risicodomein samengesteld dat de conceptversies grondig heeft beoordeeld. Vervolgens bespraken we de gezamenlijke reactie namens IIA Nederland binnen het bestuur. Zo zorgen we dat de Nederlandse stem zowel deskundig als consistent wordt ingebracht.”

Was er kritiek op de topical requirements?

Peter: “Ja, vooral bij de eerste topical requirements was er kritiek. Vanuit Nederland en breder binnen Europa zijn we vooral tegen het verplichte karakter. Internal audit opereert van oudsher principle based, waarbij auditors als onderdeel van een risicoanalyse bepalen welke criteria voor een audit passend zijn. De standaarden in de GIAS (met name 13.2 en 13.3) dekken de inhoud dus al af. Daarbij speelt ook mee dat Europese auditfuncties relatief volwassen zijn en al werken met gedegen normenkaders. Aanvullend hebben we benadrukt dat voor cybersecurity al diverse frameworks bestaan, die ook door internal audit worden toegepast en dat de extra verplichtingen kunnen leiden tot onnodige administratieve druk.”

Katleen: “We waren aanvankelijk verrast dat de meeste kritiek uit de meer volwassen regio’s kwam. Later bleek dat er misverstanden waren over de toepasbaarheid. Topical requirements zijn alleen verplicht wanneer een risico significant is én wanneer een audit op dat specifieke gebied wordt uitgevoerd. Uitsluitingen moeten dan wel worden gedocumenteerd, maar dat is heel eenvoudig, want een goed onderbouwde risicoanalyse bevat eigenlijk al die informatie. Het is geen extra werk bovenop bestaande frameworks; het is een minimale baseline. We erkennen dat er ook andere, meer gerenommeerde, frameworks bestaan. Die zijn vaak uitgebreider. De topical requirements dienen dan ook niet als vervanging van andere standaarden. Minder volwassen auditfuncties verwelkomden de topical requirements juist omdat die duidelijkheid gaven.”

Wat betekenen de topical requirements voor de dagelijkse praktijk van internal auditors?

Peter: “In de dagelijkse praktijk zie ik topical requirements vooral als een hulpmiddel. Ze helpen auditors om expliciet en gestructureerd te kijken naar de belangrijkste risico’s. Dat helpt bij het uitvoeren van de risicoanalyse: je kunt toetsen of je alle relevante risicofactoren meeneemt. Het topical requirement moet daarbij wel goed passen bij het doel van de audit en de organisatie waarin deze wordt uitgevoerd. Het is dus situatieafhankelijk of je ze daadwerkelijk, geheel, gedeeltelijk of niet wilt gebruiken in een audit.”

Katleen: “Naast het hebben van een minimum baseline was een belangrijke aanleiding dat er vaak een mismatch bestond tussen het belang van een risico en de aandacht die het kreeg in het auditplan. Cybersecurity stond jarenlang op nummer een als grootste risico, maar in de auditplanning in de praktijk soms op plek vijf of zes. Topical requirements helpen daarmee ook in het gesprek met de auditcommissie: waarom hebben we deze audit wel of niet uitgevoerd, en is het risico voldoende afgedekt?”

Wanneer moeten topical requirements verplicht worden toegepast?

Katleen: “Topical requirements worden een jaar na publicatie van kracht. In februari 2026 is dat als eerste het topical requirement cybersecurity. Ze zijn verplicht zodra een significant risico is vastgesteld in de risicoanalyse van audit en wanneer op dat domein een audit wordt gepland. De verplichting is dus volledig risicogebaseerd. Vervolgens kijk je bij de scoping van de geplande audit welke onderdelen van de topical requirements relevant zijn. Het is niet per se noodzakelijk om direct alle elementen te behandelen. Topical requirements zijn geen checklist die volledig moet worden doorlopen. Ze zijn bedoeld om auditors te helpen bepalen wat minimaal noodzakelijk is.”

Peter: “Kwaliteitstoetsers zullen niet eisen dat een audit op een risico moet worden uitgevoerd, puur omdat er een topical requirement bestaat. Maar wanneer een audit wél wordt uitgevoerd, moet worden aangetoond dat de topical requirements correct zijn toegepast. Dat betekent vooral: een goede risicoanalyse en duidelijke scopeafwegingen.”

Moeten topical requirements altijd volledig worden toegepast?

Katleen: “Nee. Als een audit zich bijvoorbeeld richt op één specifieke applicatie, hoef je ook niet direct het hele topical requirement van cybersecurity in scope te nemen. Je zou dan kunnen overwegen om governancegerelateerde normen over te slaan of in een andere audit mee te nemen. De auditor moet dus per audit kijken welke elementen uit een specifieke topical requirement relevant zijn.”

Peter: “Organizational behavior is hier een goed voorbeeld van. Gedrag speelt vaak een rol als root cause van bevindingen. De standaarden stimuleren auditors om root cause analyses uit te voeren, en in die gevallen komt gedrag dan vaak als oorzaak van een bevinding naar voren. Maar dat betekent niet automatisch dat dan het volledige topical requirement moet worden toegepast. Alleen wanneer gedrag zelf een significant risico binnen het doel en de scope van de audit is, wordt de topical requirement relevant.”

 Katleen Seeuws: “Documenteren blijft een kerntaak van het vak. Auditors vragen dat immers ook van hun auditees”

Hoe kan een auditfunctie aantonen dat zij voldoet aan een topical requirement?

Katleen: “Het belangrijkste is goede documentatie. Een solide risicoanalyse maakt al duidelijk waarom een topical requirement wel of niet van toepassing is. Tijdens de scoping van de audit leg je vast welke onderdelen relevant zijn en hoe je ze toetst. De templates in de user guidance zijn optioneel; het zijn hulpmiddelen, geen verplichting. We vragen niet om méér documentatie dan voorheen, maar om expliciet vast te leggen hoe de topical requirements zijn meegenomen.  Documenteren blijft een kerntaak van het vak. Auditors vragen dat immers ook van hun auditees. Ik zeg dan: ‘Walk the talk’.”

Peter: “Sommige auditfuncties schrokken aanvankelijk van de templates, omdat ze die interpreteerden als verplichte checklists op het niveau van de individuele vereisten. Maar auditors kunnen ook op een hoger niveau concluderen dat een topical requirement niet past bij de gekozen scope en auditmethodiek, zoals bij organizational behavior. In zulke gevallen is het voldoende om die keuze in generieke zin, voor het topical requirement als geheel of voor de drie onderdelen te onderbouwen in de risicoanalyse en scope. Daarbij zie ik ook een rol voor het IIA om leden te kunnen helpen met mappings van een topical requirement tegen veel gehanteerde frameworks. Om daarmee snel en eenvoudig te kunnen aangeven dat aan de vereisten wordt voldaan als men zo’n framework hanteert. Dat is al gedaan in de gebruikershandleiding van het cybersecurity topical requirement.”

Is een topical requirement op zichzelf voldoende als normenkader voor een auditor?

Katleen: “Een topical requirement staat nooit op zichzelf en vervangt geen raamwerken. Het vormt een minimum baseline. Auditors moeten nog steeds een eigen werkprogramma opstellen dat past bij het specifieke object, de risico’s en de context van de audit. De topical requirements zijn niet bedoeld als volledige checklist of programma. Ze helpen alleen te waarborgen dat bepaalde essentiële elementen niet worden vergeten.”

Peter: “In de praktijk verwacht ik weinig tot geen audits die uitsluitend steunen op de topical requirements. Ze zullen vrijwel altijd worden aangevuld met sectorspecifieke of andere frameworks voor de topics, zoals bijvoorbeeld DORA of ISO en NIS-2 voor cybersecurity. Soms kunnen onderdelen worden weggelaten, omdat ze niet relevant zijn voor de scope. De topical requirements helpen om het minimum af te dekken, maar auditors kunnen en moeten hun professional judgement blijven toepassen. Voor sommige organisaties zijn de topical requirements zelfs minder gedetailleerd dan de frameworks die ze al gebruiken.”

Welke topical requirements zouden jullie zelf als aanvulling willen zien?

Peter: “Gezien onze mening over het verplichte karakter heb ik niet direct behoefte aan nóg meer topical requirements. Ik zie meer waarde in Global Guidance die auditfuncties helpt bij nieuwe risico’s. Emerging topics veranderen snel, en guidance geeft flexibiliteit zonder directe verplichting. Dat past wat mij betreft beter bij het principle-basedkarakter van de beroepsnormen van internal audit.”

Katleen: “Goed punt, emerging risico’s staan ook op de radar, maar dan inderdaad voor het ontwikkelen van niet verplichte guidance. Toch is het belangrijk dat voor sommige risicodomeinen een minimum baseline wordt vastgelegd om wereldwijd consistentie en kwaliteit te waarborgen. In de pijplijn zitten onderwerpen als anti-bribery en corruption, talentmanagement, en fraude, die we in 2026 verder uitwerken. Voor emerging topics zoals artificial intelligence moeten eerst gemeenschappelijke normen worden vastgesteld voordat we overgaan tot een topical requirement.”

Peter Hartog: “Topical requirements maken onze bijdrage zichtbaarder”

Wat hopen jullie dat de topical requirements op de lange termijn teweegbrengen?

Peter: “Ik hoop dat auditors de topical requirements vooral gaan zien als hulpmiddel. Daarnaast kunnen de topical requirements helpen bij de positionering van het vakgebied. Door – net als in de accountancy – meer opdrachtgebonden normen te introduceren, kunnen we nog beter aan onze stakeholders laten zien dat internal audit een volwassen en professioneel beroep is. Het laat ook de breedte van internal auditing zien. Het maakt onze bijdrage zichtbaarder en kan daarmee de geloofwaardigheid richting bestuurders en toezichthouders vergroten.”

Katleen: “Het doel van de topical requirements is om de lat wereldwijd hoger te leggen. Ze moeten vertrouwen wekken bij stakeholders, vooral omdat ze laten zien dat auditors consistent kijken naar kritieke risico’s. Topical requirements creëren bovendien meer duidelijkheid in domeinen waar auditors traditioneel verschillende invalshoeken hebben gebruikt.”