Consent as evidence: what to record when a guardian says yes

Why a tick box fails eighteen months later

A consent column in a spreadsheet answers exactly one question: is it ticked now. Every question that actually gets asked later is a different one. What was the parent told? Which version of the notice was on screen? Who ticked it — the parent, or the clerk transcribing a phone call? Was it ever withdrawn, and did anything stop when it was?

Under India's Digital Personal Data Protection framework, the school is the one answering those questions about its students' data. The obligations commence in stages, and this is not legal advice — but the record-keeping habit below is worth building before anyone asks, because it cannot be reconstructed backwards.

The five things a consent record has to carry

1. Who decided. The guardian's identity, and separately the staff account that captured it if the decision came in over a counter or a call. Those are two different facts and collapsing them destroys the audit trail.
2. When. A timestamp, not a date typed from memory during a review.
3. For what purpose. Not "consented" but consented to *what* — admission processing, an APAAR account, a photograph on the school website. One purpose per decision, named the same way every time.
4. What they were shown. The exact notice text in force at that moment. Not a pointer to "the current privacy notice", which is a moving target and therefore no evidence at all.
5. How it was verified. In person with an ID check, a portal login, an OTP to the guardian's own number. This is the line between a consent you can defend and one you can only assert.

Append, never overwrite

The instinct is to keep a consent status field and update it. That instinct is what destroys the evidence, because the moment a withdrawal overwrites a grant, the fact that a grant ever existed — and everything the school lawfully did while it did — disappears.

Keep a ledger instead. Every decision is a new row: granted, rejected, or withdrawn. Nothing is edited, nothing is deleted, and the current state is simply the latest row for that person and that purpose. A history reads as a history, a withdrawal is a fact rather than an absence, and re-granting later is a third row rather than a resurrection.

Version the notice, freeze the wording

Notice text changes — a new purpose, a clearer sentence, a lawyer's edit. The rule that keeps old consents meaningful is simple: once a version has been shown to anybody, never edit it. Publish a new version and point new decisions at it.

• Give every version an identifier that includes its date, so "which notice was this?" is answerable from the record itself rather than from a changelog somebody has to find.
• Store a digest of the exact text alongside the decision. A hash is a cheap, checkable proof that the wording on file is the wording that was shown — and it costs nothing until the day you need it.
• Keep the statement server-side. A record that trusts the browser to report what it displayed is evidence of what a browser claimed, which is not the same thing.
• Re-consent deliberately when a change is material. A new purpose is not covered by consent to an old one, however similar the sentences look.

How this works in Vidyapeeth360

Consent in Vidyapeeth360 is an append-only ledger, not a field. Each decision — granted, rejected or withdrawn — is written as its own row with the subject, the purpose, the acting account and the verification method; the current state for a subject and purpose is the latest row. Nothing is updated in place and nothing is deleted, so a withdrawal never erases the history of the grant it followed.

Purpose keys are defined in code rather than typed per form, so the workflow that captures a consent and the workflow that later checks it use the same string. Guardian notices are server-owned and versioned: the wording is returned by the server with a deterministic digest, the client echoes only the version and the acceptance, and a version that has already been accepted is never edited — a change becomes a new version.

Every consent write also raises an internal event, so a school can attach a follow-on step — a task, a notification, a status change — to a withdrawal without anyone remembering to do it by hand, and lands a tenant audit entry alongside the ledger row.

In practice the consent record sits next to the rest of the family's record: the guardian on the user and access register, whatever the school collected through its own forms, and the uploads in document management. Retention, erasure and export are separate mechanisms with their own rules — a consent withdrawal is not itself a deletion request, and treating the two as one is a mistake schools make in both directions.

None of this makes a school compliant by itself. Compliance is configuration, notices, lawful use, vendor choices and day-to-day practice; the product's job is to make the evidence a by-product of the work instead of a project you run in a panic.