The audit log and evidence pack

When an auditor, a Support for Students review, or your own governance asks "who did what, and when", First Six can answer. Accountability after the fact is only as good as the record that survives, so this page covers what the record keeps, why it cannot be tampered with, and what you can get out of it.

The audit log

Every staff write is captured in an audit log: which institution, which staff actor, what action, on what entity, with a summary and a structured diffA precise record of what changed, showing the before and after state of the affected fields. of what changed, and when. The diff is what turns "a record was edited" into "this field went from this to that", which is the difference between knowing something happened and being able to reconstruct it.

The log is immutableOnce written, an entry cannot be changed or removed.. The database blocks updates and deletes to it, so an entry cannot be quietly altered or removed after the fact. This is the property that makes the log worth trusting: a record someone could edit is a record an investigation cannot rely on, so the inability to change it is the point, not an inconvenience.

Sensitive reads are captured too, not just writes. When a staff member opens a student's profile, reveals a help-request contact, runs a bulk export, or First Six support reads under a consented break-glass grant (dual-audited, in your trail and ours), that access is logged, so looking is as accountable as changing. For welfare data this matters as much as edits do. Improper access to a student's wellbeing record is itself the harm, even if nothing is altered.

The log is held in the primary database and retained for the life of the database. During an incident, the relevant slice is snapshotted into a separate, preserved location before anything else is touched, and kept for at least twelve months. So the evidence is isolated and safe before any remediation could disturb it.

Getting evidence out

For a Support for Students review or similar, staff can export help requests, engagement aggregates, and the audit trail itself as CSV from the console, scoped to a cohort (the activity log also has its own export, filtered or in full). Scoping keeps it to the data the review actually needs rather than a whole-institution dump, and CSV means the reviewer can work in their own tools.

Two properties of the export machinery matter to a reviewer as much as the files. Every export is itself recorded in the audit trail (dataset and row count against the staff member who pulled it), so the most sensitive read on the platform leaves the same trail as everything else; if that record ever fails to write, the staff member is told on screen rather than the gap passing silently. And a dataset that fails to load shows as unavailable with its download disabled, never as an empty file, because an empty CSV of the audit trail is itself a claim, and the console refuses to make it by accident.

What auditors get

A security or procurement reviewer is not handed a marketing deck. The evidence that backs this section is real and documented:

• The subprocessor list, kept current.
• The incident and breach-response runbook.
• A pre-filled HECVAT-style questionnaire and the compliance posture write-up.
• The security controls, including the service-role boundary and its audit query.

Common questions

Related