Audit and retention
The audit log
Section titled “The audit log”Append-only. Every action that changes state or grants access, with who, what, when and what changed. Entries cannot be edited or deleted through the application by anybody, including administrators.
Read it at the audit log. This page is about how long to keep it and what to do about erasure.
Retention
Section titled “Retention”Configurable, and a real trade rather than a setting to leave at the default.
Longer is better for investigation. “It stopped working in April” is only answerable if April is still there.
Shorter is better for disk and for privacy. The audit log is the largest table on any mature install, and it is a record of 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. That is a question for whoever owns privacy at your school rather than for ICT alone.
A common shape is twelve months, which covers a full school year plus the handover into the next one.
Erasure
Section titled “Erasure”Removing a person’s records on request is a first-class operation rather than a manual database edit.
That matters because an assessment asks how deletion works, and “by hand” does not describe a process. An assessment asking about deletion is asking whether the process is repeatable and whether it is complete.
Erasure covers the person’s records across the system, not just their row in 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. Removing it because the device belonged to a person who requested erasure would destroy the accountability record.
This is a normal and defensible position, and it is worth being able to state it clearly if asked.
Records under a legal retention obligation, where one applies.
What the log deliberately does not contain
Section titled “What the log deliberately does not contain”Secret values. Configuring a connector is logged; the token is not.
Read operations, mostly. Viewing a person’s profile is not logged. Changing it is. A log of every page view would be enormous and would bury the entries that matter.
Message bodies. That a reply was sent is logged; the text lives on the ticket.
Vendor access
Section titled “Vendor access”On managed hosting, every action a vendor engineer takes appears in your own audit log, attributed to them, alongside everything else.
Vendor access is off by default, time-bound when granted, and can be disabled outright by you.
Reviewing it
Section titled “Reviewing it”Once a term is enough, and twenty minutes is enough.
What to 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 is a chance to narrow a role with evidence rather than argument.
- Configuration changes nobody remembers making.
That last one is the most useful. A connector reconfigured three weeks ago is frequently 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.