De zeven meestgemaakte fouten bij een DORA-implementatie

De meeste DORA-trajecten lopen niet vast op de techniek maar op de volgorde en op aannames die nooit zijn getoetst. Zeven patronen die telkens terugkomen, met per stuk waarom het misgaat en wat u in plaats daarvan doet.

1. Beginnen bij het beleid

Wat er gebeurt. Iemand leest de verordening, ziet dat er een raamwerk moet komen, en begint te schrijven. Er ligt binnen een maand een net document.

Waarom het misgaat. Een raamwerk schrijven voordat u weet welke functies kritiek zijn, levert een document op dat nergens op slaat. Bij de eerste vraag van een toezichthouder, “waarom heeft u deze functie als belangrijk aangemerkt”, valt het om. En dan schrijft u het opnieuw, nu met de inventarisatie erbij.

Wat wel werkt. Begin bij uw bedrijfsfuncties en het criticaliteitsoordeel. Het beleid komt in stap 5, niet in stap 1. Zie het stappenplan.

2. Niets kritiek noemen

Wat er gebeurt. Bij het criticaliteitsoordeel blijkt dat “kritiek” zware contractbepalingen, een exitstrategie en jaarlijkse tests meebrengt. De verleiding om alles als “overig” te bestempelen is groot, en de argumenten klinken redelijk.

Waarom het misgaat. Het houdt precies één vraag stand. Zodra iemand vraagt wat er gebeurt als deze dienst een week uitvalt, en het antwoord is dat uw dienstverlening stilligt, dan was de functie kritiek. Dat is een zwaardere bevinding dan een ontbrekend document, want het raakt uw oordeelsvorming.

Wat wel werkt. De toets: wat merkt de klant, hoe lang is dat acceptabel, en kan het de krant halen. Twee keer ja betekent kritiek. Leg de redenering vast, ook bij een “nee”.

3. Het register als rapportage behandelen

Wat er gebeurt. Het register wordt één keer gevuld door een projectteam, ingediend, en daarna losgelaten.

Waarom het misgaat. Het jaar erop klopt de helft niet meer: contracten zijn gewijzigd, leveranciers hebben andere onderaannemers, er zijn diensten bijgekomen. U begint opnieuw, en ondertussen heeft u een jaar lang gestuurd op verkeerde informatie.

Wat wel werkt. Richt het informatieregister in als administratie die u zelf gebruikt, gekoppeld aan het moment waarop contracten worden afgesloten of gewijzigd. Dan is indienen een bijproduct.

4. De keten stopt bij de eerste laag

Wat er gebeurt. U weet wie uw leverancier is en legt dat netjes vast. Bij wie die zijn rekencapaciteit inkoopt, of welke partij de authenticatie verzorgt, blijft buiten beeld.

Waarom het misgaat. Voor kritieke functies moet u die keten kennen, en u hoort er anders pas van als het misgaat. Bovendien zit daar vaak het echte concentratierisico: drie verschillende leveranciers die alle drie op dezelfde infrastructuur draaien, is geen spreiding.

Wat wel werkt. Vraag het op en leg de verplichting contractueel vast. Krijgt u het niet, dan is dat op zichzelf informatie die u vastlegt en beoordeelt.

5. Een exitstrategie die niemand heeft doorgerekend

Wat er gebeurt. Er ligt een plan waarin staat dat u binnen twee weken kunt migreren naar een alternatieve leverancier.

Waarom het misgaat. Niemand heeft ooit gemeten hoe lang een volledige gegevensexport duurt, of het formaat bruikbaar is, en of het alternatief uw volume aankan. Bij de eerste echte test blijkt twee weken twee maanden.

Wat wel werkt. Doe een proef, al is het een deelexport met een stopwatch. En als er geen reëel alternatief is: schrijf dat op, met compenserende maatregelen. Een eerlijk risico dat het bestuur heeft geaccepteerd, is verdedigbaar. Zie exitstrategie.

6. Classificeren tijdens het incident

Wat er gebeurt. Er is een storing, het team is aan het herstellen, en iemand vraagt of dit gemeld moet worden. Dan begint de discussie over wat “majeur” betekent.

Waarom het misgaat. De termijn loopt door terwijl u discussieert. Bovendien is de beoordeling op dat moment gekleurd: niemand wil midden in een storing concluderen dat het ook nog eens meldplichtig is.

Wat wel werkt. Leg de drempels vooraf vast, vertaald naar uw eigen omvang, en wijs een beslisser met plaatsvervanger aan. Dan is classificeren tijdens een incident een controle in plaats van een discussie. Zie incidentclassificatie.

7. Testen zonder opvolging

Wat er gebeurt. Er wordt jaarlijks getest, er komt een rapport, en dat rapport wordt gearchiveerd.

Waarom het misgaat. Een testrapport zonder bevindingenregister, eigenaren en termijnen is voor een toezichthouder geen bewijs maar een bevinding: u heeft immers zwart op wit dat u een zwakte kent en er niets mee heeft gedaan. Dat is slechter dan niet testen.

Wat wel werkt. Elke bevinding krijgt een eigenaar, een termijn en een plek in het risicobeheerraamwerk. En het bestuur ziet de openstaande bevindingen, niet alleen het rapport.

De rode draad

Zes van de zeven fouten komen voort uit hetzelfde: iets opschrijven zonder het te toetsen. Een raamwerk zonder inventarisatie, een oordeel zonder onderbouwing, een register zonder onderhoud, een exitplan zonder proef, een drempel zonder besluit, een test zonder opvolging.

De goedkoopste manier om dat te voorkomen is één keer per onderwerp de vraag stellen: hoe weten we dat dit klopt? Kan niemand die vraag beantwoorden, dan is het een aanname en hoort het als zodanig vastgelegd.

Veelgestelde vragen

Welke fout kost de meeste tijd?

De eerste. Beleid dat op verkeerde aannames staat, schrijft u twee keer, en de tweede keer moet u ook nog uitleggen waarom het eerst anders was.

En welke is het gevaarlijkst?

De tweede. Alles te licht classificeren voelt efficiënt tot er iets uitvalt en blijkt dat er geen herstelplan is voor precies die functie.

Wij hebben al ISO 27001, lopen wij deze risico’s ook?

Vooral nummer 3, 4 en 5. Het register, de keten en de exitstrategie zijn de onderdelen die ISO 27001 niet in deze vorm kent, en dat zijn precies de plekken waar gecertificeerde organisaties zich verkijken.

Hoe merken we op tijd dat we in een van deze valkuilen zitten?

Laat iemand van buiten het traject de gap-analyse tegenlezen. Alle zeven fouten zijn van binnenuit onzichtbaar, want ze voelen op het moment zelf als een verstandige keuze.