Audit log
An audit log is an append-only record of security-relevant events in a system: who did what, to which record, from where, and when. It is distinct from an activity feed, which is a convenience for users, and from application logs, which exist to help engineers debug.
| Rung | Mechanism | Defeats | Does not defeat |
|---|---|---|---|
| 1. Writable log | An ordinary table any privileged process can update | Accidental loss, if backed up | Anyone with database access, including an insider or a compromised application |
| 2. Append-only by convention | The application never issues UPDATE or DELETE | Bugs in ordinary code paths | A different code path, a migration, a console session, a support engineer |
| 3. Permission-revoked append-only | UPDATE and DELETE privileges revoked from the application role | The application itself, and anything using its credentials | An operator with elevated database credentials |
| 4. Hash-chained append-only | Each entry hashes over the previous entry's hash plus its own canonical content | Silent alteration or removal anywhere in the sequence — it becomes detectable by recomputation | Wholesale rewriting of the entire chain by someone who can also replace the stored head |
| 5. Externally anchored | The chain head is published somewhere the vendor does not control | Wholesale rewrite, because the historical head is fixed outside the system | Entries that were untrue when written |
What has to be in an entry for it to be useful
An audit entry that records only "user updated student" is close to worthless in an investigation. The eight questions an incident review asks, and the fields each requires:
- Who acted? A stable actor identifier, not a display name that can be edited later. Where an action is taken under a group or shared identity, the true individual must still be recorded.
- What did they do? A controlled event type, not free text.
- To what? The affected record's type and identifier.
- When? A server-assigned timestamp. Client-supplied times are evidence of nothing.
- From where? Session and network context. For privacy reasons this is often stored hashed rather than raw — Kastr stores a truncated SHA-256 of the session IP, never the address itself.
- Under what authority? The role or capability that permitted it, so that a later question about whether access was appropriate can be answered.
- What changed? For modifications, enough of the before and after state to reconstruct the change.
- In which tenant? The organisation the event belongs to, which is also what allows a per-organisation chain rather than one shared sequence.
The event classes that matter in district software: authentication, record access (not only modification), record modification, message send, permission change, export, deletion, and administrative override. The one most often missing is access. A log that records edits but not reads cannot answer the FERPA question of who looked at a student's record.
Why it matters to a district specifically
Three moments make an audit log load-bearing rather than decorative. A parent alleges they were never notified before a truancy referral, and the district has to produce contact evidence a court will accept. A staff member is alleged to have accessed records without a legitimate educational interest, and the district must establish who accessed what. A public-records request or a state monitoring visit asks for message history, and the district must be able to state that what it produced is complete and unaltered.
In each case the value of the log is not that it exists but that its integrity can be asserted by someone other than the vendor. That is the entire reason rungs 4 and 5 in the table above exist.
The common misconception
"Our platform has an audit log, so we can prove what happened." Most products described as having an audit log sit at rung 1 or 2. The record is an ordinary table, the application does not normally modify it, and an administrator with sufficient privileges can. That is a history, not evidence. The question to ask a vendor is not "do you have an audit log" but "what specifically prevents an entry being altered, and does that mechanism also exclude your own staff?"
The second misconception is that a hash chain proves the entries are true. It does not. It proves they have not changed since they were written. A system that logs the wrong thing accurately will produce a perfectly verifiable record of the wrong thing.
How Kastr implements it
One chain per organisation. Each entry stores hash = sha256(prevHash ‖ canonical(event)), and writes are serialised under a Postgres advisory transaction lock so concurrent sends cannot produce a chain that verifies incorrectly.
Append-only is enforced at two independent layers, which is rung 3 and rung 4 together: UPDATE and DELETE are revoked from the application database role, and the row-level security policy set contains no UPDATE or DELETE policy at all — in Postgres, an operation with no permissive policy cannot succeed, so this is not a rule that could be misconfigured to permit.
Group-identity posts record the true author's person identifier, so a PTA volunteer posting as their group is still individually attributable. We do not currently publish the chain head externally, so we sit at rung 4 rather than rung 5, and we would rather say so than describe rung 4 in language that implies rung 5.
Questions people actually ask
What is the difference between an audit log and an activity feed?
An activity feed is a user-facing convenience: recent, filtered, usually deletable, and scoped to what the viewer finds interesting. An audit log is an evidentiary record: complete, immutable, retained on a schedule, and including events no user wants to see. A product that shows you a feed and calls it an audit log has not built the second thing.
What makes an audit log tamper-evident?
A cryptographic chain. Each entry contains a hash computed over the previous entry's hash and its own canonical content, so altering or removing any entry invalidates every hash after it. Anyone can verify this by recomputing forward. Tamper-evident is the correct word: it does not prevent alteration, it makes alteration detectable without trusting the system that stored it.
Does FERPA require a disclosure log?
FERPA requires an education agency to maintain a record of requests for and disclosures of personally identifiable information from a student's education records, available for inspection by the parent, with specified exceptions including school officials with a legitimate educational interest. That is a narrower obligation than a general system audit log, but a system audit log that records access is usually how a district satisfies it in practice.
Can an administrator delete audit log entries?
In most products, yes, if they have sufficient database or support-tier access. The design question is whether deletion is prevented by permission, made detectable by a hash chain, or both. In Kastr it is both, and the revoked privileges apply to the application role we run under — but no vendor-controlled system can fully exclude the vendor. Only external anchoring of the chain head does that, and we have not built it.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.