ICT-risicobeheer onder DORA: het raamwerk in de praktijk

De eerste pijler van DORA vraagt om een raamwerk voor ICT-risicobeheer: een samenhangend geheel van beleid, procedures en middelen waarmee u ICT-risico’s beheerst. Het is het fundament waar de andere vier pijlers op rusten, en het onderdeel waarmee elk DORA-traject hoort te beginnen.

Het raamwerk moet gedocumenteerd zijn, ten minste jaarlijks worden herzien, en worden bijgesteld na majeure incidenten en naar aanleiding van testresultaten. Dus geen eenmalig project, maar iets wat meebeweegt met uw organisatie.

De vier functies

DORA volgt een indeling die u herkent uit gangbare beveiligingsraamwerken. Elke functie beantwoordt een eigen vraag.

Identificeren: wat heeft u eigenlijk?

Weten welke bedrijfsfuncties u heeft, welke informatiemiddelen en systemen die ondersteunen, en welke afhankelijkheden daarin zitten. In de praktijk is dit het meeste werk, en het is de stap die het vaakst wordt overgeslagen omdat hij weinig zichtbaar oplevert.

Toch bepaalt deze stap alles wat erna komt. Zonder actueel overzicht kunt u niet onderbouwen welke functies kritiek zijn, kunt u het informatieregister niet vullen en kunt u niet beoordelen welke contracten de zware eisen nodig hebben.

Wat erbij hoort: een inventarisatie van systemen en gegevens, de koppelingen ertussen, de leveranciers erachter, en een classificatie van bedrijfsfuncties naar kritiek, belangrijk of overig. Dat laatste oordeel ligt bij het bestuur.

Beschermen en voorkomen

Beleid en maatregelen die de kans op een incident verkleinen en de gevolgen beperken. Denk aan toegangsbeheer met meervoudige verificatie, netwerkscheiding, versleuteling van gegevens in rust en onderweg, wijzigingsbeheer, en het scheiden van ontwikkel-, test- en productieomgevingen.

DORA schrijft geen specifieke techniek voor. Wat het wel vraagt is dat uw keuzes voortkomen uit uw risicobeeld en dat u ze kunt uitleggen. Een maatregel die er is omdat hij in een template stond, houdt geen stand.

Detecteren

Mechanismen om afwijkend gedrag en incidenten tijdig op te merken, met voldoende logging om achteraf te kunnen reconstrueren wat er is gebeurd. Dit is het onderdeel waar veel instellingen het zwakst staan: er wordt wel gelogd, maar niemand kijkt ernaar, of de logging gaat zo kort terug dat een incident van vorige maand niet meer te reconstrueren is.

Stel uzelf de praktische vraag: als iemand vanochtend met gestolen inloggegevens had ingelogd, hadden we dat dan gezien, en hoe lang daarna?

Herstellen en leren

Continuïteitsbeleid, herstelplannen per kritieke functie, back-ups die u ook echt heeft teruggezet, en een proces om lessen uit incidenten terug te voeren in het raamwerk.

Hersteldoelstellingen horen hier concreet te zijn: hoe snel moet een functie weer draaien en hoeveel gegevensverlies is acceptabel. Die getallen zijn een bestuurlijke keuze, geen technische. En ze zijn pas iets waard als u ze een keer heeft gemeten.

Het bestuur is eindverantwoordelijk

DORA legt de verantwoordelijkheid expliciet bij het leidinggevend orgaan. Het bestuur stelt het raamwerk vast, keurt het beleid voor het gebruik van ICT-diensten van derden goed, bepaalt de risicobereidheid en wordt geïnformeerd over majeure incidenten. Ook moet het zijn kennis op peil houden.

Dat is geen formaliteit. Het betekent dat digitale weerbaarheid een agendapunt is met een eigenaar aan de bestuurstafel, en dat een toezichthouder kan vragen hoe u tot uw oordeel bent gekomen. Zie wat DORA van het bestuur vraagt.

Het vereenvoudigde raamwerk

Voor bepaalde kleinere entiteiten staat een lichter regime open. De verwachtingen zijn dan minder formeel en de documentatielast lager, maar de kern blijft: u weet wat u heeft, u beschermt het, u merkt het als er iets misgaat en u kunt herstellen. Zie het vereenvoudigde raamwerk.

Waar het in de praktijk misgaat

• Beleid zonder inventarisatie. Er is een mooi raamwerk, maar geen actueel overzicht van systemen en afhankelijkheden. Bij de eerste doorvraag valt het om
• Back-ups die nooit zijn teruggezet. Ze bestaan, ze draaien, en niemand weet hoe lang een herstel duurt. Dat getal blijkt bij een echte storing steevast hoger dan het plan
• Een raamwerk dat stilstaat. Eén keer opgesteld, daarna niet meer aangeraakt, terwijl de systemen wel zijn veranderd
• Incidenten zonder terugkoppeling. Ze worden opgelost maar niet verwerkt in het risicobeeld, waardoor dezelfde oorzaak zich blijft herhalen
• Hersteldoelstellingen die niemand heeft vastgesteld. Of erger: doelstellingen die de ICT-afdeling heeft bedacht zonder dat de business ze kent

Hoe u het opbouwt

Een werkbare volgorde: begin bij de bedrijfsfuncties en het criticaliteitsoordeel, breng daarna de systemen en afhankelijkheden in kaart, stel dan pas het beleid op, en toets het met een test. Zie het stappenplan.

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

Veelgestelde vragen

Kan ik hiervoor mijn ISO 27001-systeem gebruiken?

Voor een groot deel wel. Een ISMS levert het beleid, de risicoanalyse, het wijzigingsbeheer en de incidentafhandeling. Wat u aanvullend moet regelen zit vooral in de DORA-specifieke onderdelen: het informatieregister, de meldketen naar de toezichthouder en het testprogramma met aantoonbare opvolging.

Hoe vaak moet het raamwerk worden herzien?

Ten minste jaarlijks, en daarnaast na majeure incidenten en naar aanleiding van bevindingen uit tests of toezicht. De aanleiding is daarbij even belangrijk als de frequentie: een herziening die alleen op de kalender staat, mist de gebeurtenissen die er echt toe doen.

Wie stelt vast welke functies kritiek zijn?

Het bestuur, op basis van wat de klant merkt als de functie uitvalt en hoe lang dat acceptabel is. Het is uitdrukkelijk geen technische beoordeling; de ICT-afdeling levert de feiten, het bestuur velt het oordeel.

Moeten hersteldoelstellingen per systeem of per functie?

Per functie, want dat is wat de klant merkt. Vervolgens vertaalt u dat naar eisen aan de systemen die de functie dragen. Andersom werken leidt tot doelstellingen die technisch haalbaar zijn maar bedrijfsmatig niets betekenen.