Audit trail: Wie deed wat, wanneer, en waarom je het antwoord kunt vertrouwen

Een audit trail die aangepast kan worden, is geen audit trail. Het is een werkdocument met een ernstig hoedje. ReVend OS is gebouwd zodat kritieke activiteit later reconstrueerbaar blijft: wie handelde, wat veranderde, welk record geraakt werd en of de trail zelf nog klopt.

Activity events

Server-side mutaties, gevoelige reads, documenttoegang, evidence-downloads, cronuitkomsten, webhookresultaten, admin overrides en security events schrijven activity rows. Ze bevatten actor, tenant, actie, outcome, sensitivity en begrensde metadata. Ruwe secrets, passwords, signed URLs en betaalgegevens horen daar niet thuis. De sanitizer helpt, maar de echte strategie is gevaarlijke dingen niet in de doos stoppen.

Tamper-evident chain

Audit events worden per tenant geketend met een SHA-256 hash, vertrekkend vanaf een GENESIS-rij. Elke nieuwe event bevat de vorige head, zodat een stille wijziging de keten breekt en een verifieerroutine erdoorheen kan lopen. Dat verandert de database niet vanzelf in een rechtbank, maar het geeft het platform een manier om te detecteren dat geschiedenis niet meer met zichzelf overeenkomt. Auditors houden van geschiedenis die oogcontact kan maken.

De reviewpagina leest als een zin

/general/activity is de menselijke view, en die begint met mensentaal: elke rij opent met een gewone samenvatting van wat er gebeurde, niet met een machinestatus. Dezelfde samenvatting is de eerste regel in het detailpaneel, in de CSV-export en in de kleine panelen met recente activiteit op andere schermen. Bron, correlatie en extra metadata blijven beschikbaar waar ze betekenis toevoegen; lege metadata en dubbel getoonde resource-ID’s zijn geen productdetail.

Filters houden het antwoord bruikbaar in plaats van het scherm in confetti te veranderen: zoeken, domain, actie, outcome, sensitivity, visibility, brontabel, datumbereik, en organisatie waar platformscope dat toelaat. De CSV-export vraagt eerst — de huidige pagina, of alles wat aan je filters voldoet — en dat laatste vereist een datumbereik, zodat een export niet per ongeluk naar de volledige geschiedenis grijpt.

Platformmedewerkers lezen hem over tenants heen en hebben daarnaast een activiteitenpagina aan admin-kant. Tenant-admins zien hun eigen tenant, gevoelige rijen inbegrepen, maar nooit platform-only rijen. Gewone tenantgebruikers zien het menu-item en geen data: de pagina vertelt hun dat de activity log voor tenant-admins is, wat beter is dan een 404 die doet alsof de pagina niet bestaat.

Kijken is niet doen

Een gewone pagina-load is geen zakelijke handeling. Een route openen, verversen, zoeken, sorteren, pagineren, van tab wisselen, een modal openen, een filter wijzigen — niets daarvan schrijft activiteit, want niets daarvan verandert data, status, rechten, bewijs, geld, publicatie, een supportdossier, een securityhouding of integratiegedrag. Een trail die het kijken logt, begraaft de trail die het doen logt.

Echt gevoelige reads liggen anders: cross-tenant platformcontext, documenttoegang, supportbijlagen en bid history die via de API opgehaald wordt, worden geregistreerd als gevoelige reads — ontdubbeld, of getoond via een evidence-lens — en niet als generieke “pagina bekeken”-ruis.

Groeperen is presentatie, geen verwijdering

Opeenvolgende systeem- en runtime-events met weinig informatie die scope, betekenis, outcome en resource delen, mogen in de reviewlaag als één rij verschijnen, met een teller en een tijdsbereik. De losse rijen blijven in het detailpaneel staan, en de CSV-export schrijft ze nog altijd stuk voor stuk weg. Menselijke zakelijke handelingen worden nooit samengevouwen, hoe hard ze ook op elkaar lijken. Twee mensen die twee keer hetzelfde doen, is een feit, geen duplicaat.

Wat de auditor checkt

De trail bewijst integriteit, authorship, chronologie en volledigheid. Als een record bewoog, moet ReVend tonen wie het bewoog, wanneer, waarom het mocht en welk bewijs meeging. Als het antwoord “waarschijnlijk Dave” is, loopt de audit al slecht.