Als sysadmin denk je bij SCCM al snel aan collections, software distribution en patch cycles. Niet aan privacywetgeving. En toch is de kans groot dat je er vroeg of laat mee te maken krijgt — want zodra je software uitrolt die persoonsgegevens verwerkt, of je inventariseert hardware waaraan gebruikers gekoppeld zijn, zit je middenin AVG-territorium. Geen paniek. Dit is oplosbaar. Maar je moet wel weten waar je staat.
Waarom AVG en SCCM vaker samenkomen dan je denkt
SCCM is een krachtige tool. Misschien wél te krachtig als je er even niet bij nadenkt. Hardware inventory, software inventory, user device affinity, resource discovery — het zijn stuk voor stuk features die persoonsgegevens kunnen bevatten of genereren. Weet je welke gebruiker op welk device zit? Dan heb je al een koppeling tussen een persoon en een apparaat, en dat is per definitie een persoonsgegeven onder de AVG.
Veel organisaties draaien SCCM al jaren zonder ooit serieus naar die dataverzameling te kijken. Dat is begrijpelijk — je bent druk met deployments, niet met juridische analyse. Maar de AVG maakt geen uitzondering voor drukke sysadmins. De wet geldt gewoon, ook voor wat er in je Configuration Manager-database staat. En die database is, eerlijk gezegd, een goudmijn aan gegevens als je er even induikt.
Het gaat niet alleen om wat je actief verzamelt. Software metering, voor- en nadelen afwegend, registreert ook welke applicaties gebruikers draaien en hoe lang. Dat klinkt onschuldig, maar het is feitelijk gedragsmonitoring. Afhankelijk van hoe je organisatie dat inzet, kan dat al snel een privacyvraagstuk worden waar HR of de ondernemingsraad iets over wil weten.
Wat de wet zegt en wat dat betekent voor je SCCM-inrichting
De AVG — officieel de Algemene Verordening Gegevensbescherming — verplicht organisaties om persoonsgegevens te verwerken op basis van een geldige grondslag, met een duidelijk doel, en niet langer dan noodzakelijk. Dat klinkt abstract, maar voor SCCM is het heel concreet te vertalen. Volgens de informatie van de Rijksoverheid zijn organisaties verplicht om een verwerkingsregister bij te houden van alle persoonsgegevens die ze verwerken — en daar valt je SCCM-inventarisatie gewoon onder.
Wat betekent dat in de praktijk? Een paar dingen die je nu al kunt regelen:
- Beperk hardware inventory tot wat je echt nodig hebt. SCCM inventariseert standaard een hoop klassen die je waarschijnlijk nooit gebruikt. Schakel ze uit. Minder data = minder risico = minder gedoe bij een audit.
- Stel retentieperiodes in. Configuration Manager bewaart discovery data en inventarisgegevens standaard behoorlijk lang. Ga naar Administration > Site Configuration > Sites > Site Maintenance en controleer je cleanup-taken. Zet ze aan als ze uitstaan.
- Documenteer je user device affinity-gebruik. Als je UDA actief gebruikt voor targeted deployments, leg dan vast waarom, voor wie, en op basis van welke grondslag. Dat hoeft niet in een juridisch document van vijftig pagina’s, maar het moet ergens staan.
- Wees voorzichtig met software metering. Als je het gebruikt voor licentieoptimalisatie, prima. Maar zorg dat het doel helder is en niet stilletjes verschuift naar prestatiemonitoring van medewerkers.
Het lastige is dat SCCM-beheerders zelden degenen zijn die het verwerkingsregister bijhouden. Dat is meestal iemand van juridische zaken of de privacy officer. Maar jij bent degene die weet wát er verzameld wordt. Die vertaalslag — van technische werkelijkheid naar juridische documentatie — moet ergens gemaakt worden, en dat lukt alleen als je als sysadmin aan tafel zit bij dat gesprek.
Een concreet startpunt: exporteer een overzicht van alle actieve hardware inventory-klassen uit je SCCM-omgeving en bespreek dat met je privacy officer. Dat is geen groot project, dat is een uurtje werk en een vergadering. En het laat zien dat je de boel serieus neemt, wat altijd goed is.
Praktische maatregelen die je vandaag nog kunt doorvoeren
Genoeg theorie. Laten we het hebben over wat je daadwerkelijk in de console kunt doen om je SCCM-omgeving AVG-vriendelijker te maken. Want wie heeft er nou niet een keer een collection gebouwd op basis van user discovery data zonder erbij na te denken wat er precies in die collection zit — en wie er straks mee gedeployd wordt.
Stap 1: Audit je discovery-methoden
Ga naar Administration > Hierarchy Configuration > Discovery Methods. Kijk welke methoden actief zijn. Active Directory User Discovery is de meest voor de hand liggende kandidaat: die haalt gebruikersattributen op uit AD en slaat ze op in de SCCM-database. Vraag jezelf af welke attributen je echt nodig hebt. Voornaam en achternaam voor UDA? Oké. Telefoonnummer, afdeling, manager? Alleen als je daar een concrete reden voor hebt.
Stap 2: Controleer je collection-queries
Collections die gebouwd zijn op gebruikersdata zijn prima, maar wees je bewust van wat je daarmee doet. Een collection van alle gebruikers in een bepaalde OU is functioneel. Een collection van alle gebruikers die een specifieke applicatie meer dan twee uur per dag gebruiken, begint al te ruiken naar iets wat je beter even kunt toetsen aan je privacy officer.
Stap 3: Stel data-retentie in
Dit is er eentje die veel omgevingen overslaan. Onder Site Maintenance vind je taken als “Delete Aged Discovery Data”, “Delete Aged Collected Files” en “Delete Aged Inventory History”. Standaard staan die op 90 dagen, maar check of dat voor jouw organisatie klopt. Sommige compliance-frameworks willen kortere retentieperiodes, andere juist langere voor audit-doeleinden. Stem dat af, leg het vast.
Stap 4: Beperk toegang tot gevoelige rapporten
SCCM-rapporten kunnen een schat aan gebruikersinformatie bevatten. Wie heeft er in jouw omgeving toegang tot de rapportageomgeving? Als het antwoord “iedereen met een domeinaccount” is, dan is dat een probleem. Gebruik role-based access control om rapportage te beperken tot mensen die er een legitieme reden voor hebben.
Stap 5: Documenteer en communiceer
Dit klinkt minder technisch, maar het is minstens zo belangrijk. Maak een intern document — een wiki-pagina, een Teams-kanaal, een gedeeld Word-bestand, het maakt niet uit — waarin je bijhoudt welke SCCM-features persoonsgegevens verwerken, op welke grondslag, en wie daarvoor verantwoordelijk is. Dat document is goud waard als er ooit een audit komt of als een medewerker een inzageverzoek indient.
Tot slot
AVG en SCCM zijn geen tegenpolen. Het is geen keuze tussen “goed beheer” en “privacy”. Met een beetje aandacht voor wat je inventariseert, hoe lang je dat bewaart en wie er toegang toe heeft, kun je gewoon je werk doen zonder dat je ‘s nachts wakker ligt van een boete van de Autoriteit Persoonsgegevens.
De meeste maatregelen die hier staan zijn geen grote projecten. Het zijn bewuste keuzes in een console die je toch al dagelijks open hebt. Dat is het mooie eraan: je hoeft geen privacy-expert te worden. Je hoeft alleen even stil te staan bij wat je tool allemaal doet — en of dat ook echt nodig is.
En als je twijfelt: vraag je privacy officer. Die is er niet voor niets.