This is the change-history layer — an immutable, tamper-evident trail of every record-changing action across SchoolDeck, capturing who did what and when, aligned to the DPDP Act 2023. The record an auditor or inspector asks for, that can't be quietly rewritten.
For administrators, trustees & auditors · who-did-what-when · append-only & tamper-evident · records what users did (permissions are role-based-access; live numbers are analytics).
Audit logs keep the immutable, tamper-evident forensic trail of every record-changing action across SchoolDeck — who did what, and when — aligned to the DPDP Act 2023. It's the record a school produces when a Trust auditor or CBSE inspector asks how a fee, mark or record came to be what it is: a history that can be read but not quietly rewritten. It owns the change history specifically. It is not the permission system — role-based access owns who-can-see-and-do-what; this records what they actually did. And it's not the live numbers — the current fee-collection rate, attendance and result trends are the analytics & reporting solution, which reads the live state and defers the change trail to this page.
A parent queries a changed mark. Instead of an argument, Mrs Bhattacharya opens the trail and searches the record. Here's the kind of forensic extract it returns — who, when, and what changed from and to.
| When | Who (actor) | Module | Action — from → to |
|---|---|---|---|
| Term-2, day 14 | Class teacher | Examinations | mark entered: A → B |
| Term-2, day 15 | HOD | Examinations | mark corrected: B → A (re-totalling) |
| Term-2, day 20 | Accountant | Fees | concession applied: 0 → sibling 10% |
| Term-2, day 22 | Front office | Admissions | record edited: phone updated |
| Term-2, day 28 | Custodian | Inventory | asset marked: in-use → disposed |
A parent queries a grade, it has clearly been altered, and there's no record of who changed it or when — so it becomes one person's word against another rather than a fact anyone can check.
A Trust auditor asks how a fee figure came to be, and the school reconstructs the story from memory and scattered notes — exactly the kind of answer an auditor cannot rely on.
An "audit list" that any admin can open and rewrite proves nothing — if the evidence can be doctored, it stops being evidence. Without tamper-evidence, the record is decorative.
Each module keeps its own partial history in its own way, so there's no single consistent trail — and an inspection that spans fees, marks and admissions has to be assembled from incompatible pieces.
Whenever a fee record, mark, admission entry or any other record is created, edited or deleted, the action is written to an append-only log automatically — without anyone choosing to record it — capturing the actor, the timestamp and the change, across every module.
Each entry records not just that something changed but what it changed from and to, so a mark altered from one value to another, or a fee adjusted, leaves a complete picture rather than a bare note that "something was edited."
The log is append-only and tamper-evident: it can be read and searched, but entries aren't meant to be silently rewritten, so the record itself is defensible. This is what separates a forensic trail from an ordinary editable list — its value is that it resists being doctored.
When the Trust auditor or CBSE inspector asks about a specific fee, mark or period, the relevant entries are found by searching the trail by user, record or date — producing the history of that item rather than a reconstruction from memory.
The trail records what was done; role-based access governs who was permitted to do it, and analytics & reporting shows the current numbers. A complete answer reads the change history here, the permissions there, and the live state on the dashboard.
Actions are written to the log, not removed from it. We describe this honestly as tamper-evident — the design goal is that any attempt to alter the record is itself visible — rather than claiming the storage can never be touched under any circumstance. A log you could quietly clear would defeat its own purpose.
The trail is aligned to the DPDP Act 2023, implemented in phases through 2027. Keeping a record of who accessed and changed personal data — much of it about minors — is part of handling that data responsibly, and the audit trail is the mechanism that makes that accountability possible.
The trail itself is access-controlled and India-hosted; who may even read it is governed by role-based access, so the forensic record doesn't become a second uncontrolled copy of the data. It records actions on data without exposing the data afresh.
Framework references: DPDP Act 2023 (forensic trail of access and change to personal data, phased to 2027). "Tamper-evident" is stated honestly — the design goal is that any change to the record is itself visible, not an absolute claim that the record can never be altered. The trail records what was done; the permission catalogue (who-can-see-and-do) is owned by the role-based-access feature, and the live operational numbers by the school-analytics-reporting solution.
SchoolDeck keeps the forensic trail, the permission system and the live dashboard as three separate pages on purpose — they answer three different questions, so each ranks for its own and none competes with the others.
The trail is the same; the moment it matters shifts with the reader.
When the Section 12A/12AB auditor asks how a fee or asset record changed, the school searches the trail and produces the history — who, when, from and to — rather than reconstructing it. It underpins the asset register and finance records the auditor reviews.
An inspection that spans marks, admissions and fees gets one consistent change history across modules, so the school shows a defensible record instead of stitching together separate partial logs.
A parent queries a mark, a figure looks wrong, a record changed unexpectedly — and instead of an argument, anyone authorised can look and see, factually, who made the change and when. The same trail that satisfies an auditor keeps daily record-keeping honest.
"I'm the administrator, which means I'm the one who faces the auditor and the inspector, and the question that used to make my stomach drop was always some version of 'who changed this, and when?' A mark that had been corrected, a fee with a concession nobody could explain — and all I had was people's memories and a few notes. Now there's a proper trail. When a parent disputed a grade last term, I searched the record and could see in seconds that the HOD had corrected it after a re-totalling, with the date — not someone quietly altering it. What I appreciate is that the team was honest with me about what it is: they call it tamper-evident, not unhackable, and that's the right word — the point is that any change to the record shows up, so it can't be doctored silently. And they were clear it's a different thing from our permissions module and from the analytics dashboard. This one answers 'what was done.' That's exactly the question I get asked."
What every administrator, trustee and auditor asks before they rely on the trail for an inspection.
We'll show you the forensic trail — who did what and when across every module, with before-and-after capture and tamper-evident, append-only design — and how it's searched for a Trust audit or CBSE inspection, on your school's actual data.
See the Audit Trail →