DORA-informatieregister: ISO 27001-gids

Het is 09:15 op een dinsdag. Sarah, de CISO van een snelgroeiende fintech, zit in een gereedheidsbeoordeling met haar compliance manager, juridisch adviseur, inkoopverantwoordelijke en cloudarchitect. De externe consultant vervult de rol van DORA-toezichthouder.

“Dank voor de presentatie,” zegt hij. “Verstrek uw informatieregister zoals vereist door DORA Article 28, inclusief de contractuele ICT-regelingen die kritieke of belangrijke functies ondersteunen, inzicht in onderaanneming, eigenaarschap van bedrijfsmiddelen en bewijsmateriaal dat het register wordt onderhouden binnen uw ICT-risicobeheerkader.”

Het eerste antwoord klinkt zelfverzekerd: “Wij hebben een leverancierslijst.”

Daarna volgen de vragen.

Welke leveranciers ondersteunen betalingsautorisatie? Welke contracten bevatten auditrechten, ondersteuning bij incidenten, toezeggingen over gegevenslocaties, beëindigingsrechten en exitondersteuning? Welke SaaS-platformen verwerken persoonsgegevens van klanten? Welke clouddiensten ondersteunen kritieke of belangrijke functies? Welke onderaannemers zitten achter de managed security provider? Welke interne asset-eigenaar heeft de afhankelijkheid goedgekeurd? Welke risico’s in het ISO/IEC 27001:2022-risicobehandelingsplan zijn aan deze aanbieders gekoppeld? Welke vermeldingen in de Verklaring van Toepasselijkheid onderbouwen de beheersmaatregelen?

Om 10:30 heeft het team vier spreadsheets, een CMDB-export, een SharePoint-map met PDF-contracten, een privacyverwerkerslijst, een cloudfacturatierapport en een handmatig bijgehouden SaaS-tracker geopend. Geen daarvan komt overeen.

Dat is de praktische uitdaging van het DORA-informatieregister in 2026. De DORA-implementatie is verschoven van “we hebben een roadmap nodig” naar “toon het bewijsmateriaal”. Voor financiële entiteiten, derde aanbieders van ICT-diensten, CISO’s, interne auditors en compliance teams is het register niet langer een administratief sjabloon. Het is het verbindende weefsel tussen ICT-contracten, leveranciersrisico, onderaannemingsketens, clouddiensten, ICT-activa, kritieke functies, governance-eigenaarschap en ISO/IEC 27001:2022-bewijsmateriaal.

De aanpak van Clarysec is eenvoudig: bouw het DORA-informatieregister niet als afzonderlijk compliance-artefact. Bouw het als een levende bewijslaag binnen uw ISMS, ondersteund door beheer van bedrijfsmiddelen, leveranciersbeveiliging, governance van cloudgebruik, mapping van wettelijke en regelgevende verplichtingen, auditmetadata en traceerbaarheid van risicobehandeling.

Clarysec’s Zenith Controls: The Cross-Compliance Guide Zenith Controls identificeert drie ISO/IEC 27001:2022 Annex A-ankerbeheersmaatregelen als bijzonder relevant voor dit onderwerp: A.5.9, inventaris van informatie en andere gerelateerde bedrijfsmiddelen; A.5.19, informatiebeveiliging in leveranciersrelaties; en A.5.20, het adresseren van informatiebeveiliging binnen leveranciersovereenkomsten. Deze beheersmaatregelen zijn geen extra papierwerk. Zij vormen de operationele ruggengraat om aan te tonen dat het register volledig, toegewezen, actueel en auditeerbaar is.

Wat DORA verwacht van het informatieregister

DORA is van toepassing vanaf 17 januari 2025 en creëert een ICT-weerbaarheidskader voor de financiële sector voor ICT-risicobeheer, incidentrapportage, weerbaarheidstesten, risico’s van derde partijen, contractuele regelingen, toezicht op kritieke derde aanbieders van ICT-diensten en handhaving door toezichthouders. Voor financiële entiteiten die ook onder nationale NIS2-omzetting vallen, fungeert DORA als de sectorspecifieke rechtshandeling van de Unie voor overeenkomstige vereisten voor cyberbeveiligingsrisicobeheer en incidentrapportage.

De registerverplichting valt binnen de DORA-discipline voor ICT-risicobeheer van derde partijen. DORA Article 28 vereist dat financiële entiteiten ICT-risico’s van derde partijen beheren als onderdeel van het ICT-risicobeheerkader, volledig verantwoordelijk blijven voor naleving, ook wanneer zij ICT-aanbieders inschakelen, een informatieregister onderhouden voor contractuele regelingen voor ICT-diensten en onderscheid maken tussen regelingen die kritieke of belangrijke functies ondersteunen.

DORA Article 29 voegt aandachtspunten toe voor concentratie- en onderaannemingsrisico. Dit omvat vervangbaarheid, meerdere afhankelijkheden van dezelfde of verbonden aanbieders, onderaanneming in derde landen, beperkingen door insolventie, gegevensherstel, naleving van gegevensbescherming en lange of complexe onderaannemingsketens.

DORA Article 30 definieert vervolgens de contractuele inhoud die auditors verwachten te zien. Dit omvat dienstbeschrijvingen, voorwaarden voor onderaanneming, locaties voor gegevensverwerking, toezeggingen over gegevensbescherming, toegangs- en herstelverplichtingen, serviceniveaus, ondersteuning bij incidenten, samenwerking met autoriteiten, beëindigingsrechten, deelname aan training, auditrechten en exitstrategieën voor regelingen die kritieke of belangrijke functies ondersteunen.

Een volwassen DORA-informatieregister moet vier praktische vragen kunnen beantwoorden.

Een zwak register is een spreadsheet die inkoop eenmaal per jaar bijwerkt. Een sterk register is een beheerde dataset die de leveranciersportfolio, inventaris van bedrijfsmiddelen, cloudregister, contractrepository, privacyregistraties, bedrijfscontinuïteitsplannen, incidentdraaiboeken, risicoregister en ISO/IEC 27001:2022-bewijsmateriaal met elkaar verbindt.

Waarom ISO 27001 de snelste route is naar een verdedigbaar DORA-register

ISO/IEC 27001:2022 geeft organisaties de managementsysteemstructuur die DORA-bewijsmateriaal vaak mist. Clausules 4.1 tot en met 4.4 vereisen dat de organisatie context, belanghebbenden, wettelijke, regelgevende en contractuele verplichtingen, reikwijdte, interfaces en afhankelijkheden definieert. Precies daar hoort DORA thuis in het ISMS, omdat het register afhankelijk is van inzicht in welke financiële diensten, ICT-aanbieders, klanten, autoriteiten, cloudplatformen en uitbestede processen binnen de reikwijdte vallen.

Clausules 5.1 tot en met 5.3 vereisen leiderschap, afstemming op beleid, middelen, verantwoordelijkheden en rapportage aan het topmanagement. Dat is belangrijk omdat DORA Article 5 de verantwoordelijkheid bij het leidinggevend orgaan legt om het ICT-risicobeheerkader te definiëren, goed te keuren, te overzien en daarvoor aanspreekbaar te blijven, inclusief beleid voor ICT-diensten van derde partijen en rapportagekanalen.

Clausules 6.1.1 tot en met 6.1.3 zijn het punt waarop het register risicogebaseerd wordt. ISO/IEC 27001:2022 vereist een herhaalbaar risicobeoordelingsproces, risico-eigenaren, analyse van waarschijnlijkheid en gevolgen, risicobehandeling, selectie van beheersmaatregelen, een Verklaring van Toepasselijkheid en goedkeuring van restrisico door de risico-eigenaar. Een DORA-register dat niet aan risicobehandeling is gekoppeld, wordt een statische lijst. Een register dat is gekoppeld aan risicoscenario’s, beheersmaatregelen en eigenaren, wordt auditbewijsmateriaal.

Clausules 8.1 tot en met 8.3 zetten planning vervolgens om in beheerste uitvoering. Zij ondersteunen gedocumenteerde informatie, operationele planning en beheersing, wijzigingsbeheersing, beheersing van extern geleverde processen, geplande herbeoordelingen van risico’s, implementatie van behandelingen en bewaring van bewijsmateriaal. Dit is cruciaal voor 2026, omdat toezichthouders niet alleen vragen of er op enig moment een register bestond. Zij vragen of nieuwe contracten, gewijzigde diensten, nieuwe onderaannemers, migraties naar cloudgebaseerde systemen en exitgebeurtenissen in de governancecyclus worden vastgelegd.

De Annex A-laag met beheersmaatregelen versterkt hetzelfde punt. Leveranciersrelaties, leveranciersovereenkomsten, ICT-toeleveringsketenrisico, monitoring van leveranciersdiensten, verwerving en exit van clouddiensten, incidentbeheer, bedrijfscontinuïteit, wettelijke en regelgevende verplichtingen, privacy, back-ups, logging, monitoring, cryptografie en kwetsbaarhedenbeheer dragen allemaal bij aan de kwaliteit van het register.

Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint licht de basis van bedrijfsmiddelen toe in de fase Controls in Action, Step 22:

In zijn meest strategische vorm fungeert een inventaris van bedrijfsmiddelen als het centrale zenuwstelsel van uw ISMS. Deze bepaalt hoe toegang wordt verleend (8.2), waar encryptie moet worden toegepast (8.24), welke systemen back-ups vereisen (8.13), welke logboeken worden verzameld (8.15), en zelfs hoe classificatie- en bewaarbeleid worden afgedwongen (5.10, 8.10).

Dat citaat vat het praktische punt samen. U kunt geen betrouwbaar DORA-informatieregister onderhouden tenzij de onderliggende inventaris van bedrijfsmiddelen betrouwbaar is. Als uw register “Core Banking SaaS” vermeldt, maar uw inventaris van bedrijfsmiddelen geen API’s, serviceaccounts, datasets, logbronnen, encryptiesleutels, back-upafhankelijkheden en eigenaren toont, is het register vanuit auditperspectief onvolledig.

Het Clarysec-datamodel: één register, meerdere bewijsweergaven

Een DORA-informatieregister moet uw leveranciersregister, bedrijfsmiddelenregister of cloudregister niet vervangen. Het moet deze registraties verbinden. Clarysec ontwerpt het register doorgaans als een centrale bewijslaag met beheerste relaties naar bestaande ISMS-registraties.

Het minimaal werkbare model heeft zeven gekoppelde objecten.

Deze structuur maakt het mogelijk dat één register meerdere bewijsverzoeken ondersteunt. Een DORA-toezichthouder kan contractuele regelingen bekijken die kritieke of belangrijke functies ondersteunen. Een ISO-auditor kan leveranciersmaatregelen herleiden naar Annex A-verwijzingen en risicobehandeling. Een GDPR-beoordelaar kan verwerkers, gegevenscategorieën, locaties en toezeggingen over gegevensbescherming zien. Een NIST-georiënteerde beoordelaar kan governance van de toeleveringsketen, criticaliteit van leveranciers, contractuele eisen en levenscyclusmonitoring beoordelen.

Het register wordt meer dan “wie zijn onze leveranciers?” Het wordt een afhankelijkheidsgrafiek.

Beleidsfundamenten die het register auditeerbaar maken

De beleidsset van Clarysec geeft het register een operationele thuisbasis. Voor mkb-organisaties begint het Beleid inzake beveiliging door derde partijen en leveranciers - mkb Beleid inzake beveiliging door derde partijen en leveranciers - mkb met een duidelijke registereis:

Een leveranciersregister moet worden onderhouden en bijgewerkt door de administratieve of inkoopcontactpersoon. Het moet het volgende bevatten:

Ditzelfde mkb-beleid bepaalt dat contracten gedefinieerde beveiligingsverplichtingen moeten bevatten:

Contracten moeten verplichte bepalingen bevatten voor:

Hoewel de geciteerde bepalingen in het beleid zelf veldlijsten en verplichte categorieën van bepalingen introduceren, is de implementatieboodschap direct: leveranciersgovernance moet gedocumenteerd, toegewezen en contractueel afdwingbaar zijn.

Voor enterprise-omgevingen ligt Clarysec’s Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s nog dichter bij de verwachtingen van DORA-toezichthouders:

Register van leveranciersafhankelijkheden: de VMO moet een actueel register bijhouden van alle kritieke leveranciers, met gegevens zoals geleverde diensten/producten; of de leverancier een sole-source-situatie vormt; beschikbare alternatieve leveranciers of vervangbaarheid; actuele contractvoorwaarden; en een beoordeling van de impact als de leverancier zou uitvallen of worden gecompromitteerd. Het register moet leveranciers met hoge afhankelijkheid duidelijk identificeren (bijvoorbeeld leveranciers waarvoor geen snel alternatief bestaat).

Dit sluit nauw aan op DORA Article 29 over concentratie- en vervangbaarheidsrisico. Als een leverancier sole-source is, een kritieke functie ondersteunt, in een derde land opereert, een lange onderaannemingsketen gebruikt en geen getest exitpad heeft, mag het register dat risico niet verbergen in een vrije-tekstnotitie. Het moet het markeren, een eigenaar toewijzen en koppelen aan risicobehandeling.

Clarysec’s enterprise Beleid inzake beveiliging door derde partijen en leveranciers Beleid inzake beveiliging door derde partijen en leveranciers maakt de reikwijdte expliciet:

Het omvat zowel directe leveranciers als, waar van toepassing, hun onderaannemers, en omvat software van derden, infrastructuur, ondersteuning en managed services.

Die zin beschrijft een veelvoorkomend DORA-hiaat. Veel organisaties leggen directe ICT-aanbieders vast, maar documenteren geen onderaannemers, subverwerkers, tooling voor managed services, supportplatformen of software van derden die in een dienst is ingebed.

Ook contractbewijsmateriaal is van belang. Ditzelfde enterprise-beleid bevat:

Rechten om te auditen, te inspecteren en beveiligingsbewijsmateriaal op te vragen

Die formulering moet zichtbaar zijn in uw checklist voor contractbeoordeling. Als een contract met een kritieke ICT-aanbieder geen audit- of bewijsrechten bevat, moet het register een herstelmaatregel markeren.

Bewijsmateriaal over bedrijfsmiddelen is even belangrijk. Clarysec’s mkb-Beleid inzake beheer van bedrijfsmiddelen Beleid inzake beheer van bedrijfsmiddelen - mkb stelt:

De IT-verantwoordelijke moet een gestructureerde inventaris van bedrijfsmiddelen onderhouden die minimaal de volgende velden bevat:

Het enterprise-Beleid inzake beheer van bedrijfsmiddelen Beleid inzake beheer van bedrijfsmiddelen stelt op vergelijkbare wijze:

De inventaris van bedrijfsmiddelen moet minimaal het volgende bevatten:

Het register hoeft niet elk assetveld te dupliceren, maar moet wel verwijzen naar de inventaris van bedrijfsmiddelen. Als een SaaS-dienst voor betalingsmonitoring fraudedetectie ondersteunt, moet het DORA-register koppelen naar het applicatie-asset, dataset-asset, serviceaccounts, API-integraties, logbronnen en de bedrijfseigenaar.

Clouddiensten verdienen een eigen weergave. Clarysec’s mkb-Beleid inzake gebruik van cloudservices Beleid inzake gebruik van cloudservices - mkb vereist:

Een register van clouddiensten moet worden onderhouden door de IT-aanbieder of GM. Het moet vastleggen:

Dit is bijzonder waardevol voor het ontdekken van shadow IT. Een DORA-register dat clouddiensten uitsluit die buiten inkoop zijn aangeschaft, faalt op de praktische volledigheidstoets.

Tot slot maakt Clarysec’s Beleid inzake juridische en regelgevende naleving Beleid inzake juridische en regelgevende naleving van cross-compliance een ISMS-vereiste:

Alle wettelijke en regelgevende verplichtingen moeten binnen het Informatiebeveiligingsmanagementsysteem (ISMS) worden gekoppeld aan specifieke beleidslijnen, beheersmaatregelen en eigenaren.

Dat is de brug van het DORA-register naar ISO 27001-bewijsmateriaal. Het register moet niet alleen leveranciers tonen. Het moet tonen welke beleidslijnen, beheersmaatregelen en eigenaren aan de regelgevende verplichting voldoen.

DORA-vereisten koppelen aan ISO 27001 en Clarysec-bewijsmateriaal

De onderstaande tabel combineert de belangrijkste registerverwachtingen met ISO/IEC 27001:2022 Annex A-beheersmaatregelen en praktische Clarysec-bewijsartefacten.

Deze mapping is het punt waarop het register ophoudt een spreadsheet te zijn en een bewijsmodel wordt. Elke rij moet een contracteigenaar, leverancierseigenaar, service-eigenaar, bedrijfseigenaar en compliance-eigenaar hebben. Elke kritieke relatie moet een risicoregistratie, een checklist met contractuele bepalingen, een assetkoppeling en een monitoringcadans hebben.

Praktijkvoorbeeld: één ICT-contract koppelen aan ISO 27001-bewijsmateriaal

Stel dat een financiële entiteit een cloudgebaseerd platform voor fraudeanalyse gebruikt. De dienst neemt transactiemetadata op, ondersteunt realtime fraudescoring, integreert met het betaalplatform, slaat gepseudonimiseerde klantidentificatoren op, gebruikt een onderaannemer voor cloudhosting en levert managed support vanuit een goedgekeurde locatie in een derde land.

Een zwakke registerrij zegt: “Leverancier: FraudCloud. Dienst: fraudeanalyse. Contract ondertekend. Kritiek: ja.”

Een registerrij op toezichthoudersniveau ziet er heel anders uit.

Nu kan het compliance team een samenhangend bewijspakket opleveren. Het leveranciersregister toont aan dat de aanbieder bestaat en een eigenaar heeft. De inventaris van bedrijfsmiddelen toont aan dat de interne systemen, API’s, datasets en logboeken bekend zijn. De contractchecklist toont aan dat verplichte DORA-bepalingen zijn beoordeeld. De risicobeoordeling toont aan dat concentratie, onderaanneming, gegevensbescherming en operationele weerbaarheid zijn meegenomen. De Verklaring van Toepasselijkheid laat zien welke beheersmaatregelen zijn geselecteerd. De monitoringbeoordeling toont aan dat de regeling na onboarding niet is vergeten.

De Zenith Blueprint, fase Risk Management, Step 13, beveelt precies dit type traceerbaarheid aan:

Kruisverwijs regelgeving: als bepaalde beheersmaatregelen specifiek zijn geïmplementeerd om te voldoen aan GDPR, NIS2 of DORA, kunt u dat opnemen in het Risicoregister (als onderdeel van de onderbouwing van de risico-impact) of in de SoA-notities.

Zo wordt het DORA-register ISO 27001-bewijsmateriaal in plaats van parallelle bureaucratie.

De leveranciers- en onderaannemersketen is waar registerkwaliteit faalt

De grootste registertekortkomingen worden niet veroorzaakt door ontbrekende hoofdleveranciers. Ze worden veroorzaakt door verborgen afhankelijkheidsketens.

Een managed security provider kan gebruikmaken van een SIEM-platform, endpointtelemetrie-agent, ticketsysteem en offshore triageteam. Een betalingsverwerker kan afhankelijk zijn van cloudhosting, identiteitsdiensten, fraudedatabanken en settlementconnectiviteit. Een SaaS-aanbieder kan vertrouwen op meerdere subverwerkers voor analytics, e-mail, observability, klantenondersteuning en back-ups.

DORA Article 29 dwingt aandacht af voor concentratie- en onderaannemingsrisico. NIS2 Article 21 vereist ook beveiliging van de toeleveringsketen voor directe leveranciers en dienstverleners en verwacht dat entiteiten rekening houden met kwetsbaarheden die specifiek zijn voor elke directe leverancier, de algemene productkwaliteit, de cyberbeveiligingspraktijken van leveranciers en procedures voor veilige ontwikkeling. Voor financiële entiteiten die onder DORA vallen, fungeert DORA als het sectorspecifieke regelboek voor overlappende NIS2-vereisten voor cyberbeveiligingsrisicobeheer en incidentrapportage, maar de logica voor de toeleveringsketen is gelijkgericht.

Clarysec’s Zenith Blueprint, fase Controls in Action, Step 23, geeft praktische instructie:

Identificeer voor elke kritieke leverancier of zij onderaannemers (subverwerkers) gebruiken die toegang kunnen hebben tot uw gegevens of systemen. Documenteer hoe uw informatiebeveiligingseisen naar deze partijen doorstromen, hetzij via de contractvoorwaarden van uw leverancier, hetzij via uw eigen directe bepalingen.

Hier hebben veel organisaties in 2026 herstelmaatregelen nodig. Contracten die zijn ondertekend vóór de DORA-gereedheid bevatten mogelijk geen transparantie over onderaannemers, rechten op auditbewijsmateriaal, samenwerking met autoriteiten, ondersteuning bij incidenten, exitondersteuning of locatieverplichtingen. Het register moet daarom een status voor contractherstel bevatten, zoals voltooid, hiaat geaccepteerd, heronderhandeling loopt of exitoptie vereist.

Cross-compliance: DORA, NIS2, GDPR en NIST hebben dezelfde afhankelijkheidswaarheid nodig

Een goed ontworpen DORA-informatieregister ondersteunt meer dan alleen DORA.

NIS2 Article 20 maakt cyberbeveiliging een verantwoordelijkheid van het leidinggevend orgaan via goedkeuring, toezicht en training. Article 21 vereist risicoanalyse, beleidslijnen, incidentenafhandeling, continuïteit, beveiliging van de toeleveringsketen, veilige verwerving en onderhoud, beoordeling van doeltreffendheid, cyberhygiëne, cryptografie, HR-beveiliging, toegangscontrole, beheer van bedrijfsmiddelen en MFA waar passend. Deze gebieden overlappen sterk met ISO/IEC 27001:2022 en het bewijsmodel van het register.

GDPR voegt privacyverantwoordingsplicht toe. De territoriale reikwijdte kan van toepassing zijn op EU- en niet-EU-organisaties die persoonsgegevens verwerken in de context van EU-vestigingen, goederen of diensten aanbieden aan personen in de EU, of hun gedrag monitoren. GDPR-definities van verwerkingsverantwoordelijke, verwerker, verwerking, pseudonimisering en inbreuk in verband met persoonsgegevens zijn rechtstreeks relevant voor het in kaart brengen van ICT-leveranciers. Als het DORA-register ICT-aanbieders en onderaannemers identificeert, maar geen rollen bij verwerking van persoonsgegevens, gegevenscategorieën, locaties en waarborgen vastlegt, ondersteunt het geen GDPR-bewijsmateriaal.

NIST CSF 2.0 biedt een andere nuttige invalshoek. De GOVERN-functie vereist dat organisaties inzicht hebben in missie, verwachtingen van stakeholders, afhankelijkheden, wettelijke en contractuele eisen, diensten waarvan anderen afhankelijk zijn en diensten waarvan de organisatie afhankelijk is. De GV.SC-uitkomsten voor de toeleveringsketen vragen om een programma voor risicobeheer in de toeleveringsketen, gedefinieerde leveranciersrollen, integratie in enterprise riskmanagement, criticaliteit van leveranciers, contractuele eisen, due diligence, levenscyclusmonitoring, incidentcoördinatie en planning na beëindiging van de relatie.

Een praktische cross-complianceweergave ziet er als volgt uit.

Het doel is niet om vijf compliance-werkstromen te creëren. Het doel is één bewijsmodel te creëren dat per raamwerk kan worden gefilterd.

Door de ogen van de auditor

Een DORA-toezichthouder let op volledigheid, kritieke of belangrijke functies, contractuele regelingen, onderaanneming, concentratierisico, governance, rapportage en de vraag of het register wordt onderhouden. Hij kan om een steekproef van kritieke aanbieders vragen en verwachten contractuele bepalingen, risicobeoordelingen, exitstrategieën, voorwaarden voor incidentondersteuning en bewijsmateriaal van toezicht door het management te zien.

Een ISO/IEC 27001:2022-auditor begint bij de ISMS-reikwijdte, belanghebbenden, regelgevende verplichtingen, risicobeoordeling, Verklaring van Toepasselijkheid, operationele beheersing en gedocumenteerde informatie. De auditor toetst of leveranciersrelaties en inventarissen van bedrijfsmiddelen worden onderhouden, of extern geleverde processen worden beheerst, of wijzigingen herbeoordeling activeren en of bewijsmateriaal de geclaimde implementatie van beheersmaatregelen ondersteunt.

Een NIST CSF 2.0-beoordelaar vraagt vaak naar huidige en doelprofielen, governanceverwachtingen, afhankelijkheidsmapping, criticaliteit van leveranciers, contractintegratie, levenscyclusmonitoring en geprioriteerde verbeteracties.

Een op COBIT 2019 georiënteerde auditor onderzoekt doorgaans governance-eigenaarschap, procesverantwoordelijkheid, beslissingsrechten, prestatiemonitoring, risicorapportage en assurance. De auditor zal vragen of het register is ingebed in enterprise governance en niet alleen door compliance wordt onderhouden.

Zenith Controls helpt deze perspectieven te vertalen door het onderwerp te verankeren in ISO/IEC 27001:2022 Annex A-beheersmaatregelen A.5.9, A.5.19 en A.5.20, en vervolgens cross-compliance-interpretatie te gebruiken om activa, leveranciersrelaties en leveranciersovereenkomsten te verbinden met regelgevende, governance- en auditverwachtingen. Dit is het verschil tussen “wij hebben een register” en “wij kunnen het register verdedigen”.

Clarysec’s mkb-Beleid voor audit en toezicht op naleving Beleid voor audit en toezicht op naleving - mkb behandelt ook de kwaliteit van bewijsmateriaal:

Metadata (bijvoorbeeld wie het heeft verzameld, wanneer en uit welk systeem) moeten worden gedocumenteerd.

Die eis is klein, maar krachtig. Bij een bewijsverzoek in 2026 is een spreadsheet zonder verzamelmetadata zwak. Een registerexport met bronsysteem, extractiedatum, verantwoordelijke eigenaar, goedkeuringsstatus en beoordelingscadans is sterker.

Veelvoorkomende bevindingen rond het DORA-informatieregister in 2026

De meest voorkomende bevindingen zijn praktisch.

Ten eerste: onvolledigheid van het register. Clouddiensten, supporttools, monitoringplatformen, ontwikkelaarstools, ticketsystemen en data-analyseplatformen ontbreken vaak omdat zij door inkoop niet als ICT-diensten zijn geclassificeerd.

Ten tweede: zwakke criticaliteitslogica. Sommige teams markeren leveranciers als kritiek op basis van uitgaven, niet op basis van bedrijfsimpact. DORA kijkt of de ICT-dienst een kritieke of belangrijke functie ondersteunt.

Ten derde: hiaten in contractbewijsmateriaal. Oudere leveranciersovereenkomsten bevatten vaak geen DORA-gereed gemaakte bepalingen voor auditrechten, ondersteuning bij incidenten, onderaanneming, samenwerking met autoriteiten, dienstlocaties, teruggave van gegevens, beëindiging en exitondersteuning.

Ten vierde: gebrekkige koppeling aan bedrijfsmiddelen. Registers vermelden leveranciers, maar koppelen niet aan toepassingen, datasets, API’s, identiteiten, logboeken, infrastructuur of bedrijfsdiensten. Dit maakt impactanalyse moeilijk bij incidenten en leveranciersuitval.

Ten vijfde: ondoorzichtigheid van onderaannemers. De organisatie kent de hoofdaanbieder, maar kan niet uitleggen welke subverwerkers of technische aanbieders de dienst ondersteunen.

Ten zesde: geen wijzigingstriggers. Een aanbieder voegt een nieuwe subverwerker toe, wijzigt de hostingregio, migreert de architectuur of past supporttoegang aan, maar niemand werkt het register bij of beoordeelt het risico opnieuw.

Ten zevende: geen bewijscadans. Er is geen vastgestelde frequentie voor leveranciersbeoordeling, contractbeoordeling, validatie van bedrijfsmiddelen, reconciliatie van het cloudregister of managementrapportage.

Deze problemen zijn oplosbaar, maar alleen als het register eigenaren en workflows heeft.

Een praktisch verbeterplan voor 30 dagen

Begin met de reikwijdte. Identificeer alle bedrijfsfuncties die onder DORA kritiek of belangrijk kunnen zijn. Maak voor elke functie een lijst van de ICT-diensten waarvan zij afhankelijk is. Begin niet met inkoopuitgaven. Begin met operationele afhankelijkheid.

Reconcilieer de kerngegevensbronnen: leveranciersregister, contractrepository, inventaris van bedrijfsmiddelen en register van clouddiensten. Voeg waar relevant privacyverwerkersregistraties en afhankelijkheden voor incidentrespons toe. Het doel is niet perfectie op dag één. Het doel is één ruggengraat voor het register, waarbij onbekenden duidelijk zijn gemarkeerd.

Classificeer leveranciers en diensten aan de hand van criteria zoals ondersteunde functie, gevoeligheid van gegevens, operationele vervangbaarheid, concentratie, onderaanneming, locaties, incidentimpact, hersteltijd en regelgevende relevantie.

Beoordeel contracten voor elke kritieke of belangrijke ICT-regeling. Controleer of het contract dienstbeschrijvingen, voorwaarden voor onderaanneming, locaties, toezeggingen over gegevensbescherming, toegang en herstel, serviceniveaus, ondersteuning bij incidenten, auditrechten, samenwerking met autoriteiten, beëindiging, deelname aan training en exitondersteuning bevat.

Breng ISO-bewijsmateriaal voor elke kritieke regeling in kaart. Koppel naar assetregistraties, risicobeoordelingsvermeldingen, SoA-beheersmaatregelen, leveranciers-due diligence, monitoringbeoordelingen, continuïteitsplannen, incidentdraaiboeken en bewijsmateriaal voor exitstrategieën.

Wijs een cadans toe. Kritieke aanbieders kunnen een kwartaalbeoordeling, jaarlijkse assurance, contractbeoordeling vóór verlenging en onmiddellijke herbeoordeling bij materiële wijziging vereisen. Niet-kritieke aanbieders kunnen jaarlijks of bij triggergebeurtenissen worden beoordeeld.

Gebruik deze checklist om van het register een operationeel proces te maken:

• Stel een eigenaar en plaatsvervangend eigenaar van het DORA-register aan.
• Koppel elke registerrij aan een contract-ID en leverancierseigenaar.
• Koppel elke kritieke of belangrijke ICT-dienst aan een bedrijfsfunctie en assetregistraties.
• Voeg velden voor onderaannemers en subverwerkers toe, ook als deze aanvankelijk als onbekend zijn gemarkeerd.
• Voeg de status van contractuele bepalingen toe voor DORA-kritieke voorwaarden.
• Voeg ISO/IEC 27001:2022-risico- en SoA-verwijzingen toe.
• Voeg waar van toepassing GDPR-rol-, persoonsgegevens- en locatievelden toe.
• Voeg beoordelingscadans en metadata over de laatste beoordeling toe.
• Maak escalatieregels voor ontbrekende bepalingen, onbekende onderaannemers en hoog concentratierisico.
• Rapporteer kwaliteitsmetrieken van het register aan het management.

Hier werken Clarysec’s implementatiemethode in 30 stappen, beleidsset en Zenith Controls samen. De Zenith Blueprint geeft het implementatiepad, van risicobehandeling en SoA-traceerbaarheid in Step 13 tot inventaris van bedrijfsmiddelen in Step 22 en leveranciersmaatregelen in Step 23. De beleidslijnen definiëren wie registers moet onderhouden, welk contractueel en assetbewijsmateriaal moet bestaan en hoe compliance-metadata worden vastgelegd. Zenith Controls biedt het cross-compliancekompas om hetzelfde bewijsmateriaal te mappen naar auditverwachtingen voor DORA, ISO/IEC 27001:2022, NIS2, GDPR, NIST en COBIT 2019.

Maak van het register bewijsmateriaal voordat de toezichthouder erom vraagt

Als uw DORA-informatieregister nog steeds een spreadsheet is die losstaat van contracten, activa, leveranciers, onderaannemers en ISO 27001-bewijsmateriaal, dan is 2026 het jaar om dit te herstellen.

Begin met de Zenith Blueprint Zenith Blueprint om risicobehandeling, inventaris van bedrijfsmiddelen en leveranciersgovernance met elkaar te verbinden. Gebruik Zenith Controls Zenith Controls om ISO/IEC 27001:2022 Annex A-beheersmaatregelen A.5.9, A.5.19 en A.5.20 te mappen naar cross-compliancebewijsmateriaal. Operationaliseer vervolgens de vereisten via Clarysec’s beleidslijnen voor leveranciers, bedrijfsmiddelen, cloud, juridische naleving en auditmonitoring, waaronder Beleid inzake beveiliging door derde partijen en leveranciers - mkb, Beleid inzake beheer van leveranciersafhankelijkheidsrisico’s, Beleid inzake beveiliging door derde partijen en leveranciers, Beleid inzake beheer van bedrijfsmiddelen - mkb, Beleid inzake beheer van bedrijfsmiddelen, Beleid inzake gebruik van cloudservices - mkb, Beleid inzake juridische en regelgevende naleving en Beleid voor audit en toezicht op naleving - mkb.

Het beste moment om de kwaliteit van het register te herstellen is vóór een verzoek van een autoriteit, interne audit, leveranciersuitval of contractverlenging. Het op één na beste moment is nu. Download de relevante Clarysec-beleidslijnen, toets uw huidige register aan het bovenstaande bewijsmodel en plan een DORA-registerbeoordeling om versnipperde leveranciersgegevens om te zetten in bewijsmateriaal op toezichthoudersniveau.