> For the complete documentation index, see [llms.txt](https://docs.stoik.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.stoik.io/help/help-nl/onboarding/compliance/dora.md). # DORA Sinds 17 januari 2025, **de Digital Operational Resilience Act (DORA, Verordening (EU) 2022/2554)** verplicht financiële entiteiten in de EU aan te tonen dat zij ICT-incidenten kunnen weerstaan, erop kunnen reageren en ervan kunnen herstellen. DORA vraagt je niet om een specifieke tool te kopen. Het vraagt je om maatregelen te hebben **en dat aan te tonen**. Stoïk Protect helpt bij beide: de tools dekken verschillende technische vereisten af en leveren het bewijs (rapporten, historie, voltooiingspercentages) dat auditors en toezichthouders verwachten. Dit artikel laat zien bij welke DORA-vereisten elke Stoïk Protect-tool helpt, en wat jouw verantwoordelijkheid blijft. {% hint style="info" %} Stoïk Protect heeft een speciale **NIS2** beoordeling in het **Naleving** tabblad. Er is nog geen DORA-beoordeling in het product. DORA en NIS2 overlappen sterk op technische maatregelen, en voor financiële entiteiten vervangt DORA de equivalente NIS2-vereisten (NIS2, art. 4). Daarom is de NIS2-beoordeling nog steeds een handig startpunt voor een gap-analyse. {% endhint %} ## Voor wie is DORA van toepassing? DORA geldt voor de meeste gereguleerde financiële entiteiten: banken, betaal- en elektronisch-geldinstellingen, beleggingsondernemingen, vermogensbeheerders, verzekeraars en herverzekeraars, aanbieders van cryptoactivadiensten en andere. Sommige entiteiten zijn **vrijgesteld**. De belangrijkste vrijstelling geldt voor verzekerings- en herverzekeringsbemiddelaars die micro-ondernemingen, kleine of middelgrote ondernemingen zijn (art. 2, lid 3). Kleinere entiteiten binnen de reikwijdte kunnen ook een **vereenvoudigd kader voor ICT-risicobeheer** toepassen (art. 16). Als je niet zeker weet of DORA op jou van toepassing is, vraag het dan aan je compliance officer of je toezichthouder (ACPR of AMF in Frankrijk). ## Hoe Stoïk Protect aansluit op DORA DORA heeft vijf pijlers. Stoïk Protect draagt bij aan vier daarvan. ### 1. ICT-risicobeheer (hoofdstuk II, artikelen 5 tot en met 16) Deze pijler vraagt je je activa te kennen, kwetsbaarheden te vinden, je systemen te beschermen, afwijkingen te detecteren en je mensen op te leiden. | Stoïk Protect-tool | DORA-vereiste waar het bij helpt | Bewijs dat je kunt tonen | | -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | **Externe scan** | Inventaris van ICT-activa die vanaf internet bereikbaar zijn (art. 8(1), 8(4)). Doorlopende identificatie van kwetsbaarheden en cyberdreigingen (art. 8(2)). Monitoring van ICT-systemen (art. 9(1)). | Gedateerde scanrapporten en een geschiedenis van kwetsbaarheden en hun oplossingen | | **Active Directory-scan** | Toegang beperkt tot wat elke rol nodig heeft (art. 9(4)(c)). Sterke authenticatie (art. 9(4)(d)). Detectie van geprivilegieerde, slapende of verkeerd geconfigureerde accounts. | AD-configuratierapport en een geprioriteerde lijst van bevindingen met opvolging van herstelmaatregelen | | **Cloudscan** (AWS, Azure, GCP) | Beveiliging en veerkracht van systemen, en voorkoming van ongeautoriseerde toegang en datalekken (art. 9(2), 9(3)). Detectie van verkeerd geconfigureerde instellingen aan jouw kant van de cloud, waarvoor jij volledig verantwoordelijk blijft (art. 28(1)). | Cloud-posture-rapport per omgeving | | **Monitoring van inloggegevens** | Bescherming tegen ongeautoriseerde toegang (art. 9(3)(b)). Detectie van gecompromitteerde accounts voordat ze worden gebruikt (art. 10(1)). | Lijst van gedetecteerde gelekte inloggegevens en geroteerde wachtwoorden | | **Email Security** | Beveiliging van datatransferkanalen (art. 9(3)(a)). Minder risico op ongeautoriseerde toegang en fraude (art. 9(3)(b)). | Statistieken over geblokkeerde dreigingen | | **MDR** | 24/7 detectie van afwijkende activiteit op endpoints (art. 10(1)). Voldoende middelen om afwijkingen en cyberaanvallen te monitoren (art. 10(3)). Snelle inperking (art. 11(2)). | Activiteitsrapporten, afgehandelde alerts, responstijden | | **XDR** | Meerdere lagen van controle, alertdrempels en automatische waarschuwingen (art. 10(2)), over VPN-, firewall- en cloudgegevens heen. | Detectieregels en alertgeschiedenis | | **Training** | Verplichte bewustwording van ICT-beveiliging voor alle medewerkers (art. 13(6)). Regelmatige training van het leidinggevend orgaan (art. 5(4)). | Voltooiingspercentages en cursuscertificaten | | **Phishingsimulatie** | Bewustwordingsprogramma's (art. 13(6)). Leren van waargenomen dreigingen (art. 13(1)). | Klik-, indienings- en meldingspercentages per campagne, met trends in de tijd | ### 2. Beheer en rapportage van ICT-incidenten (hoofdstuk III, artikelen 17 tot en met 23) | Stoïk-dienst | DORA-vereiste waar het bij helpt | Bewijs dat je kunt tonen | | ----------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | **MDR / XDR** | Detecteren en loggen van incidenten (art. 17(2), 17(3)). Vroegtijdige detectie is belangrijk omdat de rapportagetermijnen van DORA ingaan vanaf het moment dat het incident wordt geclassificeerd. | Alert- en incidentgeschiedenis | | **Phishingmeldknop** | Een eenvoudige manier voor medewerkers om verdachte e-mails te melden, die je proces voor incidentdetectie voedt (art. 17(3)). | Gemelde e-mails en hoe ermee is omgegaan | | **Stoïk CERT** (24/7 incidentrespons, inbegrepen bij Stoïk-verzekering) | Reactie en herstel (art. 11). Evaluatie na het incident en analyse van de grondoorzaak (art. 13(2)). Technische input voor rapporten over grote incidenten (art. 19(4)): eerste kennisgeving, tussentijds rapport en eindrapport. | Incidentrapport met tijdlijn, indicatoren van compromittering, grondoorzaak en genomen maatregelen | ### 3. Testen van digitale operationele veerkracht (hoofdstuk IV, artikelen 24 tot en met 27) DORA vereist een testprogramma, dat minstens één keer per jaar wordt beoordeeld, en dat uitdrukkelijk omvat **kwetsbaarheidsbeoordelingen en scans** (art. 25(1)). * **Externe Scan, Active Directory Scan en Cloud Scan** geven je terugkerende kwetsbaarheidsbeoordelingen die dit programma voeden (art. 24(6), 25(1)). * **Phishingsimulaties** zijn een vorm van op scenario's gebaseerd sociaal-engineeringtesten (art. 25(1)). > Threat-led penetration testing (TLPT, art. 26 en 27) is alleen verplicht voor financiële entiteiten die door hun toezichthouder zijn aangewezen. Stoïk Protect biedt dit niet aan. ### 4. Risico van ICT-derden (hoofdstuk V, artikelen 28 tot en met 44) Je blijft volledig verantwoordelijk voor je DORA-verplichtingen wanneer je een cloudprovider gebruikt (art. 28(1)). **Cloudscan** helpt je het deel van dat risico te beheersen dat afhangt van hoe *jij* je omgeving hebt geconfigureerd. Het **vervangt** het register van informatie of de verplichte contractclausules met je ICT-leveranciers niet (art. 28(3), art. 30). ### 5. Informatie-uitwisseling (artikel 45) Deze pijler is optioneel onder DORA. Stoïk Protect dekt deze niet rechtstreeks. ## Wat blijft jouw verantwoordelijkheid Stoïk Protect geeft je tools en bewijs. Je organisatie blijft verantwoordelijk voor het volgende: * **Governance.** Je leidinggevend orgaan heeft de eindverantwoordelijkheid voor ICT-risico en moet het kader goedkeuren (art. 5(2)). * **Officiële rapportage.** Je meldt grote incidenten aan je toezichthouder (art. 19). Het Stoïk CERT helpt je de technische inhoud voor te bereiden. * **Back-ups en bedrijfscontinuïteit.** Je beleid voor back-up, herstel en bedrijfscontinuïteit of disaster recovery, en de tests daarvan (art. 11, 12). * **Register van ICT-dienstverleners en contracten** (art. 28(3), 30). * **Encryptiebeleid** (art. 9(4)). * **TLPT**, als je toezichthouder je heeft aangewezen (art. 26, 27). ## Aan de slag 1. Open **Stoïk Protect** en kijk welke tools al actief zijn voor jouw organisatie. 2. Activeer de tools die passen bij je hiaten. Externe Scan, Active Directory Scan, Training en Phishingsimulatie zijn de snelste winst voor DORA-bewijs. 3. Voltooi de **NIS2-beoordeling** in het **Naleving** tabblad voor een gestructureerd overzicht van je technische maatregelen. 4. Exporteer de rapporten van elke tool en voeg ze toe aan je DORA-documentatie. {% hint style="warning" %} Dit artikel is algemene richtlijn, geen juridisch advies. Verwijzingen zijn naar de EU-teksten: Verordening (EU) 2022/2554 (DORA) en de gedelegeerde verordeningen (EU) 2024/1774 en (EU) 2025/301. De exacte reikwijdte van elke dienst hangt af van je contract. Voor je specifieke verplichtingen kun je het beste je compliance officer of je toezichthouder vragen. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.stoik.io/help/help-nl/onboarding/compliance/dora.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.