Skip to main content

Auditing at a Glance

Two logs​

LogRecords
AuditData changes — creates, updates, deletes, merges
Security auditSign-ins, permission grants, policy and masking changes, rejected outbound destinations

Separating them means a security review is not searching through routine record edits.

What immutability guarantees​

GuaranteeException
No updatesNone
No deletesThe retention purge
Gap detectionA purge produces gaps legitimately

Ordinary writes cannot modify or delete an entry — a database trigger refuses them, for every caller including administrators.

One sanctioned exception

A permissioned retention endpoint disables that trigger and deletes entries older than the retention window, from both logs. Immutability is a property of normal operation, not an absolute.

Treat that permission as among the most sensitive the platform issues: it is the only capability that can remove evidence.

A gap is not proof of tampering​

A sanctioned purge produces exactly the same signal. Read a gap as "entries are missing here", then establish whether a purge covers that window.

Masking​

ElementMasked
Old and new valuesYes, where a rule applies
Actor identityNever

Hiding who made a change would defeat the audit trail. Withhold the audit permission instead.

Audit versus history​

Answers
Audit logWho did what, and when
Temporal historyWhat a record looked like at a time

Most investigations need both: history establishes the value was wrong, the audit log establishes who made it so.

Retention​

Nothing ages out on its own

There is no retention setting and no scheduler. Entries are kept indefinitely until an operator explicitly calls the purge, which takes the window as a parameter each time it runs.

So the risk runs both ways: audit data accumulates forever unless you schedule the purge yourself, and a data-minimisation obligation you believe is being met automatically is not being met at all.

Export anything you must keep before you purge. A purge cannot be undone from within the platform.

Next​