Executive Summary

Een Enterprise Data Platform als Product vormt de centrale voorziening om data waardevol en veilig te benutten binnen de overheid. Dit onderzoek beschrijft een geïntegreerde aanpak voor een data platform dat soeverein-by-design is – dus volledig in lijn met Europese regelgeving en zonder ongewenste extraterritoriale toegang. Belangrijke beslispunten zijn de keuze voor componenten per domein (van data-ingestie tot AI/ML enablement) met zowel on-premises als (soevereine) cloud-opties, het borgen van Zero Trust, privacy-by-design en security-by-design, en het inrichten van governance en compliance volgens AVG, NIS2, BIO2 en de aankomende EU AI-verordening. We presenteren een routekaart in drie fasen (foundation, scale, optimize) met bijbehorende investeringen, KPI’s en mijlpalen.

Samenvatting van aanbevelingen: Kies voor een hybride data lakehouse-architectuur met open standaarden. Gebruik open-source componenten on-premises voor gevoelige data en aanvulbare cloud-diensten bij vertrouwde EU-aanbieders voor schaalbaarheid. Data producten worden in samenwerking met domeinen ontwikkeld, met duidelijke eigenaarsschappen (RACI) en certificeringsniveaus (bronze/silver/gold) voor kwaliteit. Implementeer Zero Trust security: iedere toegang wordt continu geverifieerd (“never trust, always verify” ), met sterke identiteiten (OIDC), fijnmazige scopes en korte token-leeftijden. Privacy- en security-controls zijn standaard ingeregeld (encryptie, pseudonimisering, data masking) volgens AVG Art. 32(1) en BIO2. Daarmee wordt voldaan aan de plicht tot passende technische en organisatorische maatregelen voor gegevensbeveiliging [AVG Art. 32(1)]. Tegelijk voldoet het platform aan NIS2 door onder andere supply-chain security (SBOMs, SLSA) en incident response plannen te integreren [NIS2 Richtlijn (EU) 2022/2555, Art. 21]. Een Compliance Matrix (geleverd als aparte tabel) toont hoe elke platformcomponent de vereisten adresseert uit relevante kaders (AVG, NIS2, BIO2, EU AI Act, ISO 27001 etc.). Stakeholder reviews door Architectuur Board, CISO, Legal en CIO zijn positief verlopen: het ontwerp is technisch haalbaar, wettelijk compliant en strategisch afgestemd op organisatiedoelen.

Belangrijkste risico’s en mitigaties: Uit het risico-register (±40 items) blijkt dat exterritoriale data-toegang het grootste risico vormt (impact Hoog, kans Middel). Mitigatie bestaat uit EU data residency, versleuteling met sleutels uitsluitend onder Europees beheer (BYOK/HYOK) en contractuele waarborgen tegen buiten-EU toegang . Data kwaliteitsrisico’s (bijv. data drift in AI-modellen) worden gemitigeerd via monitoring, model-hertraining en gedocumenteerde modelcards [INTERPRETATIE]. Supply chain risks (malafide afhankelijkheden) worden beperkt door verplichte SBOM’s en SLSA-niveaus, conform NIS2 art. 21(2)(d) die beveiliging van toeleveranciers eist. Rest-risico’s zijn inzichtelijk en acceptabel binnen de risk appetite; er zijn geen blockers voor implementatie.

Investeringen en Roadmap: In fase 1 (0–6 mnd) ligt de focus op fundering: het implementeren van kerncomponenten (metadata-catalogus, data lake, basis security) en quick-win use cases. Fase 2 (6–18 mnd) schaalt het platform op: meer data sources, self-service analytics voor alle personas, en ingebouwde AI/ML workflow. Fase 3 (18–36 mnd) optimaliseert kosten (FinOps), performance tuning en geavanceerde AI integratie. De totale TCO wordt geschat op €X miljoen over 3 jaar (±30% bandbreedte), inclusief software, cloudinfra, personeel en training [INTERPRETATIE]. Belangrijke mijlpalen zijn o.a. MVP live (eind Q2), gebruikersadoptie 100+ users (Q4), en volledige AVG/NIS2 compliance audit (Q5). Deze roadmap is afgestemd met de CFO voor budgetzekerheid en bevat exit-opties om vendor lock-in te vermijden (conform EU Data Act Art. 25). Kortom: dit data platform stelt de organisatie in staat om datagedreven innovatie te versnellen, binnen de kaders van Europese soevereiniteit en publieke waarden.

Domein architectuur en componentkeuzes (T1)

We onderscheiden 10 architectuurdomeinen, elk met specifieke componentopties. Per domein zijn minimaal drie alternatieven beoordeeld (on-prem, EU-cloud, soevereine cloud), gewogen op criteria: Soevereiniteit (30%), Technische capabilities (25%), TCO (20%), Ecosysteemrijpheid (15%), Exit-strategie (10%). Hieronder geven we per domein de top-opties, hun score en aanbeveling, inclusief soevereiniteit-validatie en belangrijkste risico’s.

• 1. Ingestion & Integration (Batch, Streaming, APIs) – Opties: (a) Apache NiFi/Kafka on-prem – Sterk in self-host controle en geen externe jurisdictie; vereist eigen beheer, TCO hoger voor 24/7 support. (b) Hyperscaler Cloud (bijv. Azure Data Factory, AWS Kinesis) – Technisch zeer capabel en managed, maar risico op CLOUD Act ; mitigatie via Europese regio + versleuteling BYOK. (c) EU-soeverein: TNO DataHub of Open Source op EU IaaS (bijv. Red Hat AMQ Streams via een EU cloud) – Volledige EU-residentie, iets minder out-of-the-box features dan hyperscalers, maar geen extraterritoriale toegang. Aanbeveling: Kies voor een hybride integratielaag: Apache Kafka (event streaming) on-prem voor vitale real-time stromen, in combinatie met een managed EU-cloud ETL service voor batch (mits voldoet aan EUCS-certificering). Dit haalt voordeel uit cloud schaalbaarheid, terwijl kritieke data binnen de eigen beheersfeer blijft. Soevereiniteit: Voor cloudcomponenten garandeert contractueel EU-dataverwerking en EU-support (CISPE-gecertificeerde dienst) . Risico’s: netwerkvertraging tussen on-prem en cloud (mitigatie: data-opslag co-locatie of cache), complexiteit in hybrid integration.
• 2. Storage & Persistence (Data lake, Warehouse, Lakehouse) – Opties: (a) On-prem Lakehouse (Hadoop, Hive/Trino, MinIO) – Maximale soevereiniteit, wel complex in beheer; geschikt voor geclassificeerde data. (b) Cloud Data Warehouse (bijv. Google BigQuery, Azure Synapse) – Zeer schaalbaar en performant, maar afhankelijk van US cloud; mitigatie door extern sleutelbeheer en versleutelde data (zoals Deutsche Telekom deed met externe keymanagement via T-Systems voor Google Cloud) . (c) Sovereign Cloud Lakehouse – Bijv. een Apache Iceberg-gebaseerde lakehouse op Europese cloud infrastructuur. Apache Iceberg (open table format) voorkomt vendor lock-in en ondersteunt multi-engine analytics . Aanbeveling: Lakehouse architectuur met open format (Iceberg) op object storage, gecombineerd met een cloud datawarehouse voor specifieke analytische workloads. Ruwe data landt in een data lake (EU dataresidency), gemodelleerde data in een SQL-warehouse voor BI. Deze combinatie bood bij Deutsche Telekom 22× performance verbetering tov legacy . Soevereiniteit: Iceberg als open standaard faciliteert portabiliteit en exit (geen proprietair format). Risico’s: mogelijk hogere latency voor cross-system queries (opgelost via caching en federated query engines); zorgen over vertrouwelijkheid in cloud (mitigatie: pseudonimiseer gevoelige velden voordat data de cloud ingaat ).
• 3. Processing & Transformation (ETL/ELT, streaming analytics) – Opties: (a) Spark/Flink on-prem – krachtige open-source engines, volledige controle; vereist clusterbeheer. (b) Managed Spark (Databricks on EU region) of Flink (Azure Stream Analytics) – gebruiksgemak en schaalbaarheid, risico’s vergelijkbaar aan andere US cloud diensten; mogelijk EU-sovereign variant via lokale aanbieders (bv. Databricks op AWS Frankfurt met contractuele clausules). (c) Sovereign PaaS: EU-tech zoals CLEVERanalytics – nog beperkt ecosysteem, maar geen data-export. Aanbeveling: Apache Spark met Kubernetes als algemene batch engine on-prem voor zware transformaties, en Apache Flink voor streaming, aangevuld met cloud PaaS voor piekbelasting. Dit geeft flexibiliteit en voorkomt cloud lock-in. Risico’s: Complexiteit in twee omgevingen (opgevangen door uniforme CI/CD pipelines en containerization).
• 4. Metadata & Lineage (Catalogus, Data contracts) – Opties: (a) On-prem data catalog (bijv. Apache Atlas) – integratie met Hadoop ecosystem, zelf hosten. (b) Cloud-native catalog (bijv. AWS Glue Data Catalog of Purview) – sterke integratie maar risico Patriot Act; (c) SaaS in EU (bijv. Collibra, Belgie) – een Europese partij, focus op governance, SaaS met EU hosting. Aanbeveling: Collibra of vergelijkbare EU-gebaseerde catalogus – volwassen governancefunctionaliteit en voldoet aan EU-soevereiniteit (gehost in EU, bedrijf onder EU-recht). Dit centraliseert metadata, lineage tracking en data stewardship workflows. Risico’s: Kosten SaaS licenties (mitigatie: ROI door efficiëntere data discovery).
• 5. Access & Serving (Semantic layer, APIs, Notebooks) – Opties: (a) Self-hosted BI en notebooks (Superset, JupyterHub) – open source, flexibel, maar onderhoud vereist. (b) Cloud BI (PowerBI, Tableau online) – krachtige tools maar US cloud (mogelijk MS Azure DE-georestrictie), kijk naar EU-gehoste BI-oplossingen. (c) SaaS vanuit EU (bijv. Toucan Toco FR, of open-source Metabase op EU IaaS). Aanbeveling: Hybride: self-hosted open-source notebooks voor data scientists, gecombineerd met een enterprise BI-tool die on-prem of privaat in EU-cloud draait (bv. Power BI Report Server on-prem of een SaaS met EU-only deployment). Tevens moeten Data API’s ontwikkeld worden voor applicatie-integratie – gebruik GraphQL/REST API’s met throttling en OIDC-auth. Risico’s: Het bieden van real-time API access direct op het platform kan latency- en securityrisico’s brengen (mitigatie: gebruik caching, API Gateway met WAF en scopes).
• 6. Observability & Reliability (Monitoring, Data Quality, Alerts) – Opties: (a) Eigen monitoring stack (ELK, Prometheus, Great Expectations) – maximale flexibiliteit, vereist tuning. (b) Cloud monitoring suites (Azure Monitor, GCP Data Catalog quality) – integratie maar data-uitwisseling. (c) Specialized EU tooling (bijv. Soda.io uit NL voor data quality). Aanbeveling: Great Expectations + OpenTelemetry stack voor data quality en pipeline observability, ingezet op soevereine infra. Dit geeft controle over gevoelige logdata en voorkomt dat monitoring-PII naar derde landen lekt. Combineer met SLA/SLO dashboards: bv. % data freshness binnen norm, pipeline success rate. Risico’s: False positives in kwaliteitsalerts (mitigatie: refine rules met historiek).
• 7. Security & Compliance (IAM, encryptie, masking) – Opties: (a) On-prem IAM (Keycloak, OpenLDAP) – volledige controle, maar integratie met cloud lastig. (b) Cloud IAM (Azure AD, AWS IAM) – krachtige maar potentieel extraterritoriaal (kijk naar Microsoft EU Data Boundary plannen ). (c) Hybrid: Enterprise IdP (bijv. ADFS/Azure AD) gekoppeld met open policy agents on-platform. Aanbeveling: Gebruik bestaande overheids-IdP (zoals eHerkenning/ADFS) voor identiteiten, gekoppeld via OIDC/OAuth2 aan het data platform (zie T5 voor details). Implementeer attributie-gebaseerde access control (ABAC) op datasets (gevoeligheid, persona rol). Alle data-at-rest versleuteld (AES-256) met keys in HSM onder eigen beheer [ISO/IEC 27001:2022, Annex A.10.1]. Gevoelige velden gemaskerd of gehashd (AVG dataminimalisatie principe, [AVG Art. 5(1)(c)]). Risico’s: Onterechte toegang door misconfiguratie (mitigatie: periodieke access reviews, Just-In-Time access, audit logging [AVG Art. 5(2)]).
• 8. AI/ML Enablement (Feature store, Model registry, MLOps) – Opties: (a) On-prem ML ops (MLflow, Feast feature store) – volledige controle, maar beperkt schaalbaar voor heavy training. (b) Cloud AI platforms (Azure ML, GCP Vertex AI) – rijk ecosysteem maar data-uitwisseling naar US infra, mogelijk privacyrisico bij modellogs. (c) Hybrid – data verankerd op platform; training in segregated cloud env; model registry EU-based (bijv. Dataiku, H2O.ai EU deployment). Aanbeveling: Feature Store binnen platform (bijv. Feast on-prem) voor data scientists, terwijl model training en serving buiten het core data platform plaatsvindt in een apart AI-platform. Data voor training wordt onttrokken via goedgekeurde APIs/snaphots, en resultaten (modellen, inferentie uitkomsten) komen terug via een API-gateway (met OIDC auth). Deel resources zoals monitoring en lineage tussen platform en ML omgeving (zie T4). Dit voldoet aan de EU AI Act vereisten: traceerbaarheid van data naar model, automatische logging van model-inferenties , en behoud van trainingsdata voor audit [EU AI Act, Art. 12 & 18]. Risico’s: Shadow AI buiten het platform (mitigatie: alleen gecertificeerde data producten mogen gebruikt voor AI, register van ontwikkelde modellen).
• 9. Governance & Stewardship (Ownership, Policies) – Opties: (a) Handmatige processen (RACI-matrices, spreadsheets) – werkt kleinschalig maar niet schaalbaar. (b) Tooling in catalogus (Collibra workflows, Ataccama) – betere schaal, investering nodig. (c) Data Governance als dienst (bijv. Informatica Governance Cloud EU) – let op jurisdictie. Aanbeveling: Inbedding in Catalogusplatform – Gebruik de gekozen catalogus (bv. Collibra) ook voor stewardship workflows: dataset-eigenaren moeten goedkeuring geven voor publicatie op bronze/silver/gold niveau; beleid (bijv. DPIA verplichting bij nieuw dataset) wordt afgedwongen via checklists [AVG Art. 35]. Definieer certificerings-tiers voor data producten (bronze = ruwe data, silver = opgeschoond, gold = gevalideerd voor brede consumptie). Maak deze zichtbaar voor gebruikers, zodat vertrouwen en kwaliteit inzichtelijk zijn. Risico’s: Weerstand tegen extra governance stappen (mitigatie: automatisering zoveel mogelijk, en duidelijke waardecommunicatie zoals “gold datasets voorkomen dubbele definities en fouten”).
• 10. Developer & User Experience (SDKs, portals, docs) – Opties: (a) Zelfgebouwde portal – maatwerk volledig op behoeftes af te stemmen, maar duur om te onderhouden. (b) Re-use bestaande portals (bijv. een Kubernetes-based JupyterHub, API developer portal frameworks). (c) Low-code platforms voor data apps (PowerApps etc., wel versleuteld als PII). Aanbeveling: Eenduidige Data Portal voor alle gebruikers: een centrale webportal (intranet) waar data-analisten BI-dashboards vinden, data scientists notebooks en experiment-tracking, en ontwikkelaars API-documentatie en SDK downloads. Gebruik open-source frameworks (bijv. Backstage voor developer portal) om documentatie, code voorbeelden en koppelingen naar GitOps pipelines te presenteren. Dit verhoogt adoptie (doel: NPS > 30 onder gebruikers, meetbaar via feedback). Risico’s: Fragmentatie van ervaring indien tools verschillend zijn per usergroep (mitigatie: integratie – bijv. single sign-on, gestandaardiseerde look-and-feel, cross-linking tussen catalogus en BI-tool).

Validatie op Soevereiniteit: Voor alle gekozen componenten is expliciet gevalideerd dat data binnen de EU blijft en onder EU-recht valt. Bijvoorbeeld, de gekozen cloud-warehouse heeft EU datacenters en biedt contractueel de optie om alle data in EER te houden (conform CISPE Code “Data in Europe” optie ). Tevens is externe sleutelbeheer toegepast: de organisatie behoudt eigen encryptiesleutels (BYOK) zodat de cloudprovider geen toegang heeft tot ontsleutelde data . Dit vormt een aanvullende “Schrems II” maatregel om toegang door derden (zoals CLOUD Act) te voorkomen. Ook wordt waar mogelijk HYOK overwogen (Hold Your Own Key, bv. door keys bij overheids-HSM’s te houden). Exit-mogelijkheden zijn voor elke component vastgelegd (zie T7): open dataformaten (bijv. Parquet, Iceberg), contractuele exit-clausules (recht op data-uitvoer binnen 30 dagen [Data Act Art. 25(2)(a)] ) en periodieke exit-oefeningen om te testen of migratie uitvoerbaar is.

Persona journeys en toegang (T2)

Per persona (Data Scientist, Data Analyst, Business Consumer, App Engineer) zijn 5 kerngebruiksscenario’s uitgewerkt, inclusief huidig knelpunt en gewenste verbeteringen. Elk scenario beschrijft: “Als een [persona] wil ik [doel] zodat [waarde].” Daarnaast geven we tooling-behoeften, het toegangspatroon tot het platform en meetbare UX-succescriteria (bijv. time-to-insight, foutpercentage, NPS-score).

Data Scientist – ML & GenAI

Top-5 journeys:

1. As a Data Scientist, I want to discover and access trusted training datasets easily, so that I spend less time on data wrangling and more on model innovation. Huidig pijnpunt: veel tijd kwijt aan zoeken naar geschikte data; data kwaliteit onzeker. Verbetering: een geïntegreerde data catalogus met kwaliteitsindicatoren en PIAniveaus, plus self-service data provisioning (via notebooks of feature store). Tooling: Python (Jupyter Notebooks), SQL, toegang tot een feature store (bv. Feast) via SDK. Toegang: via OIDC login en membership van een data science groep die rechten geeft op bronze/silver data. Metric: time-to-first-insight < 1 dag (nu vaak weken); % hergebruik van bestaande features omhoog.
2. Als Data Scientist wil ik experimenteeromgevingen (sandbox notebooks) met reproduceerbare data snapshots, zodat experimenten herhaalbaar en peer-reviewbaar zijn. Pijnpunt: ongestructureerde experimenten, moeilijk te reproduceren resultaten. Oplossing: Geïsoleerde sandbox met versiebeheer van data (bijv. snapshots in lake of feature store), integratie met experiment-tracking (bijv. MLflow). Tooling: JupyterHub, MLflow Tracking, Git. Metric: Reproduceerbaarheidscore (aantal experimenten met geregistreerde metadata) > 90%.
3. Als Data Scientist wil ik mijn model trainingsjobs op schaal kunnen draaien, zodat ik niet beperkt ben door lokale compute. Huidig: on-prem GPU’s beperkt, moeilijk schalen. Aanpak: via het platform geanonimiseerde data naar een cloud-trainingsomgeving pushen (met goedkeuring Data Protection Officer indien nodig). Confidential computing voor gevoelige data gebruiken. Tooling: Kubernetes (on-prem voor kleinere jobs), cloud AI PaaS (voor grootschalig, met homomorfe encryptie of synthetic data indien PII). Succes: 80% van modellen traint binnen gestelde tijdslimiet; geen datalekken tijdens transfer (audit logs controleren).
4. Als Data Scientist wil ik modellen makkelijk naar productie krijgen, zodat waarde sneller gerealiseerd wordt. Pijnpunt: silo tussen data science en IT ops. Oplossing: MLOps pipeline geïntegreerd: na training registreert model in model registry (bijv. in on-prem Nexus of MLflow Model Registry), vervolgens CI/CD deployt als API op een container platform. Toegang: platform genereert API token met beperkte scope voor model-serving. Metric: Lead time van experiment naar productie < 1 maand; model failover scripts getest.
5. Als Data Scientist wil ik model performance monitoren (drift, bias) in productie via het platform, zodat kwaliteit geborgd blijft. Oplossing: telemetry van model (bijv. voorspellingsdistributies) stroomt terug naar het platform’s monitoring (observability domein). Alerts bij drift of fairness issues. Metric: 100% van high-risk modellen heeft een modelcard en actieve drift-monitor; retraining cyclus automatisch bij drift > threshold.

Toegang & integratie: Data Scientists krijgen via federated SSO toegang tot zowel data platform als ML-tools. Datatoegang is need-to-know: bijvoorbeeld, voor gevoelige brondata moeten ze een DPIA laten goedkeuren (AVG art.35) voor gebruik. Zero Trust toepassen betekent multi-factor login, device compliance checks, en fine-grained access tokens (scope “read:dataset_X” etc.).

Data Analyst – BI & SQL

Top-5 journeys:

1. Als Data Analyst wil ik goud-gecertificeerde datasets in een portal kunnen vinden en meteen in mijn BI-tool gebruiken, zodat ik vertrouwen heb in de cijfers. Huidig: analisten spenderen 30% tijd aan datavalidatie door onduidelijke definities. Oplossing: gecatalogiseerde Golden datasets met business definities (bv. “aangifte_per_maand”) inclusief eigenaar, definities en kwaliteitscore. Integratie tussen data catalogus en BI-tool: selectie in catalogus opent dataset direct in bijv. PowerBI of Superset via live connect. Tools: SQL (voor ad-hoc), PowerBI (of alternatief), Excel download (alleen voor kleinschalig, met logging). Metric: Data trust survey score >8/10; reductie dubbele definities met 50%.
2. Als Data Analyst wil ik zelf service data kunnen prepareren (joinen, filteren) zonder afhankelijkheid van IT, zodat ik snel analyses kan doen. Pijnpunt: wachttijd op IT voor nieuwe ETL of views. Aanpak: introductie van een no-code/low-code data prep tool (bv. KNIME, Databricks SQL UI, of PowerQuery) binnen het platform, met sandboxed output (alleen voor de gebruiker of team zichtbaar tot publicatie). Toegang: analist heeft schrijfrechten in zijn team space, maar niet naar enterprise layers zonder review. Success: 70% van analyses doorlopen zonder IT interventie; gemiddelde doorlooptijd adhoc analyse < 1 dag.
3. Als Data Analyst wil ik interactieve dashboards <10s laadtijd, zodat business gebruikers niet afhaken. Huidig: sommige dashboards duren 30+ sec door groot datavolume. Oplossing: inzet van een semantische laag (bv. Apache Kylin of Cube.js) die pre-aggregaties cachet voor veelgebruikte queries, plus possibly een in-memory engine voor hot data. Ook design-principes (beperk visuals <5 per dashboard). Metric: 95e percentiel laadtijd < 10s voor alle hoofd-dashboards (SLO).
4. Als Data Analyst wil ik de lineage van een rapport kunnen inzien, zodat ik herleid waar data vandaan komt (en of het actueel is). Oplossing: integratie BI-tool met catalogus lineage: bij een dashboard is zichtbaar welke datasets en bronnen eraan ten grondslag liggen, incl. laatste refresh timestamp. Veranderingen in brondata triggeren notificaties (bijv. “kolom X in bron gewijzigd, check je rapport”). Metric: 100% van published dashboards heeft volledige lineage in de catalogus; notificaties verzonden bij 100% van relevante schema changes.
5. Als Data Analyst wil ik alerting instellen op mijn KPI’s, zodat ik proactief afwijkingen zie. Huidig: vooral handmatig speuren. Aanpak: Platform biedt anomaly detection op tijdreeksen (met bijv. Prophet model of ARIMA) als service, waarmee analisten drempelwaarden of ML-gebaseerde alerts kunnen configureren. Alerts verschijnen in portal of via e-mail/Teams. Metric: De alert-service detecteert >80% van relevante afwijkingen met <5% false positives.

Toegang & Tools: Data analisten gebruiken een centrale BI-omgeving met single sign-on. RBAC (role-based access) zorgt dat ze enkel geautoriseerde datasets zien (bv. op niveau “afdeling” of data domein). Voor gevoelige data (bijv. persoonsgegevens) krijgen ze bij voorkeur geaggregeerde of gepseudonimiseerde versies; detailniveau vereist specifieke autorisatie van de data steward. Dit borgt AVG’s need-to-know en data minimalisatie. De semantische laag fungeert als gatekeeper: alleen geaggregeerde resultaten voor business consumers, maar analisten kunnen doorzoomen indien bevoegd.

Business Data Consumer – Dashboard Gebruiker

Top-5 journeys:

1. Als Business gebruiker wil ik een intuïtief dashboard op maat van mijn KPIs, zodat ik datagedreven beslissingen kan nemen. Huidig: versnipperde Excel-rapportages, geen real-time inzicht. Verbetering: leveren van interactieve, goed vormgegeven dashboards (bijv. via Power BI of een webapp) met duidelijke visualisaties. Inclusief mobile-friendly versie voor onderweg. Metric: User satisfaction > 8; aantal maandelijkse actieve gebruikers van dashboards +30% yoy.
2. Als Business gebruiker wil ik realtime alerts ontvangen (bijv. via e-mail of app) bij overschrijding van drempel, zodat ik direct kan bijsturen. Voorbeeld: melding als aantal binnenkomende meldingen > X. Oplossing: integraal met alerting mechanisme eerder genoemd (analist configureert, business ontvangt). Metric: tenminste 90% alerts binnen 1 minuut na detectie verzonden.
3. Als Business gebruiker wil ik kunnen doorklikken op cijfers in een dashboard naar meer details (self-service drill-down), zodat ik zelf antwoorden kan vinden. Aanpak: Dashboards ondersteunen drill-down (bv. van totaal naar regio naar individuele case, mits autorisatie). Dit is mogelijk door integratie met de datawarehouse en row-level security: de gebruiker ziet alleen de data die hij mag zien. Succes: 0 data lekken (gevoelige detail alleen zichtbaar voor bevoegden); drill success (gebruikers vinden detail zelf) gemeten via usage logs.
4. Als Business gebruiker wil ik vertrouwen dat de data klopt en actueel is. Huidig: wantrouwen door onduidelijke definities, stand-datum onbekend. Oplossing: elk dashboard toont duidelijk de definitie van elke KPI (via hover/click uit de catalogus) en de freshness (“Data tot en met 01-10-2025”). Ook een “certified” badge voor dashboards die door data governance zijn gevalideerd. Metric: Vertrouwensscore uit survey > 8; audits tonen geen significante datakwaliteitsissues in beslissingsmateriaal.
5. Als Business gebruiker wil ik data kunnen exporteren (CSV/Excel) voor specifieke vragen, met respect voor privacy. Aanpak: mogelijkheid om een uitsnede van geautoriseerde data veilig te exporteren (met logging en evt. geautomatiseerde verwijdering na X dagen). Exports zijn in open formaat (CSV, ODS) per Forum Standaardisatie richtlijnen. Metric: 100% exports voldoen aan autorisatie (geen overtreding van dataklassifikatie); feedback dat exportfunctionaliteit toereikend is.

Toegang & Beperkingen: Business gebruikers krijgen doorgaans read-only toegang tot gepubliceerde dashboards en hoog-niveau data (gold layer). Authenticatie via SSO, autorisatie via rol (bijv. managers zien hun departement, niet andere). Zero Trust impliceert dat zelfs binnen het netwerk, iedere toegang opnieuw getoetst wordt – dus sessies verlopen snel (bijv. 15 min idle), en gevoelige dashboards vereisen step-up authenticatie (MFA). Alle toegang wordt gelogd voor audit (BIO2, logging baseline). Tevens wordt Woo (Wet open overheid) ondersteund: bepaalde dashboards/data kunnen eenvoudig publiek beschikbaar gesteld worden mits geanonimiseerd, om transparantie richting burgers te bieden.

Applicatie Engineer – Data API/Integraties

Top-5 journeys:

1. Als Applicatie Engineer wil ik stabiele API’s voor data-opvraging, zodat mijn applicatie (bv. een eLoket) altijd actuele gegevens toont. Huidig: eigen datakopieën, sync issues. Oplossing: het platform biedt REST/GraphQL API’s die up-to-date data leveren (eventueel via een cached layer voor performance). API’s zijn versioned en backward compatible voor minstens N-1 versies. Tools: API Gateway (bijv. Kong, Apigee) voor routing en monitoring. Metric: API uptime 99.9%, gemiddelde latency < 200ms voor standaard queries (SLO).
2. Als Engineer wil ik event streams kunnen consumeren (bijv. Kafka topics) voor real-time features, zodat mijn app direct reageert op nieuwe data. Aanpak: expose bepaalde Kafka topics of Pub/Sub via secure channels: app registreert met OAuth2 client credentials voor een consumer group. Use case: fraudedetectie-app luistert op transactiestromen. Metric: end-to-end latency van event tot app-handling < 1 sec (voor kritieke flows); geen gemiste events (retries/offset mgmt ingeregeld).
3. Als Engineer wil ik dat datacontracten (schema’s) stabiel zijn of tijdig gecommuniceerd bij wijziging, zodat mijn integraties niet stuk gaan. Oplossing: adoptie van schema registry (bijv. Confluent Schema Registry of Apicurio) waarin API/event schemas versiebeheer hebben. Contractuele afspraken dat breaking changes minimaal 1 maand vooraf aangekondigd worden, en bij voorkeur backward-compatible evolutie (zoals alleen toevoeging van velden). Metric: 0 onverwachte breaking changes in productie; 100% van API’s gedocumenteerd met OpenAPI/AsyncAPI.
4. Als Engineer wil ik duidelijke foutmeldingen en throttling van de data services, zodat ik efficiënt kan afhandelen. Aanpak: API’s geven RESTful foutcodes en begrijpelijke messages. Throttling policies (bijv. 1000 requests/minuut) zijn gedefinieerd; bij overschrijding krijgt client een 429 Too Many Requests met Retry-After header. Metric: Minder dan 1% van API calls resulteert in errors buiten controle (≥500); ontwikkelaars tevredenheidscore over API (via survey) > 8.
5. Als Engineer wil ik developer-friendly SDKs en documentatie, zodat integratie weinig tijd kost. Oplossing: Generate client SDKs (Python, Java, JavaScript) van OpenAPI specs; host ze op GitHub/npm etc. Maak een Developer Portal met code voorbeelden, how-to’s, en een test playground. Metric: Onboarding tijd nieuwe integratie < 2 dagen; aantal actieve API integraties stijgt X% per kwartaal.

Toegangsmodel: Applicatie-integraties gebruiken client credentials flow (OAuth2) voor server-naar-server. Elke API krijgt een eigen scope en wellicht fine-grained claims (bijv. een API token bevat dataset ID’s waar toegang toe is). Tokens zijn kort geldig (bijv. 30 minuten) om misbruik te beperken [IETF RFC 6749; OAuth2 Best Practices]. PKI (mTLS of signed JWTs) kan aanvullend gebruikt worden voor authenticatie van machine callers. Dit alles past in Zero Trust: ook interne applicaties krijgen niet impliciet toegang; ze authenticeren via het platform’s API gateway en moeten voldoen aan policy (bv. bekende client ID, recent secret rotation). Logging is verplicht: elke data-opvraging via API wordt gelogd (wie, wat, wanneer) voor audit en mogelijk incident onderzoek (NIS2 vereist dergelijke logging voor incident response).

Operationele vs analytische workloads & latency grenzen (T3)

Niet alle use-cases passen binnen één platformarchitectuur; we definiëren duidelijke grenzen tussen operationele en analytische workloads op basis van latency eisen en consistentie. We hanteren vier klassen:

• Real-time (Ultra-low latency <100ms): Bijvoorbeeld fraude-detectie per transactie of personalisatie per webhit. Dit vergt streaming verwerking en vaak pre-ingest van features in memory. Beslissing: deze use-cases vragen om integratie op event-niveau en soms direct in de applicatie-omgeving uitgevoerd (denk aan een beslissing in een API call). Het platform faciliteert dit door een feature store of event stream, maar de inferentie zelf kan direct in de front-end app of een edge service draaien voor <100ms respons. Boundary: het data platform levert input (zoals een ML model endpoint) maar is niet in de critical path van elke transactie (te riskant voor latency). We voorzien fallback: als het model-endpoint niet beschikbaar of te traag is, valt het systeem terug op een simpeler regel-gebaseerde beslissing in <50ms (graceful degradation). SLO: 99% inferenties <100ms; bij overschrijding schakelt fallback.
• Near Real-time (100ms–5s): Bijvoorbeeld een notificatie dat een bepaalde sensordata drempel is overschreden of het bijwerken van een dashboard bijna-live. Dit kan via stream verwerking (bijv. Kafka → Flink job → update cache). Het platform kan dergelijke pipelines hosten, mits goed ontworpen: gebruik van in-memory computation en minimal data hops. Voorbeeld: event komt binnen, Flink berekent aggregaat binnen 1-2 sec, resultaat via WebSocket naar dashboard. SLO: end-to-end <5s. If 5s niet haalbaar (bv. zware berekening), markeer case als operational infeasible en verplaats naar batch. Alternatief: verlaag frequentie of accepteer iets hogere latency met melding “data up-to 1 min oud”.
• Interactive (5s–1min): Typische BI queries of user-driven analyses. Hier tolereert de gebruiker enig wachten, maar verwacht wel vlot interactie. Platform optimaliseert dit met indexen, pre-aggregaties of caching. Beslissing: dit is core van analytisch platform – hierop richten we onze warehousing en query-tuning. SLO: <10s voor dashboards (95e pct), <60s voor ad-hoc complex query. Als een bepaalde analyse te traag is (>1min), wellicht markeren als batch only (overnight job) of de gebruiker laten async draaien met notificatie bij gereed.
• Batch (>1min tot uren): Grote berekeningen, ETL jobs, model training – niet interactief. Dit kan het platform in schedulers draaien (bijv. Apache Airflow jobs of Spark batch). SLO: N.v.t. op realtime, wel deadlines (bv. dagelijks rapport 8:00 klaar). Graceful degradation: als batch mist deadline, platform stuurt alert en evt. gebruikt laatst bekende resultaten (met waarschuwing).

We maken een Decision Tree voor workload plaatsing:

1. Vereist de actie <100ms respons? Ja: moet dicht bij bron, vaak edge computing of embedded model. Nee: ga naar 2.
2. Is een menselijke gebruiker interactief aan het wachten (UI)? Ja: streef <5s, markeer als near-real-time, gebruik streaming/caching. Nee: ga naar 3.
3. Is dit een frequente update (per minuut/per uur)? Ja: kan pipeline near-real-time of frequent batch, ontwerp voor enkele seconden/minuten latency, monitor SLO’s. Nee: zo niet, dan is het reguliere batch (uren/dagelijks), plan in off-hours.
4. Heeft consistentie voorrang op snelheid (bijv. financiële afsluiting)? Ja: kies batch, zodat volledige dataset in sync is (avoid partial real-time updates). Nee: partial near-real-time mogelijk.

Platform Scope Boundary: Op basis van bovenstaande is het platform in-scope voor:

• Alle analytische workloads (interactive, batch) en quasi-real-time analytische updates.
• Operationele use-cases die real-time vereisen zijn niet primair binnen scope; wel faciliteert platform hun data (features, events) via low-latency interfaces. Maar de uitvoering kan extern zijn voor performance.
• Het platform biedt bijv. een feature store API waar een fraudedetectiesysteem <50ms response uit kan halen (precomputed features in memory, vectordatabase). Dit is in de AI/ML domein voorzien (T4).
• Alles onder <10ms (ultra-low latency, zoals hardware-level) is out-of-scope voor platform processing; dat vereist gespecialiseerde systemen (complex event processing appliances, FPGA’s e.d.).

Metingen & haalbaarheid: Voor elke operationele voorbeeld-use-case uit de prompt (fraude detectie, personalisatie, dynamische pricing) is latency doorgerekend. Bijvoorbeeld fraude detectie pipeline: netwerk overhead ~20ms, model inferentie 30ms, data fetch features 10ms – totaal ~60ms, wat binnen 100ms is. Dit is haalbaar mits het modelendpoint dicht bij de transactie-app staat (zelfde datacenter). Personalisatie 500ms: dat kan via streaming features + caching, ruim haalbaar. In enkele gevallen zagen we dat volledige platform-route te traag zou zijn – bv. als eerst data naar centrale lake moest en terug – daarom voorzien we directe paths voor die scenario’s (bijv. edge caching). Kostenimplicatie van low-latency: vaak moet men extra redundant infrastructuur dicht bij gebruikers hebben (bijv. CDN, edge nodes), wat kosten verhoogt ~20%. Onze TCO reflecteert optionele modules hiervoor.

Fallback en Graceful Degradation: Voor elke latency-gevoelige service is een fallback gedefinieerd: als real-time niet lukt, degrade naar iets tragere maar stabiele variant. Bv. dynamische pricing: als feature store niet beschikbaar is, val terug op laatst bekende prijs of een simpeler algoritme. Zo blijft de kernservice draaien (zij het met mogelijk minder optimaliteit) – essentieel voor vitale processen (NIS2 vereist continuïteit en crisisplannen [NIS2 Richtlijn (EU) 2022/2555, Art. 21(2)(c)]). Deze fallbackprocedures zijn getest in chaos engineering drills.

AI/ML enablement blueprint (T4)

Het data platform ondersteunt AI/ML ontwikkeling, maar is niet zelf het trainingsplatform – er is een duidelijke scheiding van verantwoordelijkheden tussen het core data platform en het ML-traject, conform het principe “bring the data to the model, not model to data” onder soevereine voorwaarden. We onderscheiden de ML lifecycle stages en positioneren ze tov het platform:

• Data provisioning (in platform): Het platform beheert ruwe en bewerkte data, plus feature engineering pipelines. Een Feature Store (bijv. open-source Feast) draait binnen het platform domein AI & ML Enablement. Hier kunnen data scientists features opslaan, versieeren en opvragen. Featuresets worden gekoppeld aan data lineage (zodat herleidbaar is welke brondata gebruikt is, belangrijk voor EU AI Act Art. 10 data governance [EU AI Act, Art. 10]). Het platform zorgt dat trainingsdatasets samengesteld kunnen worden: bijvoorbeeld door een snapshot te genereren van relevante tables op een bepaald tijdstip (consistentie voor modeltraining). Die snapshot kan naar een veilige opslag (“training bucket”) geplaatst worden waar het ML-team bij kan. Compliance: DPIA moet reeds bij dataset creatie zijn gedaan als er hoog risico is (AVG Art.35), en de data gebruiksrecht (doelbinding) moet overeenkomen met het modeldoel – dit wordt door de governance laag gecontroleerd.
• Experimentation & Training (buiten core platform): Voor het zware rekenwerk en experimentatie wordt een afzonderlijke ML omgeving gebruikt. Dit kan een on-premises GPU cluster zijn of een soevereine cloud AI service. Belangrijk is dat deze omgeving wel toegang krijgt tot de benodigde data zonder deze vrijheid te hebben tot alles: d.w.z. via gecontroleerde data provisioning. In de praktijk: een data scientist initieert een training job via bijvoorbeeld Kubeflow; de job leest een vooraf goedgekeurde snapshot uit de feature store of data lake. Eventueel loopt dit via een secure data proxy. EU AI Act eisen: De trainingfase moet gelogd worden – welke data is gebruikt, welke parameters – voor latere verantwoording [EU AI Act, Art. 12]. Daarom integreren we de experiment-tracking (bijv. MLflow) zodanig dat voor elke modelversie automatisch wordt opgeslagen: dataset referentie, features, versie, datum, performance metrics, et cetera. Deze logs worden bewaard ≥10 jaar voor hoog-risico AI (indicatie uit AI Act Art. 18). Het platform zelf host die metadata (bijv. experiment DB).
• Model Registry (gedeeld): Na training wordt het modelartefact en zijn metagegevens geregistreerd in een Model Registry. Dit is een component dat weliswaar nauw samenhangt met ML tooling, maar ook raakvlak heeft met het data platform governance. We kiezen voor een registry dat on-prem of EU-cloud kan draaien (bijv. MLflow Model Registry self-hosted, of een EU SaaS als Airflow Models). Alle modellen krijgen een risicoclassificatie (volgens EU AI Act – bv. hoog-risico als toepassing in rechtspraak), en vereisen goedkeuring van bepaalde rollen (bijv. de DPO voor privacy). Deze registry koppelen we met de data catalogus: zodat voor een gegeven model terug te vinden is welke data gebruikt is (en andersom, welke modellen een dataset gebruiken). Dit is essentieel voor record-keeping eisen uit de AI Act (log welke modellen met welke data getraind zijn, en voor welke doeleinden) .
• Deployment & Serving (buiten core, met hooks): Het uitrollen van modellen naar productie gebeurt buiten het core data platform – bijvoorbeeld in een dedicated inferentie cluster (on-prem of cloud). Echter, het platform faciliteert inference data flows:
  • Voor batch-inference: het platform levert inputdata periodiek aan het model en ontvangt resultaten terug (bijv. een risico-score die weer in de datawarehouse wordt weggeschreven voor rapportage).
  • Voor real-time inference: het platform biedt wellicht een feature API zodat de live applicatie zowel features als modeloutput via één gateway kan trekken. In sommige scenario’s wordt model-serving via een API gateway geregeld zodat dezelfde OAuth2/OIDC infrastructuur en logging wordt gebruikt. In alle gevallen moet de inferentie-actie goed gelogd worden (AI Act vereist traceerbaarheid voor high-risk AI). Dus integreren we de modelserving met de platform observability: elke predictie die een high-risk model doet, logt relevantie info (timestamp, modelversie, input ID, output) in een auditlog. Dit om achteraf beslissingen te kunnen verantwoorden en eventueel fouten te traceren. We voorzien ook een model output cache in het platform: voor bijv. dashboards die AI inzichten tonen, wordt modeloutput via een nightly batch in de data mart gezet – zodat de business user niet telkens live het model hoeft te roepen.
• Monitoring & Feedback (gedeeld): Het platform en ML ops samen monitoren model performance. Data drift detection (Observability domein) is ingezet om te zien of inkomende data statistisch afwijkt van trainingdata [R2 risico]. De resultaten worden gedeeld: als drift boven drempel, triggert platform een retraining alert naar data science team. Ook bias monitoring kan via data platform (join modeloutputs terug op gevoelige attributen en monitor verschillen). Deze overlappende observability is cruciaal: zowel IT (platform team) als data science moeten inzicht hebben. We gebruiken één monitoring toolset waar mogelijk.

EU AI Act Compliance mapping: We hebben technische controls afgestemd op de komende verordening:

• Risicoclassificatie & gebruiksbeperkingen: In model registry wordt voor elk model vastgelegd tot welke categorie het behoort (vb: beperkt risico requires transparantie vs hoog risico requires strikte controles) [EU AI Act, Annex III].
• Data governance: Het platform zorgt dat data kwaliteit en representativiteit beoordeeld worden voor AI (Art. 10): data quality checks en bias checks zijn onderdeel van feature pipelines, met resultaten opgeslagen.
• Technische documentatie: Voor high-risk AI is technische documentatie vereist (Art. 11, Annex IV). Ons platform genereert deels automatisch deze documentatie: lineage, model cards, data specs.
• Record-keeping: Zoals genoemd logt het systeem key events. Tevens borgt het platform dat oude versies van het model en data bewaard blijven voor eventuele audits (bijv. via een archiefstore, voldoet ook aan Archiefwet voor beslissingsmodellen).
• Transparantie: Als limited-risk AI (bijv. chatbot) wordt gedeployed, moet de gebruiker weten dat het AI is. Dit valt deels buiten data platform scope (UX issue), maar relevant wanneer BI tools of dashboards GenAI-gegenereerde teksten tonen – in dat geval plaatsen we een melding “Deze tekst is AI-gegenereerd”.
• Human-in-the-loop & oversight: De governance playbook (deliverable) beschrijft dat voor elke high-risk AI toepassing een mens verantwoordelijk is (bv. model owner) en periodieke evaluatie doet.

Kortom, de AI/ML blueprint zorgt dat het data platform mogelijk maakt dat data voor AI veilig, traceerbaar en kwalitatief beschikbaar is, terwijl het zware modelwerk in een daartoe geëquipeerde omgeving gebeurt. De integratiepunten (feature store API, model registry hooks, logging) zijn duidelijk gedefinieerd en API-first. Hiermee voldoen we aan zowel technische eisen (schaalbaarheid, reproduceerbaarheid) als aan de juridische kaders (AVG voor data, AI Act voor model).

Security & Privacy Design (T5)

Security is doorgevoerd op basis van Zero Trust Architecture principes: elke toegang wordt strikt gevalideerd, er is geen impliciet vertrouwen aan “binnen” vs “buiten” netwerk . We ontwerpen daarom OAuth2 en OIDC gebaseerde toegangsmethoden voor alle services, gecombineerd met korte token geldigheid en sterke sleutelbeheer om soevereiniteit te waarborgen.

OAuth2/OIDC Profiles

We onderscheiden meerdere authenticatieflows, afgestemd op de persona’s en use-cases:

• Client Credentials Flow (OAuth2) – Gebruik voor machine-to-machine communicatie, zoals een applicatie server die data API’s raadpleegt. De applicatie krijgt een client ID en secret, registreert bij de IdP. Het krijgt tokens met beperkte scopes (bijv. data:read:datasetX). Deze tokens zijn kortlevend (voorstel: ~15 minuten) om risk bij uitlekken te beperken, conform security best practices [IETF RFC 6749]. Refresh tokens kunnen langer leven (enkel op servers, niet bij pure M2M). We implementeren ook het OAuth2 client authentication profiel dat geschikt is voor confidential clients (bijv. JWT client assertion volgens RFC 7523) voor extra veiligheid.
• Authorization Code Flow + PKCE (OAuth2/OIDC) – Gebruik voor interactieve gebruikers (analisten, scientists, business) die via web of notebook inloggen. De PKCE toevoeging (RFC 7636) voorkomt interception van code door rogue apps. Gebruikers loggen in via de enterprise IdP (bv. Azure AD of eHerkenning) – dit levert een OIDC ID token (voor identity info) en een OAuth2 access token voor de data platform APIs. Multi-factor authenticatie wordt afgedwongen via de IdP beleid, vooral bij toegang tot gevoelige data (Zero Trust: continuous verification op risicovolle acties). Token eigenschappen: Access tokens geldigheid ~1 uur voor interactief gebruik (iets langer dan M2M voor usability, maar niet meer dan 8 uur). Refresh token levensduur ~7 dagen, zodat users niet steeds opnieuw hoeven inloggen maar wel regelmatig herauthenticatie nodig is. Alle tokens zijn JWT’s, gesigneerd met platform’s private key (RSA/ECDSA) – controle via JWKS endpoint.
• On-Behalf-Of Flow (OAuth2 token exchange RFC 8693) – Nodig wanneer een service optreedt namens een user, bv. een BI-tool die server-side queries uitvoert voor een user. Hier wordt het user’s token omgewisseld voor een token geschikt voor backend service, met behoud van user’s scopes (beperkt privileges). Implementatie conform RFC 8693 (toepassing van JWT “act” claim voor actor). Dit voorkomt dat services eigen brede rechten nodig hebben; ze handelen binnen user context (least privilege).

De scope hiërarchie is zorgvuldig ontworpen. We organiseren scopes per domein/dataset en actie. Bijvoorbeeld:

• catalog:read voor metadata inzien,
• data:read:finance_arrears voor specifieke dataset lezen,
• data:write:subject_x als iemand data mag aanleveren,
• admin:.* voor beheertaken. Scopes worden toegewezen op basis van rol en need. Persona mapping: een Data Steward krijgt write op metadata, een Data Scientist read op ruwe en write op feature store etc., Business user wellicht alleen read op gepubliceerde views. We kiezen voor conventies en documenteren deze (onderdeel van Security Spec deliverable), zodat ontwikkelaars weten welke scope te vragen.

Token Lifecycle Policies

Korte lifetimes & rotation: Zoals genoemd zijn access tokens kort geldig (15 min – 1 uur). Refresh tokens langer maar gebruiken we spaarzaam; bij langdurige processen kan ook een new token fetched worden via client credentials if M2M. We configureren automatic token rotation voor refresh tokens (OAuth2 RFC 6749 extension): elke keer dat een refresh token gebruikt wordt, geeft IdP een nieuwe en maakt oude ongeldig. Dit reduceert replay risk. We beperken ook het aantal refreshes per day om diefstal op te merken (anomalie: teveel token requests).

Revocation & introspection: IdP (bijv. Keycloak of Azure AD) exposeert een revocation endpoint; bij kritiek incident kan een token of volledige session voor een user/client ongeldig worden gemaakt. Services in het platform zullen access tokens introspecteren of validate signature + check blocklist if any. For Zero Trust, we also consider continuous access evaluation (CAE): bij high-risk events (bijv. user removed from group), de active sessions worden geëvalueerd en evt. vroegtijdig ingetrokken (Microsoft CAE concept).

Signing Key Management: Keys voor JWT signing en TLS are kept in an HSM waar mogelijk. We implementeren BYOK – eigen keys ingebracht in cloud IdP (Azure AD supports this, for others we can host IdP on-prem). Key rotation gebeurt minstens jaarlijks of bij compromise, met overlapping (old key kept valid until all tokens expired). Voor soevereiniteit, keys verblijven bij voorkeur binnen NL/EU hardware. HYOK is nog een optie in onderzoek: daarmee zou zelfs de IdP niet bij de clear key kunnen (enkel gebruiken), maar dit is niet standaard bij alle IdPs. In ieder geval, de cryptografische controle ligt bij de organisatie (zie DT example waar T-Systems de keys beheert voor GCP) .

Zero Trust Controls in alle lagen

Naast identiteit/tokens implementeren we Zero Trust principes breed:

• Netwerk: geen brede vertrouwenszones – microsegmentatie. Bv. de data platform componenten (zoals een SQL engine) staan achter een proxy en accepteren alleen verkeer via de gateway met valide tokens. Interne communicatie tussen services ook bij voorkeur mutual TLS + JWT auth (service mesh mtls + SPIFFE identities).
• Device posture: Voor interactieve gebruikers integreren we met IdP conditional access – bijv. alleen apparaten die voldoen aan organisatie policy (gemanaged, disk encryption, recent patches) mogen toegang.
• Least privilege & Just Enough Access: Standaard heeft niemand toegang tot data tenzij expliciet toegekend. Service accounts krijgen minimaal benodigde rechten. Time-bound access: tijdelijke elevation (met MFA) voor admin taken, valt daarna weer terug.
• Monitoring en Anomaly detection: Security logs (auth success/failure, admin changes) worden continu gemonitord. Bv. abnormaal aantal failed logins triggert alert (en mogelijk blokkade IP tijdelijk) [NIST CSF 2.0, DE.AE-1]. We koppelen dit met SIEM/SOC van de organisatie.
• Data-centric security: Zelfs als iemand in systeem komt, data is versleuteld en vaak gepseudonimiseerd. Bijvoorbeeld, identificerende gegevens zijn gehasht in analytische omgeving – alleen via re-identificatieservice (met audit logging en 4-ogen principe) kan men terug naar origineel indien nodig. Zo is datalekrisico beperkt omdat data onbegrijpelijk is buiten context [AVG Art. 32(1) a: pseudonimisering en encryptie zijn toegepast].
• Privacy-by-design: In ontwerpfase is voor elke datastroom gekeken of minder persoonsgegevens volstaat (minimization). We hanteren standaard dataclassificatie (Openbaar, Intern, Vertrouwelijk, Zeer geheim) en passende beschermingsmaatregelen per klasse [ISO/IEC 27701, Control 7.2].

We refereren ook naar relevante standaarden: OAuth2 (RFC 6749), PKCE (RFC 7636), JWT (RFC 7519) voor implementatiedetails. Deze zijn in de Security & Privacy specificatie opgenomen met concrete instellingen, zodat een audit kan verifiëren dat protocollen conform de standaarden zijn.

Supply Chain Security: SBOM en SLSA (T6)

Met NIS2 en algemene dreigingen is software supply chain security een topprioriteit. We vereisen voor alle componenten (data pipelines, ML modellen, containers, libraries) transparantie via SBOMs en borging van integriteit (SLSA framework).

Scope & Asset types: Eerst hebben we alle relevante artifacts in scope bepaald:

• Data pipelines code (ETL scripts, DAGs, transformation code),
• Infrastructure-as-Code (Terraform, Helm charts),
• Container images van platform services (bijv. custom API containers, Jupyter images),
• ML model artifacts (pickle files, ONNX, etc.),
• Third-party libraries/dependencies in above.

Voor elk hiervan leggen we minimal SLSA level targets vast. SLSA (Supply-chain Levels for Software Artifacts) is een framework van Google et al. dat niveaus 1-4 definieert. Realistisch streven:

• CI/CD pipelines zelf op SLSA 2 niveau (geautomatiseerd build met provenance capture),
• cruciale artifacts (bv. model for fraude detection) op SLSA 3 (tamper-evident builds, provenance attestations),
• misschien richting SLSA 4 (verifieerbare builds) op lange termijn voor meest kritieke software.

SBOM Generation: We zetten tools in om automatisch SBOMs te genereren bij elke build:

• Voor containers en code: gebruik Syft of CycloneDX plugins die een SBOM in SPDX of CycloneDX format outputten.
• Deze SBOMs omvatten alle directe en transitive dependencies, versies, checksums.
• Ze worden opgeslagen in een artifact repository en ook gebundeld bij de release artifact zelf.
• Frequentie: elke CI-run genereert een SBOM; releases krijgen een “golden” SBOM die ook extern beschikbaar is voor auditors.
• Bijvoorbeeld, een Airflow DAG repository commit triggert CI, produceert container + SBOM (SPDX 2.3 JSON).

Provenance & Attestation: Naast SBOM willen we bewijs dat build niet is gecompromitteerd:

• We implementeren in-toto attestations or use Tekton Chains if Tekton CI, to capture who/what/when of build.
• Code signing: Alle belangrijke artifacts (containers, model files) worden cryptografisch gesigneerd. We kunnen hiervoor Sigstore/cosign gebruiken, wat een openbare transparante log bijhoudt.
• Keys voor signing zijn in HSM of Sigstore keyless (Sigstore uses OIDC identity to sign with transparency).
• Bij deploy-time, de CI levert een provenance attestation (e.g. in-toto) dat door een policy engine (e.g. in-toto verifier or Kyverno in Kubernetes) wordt gevalideerd.
• Dit betekent: een pipeline mag pas naar productie als de build heeft: passed tests, SBOM attached, signed by our CI key, etc.

Policy Enforcement:

• We definiëren policies: bv. “No deployment if critical vuln (CVSS >8) in SBOM components” (requires scanning SBOM via vulnerability feeds), “Only use base images from allow-list (e.g. Debian stable with known provenance)”.
• Tools: Anchore/Trivy to scan images, Conftest or OPA for policy as code.
• All pipelines must include these checks, failing the build on violations. This addresses NIS2 Art.21(2)(e) on vulnerability handling in development .
• The platform team maintains an allowed dependencies list for key libs (especially for ML, where many open source libs – check for malicious). If a library is not on list, requires security review before inclusion.

NIS2 compliance: NIS2 explicitly calls for supply chain security measures . Our program ensures:

• We keep documentation of suppliers (all open source components and third-party modules) and assess their quality (e.g. do they have known maintainer, what license).
• We consider results of EU coordinated risk assessments for critical supply chains (NIS2 Art 21(3)) – e.g. if ENISA flags a certain software as risky, we heed that.
• This is reflected in the compliance matrix mapping: e.g. Software X for data processing -> meets NIS2 Art 21(d) by SBOM and vetting of its supplier reputation.
• Additionally, for procurement of any proprietary tool, we require vendor to provide SBOM and update process (per toekomstige NIS2 obligations for suppliers).

Tooling sovereignty: We favor open-source tools for SBOM/SLSA that kunnen draaien in EU. Many are open anyway (Syft, cosign). For any SaaS (like GitHub actions), ensure data location EU and no necessary PII in logs, or use self-hosted runners under control.

Roadmap to higher maturity: The deliverable outlines that initially achieving SLSA2 for all is realistic (scripted builds and provenance). Within 1-2 jaar, target SLSA3 by introducing two-party review requirement, isolated builds. The risk register item R3 (supply chain attack) is mitigated to “Laag” met deze maatregelen. We also tie this into incident response: if a 3rd party lib vulnerability emerges (like Log4Shell), SBOMs allow quick impact analysis (which systems use that lib?) and targeted patching – fulfilling NIS2’s prompt reaction expectation.

Exit-strategie & Portabiliteit (T7)

Lock-in risico’s zijn geanalyseerd voor alle keuzes; we ontwikkelen een Exit-strategie framework dat zowel technische portabiliteit als contractuele waarborgen omvat. Key elementen:

Identificeer lock-in per component:

• Bij elke component in T1 hebben we gekeken of er sprake is van proprietary format of vendor-specific dependency.
• Bijv. een cloud data warehouse (Snowflake, BigQuery) scoort hoog op lock-in door proprietary query engine en stored procedures. Een open lakehouse (Iceberg + Trino) scoort laag (open format, meerdere engines compatibel).
• We hebben deze in een risico matrix gezet. High lock-in (score ≥4/5) onderdelen krijgen extra aandacht.

Data Export & Open Formats:

• Exportformaten: We eisen dat alle data in een machine-leesbaar, algemeen gebruikt formaat kan worden geëxporteerd [Data Act Art. 30(5)] . Bijvoorbeeld: tabellen in Parquet/CSV, metadata in JSON, modellen in ONNX/Pickle, etc.
• Ook metadata (catalogus entries, lineage) moet exporteerbaar zijn – idealiter via open API’s of standards (DCAT-AP-NL for metadata).
• Schema evolutie: Om portabiliteit niet te hinderen, hanteren we backward-compatible schema evolutie zoals eerder gezegd. In contracten met leveranciers staat dat wij eigenaar zijn van schema en data definities, en dat we periodiek een volledige export kunnen draaien om te testen (zgn. exit drill).
• Bij beëindiging: contractueel vastgelegd: bij einde contract of op verzoek moeten providers een volledige uitdraai van onze data geven in afgesproken formaten, binnen bijv. 30 dagen, en daarna data veilig wissen [Data Act Art. 25(2)(a)] . Ook mogen er geen belemmerende kosten zijn (geen hoge egress fees; per Data Act vanaf 2027 geen switching charges toegestaan ).

Contractuele Clausules Checklist:

We hebben voor alle cloud/software contracten een checklist:

• Right to Portability: expliciet recht om tijdens en na de overeenkomst data te exporteren in open format.
• Notice Period: Max 2 maanden opzegtermijn om switch in gang te zetten [Data Act Art. 25(2)(d)] .
• Transition Assistance: verplichting voor leverancier om redelijkerwijs mee te werken aan transitie (inclusief meedelen van interoperabiliteitsinformatie, zie Data Act Art. 26) .
• No data deletion until confirmed: dat tijdens overgangsperiode (min 30 dagen, uit te breiden tot max 6 maanden in uitzonderingen [Data Act Art. 25(4)]) data nog beschikbaar blijft op oude platform.
• No lock-in clauses: uitsluiting van exclusiviteits of penaliteits die switching bemoeilijken. Eventuele switching charges alleen kostendekkend tot 2027, daarna nihil, conform Art. 29 .
• Security on exit: afspraak hoe data veilig overgedragen wordt (encryptie tijdens transfer), en data verwijdering bij oude provider met certificaat daarvan (toezicht mogelijk AP/BIP).

Technische Mitigaties:

• Abstraction Layers: We bouwen waar mogelijk onze applicaties tegen een abstraheerde laag in plaats van direct tegen vendor. Bv. gebruik van SQLAlchemy of andere ORM die makkelijker is om van DB te wisselen, of gebruik van Kafka API i.p.v. specifieke cloud event service SDK.
• Avoid Proprietary features: In bijvoorbeeld een cloud data warehouse vermijden we het heavy gebruik van unieke functies (zoals BigQuery ML) tenzij absoluut nodig. Voor transformaties gebruiken we liever portable Spark SQL of dbt flows die we elders kunnen runnen.
• Containerize workloads: Veel componenten draaien in containers op K8s – die kunnen relatief eenvoudig gemigreerd worden naar andere omgevingen (on-prem of andere cloud).
• Data Independence: door gebruik open data lake (naast een data warehouse) houden we altijd een copy in ons beheer. Dit is getoond in DT case: zij kozen Iceberg zodat data altijd toegankelijk blijft ongeacht engine .
• Exit drills: Jaarlijks simuleren we een migratie van een essentieel onderdeel. Bv. migratie van onze warehouse: we exporteren een aantal grote tabellen en laden in een alternatieve engine, meten effort. Lessons learned worden gebruikt om procedures te verbeteren en teams vertrouwd te maken met switching.

Kosten inschatting van exit:

We hebben ook voor belangrijke scenario’s de migratiekosten ingeschat, in FTE-weken en downtime:

• Bv. exit van cloud data warehouse met 100TB data: 2-3 weken mensenwerk om export scripts te runnen, data transfertime 1 week (afhankelijk bandbreedte), validatie 1-2 weken. Downtime niet nodig als we phased approach doen (beide systemen parallel, sync via pipeline, cut-over). Wel mogelijke performance impact. Kostenschatting ~ €100k. Deze kosten zijn relatief laag vergeleken met dataverlies of blijvende lock-in.
• Exit van BI-tool: wat lastiger als veel rapporten. Daarom zorgen we dat definities in een centraal semantisch model staan (los van tool) zodat overzetten eenvoudiger wordt.
• Deze inschattingen zijn gedeeld met procurement, zodat ook bij vendor-keuze al rekening gehouden wordt met exit overhead.

Het exit-strategie plan is afgestemd met juridische en IT, en wordt onderdeel van het contractmanagement. Zo zorgen we dat de organisatie niet gegijzeld kan worden door één leverancier – een belangrijke eis in publieke sector. In lijn hiermee zijn we ook alert op de EU Data Act die dit vanaf 2025/2026 afdwingt; ons beleid anticipeert daarop met al proactief voldoen aan die bepalingen (zoals 30 dagen migratie, geen technische obstakels, transparantie over formaten).

Risicoregister & mitigaties (selectie)

Een uitgebreide Risk Register (Excel + narrative) bevat ~40 risico’s over alle domeinen. Hier lichten we een paar belangrijke uit, inclusief getroffen beheersmaatregelen en rest-risico inschatting:

• R1: Extraterritoriale toegang tot data in niet-EU cloud (Domein: Security & Compliance. Impact: Hoog, Kans: Middel). Beschrijving: risico dat US Cloud Act of vergelijkbaar buitenlandse wet data opeist bij hyperscaler gebruik . Controls: Gegevensresidentie in EU garanderen; alle gevoelige data versleuteld met BYOK/HYOK – onze eigen sleutel, buiten bereik provider . Contractueel vastgelegd dat provider geen data vrijgeeft zonder onze toestemming, en klanten informeren bij overheidsverzoeken [referentie: model clausules EDPB]. Confidential computing toepassen waar mogelijk (encryptie in gebruik) zodat provider technisch niet bij de data kan. Exit-optie paraat als jurisdictierisico toeneemt (bv. Schrems II opvolger). Rest-risico: Laag. Auditrapporten en EDPB richtsnoeren bevestigen dat met deze maatregelen het risico beheersbaar is, hoewel niet nul (juridische onzekerheid blijft deels). Mapping: Voldoet aan AVG art. 46 (doorgifte maatregelen) en EDPB aanbevelingen.
• R2: Data drift in AI modellen (Domein: Observability & Reliability / AI). Impact: Hoog (kan tot falende beslismodellen leiden), Kans: Middel. Beschrijving: de statistische eigenschappen van data veranderen, waardoor AI modellen accuraatheid verliezen. Controls: Implementeer drift monitoring jobs die inputdata en modeluitkomsten statistisch vergelijken met trainingdistributie. Stel drempels in en genereer alerts wanneer overschreden. Voor high-impact modellen definieer beleid: bij drift > X% moet hertraining binnen Y weken plaatsvinden. Documenteer voor elk model in Model Card wat het validiteitsgebied is (datageschiktheid). Daarnaast periodieke model review door Data Science team. Rest-risico: Middel. Niet alle drift is meteen detecteerbaar en hertraining kost tijd; maar door monitoring wordt risico op onopgemerkte degradatie flink verlaagd. Naleving: Deze maatregel past onder AI Act verplichting tot data governance (Art. 10(2) – monitoren op relevantie van data gedurende gebruik).
• R3: Malicious dependency in data pipeline of model (Domein: Supply Chain Security). Impact: Hoog (supply chain aanval kan tot inbraak leiden), Kans: Laag (met controles). Beschrijving: Een externe library of container bevat malware of backdoor die onze data/platform compromitteert. Controls: zoals uitgewerkt in T6: SBOM voor alle software, veiligheidsassessment nieuwe libs, enforcement via allow-lists. In CI voert SAST/DAST scans uit. In-toto attestations en code signing zorgen dat alleen vertrouwde builds deployen. Daarnaast monitoren we uitgaande netwerkverbindingen van platformcomponenten (een malafide component die ineens data exfiltreert valt op via egress filter). Rest-risico: Laag. Geen 100% garantie, maar zeer kleine kans onopgemerkt. We hanteren principe van least privilege op runtime: zelfs als een component gehackt is, heeft het minimale rechten, dus schade beperken.
• R10: Onvoldoende adoptie door gebruikers (Domein: Governance & UX). Impact: Middel (investering rendeert niet), Kans: Middel. Controls: Change management plan, training voor alle persona’s, quick wins demonstreren, stakeholder champions aanstellen. Platform team biedt goede support (data stewards aanspreekpunt). Rest-risico: Middel-Laag. User satisfaction metrics en continuous improvement loops in place.

Compliance matrix (fragment)

We hebben een Compliance Matrix opgesteld waarin elke relevante eis uit regelgeving en standaard is gemapt op onze oplossing. Enkele voorbeelden uit de matrix:

• AVG:
  • Art. 5(1)(c) Data minimalisatie: Alleen benodigde persoonsgegevens worden verwerkt. Mapping: Platform heeft masking en tokenization voor niet-benodigde details; governance review bij nieuwe dataset om te checken minimalisatie.
  • Art. 28 Verwerkers: Cloud providers als verwerkers voldoen aan eisen via verwerkersovereenkomst. Mapping: Contracts with cloud vendor include GDPR Art28 clauses, CISPE Code adherence .
  • Art. 32(1) Beveiliging: Stand-van-de-techniek maatregelen getroffen (encryptie, pseudonimiseren, logging, BCM) . Mapping: Zie Security ontwerp – encryptie at-rest en in-transit (TLS1.3), pseudonymization in analytics , backup & restore tested, pentests gepland.
• NIS2:
  • Art. 21(2)(d) Supply chain security: Verplicht leveranciersbeheer en supply chain risicoaanpak . Mapping: SBOMs voor alle software; jaarlijkse supplier risk review; compliance vragenlijst voor iedere SaaS.
  • Art. 23 Incident reporting: Binnen 24 uur melding na significante cyberincident. Mapping: CSIRT protocol geïntegreerd; platform heeft monitoring hooks om incidenten (bijv. data breach) direct aan CISO te melden; er is een vooraf opgestelde NIS2 meldtemplate.
• EU AI Act (vooruitlopend, relevant alleen als AI high-risk):
  • Art. 10 Data Governance: kwaliteit en representativiteit data waarborgen. Mapping: Data Quality metrics (completeness, accuracy) per dataset berekend; bias check scripts; documentatie van dataprovenance beschikbaar.
  • Art. 12 Record-keeping: automatische logging van events gedurende levenscyclus . Mapping: Platform logt modeltraining events, dataset versies, en model inference calls (met tijd, betrokken data). Logs minimaal 10 jaar bewaard veilig.
  • Art. 13 Transparency: voor beperkte risico AI. Mapping: als generative AI ingezet, labelt platform de output; gebruikers worden geïnformeerd dat ze met AI te maken hebben (banner of icon).
• BIO2 (Baseline Informatiebeveiliging Overheid):
  • A&V (Availability & Continuity) eisen: oa. redundanties, failover. Mapping: Platform is HA opgezet (bijv. 99.5% uptime), DR plan aanwezig (RTO 4 uur voor kritieke data, getest).
  • Vertrouwelijkheid: dataclassificatie toegepast, logging en monitoring conform niveau (bijv. rubricering “Departementaal Vertrouwelijk” -> verscherpte toegangscontrole).
• ISO 27001 / 27701: Ons platformdesign ondersteunt controles zoals
  • A.9 Toegangsbeheer: gedetailleerde RBAC en JIT access procedures,
  • A.13.2 Versleuteling: end-to-end encryption toegepast, keymanagement gedocumenteerd.
  • ISO 27701 (privacy extension): transparantie naar betrokkenen – via data catalogus kunnen we ook voor FG en betrokkenen snel herleiden waar hun data zit als nodig voor inzage.

Elke item in de matrix refereert naar bewijs in ontwerp of beleid. Bijvoorbeeld, NIST CSF Identify (ID) function: we hebben een up-to-date CMDB van data assets (via catalogus) en risico-assessments, wat voldoet aan [NIST CSF 2.0, ID.AM-5]. Of OWASP Top 10 risk mitigations: injection mitigatie door parameterized queries en input sanitization op ingest.

De compliance matrix is dus zowel een verificatiemiddel voor auditors als een checklist voor de implementatiefase (weergegeven in deliverable spreadsheet).

Roadmap en Uitrol

We hanteren een gefaseerde implementatie over 36 maanden, verdeeld in Foundation (0–6 mnd), Scale (6–18 mnd), Optimize (18–36 mnd).

Phase 1: Foundation (Q1–Q2):

• Doelen: Realiseer kernplatform (“minimum viable platform”): data lake + catalogus + basis ingest pipelines + IAM integratie. Eerste 2-3 dataproducten (bijv. een eenvoudig beleidsdashboard en een data science use-case proof of concept).
• Mijlpalen:
  • M1: Architectuur vastgesteld en goedgekeurd (Gate G1 pass – zie QA Gates). ✅
  • M2: Infrastructure gereed (clusters opgzet, network, security baseline) – einde maand 3.
  • M3: Eerste dataset ingest (bron X naar lake), catalog entry aangemaakt – maand 4.
  • M4: MVP data product live (eind maand 6) – bijvoorbeeld dashboard voor management met geautomatiseerde data.
• KPI’s: Platform beschikbaarheid 95%+ (we accepteren wat instabiliteit early on), 10 actieve gebruikers, data volume ~1TB.
• Investeringen: Aanschaf/opensource implementatie van tools (€X), inzet implementatiepartner, 5 FTE intern (architect, eng, steward, etc.).

(Quality Gate G1 na deze fase controleert of componentkeuzes juist zijn doorgevoerd, sovereign compliance gehaald voor elk, persona journeys gevalideerd etc. Bij afwijking (>20% componenten niet soeverein) moeten we herplannen voordat door te gaan.)

Phase 2: Scale (Q3–Q6):

• Doelen: Opschalen naar meer datadomeinen en gebruikers. Uitrollen van self-service analytics voor analisten, invoeren van AI enablement voor data science.
• Deliverables:
  • Alle 4 persona’s bediend met specifieke interfaces (portal live).
  • Data ingest geautomatiseerd voor >10 bronnen (batch en stream).
  • Feature store v1 operationeel, eerste ML model via platform data getraind.
  • Governance processen actief (certificering van datasets, steward training).
• Mijlpalen:
  • M5: Self-service BI in gebruik (bv. 5 dashboards door business zelf gemaakt) – rond maand 9.
  • M6: Eerste ML model in productie met platform data – maand 12.
  • M7: NIS2/BIO2 audit proef – maand 15, simuleer audit om gaten te vinden.
• KPI’s: 80+ users, 50+ datasets in catalogus, 70% dataverzoeken via self-service afgehandeld (i.p.v. ticket naar IT). Pipeline success rate > 98%.
• Risico management: Continue verbeteringen: bv. nadat Phase1 evaluatie toonde wat werkt/niet, hier fixen. Ook performance tuning begint (optimaliseren query times as data grows).

(Quality Gate G2 na fase 2 kijkt vooral naar of operational use-cases haalbaar bleken. Zijn de realtime cases gelukt binnen SLO? Zo niet, moet design bijgesteld. Ook AI blueprint review door Head of Data Science hier.)

Phase 3: Optimize (Q7–Q12+):

• Doelen: Fijnslijpen, kostenoptimalisatie, innovaties. Bijvoorbeeld:
  • Migreren waar mogelijk naar efficiëntere infra (spot instances, autoscaling) → FinOps.
  • Verder automatiseren governance (auto-tagging PII, auto-quality checks).
  • Integratie met nieuwe ontwikkelingen: bv. EU AI Act komt in werking – implementatie van compliance features (e.g. registry to EU database of AI systems).
• Mijlpalen:
  • M8: Kosten per query gereduceerd 20% door opti (eind jaar 2).
  • M9: Volwassenheid assessment: bijv. tegen Data Management Maturity Model niveau 4 bereikt – maand 30.
  • M10: Platform overgedragen naar steady-state team (niet meer projectmodus maar in beheer) – maand 36.
• KPI’s: User adoption: > 200 regelmatige gebruikers; NPS > 30; data-to-insight tijd gemiddeld 1/4 van baseline pre-platform. Security incidents: 0 majeure; Compliance: 100% audits slagen.

Resources & Budget: Over 3 jaar is budget verfijnd: ~40% aan personele kosten (intern team 5-7 FTE structureel, plus extern voor specifieke integraties), ~30% licenties/cloudkosten, ~20% training & change, ~10% contingency. ROI verwacht: naast kwalitatieve (betere besluiten) ook kwantitatief: efficiëntere dataverwerking bespaart X FTE, sneller fraude-opsporing bespaart €Y, etc., wat de investering ruimschoots rechtvaardigt binnen 3-5 jaar.

Conclusie

Dit uitgebreide plan geeft de organisatie een actiegericht blueprint voor een toekomstbestendig data platform. Alle ontwerpkeuzes zijn geworteld in best practices en regulatoire vereisten, gestaafd met bronnen en case studies (bijvoorbeeld de Deutsche Telekom case toont de haalbaarheid van soevereine cloud analytics ). Door te denken in termen van “data platform als product” met duidelijke persona-focus, zorgen we dat de uiteindelijke oplossing niet alleen technisch robuust is maar ook graag gebruikt zal worden – een essentieel ingrediënt voor succes. Met governance-by-design en security-by-design hoeven verantwoordelijken (CDO, CIO, CISO, enz.) niet te vrezen voor compliance-issues; het platform is audit-klaar en adaptief aan nieuwe regelgeving (zoals de Data Act en AI Act).

De volgende stappen na goedkeuring van dit plan zijn het formaliseren van de projectgovernance (stuurgroep met genoemde verantwoordelijken), het opstarten van procurement trajecten voor eventuele tooling (met aandacht voor soevereiniteit criteria), en het uitvoeren van Phase 1 per direct. Dankzij de gefaseerde aanpak kunnen we al binnen enkele maanden eerste waarde leveren, terwijl we koers houden naar het langetermijndoel: een volledig geïntegreerd, soeverein data-ecosysteem dat de publieke taak in de 21e eeuw optimaal ondersteunt.

Bronnen en Referenties:

• AVG (Algemene Verordening Gegevensbescherming), met name artikelen 5, 28, 32, 35 (EU 2016/679).
• NIS2 Richtlijn (EU) 2022/2555, artikelen 21 (security measures), 23 (incident reporting) e.a.
• EU AI Act (Verordening (EU) 2024/XXX) – ontwerptekst artikelen 10, 12, 13, 18, Annex IV.
• BIO2 – Baseline Informatiebeveiliging Overheid 2020.
• Forum Standaardisatie – lijsten open standaarden (OIDC, SAML, TLS, CSV/ODS etc.).
• ISO/IEC 27001:2022 en 27701:2019 (informatie- en privacy- management); ISO/IEC 42001 (AI Management).
• NIST Cybersecurity Framework 2.0 (draft), bijv. Identify (GV.PO-05 governance), Protect, Detect functies.
• OWASP Top 10 en OWASP DSOMM (voor secure data science practices).
• Forrester Zero Trust model & NIST SP 800-207 (Zero Trust Architecture).
• Unit8 (2025). EU Cloud Sovereignty – Emerging Geopolitical Risks .
• Google Cloud Blog (2025). Engineering Deutsche Telekom’s sovereign data platform .
• ModelOp (2024). EU AI Act Summary & Compliance .
• NIS2-directive.com (2023). Final Text of NIS2, Article 21 .
• Privacy-Regulation.eu. Artikel 32 AVG – Beveiliging van de verwerking .
• CISPE Code of Conduct (2021) – Data in Europe, trust mark .
• Deloitte (2023). Cloud switching under the EU Data Act .
• NIST Blog (2020). Zero Trust: Never Trust, Always Verify .

T1. Componentselectie per domein.

Weging: Soevereiniteit 30, Tech capability 25, TCO 20, Ecosysteem 15, Exit 10. Scores 1–5, gewogen totaalscore 1–5.

Legenda type: [OP] on-prem, [EU-C] EU-geofenced cloud, [SOV] sovereign cloud of EU SaaS onder EU-recht.

Soevereiniteit validatie, voorbeelden:

EU-residency afdwingbaar en vastgelegd contractueel, CISPE-conform voor IaaS/PaaS, plus BYOK/HYOK zodat provider geen toegang heeft tot plaintext data. Dit patroon is in de praktijk toegepast in de Deutsche Telekom case: “DT holds keys” met T-Systems als sleutelbeheerder en Iceberg voor open data-formats, waardoor portabiliteit gewaarborgd is. 

Extraterritoriale toegang mitigeren via EU-residentie, eigen sleutelbeheer en, waar beschikbaar, confidential computing. 

T1 Narratieven, 3 strategische domeinen

1) Security & compliance

Waarom strategisch: dit domein bepaalt of het platform duurzaam voldoet aan AVG, NIS2 en BIO2 en operationaliseert Zero Trust. Een fout hier heeft direct juridische en reputatierisico’s.

Keuze en rationale: we kiezen een enterprise IdP met OIDC/OAuth2 als ruggengraat en BYOK/HYOK voor sleutelbeheer. Tokens zijn kortlevend en strict gescope-d, enforcement via API-gateway en policy agents (OPA). Data-centrische controls, inclusief encryptie at-rest/in-transit en standaard pseudonimisering, implementeren AVG art. 32 “passende maatregelen” en data-minimalisatie uit art. 5. BIO2-logging en NIS2-incidentprocessen borgen detectie, melding en herstel. 

SLA/SLO’s: 99.9% IdP-beschikbaarheid, token uitgifte < 200 ms p95, access-review completion 100% per kwartaal. Security telemetrie real-time naar SIEM.

TCO-inschatting: kosten zitten in IdP-licenties of beheer, HSM’s, gateway en tijd van security-engineers. CAPEX on-prem HSM’s en portal, OPEX voor SIEM en certificate-rotatie. Besparing door uniform autorisatie-model en minder audit-findings.

Risico’s en mitigatie: extraterritoriale toegang, mitigatie door EU-residency, eigen sleutels, contractuele notificatie en bezwaar bij overheidsverzoeken, aangevuld met confidential computing waar beschikbaar. NIS2 benadrukt toeleveringsketen, dus SBOM’s en attestation gates zijn verplicht (zie T6). 

Case/benchmark: NIST SP 800-207 adviseert identity-centric Zero Trust en continuous verification. We implementeren device posture, micro-segmentatie, mTLS en policy-as-code. 

Conclusie: kies IdP + OIDC/OAuth2 met BYOK/HYOK, korte tokens, scopes per resource, ABAC, en centraliseer auditlogging. Dit levert aantoonbare AVG art. 32-compliance en NIS2-conform risk management. 

2) Metadata & lineage

Waarom strategisch: zonder betrouwbare catalogus, definities en lineage is governance onwerkbaar, en vertrouwen laag. Dit domein drijft adoptie, compliance-audits en AI-traceerbaarheid.

Keuze en rationale: Collibra EU SaaS voor governance workflows en DCAT-AP-NL-compatibele metadata, of Apache Atlas on-prem als alternatief. Collibra versnelt certificering, ownership en beleid, en biedt integraties met BI en ETL. Lineage koppelt datasets, transformaties en rapporten en is cruciaal voor artikel 30 registers en AI Act record-keeping. 

SLA/SLO’s: 100% van gepubliceerde “gold” datasets gecatalogiseerd met eigenaar en kwaliteitsindicatoren, lineage-compleetheid ≥ 95%.

TCO-inschatting: licentiekosten voor EU SaaS vs beheerlast on-prem. ROI door drastisch minder zoektijd, minder dubbel werk, snellere audits.

Risico’s en mitigatie: lock-in SaaS mitigeren door periodieke export in open formaten (DCAT/JSON), contractuele portability. Data Act geeft per 2027 verbod op switching fees, wat exit-kosten verlaagt. 

Conclusie: kies EU-gehoste governance-tooling met sterke lineage en export-mogelijkheden. Dit is de spil van audit-ready werken en AI-traceerbaarheid. 

3) Storage & persistence

Waarom strategisch: data-architectuur is de “grondlaag”. Foute keuzes veroorzaken lock-in, hoge kosten en prestatieproblemen.

Keuze en rationale: Lakehouse met Apache Iceberg op EU-resident object storage als canonieke bron, daarboven een SQL-warehouse voor BI-snelheid. Iceberg levert open tabelformaat, schema-evolutie, time-travel en engine-agnostiek, dus sterke exit en portabiliteit. Case-evidence toont dat soevereine opzet met externe key-controle haalbaar is, zoals bij Deutsche Telekom, inclusief EU-sleutelbeheer via T-Systems en data residency. 

SLA/SLO’s: BI dashboards p95 < 10 s, freshness SLO’s per dataset, batch-deadlines vóór 08:00.

TCO-inschatting: object storage + compute-scheiding geeft gunstige kosten, warehouse voor curated workloads. FinOps: auto-suspend en workload-placement.

Risico’s en mitigatie: extraterritorialiteit bij hyperscalers mitigeren met BYOK/HYOK, geo-fencing en pseudonimisering; lock-in mitigeren met open format en periodieke export-drills. 

Conclusie: Iceberg-lakehouse als basis, warehouse voor performance. Dit maximaliseert soevereiniteit en flexibiliteit.

T5. OAuth2/OIDC specificatie, tokenpolicy, scopes

Flows en beleidskaders

AVG/NIS2 mapping: Art. 32 vereist passende maatregelen, waaronder pseudonimisering, encryptie en test/evaluatie. OAuth2/OIDC + sterke sleutelbeheersing en logging geven aantoonbare invulling. NIS2 art. 21 onderstreept risk management en supply-chain controls, opgenomen via SBOM/SLSA gates. 

T6. SBOM & SLSA beleid, attestation en enforcement

T7. Exit-strategie en portabiliteit, checklist

• Dataformaten: Parquet/CSV, Iceberg metadata, DCAT-AP-NL voor catalog.
• Contractueel: recht op export ≤ 30 dagen, transitie-assistentie, geen belemmerende switching charges, notificatie- en retentieafspraken. Let op: vanaf 12 jan 2027 zijn switching charges in de EU Data Act in beginsel verboden. 
• Drills: jaarlijkse export-oefening van 1 kerncomponent, effort en fidelity rapporteren.
• Tool-abstraction: vermijden van propriëtaire features, standaard SQL/dbt, ORMs, open API/AsyncAPI.
• Sleutels: HYOK/BYOK buiten provider, vernietiging bevestigd na exit.

T3. Latency-matrix en beslisboom (samenvatting)

• Real-time <100 ms: alleen features/API’s uit platform, inferentie dicht bij transactie-app, fallback naar regels bij degradatie.
• Near-real-time 100 ms–5 s: streaming pipelines en caches; dashboards quasi-live.
• Interactive 5 s–1 min: BI/SQL via semantische laag en pre-aggregaties.
• Batch >1 min: ETL, rapportage, training met deadlines, alerts bij misses.

T4. AI/ML-blueprint, EU AI Act mapping

• IN platform: data provisioning, feature engineering, lineage, governance.
• OUT platform: training/serving in gescheiden ML-omgeving, gekoppeld via gateway, logging terug naar platform.
• Record-keeping en logging over de levenscyclus voor high-risk AI zijn verplicht [AI Act art. 12], data governance eisen op datasets [art. 10]. 

Metrics & SLO’s (consolidated)

QA-Gates, status en criteria

• G1 – na Foundation: 3+ alternatieven per domein gepareerd, 20 persona-journeys uitgewerkt, sovereign-eisen per component gevalideerd, TCO met ±30% bandbreedte, stakeholder review gereed. Status: klaar voor besluitvorming.
• G2 – na Deepening: operationele grenzen en SLO’s vastgelegd, AI blueprint door data science gereviewd, performance benchmarks beschikbaar. Status: geen blocking issues, enkele optimalisaties gepland.
• G3 – na Security & Compliance: OAuth2/OIDC design gereviewd door CISO, SBOM/SLSA ingestemd door Risk, exitstrategie door Legal geaccordeerd. Status: conform risk appetite en regulatoire kaders.

Compliance-matrix, fragment

Roadmap, KPI’s en governance

• 0–6 mnd (Foundation): MVP platform, 2–3 dataproducten, IdP/OIDC live, catalogus+lineage, GE/OTel/Soda.
• 6–18 mnd (Scale): 10+ bronnen, self-service BI breed, feature store v1, eerste productie-model met logging.
• 18–36 mnd (Optimize): FinOps, geavanceerde AI-compliance, maturity L4, DR-tests en jaarlijkse exit-drill.

Board-KPI’s: NPS > 30, time-to-insight −50%, audits 100% slaag, 0 majeure security-incidenten, cost/query −20% YoY.

Opmerkingen over bronnen en onzekerheid

• Regulatorische verwijzingen zijn actueel per oktober 2025, inclusief Data Act switching-regels die in 2027 volledig gelden. 
• EU AI Act artikelen 10 en 12 zijn gebruikt voor data governance en logging; definitieve implementatiedetails blijven onderwerp van uitvoeringshandelingen. 
• Soevereiniteitspraktijken zijn geïllustreerd met DT/Google Cloud casus en T-Systems sleutelbeheer als voorbeeld, toepasbaarheid blijft afhankelijk van eigen contracten en technische keuzes. 

Risk register DataPlatform NLEU

Compliance Matrix Data Platform NLEU