Platform capability · Audit
An audit trail that can only be added to, where tampering shows
A record of events kept as evidence for compliance. New, changed and deleted records, settings changes, sign-in events and permission changes are written to a separate ledger for each customer, and the ledger can only be added to. Each event carries a SHA-256 hash of the event before it, so an inserted or deleted event can be detected. Notification rules alert on chosen patterns. Events name people by ID, which supports anonymization without rewriting the chain.
Each audit event includes the SHA-256 hash of the event before it. Database rules block updates to recorded events, and events are deleted only by the controlled erasure and retention processes. The verification endpoint checks the chain for each customer and app, and reports a broken link. When long-term archiving is turned on, the archive keeps the sequence and hash fields, so auditors can verify exported records without access to the database.
Audit events identify who acted by ID, with no name or email. Names are looked up when an event is displayed, and show as "[deleted]" once a user has been erased. When a person is erased, the audit events about that person are deleted. One erasure record is then added to each affected chain. It says which sequence ranges were removed and how many events, and it does not name the person. The chain still verifies, and an auditor can account for every gap. Copies already held in archived retention windows, or in exports already handed out, are not reached.
Notification rules watch audit events as they arrive. A rule can alert on repeated failed sign-ins by the same person, on an unexpected role grant, or on a problem in the audit chain itself. Rules are set for each customer and each event type.
A solution architect will demo the live service against your domain model.