One source of student data: choosing a student information system in the UAE

Most UAE schools do not have a data problem, they have five. Admissions, fees, grades, attendance and parent messaging each keep their own copy of the same 1,200 students, and a small team rebuilds the truth by hand every time KHDA or ADEK asks for it. This guide argues for one system of record per kind of data, shows how to connect the rest to it, gives the order to do it in, and explains why this is also the groundwork that AI marking and reporting tools need before they will work.

Why this has moved up the list

The regulators have quietly made student records a compliance issue, not just an efficiency one.

Abu Dhabi's Department of Education and Knowledge (ADEK) published its School Reporting Policy (ADEK/S/Reporting/Policy/EN/v1.1) in November 2024. It took effect at the start of the 2024/25 academic year, with full compliance expected from 2025/26. The policy obliges schools to submit student information through the Ministry of Education's electronic Student Information System (eSIS), and the data required is granular: student personal details, enrolment and exit records, daily attendance, grade progress and exam results, behavioural and disciplinary records, fee payment sources, special education needs status, and parent or guardian details. Crucially, it lists consequences for poor data quality, including that attendance submitted through eSIS is the sole evidence base for absence-related fee disputes and absence warning letters, and that student promotion is assessed strictly on eSIS grade records. Licence renewal is contingent on meeting reporting requirements.

In Dubai, the cycle runs through the KHDA census. The KHDA private schools open data set records the operational mechanism: during census periods, schools upload or update student information through the Ministry's RPC e-service, with a named data custodian and backup responsible for the submission.

At federal level, the Ministry of Education publishes the standard IT systems every school must use: eSIS for student management, the national assessment system, the UAE Rasd platform for voluntary financial contributions, and the unified UAE pass (UAE PASS) for secure access. The SIS is described as integrating all student management operations: registration, enrolment, transfer certificates and academic performance.

On the inspection side, UAE school technology guides for 2026 and regional SIS implementation evaluations note that KHDA and ADEK inspections now put far more weight on digital record-keeping and automated attendance tracking, and that the SIS must feed government eSIS reporting cleanly. The same operational profiles show schools standardising on a clear stack: a web-based, cloud-hosted SIS that supports Microsoft Teams single sign-on, ZKTeco biometric or RFID terminals at the gates, and Arabic-first parent portals with UAE PASS login.

The business case is clear. A defensible student record is now a licensing input. Getting it wrong risks inspection grading, drains administrative hours in manual submission cycles, and, in fee disputes, eliminates the evidence base entirely.

What a student information system in the UAE actually has to carry

"Student information system" is often used loosely to describe anything from a timetable viewer to an admissions form. For a UAE school, it has to carry at least six distinct data domains, and the failure mode is consistent: each domain gets its own software, each software tool invents its own student identifier, and nobody reconciles them.

When this information lives in five separate silos, three operational failures occur. First, census and eSIS submissions must be rebuilt by hand from multiple CSV exports. Second, termly report cards are assembled from whatever spreadsheets teachers maintain locally. Third, any AI tooling introduced later cannot join a grade to a student and class with confidence, because the primary keys diverge across databases.

The rule: one system of record per kind of data

Schools can resolve this by enforcing a single architectural principle: for each row of the table above, exactly one system is permitted to author that data. Everything else reads from it. Nothing else edits it.

For most UAE schools, the assignment looks like this:

• Identity and enrolment: the SIS is the record. Admissions tools create a student record in the SIS once an offer is accepted, and subsequently stop acting as the master.
• Attendance: the SIS is the record. Gate terminals and class registers are real-time inputs into it, not parallel stores.
• Academic records: the SIS or the LMS gradebook is the record, decided once. In a multi-curriculum school, exam board criteria usually make the SIS the master for final summative grades, with the LMS feeding formative task scores.
• Fees: the finance system is the record for invoices and payments. The SIS holds a fee plan reference and an aggregated balance snapshot for administrative reporting, nothing more.
• Behaviour and wellbeing: the SIS is the record, with strict role-based access control, as this category presents the highest sensitivity under privacy regulations.
• Parent communication: the messaging platform sends and logs communications, but contact details, language preferences and consent flags live in the SIS and flow strictly one way to the messaging system.

The identifier policy matters far more than the specific vendor selected. Every system must carry the SIS student ID, and where held, the Emirates ID as the national anchor key. Document this once as an internal data contract so every software vendor, analytics report and future AI model binds to the exact same key.

Three architectures for connecting what you keep

Very few operational schools start from a blank slate, so the core decision is how existing systems interface with the primary record.

Regardless of the chosen topology, standard data exchange protocols should replace bespoke scripts wherever possible. 1EdTech's OneRoster standard defines the exact schema needed: users, courses, classes, enrolments, demographics and gradebook results, exchanged via batch CSV or over an OAuth 2.0 secured REST API covering rostering, gradebook and resource services. Version 1.2 is the current widely deployed release. If a software vendor cannot produce or ingest OneRoster data, the school takes on custom integration debt that must be maintained across every software upgrade.

There is also a statutory regulatory requirement. The ADEK reporting policy directly connects school data management to Federal Decree-Law No. 45 of 2021 on Personal Data Protection, as well as EU GDPR where applicable. Behavioural logs, SEN classifications and medical data require role-based access policies, and any cloud SIS procurement requires explicit contractual verification of local data residency.

The order to fix it in

Sequencing determines the cost and friction of implementation. Executing these steps in strict order ensures each milestone simplifies the next.

1. Inventory and identifier crosswalk (2–4 weeks). Catalogue every application holding student records. Export the full student roster from each. Match records on Emirates ID where available, then fall back to composite matching on student name and date of birth. Produce an authoritative crosswalk table linking the SIS ID to every satellite ID. Acceptance criterion: 100% of currently enrolled students matched, with every discrepancy resolved by administrative staff rather than fuzzy automated logic.
2. Declare the SIS the record for identity and enrolment (week 4). Publish the one-page data contract across all departments. Revoke direct student creation permissions in all ancillary systems, routing all admissions onboarding directly into the SIS.
3. Attendance (weeks 5–8). Ingest gate scans from ZKTeco or RFID terminals into the SIS daily, and establish class registers within the SIS as the single authority for presence. Acceptance criterion: the SIS attendance calculation matches the daily eSIS format automatically, flagging exceptions for human review rather than manual compilation.
4. Academic records (weeks 9–14, timed across a reporting term). Move final grade recording into the chosen record system. If an external LMS gradebook is retained, synchronise formative assessments to the SIS on an automated schedule. Acceptance criterion: termly report cards generate directly from the SIS without intermediate spreadsheet manipulation.
5. Fees (weeks 15–20). Maintain billing inside the ERP or finance engine, write a fee payment source classification into the SIS (mandatory for eSIS reporting), and replicate account balances nightly. Acceptance criterion: statutory fee compliance extracts run from a database view rather than manual reconciliation across departments.
6. Parent messaging (weeks 21–24). Stream parent contact information, language preferences and communication consent flags from the SIS to the outbound messaging tool nightly, strictly one way. Acceptance criterion: staff never edit parent phone numbers or email addresses inside the messaging tool directly.
7. Reporting layer (from week 25). Construct KHDA census and ADEK eSIS extracts as validated views directly over the SIS database, complete with pre-flight validation checklists before final portal upload. Administrative teams shift from rebuilding data to auditing pre-validated records.

Worked example: a 1,200-student school in Dubai

The following operational figures are based on typical mid-to-large UAE school operations. School leaders should apply their own staffing models and hourly rates to evaluate the return on investment.

A 1,200-student, FS1 to Year 13 institution operates an admissions CRM, a timetabling and gradebook tool, a standalone finance package, ZKTeco biometric gate scanners, and a third-party parent messaging platform. Historically, a registrar, a finance officer and an executive assistant spent significant portions of each week manually compiling and cross-referencing records.

Step 1: the crosswalk. Rosters were exported from all five software systems across 1,200 students in 48 class sections. Matching by Emirates ID resolved 1,143 students immediately. The remaining 57 discrepancies comprised sibling records with swapped Emirates IDs, 11 withdrawn students who remained active within the parent messaging application, and 4 duplicate profiles resulting from mid-year transfers. Administrative staff audited and resolved all 57 discrepancies within four days.

Step 2: the contract. The primary student_id along with the emirates_id became mandatory relational keys across all external databases. Finance and messaging applications recorded the SIS identifier in their respective external reference fields.

Step 3: attendance. Scans from the biometric turnstiles land in the SIS daily. An automated verification script runs nightly to isolate discrepancies between the gate turnstiles and classroom registers:

import csv

def load(path, key):
    with open(path, newline="", encoding="utf-8-sig") as f:
        return {row[key]: row for row in csv.DictReader(f)}

sis = load("sis_roster.csv", "student_id")
gate = load("gate_scans_2026-02-12.csv", "student_id")

orphans = sorted(set(gate) - set(sis))
missing = sorted(sid for sid in sis if sis[sid]["enrolment_status"] == "enrolled" and sid not in gate)

print(f"enrolled: {len([r for r in sis.values() if r['enrolment_status'] == 'enrolled'])}")
print(f"gate scans: {len(gate)}")
print(f"unknown IDs in gate feed: {len(orphans)} -> {orphans[:10]}")
print(f"enrolled with no gate scan: {len(missing)} -> {missing[:10]}")

The value of this script lies in the operational acceptance criterion. Prior to integration, the registrar spent 12 hours every week cross-referencing paper registers against gate logs. Following automated ingestion, the daily exception list is reduced to 10–25 rows, requiring roughly 2 hours a week to manage.

Steps 4 to 6: Summative marks move into the SIS for the termly reporting cycle; a fee payment source flag is added and populated from the finance software nightly; contact details and data consents sync unidirectionally to the messaging platform.

The annual operational impact:

This structural change returns 800 administrative hours annually to school staff, representing approximately half a full-time employee. At an average fully loaded administrative cost of AED 110 per hour, this delivers direct annual labour savings of approximately AED 88,000, easily amortising a mid-five-figure integration project while eliminating compliance vulnerability during regulatory inspections.

The data foundation AI marking and reporting tools need

Schools across the region are evaluating AI marking models, generative report writers, and automated parent communication assistants. Every one of these tools fails when deployed on fragmented infrastructure, and the mitigation is the exact integration architecture detailed above.

Specifically, an AI marking solution that scores open-ended responses criterion by criterion (the capability provided by our NovaGrade product) requires a verified, immutable student ID on every physical script, associated class and exam series metadata, and standardised rubrics with criterion identifiers. The model must also write item-level question scores back to the SIS gradebook without administrative intervention. Similarly, an automated reporting assistant depends on uniform historical grade sequences and attendance figures anchored to clean dates. Parent-facing AI assistants require up-to-date consent records and preferred language parameters, governed by rigorous role-based permissions that prevent safeguarding or SEN records from leaking.

Three operational rules keep school leadership protected:

1. No stable identifier, no AI implementation. If the identifier crosswalk contains unverified records, model outputs will inevitably be attributed to incorrect student profiles, introducing severe operational and reputational liabilities.
2. Capture item-level assessment data, not just aggregate percentages. An aggregate score of 68% does not provide sufficient semantic detail to ground AI diagnostic tools. Schools must retain question-level and rubric-criterion data from the first assessment series following SIS integration.
3. Establish consent frameworks and data residency before deployment. Student wellbeing, behavioural records, and SEN documentation fall under the statutory requirements of the UAE Personal Data Protection Law referenced in ADEK directives. Data boundaries and physical residency parameters must be contractually established before model inference touches student data.

Completing core integration work first turns AI adoption into a clean data access exercise that can be executed rapidly. Attempting AI adoption beforehand turns it into an intractable data cleaning challenge.

What to do next

This week: assign a single data owner to each domain listed in the architecture table, and request written confirmation from every software vendor regarding their roster export schemas and their OneRoster or REST API capabilities.

This month: compile the cross-system identifier crosswalk, reconcile all lingering student account duplicates, and formally publish the one-page data governance contract.

This term: unify attendance pipelines, connecting physical gate scans directly to the SIS register. Attendance is inspected daily by regulators and represents the single largest consumer of routine administrative time. Establishing this pipeline provides the foundation for fees, automated parent messaging, and subsequent AI capabilities.

For schools seeking support in structuring this architecture, our digital transformation practice works directly with leadership teams to map operational flows, integrate disparate software stacks, and establish unified data models before procuring or implementing new technologies. The roadmap detailed here reflects the exact operational sequence we deploy.

https://www.azrty.com/blog/one-source-of-student-data-choosing-a-student-information-system-in-the-uae

<a href="https://www.azrty.com/blog/one-source-of-student-data-choosing-a-student-information-system-in-the-uae">One source of student data: choosing a student information system in the UAE</a> (Azrty)