Het DORA-register van informatie, zonder spreadsheetdrift

De verordening digitale operationele weerbaarheid (DORA) is sinds 17 januari 2025 van toepassing op financiële entiteiten in de EU. Van alles wat ze vraagt, is het register van informatie een van de meest concrete onderdelen: een gestructureerd overzicht van elke contractuele regeling die u hebt met derde aanbieders van ICT-diensten. Het klinkt als een inventarisoefening. In de praktijk test het of uw teams voor aankoop, IT, risico en business één beeld delen van wie wat ondersteunt.

Wat het register is

Artikel 28 van DORA verplicht financiële entiteiten om een register van informatie bij te houden en te actualiseren over alle contractuele regelingen voor het gebruik van ICT-diensten die door derde aanbieders van ICT-diensten worden geleverd. Het register wordt bijgehouden op het niveau van de entiteit en, voor groepen, op gesubconsolideerd en geconsolideerd niveau.

Het register dient verschillende doelgroepen. Intern is het de ruggengraat van het beheer van ICT-risico's door derden: u kunt geen concentratie-, exit- of onderaannemingsrisico beheren voor regelingen die u niet hebt opgelijst. Extern kunnen de bevoegde autoriteiten het volledige register opvragen, en entiteiten rapporteren regelmatig over nieuwe regelingen. Toezichthouders gebruiken registergegevens ook sectorbreed, onder meer als input voor de aanwijzing van kritieke derde aanbieders van ICT-diensten op EU-niveau.

Inhoud en formaat zijn vastgelegd in technische uitvoeringsnormen, als een reeks gekoppelde templates. De logica is relationeel, niet één platte lijst.

Wat het bevat, op hoofdlijnen

Beschouw het register als een geheel van verbonden feiten:

• De entiteiten binnen het toepassingsgebied, inclusief welke groepsentiteiten welke ICT-diensten gebruiken.
• De contractuele regelingen: elk contract met een derde aanbieder van ICT-diensten, de referentie, data, het toepasselijk recht, de opzegtermijnen en het type regeling.
• De aanbieders, consistent geïdentificeerd, met informatie over waar ze gevestigd zijn en hoe ze zich verhouden tot een groep.
• De ICT-diensten die onder elke regeling worden geleverd, beschreven per type.
• De functies van de financiële entiteit die door die diensten worden ondersteund, en of elke functie kritiek of belangrijk is.
• De toeleveringsketen: onderaannemers die ICT-diensten ter ondersteuning van kritieke of belangrijke functies daadwerkelijk dragen.
• Beoordelingen van die diensten, zoals vervangbaarheid, de impact van stopzetting en of een exit haalbaar is.

Het sleutelwoord is gekoppeld. Eén contract kan meerdere diensten dekken; één dienst kan meerdere functies ondersteunen; de kriticiteit van een functie bepaalt hoeveel informatie u moet bijhouden over de aanbieders erachter.

Waar registers misgaan

De meeste eerste registers werden onder tijdsdruk opgebouwd in een spreadsheet, gevoed met exports uit aankoop en e-mails aan businessverantwoordelijken. De problemen duiken daarna op.

De spreadsheet drijft weg van de contracten

Contracten worden het hele jaar door verlengd, gewijzigd en beëindigd. Als het register een apart bestand is dat door een apart team wordt bijgehouden, moet elke wijziging opgemerkt en overgetypt worden. Binnen enkele maanden komen opzegtermijnen, einddata en gegevens van aanbieders niet meer overeen met de ondertekende documenten.

Onderaannemers ontbreken of zijn verouderd

Informatie over de toeleveringsketen zit bij de aanbieder. Ze komt laat, in uiteenlopende formaten, en verandert wanneer de aanbieder zijn eigen leveranciers wijzigt. Registers vermelden de directe aanbieder vaak in detail en de onderaannemers helemaal niet, terwijl net daar het concentratierisico schuilt.

De koppeling met functies is vaag

ICT-diensten koppelen aan de functies die ze ondersteunen, vraagt input van mensen die het bedrijfsproces begrijpen, niet alleen het contract. Zonder gedeelde lijst van functies beschrijft elke bijdrager ze anders, en wordt "kritiek of belangrijk" een label dat op gevoel wordt toegekend in plaats van op basis van criteria. Dat ondermijnt de tiering, de exitplanning en de testprioriteiten.

Het eigenaarschap is onduidelijk

Aankoop is eigenaar van het contract, IT van de dienst, de business van de functie en risk van de beoordeling. Een register dat van iedereen is, wordt door niemand bijgehouden. Wanneer het eigenaarschap niet per veld expliciet is, blijven er gaten.

Het register staat los van al de rest

Dezelfde feiten komen voor in uw business impact analysis, continuïteitsplannen en outsourcingbeleid. Wanneer elk daarvan een eigen kopie heeft, spreken ze elkaar tegen.

Een verbonden model van leveranciers, contracten, diensten en functies

De duurzame oplossing is het register niet langer als een document te behandelen, maar als een weergave van gegevens die u toch al moet beheren. Dat betekent dat u de onderliggende objecten één keer modelleert en ze koppelt:

1. Leveranciers als records, met identificatoren, tiering en screeninghistoriek.
2. Contracten als records gekoppeld aan leveranciers, met levenscyclusdata, clausules, verplichtingen en serviceniveaus die actueel blijven als onderdeel van het gewone contractbeheer.
3. Diensten die onder die contracten worden geleverd, gekoppeld aan de assets waarop ze draaien.
4. Functies of processen, elk met hun impactanalyse en herstelobjectieven, gekoppeld aan de diensten en leveranciers waarvan ze afhangen.
5. Onderaannemers als volwaardige leveranciers, gekoppeld aan de diensten die ze dragen.

Met die structuur vloeit de kriticiteit van de functie naar de diensten en leveranciers erachter, in plaats van in een kolom te worden ingetypt. Een contractwijziging werkt het register bij omdat het register uit het contract leest. Gaten worden zichtbaar als ontbrekende koppelingen in plaats van lege cellen, en eigenaarschap kan per recordtype worden toegewezen.

Praktische gewoonten die met elke tool helpen:

• Spreek eerst de lijst van functies af. Een koppeling is maar zo goed als het vocabularium waarnaar ze verwijst.
• Leg uw kriticiteitscriteria vast en pas ze toe in de impactanalyse, niet in het register.
• Vraag aanbieders om informatie over onderaanneming bij onboarding en verlenging, en noteer wanneer u die het laatst ontving.
• Stem af op het ondertekende contract, niet op het aankoopsysteem, minstens voor regelingen die kritieke of belangrijke functies ondersteunen.
• Voer vóór elke indiening een kwaliteitscontrole uit: ontbrekende identificatoren, verlopen contracten die nog vermeld staan, functies zonder beslissing over kriticiteit.

Waar ILSERIS past

ILSERIS houdt derde partijen, contracten, assets, business impact analysis en herstelplannen bij als gekoppelde records in één datamodel. Contracten dragen hun levenscyclus, verplichtingen en serviceniveaus; leveranciers dragen tiering, vragenlijsten en periodieke screening; de impactanalyse draagt herstelobjectieven en een afhankelijkhedenkaart. Het register van informatie wordt dan een vraag die u stelt aan gegevens die toch al worden bijgehouden, in plaats van een spreadsheet die ernaast wordt bijgehouden.

Dit artikel is algemene informatie, geen juridisch advies.