DPDP compliance for EdTech companies covering children's data, parental consent, tracking, behavioural monitoring, applications, vendors and security safeguards. Assess readiness with NuageSEC.
EdTech platforms can process personal data from students, parents, teachers, administrators and other users across registration, learning activities, assessments, communication, payments, analytics and support.
When a platform serves children, the compliance question becomes more specific. The DPDP Act defines a child as an individual who has not completed 18 years of age and creates additional provisions for processing children's personal data — including requirements concerning verifiable parental consent, detrimental processing, tracking or behavioural monitoring, and targeted advertising directed at children, subject to prescribed exemptions.
For EdTech companies, this means children's-data protection needs to be considered inside the product architecture, not only inside a privacy policy. NuageSEC assesses the technology and operational environment around children's data to identify privacy and security exposure and prioritise practical remediation.
That creates several questions: Is the user a child? Who is authorised to provide consent? How is that parent identified and verified? What information does the product collect? Does the product track behaviour? Is information used for advertising or profiling? Which third parties receive or process the information? Can the organisation control access to student information? These are the questions that make an EdTech DPDP assessment different from a generic business compliance review.
A typical EdTech product also connects outward — to schools, teachers, parents, cloud providers, payment platforms, communication tools, analytics services and other technology providers.
This distinction should be made very clearly.
This distinction is critical for avoiding an incorrect assumption about exemption coverage.
The DPDP Act provides a dedicated framework for children's personal data. The Act defines a child as an individual who has not completed eighteen years of age.
For an EdTech platform, age therefore becomes an important product and compliance consideration. A platform should understand how it determines whether a user is a child where that distinction affects its processing obligations.
The final DPDP Rules specify a mechanism for verifiable parental consent before processing a child's personal data.
Rule 10 requires the Data Fiduciary to adopt appropriate technical and organisational measures to ensure verifiable consent from the parent and to exercise due diligence in checking that the person identifying themselves as the parent is an identifiable adult. The Rules describe verification using reliable identity/age information or information voluntarily provided by the individual, including through an authorised virtual token.
For an EdTech product, this creates a practical product-design question: how does the platform know that the person giving consent is actually the child's parent? That question is much more valuable than simply adding a checkbox saying “I am the parent.”
The goal is not to prescribe one technology. The goal is to determine whether the actual consent architecture is capable of supporting the applicable DPDP requirements.
Children's-data compliance should not begin after the product has already been built. The assessment should identify where personal data is collected or generated and determine how each activity fits into the organisation's processing model.
Section 9 of the DPDP Act states that a Data Fiduciary shall not undertake tracking or behavioural monitoring of children or targeted advertising directed at children, subject to exemptions prescribed by the Rules. It also prohibits processing likely to cause a detrimental effect on a child's well-being.
For EdTech, this creates a particularly important distinction between necessary learning functionality and additional behavioural observation. A platform may need information to deliver an educational service — that does not automatically answer whether every form of behavioural tracking is appropriate.
This avoids the simplistic assumption that every form of student analytics is automatically prohibited.
The key question is: is information collected through an educational product being used to create or support advertising directed at children? Where advertising technology is integrated into an EdTech platform, this deserves explicit privacy and technical review.
Personalisation can be central to an EdTech product — examples include recommending lessons, adjusting difficulty, identifying areas for improvement, tracking course progress, recommending practice content and generating student insights.
The assessment should distinguish educational functionality from secondary uses of student information. For example, a platform may need performance information to recommend learning material — that does not automatically mean the same information should be available to unrelated marketing or analytics functions.
This purpose-based approach keeps the children's-data question attached to the actual product.
EdTech products often have multiple account relationships, each of which can create different access paths:
The assessment should examine: who can see student information? What can each role see? Can a parent access another student's information? Can teachers access information outside their responsibility? Can administrators access data unnecessarily? How are privileged accounts controlled? What happens when a teacher, staff member or administrator leaves? The final DPDP Rules require reasonable security safeguards including access controls, visibility through logs, monitoring and review, backups and appropriate technical and organisational measures.
Children's data does not only exist inside a database. It can pass through: mobile application → API → application server → database → analytics → parent portal → teacher portal. A vulnerability in one component can create exposure elsewhere. A technical assessment can examine:
This is where a children's-data compliance programme connects directly to application security.
Learning platforms often create extensive analytics. Possible data points include course activity, assessment performance, time spent, progress, interaction history, device or technical information and teacher observations.
The important question is not simply how much data the platform can collect. It is: what information is actually needed for the stated educational purpose? The assessment should identify unnecessary collection, uncontrolled secondary use, inappropriate access and unnecessary exposure to external analytics services.
This is particularly important where children interact directly with AI-powered learning functionality. The assessment should focus on the actual data flow and processing arrangement, rather than assuming that “AI” itself creates one universal DPDP obligation.
An EdTech company may provide its platform to schools, coaching providers, universities, training organisations, parents directly or students directly. The contractual and processing role can therefore vary.
The company should establish whether it is determining the purpose and means of processing for a particular activity or processing information on behalf of another organisation. The DPDP Act defines a Data Fiduciary as a person that determines the purpose and means of processing and a Data Processor as a person that processes personal data on behalf of a Data Fiduciary.
The same EdTech company may therefore need to examine different processing relationships across different products or customers.
Next step: DPDP Vendor & Data Processor Compliance — EdTech processor and third-party data governance →
The 2025 Rules establish requirements for communication concerning a personal-data breach, including notification to affected Data Principals without delay and detailed information to the Board within 72 hours of becoming aware of the breach, unless the Board allows a longer period. That 72-hour requirement should not be simplified into “DPDP has a blanket 72-hour breach-notification deadline.”
The final Rules contain specific retention provisions for certain classes of Data Fiduciaries and purposes, alongside other requirements concerning retention where necessary under applicable law. This is particularly important where academic records, financial records, contractual records or other legally required information may be subject to separate retention obligations.
The right approach is not “delete every student record immediately after course completion.” It is to identify the purpose, applicable retention requirement, account lifecycle and legal basis for retaining the information.
This methodology is specific to the children's-data problem in EdTech and is intentionally different from the fintech and healthcare frameworks.
These are potential assessment findings, not assumptions about every EdTech company.
Review the child-data architecture before processing begins at scale.
Assess age handling, consent and product design before launch.
Determine whether the new capability changes behavioural monitoring or the purpose of processing.
Re-run the tracking/monitoring assessment against the new feature.
Review child-directed advertising and associated tracking technologies.
Assess ad-tech integrations against the targeted-advertising restriction.
Understand what information enters the AI workflow and which providers process it.
Map the AI data flow before enabling the feature for children.
Clarify processing roles, access boundaries and third-party dependencies.
Confirm Fiduciary/Processor roles in the partnership contract.
Assess the impact of the new verification workflow.
Validate the new mechanism against Rule 10 requirements.
Evaluate whether the incident exposes weaknesses in the wider children's-data environment.
Use the incident to reassess access, tracking and vendor exposure.
The DPDP Act defines a child as an individual who has not completed 18 years of age.
No. The final Rules provide specific exemptions for a Data Fiduciary that is an educational institution, under defined conditions and limited processing purposes. A commercial EdTech company is not automatically an educational institution merely because it provides technology or services to schools.
The Act and final Rules establish a framework for verifiable parental consent before processing a child's personal data, subject to applicable statutory exemptions. Rule 10 sets out how the Data Fiduciary must take measures to verify that the person providing consent is an identifiable adult parent.
The Act generally prohibits tracking or behavioural monitoring of children, subject to exemptions prescribed by the Rules. For an EdTech organisation, whether an exemption applies depends on its status, the activity and the conditions in the Rules.
Section 9(3) of the Act generally prohibits targeted advertising directed at children, subject to prescribed exemptions. An EdTech advertising model therefore needs specific assessment rather than assuming that ordinary advertising practices can be applied unchanged.
No. The legal question depends on what is being processed, why it is processed, how it is used, whether it constitutes prohibited tracking or behavioural monitoring, and whether an applicable exemption exists.
No universal DPDP provision says that every EdTech company must conduct penetration testing. However, application/API/security testing can be relevant where those systems process children's personal data and the organisation needs to evaluate technical exposure and the effectiveness of safeguards. The 2025 Rules require reasonable security safeguards.
Potentially, depending on the statutory scope and the organisation's processing arrangement. Using a cloud provider does not by itself remove the Data Fiduciary's responsibilities where the provider processes personal data on its behalf. The Rules also expressly address security provisions in Data Fiduciary–Data Processor contracts.
The DPDP Act's child-data provisions are part of Section 9, and the 13 November 2025 commencement notification places Section 9 among the provisions commencing 18 months after 13 November 2025.
Similarly, Rules 3 and 5–16, which include the child-data rules in Rules 10 and 12, are scheduled to come into force 18 months after publication of the Rules on 13 November 2025.
These requirements are therefore described here as part of the final DPDP framework and readiness planning, rather than as obligations that are already fully operative. This distinction is particularly important for a compliance-services website.
For an EdTech organisation, DPDP readiness should connect: Age → Parental consent → Product design → Learning analytics → Access → Third parties → Security → Lifecycle.
Rather than treating children's privacy as a document prepared after the technology has already been deployed.
Keep these links focused on children's-data and EdTech-specific next steps:
Tell us about your organization. Our DPDP team will get back within one business day to define the right scope and next steps.