← All templates

Schools — DPDPA Sector Pack

The core school obligation: how the school verifies that the person consenting for a student is genuinely that child's parent or lawful guardian, per s.9 and Rules 2025 r.10 (including the virtual-token / Digital Locker route).

• Verifiable Parental Consent Procedure (Children's Data)

  The core school obligation: how the school verifies that the person consenting for a student is genuinely that child's parent or lawful guardian, per s.9 and Rules 2025 r.10 (including the virtual-token / Digital Locker route).

  # Verifiable Parental Consent Procedure **[SCHOOL_NAME]** — implements DPDP Act 2023 **s.9** (processing of children's data) and **DPDP Rules 2025 r.10** (verifiable parental consent). ## 1. Why this exists Every student under 18 is a "child" under the Act. Processing their personal data requires the **verifiable consent of a parent or lawful guardian** (s.9(1)). "Verifiable" is not satisfied by a signature on an admission form alone — r.10 requires technical and organisational measures ensuring the consenting person **is an identifiable adult** and is that child's parent/guardian. ## 2. How we verify (choose the route(s) you actually use) Under r.10, verification uses identity/age details that are either already reliably held by us, or voluntarily provided: - **Route A — details we already hold.** At admission we verify the parent's identity against [CUSTOMIZE: e.g. the admission record's government ID we sighted, the guardian named on the birth certificate/transfer certificate]. The verified parent is recorded against the student's file and is the only person who can give or withdraw consent. - **Route B — voluntarily provided details / virtual token.** Where a parent consents remotely (portal, app, email), verify via [CUSTOMIZE: chosen mechanism], which may include a **virtual token mapped to identity/age details issued by an authorised entity such as a Digital Locker service provider** (r.10). Record which mechanism was used for each consent. - **Guardianship other than a parent.** Where a lawful guardian consents, hold documentary proof [CUSTOMIZE: guardianship order / court document] before accepting consent. > Do not build a route you cannot actually operate. If the school only > collects consent in person at admission, say exactly that — Route A > alone, properly recorded, is a real control; a described online > verification flow that does not exist is not. ## 3. What consent covers (s.6(1): specific, informed, limited) Separate, itemised consent per purpose. Attach the notice (`school-student-privacy-notice`) at the time consent is sought (s.5). | Purpose | Consent required? | Notes | |---|---|---| | Academic records, attendance, examinations | [CUSTOMIZE: state the basis you rely on] | Core school function | | Health/medical information held for the child | Yes | Sensitive; restrict access | | Photographs / video for school publicity, website, social media | **Yes — separate, opt-in** | Never bundled with admission | | Transport / GPS bus tracking | [CUSTOMIZE] | See §4 on the tracking prohibition | | Third-party edtech apps and platforms | Yes, per app | See `school-edtech-vendor-checklist` | | Alumni / fundraising communication | **Yes — separate, opt-in** | | ## 4. The hard prohibition (s.9(3)) The Act **prohibits** a Data Fiduciary from: - **tracking or behavioural monitoring of children**, and - **targeted advertising directed at children**. This is a prohibition, not a consent question — parental consent does **not** unlock it. Practical consequences the school must check: - No advertising SDKs / ad-tech in any student-facing app or portal. - No behavioural analytics profiling individual students for non- educational purposes. [CUSTOMIZE: distinguish legitimate academic progress tracking — a school function — from behavioural monitoring; document where you draw the line and why.] - Bus/GPS tracking: assess and document your position — safety-purpose vehicle tracking is materially different from behavioural monitoring of a child, but the assessment must be **written down**, not assumed. - Any exemption or relaxation under **s.9(4)** applies only if the Central Government has notified it for your class of fiduciary or purpose. [CUSTOMIZE: check the current position before relying on any relaxation — do not assume one applies.] ## 5. Withdrawal (s.6(4)–(6)) A parent may withdraw any consent as easily as it was given. On withdrawal: stop that processing, notify the relevant processor (edtech vendor), and record it. Withdrawal of publicity consent means removing existing photos from [WEBSITE/SOCIAL/PROSPECTUS] going forward — record the action taken. ## 6. Records (this is the evidence) Maintain per student: verified parent/guardian identity, the verification route used, each purpose consented to with date, and any withdrawals. Upload a sample (redacted) page or a screenshot of the consent module to Sentyra. --- *Owner: [ROLE] · Review: [ANNUALLY] · Version: [VERSION] · Date: [DATE]*

• Student & Parent Privacy Notice (Printable, EN + HI)

  Notice given to parents at admission and on the school portal: what student data is collected, purposes, rights, and the Grievance Officer — English + Hindi, per s.5(3) and Rules 2025 r.3.

  # Student & Parent Privacy Notice / विद्यार्थी एवं अभिभावक गोपनीयता सूचना **[SCHOOL_NAME]** — given to the parent/guardian at or before the time consent is sought, per the DPDP Act 2023 **s.5**, presented independently and in clear and plain language per **Rules 2025 r.3**. ## What we collect and why (s.5(1)) | Data | Purpose | |---|---| | Student name, date of birth, address, photo | Admission, identification, academic records | | Parent/guardian name, contact, ID details | Verifiable parental consent (s.9), emergency contact, fee communication | | Academic records, attendance, assessments | Delivering and reporting on education | | Health information / allergies / medical needs | Student safety and care | | Biometric attendance data [IF COLLECTED] | Attendance recording (see biometric & CCTV policy) | | CCTV imagery | Campus safety | | Transport / route details [IF APPLICABLE] | School transport and safety | | Fee and payment details | Billing | We collect only what these purposes require (s.6(1)) and do not use student data for any other purpose without fresh notice and consent. ## We do not track or profile children (s.9(3)) We do not undertake tracking or behavioural monitoring of children, and we do not permit targeted advertising directed at students. Third-party educational apps we use are assessed against this rule before adoption. ## Your rights as parent/guardian (ss.11–14, s.6(4)) - **Access** a summary of your child's personal data we hold (s.11) - **Correction or erasure** of that data (s.12) - **Withdraw consent** at any time, as easily as it was given (s.6(4)) - **Grievance redressal** (s.13) — see the officer below - **Nominate** another person to exercise these rights (s.14) To exercise any right: [PORTAL/EMAIL/OFFICE] — we respond within [RESPONSE_PERIOD]. ## Retention Student records: [RETENTION_PERIOD — CUSTOMIZE; see the retention schedule and any education-board record requirement that applies to you]. Data is erased when its purpose is served unless another law requires us to keep it (s.8(7)). ## Grievance Officer (s.13 / s.8(10)) [GRIEVANCE_OFFICER_NAME] — [EMAIL] — [PHONE]. If unresolved, you may complain to the Data Protection Board of India. --- ## हिन्दी (s.5(3): Eighth Schedule language) **हम क्या एकत्र करते हैं:** विद्यार्थी का नाम, जन्म तिथि, पता, फोटो (प्रवेश एवं शैक्षणिक अभिलेख हेतु); अभिभावक का नाम, संपर्क एवं पहचान विवरण (धारा 9 के अंतर्गत सत्यापन योग्य अभिभावकीय सहमति, आपातकालीन संपर्क हेतु); शैक्षणिक अभिलेख एवं उपस्थिति; स्वास्थ्य संबंधी जानकारी (सुरक्षा हेतु); बायोमेट्रिक उपस्थिति (यदि लागू); सीसीटीवी फुटेज (परिसर सुरक्षा हेतु); शुल्क एवं भुगतान विवरण। **हम बच्चों की निगरानी या प्रोफाइलिंग नहीं करते (धारा 9(3)):** हम बच्चों की ट्रैकिंग या व्यवहारगत निगरानी नहीं करते, और विद्यार्थियों को लक्षित विज्ञापन की अनुमति नहीं देते। **अभिभावक के अधिकार (धारा 11–14, धारा 6(4)):** अपने बच्चे के डेटा का सारांश प्राप्त करना, सुधार या मिटाने का अनुरोध, सहमति वापस लेना (जितनी आसानी से दी गई थी), शिकायत निवारण, तथा अधिकार प्रयोग हेतु किसी को नामित करना। **शिकायत अधिकारी:** [GRIEVANCE_OFFICER_NAME] — [EMAIL] — [PHONE]। समाधान न होने पर आप भारतीय डेटा संरक्षण बोर्ड में शिकायत कर सकते हैं। --- *[CUSTOMIZE every bracketed field before issuing — a notice with visible placeholders is not a valid notice.]* *Version: [VERSION] · Effective: [DATE]*

• Edtech / School ERP Vendor Assessment (Processor Due Diligence)

  For most schools the ERP/edtech vendor IS the data processor holding all student data. Assessment checklist plus the s.8(2) contract terms and the s.9(3) no-tracking/no-ads screen every student-facing app must pass.

  # Edtech / School ERP Vendor Assessment **[SCHOOL_NAME]** — processor due diligence under DPDP Act 2023 **s.8(2)** (a Data Fiduciary may engage a processor only under a valid contract) and the **s.9(3)** prohibition screen for anything student-facing. ## 1. Inventory first List every system holding student or parent data — this is usually longer than schools expect: | Vendor / system | What it holds | Where hosted | Contract in place? | |---|---|---|---| | [ERP / school management software] | | | | | [Learning platform / LMS] | | | | | [Online exam / assessment tool] | | | | | [Biometric attendance vendor] | | | | | [Fee payment gateway] | | | | | [Bus tracking provider] | | | | | [Communication app — WhatsApp groups, SMS gateway] | | | | | [CCTV / AMC vendor with footage access] | | | | > Staff WhatsApp groups containing student photos and marksheets are a > real processing activity. [CUSTOMIZE: decide and document whether > these are permitted, and under what rules.] ## 2. The s.9(3) screen — pass/fail, before adoption Any app used by or about students must be confirmed to have: - [ ] **No advertising SDKs / ad networks** of any kind - [ ] **No behavioural profiling** of individual students beyond academic-progress purposes - [ ] **No sale or sharing of student data** with third parties for marketing - [ ] No "free in exchange for data" model [CUSTOMIZE: free tools often monetise data — check the actual terms, not the marketing page] A vendor failing this screen cannot be adopted, regardless of parental consent — s.9(3) is a prohibition, not a consent question. ## 3. Contract terms required (s.8(2)) The vendor contract must bind them to: - Process student data **only on our documented instructions**, for the purposes we specify — never for their own product development, marketing, or model training [CUSTOMIZE: AI/analytics features often train on customer data by default; check and disable] - Implement **reasonable security safeguards** (s.8(5)) - **Notify us of any personal data breach without delay**, so we can meet our own s.8(6) obligation [CUSTOMIZE: state the hours] - Obtain our **prior written authorisation** before engaging any sub-processor, and flow these terms down - **Assist** us in responding to parent access/correction/erasure requests - **Return or delete** all student data on termination - Tell us **where data is hosted** (relevant to s.16 cross-border transfer) ## 4. Assessment record | Vendor | Screened (§2) | Contract signed (§3) | Hosting location | Reviewed by | Date | |---|---|---|---|---|---| | | | | | | | Upload the completed table and signed contracts to Sentyra as `DPDPA-PROCESSOR` evidence. --- *Owner: [ROLE] · Review: [ANNUALLY / on each new vendor] · Version: [VERSION] · Date: [DATE]*

• Biometric Attendance & CCTV Policy (Campus)

  Biometric attendance and campus CCTV are the two highest-sensitivity processing activities on a school campus: safeguards, retention, access limits, and the no-monitoring-of-children boundary.

  # Biometric Attendance & CCTV Policy **[SCHOOL_NAME]** — implements DPDP Act 2023 **s.8(5)** (reasonable security safeguards), **s.8(7)** (erasure when purpose served), and the **s.9(3)** prohibition on behavioural monitoring of children. ## 1. Biometric attendance [DELETE THIS SECTION IF NOT USED] Biometric data of children is among the most sensitive data a school can hold. Before using it at all: - **Necessity check**: document why card/roll-call attendance is insufficient [CUSTOMIZE — if you cannot articulate this, reconsider collecting biometrics from children at all; s.6(1) limits collection to what the purpose requires]. - **Parental consent**: covered by the verifiable parental consent procedure, as a **separate itemised purpose** — never bundled into admission. - **Storage**: store **templates/hashes, not raw fingerprint or face images**, where the device supports it [CUSTOMIZE: confirm with your vendor what is actually stored and where]. - **Location**: on-device / on-premise at [LOCATION]; if the vendor stores it in their cloud, that vendor is a processor — see the edtech vendor checklist, and record the hosting location. - **Access**: [ROLES] only. Device admin password changed from default. - **Erasure (s.8(7))**: biometric enrolment deleted within [PERIOD] of a student leaving the school. Record each deletion batch. ## 2. CCTV - **Coverage**: entrances, corridors, playground, transport bays, and perimeter. **Never** in washrooms, changing rooms, or medical/ counselling rooms. - **Not behavioural monitoring (s.9(3))**: CCTV is operated for campus safety, not to monitor or profile individual students' behaviour. Footage is not used for [CUSTOMIZE: e.g. discipline analytics, attention scoring, or any per-student behavioural assessment]. - **Signage (s.5)**: display at monitored areas — > **CCTV in operation** for campus safety. Recordings kept > [RETENTION_DAYS] days. Contact: [GRIEVANCE_OFFICER_NAME], > [CONTACT]. > > **सीसीटीवी निगरानी जारी** — परिसर सुरक्षा हेतु। रिकॉर्डिंग > [RETENTION_DAYS] दिन रखी जाती है। संपर्क: [GRIEVANCE_OFFICER_NAME]। - **Retention (s.8(7))**: [RETENTION_DAYS] days, then automatic overwrite. Longer only for a specific logged incident, authorised by [ROLE]. - **Access**: DVR/NVR in a locked room; viewing limited to [ROLES]; remote-viewing apps only on named devices [CUSTOMIZE: list]. **No footage on personal phones or WhatsApp.** - **Disclosure**: to police/authorities on valid written request, or to a parent only per [CUSTOMIZE: your documented process — note footage usually shows other children, whose data must be protected]. ## 3. Evidence for Sentyra Photo of displayed signage; screenshot of the DVR retention setting; biometric deletion log page. --- *Owner: [ROLE] · Review: [ANNUALLY] · Version: [VERSION] · Date: [DATE]*

• Student Records Retention & Erasure Schedule

  How long each category of student data is kept after a student leaves, and how it is erased — including the alumni-data and old-photo problem most schools have never addressed.

  # Student Records Retention & Erasure Schedule **[SCHOOL_NAME]** — implements DPDP Act 2023 **s.8(7)**: erase personal data when the purpose is no longer being served and retention is not required by law. ## 1. Schedule | Data category | Retention after student leaves | Basis | Erasure method | |---|---|---|---| | Academic transcripts / transfer certificates | [PERIOD — CUSTOMIZE to the education-board or state requirement that applies to you] | Legal/regulatory retention | [Archive then destroy] | | Attendance records | [PERIOD] | | | | Health / medical records | [PERIOD] | | | | Biometric enrolment templates | [SHORT PERIOD — e.g. on exit] | No ongoing purpose after exit | Delete from device + vendor | | Fee / payment records | [PERIOD — statutory financial retention] | Tax/audit law | | | Photographs & video (publicity) | Until consent withdrawn or [PERIOD] | Consent | Remove from site/social/prospectus | | CCTV footage | [RETENTION_DAYS] days | Safety | Automatic overwrite | | Parent contact details | [PERIOD] | | | | Alumni contact data | Only with alumni's own consent as an adult | Consent | [CUSTOMIZE: a student who turns 18 is no longer a child — their continued inclusion in alumni communication needs their own consent, not the parent's] | > The two categories schools most often miss: **old publicity > photographs** of children still live on the website and social media > years later, and **legacy ERP data** from a discontinued vendor. Both > are ongoing processing. Address them explicitly. ## 2. Erasure on request (s.12) A parent (or a former student now an adult) may request erasure. Fulfil it unless a legal retention requirement in §1 applies — in which case tell them **which** requirement and for how long, rather than simply refusing. Log every request and outcome in Sentyra's rights tracker. ## 3. Execution - Cadence: review leavers [ANNUALLY / at each session end], owner [ROLE]. - Instruct processors (ERP/edtech vendors) to erase in step with this schedule — their copy is also your responsibility (s.8(2)). - Record each erasure batch: date, categories, records affected, by whom. --- *Owner: [ROLE] · Review: [ANNUALLY] · Version: [VERSION] · Date: [DATE]*

Need to track which template is done, get acknowledgments, and store evidence? Start your DPDPA program on Sentyra →