De IT-dienstverlener kan Microsoft 365 technisch configureren, operationele gegevens monitoren en bewijs verzamelen volgens gemaakte afspraken. De klantorganisatie blijft verantwoordelijk voor de interne beleidsregels, de inhoudelijke beoordeling van rapportages, risicoacceptatie, goedkeuring van uitzonderingen en formele aftekening dat de inrichting aan het eigen beleid voldoet.
In het kort: verantwoordelijkheid voor auditbewijs in Microsoft 365
Auditbewijs is pas bruikbaar wanneer technische gegevens, bewaartermijnen en klantbesluiten als één proces zijn ingericht. De kern is een heldere scheiding tussen operationele bewijslevering en inhoudelijke beleidsverantwoordelijkheid.
- Bepaal per controle of technisch gegenereerd bewijs volstaat of dat menselijke beoordeling en formele fiattering nodig zijn.
- Stem de bewaartermijn vooraf af op de volledige periode die aantoonbaar moet blijven; ontbrekende historie is later niet te herstellen.
- Wijs expliciet toe wie bewijs verzamelt en bewaart, en wie aan klantzijde beoordeelt, risico’s accepteert en aftekent.
- Behandel uitzonderingen als tijdelijke, traceerbare besluiten met goedkeuring, eindmoment en periodieke evaluatie.
- Gebruik rapportages en scores als input voor controle, niet als vervanging van de vastlegging dat klantgebonden acties en beleidsregels zijn beoordeeld.
- Kies tussen directe technische handhaving en beheerde uitzonderingen op basis van de benodigde operationele ruimte en de aantoonbaarheid van besluitvorming.
Verdeel auditbewijs naar controletype en bewaartermijn
De verdeling van verantwoordelijkheden voor auditbewijs begint bij twee vragen: komt het bewijs rechtstreeks uit een technische instelling, of vraagt de controle om een menselijke beoordeling? En: blijft dat bewijs lang genoeg beschikbaar voor de periode die de organisatie wil aantonen? Die vragen horen vóór de eerste controleperiode beantwoord te zijn. Anders ontstaat een inrichting waarin instellingen wel werken, maar waarin de organisatie later niet meer kan aantonen wat er in een eerdere periode is gebeurd.
Deterministische technische controles leveren geautomatiseerd bewijs op. Het technisch blokkeren van legacy authenticatie is daarvan een voorbeeld: de configuratie en de bijbehorende loggegevens vormen een objectief vertrekpunt voor bewijsverzameling. De taak ligt hier bij het inrichten van de maatregel en het beschikbaar maken van de gegenereerde gegevens. Procedurele controles hebben een ander karakter. Een periodieke kwartaalreview van beheerrollen vraagt niet alleen om een lijst met rollen of activiteiten, maar ook om menselijke beoordeling en fiattering. Het relevante bewijs bestaat dan uit de uitgevoerde beoordeling én de vastlegging van de beslissing. Wie technische gegevens verzamelt, is daarom niet automatisch degene die kan verklaren dat een procedurele controle inhoudelijk is uitgevoerd.
De gekozen retentie bepaalt vervolgens hoeveel historie beschikbaar is. Volgens Microsoft-documentatie geldt voor Purview Audit Standard doorgaans een maximale retentie van 180 dagen; de beschikbare termijn kan afhankelijk zijn van licentie en configuratie. Voor Audit Premium noemt Microsoft voor logs van Entra ID, Exchange, SharePoint en OneDrive standaard één jaar retentie, met mogelijkheden om die periode uit te breiden tot tien jaar. Controleer de actuele licentievoorwaarden en inrichting voor de eigen tenant. Een langere bewaartermijn is daarmee geen administratieve voorkeur, maar een keuze die bepaalt of de gewenste bewijsperiode later nog beschikbaar is.
Een controle die bewijs over een eerdere periode vraagt, kan dus niet wachten met die keuze tot het moment waarop de controle plaatsvindt. Bij technisch bewijs gaat het om de beschikbaarheid van de juiste loggegevens; bij procedureel bewijs om de combinatie van gegevens, beoordeling en aftekening. De vereiste historie bepaalt welke retentie past, terwijl het controletype bepaalt welke handeling daarnaast nog nodig is. Zo voorkomt de organisatie dat een logvenster, een reviewmoment en een bewijsverantwoordelijke los van elkaar worden ingericht.
Bronnen bij deze sectie: microsoft.com, itsecure.hu, isaca.org
Ongeplande exports en uitzonderingen maken bewijs achteraf onvolledig
Brede afspraken over beheer leveren geen dossier op wanneer niemand de bewijsexport beheert. Dat wordt zichtbaar zodra niet de actuele Microsoft 365-configuratie, maar de werking in een eerdere periode moet worden aangetoond. Twee hypothetische situaties laten zien waar de vertraging ontstaat.
Situatie 1: historische gegevens ontbreken. Bij onboarding zijn verantwoordelijkheden algemeen beschreven, maar een geautomatiseerde bewijsexport en periodieke controle zijn niet ingericht. Terwijl operationele uitzonderingen doorlopen, schuiven relevante gebeurtenissen buiten het beschikbare logvenster. Komt later de vraag om historische controlewerking aan te tonen, dan ontbreekt een deel van de gegevens. Hier ontbreekt niet zozeer een beleidsregel als wel een aangewezen partij die de export uitvoert en bewaart. Dat kan leiden tot een auditafwijking.
Situatie 2: een tijdelijke uitzondering wordt blijvend. De servicedesk richt ad hoc een Conditional Access-uitzondering in, zonder geregistreerde vervaldatum en zonder schriftelijk fiat. De uitzondering blijft daardoor maanden actief. Een externe auditor kan vervolgens een toegangsmogelijkheid aantreffen waarvoor noch de goedkeuring noch het eindmoment aantoonbaar is. In dit hypothetische geval kunnen hercertificeringsvertraging en herstelkosten volgen uit ontbrekende vastgelegde besluitvorming.
Ook handmatige zoekacties in de Purview Audit-portal kennen limieten. Microsoft-documentatie noemt bijvoorbeeld maximaal 50.000 records bij Standard en 100.000 bij Premium; controleer de actuele limieten voor de gebruikte licentie en zoekmethode. Voor structurele bewijsvoering over een volledig boekjaar zijn losse exports daarom niet altijd toereikend; een API-koppeling of geautomatiseerde archivering kan dan nodig zijn. De grens tussen een bruikbare rapportage en een incompleet dossier ligt bij de vastgelegde verantwoordelijkheid voor export, opslag en uitzonderingen.
Bronnen bij deze sectie: microsoft.com
Rapportages tellen pas mee na interne validatie en aftekening
Bij controles waarbij intern beleid, een uitzondering of risicoacceptatie moet worden beoordeeld, is een Microsoft 365-rapport niet het eindpunt. De dienstverlener kan de operationele gegevens aanleveren en de technische context duiden; de klantorganisatie bepaalt vervolgens of die gegevens aan de eigen beleidsregel voldoen en welke afwijking aanvaardbaar is.
| Stap | Rol van de IT-dienstverlener | Besluit aan klantzijde | Vaste controlehandeling |
|---|---|---|---|
| Verzamelen | Levert de operationele gegevens en rapportage aan. | Bepaalt welke beleidsregel en controle met de gegevens moeten worden onderbouwd. | Overzicht van Global Admins beschikbaar maken voor beoordeling. |
| Inhoudelijk valideren | Licht de technische herkomst en context van de gegevens toe. | Beoordeelt of de aangeleverde gegevens aansluiten op de interne beleidsregel. | Global Admins elk kwartaal herbeoordelen. |
| Risico accepteren | Levert feiten over de afwijking of uitzondering. | Keurt een uitzondering goed of accepteert het resterende risico. | MFA-uitzonderingsgroepen maandelijks evalueren. |
| Aftekenen | Ondersteunt met de onderliggende operationele gegevens volgens de gemaakte afspraken. | Legt de beoordeling, uitzondering en goedkeuring formeel vast. | Activaties van break-glass accounts binnen 24 uur volledig traceerbaar houden. |
Een Purview Compliance Manager-score kan verbeteracties zichtbaar maken, maar vervangt geen interne validatie. Wanneer klantbeheerde verbeteracties niet operationeel worden getoetst, blijft onduidelijk of zij in de eigen omgeving zijn uitgevoerd en beoordeeld. Vertrouwt een organisatie alleen op de score terwijl een auditor om die validatie vraagt, dan ontbreekt vooral de vastlegging van de beoordeling en eventuele risicoacceptatie.
Bronnen bij deze sectie: microsoft.com, itsecure.hu, isaca.org
Leg retentie en de inhoudelijke reviewer vast vóór het eerste bewijsvenster sluit
Deze checklist richt zich op twee afspraken die vóór het eerste bewijsvenster beschikbaar horen te zijn: een bewaarkeuze die aansluit op de vereiste bewijsperiode en een benoemde persoon aan klantzijde die ontvangen rapportages inhoudelijk beoordeelt. De technische beschikbaarheid van gegevens en de formele beoordeling ervan zijn afzonderlijke taken.
- Toets de retentie tegen de volledige bewijsperiode. Leg vast of de organisatie bewijs over een volledig boekjaar nodig heeft en vergelijk die periode met de beschikbare bewaartermijn. Microsoft vermeldt voor Purview Audit Standard doorgaans een maximale retentie van 180 dagen. Wanneer een volledig boekjaar aantoonbaar moet blijven, kan de inrichting afhankelijk zijn van Purview Audit Premium-licenties of geautomatiseerde externe logarchivering. Verifieer de actuele mogelijkheden voor de eigen licentie en tenant. Deze keuze bepaalt of de gegevens nog bestaan op het moment dat ze in een dossier nodig zijn. Leg ook vast welke voorziening de langere historie bewaart, zodat bewijs niet over verschillende locaties verspreid raakt zonder duidelijke basis voor het dossier.
- Benoem een inhoudelijke reviewer voor elke provider-rapportage. Een maandelijkse compliance- of beveiligingsrapportage heeft geen formele betekenis wanneer binnen de klantorganisatie niemand is aangewezen om de inhoud te beoordelen en af te tekenen. Dit patroon van een ongedefinieerde reviewer laat rapportages circuleren zonder besluit, interpretatie of zichtbare opvolging. Leg daarom bij de rapportage vast welke klantrol de inhoud beoordeelt, welke uitkomst wordt geregistreerd en waar de aftekening terug te vinden is. De provider kan de rapportage genereren; de beoordeling of die rapportage het interne beleid onderbouwt, blijft een klantverantwoordelijkheid. Automatische archivering houdt gegevens beschikbaar, maar neemt deze inhoudelijke validatie niet over.
Bronnen bij deze sectie: microsoft.com, isaca.org
Een register zonder opvolging laat klantspecifieke gaten open
Na de interne validatie is een centraal overzicht nodig om de relatie tussen beleid, inrichting en bewijs vast te houden. Een controle- en bewijsregister is hierbij een intern document of sjabloon, geen standaard Microsoft 365-object. Per maatregel legt het vast welk bewijs nodig is, waar het staat en wie de inhoud beoordeelt. Daarmee wordt voorkomen dat verbeterpunten wel zichtbaar zijn, maar niet aantoonbaar aan een klantspecifieke beleidsregel zijn gekoppeld.
- Toets klantbeheerde verbeterpunten tegen het eigen beleid. Leg voor ieder relevant verbeterpunt vast welke beleidsregel eraan ten grondslag ligt en welke Microsoft 365-configuratie de uitvoering moet laten zien. Rapportages en scores kunnen het gesprek over openstaande acties ondersteunen, maar het register legt de specifieke klantactie en de toetsing daarop vast.
- Vul het controle- en bewijsregister per maatregel volledig in. Neem minimaal de beleidsreferentie, de Microsoft 365-configuratielocatie, het bewijstype, de evaluatiefrequentie, de operationele verzamelaar en de inhoudelijke validator op. De verzamelaar levert het aangewezen bewijsobject aan; de validator beoordeelt of dat object de koppeling tussen de beleidsregel en de configuratie daadwerkelijk onderbouwt. Ontbreekt een van deze velden, dan blijft bij een managementvraag onduidelijk waar de instelling is vastgelegd, welk bewijs verwacht wordt of wie de inhoud ervan moet beoordelen.
Bronnen bij deze sectie: microsoft.com
Wanneer is een goedgekeurde uitzondering beter dan direct blokkeren?
De keuze tussen directe blokkering en een goedgekeurde uitzondering gaat over de verhouding tussen uniforme technische handhaving en operationele ruimte. Beide modellen vragen om een aantoonbare koppeling tussen beleid, instellingen en bewijs; alleen de aard van de besluitvorming verschilt.
- Wanneer past directe blokkering?
Direct blokkeren van alle non-compliant apparaten via Intune past bij een beleid dat afwijkingen zo veel mogelijk technisch wil uitsluiten. Deze vorm van automatisering kan auditafwijkingen beperken, omdat er minder ruimte is voor een apparaat dat buiten de gestelde eis valt. Daar staat tegenover dat directe blokkering de operationele flexibiliteit kan beperken. Als het werkproces vervolgens toch een uitweg zoekt buiten de beheerde inrichting, kan dat schaduw-IT in de hand werken. De keuze voor blokkering is daarmee vooral passend wanneer de beleidsregel weinig ruimte laat voor individuele afwijkingen en de gevolgen van die beperking in de operatie aanvaardbaar zijn. - Wanneer past een model met goedgekeurde uitzonderingen?
Een flexibel model is verdedigbaar wanneer een uitzondering formeel wordt beheerd in plaats van informeel gedoogd. Dat vraagt een andere beheerslast dan directe blokkering: de organisatie houdt zichtbaar welke beleidseis van toepassing is, aan welke Microsoft 365-instelling die eis is gekoppeld, welk bewijstype de uitzondering onderbouwt, waar dit bewijs wordt bewaard en volgens welk evaluatieritme de uitzondering terugkomt. Een gestructureerd controle- en bewijsregister maakt die route traceerbaar. Het register verandert een uitzondering niet in een vrije keuze; het maakt zichtbaar dat de uitzondering onderdeel is van een controleerbaar proces. Zonder formele klantbeslissing is een uitzondering geen alternatief voor blokkering, maar een onbelegde afwijking.
Maak bewijslevering pas onderdeel van de service na benoemde aftekening
Of de organisatie nu kiest voor directe blokkering of beheerde uitzonderingen, de gekozen werkwijze moet in de dienstverlening een vaste eigenaar en beoordelingsmoment krijgen. Een expliciete RACI-matrix maakt daarbij zichtbaar wie welke stap uitvoert en wie het besluit draagt.
Bij CloudSphere maken we in een transparante RACI-matrix expliciet onderscheid tussen operationele bewijsgeneratie door de provider en formele kwaliteitsvalidatie en risicoacceptatie door de klant. De waarde daarvan zit in de overdracht tussen beide rollen: het dossier bevat niet alleen wat er technisch is verzameld, maar ook welke klantrol de inhoud heeft beoordeeld en welke uitkomst daaruit volgde. Daarmee blijft beleidsverantwoordelijkheid zichtbaar bij de organisatie die het beleid voert.
Vaste kwartaaloverleggen geven die overdracht een terugkerend moment. Daar kunnen de interne proceseigenaar en de uitvoerende partij uitzonderingen, configuratiedrift en geaggregeerde auditdossiers behandelen. Het overleg levert pas aantoonbare sturing op wanneer de besproken uitkomsten ook worden afgestemd en afgetekend. Een configuratie die in de loop van een kwartaal verandert, een uitzondering die nog actief is of een dossier waarin gegevens zijn samengebracht: ieder onderwerp vraagt om een expliciete beoordeling in plaats van alleen distributie aan een groep ontvangers.
De financiële en operationele grens ligt bij onbelegd werk. Rapportagedistributie zonder benoemde klantvalidator en zonder aftekenmoment laat onduidelijk wie de inhoud heeft getoetst, welk risico is aanvaard en welke uitzondering nog geldig is. Dan kan er wel bewijs worden geproduceerd, maar bestaat er geen aantoonbaar governanceproces rond dat bewijs.
Bronnen bij deze sectie: isaca.org