Data Protection Summary

Edu360 holds records about children: enrolment, attendance, grades, conduct, health and welfare notes where a school keeps them, documents, and the identity of the adults linked to each student. It also holds staff payroll and school budget records, and payment records governed by the rules that apply to a licensed mobile financial services provider. The sensitivity of that mixture, rather than the size of the user base, sets the standard we design to.

Collect the least that will do the job. Decide access on the server, never in the interface alone. Make every access to a record attributable to a person and a role. Require a fresh proof of identity in front of an action that moves money, releases a document or changes a security setting. Fail closed: when a check cannot be completed, deny rather than guess. Prefer a control the build enforces over a rule written in a document — a promise nobody can break by accident is worth more than a promise everyone has to remember.

Access begins with a mobile number on the Mytel network and a one-time passcode delivered by SMS. One-time passcodes are single-use, time-limited and rate-limited, and repeated failures lock further attempts for a period. We never ask for an OTP, a passcode or a PIN outside the app's own screens, and no member of our staff has any reason to ask you for one.

A mobile number alone is not enough to reach a record. The first sign-in on a device registers that device against the account and verifies it, and an unrecognised device is challenged rather than admitted. Each installation carries its own device identifier, so two devices are never mistaken for one and a device can be revoked individually. You can see and remove your registered devices in Settings; removing one ends its access. A change of SIM or handset requires registration again.

Being signed in is not authority to do anything. Actions that move money, release an official document, approve a payroll period, change a security setting or alter who can see a record require you to authenticate again at that moment, through SmartOTP, an SMS one-time passcode, an app passcode or the device's biometric unlock, according to the action and the institution's configuration. The requirement is defined centrally per action, so a new screen cannot quietly ship without the check that its action deserves.

Biometric unlock is performed by the device's own secure hardware and operating system. Fingerprint and face templates never leave the device, are never transmitted to us, and are never stored on our servers. Our systems learn only whether the device reported a successful unlock. A local passcode or biometric unlock protects the app on that device; it never replaces the server-side check for a sensitive action.

Traffic between the app and the backend runs over encrypted transport. On top of that, the client and server establish a per-session key through an ephemeral key exchange, and each request carries a signature that binds it to that session. A request that has been modified, replayed or issued outside its session is rejected by the server. The signing and session material is scoped to one session and one device, so capturing traffic from one device does not yield anything usable on another.

Every role has a defined scope: a teacher's classes, a school, a district, a department. Scope is evaluated on the server for every request, and the interface only reflects the answer. Elevation is granted by the institution and the ministry hierarchy, never by the user and never by client-side configuration. A mini app inherits the signed-in user's role and scope and cannot widen it.

Credentials, tokens and the app passcode verifier are held in the platform's secure storage, protected by the device's keystore. A local cache exists so that recently viewed screens open quickly and remain readable during a brief loss of network; it holds no more than the screens you have opened, and clearing the app's data removes it. Uninstalling the app removes local data; it does not remove the institution's own records, which is a matter for the institution.

Access to a record and changes to it are recorded with the actor, the role, the action, the record and the time. An audit trail is what makes access to a child's record accountable rather than merely restricted, and it is what allows a school to answer the question a parent is entitled to ask: who looked at this, and why. Audit records are retained for a period proportionate to their purpose and are protected against casual alteration.

Access to production systems is limited to the people whose work requires it, granted on the principle of least privilege, individually attributable, and logged. Support work is done against the minimum data needed to resolve the case. We do not browse school records, and we do not use production data in development or testing environments.

Changes are reviewed before they ship, and parts of our policy are enforced by the build rather than by review alone. The Android release pipeline fails the build if the advertising-identifier permission is reintroduced by any component, and it verifies the shape of the artifact it produces before that artifact can be distributed. Automated analysis and tests run on every change, and a dependency with a known vulnerability blocks the pipeline. Where a control can be made mechanical, we make it mechanical.

Third-party components are pinned to reviewed versions and scanned for known vulnerabilities. Service providers process data only on our instructions and under contract. A mini app distributed through Edu360 inherits the signed-in user's role and scope, and a third-party mini app must handle student data consistently with our Privacy Policy. On-device machine learning used for QR and barcode recognition runs locally and does not transmit camera images.

We monitor for authentication anomalies, access outside an expected scope, and transaction patterns that trip a control. When an incident is suspected, we contain it, preserve evidence, assess what data and which people are affected, and record what happened and what we changed as a result. Incidents involving children's records take priority over everything else. Where a personal data breach is likely to cause risk to the people affected, we notify the responsible institution and, where the law requires, the competent authority.

Records are backed up, and restores are tested rather than assumed. Backups are protected to the same standard as the systems they came from, and data removed at the end of a retention period is removed from backups on their own cycle. Where a component fails, the product is designed to degrade to a readable state rather than to a state that shows the wrong record.

If you find a weakness, tell us before you tell anyone else, using the contact details at the foot of this page and marking the message urgent. Please include enough detail to reproduce it. Do not access, modify or download another person's data — and in particular a child's — to demonstrate a finding; a description is enough, and going further turns a report into an intrusion. We will acknowledge your report, keep you informed, and will not pursue a reporter who acts in good faith and within these limits.

Keep control of your SIM, your device and your one-time passcodes. Remove devices you no longer use. Do not share an account, and do not sign in on a device you do not control. If you are a teacher, school leader or ministry officer, treat what your scope shows you as confidential to the purpose you were given it for. If you see a record you should not be able to see, stop, do not share it, and report it. Most of what protects a child's record is technical; the last part of it is you.This summary is published in English, Vietnamese and Myanmar; the English text is the original, and where a translation differs in meaning the English text prevails.