DORA-stappenplan: van nul naar aantoonbaar

Aan DORA voldoen is geen project met een einddatum, maar de volgorde waarin u begint bepaalt wel hoeveel werk het wordt. Dit stappenplan volgt de logica van de verordening: eerst weten wat u heeft, dan beschermen, dan aantonen. Wie die volgorde omdraait, schrijft alles twee keer.

De meestgemaakte fout is beginnen bij het beleid. Een raamwerk opstellen voordat u weet welke functies kritiek zijn, levert een document op dat bij de eerste doorvraag omvalt. Begin bij uw eigen organisatie, niet bij de tekst van de verordening.

Stap 1: bedrijfsfuncties in kaart

Begin niet bij systemen maar bij wat u doet. Welke diensten levert u, wat merkt de klant als die stilvallen, en hoe lang is dat acceptabel?

Deze stap lijkt het minst technisch en is het meest bepalend. Alles wat erna komt hangt eraan: welke contracten de zware eisen nodig hebben, welke systemen jaarlijks getest moeten worden, welke herstelplannen er moeten liggen.

Leg per functie vast of die kritiek, belangrijk of overig is, met de onderbouwing erbij. Dat oordeel hoort bij het bestuur, niet bij de ICT-afdeling: het gaat over wat uw klant merkt, niet over hoe een systeem is gebouwd.

Resultaat: een overzicht van functies met een criticaliteitsoordeel en een bestuursbesluit eronder. Valkuil: niets kritiek noemen omdat dat minder werk lijkt. Dat houdt geen stand zodra iemand vraagt wat er gebeurt als de functie een week uitvalt.

Stap 2: de ICT eronder

Welke systemen, koppelingen en gegevens dragen die functies, en wie levert ze? Hier komen de verrassingen: diensten die niemand als ICT-dienst zag, koppelingen die ooit tijdelijk waren, afdelingen met een eigen abonnement op een creditcard.

Werk van functie naar systeem, niet andersom. Begint u bij de systeemlijst van de ICT-afdeling, dan mist u precies de diensten die buiten het zicht van die afdeling zijn afgesloten, en dat zijn er in de praktijk meer dan u denkt.

Neem ook de afhankelijkheden mee: welk systeem heeft welk ander systeem nodig, en waar loopt een koppeling via een partij die u niet als leverancier beschouwt. Een betaalkoppeling die via een tussenpartij loopt is een afhankelijkheid, ook als u daar geen factuur van krijgt.

Resultaat: een inventarisatie met een datum. Valkuil: hem één keer maken. Spreek nu al af wie hem bijhoudt en bij welke gebeurtenissen.

Stap 3: het informatieregister

Nu heeft u de basis om het informatieregister te vullen. Doe dit vroeg, ook als het nog niet compleet is.

Dat klinkt tegenstrijdig, maar een half gevuld register is stuurinformatie: het laat precies zien waar uw beeld gaten heeft. Welke contracten kunt u niet vinden, van welke leveranciers weet u de onderaannemers niet, waar ontbreekt de gegevenslocatie. Die lijst is uw werkvoorraad voor de maanden erna.

Resultaat: een eerste versie plus een lijst met ontbrekende gegevens en wie ze opvraagt.

Stap 4: gaten in beeld brengen

Leg uw huidige situatie naast de eisen en noteer waar u nog niet voldoet. Zie de gap-analyse voor de vragen per pijler.

Prioriteer op risico, niet op gemak. Een ontbrekende exitstrategie voor een kritieke dienst weegt zwaarder dan een ontbrekende paragraaf in een beleidsstuk, ook al is die paragraaf in een uur geschreven en kost de exitstrategie weken.

Noteer per gat drie dingen: wat ontbreekt, wat het risico is als het zo blijft, en wie het oppakt met welke termijn. Zonder die drie wordt het een lijst die een jaar later ongewijzigd wordt teruggevonden.

Stap 5: raamwerk en beleid

Nu pas schrijft u het raamwerk voor ICT-risicobeheer en het bijbehorende beleid. Op dit moment weet u waar het over gaat, en dat scheelt een herschrijving.

Houd het compact. Een toezichthouder beoordeelt of het klopt en of het leeft, niet of het dik is. Vijf documenten die kloppen en naar elkaar verwijzen zijn meer waard dan vijftien die elkaar tegenspreken.

Laat het bestuur het vaststellen, met een datum en een besluit dat terug te vinden is in de notulen. Een raamwerk zonder vaststellingsbesluit is formeel geen raamwerk.

Stap 6: contracten

Herzie de contracten, te beginnen bij de kritieke functies en bij de contracten die binnen een jaar aflopen. Dit is het onderdeel met de langste doorlooptijd, want u bent afhankelijk van de juridische afdeling aan de andere kant.

Start daarom vroeg, parallel aan stap 5, en wacht niet tot het beleid rond is. Gebruik voor de grote aanbieders hun eigen DORA-addendum als vertrekpunt; die bestaan inmiddels en schelen weken. Zie contractbepalingen en exitstrategie.

Stap 7: incidentproces

Richt één proces in voor registreren, classificeren en melden, met vooraf vastgelegde drempels en een aangewezen beslisser met plaatsvervanger.

Oefen het één keer met een fictief incident voordat u het nodig heeft. Dan weet u of het meldkanaal werkt, of de contactgegevens kloppen en of iemand om drie uur ’s nachts weet wat hij moet doen. Zie incidentmelding.

Stap 8: testen en bijstellen

Stel een testprogramma op dat past bij uw omvang, voer het uit en voer de bevindingen terug in het raamwerk. Begin met een herstelproef van één kritieke functie: die levert bijna altijd meer op dan een scanrapport.

Zonder aantoonbare opvolging is een testrapport eerder een bevinding dan een bewijs. Zie weerbaarheidstests.

Stap 9: het jaarritme

Vanaf hier is het onderhoud. Het raamwerk wordt jaarlijks herzien, het register bijgewerkt en ingediend, er wordt getest en bijgesteld, en het bestuur bespreekt het periodiek.

Leg dat ritme vast in een jaarkalender met eigenaren. Een DORA-implementatie die eindigt met een opgeleverd dossier en geen kalender, valt binnen een jaar uit elkaar.

Wat parallel kan en wat niet

Stap 1 en 2 zijn volgordelijk: zonder functies geen systemen. Stap 3 tot en met 5 kunnen elkaar overlappen. Stap 6 start u zo vroeg mogelijk omdat de doorlooptijd niet bij u ligt. Stap 7 en 8 kunnen naast elkaar lopen zodra het raamwerk staat.

Wie wacht tot alles intern klaar is voordat hij leveranciers benadert, verdubbelt de doorlooptijd. Zie hoe lang het duurt.

Veelgestelde vragen

Hoe lang duurt dit?

Dat hangt vooral af van wat er al ligt. Het zwaartepunt zit bijna altijd in stap 2 en stap 6, en die laatste bepaalt het kritieke pad omdat u daar van anderen afhankelijk bent.

Waar beginnen de meeste instellingen verkeerd?

Bij het beleid. Een raamwerk schrijven zonder te weten welke functies kritiek zijn levert een document op dat nergens op slaat, en dat merkt u pas als een toezichthouder doorvraagt.

Kunnen we stappen overslaan als we al ISO 27001 hebben?

Stap 1 en 2 heeft u dan grotendeels liggen, mits uw inventarisatie actueel is. Stap 3, 6 en 8 zijn de DORA-specifieke onderdelen en die moet u hoe dan ook doen.

Wie moet dit trekken?

Eén interne eigenaar met zicht op zowel de bedrijfsvoering als de ICT, en met mandaat om gegevens op te vragen. Vaak de risicomanager. Belangrijker dan de functie is dat het één persoon is met tijd.

Wanneer zijn we klaar?

Nooit helemaal, en dat is geen woordspel. De mijlpaal die telt: het moment waarop u elke vraag van uw toezichthouder met een document kunt beantwoorden in plaats van met een toelichting.