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. This page covers the record it keeps 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 diff of what changed, and when. The log is immutable. The database blocks updates and deletes to it, so an entry cannot be quietly altered or removed after the fact.
Sensitive reads are captured too, not just writes. When a staff member opens a student's profile, that access is logged, so looking is as accountable as changing.
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.
Getting evidence out
For a Support for Students review or similar, staff can export help requests and engagement aggregates as CSV from the console, scoped to a cohort. That gives you the activity record without anyone needing console access.
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.
The compliance material is written as an honest self-assessment, including the open items, rather than a clean-looking claim sheet. That is deliberate: it is faster for your reviewers to trust a document that names its own gaps.
The fastest answer is usually one question away.