Welkom bij alweer blog nummer 27 in onze reeks over grip krijgen op je informatie. Voordat we verder de diepte induiken stellen we ons graag nog even voor.
Wij zijn Willem Jonkers (Solution Engineer bij AvePoint) en Jeroen Bijdevier (Security Architect en Microsoft Certified Trainer). Samen bundelen we onze kennis vanuit de techniek en de beveiliging om organisaties te helpen grip te krijgen op hun Microsoft 365-omgeving.
Een gesprek dat ik onlangs had bij een klant begon met een heel concrete vraag: “Wat is nu eigenlijk het verschil tussen Data Lifecycle Management (DLM) en Records Management (RM)?” Een terechte vraag, want in de praktijk worden deze begrippen vaak door elkaar gebruikt. Ze werken deels met dezelfde bouwstenen, maar het gedrag en de bewijsvoering zijn wezenlijk anders. In deze blog leg ik dat verschil uit zoals ik het zelf inricht: op itemniveau, gestuurd door metadata, in plaats van via brede beleidsregels op sites of postbussen.
Waarom ik op itemniveau werk, niet op containerniveau
DLM biedt twee manieren om retentie in te richten: retention policies die op een hele container werken (een site, een postbus, een kanaal), en retention labels die op individuele items werken. Ik kies bewust voor de tweede route. Een container-brede policy behandelt elk document in een site hetzelfde, ongeacht of het om een concept-notitie of een formeel vastgesteld document gaat. In de praktijk lopen bewaartermijnen per documenttype juist sterk uiteen. Start archief is het zetten van het metadata label en dat werkt op itemniveau. In overheidsland vaak met MDTO labels (Metagegevens voor Duurzaam Toegankelijke Overheidsinformatie) maar die laat ik nu even achterwegen.
Mijn aanpak: koppel de retentie aan een metadataveld dat de gebruiker invult op het document zelf. Denk aan een keuzelijst ‘bewaartermijn’ vanuit de SharePoint term store. Zodra een gebruiker een waarde kiest, herkent Purview dat automatisch en past het juiste label toe zonder dat iemand ooit een retentielabel handmatig hoeft te selecteren. Het voordeel van deze methode is dat documenten in bulk gelabeld kunnen worden, iets wat met handmatig labelen veel werk is.
Data Lifecycle Management: het metadatalabel als basis
De technische keten die ik hiervoor gebruik, bestaat uit vier stappen:
- Term store – de mogelijke bewaartermijnen staan als terms in een term set (bijvoorbeeld ‘1 jaar’, ‘10 jaar’, ‘30 jaar’), gekoppeld aan een sitekolom op de documentbibliotheek middels een content type.
- Refinable String-mapping – de crawled property van die metadatakolom wordt gemapt naar een vooraf gedefinieerde RefinableString (00 t/m 199); alleen deze zijn toegestaan als voorwaarde in een auto-labelbeleid, een custom managed property werkt niet
- Query verifiëren – vóór het bouwen van het beleid test ik de zoekquery (bijvoorbeeld RefinableString01:”Retentie 10 jaar”) rechtstreeks in de SharePoint-zoekbalk, om zeker te weten dat de mapping klopt
- Auto-apply label policy – de geverifieerde query wordt de voorwaarde in het auto-labelbeleid; Purview past het label vervolgens automatisch toe op elk item dat aan de voorwaarde voldoet
Het resultaat: een standaard retentielabel op itemniveau, zonder recordstatus. Dat label regelt bewaren en (op termijn) verwijderen, maar blokkeert het bewerken van het document niet. Een gebruiker kan het bestand gewoon aanpassen; alleen het verwijderen wordt tegengehouden zolang de retentie loopt.
Wat deze aanpak niet biedt: er is geen recordstatus, geen bewijs van verwijdering (‘proof of disposition’), en geen File Plan-documentatie met autoriteitsverwijzingen. Voor puur ‘bewaren volgens beleid’ is dat geen probleem. Zodra een auditor of toezichthouder vraagt om aantoonbaarheid, loop je hier wel tegenaan.
Records Management: hetzelfde label, één vinkje verder
Het belangrijkste punt: de technische keten blijft hetzelfde. Records Management vraagt geen aparte infrastructuur, maar voegt eigenschappen toe aan hetzelfde label. Bij het aanmaken van een label in Purview bepaal je met twee instellingen het gedrag: Is record (Yes/No) en Is regulatory (Yes/No).
Is record: Yes
Zet je Is record op Yes, dan verandert het labelgedrag wezenlijk. Zodra het label via dezelfde metadatawaarde aan een item wordt toegekend, krijgt het item de status Locked. De gebruiker kan het document dan niet meer bewerken of verwijderen; alleen een beheerder kan het label nog aanpassen. Je kunt het label ook configureren met ‘Unlock this record by default’. Het item start dan als Unlocked, zodat er nog één laatste bewerkingsronde mogelijk is voordat het definitief wordt vastgezet. Deze lock/unlock-functionaliteit, ook wel record versioning, werkt alleen in SharePoint en OneDrive en niet in Exchange.
Is regulatory: Yes of No
Staat ‘Is regulatory’ op No (het meest gebruikte scenario), dan is het een gewone record: een bevoegde beheerder kan het label in uitzonderingsgevallen nog wijzigen of het item verwijderen. Staat het op Yes, dan wordt het een regulatory record: niemand kan dit label meer verwijderen, ook een Global Administrator niet. De termijn kan alleen worden verlengd, nooit verkort. Deze optie staat bewust niet standaard aan in de labelwizard; je schakelt hem eerst in met Set-RegulatoryComplianceUI -Enabled $true, een actie die zelf ook weer wordt gelogd.
File Plan: dezelfde labels, met documentatie erbij
Belangrijk om te weten: het File Plan (Purview-portal > Records Management > File plan) maakt geen nieuwe labels aan die ergens anders zouden zitten. Het toont dezelfde labels die je ook via Data Lifecycle Management ziet, aangevuld met optionele file plan descriptors zoals categorie, autoriteitstype en wetsverwijzing. Waar File Plan wel bij helpt: labels in bulk aanmaken via een .csv-import, en exporteren voor offline review. Wat File Plan niet doet: de RefinableString-mapping of de auto-apply policy zelf inrichten. Die stappen blijven altijd apart nodig, via SharePoint (voor de mapping) en de Label policies-tab (voor de auto-apply policy) ook als het label zelf via File Plan is aangemaakt. De file plan methode is in mijn werkzaamheden niet zinvol omdat ik op item zaken configureer en toch nog labels moet maken.
Disposition review: de menselijke laatste stap
Combineer je het label met een reviewer, dan moet iemand aan het einde van de bewaartermijn expliciet goedkeuren dat het item verwijderd, opnieuw gelabeld, of verlengd mag worden. Dit heet disposition review, en het vereist de rol Disposition Management. Een Global Administrator krijgt die rol niet automatisch. Reviewers en de metadata van al verwijderde items (de proof of disposition) vind je via Purview-portal > Records Management > Disposition.
Hetzelfde label, twee niveaus van bewijsvoering
| Aspect | DLM (Is record: No) | RM (Is record: Yes) |
| Trigger | Metadatawaarde op het item (via RefinableString-query) | Dezelfde metadatawaarde, zelfde mechanisme |
| Bewerken | Blijft mogelijk | Geblokkeerd (Locked), tenzij bewust unlocked |
| Verwijderen | Geblokkeerd tijdens retentie, label zelf is te wijzigen | Alleen door beheerder; bij regulatory door niemand |
| Bewijs | Geen proof of disposition | Proof of disposition bij verwijdering |
| Goedkeuring | Niet van toepassing | Optioneel: disposition review door aangewezen rol |
| Documentatie | Enkel labelnaam en instellingen | File plan descriptors: categorie, autoriteitstype, citatie |
Overheidsorganisaties werken vaak middels zaken en dossiers met de eerder aangegeven MDTO labels. Bij een Disposition review schiet mijn inziens Purview te kort. Zaken, dossier en gekoppelde zaken zijn niet terug te vinden in het Disposition review proces.
Tot slot
Het verschil tussen DLM en RM zit dus niet in aparte tooling of een apart proces. Het zit in één vinkje op hetzelfde label: ‘Is record’. De hele metadata-gedreven keten term store, RefinableString, geverifieerde query, auto-apply policy blijft voor beide identiek. Wat verandert, is wat er gebeurt zodra het label eenmaal is toegepast: blijft het item gewoon bewerkbaar (DLM), of wordt het vastgezet met bewijs van verwijdering achteraf (RM)?
Mijn advies is: begin met de metadatastructuur en verifieer die grondig, bepaal pas daarna per documentcategorie of ‘Is record’ nodig is, en zet ‘Is regulatory’ alleen in voor de categorieën waarbij vroegtijdige verwijdering echt nooit mag gebeuren. Heb je vragen, verbetering of andere zaken hoor ik deze natuurlijk graag. Ben benieuwd hoe andere dit aanpakken en leer graag.
