On this page
- When DPDP applies
- Data lifecycle
- Data Fiduciary
- Children’s data
- Parental consent
- Rule 12
- Admissions
- Consent architecture
- Privacy notices
- Rights
- Employee data
- Website
- Technology check
- CCTV
- Bus GPS
- Biometrics
- EdTech & vendors
- Foreign cloud
- AI
- Aadhaar & APAAR
- Retention
- Breaches
- Security
- Government schools
- DPO & SDF
- Penalties
- Priority risks
- Readiness check
- Roadmap
- Checklist
- Myth vs fact
- FAQ
- Primary sources
Overview · Applicability
When does DPDP apply to a school?
Yes, in most cases. The Act covers processing of digital personal data within India where data is collected in digital form, or collected on paper and later digitised. It also reaches processing outside India connected to offering goods or services to people in India. For a school, that captures almost every modern system — from the admission form to the ERP, cloud drives, LMS, CCTV, bus GPS and payment portal.
Covered digital processing for a school will typically include online enquiry, registration and admission forms; Student Information Systems and ERPs; spreadsheets and electronic registers; Google Drive / OneDrive and email attachments; Learning Management Systems; Google Workspace for Education and Microsoft 365 / Teams; online assessment systems; CCTV footage where a person is identifiable; bus GPS, RFID and transport apps; digital attendance, student-ID and biometric systems; parent-communication apps, SMS and school-managed WhatsApp; fee-payment portals; employee, teacher, driver, contractor and applicant records; and website forms, chatbots, analytics and social-media tools.
School categories
↔ Scroll the table horizontally to see all columns.
| School type | DPDP position | Practical issue |
|---|---|---|
| Private school | Normally within scope for covered digital processing | Identify the legal entity operating the school and every relevant system |
| CBSE-affiliated private | Within scope; board reporting adds distinct flows | Separate school processing from CBSE registration, LOC and exam workflows |
| CISCE-affiliated | Within scope; CISCE rules may add recordkeeping duties | Check current CISCE rules for the relevant exam year |
| International school in India | Within scope for covered Indian processing | May also carry foreign contractual / regulatory commitments |
| Preschool / kindergarten | Within scope where child/parent data are digitised | Child-data design is especially important |
| Aided school | Usually within scope | Map school-controlled and government-reporting systems separately |
| Government school | Not automatically exempt | Assess State/instrumentality status, statutory purpose and s.17 modifications |
| School chain / group | Within scope; roles differ across trust, society, company, central office and campus | Identify whether data is centrally or locally controlled |
| Coaching institution | Within scope where it processes covered digital data | May be a separate Data Fiduciary even when serving minors |
Sources: DPDP Act, 2023 (India Code) · DPDP Rules, 2025 (MeitY)
Overview · Data map
The school data lifecycle
Personal data enters the school long before a child is enrolled and persists long after they leave. Mapping the whole lifecycle is the fastest way to see where child-data, retention and vendor risks concentrate.
Enquiry → Archive: data, and its main risk, at each stage
Enquiry
Parent name, mobile, email, child age/grade interest
Reusing enquiry data for unrelated marketing
Admission
Student identity, DOB, address, parent details, documents
Overcollection & exposed document uploads
Verification
Birth / transfer certificate, ID, category/disability docs
Aadhaar overcollection & broad access
Enrolment
Student ID, emergency contacts, health, guardian details
Inaccurate guardianship / custody records
Classroom
Assignments, attendance, grades, accommodations
Behavioural analytics on student content
Assessment
Marks, exam registration, report cards, photographs
Incorrect or publicly exposed results
Transport & activities
GPS, RFID, bus attendance; performance photos/videos
Unnecessary tracking; public social-media exposure
Payments
Payer details, invoices, fee status, payment reference
Fee data sent through informal channels
Graduation / withdrawal
Transfer certificate, final records, account-closure data
Rights transition when a student turns 18
Alumni & archive
Contact details, academic history; backups, vendor-held data
Indefinite retention; “deleted” data persists in backups
Overview · Roles
Who is the Data Fiduciary?
Usually the school itself. A Data Fiduciary is the person who, alone or with others, determines the purpose and means of processing. A school decides why it collects data, which systems and suppliers it uses, and how long it keeps records — so it is normally the Data Fiduciary and remains responsible for processing done on its behalf.
Correctly identifying the legal entity matters, because that entity must be named in notices, processor contracts, rights workflows, breach notifications and accountability records. The relevant school entity may be a public or private trust, a registered society, a Section 8 company, a private limited company, a government department or State authority, a central education group, or a campus-specific entity within a group.
A Data Processor processes personal data on behalf of a Fiduciary, and may be engaged only under a valid contract. A SaaS product is not automatically a Processor simply because the school pays for it — the role turns on who decides the purpose and means of the relevant processing.
↔ Scroll to see the vendor-role columns.
| Activity | School role | Vendor role | Why |
|---|---|---|---|
| School ERP | Usually Data Fiduciary | Usually Processor for school-directed storage/administration | The school determines why records are collected and used |
| Google Workspace / Microsoft 365 | Usually Data Fiduciary | Processor for institution-controlled services; separate roles for provider-controlled functions | Contract terms, configuration and provider processing matter |
| Payment gateway | Fiduciary for fee administration | Processor for some services; independent Fiduciary for settlement, fraud, KYC | Payment providers may independently determine some purposes |
| CBSE reporting | Fiduciary for school-held records | CBSE may be independent Fiduciary for board/exam processing | Each organisation determines its own purpose |
| CCTV operator | Usually Data Fiduciary | Processor when operating only under school instruction | Independent analytics / facial recognition changes the assessment |
| EdTech app | Fiduciary for school deployment | Processor, independent Fiduciary or dual-role, depending on functions | Advertising, analytics, profiling, retention and AI training matter |
| Bus GPS provider | Usually Data Fiduciary | Processor where it follows school instruction | Location reuse, driver-app functions and analytics need review |
Source: DPDP Act, 2023, ss.2, 8 (India Code). See also Data Fiduciary and Data Processor.
Children’s data
Why children’s data changes everything
Most students are children. A child is an individual who has not completed 18 years, and where the individual is a child the Data Principal includes the child’s parent or lawful guardian. Three separate section 9 duties then apply — and they are not the same thing.
↔ Scroll to see school examples.
| Provision | Legal rule | School example |
|---|---|---|
| s.2(f) | A child is under 18 | A 17-year-old Class XII student remains a child |
| s.2(j)(i) | Parent / lawful guardian is included in the child’s Data Principal framework | A parent asks to correct an emergency-contact record |
| s.9(1) | Obtain verifiable parental consent before processing child data, unless a Rule 12 / Fourth Schedule exception applies | Optional EdTech account or public image use |
| s.9(2) | Do not process child data in a way likely to cause a detrimental effect on child well-being | Emotion detection, stigmatising risk scoring, unsafe disclosure |
| s.9(3) | Do not track, behaviourally monitor, or direct targeted advertising at children — except to the extent an applicable prescribed exception disapplies it | GPS, classroom analytics, AI proctoring, child-directed ad-tech |
Detrimental effect on child well-being (s.9(2))
The Act does not define “detrimental effect on the well-being of a child.” A school should not assume that consent alone permits a processing activity that is otherwise likely to harm child well-being. Higher-risk examples include emotion-recognition tools, persistent behavioural scoring, automated disciplinary profiling, public disclosure of counselling/disability/health information, automated labels such as “high risk” or “disruptive,” and intrusive or disproportionate surveillance. A documented child-well-being review before deploying high-risk monitoring, profiling, biometric or AI tools is a recommended risk-control measure — not a prescribed statutory form for ordinary schools.
Tracking, behavioural monitoring and advertising (s.9(3))
Schools should not assume a system avoids section 9(3) merely because it is labelled “student safety,” “learning analytics” or “engagement monitoring.” Activities needing careful assessment include continuous GPS tracking, facial-recognition access, screen monitoring, browser/device activity tracking, attention/emotion/engagement scoring, AI proctoring, student behavioural profiles, classroom-surveillance analytics, and advertising identifiers or cross-platform tracking.
A child-data decision aid
For each processing activity, work down the tree
Children’s data · Consent
Verifiable parental consent (Rule 10)
A phone OTP is not enough on its own. Rule 10 requires appropriate technical and organisational measures to ensure verifiable parental consent, plus due diligence that the person identifying as a parent is an identifiable adult. It contemplates reliable identity/age details the school already holds, voluntarily supplied details, authorised virtual tokens, and DigiLocker-supported verification. It does not require Aadhaar.
↔ Scroll to compare verification routes.
| Verification approach | Contemplated? | Strength | Limitation | Recommended use |
|---|---|---|---|---|
| Authenticated parent account linked to reliable school-held identity/age records | Yes, in substance | Strong for an ongoing relationship | Depends on quality of initial verification | Preferred for routine permissions |
| Verified ERP / parent app | Strongly supported | Good audit trail, scalable withdrawal | Requires secure account design | Core consent channel |
| Mobile OTP alone | No | Confirms control of a number | Does not prove adult identity, parenthood or guardianship | Additional factor only |
| Verified email alone | No | Confirms email control | Does not establish adult identity/relationship | Supporting factor only |
| Signed admission documentation | Not specifically listed | Can evidence a representation | May be broad, stale or unverified | Combine with authentication |
| Government identity documents | Voluntary details contemplated | May help identity/age checks | Overcollection / retention risk | Only when risk justifies; accept alternatives |
| DigiLocker | Expressly contemplated | Strong voluntary route | Not mandatory or universally accessible | Strong option for higher-risk cases |
| Aadhaar authentication | Not required | Only in an authorised Aadhaar-law context | DPDP does not require it | Do not make it a default VPC method |
OTP is not proof of parenthood. A more defensible model is reliable parent/guardian records established at admission, linked to an authenticated account, with OTP or another second factor and a timestamped record of the specific decision. This is an implementation interpretation of Rule 10, not a prescribed “four-factor” statutory test. For divorced parents, shared custody, guardianship disputes, boarding students and children in care, the Act sets no complete protocol — record custody/guardianship orders where supplied, distinguish parent, guardian, emergency contact and fee payer, grant portal access only to those with documented authority, and escalate disputes rather than letting staff decide them.
Source: DPDP Rules, 2025, Rule 10 (MeitY) · Section 9
Children’s data · Exceptions
Rule 12 and the Fourth Schedule: what is (and isn’t) exempt
Conditional, not blanket. Rule 12 and the Fourth Schedule provide specific exceptions from section 9(1) and section 9(3) for identified classes of Data Fiduciaries and identified purposes, subject to the conditions stated in the Schedule. They do not disapply section 9(2), which continues to govern processing likely to cause a detrimental effect on a child’s well-being.
A scope map for schools
May fall within a specific Fourth Schedule exception — if the condition is met
- Tracking / behavioural monitoring genuinely for educational activities (Part A item 3)
- Monitoring in the interests of enrolled-child safety (Part A item 3)
- Transport tracking of an enrolled child during travel to/from school (Part A item 5)
- Real-time location for a child’s safety, protection or security (Part B item 4)
- Creating a student email account, to the extent necessary (Part B item 3)
Not automatically exempt — needs its own s.4/7/9 analysis
- Admissions & ordinary ERP records
- Grades, report cards & attendance registers
- Public / website / social-media photos
- Optional EdTech & add-on services
- AI training on student data
- Biometrics for convenience
- Targeted advertising to children
- Unrelated analytics & profiling
Educational institution (Part A item 3)
Lists an educational institution as a class of Data Fiduciary, conditioned on the tracking/behavioural monitoring being for the institution’s educational activities or in the interests of enrolled-child safety.
May be relevant where the processing actually involves tracking/monitoring, is genuinely connected to education or enrolled-child safety, and the stated condition is met.
Core academic processing is not automatically exempt merely because it supports education. Admissions, ERP, grades, attendance and exams each need their own ss.4/7/9 analysis.
Educational activities
The entry refers to tracking and behavioural monitoring for educational activities.
Document the education-related purpose, functions enabled, child population, data fields, access, necessity and the applicable condition.
“Educational activity” is not a broad label for surveillance, profiling, advertising or product analytics unrelated to the condition.
Safety of enrolled children
The same entry refers to the interests of safety of enrolled children.
Targeted safety-focused monitoring may fall within the entry if the stated condition is actually met.
Not a general licence for unrestricted surveillance, indefinite retention, public sharing or unrelated profiling.
School transport (Part A item 5) & real-time safety (Part B item 4)
Part A item 5 permits a transport provider engaged by the institution to track an enrolled child’s location for safety during travel to/from school. Part B item 4 covers real-time location for a child’s safety, protection or security, limited to that purpose.
Live bus location during genuine school travel, and narrowly designed emergency-location workflows, may be supportable when confined to student safety.
No automatic justification for tracking after drop-off, all-day tracking, private-travel tracking, marketing, disciplinary profiling, or broad location histories and dashboards.
School email accounts (Part B item 3)
Covers creation of a user account for communication by email, limited to what is necessary for that account.
Creating a school-controlled student email account may be within this purpose-specific exception.
It does not authorise unrelated platform add-ons, behavioural analytics, AI tools, advertising settings, external apps or indefinite retention.
Sources: DPDP Act, 2023, s.9 · DPDP Rules, 2025, Rule 12 & Fourth Schedule
Not sure which of your systems fall inside an exception?
Most schools discover the gaps fastest by inventorying systems first, then testing each child-data workflow against the exact Rule 12 condition. The readiness check below gives you a starting map.
School operations
DPDP Act compliance in admissions
Admissions is the highest-volume child-data workflow. DPDP does not declare any field automatically unlawful. The questions are whether the data is processed for a lawful purpose (s.4), whether any consent is valid and purpose-specific (s.6), whether a child-data condition applies (s.9), whether notice is given, and whether security/retention duties are met. Map each field to a stated purpose and restrict access to staff who need it.
↔ Scroll to see the DPDP concern and recommended action.
| Field | Typical purpose | Always necessary? | DPDP concern | Recommended action |
|---|---|---|---|---|
| Student name | Identify applicant | Usually yes | Accuracy & identity matching | Required field with a correction process |
| Date of birth | Age eligibility / placement | Usually yes | Accuracy & document security | Collect with a stated purpose |
| Photograph | ID, security, application record | Not always at enquiry | Public reuse is a separate purpose | Separate internal ID use from publicity |
| Aadhaar | Sometimes sought for a separate govt/board process | Not for ordinary admission | Cannot be compulsory for ordinary admission | Offer alternatives; collect only for a verified separate purpose |
| Parent income | Scholarship / fee concession | Not always | Financial privacy & excess collection | Collect only for aid/concession assessment |
| Religion | Limited institutional/statutory context | Not always | High sensitivity & discrimination risk | Do not collect unless genuinely required and documented |
| Caste / category | Reservation, scholarship, reporting | Not always | Misuse / discrimination / access risk | Collect only for the applicable purpose; segregate access |
| Disability information | Accessibility & accommodation | Not always at enquiry | Harm from disclosure | Collect only relevant support info; restrict access |
| Medical history | Allergies, medication, safety | Not a full history | Excessive collection / disclosure | Request only necessary safety-related details |
| Previous-school records | Placement, transfer verification | Often for transfer | Excessive historical disciplinary/counselling data | Define required documents; avoid unlimited uploads |
Recommended admission controls: separate mandatory eligibility fields from optional scholarship/transport/publicity fields; do not treat a broad admission signature as universal permission for social media, EdTech, biometrics, AI or marketing; build a parent/guardian authentication workflow before enabling child digital accounts where s.9(1) applies; restrict document access; do not make Aadhaar the only identity route; define retention for incomplete and unsuccessful applications; and keep a data inventory showing which vendor receives each admissions-data category.
School operations · Consent
School consent architecture
Different activities carry different consent and child-data implications. Do not bundle a publicity or optional-service permission into a core admission or academic workflow — separate the optional from the essential, and record what withdrawal means for each.
↔ Scroll to see grounds, withdrawal and classification.
| Activity | Consent / VPC issue | Possible ground / exception | Withdrawal consequence | Class |
|---|---|---|---|---|
| Admission application | Child data; s.9(1) may apply unless an exception applies | Consent; s.7(a) may be relevant to voluntarily supplied data but does not remove s.9 analysis | Essential-information withdrawal may prevent progressing | Interpretation |
| Core academic records | Ordinary processing needs its own s.4/7/9 analysis | Do not assume Rule 12 Part A item 3 applies just because it supports education | May affect service; statutory/board retention may continue | Interpretation |
| Examinations | Student data + possible board disclosure | s.7(d) where disclosure is legally required; verify board/state requirement | Board process may be affected | Interp / Verify |
| School ID photo | Child image processing | Requires specific workflow analysis; no blanket exception | Consider an alternative ID method where practical | Practice / Interp |
| Website / social-media photo | Public child-data disclosure + platform processing | No automatic educational exception | Stop future use; remove school-controlled content | Practice |
| CCTV | Child monitoring / security | Rule 12 Part A item 3 only where actual monitoring meets the condition | Withdrawal may not be workable where a justified safety deployment continues | Interpretation |
| Bus GPS | Child location | Part A item 5; Part B item 4 in applicable safety contexts | Alternative transport arrangement may be needed | Law / Interp |
| Biometrics | Child data + monitoring/security risk | Feature-level analysis; do not assume a tracking exception applies | Consider a lower-risk method where practical | Interp / Practice |
| Student email account | Child digital-account processing | Part B item 3 may apply to account creation only, to the necessary extent | Disable optional services where appropriate | Law / Interp |
| Optional EdTech | Child data, vendor role, tracking/ad risk | No general school exception | Disable account/data flow if withdrawal applies | Interpretation |
| AI tools | Child data, profiling, well-being & training risk | No general exception | Use a non-AI alternative where feasible | Practice / Interp |
School operations · Transparency
School privacy notices
Sections 5–6 don’t create a named notice for every workflow. The section 5 notice obligation is tied to a request for consent under section 6. Where processing relies on another route (e.g. a relevant section 7 certain legitimate use), section 5 does not automatically create a separate named notice. Layered notices remain a strong transparency practice because they help schools explain processing clearly.
Section 5 requires a consent request to be accompanied or preceded by notice identifying the personal data and purpose, how to exercise rights, and how to complain to the Board. Rule 3 requires clear, plain-language, itemised notice with links for withdrawal, rights and Board complaint. Section 5(3) gives the Data Principal the option to access notice contents in English or any Eighth Schedule language; section 6(3) does the same for a consent request. The Act does not require every school to publish every notice in all 22 languages.
Recommended layered-notice structure
| Notice | Legal status | What it should cover |
|---|---|---|
| Admissions | Required where consent is requested under Sections 5–6; otherwise useful as a broader transparency control | Applicant/student/parent data, documents, purpose, systems, retention, rights, contact |
| Parent / student | Required for relevant consent-based processing; broader layered transparency is recommended practice | Academic administration, attendance, communication, safety, systems, rights |
| Website | Required where website processing seeks consent; otherwise assess the applicable route and transparency needs | Forms, analytics, chatbots, newsletters, payments, contact channels |
| Employee | Required where employee processing relies on consent; broader transparency recommended, including for s.7(i) processing | Recruitment, payroll, attendance, CCTV, HR records, grievance route |
| CCTV | Recommended transparency control unless a consent workflow creates a direct s.5 obligation | Coverage, purpose, access, retention approach, contact |
| Transport / GPS | Recommended transparency control unless a consent workflow creates a direct s.5 obligation | GPS purpose, access, safety limitation, vendor, retention |
| Photo / media | Often appropriate where consent is the route; separate treatment recommended for public/media use | Internal records, yearbook, website, social media, videos, withdrawal |
| Alumni | Depends on the route; generally recommended as a transparency control | Contact use, ongoing communications, preference/withdrawal route |
Sources: Section 5 (notice) · Section 6 (consent) · DPDP Rules, 2025, Rule 3 · Notice
School operations · Rights
Student and parent rights
The Act provides rights of access, correction/completion/updating, erasure, grievance redressal and nomination. Rule 14 requires a school to prominently publish how to make rights requests and a reasonable grievance-redressal period that does not exceed 90 days.
| Right | School scenario | School response |
|---|---|---|
| Access | Parent asks what data is held about a 12-year-old | Verify authority; provide the required summary securely |
| Correction | Correct contact details or allergy information | Update systems and confirm completion |
| Completion | Add emergency-contact or medical instruction | Verify authority and add necessary information |
| Updating | Update custody, pickup or communications info | Update controls; alert authorised functions |
| Erasure | Delete a former student’s optional EdTech account | Erase unless retention remains necessary for a purpose or law |
| Grievance | Marks sent to the wrong WhatsApp group | Investigate, mitigate, respond and assess breach duties |
| Nomination | Adult alumnus nominates another person | Provide a documented process and verify details |
School operations · Staff
Employee and teacher data
Analyse employee data separately from student child data. Section 7(i) permits processing for employment purposes and for safeguarding the employer from loss or liability in specified contexts — but it is not a blanket basis for unlimited surveillance, unrelated marketing or disclosure unrelated to employment.
| Activity | DPDP analysis | School action |
|---|---|---|
| Recruitment | Candidate data processed for recruitment | Provide applicant notice; set unsuccessful-candidate retention |
| Payroll | Employment & statutory-compliance processing | Restrict HR/finance access; retain as law requires |
| Attendance | Employment purpose may be relevant | Assess biometrics separately |
| CCTV | Security & employment-monitoring issues | Give transparency; limit scope |
| Health information | High practical risk | Collect only for safety, accommodation or legal requirement |
| Disciplinary data | Harm if misused | Limit access; set retention |
Source: Section 7 (certain legitimate uses)
School operations · Web
School website compliance
Be cautious about advertising pixels and behavioural advertising on child-facing or admissions pages. The restriction on targeted advertising directed at children should not be assumed displaced by the educational-institution exception.
| Component | DPDP issue | Practical control |
|---|---|---|
| Enquiry form | Digital personal-data collection | Clear just-in-time notice; minimum fields |
| Admission form | Child data / documents / parent workflow | Secure portal, restricted access, field review |
| Google Analytics | May involve identifiable online data in context | Document purpose; configure proportionately |
| Meta Pixel | Advertising / profiling risk, esp. on child/admissions pages | Avoid or carefully assess before deployment |
| Cookies | DPDP does not replicate EU cookie-law architecture | Assess the actual processing rather than copy EU claims |
| Chatbot | Users may disclose student/parent data | Limit data capture; define vendor retention |
| Student photos | Child / publicity processing | Separate media permission; takedown workflow |
| Payment integration | Parent payment data / third-party role | Provide notice; review payment-provider terms |
Technology
What applies to a specific school technology?
Each technology raises a slightly different combination of issues. Pick a system to see the main DPDP issue, the relevant law, whether Rule 12 is even in play, the common mistake, and a sensible first action. (Every panel is also printed in full below.)
CCTV
Identifiable footage of children; intrusion rises from gates to classrooms to counselling rooms.
ss.4/8/9 security & child-data duties; no blanket prohibition and no fixed retention period in DPDP.
Part A item 3 safety condition may be relevant only where the actual monitoring meets it.
Assuming “security” justifies cameras everywhere, plus a copied “30-day rule.”
Map camera locations & purposes; remove cameras from toilets/changing/counselling spaces; document a proportionate retention approach.
Bus GPS
Continuous child location data and who can see it.
s.9(3) tracking restriction, disapplied only by an applicable exception.
Part A item 5 (transport) and Part B item 4 (real-time safety) — purpose-limited to travel/safety.
All-day tracking, indefinite history, live links shared to open groups.
Limit tracking to the journey window; restrict access & history; disable tracking after drop-off.
Biometrics & facial recognition
Persistent child identifiers, monitoring risk and vendor storage.
s.9(1) VPC unless a valid exception applies; s.9(2) well-being; s.8(5)/Rule 6 security. No GDPR-style “sensitive data” label.
No automatic exception — assess the specific feature.
Adopting fingerprint/face attendance for convenience.
Run a necessity, feature, child-impact and vendor-risk assessment; offer a lower-risk alternative where practical.
EdTech & vendors
Vendor role, tracking/advertising and AI-training terms on child data.
School responsible for processing on its behalf; valid processor contract; s.8(5)/Rule 6 security; s.8(7) erasure.
No general school exception for optional EdTech.
Treating any paid SaaS as a Processor and certifying it “DPDP compliant.”
Build an approved-tool register; classify each vendor’s role; disable child-directed advertising and unnecessary analytics.
AI tools
Pasting identifiable student data into external systems; profiling and well-being effects.
DPDP applies wherever an AI system processes personal data; ss.4–9, esp. s.9(2)/9(3).
No general exception; verify whether s.9(1) VPC is required.
Teachers using consumer AI with identifiable report cards or counselling notes.
Publish an AI-use policy; approve tools; require de-identification or non-AI alternatives for identifiable child data.
Disclosure of child-related data and phone-number visibility in groups.
No WhatsApp-specific prohibition; general processing, security and child-data duties apply.
Not a Rule 12 question — a channel-control question.
Sending marks, medical, discipline, fee or live-location details to open groups.
Use official managed accounts / broadcast tools; keep individual records off open groups; publish a staff messaging policy.
Foreign cloud & workspace
Configuration, child accounts, analytics/AI settings and cross-border processing.
No general localisation; s.16 / Rule 15 permit future transfer restrictions; other laws may add protection.
Not a Rule 12 question — a role & transfer question.
Believing DPDP bans Google Classroom or foreign cloud, or that a vendor is generically “compliant.”
Document the role, configuration, child accounts, analytics/AI settings, hosting/support locations and contract terms.
Can schools use CCTV?
No blanket prohibition — but no blanket permission either. Whether a deployment is compliant depends on purpose, child-data implications, applicable Rule 12 / Fourth Schedule conditions, security, access, transparency, retention and other applicable law. DPDP does not prescribe a universal 30-day school-CCTV retention period.
↔ Scroll to see risk and recommended control.
| Location / use | DPDP issue | Rule 12 relevance | Risk | Recommended control |
|---|---|---|---|---|
| Gates & entrances | Visitor/student security; identifiable footage | Safety condition may be relevant | Medium | Document purpose; restrict access; justified retention |
| Corridors | Broad observation of movement | May involve monitoring; assess Part A item 3 condition | Med/High | Avoid unnecessary analytic features |
| Playground | Safety & activity monitoring | Safety condition may be relevant | Medium | Limit viewing and public sharing |
| Classroom | Higher intrusion; behavioural-monitoring risk | No automatic exemption | High | Only for a defined need; no continuous remote observation |
| School buses | Child safety and location/video | Transport/safety entries may be relevant | High | Restrict live access and video export |
| Counselling rooms | Intrusive and potentially harmful | Do not assume any exception | Critical | Avoid routine CCTV/audio monitoring |
| Toilets / changing rooms | Severe dignity/safety/well-being risk | No ordinary safety justification | Critical | Do not install cameras |
| Facial-recognition CCTV | Biometric identification + monitoring | Requires feature-level assessment | Critical | Do not deploy for convenience; seek specialist review |
Adopt a documented, proportionate retention approach linked to safety, incident investigation, claims and legal-hold requirements. Signage, role-based access, export restrictions, audit logs and limited viewing are advisable privacy and security controls — not all expressed as school-specific DPDP commands.
School bus GPS and student tracking
Fourth Schedule Part A item 5 addresses a transport provider engaged by the institution, allowing tracking of enrolled children’s location for safety during travel to or from school. Part B item 4 separately addresses real-time location for a child’s safety, protection or security, limited to that purpose. The exception is purpose-limited — “student safety” is not a generic licence for continuous surveillance.
Good design
- GPS operates only during defined transport journeys
- Access limited to transport managers, safety staff & authorised parents
- Parents see necessary live route info, not unrestricted history
- Location history kept only for a documented safety/incident period
- Vendor terms prohibit unrelated analytics, advertising or reuse
- Tracking after drop-off is disabled unless a genuine safety scenario requires it
High-risk design
- Tracking students all day or after normal school travel
- Letting all parents/staff view every child’s live location
- Retaining location history indefinitely
- Inferring conduct or family habits from location
- Selling, profiling or marketing based on location
- Sending live-location links/screenshots into open WhatsApp groups
Biometrics and facial recognition
No blanket ban, but not low-risk. DPDP contains no blanket prohibition on fingerprints, facial templates or iris scans, and no GDPR-style special-category classification. That does not make biometric processing low risk: it can raise child-data processing, s.9(1) VPC (unless a valid exception applies), tracking/monitoring, s.9(2) well-being, persistent-identifier security, vendor reuse, and retention/deletion issues.
| Technology | Main concern | Recommended approach |
|---|---|---|
| Fingerprint attendance | Persistent identifier, vendor storage, monitoring | Do not use solely for convenience without a documented operational need |
| Facial-recognition attendance | Biometric identification + surveillance/tracking | Treat as high risk; assess specific features |
| Iris scan | High-impact identifier | Use only where clearly justified and strongly controlled |
| Biometric access control | Security aim, but individual monitoring may result | Limit access, retention and secondary use |
| AI facial analytics | Profiling, monitoring, emotion/behaviour inference | Avoid without specialist legal, technical & well-being review |
Providing a manual, RFID-card or supervised attendance alternative is a prudent proportionality control where practical. DPDP does not expressly impose a universal alternative-method requirement.
EdTech and vendor compliance
Outsourcing does not outsource responsibility. A school remains responsible for processing done on its behalf by a Data Processor, who may be engaged only under a valid contract. Rule 6 requires appropriate contractual security provisions between Fiduciary and Processor. But no vendor should be certified in generic terms as “DPDP compliant” — it depends on your configuration, enabled functions, child accounts, tracking/advertising settings, AI-training terms, retention, export ability, contractual role and hosting.
The same supplier can sit in different roles
it stores/processes records only under school instruction (e.g. ERP hosting, LMS delivery, school-directed CCTV).
it decides its own purposes — cross-customer analytics, benchmarking, marketing, product development, settlement/fraud/KYC.
it does both — e.g. a workspace provider running the contracted service and independent telemetry/service-improvement processing.
- What exact service purpose is performed, and who determines purpose and means?
- Are children involved, and does the vendor track/monitor behaviour or serve ads?
- Is data used for AI training, and where is it hosted / accessed?
- What happens to the data on termination, and can the vendor support rights requests?
Vendor assessment questions
↔ Scroll to see DPDP basis and evidence to obtain.
| Question | Why it matters | DPDP basis | Evidence to obtain |
|---|---|---|---|
| What exact service purpose is performed? | Scope, notice & necessity | ss.4–6 | Data-flow description & configuration record |
| Who determines purpose and means? | Processor vs independent Fiduciary | ss.2(i), 2(k) | Contract, privacy terms, product docs |
| Are children involved? | Triggers s.9 assessment | s.9 | User-age / account configuration |
| What safeguards are used? | Reasonable safeguards duty | s.8(5), Rule 6 | Security architecture; access/log/backup evidence |
| Are subprocessors used? | Extends data flow & risk | s.8 responsibility | Subprocessor list; hosting/support locations |
| Data hosted/accessed outside India? | Transfer monitoring | s.16, Rule 15 | Hosting, backup & support-access map |
| Does the vendor track/monitor behaviour? | s.9(3) risk | s.9, Rule 12 | Feature inventory & analytics settings |
| Ads served / profiles for marketing? | Targeted-advertising risk for children | s.9(3) | Product settings & contractual warranty |
| Is data used for AI training? | Secondary-use & well-being risk | ss.4–9 | Written term & technical configuration |
| How long is data retained; what at termination? | Erasure / stranded records | s.8(7) | Retention/deletion schedule; export/deletion docs |
| How are incidents escalated; rights supported? | Notify without delay; handle rights | Rule 7; ss.11–14 | Incident clause, contacts; rights-assistance process |
Valid processor contract where the supplier is a Processor; school responsibility for processing on its behalf; reasonable security safeguards; appropriate contractual security provisions; erasure under s.8(7), including causing Processors to erase.
24-hour incident escalation; prior written subprocessor approval; ISO 27001 / SOC 2 assurance; penetration-testing evidence; audit rights; defined deletion targets; express AI model-training restrictions. Commercially sensible — but not all are DPDP-mandated clauses.
Foreign cloud platforms
Permitted in principle. Schools may use Google Workspace, Microsoft 365 and foreign EdTech in principle; DPDP imposes no general localisation rule for ordinary schools. Section 16 lets the Central Government restrict transfers to a notified country; Rule 15 permits transfer subject to future requirements. Other Indian laws may add protection for particular data or sectors.
As of the research cut-off, no school-specific transfer restriction, foreign-country block list or universal education-data localisation requirement was identified in the reviewed primary material. Recheck before procurement and periodically. No vendor should be certified generically as “DPDP compliant” — the analysis depends on your actual configuration, enabled functions, child accounts, analytics/advertising settings, AI-training terms, retention, export ability, contractual role and hosting/support locations. s.16
WhatsApp and school communications
Not banned — but not for sensitive records. DPDP does not prohibit WhatsApp, and contains no WhatsApp-specific rule. School-controlled use can still involve child-data disclosure and security risk, so keep sensitive records off open groups.
Lower-risk uses
- General closure notices & uniform reminders
- Event timing & broad announcements
- Emergency broadcasts via a controlled school account
- Links directing parents to a secure portal
High-risk uses
- Individual marks, report cards or rankings
- Medical, allergy, medication or counselling details
- Disciplinary records & fee-default details
- Student live location, bus route or GPS links
- Photos without separate media permission; ID docs in groups
Prefer parent apps, SMS, email, secure portals or broadcast tools where parents need not see each other’s numbers; maintain a staff messaging policy; provide an alternative channel for parents who do not use WhatsApp; and train staff not to treat a WhatsApp “yes” as a substitute for verifiable parental consent.
AI use in schools
No separate “AI regime” — DPDP just applies. DPDP has no dedicated AI-in-schools regime; it applies wherever an AI system processes digital personal data. When a teacher pastes an identifiable report card, behavioural report, accommodation plan, counselling note or student essay into an external AI system, the school may be disclosing personal data to another entity — and must check the provider’s role, data use, training terms, retention, hosting, security, child-data implications and any s.9(2) harm.
Higher-risk uses include generative AI tools (ChatGPT, Gemini, Copilot), AI tutoring, automated grading, essay assessment, AI proctoring, student-risk scoring, behavioural analytics, facial/emotion/attention recognition, AI-generated disciplinary flags, and tools that use uploaded student work for model training.
AI decision logic — can this student information go into this AI system?
- Is the information personal data, or can the student reasonably be identified from it?
- Is the individual under 18?
- Is the AI tool approved by the school?
- Has the school identified the provider’s role and relevant terms?
- Does the contract/configuration prevent use for training, advertising, profiling or unrelated development?
- Is the use tied to a defined educational or administrative purpose?
- Does it involve tracking, behavioural monitoring, emotion recognition, profiling or a decision affecting the student?
- Has the school assessed potential detrimental effect on child well-being (s.9(2))?
- Does a Rule 12 exception clearly apply, or does s.9(1) require VPC?
- Can the task be done with de-identified information, or without an AI tool at all?
If the school cannot answer these reliably, identifiable student information should not be entered into that AI service.
Regulatory
Aadhaar and APAAR
Aadhaar cannot be compulsory for ordinary admission. The Supreme Court held that Aadhaar cannot be made mandatory for school admission, because admission is not a subsidy, benefit or service within the relevant Aadhaar Act provision. Rule 10 does not require Aadhaar for verifiable parental consent, and a school should not design a parent-verification workflow that makes Aadhaar the only option.
Distinguish the Aadhaar number, an Aadhaar photocopy, Aadhaar authentication, voluntary Aadhaar use, alternative identity/age documents, and a separate board/exam/welfare/government-scheme requirement. A government scholarship or welfare scheme may create its own identification obligations under its own framework — verify the precise scheme, authority, data fields, alternatives and legal source rather than generalising.
APAAR, CBSE registration/LOC and DigiLocker
APAAR is a distinct government education identity workflow: the official APAAR process describes parents submitting consent voluntarily for APAAR ID creation, and identifies parental consent as a step for minors. It should not be treated as proof that Aadhaar is mandatory for ordinary admission. CBSE’s 2025 materials addressed linking APAAR ID to registration/LOC data; the 11 September 2025 partial-relaxation material stated that where APAAR ID was not generated because parents did not consent, schools should record the denial and enter “REFUSED” in the LOC, and enter “NOGEN” where non-generation occurred for other reasons.
Sources: Supreme Court, Aadhaar judgment (2018) · APAAR portal · CBSE examination circulars
Regulatory · Retention
Data retention and deletion
No single universal DPDP retention period. Section 8(7) requires a Data Fiduciary — unless retention is necessary for legal compliance — to erase personal data when consent is withdrawn or as soon as it is reasonable to assume the purpose is no longer served, whichever is earlier, and to cause its Processor to erase too. Beyond that, schools must separately verify board, state-education, tax, accounting, employment, safeguarding, court, audit, insurance and limitation requirements.
↔ Scroll to see other retention sources and approach.
| Record type | DPDP position | Other retention source | Uniform India-wide period? | Recommended approach |
|---|---|---|---|---|
| Rejected applications | Delete when purpose ends unless another legal reason applies | Dispute/appeal policy; state rules | No | Defined admissions-cycle/appeal retention; delete securely |
| Student academic records | Retain while purpose/legal need continues | Board/state/transfer verification | No single confirmed period | Preserve minimum authenticated record; reduce ancillary data |
| Attendance | Retain only while purpose/obligation continues | CBSE/CISCE/state rules | No | Verify board/state rule; use a documented period |
| CISCE answer scripts | Specific CISCE retention rule | CISCE regulations | Yes (CISCE): not retained later than 60 days after result declaration | Do not generalise to all school records |
| CISCE assessed assignments | Specific CISCE rule | CISCE regulations | Yes (ICSE/ISC): school retains 60 days after result declaration | Preserve only for that period unless another lawful need |
| CCTV footage | No universal DPDP period | Local/sector/state policy | No | Short rolling retention; preserve incident footage under legal hold |
| GPS records | No universal DPDP period | Transport/safety/local rules | No | Retain only for operational safety/complaint period |
| Medical / counselling | Keep only for safety, care & lawful need | Policy, insurance, safeguarding | No | Review routinely; tightly restrict access |
| Fee / accounting | DPDP erasure subject to other law | Tax / accounting law | Varies | Separate finance retention from student-profile retention |
| Employee records | DPDP erasure subject to other law | Payroll / tax / employment law | Varies | HR retention schedule by record type |
| Safeguarding / POCSO | Do not erase where legal/court/safeguarding retention applies | POCSO / child-protection / law-enforcement | No simple period | Seek legal advice; restricted access / legal hold |
CISCE regulations provide a verified example of board-specific rules: CISCE does not retain answer scripts later than 60 days after declaration of results, and schools retain assessed ICSE/ISC assignments for 60 days after result declaration. Separately, Rule 8(3) requires retention of personal data, associated traffic data and processing logs for at least one year for the Seventh Schedule purposes, subject to longer applicable-law retention — assess its scope carefully for each school system.
Sources: Section 8(7) · CISCE Regulations · DPDP Rules, 2025, Rule 8(3)
Regulatory · Incidents
Data breaches
“72 hours” is not a grace period before you notify. A breach includes unauthorised processing, accidental disclosure, acquisition, alteration, destruction or loss of access. Under Rule 7, affected people and the Board must be notified without delay after awareness; a detailed update to the Board follows within 72 hours (or longer if the Board allows). The 72-hour window governs the detailed update — not initial notification.
Ransomware, an unavailable ERP, a lost laptop, an exposed Drive link, wrongly shared report cards, leaked CCTV or transport-location exposure can all require breach assessment.
School breach-response sequence (once Rule 7 is in force)
1 · Detect
Record discovery time, source, affected systems, data and immediate risk.
2 · Contain
Disable exposed links/accounts, reset credentials, revoke sessions, isolate systems, suspend compromised vendor access.
3 · Assess & escalate
Identify affected individuals, data categories, vendor involvement and impact; notify principal, management, IT/security, privacy owner, legal, insurer and vendor.
4 · Notify affected people WITHOUT DELAY
Provide the required notice to affected Data Principals once Rule 7 applies.
5 · Initial Board notice WITHOUT DELAY
Notify the Board with the breach details available.
6 · Detailed Board update WITHIN 72 HOURS
Updated facts, circumstances, mitigation, responsible-person findings, remedial measures and an affected-person-notification report — unless the Board extends.
7 · Remediate & preserve
Restore systems, patch causes, correct vendor controls, support affected individuals, and preserve logs, notices, timeline and evidence.
Regulatory · Security
Reasonable security safeguards
Section 8(5) requires reasonable security safeguards. Rule 6 specifies appropriate technical and organisational measures — including encryption/obfuscation/masking or virtual tokens; access controls; visibility through logs/monitoring/review; continuity measures including backups; one-year log retention; processor-contract security provisions; and measures to ensure effective observance. DPDP does not expressly require every school to use MFA, hold ISO 27001, encrypt every field or run annual penetration tests — those are risk-based choices; the statutory standard is reasonable safeguards and appropriate Rule 6 measures.
| School control | DPDP connection | Classification |
|---|---|---|
| MFA for ERP, cloud, email & admin | Supports safeguards / access controls | Recommended practice |
| Role-based access | Rule 6 access controls | Recommended practice |
| Encryption / masking / tokenisation | Rule 6 provides examples | Statutory category |
| Logs & periodic review | Rule 6 includes logs/monitoring/review | Statutory category |
| Backups & restoration testing | Rule 6 includes continuity/backups | Statutory category |
| Prompt removal of departed access | Access control & breach prevention | Recommended practice |
| Incident-response plan & tabletop | Breach readiness | Recommended practice |
| Vendor-access register | Processor oversight | Recommended practice |
Sources: Section 8(5) · DPDP Rules, 2025, Rule 6
Regulatory · Public sector
Government schools
Government schools are not automatically exempt merely because they are government-run. They may process data as State instrumentalities, and sections 7 and 17 can affect particular activities. Section 17 contains specific exemptions/modifications — for example, s.17(4) modifies s.8(7) and s.12(3) for processing by the State or its instrumentalities, and modifies s.12(2) where the purpose does not include a decision affecting the Data Principal. It does not create a universal government-school exemption. Government-school systems should identify the relevant public authority, map each statutory function, verify any s.7 ground, and determine whether a specific s.17 exemption or actual notification applies. s.17
Regulatory · Governance
Does every school need a DPO?
No. A statutory DPO is an additional obligation for a Significant Data Fiduciary (SDF). SDF status requires Central Government notification based on statutory factors — volume and sensitivity of data, risk to rights, sovereignty, electoral democracy, State security and public order. Children’s-data processing alone does not automatically make a school an SDF, and no official notification identifying schools as SDFs was located in the source review for this guide.
If notified as an SDF, an organisation must appoint an India-based DPO and an independent data auditor, and conduct periodic DPIAs and audits; Rule 13 requires a DPIA and audit once every 12-month period from notification. Ordinary schools should still publish the business contact details of a DPO where applicable — or another person able to answer processing queries — and maintain an effective grievance mechanism.
Weighing whether to appoint or outsource a privacy lead?
Most mid-sized schools do not need a statutory DPO, but every school needs a named, published privacy contact and a working grievance route. If you want help scoping that role, DPOIndia works with schools on exactly this.
Regulatory · Penalties
Penalties
These are maximum statutory ceilings, not automatic fines. Under section 33, the Board must consider the nature, gravity and duration of non-compliance; the data affected; repetitive nature; gain/loss avoided; mitigation; proportionality; and the likely impact of the penalty.
↔ Scroll to see Schedule item and school example.
| Contravention | Maximum | Schedule item | School example |
|---|---|---|---|
| Failure to take reasonable security safeguards (s.8(5)) | ₹250 crore | Item 1 | Poorly secured cloud drive, ERP or admin account exposes student records |
| Failure to notify a breach to the Board / affected people (s.8(6)) | ₹200 crore | Item 2 | Report-card, CCTV or GPS leak is not notified as required |
| Failure to observe additional children’s-data obligations (s.9) | ₹200 crore | Item 3 | Unlawful child tracking, monitoring, targeted advertising or child-data failure |
| Failure to observe SDF obligations (s.10) | ₹150 crore | Item 4 | Relevant only if the school/group is actually notified as an SDF |
| Breach of any other provision (no separate item) | ₹50 crore | Item 7 | Notice, rights, contact or processor-related obligation not otherwise specified |
Source: DPDP Act, 2023, s.33 & the Schedule (India Code)
Implementation
The 15 highest-priority risks
If time is short, these are the exposures that most often turn into incidents, complaints or penalty-relevant failures. Severity reflects likely impact and sensitivity, not a statutory grade.
Public or over-shared ERP, cloud-drive or spreadsheet records
CriticalFirst action: Audit permissions, links and admin access; remove public access.
Unapproved EdTech & AI tools used by teachers
CriticalFirst action: Create an approved-tool process; stop identifiable-data uploads to unapproved services.
Child behavioural analytics, emotion recognition or AI profiling
CriticalFirst action: Freeze and assess systems; disable high-risk functions.
Bus GPS / live location exposed beyond safety purpose
CriticalFirst action: Restrict tracking window, access and history.
Ad-supported or targeted-advertising EdTech
CriticalFirst action: Remove child-targeted advertising and behavioural ad-tech.
No parent/guardian verification & consent evidence
CriticalFirst action: Build a parent-account and consent-record process where s.9(1) applies.
Aadhaar demanded as a universal admission document
HighFirst action: Remove mandatory treatment and accept alternatives.
Social-media photos posted without separate permission
HighFirst action: Use a dedicated media-permission and takedown workflow.
Biometric / facial attendance used for convenience
HighFirst action: Conduct necessity, feature, child-impact and vendor-risk assessment.
Sensitive records shared in WhatsApp groups
HighFirst action: Move marks, medical and discipline records to secure channels.
Vendor contracts lack security / deletion / incident support
HighFirst action: Prioritise ERP, LMS, cloud, GPS, CCTV, payment and AI suppliers.
No rights / grievance workflow
HighFirst action: Establish secure request intake, verification, tracker and response.
Indefinite retention of rejected applications & dormant accounts
HighFirst action: Apply a retention schedule and deletion workflow.
Shared passwords & former-staff access
HighFirst action: Adopt MFA, offboarding and access reviews.
No breach-response process
Medium/HighFirst action: Create a Rule 7 playbook, contacts and notification templates.
School DPDP readiness check
Answer 13 quick questions for an indicative readiness band across the areas that matter most before 13 May 2027. Everything runs in your browser — nothing is sent anywhere.
How ready is your school?
Yes = 2, Partly = 1, No = 0. This is an operational readiness indicator, not a legal opinion or certification.
This readiness check is a general operational indicator based on your self-assessment. It is not a legal opinion, an audit or a certification, and it does not transmit or store your answers.
Implementation roadmap to 13 May 2027
A workable sequence for the window before the core provisions commence. Adjust to your entity structure, board obligations and technology stack.
Five phases: discover → design → implement → test → validate
- Appoint sponsor & privacy lead
- Identify operating entity/entities
- Create data inventory & child-data register
- Map suppliers & contracts
- Audit cloud drives & public links
- Freeze high-risk new deployments
- Draft governance structure
- Design notices & VPC workflow
- Create Rule 12 exception register
- Build vendor questionnaire
- Draft processor addendum
- Design rights/grievance workflow & retention schedule
- Configure parent portal & consent records
- Update ERP/LMS/cloud roles
- Amend high-risk vendor contracts
- Implement EdTech/AI approval process
- Publish notices & privacy contact
- Train staff; establish breach plan
- Run breach tabletop
- Test rights/withdrawal process
- Test vendor incident escalation
- Audit website/social media & WhatsApp
- Test access deprovisioning
- Validate Rule 12 conditions
- Management readiness review
- Confirm critical systems mapped
- Confirm high-risk vendors assessed
- Confirm notices/rights channels live
- Confirm breach process & deletion workflow
- Document residual gaps with a time-bound plan
School DPDP readiness checklist
A grouped checklist you can work through with IT, admissions, academics, HR, finance, transport and communications.
Governance & data inventory
- Operating legal entity is identified; a management-level privacy owner is named; a privacy contact is published
- Responsibilities assigned across admissions, IT, academics, HR, finance, transport and communications
- Student, parent and employee systems, cloud drives, spreadsheets and shadow IT are mapped
- CCTV, GPS, biometrics and access-control systems, and paper-to-digital workflows, are included
- Data recipients and vendors are identified
Admissions
- Every admission-form field has a documented purpose
- Aadhaar is not the only admission identity route
- Optional fields are separated from mandatory eligibility fields
- Rejected-application retention is defined; document upload and staff access are controlled
Children’s data & verifiable parental consent
- Under-18 data flows are identified; s.9(2) well-being risks assessed
- Tracking, behavioural monitoring and advertising features are identified
- Rule 12 / Fourth Schedule exceptions recorded only where actual conditions are met
- Parent/guardian verification exists; parent accounts are authenticated
- Consent records identify purpose, notice version, date/time and verification route; OTP is not treated as standalone proof; custody/guardianship escalation exists
Notices & transparency
- Consent-based workflows use a Section 5/6-compliant notice before or with the request
- Layered admissions, parent/student, employee and website transparency material is maintained where useful
- CCTV, transport/GPS and media transparency material is available where relevant
- Data Principals can access notice/consent requests in English or an Eighth Schedule language where required
Vendors, EdTech & AI
- Material Processor relationships are contract-backed with appropriate security provisions
- Each vendor role is classified as Processor, independent Fiduciary or dual role; incident contacts documented
- Approved EdTech register exists; tracking/analytics features assessed; child-directed advertising disabled
- AI training/data-use terms reviewed; teachers do not use unapproved apps with identifiable student data; AI-use policy exists
CCTV, GPS & biometrics
- Camera locations/purposes mapped; none in toilets, changing rooms or counselling spaces; access/export restricted; retention documented
- GPS tracking limited to safety/travel; off-hours tracking disabled; parent access controlled; history limited
- Fingerprint/face/iris processing inventoried; features assessed; security/deletion documented; lower-risk alternatives considered
Security & breach response
- MFA protects ERP, cloud email, storage and admin accounts; access is role-based; departed access removed promptly
- Logs and backup arrangements exist; public links/shared-drive access reviewed
- Access/correction/erasure channel with identity verification; published grievance period ≤ 90 days
- Rule 7 breach templates prepared; CERT-In assessment process exists; breach tabletop completed
Retention, employees, website & training
- Record-by-record retention schedule with legal sources; rejected applications deleted; dormant accounts closed; vendor deletion documented
- Employee data notice available; HR retention schedule exists
- Website forms/analytics reviewed; Meta Pixel/ad-tech assessed; WhatsApp policy exists
- Training records maintained; annual review calendar established
Myth vs fact
“DPDP is already fully operational for schools.”
Core ordinary-school obligations commence on 13 May 2027.
“Schools need consent for everything.”
The Act provides consent and certain legitimate uses; children’s rules and Rule 12 require workflow-specific analysis.
“Education automatically creates a blanket child-data exemption.”
Rule 12 / Fourth Schedule exceptions are conditional and purpose-specific.
“An admission signature permits every future use.”
Consent must be specific, informed and tied to the specified purpose.
“Section 9(2) bans tracking.”
s.9(2) concerns detrimental effect on well-being; tracking, monitoring and targeted advertising are in s.9(3).
“DPDP bans CCTV in schools.”
No blanket prohibition; a deployment needs fact-specific assessment.
“DPDP mandates a 30-day CCTV deletion rule.”
No universal DPDP school-CCTV period was identified.
“Aadhaar is mandatory for admission / APAAR makes it mandatory.”
Aadhaar cannot be compulsory for ordinary admission; APAAR is a distinct workflow.
“Schools cannot use Google Classroom or foreign cloud.”
DPDP does not generally prohibit them or impose universal localisation.
“Vendor contracts remove school responsibility.”
The Data Fiduciary remains responsible for processing done on its behalf.
“DPDP calls biometrics and health data ‘sensitive personal data.’”
DPDP does not create a GDPR-style special-category regime.
“Schools have 72 hours before notifying a breach.”
Initial Board and affected-person notice is without delay; 72 hours concerns the detailed Board update.
Management FAQ
Does DPDP apply to schools?
Yes — to covered digital personal-data processing by schools in India, including offline data later digitised. The core obligations relevant to ordinary schools commence on 13 May 2027.
Is every student a child under DPDP?
No. A child is a person who has not completed 18 years. A 17-year-old remains a child; an 18-year-old does not.
Do schools need parental consent for every activity involving a child?
Not necessarily. Section 9(1) requires verifiable parental consent unless a Rule 12 / Fourth Schedule exception applies. Other grounds may be relevant, but core education activities do not automatically qualify under the educational-institution exception.
Is a mobile OTP enough for verifiable parental consent?
Not by itself. It proves control of a phone number, not adult identity, parenthood or guardianship. Use it as part of an authenticated parent-account process.
Does Rule 12 exempt schools from all child-data obligations?
No. Rule 12 exceptions are limited to listed classes/purposes and stated conditions. Section 9(2), on detrimental effect on child well-being, remains applicable.
Can schools use CCTV, and is a 30-day retention period required?
No blanket prohibition; compliance depends on purpose, child-data implications, Rule 12 conditions, security, access, transparency, retention and other law. No universal 30-day school-CCTV rule is established by DPDP — use a documented, proportionate period.
Can schools track buses using GPS?
A Fourth Schedule exception addresses tracking enrolled children’s location for safety during travel to or from school. The use must remain tied to that travel/safety purpose.
Can schools use facial recognition or fingerprint attendance?
DPDP imposes no blanket ban, but these create substantial child-monitoring, security, retention and well-being risks and should not be adopted merely for convenience. Assess the specific features, s.9 implications, security, vendor terms and lower-risk alternatives.
Is Aadhaar mandatory for school admission?
No. The Supreme Court held Aadhaar cannot be made compulsory for school admission. Provide alternative identity/age routes where needed. APAAR is a distinct government workflow and does not make Aadhaar mandatory for ordinary admission.
Can schools use Google Workspace or Microsoft 365?
Yes in principle. DPDP does not prohibit foreign cloud platforms, but assess role, configuration, child accounts, analytics, AI features, contract, security, retention and cross-border processing.
Can teachers use WhatsApp?
DPDP does not prohibit WhatsApp. Use it carefully and avoid individual marks, medical data, discipline details, fee information and live location in open groups.
Can parents ask a school to delete student information?
Yes, subject to retention necessary for the specified purpose or another law. Where s.8(7) applies, the school must also cause relevant Processors to erase data.
What happens when a student turns 18?
They are no longer a child and should be treated as the adult Data Principal for ongoing rights and consent. DPDP does not prescribe a detailed transition protocol.
Who is responsible if an EdTech vendor leaks data?
The school remains responsible for processing done on its behalf by a Processor. The vendor may have separate obligations, but outsourcing does not eliminate the school’s DPDP responsibility.
Does every school need a DPO, and what is the breach deadline?
No — a statutory DPO is required for a notified Significant Data Fiduciary; ordinary schools still publish a responsible contact. For breaches, affected people and the Board must be notified without delay, with the detailed Board update within 72 hours unless the Board allows more time.
Are government schools exempt, and are records kept forever?
Government schools are not automatically exempt; the authority, purpose, s.7 ground and any s.17 exemption require separate analysis. Records are not kept forever — s.8(7) requires erasure when consent is withdrawn or the purpose ends, unless a purpose or law requires retention.
Primary sources
Law-level statements in this guide are anchored to primary material. Always confirm against the latest official version.
DPDP Act & Rules
Education: CBSE, CISCE, APAAR & DigiLocker
Aadhaar (Supreme Court)
Cybersecurity (CERT-In)
Related DPDP Act resources
The DPDP Act, 2023
Section-by-section reference with plain-English explanations.
DPDP Rules, 2025
The notified Rules, including Rule 10, Rule 12 and the Fourth Schedule.
Section 9: children’s data
The core children’s-data provisions referenced throughout this guide.
DPDP for education & EdTech
Sector overview for schools, EdTech and education providers.
DPDP Act for Schools & K-12
The schools sub-sector landing: obligations, consent and vendor gaps at a glance.
DPDP readiness assessment
The full guided assessment for a structured gap analysis.
All implementation guides
The full DPDP implementation guide library.
DPDP consent management guide
The consent hub: valid consent, withdrawal, proof of consent and children’s data.
School consent & VPC playbook · soon
A deeper workflow guide to Rule 10 verification is in preparation.
EdTech vendor assessment kit · soon
Templates for classifying and reviewing school suppliers.
School breach-response templates · soon
Rule 7 notification templates and an escalation directory.
- Written by
- The DPDPActIndia editorial team.
- Last updated
- 3 September 2026.
- Editorial methodology
- This guide separates what the Act text states, what the notified 2025 Rules add, what depends on future notifications or verification, and what is an implementation interpretation. Statements are labelled as Law, Interpretation, Practice or Verify where that distinction matters, and law-level claims are anchored to the primary sources listed above.
- Scope note
- Focused on ordinary Indian schools processing covered digital personal data. Significant Data Fiduciary duties are noted only where relevant.
This guide is general information about the DPDP Act, 2023 and the DPDP Rules, 2025 for Indian schools. It is not legal advice, an audit or a certification, and it has not been individually reviewed against any specific school’s facts. Confirm your position against the current official Act, Rules, board/state requirements and, where needed, qualified legal advice before acting.