Wanneer Nederlandse toezichthouders zoals de AFM, DNB of de Autoriteit Persoonsgegevens audits uitvoeren, toetsen zij niet langer alleen beleidsstukken, maar ook de technische realiteit achter ethische muren. Handelsafdelingen moeten strikt zijn gescheiden van advies- of onderzoeksactiviteiten om marktmisbruik te voorkomen, en overheidsinstanties moeten bewijzen dat beleidsmakers geen ongeoorloofde invloed uitoefenen op uitvoeringsorganisaties. Zonder digitale waarborgen is het vrijwel onmogelijk om aan te tonen dat informatie werkelijk gescheiden blijft in een wereld waarin Teams, SharePoint en Viva Engage juist zijn ontworpen om silo’s te doorbreken.
Information Barriers vormt daarom een cruciaal onderdeel van de Nederlandse Baseline voor Veilige Cloud. Het is niet slechts een knop in het compliance-portaal, maar een ontwerpprincipe waarbij organisatorische segmenten, juridische verplichtingen, procesarchitectuur en technische configuraties samenkomen. Deze tutorial gaat stap voor stap door de ontwerpafwegingen, implementatiestappen en operationele borging die nodig zijn om Chinese walls aantoonbaar te laten functioneren. Daarbij ligt de nadruk op de combinatie van Microsoft Purview en Microsoft Teams, maar we kijken ook naar de impact op Exchange, SharePoint, Viva en externe samenwerking. Het doel is om security- en complianceprofessionals te helpen een oplossing te bouwen die audits doorstaat, maar ook rekening houdt met de dagelijkse werkelijkheid van bestuurders, juristen, onderzoekers en klantteams die binnen dezelfde tenant moeten blijven samenwerken.
Information Barriers realiseren vraagt om een combinatie van juridische interpretatie, nauwkeurige segmentdefinities, technische configuratie en gedisciplineerde changeprocessen. Alleen wanneer alle vier de dimensies synchroon lopen ontstaat een verdedigbare ethical wall.
Richt een volledig gescheiden pilot-tenant of isolatieomgeving in waarin u productiedata simuleert, zodat incompatibiliteiten met voice, apps of gasttoegang vroegtijdig zichtbaar worden en governancecommissies tijdig uitzonderingen kunnen beoordelen.
Segmentatie en beleidsarchitectuur
Een succesvolle Information Barriers-implementatie start met een segmentatiemodel dat zowel de juridische verplichtingen als de feitelijke werkprocessen weerspiegelt. Nederlandse financiële instellingen moeten bijvoorbeeld aantonen dat medewerkers die aan MiFID- of MAR-gerelateerde handelsactiviteiten werken geen toegang hebben tot dossiers van corporate finance of fusie-en-overnameadviseurs. Voor ministeries en uitvoeringsorganisaties geldt dat beleidsvorming, subsidieafhandeling, toezicht en opsporing strikt gescheiden moeten blijven om belangenverstrengeling te voorkomen. Het segmentatiemodel beschrijft daarom niet alleen welke afdelingen er bestaan, maar vooral welke datastromen, besluitvormingsprocessen, leveranciersketens en vertrouwelijke dossiers binnen die afdelingen circuleren. Door de modelleerfase te beginnen met een multidisciplinaire sessie tussen juridische experts, enterprise-architecten en proceseigenaren wordt geborgd dat Information Barriers niet wordt gereduceerd tot een IT-project, maar fungeert als verlengstuk van governance.
In de praktijk wordt het model vertaald naar segment labels in Microsoft Purview. Deze labels worden gevoed door identity-attributen (zoals afdelingscodes, cost centers of functieprofielen), maar ook door membership van specifieke Microsoft Entra-groepen. Het is aan te bevelen om dynamische groepen te gebruiken die gekoppeld zijn aan authoritative HR-systemen, zodat mutaties automatisch doorwerken. Tegelijkertijd moet er ruimte blijven voor fine-grained uitzonderingen. Denk aan compliance officers, onderzoeksjuristen of security-analisten die vanuit hun rol juist dwars door segmenten heen moeten kunnen kijken. Het beleid moet daarom twee lagen bevatten: een harde scheidingslaag voor wie nooit mag communiceren, en een gecontroleerde vensterlaag waarbij overleg alleen onder specifieke voorwaarden is toegestaan. Deze vensterlaag wordt vormgegeven via aanvullende policies, expliciete toestemmingen en loggingafspraken die door de compliance-afdeling worden gevalideerd.
Een ander architectonisch aandachtspunt is data residency. Wanneer segmenten bijvoorbeeld internationale projectteams omvatten, moeten organisaties bepalen of cross-border communicatie juridisch is toegestaan, zelfs wanneer Information Barriers de interacties technisch blokkeert. De Nederlandse Baseline voor Veilige Cloud benadrukt dat segmentatie geen substituut is voor juridisch beleid: het is een bewijs dat beleid wordt uitgevoerd. Daarom hoort bij de architectuur ook een dossier waarin per segment wordt beschreven welke wet- en regelgeving relevant is, welke risico’s worden gemitigeerd en welke compensating controls worden ingezet voor uitzonderingen. Dit dossier wordt gebruikt bij audits en tijdens de verplichte jaarlijkse review van beleid en procedures.
Tijdens de ontwerpfase ontstaan vaak discussies over hybride rollen. Moderne organisaties kennen bijvoorbeeld productmanagers die zowel met ontwikkelteams als met commerciële teams spreken, of programmaleiders die beleid vertalen naar uitvoering. In plaats van deze rollen structureel buiten Information Barriers te plaatsen (waardoor de scheiding verwatert) is het verstandiger om hun communicatiebehoefte in scenario’s uiteen te zetten. Voor ieder scenario wordt vastgelegd via welk kanaal (Teams, e-mail, gedeelde werkruimten) communicatie mag plaatsvinden, hoe lang het venster openstaat en welke logging moet worden vastgelegd. Zo blijft de structurele scheiding intact, terwijl de organisatie toch wendbaar blijft. Het resultaat is een beleidsarchitectuur waarin segmentatie, uitzonderingsbeheer en auditvoorbereiding elkaar versterken en waarover directie en ondernemingsraad gezamenlijk besluiten kunnen nemen.
Een volwassen architectuur bevat bovendien meetpunten. Door per segment key risk indicators vast te stellen (bijvoorbeeld het aantal uitzonderingen per kwartaal of het percentage nieuwe medewerkers dat binnen vijf werkdagen correct is toegewezen) ontstaat een vroegtijdige waarschuwing wanneer de scheiding dreigt te eroderen. Deze indicatoren worden gekoppeld aan het risicoregister en besproken in hetzelfde overleg waarin ook DPIA’s, records management en identity governance worden behandeld. Hierdoor groeit Information Barriers uit tot een integraal onderdeel van het compliance-ecosysteem in plaats van een geïsoleerde maatregel.
Technische implementatie en validatie
Zodra het segmentatiemodel is vastgesteld, verschuift de aandacht naar de technische implementatie in Microsoft 365. Information Barriers wordt geconfigureerd in het Microsoft Purview complianceportaal, maar de impact strekt zich uit tot Microsoft Teams, Exchange, SharePoint, OneDrive en Viva Engage. De configuratie begint met het inschakelen van het Information Barriers-framework in PowerShell en het koppelen van de juiste licenties (E5 of een vergelijkbare add-on). Daarna worden segmenten aangemaakt via cmdlets zoals New-OrganizationSegment, waarbij zorgvuldig wordt gecontroleerd welke attributen het segment vullen. Een veelgemaakte fout is het gebruik van statische CSV-imports die binnen enkele weken verouderd raken. Door segmenten te baseren op dynamische groepen en HR-koppelingen blijft de configuratie actueel zonder handmatige tussenkomst, wat essentieel is om tijdens audits aan te tonen dat de scheiding 24/7 geldig is.
Het opstellen van policies vereist een iteratieve aanpak. Elke policy bepaalt welke segmenten niet met elkaar mogen communiceren en of er uitzonderingen gelden voor specifieke apps of workloads. In complexe organisaties wordt gewerkt met policy stacks waarin meerdere blokkerende regels elkaar overlappen. Daarom is het aan te raden om policies logisch te groeperen (bijvoorbeeld alle financiële scheidingen in één set en alle overheidsketens in een andere set) en versiebeheer toe te passen via Infrastructure as Code. Door de PowerShell-configuratie in Git te bewaren, inclusief change-requests en goedkeuringen, ontstaat een reproduceerbaar auditspoor dat aansluit bij de eisen uit de BIO en NIS2.
De technische implementatie moet altijd worden voorafgegaan door regressietests. Information Barriers beïnvloedt uitnodigingen voor vergaderingen, toegang tot gedeelde kanalen, federatie met externe tenants en zelfs zoekresultaten in SharePoint. In een pilotomgeving worden daarom realistische persona’s aangemaakt met productiedata en workloads, zodat wordt zichtbaar welke functies plotseling niet meer werken. Denk aan scenario’s waarin serviceaccounts agenda’s beheren, of waarin juridische teams documenten vanuit meerdere segmenten bewerken. Door tijdens de pilot testcases te schrijven die aansluiten op het eerder beschreven segmentatiemodel, ontstaat een volledige trace van ontwerp naar uitvoering. Bevindingen worden vastgelegd in het change register en leiden tot aanvullende policies, alternatieve processen of bewust uitzonderingsbeheer.
Ook na de uitrol blijft validatie cruciaal. Microsoft levert rapportages waarmee je kunt zien hoeveel communicatiepogingen zijn geblokkeerd, maar organisaties doen er goed aan om deze data te combineren met SIEM- en Purview Audit-logs. Zo kan een SOC-analist zien of er ongebruikelijke pieken zijn in geblokkeerde communicatie, wat kan duiden op een configuratiefout of een gebruiker die bewust probeert de barrière te omzeilen. Daarnaast moet er een formele releasekalender zijn waarin wijzigingen in segmenten, policies of identity-attributen worden gepland. Elke wijziging wordt vooraf beoordeeld door juridische en compliance experts, zodat het technische landschap synchroon blijft lopen met de bestuurlijke afspraken.
Een element dat vaak wordt vergeten is de compatibiliteit met gasttoegang, Teams Connect en Viva-apps. Wanneer een segment bijvoorbeeld externe consultants bevat, moeten organisaties bepalen of deze gebruikers een apart tenant-onboardingproces krijgen of binnen de Information Barriers-structuur worden opgenomen. Het documenteren van deze beslissingen, inclusief fallbackscenario’s voor kritieke ketens zoals crisisteams, voorkomt dat de organisatie tijdens een incident vastloopt doordat noodzakelijke communicatie niet mogelijk is. Door architectuurdiagrammen, runbooks en scripts gezamenlijk te beheren in hetzelfde DevSecOps-proces ontstaat een verifieerbare keten van ontwerp naar operatie.
Operationele borging, monitoring en audits
Na de technische activatie begint het echte werk: het dagelijks bewaken van de integriteit van Information Barriers. Operationele teams moeten duidelijke runbooks hebben waarin wordt beschreven hoe verzoeken tot uitzonderingen worden verwerkt, welke registraties nodig zijn en hoe escalaties verlopen. In Nederlandse overheden komt het geregeld voor dat crisisteams of interdepartementale taskforces tijdelijk dwars door segmenten heen moeten opereren. In plaats van ad-hoc uitzonderingen te creëren, wordt in het runbook vooraf gedefinieerd welke functies dergelijk tijdelijke toegang mogen aanvragen, hoe lang de toegang geldig blijft en welke bewijsstukken (bijvoorbeeld ministeriële besluiten of NCTV-instructies) moeten worden opgeslagen in het dossier. Deze procedurele discipline is noodzakelijk om later tijdens parlementaire enquêtes of gerechtelijke onderzoeken te kunnen aantonen dat er nooit ongecontroleerde communicatiestromen zijn ontstaan.
Monitoring vormt de tweede pijler van operationele borging. Naast de standaardrapporten uit Microsoft Purview moet er een koppeling zijn met het centrale loggingplatform, bijvoorbeeld Microsoft Sentinel of Splunk. Hierin worden alertregels opgesteld die signaleren wanneer policies worden aangepast, wanneer uitzonderingen lang open blijven staan of wanneer een segment ongewoon snel groeit doordat HR-gegevens verkeerd zijn aangeleverd. Door dergelijke signalen te koppelen aan het Configuration Management Database (CMDB) en het risicoregister kan de organisatie aantonen dat er een closed loop bestaat waarin bevindingen leiden tot correctieve maatregelen. Dit sluit aan op de eisen uit de BIO-paragraaf over continue verbetering en op de NIS2-verplichting tot risicogestuurd toezicht.
Auditvoorbereiding is de derde component. Jaarlijks moeten boards en toezichthouders kunnen overleggen dat Information Barriers daadwerkelijk werkt. Dat betekent dat naast technische logging ook narratieve rapportages beschikbaar moeten zijn. Een goed praktijkvoorbeeld is een kwartaalrapport waarin per segment wordt beschreven hoeveel communicatiepogingen zijn geblokkeerd, welke uitzonderingen zijn goedgekeurd, welke incidenten hebben plaatsgevonden en welke lessons learned naar voren zijn gekomen. Deze rapportage wordt besproken in het compliance-comité, waarna besluiten over beleidswijzigingen, aanvullende training of toolingverbeteringen worden vastgelegd. Door dezelfde rapportage te gebruiken voor in- en externe audits ontstaat consistentie en wordt voorkomen dat het team vlak voor een audit halsoverkop data moet verzamelen.
Tot slot hoort bij operationele borging een volwassen human factor-programma. Medewerkers moeten begrijpen waarom bepaalde chats of vergaderingen niet werken, anders ontstaat er frustratie en zoeken zij ongedocumenteerde omwegen zoals privékanalen of shadow IT. Communicatiecampagnes leggen uit welke regelgeving wordt ondersteund, hoe uitzonderingen werken en welke kanalen wél zijn toegestaan voor samenwerking. Servicedesks krijgen scripts waarmee zij vragen kunnen beantwoorden zonder dat gevoelige details over segmenten worden prijsgegeven. Door opleiding, monitoring, audits en communicatie te combineren, ontwikkelt Information Barriers zich van een technische feature naar een bewezen control die zowel binnenlandse als Europese toezichthouders overtuigt.
Om dat te onderbouwen worden concrete KPI’s en maturity-assessments toegevoegd aan het reguliere planning-en-controlproces. Denk aan het percentage uitzonderingsverzoeken dat binnen de afgesproken Service Level Agreement wordt afgehandeld, het aantal medewerkers dat jaarlijks training volgt en de tijd die nodig is om een misconfiguratie te herstellen. Door deze metrics te koppelen aan de governance dashboards voor de Nederlandse Baseline voor Veilige Cloud, ontstaat een transparante dialoog met bestuurders over de staat van ethical walls en de investeringen die nodig zijn om deze blijvend te versterken.
Information Barriers bewijst zijn waarde alleen wanneer segmentatie, techniek en governance elkaar continu versterken. Door het juridische kader te vertalen naar identitygestuurde segmenten, policies te automatiseren via Infrastructure as Code en operationele teams te voorzien van runbooks en analysetools, ontstaat een systeem dat audits met vertrouwen tegemoet treedt. Nederlandse organisaties kunnen daarmee aantonen dat zij insider trading, beleidsbeïnvloeding, onderzoeksbias of ongewenste gegevensuitwisseling actief voorkomen, terwijl zij tegelijkertijd de noodzakelijke samenwerking tussen programma’s, ketenpartners en leveranciers in goede banen leiden.
De Nederlandse Baseline voor Veilige Cloud vraagt om deze integrale benadering: ontwerp ethische muren niet als geïsoleerd project, maar als onderdeel van een bredere compliance-architectuur waarin ook classificatie, identity governance, records management en incidentrespons samenkomen. Wie die lijn vasthoudt, bouwt een duurzame verdedigingslaag die standhoudt tegen veranderende regelgeving en de steeds kritischer blik van toezichthouders.