HR-gegevensbewaring is de discipline van beslissen hoe lang elk soort personeelsrecord moet bestaan, en dan het systeem het daadwerkelijk laten doen. Het is moeilijk om een reden die niets met technologie te maken heeft: het antwoord is anders in elk rechtsgebied en voor elke categorie record, en geen enkel getal kan overal correct zijn.
Dit artikel zet uiteen waarom er geen universele termijn is, hoe personeelsrecords uiteenvallen in groepen met verschillende klokken, welke principes de beslissing sturen, en wat verwijdering moet dekken om iets te betekenen.
Waarom is er geen enkele bewaartermijn?
Omdat de termijn wordt vastgesteld door wie gezag heeft over het record, en dat varieert per rechtsgebied en vaak per type record binnen één rechtsgebied.
Sommige termijnen bestaan omdat een vordering zo lang kan worden ingesteld, en de termijn is zo gesteld dat het bewijs de vordering overleeft. Sommige bestaan omdat een toezichthouder het record voor inspectie vereist. Sommige bestaan om de persoon over wie het record gaat te dienen, zodat die jaren later een referentie kan verkrijgen of een dienstverbandperiode kan bewijzen. En sommige bestaan louter omdat het systeem nooit is verteld ze niet langer te bewaren, wat helemaal geen regel is maar de afwezigheid ervan.
De praktische consequentie is dat wie bewaring ontwerpt de termijn moet behandelen als configuratie die door de beheerder voor zijn eigen rechtsgebied wordt aangeleverd, niet als een constante die door de ontwikkelaar wordt gekozen. Een hardgecodeerde duur is fout op de meeste plekken waar hij zal draaien, en hij is stil fout, omdat niets in het systeem controleert of het getal nog van toepassing is. Waar een termijn configureerbaar is, kan de beheerder ervoor instaan; waar hij is ingebakken, kan niemand dat.
Hoe verdelen personeelsrecords zich naar doel?
Naar waarvoor het record dient, want dat bepaalt zijn klok. Vier groepen dekken het meeste van wat een recruitmentsysteem bevat.
| Groep | Waarvoor het dient | Waarom zijn klok verschilt |
|---|---|---|
| Actieve werknemersrecords | Het dienstverband beheren | Bewaard zolang de relatie duurt, en gewoonlijk daarna |
| Voormalige werknemersrecords | Referenties, vorderingen en wettelijke plichten | Bewaard voor een periode na het einde van de relatie, vastgesteld door de beheerder |
| Materiaal van afgewezen kandidaten | Bewijs over een beslissing | Gewoonlijk het kortstlevende, omdat de beslissing is gesloten |
| Interviewnotities en beoordelingen | De redenering achter een beslissing | Vaak over het hoofd gezien, en de groep die het vaakst informeel wordt bewaard |
De laatste twee groepen veroorzaken de meeste problemen, en om dezelfde reden: ze worden midden in een proces gecreëerd, door mensen die niet aan een recordsregime denken, en ze leven vaak buiten het systeem dat al het andere beheert. Notities die in een vergadering worden gemaakt, berichten tussen interviewers en een spreadsheet om kandidaten te vergelijken zijn allemaal personeelsrecords. Een bewaarbeleid dat alleen het applicant tracking system dekt, dekt een deel van het plaatje.
Alle vier groepen als één record met één vervaldatum behandelen is de meest voorkomende ontwerpfout. Het levert het slechtste van beide uitkomsten op: kandidatenmateriaal dat veel langer wordt bewaard dan de beslissing vereist, en dienstverbandrecords die eerder verlopen dan de eigen verplichtingen van de beheerder toestaan.
Welke principes moeten de beslissing sturen?
Zes, en het zijn de gewone voor persoonsgegevens, toegepast op een recruitmentcontext.
- Doelbinding — verzamel het record voor een vastgesteld doel en hergebruik het niet later omdat het er toevallig is.
- Minimalisatie — bewaar wat het doel vereist en niets dat slechts nuttig zou kunnen zijn.
- Nauwkeurigheid — houd het record correct, en geef de persoon een weg om het te corrigeren.
- Opslagbeperking — definieer hoe lang elk record leeft, en handhaaf het in plaats van het aan te nemen.
- Integriteit en vertrouwelijkheid — beperk wie het record kan bereiken, en weet wie dat deed.
- Verantwoordingsplicht — wees in staat aan te tonen dat de eerste vijf daadwerkelijk gebeuren.
Twee van deze worden vaak beweerd en zelden geïmplementeerd. Opslagbeperking bestaat vaak als een geschreven beleid zonder mechanisme erachter, zodat records hun termijn overleven en niemand erachter komt. Verantwoordingsplicht betekent vaak een document in plaats van een praktijk, zodat er geen manier is om een vraag te beantwoorden over wat er is verwijderd en wanneer.
Minimalisatie verdient een specifieke waarschuwing in een recruitmentcontext, omdat de verleiding de andere kant op gaat. Extra informatie voelt onschadelijk bij het verzamelen en is precies het materiaal dat later blootstelling creëert. Een veld dat niet nodig is voor de beslissing is geen neutrale toevoeging; het is een aansprakelijkheid met een bewaarklok eraan vast.
Wat moet verwijdering dekken?
Alles wat het record heeft aangeraakt, wat bijna nooit één tabel is.
Het leven van een record laat sporen na op de plekken waar het langs is gekomen, en elk van die plekken heeft een regel nodig. Live opslag, back-ups en archieven, exports geproduceerd voor rapportage, logvermeldingen die veldwaarden bevatten, zoekindexen die uit het record zijn gebouwd, gecachte kopieën die door een integratie worden bewaard, en elke kopie die een persoon naar een lokaal apparaat heeft gedownload. De rij verwijderen en daar stoppen is een gangbare en ernstige onderschatting.
Drie onderscheidingen maken het ontwerp hanteerbaar. Scheid verwijdering van anonimisering, en wees eerlijk over welke van de twee wordt gedaan — de koppeling met een persoon verwijderen is niet hetzelfde als het record verwijderen, en een geanonimiseerd record dat opnieuw kan worden gekoppeld is niet geanonimiseerd. Scheid verval van verzoekgestuurde verwijdering, aangezien het ene volgens een schema loopt en het andere op een willekeurig moment aankomt en zich door dezelfde plekken moet voortplanten. En scheid het record van het bewijs dat de verwijdering plaatsvond, dat normaal de verwijdering zelf moet overleven.
Back-ups zijn het deel dat al dit verzet, omdat het gewone mechanisme voor het herstellen van de nieuwste toestand hetzelfde mechanisme is dat het verwijderde record bewaart. De gebruikelijke verzoende positie is dat back-ups zijn uitgesloten van onmiddellijke verwijdering maar gedekt moeten worden door een verval dat hen uiteindelijk bereikt, en dat een herstelde back-up de verwijderingen die sinds het nemen zijn gedaan opnieuw toepast. Welke positie ook wordt ingenomen, het moet een beslissing zijn die is opgeschreven in plaats van een omissie die niemand opmerkte.
Voor ontwikkelaars: bewaring als configuratie en purge
Behandel de termijn als data. Geef elke categorie record zijn eigen geconfigureerde termijn, aangeleverd door de beheerder, en laat het systeem handhaven wat het wordt verteld in plaats van een mening te dragen.
Vijf gewoonten maken het verschil. Tag elk record met de categorie die zijn klok bepaalt, zodat een purge records op regel kan vinden in plaats van via een met de hand onderhouden lijst. Koppel de klok aan de categorie in plaats van aan de tabel, omdat dezelfde tabel records van meerdere soorten bevat. Log de purge zelf — wanneer ze liep, wat ze matchte, en wat ze verwijderde — en bewaar dat log waar de purge het niet kan verwijderen. Maak de velden die u verzamelt degene die uw gedocumenteerde doel nodig heeft, zodat minimalisatie een eigenschap van het schema is in plaats van een belofte. En geef elke omgeving die personeelsdata bevat, inclusief test- en demonstratieomgevingen, hetzelfde regime, omdat een kopie in een testomgeving een kopie is.
Dat laatste punt is het eerste om actie op te ondernemen. Personeelsdata zouden helemaal niet mogen worden gebruikt om testomgevingen te vullen. Voorbeeldrecords moeten voor het doel worden geconstrueerd, en waar een kopie van echte data onvermijdelijk is voor een specifiek onderzoek, moet die worden beheerd alsof het productie was. Alles op deze site is gegenereerd voor testen en demonstratie, en de personeelsrecords die het produceert zijn bedoeld om echte records in precies die omgevingen te vervangen, nooit om ze aan te vullen.
Volgende stappen
Zoek uit of uw systemen één vraag kunnen beantwoorden: welke kandidaatrecords van twee jaar geleden hebben geen doel meer, en wat houdt ze nog vast. Het antwoord is gewoonlijk een lijst van plekken waar niemand aan dacht, en het is een beter startpunt dan een beleidsdocument. Hoe een synthetisch carrièrerecord in de eerste plaats wordt samengesteld, wordt behandeld in carrièreprofiel testdata, en een van de gevoeligste velden in zo’n record wordt apart behandeld in salaris valuta periode. De carrièreprofieltool produceert records die bedoeld zijn voor test- en demonstratiegebruik in plaats van voor productie.