> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/regulations/component-5/student-data-protection.md).

# Student Data Protection

Why children cannot meaningfully consent for themselves, the enhanced protections student data requires, and the EdTech processing-agreement gap most education systems have not yet closed.

Student data is among the most sensitive personal data processed by government. It covers the full arc of a child's development — enrolment, attendance, assessment results, health and welfare records, disability status, disciplinary history, and increasingly behavioural data generated by digital learning platforms. The people whose data is at stake are children, who cannot meaningfully consent for themselves and whose interests must be protected by the legal framework rather than by their own choices. The risks are correspondingly severe: commercial exploitation of children's data, profiling that follows a person from childhood into adult life, and breaches of datasets that families cannot choose not to be in.

The general [data protection framework — Category 2 in Component 1](/experience-digital-transformation/regulations/component-1-the-landscape-of-digital-transformation-regulations/track-a-cross-cutting-guardrails.md#data-protection-and-privacy-regulation), applies to student data, but the education sector context requires several additional or enhanced provisions:

* **Enhanced consent requirements.** Where the general data protection framework permits processing of adult personal data on the basis of contractual necessity or legitimate interest, processing of children's data typically requires explicit parental consent or a specific statutory basis. The age at which a child can consent independently varies across jurisdictions but is typically 13–16.
* **Purpose limitation** is particularly important in the education context because student data is frequently sought for purposes other than education — by commercial EdTech providers for product improvement, by researchers for academic study, by employers for pre-employment screening. The regulatory framework must establish clear rules about when secondary use is permissible and when it is prohibited.

The EdTech dimension of student data protection deserves specific attention. When educational institutions deploy third-party digital learning platforms, they typically transfer student data to the platform operator under a processing agreement. The adequacy of those agreements — whether they genuinely constrain the operator's use of the data to educational purposes — is a regulatory and procurement question that many education systems have not yet addressed systematically. The regulatory framework should require that EdTech procurement includes data protection impact assessments and contractual conditions that restrict secondary data use, a point developed further in [EdTech Platform Governance](/experience-digital-transformation/regulations/component-5/edtech-platform-governance.md).

{% hint style="info" %}
**EXAMPLES IN PRACTICE — Student data protection instruments**

GDPR Article 8 sets the template for age-of-consent rules, allowing member states to fix the threshold between 13 and 16. The United States regulates the sector through the combination of FERPA (education records held by institutions) and COPPA (data collected online from children under 13). The UK's Age Appropriate Design Code illustrates the newer regulatory technique: a statutory code of practice imposing child-centred design duties directly on online services likely to be accessed by children.
{% endhint %}

For the full comparative treatment of data protection — the GDPR and the Brussels effect, comparative practice across Estonia, Brazil, South Korea, India, Kenya, and Nigeria, and the detailed regulatory-elements-and-education analysis — see [Component 3's Data Protection profiles](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations/data-protection-and-privacy-key-regulatory-elements-and-education-implications.md), particularly the [Comparative Practice and Regulatory Reference page](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations/data-protection-and-privacy-comparative-practice-and-regulatory-reference.md) where the age-of-consent and processor-obligation instruments above are set out in comparative detail.

Student data protection sets the baseline that every commercial and government-operated platform touching learners must meet. [EdTech Platform Governance](/experience-digital-transformation/regulations/component-5/edtech-platform-governance.md) turns to what happens once that data reaches a platform.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/regulations/component-5/student-data-protection.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.