Waarom documentatie geen governance is: de illusie van compliancechecklists

By Mirko Peters · 2026-08-28

Wanneer organisaties aan hun cloudreis beginnen, verwarren ze vaak papierwerk met bescherming. Ze steken veel energie in uitgebreide beleidspresentaties, ingewikkelde Excel-sheets en complexe RACI-matrices, in de veronderstelling dat het op papier vastleggen van regels gelijkstaat aan het afdwingen ervan in productie. Helaas is die afhankelijkheid van documentatie en redelijk gedrag een gevaarlijk

Automatically translated with AI from the original post. Read the English original

Cover: Fix Azure Governance Before Your Next Cloud Audit

Wanneer organisatiesBeginnen aan hun cloudreis verwarren ze vaak papierwerk met bescherming. Ze steken veel energie in uitgebreide beleidspresentaties, ingewikkelde Excel-sheets en complexe RACI-matrices, in de veronderstelling dat het op papier vastleggen van regels gelijkstaat aan het afdwingen ervan in productie. Helaas is die afhankelijkheid van documentatie en redelijk gedrag een gevaarlijke illusie. Echte cloudgovernance gaat niet over wat een onderneming in een beleidsdocument zegt te geloven; het gaat over wat het control plane weigert toe te staan.

Naarmate organisaties uitgroeien tot tientallen teams en honderden abonnementen, faalt handmatig toezicht onvermijdelijk. In deze uitgebreide post ontleden we waarom beleidsafwijking ontstaat, hoe goede teams onbedoeld chaos veroorzaken en hoe je met native platformtools een deterministisch operationeel model bouwt. Voor een diepgaande verkenning van deze strategieën raden we je aan de bijbehorende podcastaflevering Fix Azure Governance Before Your Next Cloud Audit te bekijken.

Kernstelling

Als intentie niet wordt afgedwongen door het control plane, zal ze verval ondergaan.

Governance die steunt op het geheugen van mensen, geschreven documentatie of optimistische verwachtingen van redelijk gedrag, is helemaal geen governance. Het is simpelweg hoop op schaal. Wanneer het onderliggende platform ongeautoriseerde acties technisch niet beperkt, is je architectuur kwetsbaar voor entropie, menselijke fouten en stille configuratieafwijkingen.

De faalwijze in grote organisaties: wanneer beleidsafwijking normaal wordt

Governance faalt zelden omdat een organisatie is vergeten de regels op te schrijven. Ze faalt omdat die controles na verloop van tijd langzaam wegdrijven van de werkelijkheid. Vrijwel elke cloudimplementatie van een onderneming begint met zuivere intenties:

Een schone basisbeveiligingsbaseline
Gestandaardiseerde naamgevingsconventies
Tijdelijke eigenaartoewijzingen voor de bootstrapfase
Een keurig opgemaakt spreadsheet met de naam RACI
Iedereen in de organisatie die zich wederzijds verantwoordelijk voelt

Dan slaat de werkelijkheid toe in de vorm van de eerste dringende uitzondering. Die lijkt volkomen redelijk, zeer kritiek en gerechtvaardigd als eenmalige zakelijke noodzaak. Het platformteam keurt de uitzondering goed om projecten in beweging te houden. Die ene goedkeuring creëert echter een permanente splitsing in het systeemgedrag. Uitzonderingen zijn geen geïsoleerde gevallen; het zijn entropiegeneratoren.

De meeste organisaties verwijderen deze uitzonderingen nooit, en volgen ze ook niet met een gedegen levenscyclusbeheer. Geleidelijk houdt de geschreven baseline op te bepalen wat er daadwerkelijk in de tenant gebeurt. Hij verwordt tot een historisch advies, omringd door verouderde workarounds. Op schaal manifesteert dit zich in drie afzonderlijke faalwijzen:

Ontbrekende controles – onvolwassen, maar relatief eenvoudig op te lossen.
Afdrijvende controles – de verraderlijke echte kwaal van grote omgevingen.
Conflicterende controles – meerdere schijnbaar ‘juiste’ baselines die niet vreedzaam naast elkaar kunnen bestaan.

Organisaties leggen alle drie vaak verkeerd uit als toolproblemen en haasten zich om dure dashboards en software voor compliancescores aan te schaffen. Geen van deze tools stopt afwijking op eigen kracht, omdat afwijking in de kern een probleem van beslissingsverdeling is en geen kennistekort.

Waarom goede teams nog steeds chaos veroorzaken

Cloudomgevingen accepteren implementaties vanuit meerdere kanalen: developerportals, CI/CD-pipelines, service principals, beheerde identiteiten en gestreste mensen die onder strakke deadlines werken. Elke dag vinden duizenden microbeslissingen plaats, over regio's, SKU's, netwerkblootstelling, identiteitstoewijzingen en logconfiguraties heen.

Als harde beperkingen niet automatisch worden afgedwongen, uit het systeem zich vanzelf in lokale optimalisatie op schaal. Zelfs de meest getalenteerde engineeringteams veroorzaken onvermijdelijk operationele chaos wanneer ze onbeperkte keuzes krijgen. Daarom veranderen centrale platformteams vaak in overbelaste ticketwachtrijen. Dat ligt niet aan incompetentie, maar aan het feit dat de organisatie van hen verwacht dat ze als runtime-autorisatiemechanisme voor elke afzonderlijke toepassing fungeren.

Wanneer het auditseizoen aanbreekt, komt de lelijke waarheid aan het licht:

Beleid bestaat op papier, maar actieve uitzonderingen kunnen niet worden verklaard.
Logging is ingesteld, maar de resultaten verschillen frustrerend sterk tussen workloads.
Dashboards voor de beveiligingsstatus lijken acceptabel, maar alleen omdat talloze uitzonderingen de onderliggende kwetsbaarheden verhullen.
Cloudkosten kunnen niet nauwkeurig worden toegewezen, omdat tagbeleid slechts "aanbevolen" was.

Beveiligingsincidenten onthullen een nog harder beeld. Uit evaluaties na een incident blijkt zelden dat de organisatie geen schriftelijk beleid had. Wat ze wel vinden, is dat niemand wist dat er nog een riskant netwerkpad of een verouderde machtiging bestond. Dat schaduwpad bestaat uitsluitend omdat drift het heeft gecreëerd.

Governance by Design: deterministische versus probabilistische controle

Echte governance by design betekent dat het platform de organisatorische intentie native afdwingt, zodat niemand dat hoeft te onthouden. Een deterministisch systeem gedraagt zich elke keer identiek. Een specifieke aanvraag levert altijd exact dezelfde uitkomst op, ongeacht wie haar indient of hoe dringend de deadline voelt.

Probabilistische governance daarentegen klinkt voor de meeste IT-leiders gevaarlijk bekend:

"Het zou waar moeten zijn."
"Het wordt meestal afgedwongen."
"We bekijken het later wel."
"De meeste teams houden zich eraan."

Dat is geen governance; dat is op de kansen gokken. Probabilistische systemen voelen productief omdat ze ontwikkelaars nooit vooraf blokkeren, maar de wrijving verdwijnt niet, ze verschuift alleen. Later duikt ze weer op als uitputtende audits, ernstige beveiligingsincidenten en dure noodopruimingen.

Deterministische guardrails stoppen drift direct aan de grens door strikt te controleren op zaken als:

Toegestane geografische regio's
Geweigerde patronen voor netwerkblootstelling
Verplichte diagnostische instellingen
Vereiste versleutelingsnormen
Afgedwongen eigendomsmetadata

Als een implementatie niet aan deze criteria voldoet, wordt ze meteen aan de grens geweigerd, en niet pas maanden later in een kwartaalrapport gesignaleerd.

Landing zones en managementgroepen: waar schaal slaagt of faalt

Landing zones zijn veel meer dan architectuurdiagrammen; het zijn bindende organisatorische afspraken. Als een abonnement binnen een specifieke landing zone valt, gelden de vooraf gedefinieerde regels onvoorwaardelijk en zonder ruimte voor onderhandeling.

Managementgroepen vormen het kernpunt van de handhaving. Azure Policy en Role-Based Access Control (RBAC) erven van bovenaf door deze hiërarchie heen. Als je managementgroepstructuur rommelig en ongeorganiseerd is, wordt governance al snel archeologisch onderzoek.

Een gezonde, werkende hiërarchie is ondiep, doelbewust opgebouwd en gestructureerd rond risico en intentie in plaats van rond het organigram van het bedrijf:

Platforminfrastructuur versus applicatieworkloads
Productieomgevingen versus niet-productieomgevingen
Gereguleerde workloads versus niet-gereguleerde workloads
Sandboxes versus strikt beheerde omgevingen

Als het verplaatsen van een abonnement naar een andere managementgroep de geërfde regels niet merkbaar verandert, is je hiërarchie niets meer dan decoratie. En decoratie leidt onvermijdelijk tot entropie.

Abonnementen: de blast radius is een ontwerpkeuze

Abonnementen zijn veel meer dan eenvoudige facturatiecontainers. Ze fungeren als kritieke beveiligingsgrenzen, grenzen voor kostentoewijzing, mechanismen voor beleidsovererving en perimeters voor het insluiten van incidenten.

Alle workloads in één gigantisch abonnement plaatsen creëert een onaanvaardbaar grote gedeelde blast radius. Maar willekeurige, ongecontroleerde abonnementen per team leiden tot wildgroei en diepe inconsistenties in de configuratie. Een duurzame abonnementsstrategie beantwoordt vanaf het begin vier fundamentele vragen:

Wie is eigenaar van dit abonnement?
Welke specifieke governance-baseline is van toepassing?
Welk toegangsmodel is toegestaan?
Wat is de verwachte maximale blast radius?

Als je team deze vragen niet duidelijk kan beantwoorden, moet het abonnement nog niet worden aangemaakt.

Identity & RBAC: wijs intentie toe, geen personen

RBAC faalt op schaal onvermijdelijk wanneer machtigingen rechtstreeks aan individuele gebruikersaccounts worden toegewezen in plaats van aan doelgerichte groepen. Mensen wisselen van rol, teams roteren en externe medewerkers vertrekken, maar directe machtigingen blijven hardnekkig bestaan.

Rollen moeten worden toegewezen aan groepen die expliciet de intentie, het operationele bereik en duidelijke verantwoordelijkheden vastleggen. Discipline in het bereik is essentieel, want overerving is de manier waarop privileges ongemerkt door een omgeving heen verspreiden. De Owner-rol is geen handige kortere weg; het is een krachtig persistentiemechanisme. Als een aanvaller een Owner-identiteit compromitteert, kan hij veel meer doen dan resources implementeren: hij kan zichzelf permanente achterdeur-toegang verlenen.

Echt least privilege vereist een strikte scheiding van taken:

Het platformteam definieert de fundamentele grenzen.
Workloadteams opereren strikt binnen die grenzen.
Securityteams observeren, monitoren en onderzoeken afwijkingen.
Automatiseringspipelines rollen herhaalbare patronen uit, geen ad-hocmachtigingen.

Privileged Identity Management: Permanente bevoegdheden zijn uitgestelde incidenten

Permanente beheerderstoegang is nooit een teken van operationele efficiëntie; het is simpelweg uitgestelde incidentrespons die wacht om te gebeuren. Privileged Identity Management (PIM) scheidt bevoegdheid strikt van actief gebruik en maakt van administratieve bevoegdheid een controleerbare, tijdgebonden gebeurtenis in plaats van een permanent kenmerk.

Een effectief PIM-ontwerp zou voor dagelijkse gebruikers enigszins ongemakkelijk moeten aanvoelen:

Sessietijdslimieten moeten strikt verplicht zijn.
Motivatieteksten voor verhoogde toegangsaanvragen moeten zinvol zijn en worden gecontroleerd.
Multi-factor authentication (MFA) moet onderhandelbaar zijn; dat is het niet.
Rollen die grenzen verleggen, vereisen formele goedkeuringsworkflows.

Als de bedrijfsleiding "tijdelijk permanente toegang" als routinematige noodoplossing toestaat, degenereert PIM snel tot louter security theater. Bevoegdheid moet altijd zeldzaam zijn, strak afgebakend, goed zichtbaar en regelmatig gecontroleerd.

Azure Policy: afdwingen wat mag bestaan

Waar RBAC bepaalt wie binnen de cloud mag handelen, bepaalt Azure Policy wat er daadwerkelijk mag bestaan. Azure Policy is geen zachte richtlijn; het is een actieve poortwachter binnen het control plane.

Auditonly-beleid kan achteraf afwijkingen detecteren, maar Deny-beleid voorkomt actief dat afwijkingen ontstaan. Een volwassen beleidsmodel gebruikt meerdere handhavingseffecten:

Deny voor strikte, niet-onderhandelbare beveiligings- en architectuurvereisten.
Modify voor geautomatiseerde resourcehygiëne en consistente naamgeving.
DeployIfNotExists voor systematische compliance-eisen, zoals diagnostische logging.
Audit uitsluitend voor de eerste leerfase; nooit als permanente eindsituatie.

Het niet saneren van bestaande resources creëert een gefragmenteerde werkelijkheid: beheerde toekomstige resources die naast onbeheerde legacy-assets bestaan. Dat split-brain-scenario is het exacte tegenovergestelde van echte governance.

Security Posture & Continue Compliance: signalen voeden de vangrails

Tools voor cloud posture management zijn rookmelders, geen brandblussers. Hun echte waarde ligt niet in opzichtige dashboards, maar in continue feedbackloops. Beveiligingssignalen moeten architectuurverbeteringen automatisch aansturen:

Posture-bevindingen vertalen naar nieuw Deny-beleid.
Overmatig ruime RBAC-scopes inperken.
Verplichte diagnostiek afdwingen voor nieuw ontdekte blinde vlekken.
De standaardinstellingen van de landing-zone-automaten verbeteren.

Compliance overleeft in dynamische cloudomgevingen alleen wanneer het als doorlopend proces wordt behandeld. Bewijs wordt niet meer handmatig verzameld; het wordt automatisch geproduceerd door het architectuurontwerp. Audits krimpen van maanden paniek naar dagen routinematige verificatie wanneer afgedwongen intentie documentatietheater vervangt.

FinOps-vangrails: kosten zijn governance

Kosten lekken onvermijdelijk waar machtigingen onbeperkt zijn. Als teams vrij zijn om elke dure SKU in elke regio te implementeren zonder eigenaarsmetadata, wordt het cloudplatform in feite een onbeperkt inkoopsysteem met een API.

Echte FinOps begint met afgedwongen metadatavereisten:

Duidelijke toewijzing van eigenaarschap
Classificatie van de omgeving
Applicatie- of productidentificatie
Niveau van gevoeligheid van gegevens

Budgetten moeten fungeren als vroegwaarschuwingssignalen en niet als straffende schandemechanismen. Effectieve chargeback- en showback-modellen brengen dagelijkse technische beslissingen in lijn met financiële gevolgen. Deny dure resourcepatronen waar ze niet thuishoren, en sta experimenteren alleen toe binnen containers waar de blast radius volledig is ingeperkt. Kostenbeheer is nooit besparingstheater; het is het actief afdwingen van architecturale doelgerichtheid.

Het operationele model: governance die druk overleeft

Governance faalt uiteindelijk wanneer het eigenaarschap van beslissingen dubbelzinnig wordt. Een robuust operationeel model definieert duidelijk:

Belanghebbende eigenaren binnen platform-, security-, finance- en applicatieteams.
Duidelijke beslissingslijnen die self-service, goedkeuringsworkflows en verboden patronen van elkaar scheiden.
Strikte levenscycli voor uitzonderingen, inclusief aanvraag, verlopen, hervalidatie en verwijdering.
Beleid wordt op dezelfde manier behandeld als applicatiecode, compleet met versiebeheer en gefaseerde uitrol.

Vertrouwen op ticketgebaseerd governance schaalt niet goed. Het centraliseert alleen administratieve wrijving in plaats van echte controle op te leveren. Veilig werken moet altijd het makkelijkste zijn voor je engineeringteams.

Slotgedachte

Governance wordt nooit bepaald door wat een organisatie zegt te geloven. Echte governance blijkt uitsluitend uit wat het cloudcontrolevlak weigert toe te staan. Als de bedoeling van de organisatie niet actief wordt afgedwongen door automatisering, dan erodeert ze: langzaam, stilletjes, en dan ineens helemaal.

🎧 Luister naar deze aflevering

Wil je een praktische uitleg over Fix Azure Governance Before Your Next Cloud Audit? In deze aflevering wordt het onderwerp in heldere taal uitgelegd en wordt getoond waarom het ertoe doet voor Microsoft 365, Azure, Power Platform, beveiliging, AI en modern werken.

Luister naar deze aflevering als je wilt:

De kernconcepten achter Fix Azure Governance Before Your Next Cloud Audit begrijpen
Zien hoe het past in het bredere Microsoft-technologie-ecosysteem
Leren waar het praktische waarde kan opleveren voor je organisatie

Misschien vind je deze gerelateerde M365 FM-afleveringen ook interessant:

Ontdek meer praktijkgerichte Microsoft-gesprekken op M365 FM.