> 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/national-learner-registry-governance.md).

# National Learner Registry Governance

The legal, data-protection, and interoperability foundations of a national learner registry, and Estonia's HAVAI interoperability framework as a worked example.

The following five profiles — starting with this one — address the regulatory areas specified in the Terms of Reference for this Primer. Each profile is concise by design: the full comparative analysis of the underlying regulatory categories is in [Component 3](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations.md). These profiles focus on what is distinctive about the education sector application of each regulatory area. Each should be read as an exercise in risk mitigation: the question to ask of every instrument proposed here is which concrete risk it addresses — exclusion of learners from services, misuse of children's data, credentials that cannot be trusted, vendor lock-in, or automated decisions that cannot be explained or appealed. Each profile therefore names the risks its regulatory area is designed to mitigate.

One area is intentionally absent from this chapter: school connectivity itself. Its regulatory content — universal service obligations, licence conditions, infrastructure sharing — is horizontal telecommunications regulation, treated elsewhere in the wider Primer, and in the connectivity-first scenario of [The Charter for Public Digital Learning Platforms and Country Scenarios](/experience-digital-transformation/regulations/component-5/the-charter-for-public-digital-learning-platforms-and-country-scenarios.md); its education-specific dimension is a matter of policy and budget rather than sectoral regulation. For readers checking against the Terms of Reference: its five example areas map onto these profiles as follows — national learner registry governance (this page), digital credential regulations ([Digital Credentials](/experience-digital-transformation/regulations/component-5/digital-credentials.md)), student data protection regulations ([Student Data Protection](/experience-digital-transformation/regulations/component-5/student-data-protection.md)), and EdTech platform regulations together with digital learning platform governance (both in [EdTech Platform Governance](/experience-digital-transformation/regulations/component-5/edtech-platform-governance.md), which treats commercial and government-operated platforms as two faces of one regulatory area) — with [AI in Education Governance](/experience-digital-transformation/regulations/component-5/ai-in-education-governance.md) added in view of the ToR's broader emphasis on AI.

## The Learner Registry as Foundational Infrastructure

The learner registry is the foundational data infrastructure of a digital education system. It is the authoritative record of who is enrolled in what institution at what level, and it is the reference dataset that enables all other digital education services to operate with verified identities rather than self-reported ones. Without a reliable learner registry, digital credentials cannot be issued reliably, assessment results cannot be attributed to verified individuals, and education statistics cannot be trusted. The risks registry governance mitigates are correspondingly concrete: ghost learners and unreliable statistics, exclusion of unregistered children from services and funding formulas, and uncontrolled access to a dataset that describes the entire school-age population.

Registry governance requires regulatory provisions at three levels:

1. **Legal authority.** Which institution holds the registry, under what legal mandate, and what obligations schools and educational institutions have to report enrolment data to it. In most countries this requires an amendment to the Education Act or a dedicated sub-regulatory instrument rather than new primary legislation — but the legal basis must be explicit.
2. **Data protection framework.** Learner registries process personal data about children, which attracts enhanced legal protections in virtually all data protection frameworks. Data minimisation — collect only what is necessary — and purpose limitation — use data only for the purposes for which it was collected — apply with particular force.
3. **Interoperability framework.** The registry's value depends on its connections to the civil registration system (to verify identities at enrolment), the education administration system (to link learners to schools and grades), and eventually to the credentialing system (to link learners to their qualifications). Each connection requires a legal basis for data sharing.

Developing countries implementing learner registries face two common structural challenges. The first is **coverage**: a registry that does not capture out-of-school children, children in informal education settings, or children in hard-to-reach areas systematically excludes the most vulnerable learners from the digital education ecosystem. Ensuring that registration of learners does not depend on the school having internet connectivity is a design requirement that the Giga initiative's connectivity programme directly addresses. The second is **linkage to civil registration**: a learner registry linked to verified birth registration records is far more reliable than one that accepts self-reported identity. In countries where civil registration coverage is incomplete, the learner registry may actually become a driver of civil registration rather than a dependent of it.

{% hint style="info" %}
**EXAMPLES IN PRACTICE — Learner registry instruments**

Estonia's EHIS — the national education information system, established with an explicit statutory basis, a designated controller, and defined reporting obligations for schools — is the model this profile describes. Kenya's NEMIS (see the [case study](/experience-digital-transformation/regulations/component-5/the-education-sector-and-digital-public-infrastructure.md)) shows the same instrument in a developing-country setting, with the learner identifier linked to birth registration. India's APAAR learner ID initiative illustrates the registry question at federal scale — together with the consent and data protection debates that accompany any identifier assigned to children.
{% endhint %}

{% hint style="info" %}
**CASE STUDY — Estonia's Education Information System Interoperability Framework (HAVAI)**

Estonia's HAVAI framework — the Hariduse infosüsteemi koosvõime raamistik, or Education Information System Interoperability Framework — is a national-level regulatory instrument that translates the principles of Estonia's broader state information system interoperability framework into binding requirements for IT systems used by educational institutions.

**Goal and scope.** The framework enables automated data exchange between education information systems and between those systems and state-level registries. Scope covers all IT systems used in educational institutions, divided into three functional layers: (1) education accounting modules — statutory registries covering learner records, qualifications, learning resources, assessment results, and similar data whose establishment and governance is defined by legislation; (2) teaching process modules — systems managing admissions, curriculum, daily teaching, and school-family communication, which institutions select freely but must make interoperable; and (3) institution administration modules — finance, HR, facilities, and document management, also freely chosen but subject to interoperability requirements. The distinction between the statutory first layer and the freely chosen second and third layers clarifies which systems require legislative mandate and which require only technical standards compliance.

**Eight operating principles.** Subsidiarity and proportionality (IT decisions taken at institutional level; prefer loosely coupled service-based systems over mechanical integration); user-centricity (systems designed around the learner's educational journey, not institutional levels; data submitted once only); security and privacy (confidentiality, authenticity, availability, and verifiability mandatory; compliance with data protection rules required); multilingualism (language requirements apply to services, metadata, documentation, and data structures, not only user interfaces); information preservation (institutions must maintain open data services and comply with National Archives requirements for digital documents); reuse (education data and systems reused freely; open source preferred using the EUPL licence and the OSOR.eu repository); technology neutrality (functional requirements first; technology choices last, through procurement; open standards mandatory — XML, WSDL, SOAP); and effectiveness and efficiency (total lifecycle cost, flexibility, transparency, and risk reduction all considered in system adoption decisions).

**Master data governance.** The framework defines a master data regime: unique, open, and queryable data objects that must be semantically described before connection to the national data exchange layer. Each data object has a designated custodian — determined by legislation for the statutory first layer, and by the institution itself for the second and third layers — responsible for accuracy, openness, and update notification to data users. Access to master data is through XML web services described in WSDL format, held in RIHA (the state information system registry). Legally evidential data exchange runs exclusively through [X-Road](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations/interoperability-and-digital-government-comparative-practice-regulatory-reference-and-the-educat.md), Estonia's national data exchange layer. Security requirements — integrity, availability, and confidentiality — are set by the custodian, and institutions accept these obligations upon signing the X-Road membership agreement.

**Relevance to the Primer's framework.** HAVAI demonstrates three regulatory design choices this Primer argues for. First, it separates the statutory layer (registries requiring legislative mandate) from the freely chosen layers (teaching process and administration systems requiring only technical standards compliance) — the same distinction the [dependency table](/experience-digital-transformation/regulations/component-5/infrastructure-dependencies-in-digital-education.md) draws between the sector-wide DPI layer and the school-level layer. Second, it institutes custodianship as the organising principle for data governance: rather than centralising all data in a single system, it distributes custody while mandating open queryability — a model that preserves institutional autonomy while enabling system-wide interoperability. Third, it uses existing national infrastructure (X-Road, RIHA) as the technical backbone rather than building education-specific exchange mechanisms, reducing both cost and governance complexity.

**The EU parallel.** What Estonia built nationally, the EU is now attempting at supranational scale. The European Higher Education Interoperability Framework (HEIF), initiated by the European Commission in 2023 and launched in January 2025 under the Digital Education Action Plan 2021–2027, aims to provide higher education institutions with a common toolkit for interoperable virtual learning environments and EU-wide alignment of data exchange standards. The [Interoperable Europe Act](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations/interoperability-and-digital-government-comparative-practice-regulatory-reference-and-the-educat.md) (April 2024) provides the governance structure for cross-border public service interoperability, but does not impose technical standards — the EU framework is at the governance architecture stage that Estonia reached with HAVAI a decade earlier. The contrast illustrates a broader pattern: national interoperability frameworks built on existing state data infrastructure (identity, exchange layer, registry) can move considerably faster than supranational frameworks that must first establish the shared infrastructure that national systems already have.
{% endhint %}

Registry governance also depends on the [national digital identity framework](/experience-digital-transformation/regulations/component-3-comparative-analysis-of-regulations/digital-identity-and-trust-services-regulatory-reference-and-the-education-sector.md) that authenticates learners, teachers, and administrators — see Component 3's Digital Identity profiles for the comparative landscape. [Digital Credentials](/experience-digital-transformation/regulations/component-5/digital-credentials.md) builds directly on a functioning registry, since a credential is only as trustworthy as the enrolment and completion record behind it.

{% hint style="success" %}
**Related resource.** A separate GitBook Knowledge Product, the [National Learner Registry and Digital Credentials](https://experience-digital-transform.gitbook.io/experience-digital-transformation/national-learner-registry/national-learner-registry-and-digital-credentials/learner-registry) KP, works through a national learner registry implementation in full operational detail. It is a useful companion for a practitioner who has read this profile's governance principles and now needs a worked example of registry design end to end.
{% endhint %}


---

# 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/national-learner-registry-governance.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.