Stel dat iemand over een jaar naar uw logboek kijkt en één vraag stelt: hoe weet u dat hier niets uit verdwenen is?
Niet: is er iets veranderd. Niet: staat het in de documentatie. Maar: hoe weet u dat er aan het eind niets is weggeknipt.
Op die vraag hebben de meeste tools geen antwoord. Wij wel, sinds afgelopen zomer — maar dat antwoord bestaat voor een deel uit “in vier situaties zien we het niet”. Die vier staan hieronder.
Waarom we dit opschrijven
Een auditspoor is onze centrale belofte. Een belofte die u niet zelf kunt narekenen, is een slogan.
Dus in plaats van hier op te schrijven wat het tegenhoudt — dat doen alle anderen ook — schrijven we op wat het niet tegenhoudt. Alles hieronder staat ook in het beveiligingsdocument bij onze broncode. Het staat hier omdat een beveiligingsdocument dat niemand leest geen openheid is.
Wat de ketting wél ziet
Elke regel in het logboek draagt een berekening over de vorige regel plus wat er op deze regel gebeurd is. De controle loopt vanaf regel nul en rekent alles opnieuw uit.
Daarmee worden drie dingen zichtbaar.
Inhoud aangepast. De herberekening klopt niet meer.
Regels omgewisseld. De volgorde loopt strikt op en breekt.
Een regel er middenin bij of tussenuit. De koppeling naar de vorige regel valt weg.
Daarbovenop mag de software zelf op de logboektabel alleen toevoegen en lezen. Wijzigen en verwijderen zijn niet toegestaan.
Dat is wat een goed logboek hoort te doen. Nu de rest.
Gat 1: het einde eraf knippen
De controle verankert alleen de eerste regel aan een vast startpunt en loopt dan vooruit. Ze controleert niet of de keten bij regel één begint, en niet of het eind overeenkomt met een verwacht aantal regels.
Denk aan een papieren logboek waarin iemand de laatste bladzijden eruit scheurt. Wat overblijft is doorlopend genummerd, netjes ondertekend en volledig consistent. Precies dat gebeurt hier: verwijder de laatste regels en de controle meldt gewoon dat alles in orde is.
Daar komt bij dat de koppelberekening geen geheim gebruikt. Wie de hele database kan beschrijven, kan de hele keten opnieuw uitrekenen.
De grens exact: de ketting houdt stand tegen iedereen die niet in de database kan schrijven, en tegen aanpassen, omwisselen en er middenin iets uithalen door iemand die dat wél kan. Niet tegen afknippen aan het einde.
Gat 2: het logboek lezen laat geen spoor na
Het logboek raadplegen levert zelf geen regel op. Wie erin heeft gekeken en wanneer, staat er niet in.
En er bestaat geen draaiboek voor wie er gewaarschuwd wordt als de controle faalt, of als iemand tien keer achter elkaar wordt geweigerd. Detectie hebben we. Alarmering niet.
Dat is vandaag begrensd doordat dit onderdeel in één proces draait, zonder netwerkkant en zonder scheiding tussen beheerder en gebruiker om tegen af te zetten. Bij de desktopversie hoort het er wel te zijn.
Gat 3: de velden waarop u zoekt worden niet nagerekend
De controle rekent elke regel na op basis van het verzegelde deel ervan. Maar de losse velden waarop u zoekt en die u terugkrijgt — tijdstip, soort handeling, wie het deed, documentnaam, dossierkenmerk — worden niet vergeleken met hun kopie binnen dat verzegelde deel. En als een documentnaam leeg is, bestaat die kopie helemaal niet.
Iemand met schrijfrechten kan dus een zoekveld aanpassen. Uw zoekopdracht geeft de gewijzigde waarde terug, terwijl de controle gewoon slaagt.
De regel die daaruit volgt en die wij zelf aanhouden: het verzegelde deel is leidend, de zoekvelden zijn hulpmiddelen om op te filteren. Dit repareren verandert de controle zelf, en dat doen we niet tussendoor.
Gat 4: twee velden staan leesbaar op schijf, en wissen raakt ze niet
Dit is de zwaarste, en het is de directe buurman van gat 3: dezelfde twee velden, dezelfde oorzaak, namelijk dat ze buiten het verzegelde deel liggen.
De documentnaam en het dossierkenmerk worden op elke regel onversleuteld weggeschreven. In de sectoren waar dit product voor bedoeld is, dragen ze allebei routinematig herleidbare gegevens. Een documentnaam is vaak een persoonsnaam of een zaaknummer. Een dossierkenmerk is per definitie een cliëntaanduiding.
Het gevolg, onomwonden: een wisverzoek raakt deze twee velden niet. Wie de handeling verrichtte, wordt wél afgeschermd via een sleutel per betrokkene, maar deze twee vallen daar niet onder. Die sleutel vernietigen doet niets met leesbare tekst. Een gewiste betrokkene die in een documentnaam voorkomt, blijft herleidbaar.
En er is geen reparatie achteraf die de ketting heel laat. Een al geschreven regel herschrijven of zwartlakken breekt zowel de ketting als het zegel eroverheen. Voor regels die al geschreven zijn is dit dus blijvend. Dat is een gevolg van het ontwerp, geen vergeten detail — maar het is er wel een dat u moet weten voordat u begint.
De velden weglaten kan niet: het zijn de velden waarop het logboek doorzoekbaar is, ze dragen de reconstructie van wat er gebeurd is, en het dossierkenmerk is de basis onder de export per dossier.
Wat u er als beheerder aan doet: behandel beide velden als persoonsgegevens die op schijf staan, en versleutel de opslag. Noch de ketting, noch de software zal ze voor u afschermen.
Dit artikel is algemene informatie en geen juridisch advies. Voor uw eigen situatie: leg het voor aan een jurist of uw functionaris gegevensbescherming.
Wat we aan gat 1 gedaan hebben, en waar dat ophoudt
Sinds juli 2026 kan Provenize periodiek een ondertekend zegel over het logboek zetten. Dat zegel bevat een vingerafdruk over alle regels tot dat moment, het aantal regels, het tijdstip, en een handtekening.
Daarmee wordt afknippen zichtbaar: het aantal regels klopt niet meer met wat er verzegeld is. Maar alleen onder vier voorwaarden, en we noemen dit nooit onvervalsbaar zonder ze alle vier erbij te zetten.
Het zegel moet buiten bereik liggen van wie in de database kan schrijven. Het zegel staat namelijk zelf in diezelfde database. Draait u alleen lokaal, dan kan iemand met schrijfrechten het dekkende zegel weggooien. De controle valt dan terug op een ouder zegel dat nog steeds klopt, en meldt dat alles in orde is — voor een logboek waarvan nieuwere, wél verzegelde regels vernietigd zijn. Het zegel elders publiceren is de enige verdediging. Alleen lokaal werken laat dit per constructie open.
De ondertekensleutel moet niet gestolen zijn. Die sleutel is een bestand dat alleen door het besturingssysteem wordt beschermd. Op Windows leunt dat op de rechten van het bestand, en die zijn daar minder streng af te dwingen dan op Linux. Het sleutelbestand zelf versleutelen staat op de planning, het is er nog niet.
Er moet een sleutel ingesteld zijn geweest toen het zegel werd gezet. Zo niet, dan is het zegel niet ondertekend en stelt het niets voor. De controle meldt dat apart.
De regels moeten vóór het laatste zegel liggen. Alles wat daarna is toegevoegd, valt er buiten. Knipt iemand terug tot precies het laatste zegel, dan klopt het weer. Hoe vaak u verzegelt, is dus uw eigen risicovenster. Wie nooit verzegelt, heeft er niets aan.
Het detail waar ik het langst over heb nagedacht
De voor de hand liggende oplossing is om het zetten van een zegel zelf als regel in het logboek te schrijven. Dan zie je later immers dat er verzegeld is.
Ik heb dat bewust niet gedaan, want het werkt niet.
Zo’n regel komt namelijk net ná het punt waar het zegel eindigt. Dat is precies het gebied dat iemand weghaalt die de staart afknipt. De regel staat dan naast de regels die hij zou moeten bewijzen, en verdwijnt met ze mee. Het is de aantekening “hier eindigt het logboek” op de laatste bladzijde: wie die bladzijden eruit scheurt, scheurt de aantekening mee.
Zegels aan elkaar koppelen lost het niet op, en een teller in de database ook niet. Alles ligt binnen hetzelfde schrijfbereik.
Vijf antwoorden, geen twee
De controle geeft geen “goed” of “fout” terug, maar vijf verschillende uitkomsten: het klopt, het klopt niet, het zegel is ongeldig, het zegel is niet ondertekend, of er is helemaal geen zegel.
Dat is geen muggenzifterij. Een zegel dat er niet is en een zegel dat er wel is maar nergens mee ondertekend, mogen nooit dezelfde uitkomst delen met “alles is nagerekend en het klopt”. Een controletool die afwezigheid samenvouwt met goedkeuring, liegt tegen zijn gebruiker.
Om dezelfde reden noemen we gat 1 niet gesloten. We noemen het voorwaardelijk gesloten. Het mechanisme is er; wat overblijft is een plicht van u — regelmatig verzegelen, en het zegel buiten bereik bewaren.
Zes vragen voor uw leverancier
Deze vragen werken bij ons en bij iedereen. De manier waarop ze beantwoord worden, zegt vaak meer dan het antwoord.
- Wat ziet uw controle níét? Als het antwoord “alles” is, bent u klaar met het gesprek.
- Merkt uw controle het als de laatste regels zijn weggeknipt, of alleen als er middenin iets is veranderd?
- Ligt het ijkpunt waartegen u controleert buiten het bereik van uw eigen beheerders?
- Worden de velden waarop ik zoek ook nagerekend, of alleen de verzegelde inhoud?
- Welke velden in dat logboek zijn persoonsgegevens, en wat gebeurt daarmee bij een wisverzoek?
- En de belangrijkste: staat dat antwoord ergens waar ik het zelf kan nalezen?
Vraag zes is de reden dat dit stuk bestaat. Wij hebben de antwoorden opgeschreven voordat iemand erom vroeg, en u mag ons eraan houden.
Wilt u de volledige grenzen zien? Wat we wel en niet beschermen — zwart op wit, zonder marketing eromheen.
Waar wij staan
Een claim over aantoonbaarheid uit software die niemand mag inzien, is een tegenspraak. Dat is de reden dat de SDK open source is.
Maar een claim over aantoonbaarheid zónder uitgeschreven grens is net zo goed een slogan. Het getal dat telt is niet hoeveel aanvallen we tegenhouden, maar hoe precies we kunnen zeggen welke niet.
Vindt u een vijfde gat, dan horen we dat liever van u dan van iemand anders. Het meldpunt staat open.
Eerlijk erbij: de SDK is gebouwd maar nog vóór 1.0, en Provenize Desktop is nog niet uitgebracht — de release staat gepland voor eind 2026. Er draait nog niets in productie bij een klant. Het zegel uit dit stuk werkt en is getest; de verbeteringen die we noemen als “staat op de planning” bestaan nog niet. Het product is ontworpen om te ondersteunen bij naleving van uw verplichtingen. Het is geen keurmerk, geen certificaat en geen garantie; die woorden gebruiken wij bewust niet.
Wilt u meedenken voordat het af is? We zoeken een beperkt aantal kantoren en teams die het product vóór de release gebruiken en vormgeven. Dat kost niets. Wat we terugvragen is eerlijke feedback: info@provenize.ai.
Meer voor uw vakgebied: AI in cliëntdossiers (juridisch & compliance) en oude pentestrapporten doorzoeken zonder cloud.
v0.1 · september 2026 · Terug naar het blogoverzicht