Log every action that changes who can do what, reads sensitive data in bulk, or alters security settings: role and permission changes, admin logins, impersonation, data export, configuration edits and break glass account use. Record who, what, when, from where and the before and after values.
Why this list matters most
Ordinary user events tell you what customers did. Privileged events tell you whether the system itself was changed. If an attacker gains admin rights, the first useful evidence is a trail of what they did with them.
The OWASP Logging Cheat Sheet places these under higher risk functionality: user and privilege administration, admin actions, use of default, shared or break glass accounts, access to sensitive data, encryption and key activities, and data import and export. It also lists configuration changes among system events.
The checklist
| Action | Record |
|---|---|
| Role or permission granted or removed | Actor, target user, old role, new role |
| Admin or support login | Actor, method, MFA result, source |
| Impersonation or act as user | Actor, target user, start, end, reason |
| User created, disabled or deleted | Actor, target, reason if given |
| API key or token created or revoked | Actor, scope, expiry, key ID (never the secret) |
| Security setting changed | Setting name, old value, new value |
| Bulk data export or import | Actor, dataset, row count, destination |
| Access to sensitive records by staff | Actor, record type, record ID, ticket reference |
| Break glass account use | Actor, start, end, approver |
| Encryption key action | Key ID, action, actor |
Store key IDs, not key material. The same goes for tokens.
Design rules
Write these as a separate audit stream. Different retention, different access, different alerting. The OWASP A09 guidance suggests an audit trail for high value transactions with integrity controls, such as append only database tables, so records cannot be altered or deleted unnoticed.
Make the audit write part of the action. If the role change commits but the audit entry fails, you have an unrecorded change. Either write both in one transaction or fail the action.
Record before and after values where it is safe to do so. Knowing that a role changed is useful. Knowing it moved from viewer to owner is evidence.
Never allow the admin user to edit or delete the audit stream through the same interface they administer.
Alerts worth setting
- Any change that adds the highest privilege role.
- Admin actions outside normal hours for that person or region.
- Impersonation without a linked support ticket.
- Any use of a break glass account.
- A sudden large export.
Keep alerts few and each tied to a named person who responds. For protecting the stream itself, see protecting logs from tampering.
Quick check
Do support staff actions need logging too?
Yes. Staff access to customer data and impersonation are privileged actions and are often the first thing a customer or auditor asks about.
Should the audit log live in the main database?
It can, in append only tables with restricted write rights, but many teams also ship a copy to separate storage so a database compromise does not erase the trail.
Safeguard's policies, gates and agent identity controls record decisions the same way, and compliance and evidence automation collects proof for audits. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
