What "delete a student's data" can and cannot mean

Two duties that point in opposite directions

A school holds a child's data because it had to. Then a family leaves and asks for it to be removed. The request is legitimate. So is the school's obligation to keep books, examination records and audit trails for years after the child has gone.

Both are real, and the resolution is not a compromise. It is a distinction: erase the person from the record, keep the record. A receipt for ₹42,000 has to survive an audit; the child's name, address and guardian's phone number do not have to survive on it.

Three different things people call deletion

• Removal — the row is gone. Appropriate for things that exist only to communicate: notifications, message logs, one-time tokens. Nothing later depends on them.
• Redaction in place — the row survives, the person does not. The invoice keeps its number, date and amount; the name becomes a placeholder. This is what makes an audited ledger and a family's request compatible.
• Anonymisation — the record is kept for aggregate purposes with the identifiers scrubbed. Useful for enquiry and pipeline data, where the count matters and the individual does not.

Most "delete the data" conversations go wrong because the two sides mean different items from that list. Say which one you mean, per record type, in writing, and the conversation becomes short.

What must stay, and how to justify it

Before deciding anything, write down which categories your school holds and how long each is kept. Not per file — per category. That list is the thing that lets you answer a parent in one sentence instead of a week.

1. Money. Invoices, receipts, refunds, ledger postings. Retained for whatever period your own accounting and tax obligations set — confirm that period with your auditor and write it down; the personal identifiers on them can go.
2. Academic outcomes. Marks and results a board, another school or a university may need to verify. Retained; contact details attached to them are not the outcome.
3. Audit trails. Who did what, when. These exist precisely so they cannot be edited after the fact — a system that lets you delete its own audit log has no audit log.
4. Special-category records. Health, infirmary, counselling and wellbeing entries about a child. These are the most sensitive thing a school holds, and unlike the ledger there is rarely a reason to keep them once the child has left. Treat them as removable, and check that your system actually removes them rather than leaving a parallel copy behind.

The copies nobody remembers

The hard part of erasure is not the student record. It is the eleven other places the child's name was copied for convenience — the transport assignment, the hostel gate pass, the library loan, the delivery log for a message, the uploaded birth certificate, the task somebody created about them.

Each of those is a genuine operational record that may need to survive. What must not survive is the name and the guardian's phone number sitting on it, because that is exactly what makes an "erased" student recoverable by searching for their name. Ask your vendor, specifically: which records keep a copy of the student's name, and what happens to each one on erasure? A confident "we delete everything" is usually a system that has never enumerated the list.

How this works in Vidyapeeth360

Erasure is redact-in-place. The student row survives with its identifier, class, section and status so the financial ledger and audit trail stay coherent, and the personal fields are cleared: name, guardians, address, photograph, date of birth, blood group, and the national identifiers including the Aadhaar reference, APAAR ID and UDISE PEN. The record is marked erased with the time it happened.

The copies are enumerated rather than hoped about. Invoices and payments keep the row and lose the name. Transport assignments, hostel allocations and gate passes, library loans and the DigiLocker push record are each stripped of the denormalised name and guardian phone; uploaded documents are withdrawn; task records keep the operational history but lose the link back to the child. Notifications, message logs, consent tokens and the health, infirmary and immunisation records are removed outright — special-category data about a child should not linger because it lived in a different table.

Retention is deliberately conservative and separate from erasure. Windows are declared once per collection, and only a narrow allowlist of low-risk operational records is ever purged automatically — enquiry records are anonymised in place rather than deleted, and financial, student, audit and consent data is never auto-deleted at all. The automatic sweep is off unless a deployment turns it on.

Before erasing, export. The access copy assembles the student's record across the register, invoices, payments, refunds, attendance, marks, library, hostel, transport, consent and communications, so the family can be given what the school held. Erasure after that is a decision somebody made and can point at — not a delete key. Who may run either is a permission question, which is why the access model matters as much as the mechanism, and why the surviving fee record and the withdrawn documents end up in different states.

This is a set of controls, not a compliance certificate. Your school still owns the notices, the lawful basis, the vendor list and the decision itself — the product's contribution is that the decision is executed consistently and leaves a trail.