Hoe bewijs je dat een bestand op een bepaalde datum al bestond?

Het is een vraag die vaker opduikt dan je denkt: kan ik bewijzen dat een bestand op een bepaalde datum bestond. Niet wanneer het voor het laatst is aangepast, niet wanneer iemand beweert dat het gemaakt is, maar objectief aantonen dat het bestand op datum X al in die vorm aanwezig was. In journalistiek, bij contracten, in intellectueel eigendom en bij digitale onderzoeken is dat verschil cruciaal. Een screenshot of een bestandsdatum in Windows volstaat zelden, omdat die datum door de gebruiker zelf te wijzigen is en niets zegt over de inhoud.

In de praktijk komt de behoefte voort uit situaties die heel herkenbaar zijn. Een journalist ontvangt een foto die volgens de bron al maanden oud is, maar de metadata is opgeschoond. Een ontwerper wil aantonen dat een CAD-tekening al bestond voordat een concurrent eenzelfde ontwerp publiceerde. Een ontwikkelaar wil vastleggen dat een broncodeversie op een specifieke dag heeft bestaan, zonder dat later kan worden beweerd dat de code achteraf is herschreven. In al die gevallen gaat het niet om een mening, maar om technisch traceerbare informatie die je kunt documenteren en later kunt herhalen.

Bestandsmetadata geeft een eerste indicatie, maar geen bewijs op zichzelf. Bij een foto vind je vaak EXIF velden zoals CreateDate, ModifyDate en camera-instellingen. Bij een PDF zie je CreationDate en ModDate in het document informatie woordenboek. Bij een DOCX of XLSX zit er core properties metadata met aangemaakt door en gewijzigd op. Bij video en audio zijn er container timestamps, encoder informatie en soms GPS. Dat zijn bruikbare aanwijzingen, maar elk van die velden kan door software worden aangepast of verloren gaan bij export, conversie of bewerking. Een JPG die is geopend en opnieuw opgeslagen mist vaak originele EXIF, een PDF die is geprint naar PDF krijgt een nieuwe CreationDate. Daarom moet je metadata altijd lezen als een technisch spoor, niet als een onweerlegbaar tijdstempel.

Wat wél robuust is, is een combinatie van een cryptografische vingerafdruk van de inhoud en onafhankelijke documentatie van het moment waarop die vingerafdruk is vastgelegd. Een hash zoals SHA-256 verandert bij de kleinste wijziging van een bestand, zelfs één bit. Als je op een bepaalde datum de hash van een bestand berekent en die hash op een betrouwbare manier vastlegt, kun je later aantonen dat het bestand in die exacte vorm op dat moment bestond. De hash bewijst niet wie het maakte, maar wel dat de inhoud identiek is aan wat je toen hebt vastgelegd. Dat is de kern van file integrity verification.

In de praktijk werk je daarom met een keten. Eerst maak je een momentopname van het bestand met volledige metadata extractie, zodat je ziet welke technische informatie er op dat moment aanwezig is. Vervolgens bereken je meerdere hashes, bijvoorbeeld SHA-256 en MD5, en noteer je die samen met de bestandsnaam, grootte en een tijdstempel uit een onafhankelijke bron. Die notitie leg je vast in een rapport of logboek dat zelf ook getimestamped wordt. Wil je extra zekerheid, dan kun je de hash publiceren via een tijdstempel dienst of een blockchain anchor, zodat het bestaan van die hash op een bepaald moment door derden kan worden gecontroleerd. Een forensisch PDF rapport dat al deze gegevens op één pagina bundelt is dan een helder, reproduceerbaar document voor audit, journalistiek of een procedure.

Dat is precies waar een platform als FilesAudit voor bedoeld is. Je uploadt een bestand en het platform extraheert technische metadata, berekent SHA-256, MD5 en CRC32 en genereert een professioneel PDF rapport met tijdstip van analyse. Dat rapport documenteert wat er technisch in het bestand staat, niet wie de eigenaar is of of het legaal is. Het is een objectieve vastlegging van de staat van het bestand op het moment van analyse, die je kunt archiveren en later opnieuw kunt verifieren door dezelfde hash te berekenen. Voor wie regelmatig bestanden moet vastleggen is de FilesAudit startpagina een praktische plek om snel een eerste analyse te doen en te zien welke metadata er beschikbaar is. Voor bulk of lokaal werk is er ook een desktop optie.

Voorbeelden helpen om het concreet te maken. Stel je bent journalist en ontvangt op 12 september een video die een incident van 3 september zou tonen. Je laadt de video op, bekijkt de container metadata en de encoder informatie, laat de hash berekenen en slaat het rapport op met datum en tijd van upload. Een week later vraagt een redacteur of de video is aangepast. Door de hash opnieuw te berekenen en te vergelijken met het rapport weet je met zekerheid of de inhoud identiek is. Een ander voorbeeld is een architect die een DWG bestand op 1 juni deelt met een opdrachtgever. Door op die dag een hash en metadata rapport te genereren kan later worden aangetoond dat het bestand op die datum al die specifieke laagstructuur en revisie informatie bevatte. Bij een auteursrechtgeschil kan zo'n vastlegging samen met communicatie logs een belangrijke technische onderbouwing vormen, zonder dat het platform zelf een juridische conclusie trekt.

Het is belangrijk om de verschillen per bestandsformaat te kennen. Bij foto’s zijn EXIF, GPS en XMP velden relevant, maar die kunnen ontbreken na compressie of bewerking. Bij PNG is er geen standaard EXIF maar wel tEXt chunks met metadata. Bij PDF’s vind je creation en modification data, maar ook informatie over het maakprogramma en soms embedded fonts. Bij DOCX bestanden zit er XML metadata over auteur en revisiegeschiedenis die bij een herschrijving kan veranderen. Bij MP4 en MOV zijn er creation time tags in de moov atom, maar die worden bij transcoderen vernieuwd. Bij ZIP archieven kun je per bestand de interne timestamps zien, maar die zijn niet cryptografisch beschermd. Een overzicht van alle ondersteunde formaten helpt om te zien waar je metadata kunt verwachten en waar je juist voorzichtig moet zijn. De blog van FilesAudit bevat ook praktische voorbeelden voor specifieke situaties.

Een veelgemaakte fout is om alleen te vertrouwen op de bestandsdatum op de schijf. Die datum is een eigenschap van het bestandssysteem en wordt aangepast bij kopiëren, verplaatsen of herstellen van een backup. Een tweede fout is te denken dat een enkele hash volstaat zonder context. Een hash bewijst identiteit, geen herkomst. Een derde valkuil is metadata na te bewerken en daarna te claimen dat het origineel is. Daarom werk je altijd met een combinatie van inhoudshash, volledige metadata dump, rapport met tijdstempel en, waar mogelijk, een onafhankelijke vastlegging van dat rapport. Bewaar het originele bestand onveranderd en maak een werk kopie voor analyse.

Kort samengevat kun je het bestaan van een bestand op een bepaalde datum niet bewijzen met één klik, maar wel technisch