Audit trail: wie deed wat, wanneer, en waarom je het antwoord kunt vertrouwen
Hoe append-only event logs, RLS-protected mutation records en de activity log samen bewijs vormen dat de auditor aanvaardt.
Een audit trail die aangepast kan worden, is geen audit trail. Het is een werkdocument. De audit-infrastructuur van het platform is bewust zo gebouwd dat de trail niet stilletjes herschreven kan worden — en dat het operationele team dat kan bewijzen.
Append-only eventtabellen
Meerdere tabellen zijn ontworpen als append-only: escrow_events, audit_events, settlement_events en nog een paar. Databasetriggers blokkeren UPDATE en DELETE op deze tabellen. Nieuwe rijen kunnen worden ingevoegd (een correctie-event met verwijzing naar het origineel), maar de originele records blijven staan. Elk event draagt een timestamp, actor (user_id) en relevante context.
Activity log
De pagina /admin/activity is de platformbrede eventweergave. Ze toont gebruikersacties over modules heen: bedrijfswijzigingen, contractbeëindigingen, rolwijzigingen, settings-updates. Filterbaar op gebruiker, actietype en periode. Gebruikt voor de vraag “wie wijzigde dit dinsdag om 16u?” die tijdens incidentreviews altijd opduikt.
RLS-bescherming
Row-Level Security op de eventtabellen zorgt dat zelfs een SQL-level read niet buiten tenantgrenzen komt — een tenant ziet alleen eigen auditrijen. Platform admins (geverifieerd via getAdminScope() met de platformlaag) kunnen tenantoverschrijdend kijken voor cross-tenant vragen, maar die toegang wordt zelf gelogd.
Geschiedenis per entiteit
De meeste entiteiten tonen hun eigen geschiedenis op de detailpagina: een company toont wijzigingen aan kernvelden, een asset toont statustransities en gradewijzigingen, een contract toont amendments. De history view is de per-entiteit slice van de audit trail, geformatteerd voor mensen in plaats van machines.
Wat de auditor controleert
De audit trail bewijst: integriteit (records zijn niet aangepast), auteurschap (de genoemde gebruiker voerde de actie echt uit, met geverifieerde login), chronologie (timestamps komen van de server, niet van de client) en volledigheid (het event voor een actie bestaat op de juiste plaats). Als die vier kloppen, gaat de audit door naar het volgende punt.