Audit and retention
The audit log
Section titled “The audit log”Records covered operations: who did something, what they did, when, and what changed. The application has no interface to edit an entry or delete one by ID. Production Docker’s restricted database role adds database enforcement; database owners and hosting administrators have separate authority. Demo and native installations use an owner connection, so do not assume the same database guard.
The one way an entry leaves is the retention window below, and it is bounded so that it cannot be used as a deletion tool: an audit window may not be set shorter than 90 days, and applying it is itself recorded — the entry naming whoever ran a purge, and how much it removed, is written before the deletion and therefore survives it. Changing these settings, and running a purge by hand, both ask you to confirm who you are.
Read it at the audit log. This page is about how long to keep it and what to do about erasure.
What is not recorded yet
Section titled “What is not recorded yet”Coverage is not complete. Sign-in and sign-out, password and MFA changes, API-key lifecycle operations and some integration/configuration changes do not all produce audit entries. Coverage varies by operation and version; the log is not a complete account of access or every write. Directory actions, including guarded mailbox operations, have their own audit records in current releases. Check the installed version and the operation’s coverage before relying on a particular entry.
Follow the roles and permissions guidance and link directory work to a ticket. The ticket preserves the reason and service-desk context alongside the covered audit entries.
Retention
Section titled “Retention”Retention is configurable, and the two directions pull against each other.
Longer helps investigation. “It stopped working in April” is only answerable if April is still there.
Shorter helps disk and privacy. The audit log is the largest table on a mature install, and it records people’s activity.
Some jurisdictions set a minimum retention for records of access to student data. Check what applies to you before setting it short, with whoever owns privacy at your school.
A common shape is twelve months, which covers a full school year plus the handover into the next one.
The window can be set from 90 days to ten years, or to keep everything. The floor is deliberate: below about three months, shortening the window stops being a retention decision and becomes a way to erase recent history, including the record of the setting being changed. If a shorter period is genuinely required somewhere, that is a conversation to have rather than a slider to move.
A purge you start by hand is refused for an hour after either window is shortened, so a change is visible before it becomes permanent. The scheduled sweep is never delayed — whatever the policy says applies on its own.
Erasure
Section titled “Erasure”Removing a person’s records on request is a built-in operation, not a manual database edit. It covers their records across the system rather than one table.
What erasure does not remove
Section titled “What erasure does not remove”Audit entries recording actions taken by staff. An entry saying a technician sent a wipe command is a record of the technician’s action, and it stays.
Records under a legal retention obligation, where one applies.
What the log does not contain
Section titled “What the log does not contain”Secret values. Configuring a connector is logged; the token is not.
Most read operations. Viewing a person’s profile is not logged; changing it is. The exceptions are the bulk ones: exporting everything held about a person for an access request, and viewing somebody’s sign-in history, are both recorded — naming who looked and at whom, not what they saw.
Message bodies. That a reply was sent is logged; the text lives on the ticket.
Vendor access
Section titled “Vendor access”Support restore and setup-link operations record audit entries with the caller’s stated requester. Read requests are not all audited, and the product log does not cover direct hosting or database administration. The API is available when its deployment key is configured unless an administrator switches it off; there is no automatic expiry. See support access controls.
Reviewing it
Section titled “Reviewing it”Twenty minutes a term is enough. Look for:
- Accounts that should have been deactivated and were not.
- Permissions being used that you did not expect, which usually means the role is wider than the job.
- Permissions never used, which lets you narrow a role with evidence.
- Configuration changes nobody remembers making. A connector reconfigured three weeks ago is often the answer to a problem that started three weeks ago.
If the database is growing faster than expected, the audit log is the first place to look, and retention is the lever.
Related
Section titled “Related”- The audit log for using it day to day.
- Compliance answers, which reports the retention settings.
- What we process.