Audit · Plans and data
Data and privacy
Audit keeps what your app sends in each event, and nothing else: ids for people and accounts, never their names or email addresses.
What Audit keeps
Loading what it keeps…
Before it leaves your server
The SDK sends the event as you recorded it: the action, the actor, the target, the subject, the account, the request's id, the reason and the context. Nothing about the request itself goes with it: no IP address, no headers, no user agent. Until Audit has an event, it is in the outbox in your own database.
- An email address as an id, or anywhere in the context, throws in your app and is never written.
- An email address typed into a reason is replaced with
[e-mail removed]before the event is written to the outbox. - Audit refuses an event that still has an email address anywhere in it.
The SDK can't tell a name or a phone number from other text. Keep the context to ids and short facts, and ask your operators not to type personal data into a reason.
Who can read it
The project's people with Triage or Admin in Audit read its events and access reports. People with Viewer see counts and the Integrity page, never anyone's actions. Every read is written down, and the project's admins see who read what on Who read it.
Erasing a person's data
An audit log only ever grows: no one can change or delete one event without the chain showing it. So Audit has no way to erase one person's events. They go with everyone else's when they are older than the months the project keeps, a whole day at a time.
What Audit holds about a person is your id for them. When you erase the person in your app, the events keep an id that no longer points to anyone, and the link to your console leads nowhere.
Keep personal data out of the context