Het kan aan mij liggen, maar de laatste tijd is oud-burgemeester van Weert Jos Heijmans (D66) steeds in het nieuws. Een van de onderwerpen in de interviews dat elke keer terugkomt is het feit dat de burgemeester zijn e-mails heeft gewist. Volgens eigen zeggen in de BB van 4 december 2020 deed hij dat elk kwartaal. 'Je krijgt als burgemeester iedere maand duizenden berichten. ' De regionale kranten zouden hebben bericht dat ondanks ruim 9.000 gewiste mails Jos Heijmans niets te verbergen zou hebben. 

In juni 2020 speelde de zaak voor de rechtbank. Jos Heijmans had een kort geding aangespannen omdat hij niet wilde dat e-mails van hem in handen kwamen van de gemeente Weert. De rechtbank heeft de vorderingen vanwege formele redenen afgewezen. Hij zou naar bestuursrechter moeten zijn gegaan en niet naar de civiele rechter. Heijmans vreesde dat bestanden in verkeerde handen zouden terechtgekomen, wat gevolgen zou kunnen hebben voor de veiligheid van hem en zijn gezin. Maar de rechtbank ziet „geen concrete aanwijzingen” dat veiligheidsrisico’s toenemen als de e-mails door de gemeente worden bewaard. Deze argumenten doen denken aan de affaire rondom  e-mails van Hillary Clinton in 2016.In haar tijd als minister van Buitenlandse Zaken (2009-2013) gebruikte Clinton een privéserver om zakelijke e-mails te versturen en niet die van het departement. Daar werd de FBI!! voor ingeschakeld. 

BB bericht dat de gemeente Weert de bewaartermijn standaard Back-up van de werkomgeving heeft verlengd in verband met het integriteitsonderzoek. 

Een lange inleiding om te vragen, wat is de standaard bewaartermijn van de Back-up?  Vaak wel lang vermoed ik wanneer je naar de affaire van het bonnetje van Teeven kijkt. 

Weergaven: 1341

Hierop reageren

Berichten in deze discussie

Ik herken de vraag en ben daar ook weleens naar opzoek geweest. Dat valt tegen. Volgens mij is voor backups tussen de 3 en 6 maanden gebruikelijk met soms uitloop naar een jaar.

Jouw laatste zin triggert mij. Volgens mij is het doel van een backup vooral om iets terug te kunnen zetten als er iets mis is gegaan vanuit een vaak technisch perspectief (technische storingen, hacks, etc). Volgens mij worden backups niet gezien als een middel om een archief te herstellen door menselijk handelen, dit zou je ook m.i. niet via een backup moeten organiseren, maar met de juiste inrichting, autorisaties en functionlaiteit.

Dank voor je antwoord. Wat e-mailservers betreft heb ik ook wel eens een termijn vernomen van zeven jaar. Wat wel wezenlijk is bij vernietiging dat je ook de bestanden op de Back-up verwijdert/ ontoegankelijk maakt. Anders krijg je zo'n Teevenverhaal. MY-LEX voert dat sinds kort ook zo uit, begreep ik van deze firma. 

Als je kijkt naar de bonnetjes-affaire van Teeven zou je kunnen redeneren dat een bewaartermijn van 7 jaar ivm eventuele financiële gevolgen voldoende zou moeten zijn. Ik meen dat bij onze gemeente de mails van wethouders ook  7 jaar worden bewaard. Maar het gaat hier feitelijk om een back-up van het systeem en dat omvat meer dan alleen mails.

In de praktijk kan je er volgens mij geen mail meer op terugvinden vermoed ik. 

Back-ups zijn wel een interessant gegeven. Ik kan mij zo bedenken dat AVG-technisch je de back-ups moet verwijderen als ze hun doel verloren hebben. Je zou dan kunnen zeggen dat je een back-up verwijderen moet als je een nieuwe gemaakt hebt. Of als je een serie wilt aanhouden dan kun je ook 10 back-ups behouden en de 11-de en oudste gooi je dan weg.

De vraag is of back-ups onder de archiefwet vallen of niet? Als ze onder de AW vallen moeten ze ook opgenomen zijn/worden in de selectielijsten. En daar staan ze geloof ik niet in, als ik mij niet vergis.

Groet Jan-Jaap

Jan-Jaap, klopt staat er niet, sinds dit jaar wel logging: http://www.breednetwerk.nl/forum/topics/logginggegevens-en-de-gemee...

In de handreiking Back-up en recovery van de IBD staat op p.9 een bewaartermijn van 1 jaar voor de kwartaal back-up: https://www.informatiebeveiligingsdienst.nl/product/back-up-en-reco...  

Ze hebben het vervolgens over back-ups van digitaal archief, die een andere bewaartermijn hebben. Volgens mij bedoelen ze met digitaal archief scans die in het kader van vervanging zijn gemaakt. Waarom die een andere bewaartermijn hebben dan born digital archief is mij niet helemaal duidelijk.

Dank nuttige aanvulling Caroline. Eerder heb ik over de afwijkende termijnen logging ook overleg gevoerd en daarom is die aangepast in de selectielijst. Op de werkvloer ontstond verschil van mening tussen ICT en informatievoorziening. Ik zal dit punt ook weer eens aan gaan kaarten. 

Backups en logging zijn bedoeld als hulpmiddelen bij ongelukken/rampen. Het nut ervan en daarmee de procestermijn is beperkt tot de volgende backup voor backups en de maximale termijn dat de data nog geaccepteerd worden als bewijs voor logbestanden.

Het wordt complexer als de backup niet bestaat uit een full-backup maar incremental is, zodat er meer bestanden nodig zijn om de situatie van moment X te herstellen na een ongeluk/ramp. Van ouds her is er bij systeembeheerders ook sprake van grootvader-vader-zoon-principes voor volledige backups. "Veiligheid voor alles..." Er is m.i. geen valide argument meer voor dit principe. Online storage, offline storage en cloud-opslag zijn ook vraagstukken die de complexiteit verhogen. Niet in de zin van bewaartermijn, maar wel in de zin van "wat staat waar ?"

De AVG maakt het nog complexer omdat persoonsgegevens geanonimiseerd zouden moeten worden of vernietigd moeten worden zodra ze niet meer nodig zijn.

Helaas zijn deze bestanden ontstaan in het reguliere werk van gemeenten en dus zijn het formeel archiefbescheiden. De Archiefwet voorziet m.i. hiervoor niet in een passende bewaarstrategie. M.i. zou er sprake moeten zijn van beperkte toegang tot de bewaarde bestanden, zoals dat in de praktijk altijd wel het geval is. Een gedeeltelijk vernietigen betekent immers dat de integriteit van de bestanden aangetast wordt en daarmee is het niet meer geschikt voor het doel: een restore als dat nodig is.

Helaas blijkt uit jurisprudentie dat de rechtspraak zich nog geen raad weet met dit soort bestanden. Al het werk van zorgvuldig vernietigen door DIV of ingebed in de werkprocessen m.m.v. DIV is zinloos als een rechter een backp van jaren geleden beveelt te restoren. DIV heeft immers geen gedeeltelijke vernietiging in die bestanden kunnen uitvoeren. Zorg dus dat een dergelijke backup er niet meer is, met als argument dat de procestermijn is afgelopen vanaf het moment dat er een nieuwe backup is. De bewaartermijn mag van mij dan op 0 of 1 dag staan.

Het probleem van mailboxen is dat dit op zich natuurlijk slechts een vergaarbak is van losse e-mails. Die e-mails zijn archiefwaardig. De mailbox m.i. niet. De fysieke brievenbus of de postzak bewaren we toch ook niet ? E-mail moet dus m.i. worden gearchiveerd, niet de mailbox.

De nieuwe Archiefwet (2023 ?) blijft wat mij betreft voor deze problematiek nog steeds onvoldoende.

Een lang antwoord waarbij conflicten tussen wetten de basis zijn en die worden niet opgelost met een nieuwe selectielijst of de overstap van de BIG op de BIO.

Maar wel een goed antwoord, dank hiervoor. 

Mbt je laatste vraag: er is niet zoiets als DE standaard termijn van DE backup. Backup schema's kunnen op verschillende manieren geconfigureerd (zie ook antwoord Jules). Er kunnen backups per dag(deel) zijn, per week, kwartaal en jaar. Ook de bewaartijd daarvan kan ingesteld. Aangezien backups doorgaans meer gebonden zijn aan opslag en applicaties is er niet zoiets als een proces-, laat staan zaakgebonden bewaartermijn.

Niet alleen rond backups, ook rond auditlogs doet het idee onder archivarissen wel eens ronde dat deze op dezelfde wijze vernietigd zouden kunnen worden (omdat een norm of wet dat zegt) als zaakgebonden informatie. Maar dat zal nooit zo werken. Backups zijn niet voor archivering maar voor restore bij calamiteiten of ongelukken met (grootschalige) verwijderring. Cloudsystemen hebben tot een beperkter termijn zelf dit soort restore mogelijkheden (vgl Office 365).

Soms worden (offline) backups niet hergebruikt, of is dit in het verleden zo aangepakt, bv toen er nog geen cloud backup bestond en blijkt er na vele jaren nog iets bijzonders te kunnen worden terug gevonden. Dat is leuk, maar daar zijn ze niet voor bedoeld. Exchange beschikt over voldoende mogelijkheden om (desnoods specifieke sleutelfiguren-)mailboxen te beschermen tegen verwijdering van e-mail berichten. Dat had (zelfs in Weert, toch?) al lang kunnen gebeuren. Je hoeft dan niet naderhand paniekerig ineens backups te gaan bewaren of raadplegen. Omdat ze er niet voor zijn bedoeld is het een dure oplossing om informatie die bewaard had moeten blijven boven water te halen.

Ook zouden archivarissen, DIV en inspectie zich vaker tegen dit traditionele domein van ICT beheer mogen aan bemoeien. Het is van begin af aan niet correct geweest dat technisch beheerders (toen nog) de omvang van mailboxen bepaalden. En tegenwoordig nog steeds daar de vrijheden van gebruikers lijken te bepalen. We weten al vele jaren dat e-mails niet in het DMS komen en dat de mailboxen zelf beschermd zullen moeten worden. Juist van die rollen die deel uitmaken van bestuur en besluitvorming. Handmatige registratie is al te lang onbeheersbaar gebleken, alle goedbedoelde e-mailprotocollen en 'opvoedingspogingen' ten spijt.

Dat de betreffende burgemeester zelf periodiek zijn mailbox leegde heeft uiteindelijk ook weinig met techniek en alles met governance en integriteit te maken. En privé hobby's horen per definitie in de privé mailbox.

@Eric:

"We weten al vele jaren dat e-mails niet in het DMS komen en dat de mailboxen zelf beschermd zullen moeten worden." is wat mij betreft onjuist: regel het beheer van de e-mail in plaats van buiten de toestemming van de betrokkene om te pogen archiefwaardige informatie veilig te stellen. Functionarissen zijn net mensen: ze zullen hun communicatie via andere kanalen gaan doen als ze niet meer vrij over hun eigen informatie (in dit geval in hun mailbox) mogen beschikken.

Antwoorden op discussie

RSS

© 2024   Gemaakt door Marco Klerks.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden