Microsoft Purview Data Lifecycle Management: Van Bewaarbeleid tot Automated Records Management

Data lifecycle management is het spannendsveld waar legal compliance, security requirements en operational efficiency elkaar ontmoeten. Nederlandse overheidsorganisaties moeten voldoen aan de Archiefwet die verplicht tot bewaren van overheidsinformatie voor vastgestelde termijnen (vaak 10-100 jaar), terwijl de AVG vereist dat persoonsgegevens niet langer worden bewaard dan noodzakelijk. Deze ogenschijnlijk tegenstrijdige requirements vragen om sophisticated tooling die granular controle biedt over wat, hoe lang en onder welke condities data wordt bewaard of verwijderd. Microsoft Purview Data Lifecycle Management (voorheen Microsoft 365 Retention, hernoemd in 2022) biedt deze capabilities via retention policies (breed toepasbaar), retention labels (gebruiker- of auto-toegepast op specifieke content), en records management (onwijzigbare archiveringen met compliance reviews). Voor organisaties die opereren in highly regulated environments is correct geconfigureerd lifecycle management niet alleen een compliance requirement maar ook een security control: oude data die niet langer nodig is vormt een liability bij data breaches. Deze tutorial behandelt end-to-end implementatie van Purview Data Lifecycle Management met praktische scenario's uit Nederlandse overheidspraktijk.

Data Lifecycle Management Fundamentals: Concepten en Architectuur

Waarom Data Lifecycle Management?

Data lifecycle management is de onzichtbare ruggengraat onder professionele informatiehuishouding in de publieke sector. Iedere e‑mail, elk document, ieder Teams‑bericht en elke dataset doorloopt een levenscyclus: informatie wordt gecreëerd, gedeeld, geraadpleegd, soms aangepast en moet uiteindelijk worden bewaard of vernietigd. Voor Nederlandse overheidsorganisaties wordt die levenscyclus niet alleen bepaald door praktische overwegingen, maar vooral door een strak juridisch kader. De Archiefwet legt vast welke soorten overheidsinformatie voor welke termijn moeten worden bewaard en onder welke voorwaarden vernietiging is toegestaan. Tegelijkertijd verplicht de AVG organisaties om persoonsgegevens juist niet langer te bewaren dan noodzakelijk is voor het oorspronkelijke doel. Zonder geregisseerde levenscyclus ontstaan onvermijdelijk spanningen tussen deze kaders, groeit de hoeveelheid historische data onbeheersbaar door en wordt het vrijwel onmogelijk om tijdens een incident of juridische procedure snel de juiste informatie terug te vinden.

Juist in dat spanningsveld tussen bewaarplicht en dataminimalisatie biedt Microsoft Purview Data Lifecycle Management structuur. In plaats van ad‑hoc beslissingen over bewaren of verwijderen, definieer je expliciete bewaartermijnen en vernietigingsmomenten die zijn afgestemd op selectielijsten, interne beleidskaders en verwerkingsregisters. Voor archiefwaardige stukken, zoals beleidsdossiers, besluiten en formele correspondentie, kan een organisatie vasthouden aan lange of zelfs permanente bewaartermijnen. Voor tijdelijke of operationele informatie, bijvoorbeeld conceptdocumenten, werknotities of tijdelijke projectcommunicatie, kan een veel kortere termijn worden geconfigureerd. Door deze regels centraal vast te leggen en technisch af te dwingen ontstaat een consistent regime dat in audits en bij het Nationaal Archief onderbouwd kan worden.

De kernbouwstenen van Purview lifecycle management zijn de bewaarbeleid (retention policies), de bewaarlabels (retention labels) en de records‑functionaliteit. Bewaarbeleid werken op grote schaal: je geeft aan dat bepaalde workloads of locaties – denk aan alle Exchange‑postvakken, alle SharePoint‑sites of alle OneDrive‑accounts – onder een generiek regime vallen. Een ministerie kan bijvoorbeeld beslissen dat alle e‑mail standaard zeven jaar wordt bewaard, ongeacht of gebruikers berichten tussentijds verplaatsen of verwijderen. De technische implementatie gebeurt op de achtergrond in verborgen opslaglocaties, waardoor de dagelijkse werkprocessen voor medewerkers nauwelijks veranderen, terwijl de organisatie wel zeker weet dat cruciale communicatie bij een Wob‑ of Woo‑verzoek of een rechtszaak nog beschikbaar is.

Bewaarlabels vullen deze brede laag aan met fijnmazige controle. In plaats van een hele locatie onder één standaardtermijn te brengen, kan een organisatie labels publiceren die gebruikers – of slimme automatische detectieregels – op individuele documenten en berichten toepassen. Denk aan labels voor contractdossiers, aanbestedingsdocumentatie, staatsgeheime stukken of onderzoeksdossiers met gevoelige persoonsgegevens. Elk label kan zijn eigen bewaartermijn, startmoment en eindactie hebben. Bovendien kan een label een item markeren als record, waardoor het document of bericht gedurende de bewaartermijn niet meer te wijzigen is. Dat is ess sentieel om de integriteit van bewijsstukken en formele besluiten aan te tonen richting toezichthouders en rechters.

De records‑functionaliteit vormt de meest strikte laag van lifecycle management. Wanneer informatie formeel als record is vastgelegd, wordt de inhoud feitelijk bevroren: gebruikers kunnen deze nog raadplegen, maar niet meer aanpassen of verwijderen. Voor zogeheten regulatory records geldt dat zelfs beheerders het object niet zonder meer kunnen verwijderen. In combinatie met een zorgvuldig opgezet file plan – een digitale variant van het traditionele ordeningsplan waarmee archieven al decennialang werken – kan een organisatie zo een compleet stelsel opbouwen waarin elke categorie informatie een duidelijk doel, een vastgelegde bewaartermijn en een voorspelbaar eindpunt heeft. Disposition‑workflows zorgen er vervolgens voor dat na afloop van de termijn niet automatisch wordt verwijderd, maar dat een recordsmanager of archivaris eerst expliciet beoordeelt of vernietiging verantwoord is of dat overbrenging naar het Nationaal Archief nodig is.

Onder de motorkap werkt Purview met verschillende technische opslaglagen die ervoor zorgen dat bewaartermijnen worden afgedwongen zonder gebruikers direct te beperken. In Exchange Online worden verwijderde berichten bijvoorbeeld in speciale verborgen mappen bewaard totdat de termijn is verstreken. In SharePoint en OneDrive wordt een kopie van documenten vastgehouden in een verborgen Preservation Hold Library, zelfs als gebruikers het oorspronkelijke document verwijderen of overschrijven. Teams maakt gebruik van dezelfde mechanismen, waarbij chatberichten in Exchange en bestanden in SharePoint worden beveiligd door het ingestelde beleid. Hierdoor kan een organisatie met vertrouwen aangeven dat informatie niet voortijdig verloren gaat, terwijl medewerkers toch de vrijheid behouden om hun werkruimtes op te schonen.

Een belangrijk ontwerpprincipe binnen Purview is dat de meest beschermende regel altijd voorrang krijgt. Wanneer een document onder meerdere beleid valt, geldt de langste bewaartermijn. Als zowel een algemeen beleid als een specifiek label van toepassing zijn, wint het label. Dit principe voorkomt dat per ongeluk te korte termijnen worden toegepast en biedt een robuuste basis voor juridische verdediging. Daarnaast is er een duidelijk onderscheid tussen bewaren en vernietigen: gedurende de bewaartermijn blokkeren de systemen pogingen om definitief te verwijderen, maar na afloop kan ofwel automatisch, of na een expliciete beoordeling, alsnog worden vernietigd. Daarmee ontstaat een gecontroleerde, reproduceerbare levenscyclus die zowel de Archiefwet als de AVG serieus neemt.

Tot slot draagt goed ingericht lifecycle management niet alleen bij aan juridische naleving, maar ook aan informatiebeveiliging en operationele efficiëntie. Oude data die geen functionele of wettelijke waarde meer heeft, vergroot het schadebeeld bij een datalek en belast back‑ups, zoekindexen en migraties onnodig. Door verouderde en triviale informatie systematisch op te ruimen, blijven zoekresultaten relevanter, dalen opslag‑ en beheerlasten en wordt het eenvoudiger om te voldoen aan nieuwe wetgeving of interne beleidswijzigingen. Data lifecycle management met Microsoft Purview is daarmee geen puur compliance‑project, maar een strategische investering in een beheersbare, veilige en toekomstbestendige informatiehuishouding.

Retention Policies: Organisation-Wide Bewaarbeleid

Retention policies vormen de basislaag van Microsoft Purview Data Lifecycle Management en zijn bij uitstek geschikt om organisatiebrede afspraken over bewaartermijnen technisch af te dwingen. In plaats van per gebruiker, site of team een eigen regeling te hanteren, leg je met één beleid vast dat bijvoorbeeld alle e‑mail zeven jaar wordt bewaard, alle documenten in SharePoint en OneDrive tien jaar beschikbaar blijven en dat Teams‑berichten na vijf jaar automatisch worden verwijderd. Voor Nederlandse overheidsorganisaties sluit dit goed aan op de selectielijsten die per categorie archiefbescheiden aangeven hoe lang informatie minimaal bewaard moet blijven. Door een generiek beleid als vangnet te gebruiken, voorkom je dat belangrijke correspondentie of besluiten buiten de reikwijdte van bewaartermijnen vallen omdat niemand eraan dacht een specifiek label toe te passen.

Een typische eerste stap is het inrichten van een standaard e‑mailbeleid. Daarbij wordt vastgelegd dat alle berichten vanaf het moment van verzenden of ontvangen gedurende een vaste periode bewaard blijven, ongeacht wat de gebruiker in zijn postvak doet. Medewerkers kunnen berichten nog steeds verwijderen of opruimen zoals ze gewend zijn, maar op de achtergrond zorgt Exchange ervoor dat er een kopie wordt vastgehouden in een speciale, niet‑zichtbare opslaglocatie. Pas na afloop van de termijn worden deze berichten definitief en onherstelbaar verwijderd. Dit sluit aan bij de praktijk waarin correspondentie vaak nog jaren later relevant blijkt voor een Woo‑verzoek, een parlementaire enquête of een juridische procedure. Door het beleid centraal te definiëren, hoeft de individuele medewerker niet meer zelf te beoordelen welke e‑mails wel of niet bewaard moeten worden; de organisatie kiest een uniforme ondergrens die juridisch verdedigbaar is.

Voor documenten in SharePoint en OneDrive werkt het principe vergelijkbaar, maar speelt de rol van inhoud en context een grotere rol. Veel organisaties kiezen ervoor om alle documenten minimaal tien jaar te bewaren en daarna een vernietigingsproces te starten waarbij een recordsmanager of juridisch adviseur per verzameling documenten beoordeelt of vernietiging verantwoord is. Technisch gezien verplaatst SharePoint verwijderde documenten naar een verborgen Preservation Hold Library, waar zij blijven bestaan zolang de bewaartermijn loopt. Gebruikers ervaren dat hun documenten verdwijnen uit de bibliotheek wanneer zij ze verwijderen, maar vanuit het perspectief van de organisatie is het dossier nog volledig beschikbaar voor eDiscovery, interne onderzoeken en archiefvorming. Zodra de termijn verloopt, presenteert Purview de betreffende documenten in een overzicht voor beoordeling, inclusief relevante metadata, zodat een geïnformeerde beslissing genomen kan worden over vernietiging of verlenging van de bewaartermijn.

Ook voor samenwerking in Microsoft Teams zijn specifieke beleid nodig. Kanaalberichten vormen vaak een informele aanvulling op formele e‑mail, maar kunnen wel degelijk bestuurlijke relevantie hebben, bijvoorbeeld wanneer besluiten of instructies via Teams worden gedeeld. Door een bewaarbeleid te configureren dat kanaalberichten gedurende een vooraf bepaalde periode bewaart en daarna automatisch verwijdert, voorkom je dat Teams uitgroeit tot een onbeheersbaar archief van jaren aan chatgeschiedenis. Tegelijkertijd blijft de belangrijkste communicatie gedurende de noodzakelijke periode beschikbaar voor verantwoording en reconstructie. Voor privéchats, die technisch in Exchange‑postvakken worden opgeslagen, kan een apart beleid worden ingericht dat aansluit bij de aard van de communicatie en de mate waarin deze als officiële correspondentie wordt beschouwd.

Een interessant gebruik van retention policies is het ondersteunen van tijdelijke projecten. Projectsites in SharePoint worden vaak voor een aantal jaren intensief gebruikt en raken daarna in onbruik. Als er geen lifecycle‑regeling bestaat, blijven deze sites onbeperkt bestaan en vullen ze de omgeving met verouderde informatie. Door projectsites te markeren met een eigenschap die aangeeft of een project actief of afgesloten is, kan een adaptief bereik worden gemaakt dat automatisch alle afgesloten projecten groepeert. Op die groep kan vervolgens een beleid worden toegepast dat bepaalt dat de volledige site, inclusief documenten en pagina's, na een vaste periode wordt verwijderd. Projectleiders markeren zelf de afsluiting, waarna de technische klok begint te lopen. Dit zorgt voor een voorspelbare afronding en voorkomt dat vergeten projectomgevingen nog jaren onnodig persoonsgegevens en gevoelige informatie bevatten.

Retention policies spelen bovendien een belangrijke rol bij het implementeren van AVG‑principes zoals opslagbeperking en dataminimalisatie. Voor verwerkingen waarbij persoonsgegevens slechts kort nodig zijn, zoals wervingsprocedures of klachtenafhandeling, kan een beleid worden ingericht dat uitsluitend gericht is op tijdige verwijdering. Zo kun je mailboxen of shareddossiers die gebruikt worden voor werving configureren met een beleid dat berichten en documenten na een jaar automatisch verwijdert, omdat er dan geen rechtmatig belang meer is om de gegevens te bewaren. Voor elke verwerking wordt in het verwerkingsregister en de bijbehorende juridische documentatie vastgelegd welke termijn geldt en op welke wettelijke grondslag die termijn is gebaseerd. Het beleid in Purview vertaalt deze papieren afspraken naar automatisch afgedwongen technische maatregelen.

Om grip te houden op het geheel is monitoring en rapportage essentieel. In de Purview‑portal is een dashboard beschikbaar waarin in één oogopslag zichtbaar is hoeveel items onder een bewaarbeleid vallen, waar vernietiging op korte termijn wordt verwacht en hoeveel documenten nog in de beoordelingswachtrij staan. Voor compliance‑rapportages kunnen overzichten worden geëxporteerd waarin per beleid en per locatie wordt weergegeven welke instellingen zijn geconfigureerd en welke volumes worden geraakt. Tijdens audits door interne auditors, de Algemene Rekenkamer of externe toezichthouders kan zo onderbouwd worden dat bewaartermijnen niet slechts beleidsmatig zijn vastgelegd, maar daadwerkelijk systematisch worden toegepast en gevolgd. Daarmee vormen retention policies het concrete bewijs dat de "Nederlandse Baseline voor Veilige Cloud" niet alleen op papier bestaat, maar ook aantoonbaar is geïmplementeerd in de dagelijkse praktijk.

Retention Labels & Records Management: Granular Controle en Immutable Archives

Retention Labels: Use Cases

Use Case 1: Staatsgeheime Documenten (25 Jaar, Regulatory Record)

Requirement: Documents classified as "Staatsgeheim" moeten 25 jaar bewaard, immutable, disposition review required

Configuration:

• Label Name: "SG - Staatsgeheim - 25 Jaar"
• Description: Voor gebruikers: "Dit document is geclassificeerd als Staatsgeheim en wordt 25 jaar bewaard"
• Retention Settings:
• Retain items for: 25 years
• Start retention period: When labeled (or when created)
• At end of retention period: Start disposition review
• Record Settings:
• Mark as record: Yes
• Record type: Regulatory record (cannot be deleted by anyone, including admins)
• Label Actions:
• Block editing: Yes (document becomes read-only)
• Block deletion: Yes (even admin can't delete)
• Mandatory description: User must enter reason when applying label

Auto-Apply Policy:

• Condition: Document contains keyword "STAATSGEHEIM" in header/footer
• Simulation: Test auto-apply on 100 documents, verify correct matches
• Deployment: Apply to specific SharePoint sites (classified document libraries)

User Experience:

• User creates document with "STAATSGEHEIM" header
• System automatically applies "SG" label within 24 hours
• Document becomes read-only (can view but not edit)
• If user tries to delete: Error message "This item is a record and cannot be deleted"
• Label visible in document properties (users can see retention info)

Legal & Compliance Value:

• Immutability: Demonstrates document integrity for legal proceedings
• Chain of custody: Audit logs show who accessed, when, no modifications possible
• Disposition control: After 25 years, archivist reviews for permanent archival or destruction

Use Case 2: Contracten (10 Jaar na Expiratie, Event-Based)

Requirement: Contracts bewaren 10 jaar na expiration date, dan auto-delete

Challenge: Retention moet starten op contract end date, niet creation date

Solution: Event-Based Retention

Step 1: Create Event Type

• Event Type: "Contract Expiration"
• Description: "Triggered when contract reaches expiration date"

Step 2: Create Retention Label

• Label Name: "Contract - 10 Years After Expiration"
• Retention Settings:
• Retain items for: 10 years
• Start retention period: When event occurs (Contract Expiration)
• At end of retention period: Delete items automatically
• Record: Mark as record (immutable during retention)

Step 3: Apply Label

• Contract documents: Manually or auto-apply label (via metadata "DocumentType" = Contract)
• Each contract: Has label applied when finalized

Step 4: Trigger Event

• Contract management system: Monitors contract expiration dates
• On expiration: System triggers "Contract Expiration" event for that contract
• Methods:
• PowerShell: New-ComplianceRetentionEvent -EventType "Contract Expiration" -SharePointAssetId
• Power Automate: Flow triggers event when expiration date reached

Step 5: Retention Calculation

• Event triggered: Retention clock starts (10 years from expiration)
• Example: Contract expires 2024-06-01, event triggered, retention until 2034-06-01
• After 10 years: Document auto-deleted

Benefits:

• Accurate retention: Starts from legally relevant date (expiration, not creation)
• Automation: No manual tracking of retention end dates
• Scalability: Handles thousands of contracts with different expiration dates

Use Case 3: Temporary Project Files (2 Jaar, Regular Record)

Requirement: Project documents bewaren during project + 2 years, user-deletable during project, immutable after project closure

Configuration:

• Label Name: "Project Files - 2 Years After Closure"
• Retention Settings:
• Retain items for: 2 years
• Start retention period: When event occurs (Project Closure)
• At end of retention period: Delete items automatically
• Record: Mark as record only when project closes
• During project: Regular document (editable, deletable)
• After closure: Becomes record (immutable)

Implementation:

• Project sites: Default label applied to document libraries
• Project active: Documents are regular (not records yet)
• Project closes: Admin triggers "Project Closure" event
• System: Converts all labeled documents to records
• Effect: Documents become read-only, retention clock starts
• After 2 years: Documents auto-deleted

File Plan Manager: Structured Records Classification

What: Hierarchical classification scheme for records (like traditional file plan)

Structure: ``` File Plan ├── Category: Departement (e.g., HR, Finance, IT) │ ├── Subcategory: Function (e.g., Recruitment, Payroll) │ │ ├── Retention Label: "Recruitment Files - 1 Year" │ │ ├── Retention Label: "Payroll Records - 7 Years" ```

Benefits:

• Structured classification: Aligns with organizational taxonomy
• Import/Export: Migrate from legacy records management systems
• Descriptors: Add metadata (authority, citation, notes) to labels
• Reporting: Generate file plan reports for compliance audits

Implementation Example: Ministerie File Plan

Category: Beleid & Regelgeving

• Subcategory: Wetsvoorstellen
• Label: "Wetsvoorstel - Permanent" (never delete)
• Authority: Archiefwet, Selectielijst Rijksoverheid
• Citation: Selectielijst item 1.1
• Subcategory: Ministeriele Regelingen
• Label: "Ministeriële Regeling - 20 Years"
• Disposition: Review by archivist after 20 years

Category: Projecten

• Subcategory: Infrastructuurprojecten
• Label: "Infrastructuurproject - 50 Years"
• Authority: Archiefwet (major public works)
• Subcategory: ICT Projecten
• Label: "ICT Project - 10 Years"
• Disposition: Auto-delete after 10 years

Disposition Reviews: Multi-Stage Approval

Scenario: Documents pending deletion after retention period, require legal + archivist approval

Configuration:

• Retention label: "General Records - 10 Years with Review"
• Disposition settings:
• Stage 1: Legal review (lawyer approves/denies)
• Stage 2: Archivist review (archivist approves/denies)
• Approval required: Both stages must approve before deletion

Workflow:

1. Document reaches end of 10-year retention
2. System: Moves document to "Pending Disposition" queue
3. Notification: Email to legal team
4. Legal reviewer: Reviews document in Purview portal

• Options: Approve disposal, Extend retention (+5 years), Relabel (permanent retention)
• Action: Selects "Approve disposal"

1. System: Moves to Stage 2
2. Notification: Email to archivist
3. Archivist: Reviews document

• Checks: Historical value? Precedent value? Public interest?
• Action: "Approve disposal" (no permanent retention needed)

1. System: Permanently deletes document
2. Audit log: Records both approvals, deletion timestamp, deleted by (system)

Rejection Flow:

• If any stage rejects: Document NOT deleted
• Reviewer extends retention: Document kept for additional period
• After extended period: Re-enters disposition review

Monitoring Disposition:

Purview portal → Records Management → Disposition

• Pending Disposition: Items awaiting review (action required)
• Completed Dispositions: Items disposed (audit trail)
• Disposition Reports: Generate reports for compliance (what deleted, when, by whom)

Proof of Disposition:

• Compliance requirement: Demonstrate items were disposed properly
• Purview provides: Export of disposed items (filename, date disposed, approvers, reason)
• Archiefwet: Maintain disposition logs for audit by Nationaal Archief

Adaptive Scopes: Dynamic Targeting voor Complex Governance

Zodra een organisatie de eerste generatie bewaarbeleid heeft ingericht, ontstaat vrijwel altijd de vraag hoe die beleid zich verhouden tot een dynamische werkelijkheid. Medewerkers veranderen van functie, nieuwe teams en SharePoint‑sites worden dagelijks aangemaakt en oude samenwerkingsomgevingen verdwijnen langzaam uit beeld. Als elk bewaarbeleid handmatig gekoppeld zou moeten worden aan specifieke gebruikers, groepen of sites, ontstaat al snel een onhoudbare beheerlast en groeit het risico dat nieuwe objecten buiten het bereik van het beleid vallen. Adaptive scopes in Microsoft Purview lossen dit probleem op door het bereik van beleid niet langer statisch te definiëren, maar te baseren op eigenschappen die automatisch worden bijgewerkt, zoals afdelingskenmerken in Entra ID, gevoeligheidslabels of specifieke site‑eigenschappen.

Het concept achter een adaptieve scope is eenvoudig: in plaats van een lijst namen of URL’s vast te leggen, beschrijf je in een query aan welke voorwaarden een gebruiker, site of groep moet voldoen om binnen het bereik te vallen. Voor gebruikers kan dat bijvoorbeeld een specifieke afdeling zijn, een landcode, een functietitel of een aangepaste attribuutwaarde. Voor sites gaat het om kenmerken zoals het toegepaste sjabloon, het gevoeligheidslabel, een zelf ingericht veld voor projectstatus of een patroon in de URL. Voor Microsoft 365‑groepen kun je denken aan naamgevingsconventies, het onderscheid tussen openbare en privé‑groepen of de aanmaakdatum. Purview evalueert deze queries periodiek en past het beleid automatisch toe op alle objecten die aan de criteria voldoen, ook als die later zijn aangemaakt of van status veranderen.

Een praktisch voorbeeld is het inrichten van een afwijkende bewaartermijn voor HR‑communicatie. Waar algemene e‑mail misschien zeven jaar wordt bewaard, kan voor personeelsdossiers en arbeidsrechtelijke correspondentie een langere termijn gewenst zijn. Met een adaptieve gebruikersscope die alle accounts omvat waarvan in Entra ID het veld "Department" op Human Resources is ingesteld, ontstaat automatisch een groep postvakken waarop een specifiek beleid kan worden toegepast. Zodra een nieuwe medewerker bij HR in dienst komt en door HR zelf of door de IAM‑keten met het juiste departement wordt aangemaakt, valt zijn postvak zonder extra beheerhandelingen binnen de HR‑scope. Verlaat iemand de afdeling, dan verdwijnt zijn postvak bij de volgende evaluatiecyclus weer uit het bereik. Zo blijft de configuratie synchroon lopen met de werkelijkheid van de organisatie.

Een tweede scenario betreft project‑ en programmaomgevingen in SharePoint. In veel organisaties worden projectsites aangemaakt voor de duur van een traject en daarna nauwelijks nog onderhouden, terwijl zij wel grote hoeveelheden documenten, plannen en rapportages bevatten. Door bij het aanmaken van een site een eigenschap "ProjectStatus" te registreren en die gedurende de levensduur van het project te beheren, kan een adaptieve sitescope worden ingericht die alle actieve projecten groepeert en een andere scope die alleen afgesloten projecten bevat. Actieve projecten vallen dan automatisch onder een beleid dat documenten uitsluitend bewaart en nooit automatisch verwijdert, zodat projectteams vrij kunnen werken zonder zich zorgen te maken dat informatie te vroeg verdwijnt. Zodra een project formeel wordt gesloten en de status wordt bijgewerkt, verschuift de site automatisch naar de scope voor afgesloten projecten, waar een beleid geldt dat bijvoorbeeld na twee jaar alle inhoud opruimt.

Adaptive scopes zijn ook krachtig in combinatie met classificatie en gevoeligheidslabels. Wanneer een organisatie Purview‑gevoeligheidslabels gebruikt om sites en Teams‑omgevingen te markeren als intern, vertrouwelijk of strikt vertrouwelijk, kan dezelfde classificatie direct worden gebruikt om bewaartermijnen te sturen. Sites met het label "Confidential" kunnen bijvoorbeeld twintig jaar worden bewaard, terwijl interne sites na tien jaar gereinigd mogen worden. Als een site later wordt opgewaardeerd naar een hogere gevoeligheidsklasse, past het bewaarbeleid zich vanzelf aan bij de eerstvolgende evaluatie. Daarmee ontstaat een consistent stelsel waarin gegevensclassificatie, toegangsbeveiliging en lifecycle management logisch op elkaar aansluiten.

Voor organisaties met meerdere geografische regio’s of een Microsoft 365 Multi‑Geo inrichting spelen adaptieve scopes eveneens een belangrijke rol. Door gebruikers op basis van landcode of kantoorlocatie te groeperen, kunnen per regio verschillende beleidsregels worden afgedwongen die rekening houden met nationale wetgeving en interne afspraken. Nederlandse gebruikers kunnen bijvoorbeeld een beleid krijgen dat expliciet is ontworpen om te voldoen aan de AVG en Nederlandse archiefregels, terwijl gebruikers in andere jurisdicties onder een ander regime vallen. Dit vermindert de noodzaak om per land een aparte tenant te beheren, terwijl toch aantoonbaar wordt gemaakt dat dataresidency en lokale eisen serieus worden genomen.

Belangrijk is dat adaptive scopes geen real‑time mechanisme zijn, maar periodiek worden geëvalueerd. In de praktijk betekent dit dat wijzigingen in eigenschappen, zoals een afdelingswissel of een aanpassing van een site‑attribute, binnen ongeveer een dag in de scope worden verwerkt. Voor de meeste governance‑scenario’s is dat ruim voldoende, maar voor zeer tijdkritische processen is het goed om hiervan bewust te zijn. Beheerders kunnen via de Purview‑portal of met PowerShell controleren welke objecten op een bepaald moment onder een adaptieve scope vallen en zo verifiëren of de query zich gedraagt zoals bedoeld. Bij de inrichting loont het de moeite om eerst met een simulatie‑ of rapportagemodus te werken, zodat zichtbaar wordt welke gebruikers, sites of groepen geraakt worden voordat definitieve beleid wordt gekoppeld.

Wanneer adaptive scopes zorgvuldig worden ontworpen en gekoppeld aan betrouwbare brongegevens, verandert lifecycle management van een handmatig, foutgevoelig proces in een grotendeels zelfonderhoudend systeem. Nieuwe teams, afdelingen en projecten worden vanzelf meegenomen, terwijl verouderde omgevingen geleidelijk naar een regime van opruimen en archiveren verschuiven. Daarmee ondersteunen adaptive scopes niet alleen de juridische en beveiligingsdoelstellingen van de "Nederlandse Baseline voor Veilige Cloud", maar reduceren zij ook het dagelijkse beheerwerk aanzienlijk en verkleinen zij de kans op menselijke fouten in complexe governance‑configuraties.

Compliance & Best Practices: Archiefwet, AVG en Operational Excellence

Archiefwet Compliance:

Requirement 1: Selectielijst Alignment

What: Selectielijst Rijksoverheid definieert bewaartermijnen per documentcategorie

Implementation:

• Map retention labels to selectielijst items
• Example:
• Selectielijst 1.1 (Wetsvoorstellen): Permanent → Retention label "Permanent Retention"
• Selectielijst 3.1 (Algemene correspondentie): 5 jaar → Retention label "Correspondence - 5 Years"
• Selectielijst 8.2 (Financiële stukken): 7 jaar → Retention label "Financial - 7 Years"

Documentation:

• File Plan Manager: Add selectielijst item numbers as "Citation" field
• Compliance reports: Show retention labels mapped to selectielijst
• Audit trail: Demonstrate bewaartermijnen based on selectielijst

Requirement 2: Vernietigingslijsten

What: List of documents destroyed, required by Archiefwet

Implementation:

• Purview disposition reports: Export list of disposed items
• Contents: Document title, date created, date disposed, retention label, approver
• Frequency: Quarterly reports to Nationaal Archief (if required)
• Retention: Vernietigingslijsten zelf moeten permanent bewaard worden

Requirement 3: Overbrenging naar Nationaal Archief

What: Permanent records moeten worden overgebracht to Nationaal Archief after 20 years

Challenge: Purview retention keeps items in Microsoft 365, not physical transfer

Solution:

• Retention label: "Permanent Retention - Transfer to Archive"
• After 20 years: Disposition review triggers
• Reviewer: Exports items, submits to Nationaal Archief (via e-Depot or physical)
• After transfer: Mark items as transferred in Purview (custom metadata)
• Optionally: Delete from M365 after successful transfer (free up storage)

AVG (GDPR) Compliance:

Requirement 1: Storage Limitation (Article 5(1)(e))

Principle: Personal data kept no longer than necessary

Implementation:

• Data mapping: Identify all processing activities with personal data
• Per activity: Define retention period with legal basis
• Example:
• Employee records: 7 years after employment end (tax law requirement)
• Recruitment data: 4 weeks after rejection (no longer necessary)
• Customer data: 10 years after last transaction (commercial law)
• Retention policies: Implement delete-only or retain-then-delete policies

Conflict Resolution: Archiefwet vs AVG

Conflict: Archiefwet requires long retention, AVG requires minimization

Resolution:

• AVG Article 89: Exception for archiving in public interest
• Government archives: Can keep personal data longer if archival purpose
• Safeguards: Implement pseudonymization, access controls
• Documentation: Maintain DPIA (Data Protection Impact Assessment) documenting justification

Example:

• Document: Personnel file with personal data
• Archiefwet: Bewaren 75 years (historical personnel research)
• AVG: Minimize retention
• Solution: Retain 75 years under Article 89 exception, pseudonymize after active period (e.g., after 10 years), restrict access to archivists only

Requirement 2: Right to Erasure (Article 17)

Principle: Individuals can request deletion of personal data

Challenge: Retention policies prevent deletion

Solution:

• Litigation hold: Place items related to erasure request on hold
• Review: Legal team assesses if retention is still lawful (public interest exception?)
• If no lawful basis: Override retention, delete data
• If lawful basis: Deny request, document justification
• Purview: Track erasure requests, document decisions

Operational Best Practices:

Best Practice 1: Start Broad, Then Granular

Approach:

1. Phase 1: Org-wide retention policies (safety net)

• All emails: 7 years
• All documents: 10 years
• All Teams: 5 years

1. Phase 2: Retention labels for exceptions

• High-value records: Longer retention
• Temporary data: Shorter retention
• Regulatory records: Immutable

1. Phase 3: Adaptive scopes for automation

• Department-specific policies
• Project-based policies

Rationale: Policies provide baseline compliance, labels add granularity, scopes add automation

Best Practice 2: Test in Non-Production

Process:

• Create test tenant or test users in production
• Configure retention policies in test environment
• Verify:
• Correct items retained
• Correct items deleted
• Disposition reviews work
• Audit logs captured
• Load test: Apply policy to 10K items, measure performance impact
• After validation: Deploy to production in phased approach

Best Practice 3: Monitor Disposition Queues

Risk: Items pending disposition pile up, reviewers overwhelmed

Mitigation:

• Daily monitoring: Check disposition queue size
• Alerts: If queue > 1000 items, notify reviewers
• Capacity planning: Ensure sufficient reviewer capacity (estimate: 100 items/hour review speed)
• Escalation: If queue growing, escalate to management for additional resources

Best Practice 4: Audit Log Everything

What to Log:

• Policy creation/modification/deletion
• Label application (manual and auto)
• Disposition actions (approved/denied/extended)
• Hold applications (who placed hold, why)
• Retention overrides (manual deletions despite retention)

Use Cases:

• Compliance audits: Demonstrate control over retention
• Incident response: Investigate unauthorized deletion
• Forensics: Track chain of custody for legal proceedings

Purview Audit Search:

• Activities: Filter by "Retention policy", "Retention label", "Disposition review"
• Date range: Last 90 days (or export to Log Analytics for longer retention)
• Export: Generate audit reports for compliance

Best Practice 5: Communicate to Users

Why: Users confused by retention impact on their data

Communication Plan:

Before Deployment:

• All-hands email: "New data retention policies rolling out"
• Explanation: Why (compliance), What (policies), When (rollout date)
• FAQ: Common questions (Can I still delete? What happens after retention?)

During Deployment:

• Department-specific training: How retention affects your work
• Super-user program: Departmental champions answer questions
• Helpdesk preparation: Train support staff on retention topics

After Deployment:

• User guide: Published in intranet
• Video tutorials: How to apply retention labels
• Feedback mechanism: Users report issues, questions

Sample User Communication:

Subject: New Document Retention Policies - What You Need to Know

Dear Colleagues,

Starting [Date], our organization is implementing automated document retention policies to comply with Archiefwet and AVG requirements.

What changes:

• Emails: Automatically retained for 7 years, then deleted
• Documents: Automatically retained for 10 years, then reviewed
• Teams messages: Retained for 5 years, then deleted

What you need to do:

• Continue working normally - retention happens automatically
• Apply retention labels to special documents (training provided)
• Do NOT try to circumvent retention (legal violations)

Questions? Visit our FAQ: [intranet link] Contact IT Helpdesk: [email/phone]

Thank you, IT & Compliance Team

Best Practice 6: Regular Compliance Reviews

Frequency: Quarterly

Agenda:

1. Policy inventory: List all active retention policies/labels
2. Coverage analysis: What % of data is under retention?
3. Disposition backlog: How many items pending review?
4. Audit findings: Any issues found in audits?
5. Regulatory updates: Changes in Archiefwet, AVG?
6. Policy updates: Do retention periods need adjustment?
7. Action items: Tasks assigned with owners and deadlines

Attendees: CISO, Compliance Officer, Records Manager, Legal, IT

Deliverable: Compliance review report for management

Microsoft Purview Data Lifecycle Management is een sophisticated platform dat veel verder gaat dan simpelweg "bewaar X jaar en delete". De combinatie van retention policies voor brede dekking, retention labels voor fijnmazige controle, adaptive scopes voor dynamische targeting, event-based retention voor business-gedreven lifecycle en records management voor immutable compliance biedt Nederlandse overheidsorganisaties de tools om te voldoen aan complexe en soms conflicterende requirements van Archiefwet en AVG. Succes vereist echter meer dan alleen het aanzetten van policies – het vraagt om doordacht ontwerp waarin legal, compliance en operationele requirements worden gebalanceerd, grondige testen om onbedoelde verwijderingen te voorkomen, gebruikerscommunicatie zodat mensen begrijpen wat er met hun data gebeurt en continue monitoring om te borgen dat beleid blijft werken zoals bedoeld. Voor organisaties die deze reis beginnen: start met org-wide policies als vangnet, voeg labels toe voor uitzonderingen, automatiseer met adaptive scopes en bouw geleidelijk naar volledige records management-maturiteit. De investering in correct geconfigureerd lifecycle management betaalt zich direct terug in lager compliancerisico, lagere opslagkosten en betere datahygiëne.