Overzicht
Een audittrail beantwoordt de vraag die niemand graag stelt: wat is er gebeurd, wie deed het en wanneer? In financiële processen komt die vraag op bij onderzoek door een toezichthouder, intern onderzoek, geschillen, certificeringen en bij het zoeken naar de oorzaak van een datafout die pas weken of maanden later aan het licht komt.
De meeste financiële systemen houden wel een vorm van wijzigingshistorie bij, maar meestal niet genoeg. Databaselogs leggen vast dat een regel is gewijzigd, zonder de zakelijke context. Applicatielogs zijn gemaakt om fouten te zoeken, niet voor compliance. En vaak kunnen dezelfde gebruikers wier handelingen worden vastgelegd, die registratie ook aanpassen of verwijderen.
Audittrailsoftware is speciaal gemaakt om elke belangrijke handeling vast te leggen, met de context die de registratie betekenis geeft, opgeslagen op een manier die latere wijziging onmogelijk maakt, en toegankelijk voor wie haar nodig heeft, in de vorm die zij nodig heeft.
Wij bouwen audittrails voor financiële afdelingen, handelsbedrijven en andere organisaties waar volledige en juiste registraties een eis zijn van compliance, toezicht of de bedrijfsvoering.
Wat een audittrail moet vastleggen
Wie. Elke handeling hoort bij de ingelogde persoon die haar uitvoerde: gebruikers-ID, naam, rol op dat moment en de manier van inloggen. Die identiteit wordt nooit weggelaten of algemeen gemaakt.
Wat. De handeling zelf, het systeem en het object waarop ze werd uitgevoerd, en de uitkomst. Bij een wijziging de oude en nieuwe waarde van elk veld. Bij een stap in een workflow, zoals goedkeuren, afwijzen of escaleren, het besluit en de reden.
Wanneer. Het tijdstip in UTC, tot op de milliseconde. Dat telt als de volgorde van gebeurtenissen ter discussie staat en de audittrail het bewijs is.
Context. De zakelijke context die de handeling begrijpelijk maakt: de transactie, de klant of tegenpartij, de stap in de workflow, het goedkeuringsniveau en het bedrag of de hoeveelheid.
Sessie. De sessie, het IP-adres, het apparaat waar dat bekend is, en een verzoeknummer dat de registratie koppelt aan de applicatielogs.
Integriteit en bescherming tegen manipulatie
Eén keer schrijven. Een registratie wordt één keer geschreven en nooit gewijzigd of verwijderd. De opslag dwingt dat af: er is alleen toevoegen, geen aanpassen.
Cryptografische keten. Registraties zijn aan elkaar gekoppeld met hashes: elke registratie bevat een hash van de eigen inhoud en van de vorige registratie. Wie één registratie wijzigt, breekt de keten, en dat valt direct op.
Opslag buiten het systeem. Voor de hoogste zekerheid gaan registraties naar opslag die volledig gescheiden is van de systemen die worden gecontroleerd.
Functiescheiding. Gebruikers wier handelingen worden vastgelegd, hebben geen schrijfrechten op de opslag van de audittrail.
Bewaren en compliance
Bewaartermijnen. Termijnen worden per soort registratie ingesteld. De fiscale bewaarplicht in Nederland is zeven jaar (art. 52 AWR), voor gegevens over onroerende zaken tien jaar. Het systeem voorkomt verwijdering binnen de termijn en signaleert registraties waarvan de termijn afloopt.
Regels en kaders. Werkt u onder kaders zoals MiFID II, DORA (van toepassing sinds 17 januari 2025), SOX, de AVG of ISAE 3402, dan ontwerpen we de audittrail rond de eisen die die kaders aan registraties stellen.
Bewijs leveren. Moet een registratie als bewijs dienen, voor een toezichthouder, accountant of rechter, dan exporteert het systeem haar in een vorm die daarvoor geschikt is.
Toegang en zoeken
Snel zoeken. Registraties zijn doorzoekbaar op wat compliance en de praktijk het meest vragen: persoon, soort handeling, object, periode, stap in de workflow en bedrag.
Over systemen heen. Een financieel proces loopt door meerdere systemen. Om de goedkeuring, de transactie en de bijgewerkte positie aan elkaar te koppelen via één transactiereferentie, is één centrale audittrail nodig of een laag die registraties uit verschillende systemen verbindt.
Toegang per rol. Ook de audittrail zelf is afgeschermd: niet iedereen hoeft alles te zien. De toegang is net zo zorgvuldig ingericht als die tot de gegevens zelf.
Koppelingen
Financiële systemen. Exact Online, AFAS en Twinfield: transacties, goedkeuringen en wijzigingen in de inrichting, vastgelegd via de API.
Handelssystemen. Orders, uitvoering, wijzigingen en annuleringen, met het detail per transactie dat MiFID II en vergelijkbare kaders vragen.
ERP. Goedkeuring van inkooporders, ontvangstbevestigingen, factuurverwerking en het vrijgeven van betalingen, met de context van de workflow.
Identiteit en toegang. Inloggen, wijzigingen in rechten, roltoewijzingen en toegangsreviews uit Auth0 en Active Directory.
Gebruikte technologieën
- Rust en C# / ASP.NET Core: het verwerken van grote aantallen events, de cryptografische keten en het opsporen van manipulatie, en koppelingen met financiële pakketten
- React / Next.js met TypeScript: het zoeken in de audittrail, het compliancedashboard en het exporteren van bewijs
- SQL (PostgreSQL, MySQL) en Redis: PostgreSQL met alleen-toevoegen, partitionering per periode en snelle indexen, plus een buffer voor events
- REST en webhooks: het verzamelen van events uit gekoppelde systemen
- AWS S3 of andere objectopslag: een archief dat maar één keer wordt beschreven, voor langdurig bewaren met controle op integriteit
- Auth0 en Active Directory: events over inloggen en rechten
- Exact Online, AFAS en Twinfield: events uit de financiële systemen
Wanneer het loont
De meeste organisaties leggen wel iets vast. De vraag is of dat genoeg is voor de verplichtingen waaronder ze werken. De gaten zijn meestal goed te herkennen: registraties die bestaan maar niet snel genoeg te doorzoeken zijn, registraties die de gecontroleerde mensen zelf kunnen aanpassen, en data verspreid over systemen zonder manier om gebeurtenissen aan elkaar te koppelen.
Veelgestelde vragen
Wat legt een audittrail vast?
Wie een wijziging deed, wanneer, vanaf waar, de oude en nieuwe waarde en, waar nodig, de reden. Ook het inzien van gevoelige gegevens kan worden gelogd.
Hoe maken jullie het manipulatiebestendig?
Regels worden alleen toegevoegd en met hashes aan elkaar gekoppeld, zodat een gewijzigde of verwijderde regel opvalt. De opslag kan los staan van de applicatie die wordt gelogd.
Kan het aan een bestaand systeem worden toegevoegd?
Meestal wel, via databasetriggers, change data capture of logging in de applicatie. Wij kiezen de methode die bij uw systeem past.
Hoe lang worden gegevens bewaard?
De bewaartermijn volgt uw wettelijke en interne eisen, zoals de fiscale bewaarplicht van zeven jaar, en persoonsgegevens worden behandeld volgens de AVG.
Wie is eigenaar van de code?
Het eigendom van de broncode wordt in het contract vastgelegd, en de code kan volledig van u zijn, inclusief documentatie en tests.
Zie ook controller tooling, afstemmingssoftware en datastrategie.
Het dossier dat de organisatie beschermt
Een audittrail merkt u in het dagelijkse werk niet op, maar is onmisbaar zodra er vragen komen van een accountant, een toezichthouder of uw eigen directie. Vanaf het begin ingebouwd beantwoordt het die vragen met bewijs in plaats van reconstructie. Vertel ons welke systemen u wilt laten vastleggen.