Datagovernance

Introductie

Governance-mechanica is al concreet aan bod gekomen — rolgebaseerde toegang en lineage via Unity Catalog in Databricks, de governance-sectie in Modern Data Platform Architecture, data contracts als afgedwongen CI-check in Data Quality & Testing. Dit hoofdstuk herhaalt die techniek niet, maar behandelt governance als organisatorische discipline: wie is verantwoordelijk voor wat, hoe classificeer je data zodat beleid uitvoerbaar wordt, en hoe organiseer je governance zodat het een dataplatform niet vertraagt maar juist mogelijk maakt.

Wat Data Governance Werkelijk Is

Een veelgemaakte vergissing: governance gelijkstellen aan toegangscontrole. RBAC (wie mag welke tabel lezen) is een afdwingingsmechanisme, niet governance zelf. Governance is het geheel van beslissingen over wie data mag definiëren, wie verantwoordelijk is voor de kwaliteit ervan, welke regels gelden voor gevoelige data, en hoe die regels consistent worden toegepast over een organisatie — RBAC is slechts één van de technische middelen om die beslissingen af te dwingen, naast classificatietags, retentiebeleid en catalogisering.

Zonder dit onderscheid eindigen organisaties met technisch uitstekend beveiligde platformen (strikte RBAC, versleuteling, audit logs) die alsnog governance-problemen hebben: niemand weet wie een tabel "eigenaar" is, dezelfde klant heet in drie systemen anders, en een analist gebruikt een verouderde definitie van "actieve klant" zonder dat iemand het merkt. Governance lost dát op — het is een organisatorisch, niet uitsluitend technisch vraagstuk.

Classificatieniveaus: de Basis van Elk Beleid

Voordat je beleid kunt afdwingen ("gevoelige data mag niet naar analisten"), moet je kunnen benoemen wat gevoelig is. De meeste organisaties werken met een classificatiehiërarchie van vier niveaus:

Publiek — informatie die vrijelijk gedeeld kan worden, zoals gepubliceerde productprijzen of marketingcontent. Geen beperkingen nodig.

Intern — bedrijfsinformatie die niet voor externen bedoeld is, maar geen direct risico vormt bij interne verspreiding — operationele metrics, interne rapportages.

Vertrouwelijk — data die schade kan veroorzaken bij verkeerde verspreiding: financiële resultaten vóór publicatie, strategische plannen, salarisgegevens.

Restricted (persoonsgegevens/PII) — data die onder wettelijke bescherming valt (AVG/GDPR): namen, e-mailadressen, BSN's, medische gegevens. Dit niveau vereist niet alleen toegangscontrole maar ook maskering, encryptie en een expliciete rechtsgrond voor verwerking.

Deze classificatie hoort op kolomniveau te leven, niet alleen op tabelniveau — een customers-tabel bevat vaak een mix: customer_id is intern, email is restricted, signup_date is publiek-achtig. Platformen als Unity Catalog en Purview ondersteunen dit via policy tags: metadata die je aan een kolom hangt, waarna toegangsregels automatisch op basis van die tag worden afgedwongen, in plaats van dat elke tabel individueel handmatig beveiligd moet worden.

-- Classificatie als kolomtag, niet als los document
ALTER TABLE silver.customers ALTER COLUMN email SET TAGS ('classification' = 'restricted');
ALTER TABLE silver.customers ALTER COLUMN signup_date SET TAGS ('classification' = 'public');

-- Beleid gekoppeld aan de tag, niet aan de specifieke tabel
CREATE MASKING POLICY mask_restricted AS (val STRING) RETURNS STRING ->
  CASE WHEN CURRENT_ROLE() IN ('data_engineer', 'compliance_officer') THEN val
       ELSE '***MASKED***' END;
ALTER TAG classification SET MASKING POLICY mask_restricted WHEN classification = 'restricted';

Dit tag-gebaseerde patroon schaalt fundamenteel beter dan tabel-voor-tabel beleid: een nieuwe kolom met een email-achtig karakter krijgt bij aanmaak de juiste tag, en het maskeringsbeleid past zich automatisch toe — niemand hoeft zich te herinneren om een nieuwe tabel handmatig te beveiligen.

Eigenaarschap en Stewardship: Wie is Verantwoordelijk?

Een tabel zonder eigenaar is een tabel die niemand onderhoudt zodra er iets misgaat. Volwassen governance-programma's onderscheiden drie rollen, vaak verward maar functioneel verschillend.

Data owner — meestal een business-rol (een hoofd Sales voor klantdata, een hoofd Finance voor financiële data), verantwoordelijk voor beslissingen: wie mag deze data zien, wat betekent een bepaald veld precies, wanneer is data verouderd genoeg om te verwijderen. De owner is zelden de persoon die de tabel technisch bouwt.

Data steward — vaak een analist of domeinexpert, verantwoordelijk voor de dagelijkse kwaliteit: het bewaken van definities, het signaleren van datakwaliteitsproblemen (zie Data Quality & Testing), het onderhouden van een businessglossarium.

Data custodian — meestal de data engineer, verantwoordelijk voor de technische implementatie: de tabel daadwerkelijk bouwen, beveiligen, en operationeel houden volgens de beslissingen van de owner en de kwaliteitsnormen van de steward.

Het probleem dat deze scheiding oplost: zonder expliciete rollen valt eigenaarschap impliciet toe aan wie de tabel toevallig heeft gebouwd (de custodian), die zelden de bevoegdheid of businesskennis heeft om beslissingen te nemen over wie toegang moet krijgen of wat een veld precies betekent — met als gevolg dat niemand die beslissingen ooit expliciet neemt.

Master Data Management: de Ene Waarheid over een Entiteit

Wanneer dezelfde klant in het CRM, het factuursysteem en het supportsysteem onder net iets andere gegevens bestaat, ontstaat een vraag die governance moet beantwoorden: wat is de golden record — de ene, gezaghebbende waarheid over die klant? Dit is het domein van master data management (MDM).

MDM lost dit op met een combinatie van matching-logica (welke records in verschillende bronnen representeren dezelfde echte entiteit — vaak via fuzzy matching op naam/adres/e-mail wanneer een gedeelde sleutel ontbreekt) en overervingsregels (welke bron "wint" bij conflicterende waarden — vaak de meest recent bijgewerkte bron, of een vaste prioriteitsvolgorde per veld). Dit raakt direct de Data Vault-benadering uit Data Vault 2.0: een hub met business keys plus satellites per bron is de ruwe basis, en de golden record wordt gebouwd als afgeleide informatielaag erbovenop — MDM is in de praktijk vaak precies het businessvault dat in dat hoofdstuk werd genoemd, met expliciete matching- en overervingsregels als kernlogica.

-- Vereenvoudigd golden-record-patroon: nieuwste, meest complete waarde per bron wint
CREATE OR REPLACE TABLE gold.customer_golden AS
SELECT
    customer_key,
    COALESCE(
        MAX(CASE WHEN record_source = 'crm_sales' THEN email END),
        MAX(CASE WHEN record_source = 'crm_acquired' THEN email END)
    ) AS email,
    MAX(load_date) AS last_updated
FROM raw_vault.sat_customer_all_sources
GROUP BY customer_key;

Data Catalogs: Vindbaarheid als Governance-functie

Lineage (behandeld in Databricks) toont waar data vandaan komt; een data catalog lost een ander probleem op: welke data bestaat er eigenlijk, en wat betekent het? Zonder catalog herontdekken analisten steeds opnieuw dat een tabel al bestaat, of erger, bouwen ze een dubbele versie omdat ze niet wisten dat er al een gold.revenue_by_category was. Een catalog combineert technische metadata (schema, laatste update) met businessmetadata (een beschrijving in gewone taal, de eigenaar, gerelateerde termen in een businessglossarium) in één doorzoekbare index — de brug tussen de technische wereld van tabellen en kolommen en de businesswereld van "wat betekent actieve klant eigenlijk".

Gefedereerd versus Centraal: de Organisatorische Vraag

Een laatste, structurele beslissing: wie is verantwoordelijk voor governance-beleid — één centraal team, of elk domeinteam voor zijn eigen data?

Centrale governance — één team stelt beleid vast en handhaaft het over de hele organisatie. Consistent, maar wordt bij grote organisaties al snel een knelpunt: elk nieuw dataset moet langs hetzelfde kleine team, wat vertraging oplevert die precies ingaat tegen de snelheid die een modern dataplatform zou moeten bieden.

Gefedereerde governance (data mesh) — elk domeinteam (sales, finance, product) is zelf verantwoordelijk voor de governance van zijn eigen data, binnen een gedeeld, organisatiebreed kader van standaarden (dezelfde classificatieniveaus, dezelfde catalogtool, dezelfde minimale kwaliteitsnormen). Dit is de kerngedachte achter data mesh: domeineigenaarschap in plaats van centrale controle, met governance als gedeeld contract in plaats van een centraal goedkeuringsproces.

De praktische vuistregel: centrale governance werkt prima tot een organisatie een omvang bereikt waarop één team simpelweg niet meer alle domeinen kan bijbenen — vergelijkbaar met de monorepo-versus-polyrepo-afweging uit Git & Branch-strategieën, is dit een schaalvraag, geen principiële keuze die je dag één al moet maken.

Retentiebeleid: Hoe Lang Bewaar je Wat?

Classificatie beantwoordt "wie mag dit zien"; retentiebeleid beantwoordt een net zo belangrijke vraag die governance vaak vergeet: "hoe lang mag dit blijven bestaan?" Dit is geen puur technische kwestie (VACUUM-instellingen uit Delta Lake regelen alleen hoelang je terug kunt kijken, niet hoelang data hoort te bestaan) maar een beleidsbeslissing die per classificatieniveau en vaak per rechtsgrond verschilt.

Restricted-data (persoonsgegevens) valt onder AVG-vereisten die bewaring beperken tot "niet langer dan noodzakelijk voor het doel" — een klant die zijn account drie jaar geleden opzegde, hoort niet voor altijd in je silver-laag te blijven staan zonder concrete reden. Financiële data heeft vaak juist een minimale bewaartermijn (wettelijke bewaarplicht, vaak 7 jaar in Nederland), waardoor retentiebeleid soms twee kanten opwerkt: sommige data moet je actief verwijderen, andere data mag je niet te vroeg kwijtraken.

-- Retentiebeleid als uitvoerbare regel, niet alleen een document
CREATE OR REPLACE TABLE gold.retention_candidates AS
SELECT customer_id, last_activity_date
FROM silver.customers
WHERE classification = 'restricted'
  AND last_activity_date < CURRENT_DATE - INTERVAL '3 years'
  AND NOT EXISTS (SELECT 1 FROM legal_holds WHERE legal_holds.customer_id = silver.customers.customer_id);

De NOT EXISTS-check tegen een legal_holds-tabel is bewust: een legal hold (bijvoorbeeld een lopend juridisch geschil) kan een verwijderverplichting tijdelijk opschorten, ook voor data die anders al verwijderd had moeten zijn — retentiebeleid moet dit soort uitzonderingen expliciet kunnen respecteren, niet blind een vaste regel toepassen.

Audit Trails: Wie Deed Wat, Wanneer?

Voor gereguleerde sectoren (financieel, zorg) is het niet genoeg om toegang correct te beperken — je moet ook kunnen aantonen wie welke data heeft geraadpleegd, gewijzigd of geëxporteerd, vaak met jarenlange bewaarplicht op die logs zelf. Dit is een andere laag dan de lineage uit Databricks (die toont hoe data getransformeerd is), en een andere laag dan de teststrategie uit Data Quality & Testing (die toont of data correct is) — een audit trail toont specifiek wie er bij was.

De meeste moderne platformen loggen dit automatisch op query-niveau (wie voerde welke query uit, tegen welke tabellen, wanneer), maar governance moet expliciet bepalen: welke acties zijn audit-plichtig (elke SELECT, of alleen op restricted-data?), hoe lang blijven audit-logs zelf bewaard, en wie mag de logs zelf inzien — audit-logs zijn zelf vaak weer gevoelige data, omdat ze onthullen wie waarin geïnteresseerd was.

Best Practices

• Classificeer op kolomniveau via tags, niet op tabelniveau via losse documenten — dit is wat automatische, schaalbare beleidsafdwinging mogelijk maakt.
• Wijs expliciete owners, stewards en custodians toe per belangrijk domein, met duidelijk onderscheid tussen wie beslist, wie kwaliteit bewaakt, en wie bouwt.
• Bouw een golden record via expliciete matching- en overervingsregels, gedocumenteerd en reproduceerbaar — niet via een ad-hoc COALESCE die niemand meer kan uitleggen na een jaar.
• Investeer in een doorzoekbare catalog met businessbeschrijvingen, niet alleen technische metadata — de meeste "bestaat deze data al"-vragen worden hierdoor voorkomen.
• Kies gefedereerde governance zodra centrale goedkeuring een merkbaar knelpunt wordt, niet eerder — vroegtijdige federatie voegt coördinatiekosten toe zonder voordeel.

Veelgemaakte Fouten

• Governance gelijkstellen aan RBAC, waardoor organisatorische vragen (wie is eigenaar, wat betekent dit veld) onbeantwoord blijven ondanks technisch prima beveiligde tabellen.
• Classificatie op tabelniveau in plaats van kolomniveau, waardoor een tabel met één gevoelig veld in zijn geheel overbeveiligd wordt, of erger, ondergeclassificeerd blijft omdat de tabel als geheel "niet zo gevoelig" aanvoelde.
• Geen expliciete owner toewijzen, waardoor eigenaarschap impliciet bij de bouwer van een tabel terechtkomt, zonder de bevoegdheid om echte governance-beslissingen te nemen.
• Golden-record-logica ad-hoc en ongedocumenteerd bouwen, waardoor niemand meer kan reconstrueren waarom bron A voor veld X wint en bron B voor veld Y.
• Centrale governance aanhouden bij een organisatie die het allang ontgroeid is, wat elk nieuw dataset onnodig vertraagt en teams motiveert om governance te omzeilen in plaats van te volgen.

Performance Tips

• Automatiseer classificatietagging waar mogelijk (patroonherkenning op kolomnamen als email, ssn, phone) in plaats van elke kolom handmatig te taggen — handmatige tagging wordt bij honderden tabellen onhaalbaar.
• Cache catalogzoekopdrachten en metadata-aggregaties — een catalog die bij elke zoekopdracht live alle tabellen bevraagt, schaalt slecht bij duizenden objecten.
• Beperk MDM-matching tot de velden die het daadwerkelijk nodig hebben — fuzzy matching over te veel kolommen tegelijk is zowel traag als foutgevoelig.
• Meet de doorlooptijd van governance-goedkeuringen expliciet — dit is de concrete metriek die aangeeft wanneer centrale governance een knelpunt begint te worden.

Interviewvragen

"Wat is het verschil tussen governance en toegangscontrole (RBAC)?" Let op: RBAC is een technisch afdwingingsmechanisme; governance omvat de bredere organisatorische beslissingen (eigenaarschap, definities, classificatie) waarvan RBAC er slechts één van de technische uitvoeringen van is.

"Leg het verschil uit tussen een data owner, een data steward en een data custodian." Let op: owner beslist (business-rol), steward bewaakt dagelijkse kwaliteit en definities, custodian bouwt en beheert technisch (vaak de data engineer) — drie functioneel verschillende verantwoordelijkheden.

"Waarom zou je classificatie op kolomniveau doen in plaats van tabelniveau?" Let op: de meeste tabellen bevatten een mix van gevoeligheidsniveaus; kolomniveau-classificatie via tags maakt geautomatiseerde, schaalbare beleidsafdwinging mogelijk zonder elke tabel individueel te hoeven beveiligen.

"Wat is een golden record, en hoe bouw je er een?" Let op: de ene gezaghebbende waarheid over een entiteit die in meerdere bronnen met afwijkende gegevens voorkomt, gebouwd via expliciete matching-logica (welke records dezelfde entiteit zijn) en overervingsregels (welke bron wint per veld).

"Wanneer zou je kiezen voor gefedereerde in plaats van centrale governance?" Let op: zodra een centraal governance-team niet meer alle domeinen kan bijbenen en een merkbaar knelpunt wordt — een schaalvraag, geen principiële keuze die vanaf dag één gemaakt moet worden.

"Wat is het verschil tussen retentiebeleid en de VACUUM-instellingen van Delta Lake?" Let op: VACUUM bepaalt hoelang je technisch terug kunt kijken (time travel/opslagbeheer); retentiebeleid is een beleidsbeslissing over hoelang data hoort te bestaan, vaak met tegenstrijdige eisen per classificatie (AVG dwingt tot verwijderen, wettelijke bewaarplicht dwingt juist tot bewaren).

"Wat is een audit trail, en waarom is het iets anders dan lineage?" Let op: lineage toont hoe data getransformeerd is; een audit trail toont wie welke data heeft geraadpleegd of gewijzigd, wanneer — relevant voor compliance-aantoonbaarheid, niet voor het begrijpen van transformatielogica.

Relevante Documentatie

• Databricks: Unity Catalog Data Classification — policy tags en geautomatiseerde beleidsafdwinging in de praktijk.
• Microsoft Purview: Data Governance — catalogisering en classificatie binnen het Microsoft-ecosysteem.
• Data Mesh Principles — de kernprincipes achter gefedereerde, domeingedreven governance.

Samenvatting

Data governance is een organisatorische discipline die verder gaat dan technische toegangscontrole: het omvat classificatie op kolomniveau, expliciet eigenaarschap verdeeld over owners/stewards/custodians, master data management voor een consistente golden record over bronnen heen, en een doorzoekbare catalog die vindbaarheid net zo belangrijk maakt als lineage. De keuze tussen centrale en gefedereerde governance is een schaalvraag: centraal werkt tot het een knelpunt wordt, waarna een data-mesh-achtige, domeingedreven aanpak beter past. Met governance als organisatorisch raamwerk behandeld, verschuift het volgende hoofdstuk naar de technische tegenhanger: Data Security.