Trust Center-vereisten onder NIS2 en DORA
Geen van beide regelgevingen noemt 'trust center' bij naam. Beide creëren vereisten die alleen een gestructureerde externe bewijslaag kan vervullen.
NIS2 en DORA zijn interne governance-regelgevingen. Ze vertellen u welke beveiligingsmaatregelen u moet implementeren, welke incidenten u moet rapporteren en welk bewijs u moet bewaren. Ze schrijven niet voor hoe u uw nalevingshouding extern communiceert.
Maar dit is wat er in de praktijk gebeurt: uw klanten — vooral degenen die zelf gereguleerd zijn — hebben gestructureerd, continu inzicht nodig in uw beveiligingshouding. Niet uit nieuwsgierigheid, maar omdat hun eigen NIS2- en DORA-verplichtingen hen verplichten hun toeleveringsketen te monitoren. Uw Trust Center is waar die monitoring plaatsvindt.
De regelgevingslogica
NIS2 en DORA bestaan niet in isolatie. Ze creëren een cascade van verplichtingen die door toeleveringsketens stroomt.
Een essentiële entiteit onder NIS2 moet toeleveringsketenbeveiliging waarborgen (artikel 21(2)(d)). Daarvoor moet zij haar leveranciers beoordelen en monitoren. Die leveranciers zijn niet direct gereguleerd door NIS2 (tenzij ze ook essentiële of belangrijke entiteiten zijn), maar ze hebben een commerciële verplichting: als u uw beveiligingshouding niet kunt aantonen aan uw gereguleerde klanten, verliest u het contract.
Dezelfde logica geldt onder DORA. Financiële entiteiten moeten ICT-derdenrisico beheren (artikelen 28-30). Hun ICT-dienstverleners moeten bewijs leveren van beveiligingsmaatregelen, incidentbeheercapaciteiten en bedrijfscontinuïteitsplanning — niet eenmalig, maar continu.
Dit creëert een marktniveau-vraag naar gestructureerde, verifieerbare, continu bijgewerkte externe beveiligingscommunicatie. Dat is wat een Trust Center doet. De regelgeving creëert de behoefte; het Trust Center is het operationele antwoord.
NIS2-vereisten die Trust Center-behoefte creëren
Toeleveringsketenbeveiliging — Artikel 21(2)(d)
Wat de regelgeving zegt: Essentiële en belangrijke entiteiten moeten "toeleveringsketenbeveiliging" adresseren, inclusief "beveiligingsgerelateerde aspecten betreffende de relaties tussen elke entiteit en haar directe leveranciers of dienstverleners."
Wat dit betekent voor leveranciers: Uw gereguleerde klanten moeten aan hun nationale bevoegde autoriteit aantonen dat zij hun toeleveringsketen monitoren. Ze hebben bewijs nodig dat hun leveranciers passende beveiligingsmaatregelen handhaven.
Wat dit van uw Trust Center vereist:
- Gestructureerde presentatie van uw beveiligingshouding, continu bijgewerkt — geen statische PDF
- Frameworks en certificeringen weergegeven met scope, geldigheid en auditdata
- Subverwerkerlijst met gegevensverwerkingslocaties en rollen — zichtbaar, niet afgeschermd achter een verkoopgesprek
- Leveranciersprofielen die uw klanten kunnen refereren in hun eigen NIS2-documentatie
Als uw Trust Center een documentenopslagplaats is die eens per kwartaal wordt bijgewerkt, voldoet het niet aan de verwachting van continue monitoring. Als het real-time nalevingsstatus biedt met automatisch bijgewerkt bewijs, wel.
Incidentrapportage — Artikel 23
Wat de regelgeving zegt: Essentiële en belangrijke entiteiten moeten indienen:
- Vroege waarschuwing aan hun CSIRT binnen 24 uur na kennis van een significant incident
- Incidentmelding binnen 72 uur met initiële beoordeling
- Eindrapport binnen een maand met oorzaakanalyse
Wat dit betekent voor leveranciers: De rapportageverplichting rust op de entiteit, niet op hun leverancier. Maar wanneer het incident bij een leverancier ontstaat of deze treft, begint de rapportagetijdlijn van de entiteit wanneer zij ervan op de hoogte raakt. Vertraagde bewustwording betekent vertraagde rapportage betekent regelgevingsblootstelling.
Wat dit van uw Trust Center vereist:
- Incidentcommunicatiecapaciteit — gestructureerde statusupdates die getroffen klanten ontvangen via het Trust Center, niet via individuele e-mails
- Ernstclassificatie zichtbaar voor relevante belanghebbenden
- Tijdlijndocumentatie die uw klanten kunnen refereren in hun eigen incidentmeldingen aan hun CSIRT
- Post-incidentbewijs (oorzaakanalyse, herstelstappen) beschikbaar via hetzelfde kanaal
Toezichtbevoegdheden — Artikelen 32-33
Wat de regelgeving zegt: Nationale bevoegde autoriteiten kunnen audits uitvoeren, bewijs opvragen en entiteiten verplichten nalevingsmaatregelen aan te tonen — op elk moment, niet alleen tijdens geplande auditcycli.
Wat dit betekent voor leveranciers: Als de bevoegde autoriteit van uw klant (in Duitsland: het BSI) hen vraagt toeleveringsketenbeveiliging aan te tonen, zal uw klant zich tot u wenden. Ze hebben uw nalevingsbewijs snel nodig — niet "we bereiden iets voor voor de audit."
Wat dit van uw Trust Center vereist:
- Bewijs dat actueel is (de stand van vandaag, niet die van vorig kwartaal)
- Bewijs dat gestructureerd is (georganiseerd per framework, maatregel en controle — geen map met PDF's)
- Bewijs dat opvraagbaar is (uw klant kan binnen uren ophalen wat nodig is, niet weken)
DORA-vereisten die Trust Center-behoefte creëren
ICT-derdenrisicobeheer — Artikelen 28-30
Wat de regelgeving zegt: Financiële entiteiten moeten risico's identificeren, classificeren en beheren die voortvloeien uit ICT-derdendienstverleners. Dit omvat het bijhouden van een register van alle ICT-derdenarrangementen, het uitvoeren van due diligence voor contractering en het continu monitoren van naleving.
Wat dit betekent voor leveranciers: Als u verkoopt aan financiële instellingen in de EU, moeten uw klanten u classificeren in hun ICT-derdenregister en uw beveiligingshouding monitoren. Ze hebben gestructureerde gegevens nodig over uw beveiligingsmaatregelen, bedrijfscontinuïteitscapaciteiten en onderaannemersketens.
Wat dit van uw Trust Center vereist:
- Beveiligingsdocumentatie gestructureerd rond de categorieën die DORA van financiële entiteiten vereist te beoordelen: beschikbaarheid, authenticiteit, integriteit, vertrouwelijkheid (artikel 5)
- Bedrijfscontinuïteits- en ramphersteldocumentatie — niet alleen dat een plan bestaat, maar bewijs van testen
- Zichtbaarheid in de onderaannemersketen — DORA vereist dat financiële entiteiten de volledige ICT-toeleveringsketen begrijpen, niet alleen de directe relatie
- Contractueel nalevingsbewijs — DORA artikel 30 specificeert wat ICT-dienstcontracten moeten bevatten; uw Trust Center kan aantonen dat u aan deze bepalingen voldoet
Incidentrapportage — Artikel 19
Wat de regelgeving zegt: Financiële entiteiten moeten grote ICT-gerelateerde incidenten melden aan hun bevoegde autoriteit, met classificatie gebaseerd op impactcriteria waaronder gegevensverlies, dienstonbeschikbaarheid en aantal getroffen cliënten.
Wat dit betekent voor leveranciers: Wanneer een incident bij u een financiële klant treft, moeten zij dit classificeren tegen DORA's impactcriteria. Ze hebben uw incidentgegevens gestructureerd nodig, niet begraven in een e-mailketen.
Wat dit van uw Trust Center vereist:
- Incidentcommunicatie die de gegevens biedt die financiële entiteiten nodig hebben voor hun eigen DORA-classificatie: omvang van impact, gegevenscategorieën getroffen, dienstbeschikbaarheidsstatus, hersteltijdlijn
- Gestructureerd formaat dat aansluit bij DORA-rapportagesjablonen, waardoor de classificatielast voor uw klant vermindert
Toezicht op kritieke ICT-derdenleveranciers — Artikelen 31-37
Wat de regelgeving zegt: De Europese toezichthoudende autoriteiten (ESA's) kunnen ICT-derdenleveranciers als "kritiek" aanwijzen en hen onderwerpen aan direct toezicht, inclusief inspecties ter plaatse en bewijsverzoeken.
Wat dit betekent voor leveranciers: Als u wordt aangewezen als kritieke ICT-derdenleverancier, kunnen toezichthoudende autoriteiten uw beveiligingshouding rechtstreeks onderzoeken. Zelfs als u niet als kritiek wordt aangewezen, moeten uw financiële klanten aantonen dat zij u zouden kunnen vervangen indien nodig — wat vereist dat zij uw dienstarchitectuur in detail begrijpen.
Wat dit van uw Trust Center vereist:
- Voldoende technische documentatie voor toezichthouders om uw beveiligingshouding te beoordelen zonder een apart auditproces
- Dienstarchitectuurinformatie die financiële entiteiten helpt concentratierisico en exitstrategieën te beoordelen
- Bewijs van nalevingsmaatregelen dat direct aan toezichthoudende autoriteiten kan worden gepresenteerd
Wat een NIS2/DORA-klaar Trust Center moet doen
Op basis van deze regelgevingsvereisten heeft een Trust Center dat NIS2- en DORA-getroffen klanten bedient vijf mogelijkheden nodig die verder gaan dan traditioneel documentdelen:
1. Continue nalevingsstatus
Statische documentatie die elk kwartaal wordt bijgewerkt, voldoet niet aan verwachtingen voor continue monitoring. Het Trust Center moet uw huidige nalevingshouding weerspiegelen — certificeringen met geldigheidsdata, maatregelstatus die bijwerkt wanneer uw ISMS bijwerkt, bewijs dat is voorzien van tijdstempel en versie.
2. Gestructureerde leveranciersprofielen
Uw klanten moeten u opnemen in hun toeleveringsketen-beveiligingsdocumentatie (NIS2) of ICT-derdenregister (DORA). Maak dit gemakkelijk: bied gestructureerde gegevens over uw beveiligingsmaatregelen, certificeringen, gegevensverwerkingslocaties en onderaannemerrelaties in een formaat dat zij direct kunnen refereren.
3. Incidentcommunicatiekanaal
E-mailketens schalen niet. Wanneer een incident meerdere klanten treft, hebt u een gestructureerd communicatiekanaal binnen het Trust Center nodig dat ernstclassificatie, tijdlijndocumentatie, impactomvang en herstelstatus biedt — zichtbaar voor getroffen belanghebbenden, passend afgeschermd.
4. Bewijs op verzoek opvraagbaar
Als de toezichthouder van uw klant om toeleveringsketenbewijs vraagt, zou uw klant geen ondersteuningsticket hoeven in te dienen en te wachten. Het Trust Center moet nalevingsbewijs direct opvraagbaar maken — gestructureerd per framework en maatregel, actueel en verifieerbaar.
5. Gelaagde toegangscontroles
Niet alles hoort op een openbare pagina. Pentestsamenvattingen kunnen NDA-afgeschermd zijn. Incidentcommunicatie kan beperkt zijn tot getroffen klanten. Frameworkcertificeringen kunnen openbaar zijn. Een Trust Center dat gereguleerde sectoren bedient, heeft gedetailleerde toegangscontrole nodig — openbaar, beperkt, NDA-afgeschermd, klantspecifiek — zonder de basisinformatie ontoegankelijk te maken.
Wat dit betekent voor platformkeuze
Als uw klanten essentiële of belangrijke entiteiten onder NIS2 omvatten, of financiële entiteiten onder DORA, heeft het Trust Center dat u kiest regelgevingsimplicaties — niet alleen voor u, maar voor de nalevingshouding van uw klanten.
Beoordeel het platform aan de hand van deze regelgevingsvereisten, niet alleen aan de hand van functielijsten. Een Trust Center met mooie analytics en AI-vragenlijstautomatisering maar geen incidentcommunicatiecapaciteit, geen leveranciersprofielen en geen bewijsopvraging — dat Trust Center bedient niet de markt die NIS2 en DORA creëren.
Overweeg datasoevereiniteit in de regelgevingscontext. Uw Trust Center bevat nalevingsbewijs waar uw klanten op vertrouwen voor hun eigen regelgevingsverplichtingen. Als dat bewijs is opgeslagen op infrastructuur die onderworpen is aan de Amerikaanse CLOUD Act, erven uw klanten dat soevereiniteitsrisico in hun toeleveringsketenbeoordeling.
Vraag of het platform EU-frameworks als primair of secundair behandelt. Als NIS2 en DORA bijzaken zijn in de productervaring — beschikbaar maar niet prominent — zullen uw gereguleerde klanten dat opmerken. Ze beoordelen uw nalevingsvolwassenheid, en uw Trust Center is het bewijs.
Bronnen
- Richtlijn (EU) 2022/2555 (NIS2-richtlijn) — Toeleveringsketenbeveiliging (art. 21(2)(d)), incidentrapportage (art. 23), toezichtbevoegdheden (art. 32-33).
- Verordening (EU) 2022/2554 (DORA) — ICT-derdenrisicobeheer (art. 28-30), incidentrapportage (art. 19), toezicht op kritieke leveranciers (art. 31-37).
- NIS2-uitvoeringswet Duitsland (NIS2UmsuCG) — Duitse omzetting waarmee BSI-toezichtbevoegdheid wordt vastgesteld.