--- mpf: '0.7' title: Veerkracht — ESFI Docs url: https://docs.esfi.eu/nl/topics/resilience/ mpf-url: https://docs.esfi.eu/nl/topics/resilience/index.mpf organization: European Strategy & Future Infrastructure domain: docs.esfi.eu lang: nl updated: '2026-11-03' author: ESFI provenance: human source-hash: de633d6da6efe5753c7c3cb9d87ef4a4b3281abfd9cae4fcb9613d77554ded96 toc: - level: 1 text: Veerkracht id: veerkracht - level: 2 text: Begin bij de functie, niet bij de inventaris id: begin-bij-de-functie-niet-bij-de-inventaris - level: 2 text: Duplicatie is geen onafhankelijkheid id: duplicatie-is-geen-onafhankelijkheid - level: 2 text: Een doelbewuste manier om te degraderen id: een-doelbewuste-manier-om-te-degraderen - level: 2 text: Elke resilienceclaim heeft een grens id: elke-resilienceclaim-heeft-een-grens - level: 2 text: Gepland, getest en bewezen zijn verschillende dingen id: gepland-getest-en-bewezen-zijn-verschillende-dingen - level: 2 text: De test eindigt wanneer de normale werking terug is id: de-test-eindigt-wanneer-de-normale-werking-terug-is - level: 2 text: Storingen respecteren geen organigrammen id: storingen-respecteren-geen-organigrammen - level: 2 text: Kennis kan een single point of failure zijn id: kennis-kan-een-single-point-of-failure-zijn - level: 2 text: Hoe we er samen aan werken id: hoe-we-er-samen-aan-werken - level: 2 text: Waar we voorzichtig zijn id: waar-we-voorzichtig-zijn - level: 2 text: Verder lezen id: verder-lezen - level: 2 text: Wijzigingen in deze positie id: wijzigingen-in-deze-positie - level: 2 text: Op deze pagina id: op-deze-pagina spec-origin: esfi.eu content-origin: docs.esfi.eu content-id: esfi:page:topics-resilience content-parity: html: true human-visible-source: true hidden-sections: false summary: Wat blijft werken wanneer iets uitvalt? index: true confidence: probable content-type: analysis companion-footer: ESFI — civilization infrastructure · https://esfi.eu companion-contact: mailto:hermes@esfi.eu preferred-representation: mpf companion-scope: cite: true summarize: true train: true index: true relay: true language-variants: en: https://docs.esfi.eu/topics/resilience/index.mpf fr: https://docs.esfi.eu/fr/topics/resilience/index.mpf nl: https://docs.esfi.eu/nl/topics/resilience/index.mpf de: https://docs.esfi.eu/de/topics/resilience/index.mpf hr: https://docs.esfi.eu/hr/topics/resilience/index.mpf mpf-id: f8349430cf7993cf9ac7755e3d364b862ee32bdb56ccc25748425f60ee032680 --- Taal ✕ /nl/topics/resilience/index.mpf[bestand openen ↗](/nl/topics/resilience/index.mpf)[specificatie ↗](/nl/standards/mpf/0.7)✕ laden… # Veerkracht {#veerkracht} **Wat blijft werken wanneer iets uitvalt?** Een organisatie doet alles wat resilienceplanning vraagt. Twee datacenters. Twee netwerkproviders. Een geteste backup. Een continuïteitsplan dat door het bestuur is goedgekeurd. Dan gebeurt er een incident. Beide netwerkverbindingen blijken door dezelfde buis onder dezelfde weg te lopen. Beide datacenters steunen op dezelfde identity service, die samen met de primaire omgeving uitvalt. De backup is intact, maar de procedure om hem te activeren veronderstelt een communicatiekanaal dat samen met al het andere is uitgevallen. Elke component was gedupliceerd. Niets was onafhankelijk. De meeste organisaties waarmee we spreken hebben niet te weinig veerkrachtmaatregelen. Wat ze vaak missen is een duidelijk antwoord op een smallere vraag: wanneer een specifieke afhankelijkheid verdwijnt, welke essentiële functie blijft dan werken, hoe lang, op welk niveau, onder wiens bevoegdheid en met welk pad terug naar normaal? Daar houdt veerkracht op een checklist te zijn en wordt het een engineeringeigenschap. Onze positie is eenvoudig te formuleren. **Veerkracht is een eigenschap van een essentiële functie onder een benoemde faalconditie.** “Veerkrachtig” op zichzelf is geen claim die iemand kan testen. “Deze functie blijft op dit niveau zo lang doorgaan wanneer die afhankelijkheid wegvalt” is dat wel. * * * ## Begin bij de functie, niet bij de inventaris {#begin-bij-de-functie-niet-bij-de-inventaris} Veerkrachtwerk begint vaak met een inventaris: systemen, locaties, verbindingen, backups, leveranciers. De inventaris is nuttig. Hij vertelt niet wat de organisatie probeert te behouden. Wij beginnen bij de functie die moet doorgaan. Betalingen uitvoeren. Een noodrespons coördineren. Een publieke informatiedienst beschikbaar houden. Een waterzuiveringsproces uitvoeren. Elk daarvan is tegelijk afhankelijk van veel dingen: stroom, communicatie, identiteit, data, fysieke toegang, mensen, logistiek, specialistische kennis en externe diensten. Pas wanneer de functie is benoemd, kan worden gevraagd welke van die afhankelijkheden ertoe doen, welke een tijdlang verloren mogen gaan en welke helemaal niet verloren mogen gaan. Het verschil is praktisch. Een inventaris kan laten zien dat elk systeem een backup heeft. Alleen een functiegerichte blik kan laten zien dat al die backups van hetzelfde afhankelijk zijn. ## Duplicatie is geen onafhankelijkheid {#duplicatie-is-geen-onafhankelijkheid} Redundantie is gemakkelijk te tekenen en gemakkelijk te overschatten. Een systeem kan veel kopieën bevatten en toch één punt hebben waarop ze allemaal tegelijk falen. Wij noemen de verzameling dingen die door dezelfde gebeurtenis kunnen worden uitgeschakeld een **failure domain**. De eerste vraag die we aan elk resilienceontwerp stellen is: **welke ene gebeurtenis kan zowel het primaire pad als de fallback uitschakelen?** Als het antwoord dezelfde gebeurtenis is, heeft de organisatie duplicatie, geen onafhankelijkheid. Failure domains nemen verschillende vormen aan, en de gevaarlijkste zijn vaak het minst zichtbaar. **Fysiek.** Twee glasvezelroutes in één sleuf. Twee faciliteiten gevoed door één transformator. Twee locaties bereikbaar via één brug. Redundante servers die één koelsysteem delen. **Digitaal.** Eén identity provider achter elke applicatie. Eén DNS-authority. Eén cloudaccount waarin productie en backup staan. Eén deployment pipeline waarvan elk herstel afhangt. **Operationeel.** Eén team dat weet hoe het systeem moet worden hersteld. Eén leverancier die bevoegd is om het te repareren. Eén beheerder die de sleutels kan terughalen. **Institutioneel.** Eén autoriteit wier goedkeuring nodig is voordat iemand kan handelen. Eén overdracht tussen organisaties zonder fallback wanneer ze mislukt. Eén inkoopregel die noodsubstitutie onmogelijk maakt. **Redundantie zonder gescheiden failure domains is geen veerkracht.** Het werk is niet kopieën tellen, maar uitzoeken welke schijnbaar onafhankelijke paden nog steeds samen kunnen falen. ## Een doelbewuste manier om te degraderen {#een-doelbewuste-manier-om-te-degraderen} Continuïteit betekent niet altijd volledige dienstverlening. Soms is het juiste resultaat een verminderde dienstverlening die de essentiële functie in leven houdt terwijl de rest wacht. Dat werkt alleen als de verminderde toestand vooraf is ontworpen. Voor elke essentiële functie weet een veerkrachtige organisatie: - welke capaciteit beschikbaar moet blijven en welke kan worden opgeschort; - hoe lang de gedegradeerde toestand houdbaar moet zijn; - welke beslissingen nog kunnen worden genomen en door wie; - welke data betrouwbaar moeten blijven; - welke veiligheids- of beveiligingsvoorwaarden niet mogen worden versoepeld; - wie bevoegd is de gedegradeerde toestand in en uit te gaan. Zonder deze grenzen kan een systeem als “beschikbaar” worden gerapporteerd terwijl het de functie die ertoe doet niet meer uitvoert. **Veerkracht is niet de afwezigheid van degradatie. Het is het vermogen doelbewust te degraderen zonder de essentiële functie te verliezen.** ## Elke resilienceclaim heeft een grens {#elke-resilienceclaim-heeft-een-grens} Een geslaagde resiliencetest bewijst iets. Zelden bewijst hij zoveel als later wordt aangenomen. Een dienst die het verlies van één netwerkpad overleeft heeft niet laten zien dat hij een stroomstoring overleeft. Een locatie die één uur op noodstroom draait heeft niet aangetoond dat ze drie dagen kan draaien. Een hersteloefening die is uitgevoerd terwijl normale communicatie- en identiteitsdiensten beschikbaar waren, heeft niet laten zien dat herstel werkt wanneer die diensten onderdeel van het incident zijn. Daarom koppelen we aan elke resilienceclaim de omstandigheden waaronder zij geldt. We noemen dit de **failure envelope**: wat bij de start beschikbaar was, wat werd weggenomen, hoe lang, welke minimale dienstverlening werd verwacht, wat werkelijk gebeurde, waarvan het resultaat nog afhankelijk bleef en hoe de normale werking werd hersteld. Een geslaagd resultaat binnen één envelope bewijst geen veerkracht daarbuiten. Wij verkiezen een smalle claim die reproduceerbaar is boven een breed label dat dat niet is. Hier hangt veerkracht ook af van oordeelsvermogen. Testrapporten, leveranciersgaranties en certificeringen doen allemaal uitspraken over veerkracht. Een organisatie die ze kan beoordelen stelt telkens de juiste vraag: onder welke omstandigheden is dit aangetoond, en zijn dat de omstandigheden waarmee wij werkelijk te maken hebben? Een organisatie die die vraag niet kan stellen, vertrouwt op een label, hoe gedetailleerd het rapport erachter ook is. ## Gepland, getest en bewezen zijn verschillende dingen {#gepland-getest-en-bewezen-zijn-verschillende-dingen} Niet elk resiliencebewijs heeft hetzelfde gewicht. We onderscheiden vier soorten. **Ontwerp** beschrijft wat bedoeld is: architectuurdiagrammen, routeplannen, herstelprocedures. Het is nodig, want het vertelt wat moet worden getest. Het is geen bewijs dat het systeem zich zo gedraagt. **Configuratie** beschrijft hoe het systeem werkelijk verbonden en ingesteld is. Ze kan afwijken van het ontwerp, en die afwijking is zelf een risico. **Oefening** legt vast wat er gebeurde toen een echte afhankelijkheid doelbewust werd weggenomen of gedegradeerd. Hier begint een claim van intentie naar demonstratie te bewegen. **Incidentbewijs** laat zien wat er gebeurde toen iets werkelijk faalde. Het onthult vaak afhankelijkheden die geen oefening had voorzien, maar de omstandigheden zijn ongecontroleerd en dossiers kunnen onvolledig zijn. Europese regelgeving beweegt in dezelfde richting. DORA verplicht financiële entiteiten hun digitale operationele veerkracht te testen, onder meer met scenario-gebaseerde tests, in plaats van alleen op gedocumenteerde plannen te vertrouwen. Het principe geldt veel breder dan finance: **geplande capaciteit is geen aangetoonde capaciteit.** ## De test eindigt wanneer de normale werking terug is {#de-test-eindigt-wanneer-de-normale-werking-terug-is} Een systeem dat de eerste fase van een storing overleeft maar niet netjes naar normaal kan terugkeren, heeft de resiliencecyclus niet voltooid. Herstel heeft zijn eigen afhankelijkheden, en dat zijn vaak precies de afhankelijkheden die niemand heeft onderzocht. Hoe wordt de storing gedetecteerd? Wie is bevoegd om te handelen? Welke dienst komt als eerste terug? Welke data zijn gezaghebbend na een periode van gesplitste of gedegradeerde werking, en hoe worden ze gereconcilieerd? Welke credentials en sleutels zijn nodig, en zijn ze bereikbaar? Is herstel afhankelijk van hetzelfde pad dat uitviel? Een backup die start maar zijn data niet kan reconciliëren kan beschikbaarheid behouden en integriteit beschadigen. Een locatie die geïsoleerd kan werken maar niet veilig kan herverbinden heeft de storing alleen uitgesteld. **De test eindigt wanneer de essentiële functie is teruggekeerd naar haar gedefinieerde normale toestand, niet wanneer de fallback start.** ## Storingen respecteren geen organigrammen {#storingen-respecteren-geen-organigrammen} De meest ingrijpende storingen kruisen de grenzen die organisaties tussen afdelingen, systemen en verantwoordelijkheden trekken. Een stroomstoring wordt een communicatiestoring. Een communicatiestoring wordt een identiteitsstoring. Een identiteitsstoring verhindert operators de tools te bereiken die ze nodig hebben om te herstellen. [De grootschalige stroomuitval op het Iberisch Schiereiland in april 2025](https://www.entsoe.eu/publications/blackout/28-april-2025-iberian-blackout/) liet zien hoe snel een storing in één systeem doorwerkt naar vervoer, telecommunicatie en retailbetalingen, die elk afzonderlijk worden gepland. Daarom is een afhankelijkheidskaart die bij IT-systemen stopt onvolledig. Ze moet ook de mensen, bevoegdheden, energie, communicatie, logistiek en fysieke toegang omvatten die nodig zijn om een functie te laten draaien en terug te brengen. Daaruit volgen twee gevolgen voor onze manier van werken. **Correlatie is belangrijker dan één afzonderlijk signaal.** Een communicatie-anomalie, een stroomonregelmatigheid of een logistieke verstoring kan afzonderlijk routine zijn. Dezelfde drie rond dezelfde functie op hetzelfde moment zijn dat niet. Veerkracht hangt minder af van meer signalen verzamelen dan van zien wanneer zwaktes in verschillende domeinen op één lijn beginnen te komen. **Richting is even belangrijk als positie.** Een statische score kan verbergen of een systeem verbetert of verslechtert. Een organisatie die redelijk functioneert maar gestaag verzwakt kan meer risico lopen dan één die er slecht voor staat maar snel verbetert. Dezelfde logica geldt voor functies die landsgrenzen overschrijden. Bevoegdheid verandert aan de grens, procedures verschillen en apparatuur of data kunnen sneller oversteken dan juridische verantwoordelijkheid. Grensoverschrijdende veerkracht kan niet volledig binnen één bestuur worden aangetoond. De oefening moet de grens zelf omvatten. ## Kennis kan een single point of failure zijn {#kennis-kan-een-single-point-of-failure-zijn} Veerkracht gaat niet alleen over assets. Een functie kan kwetsbaar worden omdat het vermogen om haar te herstellen bij één persoon, één aannemer of één team ligt. Er verandert zichtbaar niets wanneer die persoon met pensioen gaat of dat contract eindigt. Het eerste signaal is meestal het volgende incident, wanneer niemand die overblijft nog weet waarom het systeem zo is geconfigureerd. Daarom nemen we kennis, specialistische capaciteit en institutioneel geheugen mee in resiliencewerk wanneer die essentieel zijn voor continuïteit of herstel. Wie weet hoe deze functie moet worden hersteld? Is die kennis door meer dan één persoon in de praktijk gebracht? Zou de organisatie haar opnieuw kunnen opbouwen als ze verloren ging? Hier raakt veerkracht aan ons werk rond [Capaciteitsoverdracht](/nl/topics/capability-transfer). Een systeem dat een technische storing overleeft maar niet het vertrek van één specialist is niet veerkrachtig. Het heeft geluk. ## Hoe we er samen aan werken {#hoe-we-er-samen-aan-werken} Onze aanpak van veerkracht volgt dezelfde volgorde als de rest van ons werk: eerst begrijpen, dan ontwerpen, dan testen onder omstandigheden die ertoe doen. **Benoem de functie.** Spreek af wat moet blijven doorgaan en op welk minimumniveau. **Breng de afhankelijkheden in kaart.** Over fysieke, digitale, operationele, institutionele en menselijke lagen heen, en vind de failure domains die ze delen. **Ontwerp de gedegradeerde toestand en het herstelpad.** Beslis vooraf wat kan worden opgeschort, wat moet blijven, wie beslist en hoe de normale werking terugkeert. **Test binnen een benoemde envelope.** Neem een echte afhankelijkheid weg of degradeer haar, leg vast wat gebeurt en zeg precies wat het resultaat wel en niet aantoont. **Laat het vermogen om te oordelen achter.** De organisatie moet eindigen met mensen die het volgende testrapport, de volgende leveranciersgarantie of het volgende incident zelf kunnen beoordelen. Wanneer we samen met een partner naar een essentiële functie kijken, leggen we doorgaans deze vragen vast: | Vraag | Wat ze zichtbaar maakt | | --- | --- | | Welke functie moet blijven doorgaan, en op welk minimumniveau? | Waar veerkracht werkelijk voor dient. | | Waar hangt ze op elke laag van af? | De volledige dependency graph, niet alleen IT. | | Welke daarvan kunnen samen falen? | De echte failure domains. | | Welk scenario testen we, en hoe lang? | De envelope van de claim. | | Wie kan handelen tijdens de storing? | Of bevoegdheid het incident overleeft. | | Wat gebeurde er werkelijk toen we het testten? | Het verschil tussen ontwerp en gedrag. | | Hoe werd de normale werking hersteld? | Of de cyclus werd voltooid. | | Welke verandering zou dit resultaat ongeldig maken? | Wanneer het bewijs verloopt. | De laatste vraag is belangrijker dan ze lijkt. Een gewijzigde route, identity provider, stroomregeling, leverancier of procedure kan een eerder resultaat ongeldig maken zonder dat de naam van de dienst verandert. Resiliencebewijs heeft een levenscyclus en moet worden herzien wanneer het onderliggende systeem verandert. ## Waar we voorzichtig zijn {#waar-we-voorzichtig-zijn} We houden ons aan enkele toezeggingen over wat we claimen. We noemen een systeem niet veerkrachtig omdat het een backup heeft, en we noemen twee systemen niet onafhankelijk voordat we begrijpen wat ze delen. We generaliseren een geslaagde componenttest niet tot een claim over het hele systeem en behandelen een simulatie niet als bewijs van fysiek gedrag. We presenteren geplande capaciteit niet als bereikte capaciteit. Waar iets is ontworpen maar nog niet getest, zeggen we dat. We behandelen herstel niet als een bijzaak en vervangen een gevoel van richting niet door één score. En we noemen niets veerkrachtig zonder de functie, de faalconditie, de grens en het bewijs te benoemen. * * * ## Verder lezen {#verder-lezen} - [Richtlijn (EU) 2022/2557 (CER)](https://eur-lex.europa.eu/eli/dir/2022/2557/oj), over de veerkracht van kritieke entiteiten. - [Verordening (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj), over digitale operationele veerkracht voor de financiële sector. **Gerelateerde thema’s:** [Soevereiniteit](/nl/topics/sovereignty) · [Capaciteitsoverdracht](/nl/topics/capability-transfer) · [Vroege waarschuwing](/nl/topics/early-warning) * * * ## Wijzigingen in deze positie {#wijzigingen-in-deze-positie} - 24 september 2026 — Voor het eerst gepubliceerd. Materiële wijzigingen worden hier met datum vermeld. Correcties van formulering of links worden niet opgenomen. ## Op deze pagina {#op-deze-pagina} ESFI — civilization infrastructure · https://esfi.eu