DORA voor aanbieders van cryptoactivadiensten

Aanbieders van cryptoactivadiensten vallen onder DORA. Voor deze sector komt dat vaak samen met een MiCA-vergunningtraject, waardoor twee nieuwe regimes tegelijk landen bij organisaties die vaak nog jong zijn en snel groeien.

Waarom dit hier anders ligt

Bij een bank zit het risico vooral in systemen die transacties verwerken. Bij een cryptodienstverlener zit het daarnaast in sleutelbeheer: wie kan bij de private keys, hoe zijn die opgeslagen, wat gebeurt er als die toegang wegvalt of uitlekt.

Dat is tegelijk een beveiligings-, een continuïteits- en een bewaarvraagstuk. Verliest u sleutels, dan is er geen herstelprocedure en geen verzekeraar die het terugdraait. Die onomkeerbaarheid maakt hersteldoelstellingen hier scherper dan elders.

Daar komt bij dat veel van de infrastructuur buiten uw invloed ligt: publieke blockchains, externe liquiditeitsaanbieders, custodians, bridges en orakels. DORA dwingt u die afhankelijkheden te benoemen in plaats van ze als gegeven te beschouwen.

Wat DORA concreet vraagt

• Een raamwerk voor ICT-risicobeheer waarin sleutelbeheer en toegangsbeheer expliciet zijn belegd
• Registratie en classificatie van incidenten, van een mislukte transactie tot een beveiligingsinbreuk; zie incidentclassificatie
• Testen van uw weerbaarheid, inclusief herstel na verlies van een kritiek systeem; zie weerbaarheidstests
• Een informatieregister met uw custodians, exchanges en infrastructuurpartijen
• Contracten met die partijen die aan de DORA-eisen voldoen; zie contractbepalingen

Afhankelijkheden zonder contractpartij

Een publieke keten heeft geen contractpartij, dus hij past niet in het register zoals een leverancier dat doet. De afhankelijkheid hoort wel thuis in uw risicoanalyse en uw continuïteitsplan.

De vragen die u moet kunnen beantwoorden: wat doet u bij netwerkcongestie, wat bij een splitsing van de keten, wat als een bridge wordt gecompromitteerd, en hoe informeert u klanten als afwikkeling vertraagt. Dat is precies het soort scenario dat zich leent voor een tafeloefening.

Snelle groei als risicofactor

Veel partijen in deze sector zijn in korte tijd gegroeid, met systemen die meegroeiden zonder dat de documentatie dat deed. DORA dwingt dat recht te zetten: een actuele inventarisatie, vastgelegde toegangsrechten en een raamwerk dat het bestuur heeft vastgesteld.

Dat voelt als rem, maar het is ook de fase waarin de meeste instellingen ontdekken dat niemand meer precies wist welke sleutels waar stonden en wie er toegang toe had.

DORA naast MiCA

MiCA gaat over de vergunning, de informatieverstrekking, marktmisbruik en de bescherming van houders. DORA gaat over de weerbaarheid van uw ICT. Ze overlappen op één punt: MiCA stelt ook eisen aan de bewaring en de bedrijfsvoering, en DORA vult in hoe u de digitale kant daarvan aantoonbaar maakt.

Praktisch loont het om beide trajecten door dezelfde mensen te laten doen, want de inventarisatie die MiCA vraagt is voor een groot deel dezelfde als die DORA vraagt.

Veelgestelde vragen

Geldt DORA ook zonder MiCA-vergunning?

DORA richt zich op gereguleerde financiële entiteiten. Bent u vergunningplichtig onder MiCA, dan valt u onder DORA. Opereert u buiten dat kader, dan gelden eerder algemene regels zoals NIS2; zie de vergelijking.

Valt een publieke blockchain onder mijn derdepartijrisico?

Niet als contractpartij, wel als afhankelijkheid. Leg hem vast in uw risicoanalyse en uw continuïteitsplan.

Hoe gaan we om met sleutelbeheer in het raamwerk?

Als een eigen onderdeel, met vastgelegde rollen, meervoudige controle, en een uitgewerkt scenario voor verlies of compromittering. Het is het punt waar een toezichthouder als eerste naar vraagt.