DORA-rapportage voor het bestuur: indicatoren, bewijs en een dashboard

1. Begin bij de beslissingen die het bestuur moet nemen

Bestuursstukken kunnen alle verzamelde beveiligingsindicatoren bevatten en toch de belangrijkste vraag onbeantwoord laten: kan de organisatie klanten blijven bedienen als er iets misgaat? Een rapport voegt waarde toe wanneer het een wezenlijke onzekerheid blootlegt, een afweging uitlegt of een besluit over middelen, prioriteiten of risico ondersteunt.

Vraag: wat is er sinds de vorige vergadering veranderd? Welke klantgerichte dienst kan nu uitvallen met gevolgen die de organisatie niet kan aanvaarden? Welk besluit is vandaag nodig? Zet de antwoorden vóór de grafieken. Een bestuurder moet de noodzaak van dringende financiering niet uit een rode cel op pagina dertig hoeven afleiden.

Binnen het algemene ICT-risicobeheerkader gaat artikel 5 over de verantwoordelijkheid van het leidinggevend orgaan en regelmatige opleiding; artikel 6 over het risicobeheerkader en de evaluatie daarvan; artikel 13, lid 5, vereist dat hoger ICT-personeel minstens jaarlijks rapporteert over bepaalde bevindingen en aanbevelingen. Zie DORA, artikelen 5, 6 en 13.

Deze bepalingen schrijven geen goedgekeurd dashboard of universeel format voor maandelijkse bestuursstukken voor. Kies een frequentie die past bij uw risico’s en governance, met een escalatieroute voor dringende zaken tussen vergaderingen. Houd wettelijke rapportages, verzoeken van toezichthouders en interne managementrapportages uit elkaar. Deze gids biedt een praktische aanpak en vervangt niet de beoordeling van verplichtingen voor uw eigen organisatie. Lees voor de taakverdeling onze gids over DORA-verantwoordelijkheden voor de raad van bestuur.

2. Structureer het rapport rond diensten en bedrijfsimpact

Begin met een korte lijst van bedrijfsdiensten die bestuurders herkennen: een betaling uitvoeren, toegang krijgen tot een beleggingsrekening, een transactie afwikkelen of een verzekeringsclaim ontvangen. Koppel deze aan de beoordeling van kritieke of belangrijke functies. Vervang dit bedrijfsperspectief niet ongemerkt door een lijst applicaties. Eén dienst kan meerdere applicaties, teams, locaties en externe leveranciers nodig hebben.

Benoem voor elke dienst een verantwoordelijke aan de bedrijfskant en beschrijf de gevolgen van uitval. Vermeld getroffen klanten of transacties, kritieke deadlines, handmatige noodprocedures en het moment waarop achterstanden moeilijk weg te werken worden. Onderscheid gemeten gevolgen van schattingen. Is de klantentelling onvolledig, vermeld dan de onzekerheid in plaats van een schijnbaar exact totaal.

Een bruikbare regel per dienst verbindt risico en bewijs: het belangrijkste uitvalscenario, het hersteldoel, de recentste relevante test en de resterende zwakte. Een geslaagde databaserestauratie zegt weinig over de betaaldienst als identiteits- en toegangsbeheer, transactieafstemming en uitgaande verbindingen niet zijn getest.

Maak veranderingen zichtbaar. Een nieuwe leverancier, overname, productintroductie of migratie kan het dienstenoverzicht verouderen. Markeer de beoordeling als te actualiseren zodra een belangrijke afhankelijkheid verandert. Anders kan het rapport groen blijven terwijl het bewijs een bedrijfsmodel beschrijft dat niet meer bestaat.

Maak gedetailleerde technische inventarissen beschikbaar via links met toegangscontrole. De bestuurspagina moet gevolgen en besluiten uitleggen; de onderliggende documentatie moet controleurs in staat stellen beweringen te herleiden tot hun bronnen en verantwoordelijke teams.

3. Definieer elke indicator voordat u er een kleur aan geeft

Een percentage zonder noemer leidt gemakkelijk tot misverstanden. „Hersteltests voltooid: 90%” kan negen van tien geplande oefeningen, negen van tien bedrijfsdiensten of negen van tien applicaties betekenen. Dat zijn verschillende metingen. Zet de teller en noemer bij de indicator en vermeld wat is uitgesloten.

• Doel: het besluit of de risicovraag die de indicator helpt beantwoorden.
• Populatie: de inbegrepen diensten, systemen, aanbieders of mensen, plus uitsluitingen.
• Berekening: exact teller, noemer, eenheid en omgang met ontbrekende data.
• Verantwoordelijkheid: de verantwoordelijke aan de bedrijfskant, de gegevensaanleveraar en de beoordelaar.
• Timing: observatieperiode, extractiedatum, beoordelingsdatum en volgende update.
• Bewijs: het document of de registratie die het resultaat onderbouwt, met de versie en vastgelegde beheerregels.
• Escalatie: de intern overeengekomen drempel en de actie die bij een overschrijding wordt genomen.

Onderscheid „niet getest”, „test mislukt” en „bewijs ontbreekt”. Eén groene of oranje status voor alle drie verbergt wat nog moet gebeuren. Toon absolute aantallen naast percentages, zodat een kleine groep geen onterechte zekerheid geeft. Eén achterstallige actie die er twee worden is een verdubbeling, maar het belang hangt af van de betrokken dienst en de ernst.

Behoud vergelijkbaarheid. Indien de noemer toeneemt na een overname, toon zowel de nieuwe populatie als de reden voor de onderbreking. Interpreteer een lager voltooiingspercentage niet automatisch als verslechterde uitvoering zonder de scope te controleren.

4. Onderscheid hersteldoelen van aangetoonde prestaties

De beoogde hersteltijd (RTO) geeft aan binnen welke tijd een dienst of capaciteit na een verstoring hersteld moet zijn. Het beoogde herstelpunt (RPO) geeft aan hoeveel gegevensverlies aanvaardbaar is, uitgedrukt in tijd. Geen van beide bewijst dat herstel werkt. Rapporteer doel en waargenomen resultaat apart, met het scenario, de reikwijdte en de meetgrenzen.

Een RTO van vier uur betekent niet dat alleen het herstelcommando binnen vier uur klaar moet zijn en de transactieafstemming later mag volgen. Definieer wanneer de klok start en welke bedrijfsvoorwaarden het herstel voltooid maken. Noteer voor het RPO het recentste bruikbare herstelpunt en of de transactieafstemming de volledigheid bevestigde. Een systeem kan snel herstarten met te oude of onbetrouwbare gegevens.

Binnen het volledige kader beschrijft artikel 11(6) jaarlijkse tests van continuïteits- en herstelplannen voor alle functies en bij ingrijpende wijzigingen. Artikel 24(6) vereist jaarlijkse passende tests van alle ICT-systemen en applicaties die vitale of belangrijke functies ondersteunen, met uitzondering van micro-ondernemingen. Zie DORA’s testbepalingen. Controleer de reikwijdte voor uw organisatie voordat u deze eisen in een planning omzet.

Artikel 25 van Gedelegeerde Verordening 2024/1774koppelt continuïteitstests aan bedrijfsimpact- en risicoanalyses. Tekortkomingen moeten worden geanalyseerd, aangepakt en gemeld aan het leidinggevend orgaan. Koppel elk niet-behaald doel aan een verbeteractie, een verantwoordelijke en een plan voor een nieuwe test.

Houd dreigingsgestuurde penetratietests (TLPT) apart. Ze gelden voor aangewezen entiteiten, niet voor alle organisaties. Selectiecriteria en testvereisten staan in Gedelegeerde Verordening 2025/1190, naast DORA Artikelen 26–27. Een tabletop, kwetsbaarheidsscan of gewone penetratietest mag niet als TLPT worden aangeduid. Rapporteer welk type bewijs elke oefening daadwerkelijk oplevert.

5. Toon leveranciersconcentratie via dienstafhankelijkheden

Het aantal leveranciers zegt niet genoeg over concentratie. Drie leveranciers kunnen afhankelijk zijn van dezelfde cloudregio, hetzelfde identiteitsplatform of dezelfde telecomroute. Vraag bij elke belangrijke dienst welke afhankelijkheden tegelijk kunnen uitvallen en of het alternatief operationeel onafhankelijk is. Onderscheid contractuele alternatieven van alternatieven die daadwerkelijk zijn ingericht, bemand en getest.

De EBA-richtlijnen voor het informatieregister lichten het register van ICT-contractuele afspraken toe en bieden hulpmiddelen voor de rapportage. Gebruik het register als bron voor het bestuursrapport. Een compleet register is waardevol, maar het bestuur moet ook begrijpen wat de relaties betekenen voor de continuïteit van diensten.

Een compact overzicht kan de diensten van een leverancier tonen, de recentste verificaties, onopgeloste beperkingen, de geschatte overstaptijd en het volgende beslismoment. Presenteer die tijd als schatting totdat er een geloofwaardige onderbouwing is. Neem gegevensextractie, migratie, vaardigheden, contractuele beperkingen en de overgang voor klanten mee, niet alleen de vervanging van infrastructuur.

Stel een concrete vraag: als de leverancier niet meer beschikbaar of geschikt is, welke dienst dwingt ons dan als eerste tot actie en wat belemmert een ordelijke overstap? Escaleer ontbrekende informatie en onduidelijkheid over verantwoordelijkheden voor afhankelijkheden expliciet. Onze DORA-gids over risico’s van externe ICT-leveranciers werkt de vragen over leveranciers en contracten verder uit.

6. Leg incidenttrends uit en hoe lang onopgeloste risico’s blijven bestaan

Incidentaantallen hebben context nodig. Een stijging kan betere detectie betekenen in plaats van minder weerbaarheid. Een daling kan door een onvolledige gegevensstroom komen. Vermeld de definitie, observatieperiode, wezenlijke gevolgen voor diensten en eventuele wijzigingen in de gegevensverzameling. Houd interne ernstniveaus gescheiden van de wettelijke incidentclassificatie: een bestuursgrafiek mag het meldproces niet ongemerkt herdefiniëren.

Bruikbare gegevens zijn onder meer uitvalminuten per dienst, terugkerende oorzaken, mislukte wijzigingen, herstelresultaten en de tijd die belangrijke verbeteracties openstaan. Gebruik voor detectie- en reactietijden vaste start- en eindgebeurtenissen. Gemiddelden kunnen één langdurige verstoring verbergen: toon de spreiding of het belangrijkste afwijkende geval wanneer dat het besluit beïnvloedt.

Volg acties uit incidenten, tests, audits en leveranciersbeoordelingen in één overzicht, maar behoud hun bron. Elk item heeft een eigenaar, oorspronkelijke en huidige deadline, getroffen dienst, bewijs van afronding en een beoordelaar nodig. Een ticket met de status 'voltooid' betekent niet automatisch dat de achterliggende zwakte is verholpen.

Toon verlengingen en heropende acties. Door de deadline te verschuiven kan een achterstallig overzicht er beter uitzien zonder dat het risico verandert. Leg vast wie de verlenging goedkeurde, de reden, tijdelijke bescherming en het volgende beoordelingsmoment. Prioriteer de consequenties van de resterende zwakte boven het belonen van teams voor veel gesloten tickets met geringe impact.

Sluit de sectie af met een korte uitleg van het terugkerende probleem en de voorgestelde ingreep. Als meerdere incidenten dezelfde onduidelijke verantwoordelijkheid blootleggen, is een concreet operationeel besluit mogelijk nuttiger dan een nieuw dashboard.

7. Koppel opleidingsgegevens aan aangetoond beoordelingsvermogen

Een afgeronde opleiding bewijst deelname, maar niet dat bestuurders een optimistische herstelclaim kunnen toetsen of een moeilijke keuze tussen diensten kunnen maken. Combineer opleidingsgegevens met enkele praktijkoefeningen. Vraag deelnemers ontbrekend bewijs aan te wijzen, escalatiemomenten te kiezen en afwegingen bij een fictieve dienstverstoring uit te leggen.

Rapporteer wie de opleiding moet volgen, de toegewezen inhoud en versie, afrondingsdata, beoordelingsmethode en benodigde vervolgstappen. Registreer functiewijzigingen en nieuwe leden om de noemer correct te houden. Heeft iemand relevante ervaring, leg dan vast hoe die is meegewogen en welke kennis van de eigen organisatie nog ontbreekt.

Een gesprek over de opleiding kan laten zien dat deelnemers ransomware-termen kennen, maar niet weten wie nooduitgaven mag goedkeuren. De actie is dan concreet: verduidelijk de bevoegdheid, actualiseer het plan en oefen de toepassing. Presenteer een gemiddelde quizscore niet als maat voor de weerbaarheid van de hele organisatie.

Gebruik voor het opleidingsprogramma onze gids over DORA-opleidingseisen voor bestuurders. Voor de praktijk laat de gids voor een incidentresponsoefening met bestuurders zien hoe u een verstoring omzet in besluiten en vastgelegde leerpunten. Scherm individuele opleidingsgegevens voldoende af. Het bestuursrapport heeft doorgaans informatie over deelname, hiaten en vervolgacties nodig, niet de gedetailleerde antwoorden van elke deelnemer.

8. Een fictief bestuursdashboard met afwijkingen die actie vragen

Het volgende voorbeeld is volledig fictief. De cijfers zijn geen branchenormen, wettelijke drempels of bevindingen over een echte organisatie. Stel dat een financiële entiteit vier diensten voor dit rapport heeft gekozen. De stukken van september geven de stand op 30 september weer en noemen de verantwoordelijken voor het bewijs en de opvolging.

In dit voorbeeld is het doel voor gegevensverlies gehaald, maar het doel voor hersteltijd niet. Eén label „herstel geslaagd” zou de vertraging van de dienst verhullen. De testdekking gaat over diensten, niet over alle systemen die getest moeten worden. Het testregister moet die afzonderlijke reikwijdte behouden.

De tabel stelt een onbekend resultaat ook niet gelijk aan een mislukte test. Bestuurders zien welke onzekerheid onderzoek vereist en welke aangetoonde zwakte financiering nodig heeft. Koppel elke regel aan bewijs met vastgelegde beheer- en toegangsregels. Neem het besluit mee naar volgende bestuursstukken tot de uitkomst is geverifieerd.

9. Zet het rapport om in een herhaalbaar besluitvormingsproces

Gebruik een beknopt beslisverslag bij elke materiële uitzondering. Beschrijf de getroffen dienst, het scenario, beschikbaar bewijs en resterende onzekerheid. Geef realistische opties aan, hun kosten of inzet, het managementadvies en het gevolg van uitstel. Vermeld de bevoegde beslisser en de uiterste beslisdatum.

Voorbeeldbesluit: keur de voorgestelde verbetering van het herstel van de betaaldienst goed, met de operationeel directeur als verantwoordelijke voor de uitvoering. Vereis een nieuwe test tegen de afgesproken doelen uiterlijk op de overeengekomen datum. Leg tijdelijke maatregelen, resterend risico en escalatievoorwaarden vast. Presenteer resultaat en bewijs bij de volgende relevante commissievergadering.

Leg bij tijdelijke risicoacceptatie de onderbouwing, bevoegdheid, voorwaarden en einddatum vast. Acceptatie is een governancebesluit; zij heft een niet-nagekomen wettelijke verplichting niet op. Een algemene notitie dat het bestuur „kennis heeft genomen van het rapport” vertelt weinig over kritische vragen, alternatieven of opvolging.

1. Spreek af welke diensten in het rapport vallen en koppel deze aan de toepasselijke eisen en interne verantwoordelijkheden.
2. Begin met een beperkt aantal indicatoren en definieer deze voordat u de gegevensverzameling automatiseert.
3. Benoem verantwoordelijken voor gegevens en beoordelaars, met een peildatum en een expliciete aanpak voor ontbrekend bewijs.
4. Controleer een voorbeeldindicator aan de hand van de bron en ga na of de toelichting overeenkomt met het werkelijke resultaat.
5. Oefen met een fictieve afwijking en toets of de stukken een duidelijk besluit mogelijk maken.
6. Noteer het besluit, communiceer de actie en verifieer het effect in latere rapportages.

Begin met betrouwbare stukken die deelnemers kritisch kunnen beoordelen. Automatiseer de verzameling pas wanneer de definities stabiel zijn. Voor een gedeelde basis in bestuurlijk toezicht biedt de cursus «DORA-cybersecuritytraining voor bestuurders en directieleden» acht modules en ongeveer drie uur begeleide studie. Gebruik de cursus binnen een breder programma van organisatiespecifieke bespreking, oefening en opvolging. Afronding alleen bewijst geen naleving van de regelgeving.