This notice describes NexusGrade's own privacy practices as a Data Processor. It is pending review by NexusGrade's legal counsel and has not been reviewed or approved by a lawyer. An institution evaluating NexusGrade should have its own counsel review this document, alongside the tenant-specific notice it publishes for its own students, parents and staff. Last updated 10 September 2026.
Privacy notice
How personal data moves through NexusGrade.
Your institution is the Data Fiduciary under the DPDP Act — it decides why and how personal data is processed, and it publishes its own notice. NexusGrade is the Data Processor behind that notice. This page describes our side of that boundary: what we handle, what we refuse to do with it, and how the rights the Act creates are actually exercised in the product.
Scope & roles
This notice covers personal data processed through the NexusGrade platform on behalf of a subscribing school, college or university (the Institution). Under the Digital Personal Data Protection Act, 2023 ("DPDP Act"), the Institution is the Data Fiduciary — it decides why and how personal data is processed, and it is responsible for publishing its own notice to the students, parents, staff and applicants whose data it holds.
NexusGrade Technologies acts as the Institution's Data Processor: we process personal data only on the Institution's documented instructions, through the platform the Institution has configured. The Fourth Schedule exemption that lets an educational institution process a child's personal data for admission, attendance, examination and related educational purposes belongs to the Institution as Data Fiduciary. It is not ours to inherit, and the platform is built to enforce that boundary rather than merely state it — see "What we do not do", below.
Every processing purpose configured in the compliance module is tagged with who controls it — the Institution or the platform — so this split is a field in the schema, not only a paragraph here. If your Institution has published its own privacy notice (most do, through the Compliance module), that notice governs your relationship with the Institution; this page describes NexusGrade's role as the processor operating behind it.
What data we process
On the Institution's instructions, the platform holds:
- Identity: name, date of birth, gender, photograph, category
- Contact: address, phone number, email address
- Academic: class, section, subjects, attendance, marks and results
- Financial: fees invoiced, payments and concessions
- Identifiers: admission number, and, where provided, APAAR/ABC ID
- Transport: an allotted route and stop, and a vehicle's live location while a child is travelling on it
Where an Institution enables them, and only to the staff roles its own capability model grants for that purpose: biometric attendance identifiers, health and counselling records, and discipline records. Where the Institution enables the in-product AI assistant, conversation transcripts are kept on the Institution's own retention schedule for safety review.
Bus location tracking is a named exception worth calling out on its own: the Act bars tracking a child's location as a rule, and the Fourth Schedule carves out an exemption specifically for tracking done in the interests of a child's safety. The platform's transport module is built to that exemption and nothing wider — it shows where the bus is, not where the child has otherwise been.
What we do not do
- No cross-tenant benchmarking. One institution's data is never compared against, or exposed to, another.
- No model training on student, parent or staff data.
- No behavioural analytics, profiling or targeted advertising directed at children — the Act bars this outright and no exemption available to a school extends it to a vendor.
- No sale of personal data, to anyone, ever.
We do not read an Institution's tenant data ourselves except: to operate the platform in ways the Institution has instructed (for example, running the scheduled compliance and retention jobs described below); or through the audited "sign in as" support flow, which requires the account holder's consent and a fresh step-up assertion from the support engineer, and is never silent. Every such session is its own row in the tenant's audit trail — who started it, whose account, when it ended.
Consent
Processing a child's personal data requires verifiable parental consent. The Compliance module records who gave consent, when, and by what method — a tick-box on an admission form is deliberately not accepted as verification on its own; the method itself is recorded, because that is what the Act's implementing rules require it to mean.
Withdrawing consent is built to be exactly as easy as giving it: withdrawal is not placed behind the step-up re-authentication that guards higher-risk actions elsewhere in the compliance console, because a re-authentication challenge on the way out and not on the way in is precisely the friction the Act forbids. Withdrawal does not undo processing already lawfully carried out, and some records must still be retained where the law requires it — see "Retention & erasure".
Your rights
A student, parent or staff member can ask to access, correct, or erase their personal data. This is a real workflow in the Compliance module, worked by the Institution's own staff — not an email to a developer. The Act sets a 90-day ceiling on a response; an Institution's own published service commitment is often shorter, and the platform tracks and surfaces whichever deadline binds first, on a dashboard, before it is missed.
Every record-level read behind a rights request is itself logged — who looked, at what, under what authority — because accounting for the platform's own reads is treated as part of honouring the right, not separate from it.
To exercise a rights request, use the request flow published in your Institution's own privacy notice or Compliance module. For a request about NexusGrade's own handling of platform-level data (rather than a specific Institution's tenant data), see "Contact", below.
Retention & erasure
Every data class an Institution holds carries its own retention policy with a statutory citation, a retention period, and — for anything touching a data principal's request — a minimum floor of one year: the Act's implementing rules set that floor as a limit in both directions, and erasing too early is treated as seriously as keeping data too long.
Before an erasure job runs, the person affected — or, for a minor, the verified parent of record — receives advance notice, so erasure is never a surprise. A legal hold can freeze erasure for a specific record while litigation or a statutory obligation requires it; an erasure job checks for an active hold before it runs, not after.
Security & access
Access resolves as capability × scope against a person's actual appointment, not a job title — see Security & compliance for the full model. Every sensitive read is logged, not only every write, and the highest-risk compliance actions — releasing a rights-request export, scheduling an erasure, placing or lifting a legal hold, filing a breach report, reading the access-log itself — require a fresh authentication assertion, not a standing session.
Sensitive integration credentials, such as payment-gateway and AI-provider keys, are stored encrypted rather than in plain text, and are never exposed back through the interface once saved.
Data residency
Institution data is hosted within India, and every table carries a tenant boundary enforced by the same authorisation model at the query layer — one institution's data does not become reachable because another institution's console had a mistake in it.
Breach notification
A personal data breach is worked through a dedicated incident workflow: an initial intimation to the Data Protection Board without delay, followed by a detailed report, and notification to affected data principals — each step gated behind the same fresh-authentication requirement as the rest of the compliance console, because a false or altered filing here is its own offence. Moving the recorded discovery time of an incident is treated with the same gate as filing the report itself, since it moves the statutory clock.
Children's data
The Act treats anyone under 18 as a child, and restricts processing their data beyond what admission, attendance, examination and safety purposes require. In practice that shapes real product decisions: attendance-shortage alerts are reported as counts per section, never a named "students to watch" list — the Act prohibits processing likely to have a detrimental effect on a child's wellbeing, and a broadcast judgement attached to a named child is exactly that. A teacher who needs the names has them in their own register, behind a capability check and a read log, not a broadcast.
When a data principal turns 18, the consent seat itself moves from the verified parent to the person, recorded as its own event in the compliance history — adulthood is not something a school has to remember to update by hand.
Grievance redressal
A grievance about how your own Institution handles your data should first go to the Institution's own Grievance Officer, published in its own notice. A grievance about NexusGrade's own conduct as processor goes to the platform Grievance Officer named on the Grievance officer page. Only after that process has been exhausted and answered does a complaint to the Data Protection Board of India become available, as the Act provides.
Changes & contact
We will post any material change to this notice here with an updated "last updated" date. Because this document is still in draft, expect it to change more than a finished notice would as counsel review lands.
Questions about NexusGrade's own data-protection practices, or about this notice itself, can be sent to dpo@nexusgrade.com. For anything about a specific Institution's records — yours or your child's — the request goes to that Institution first; see "Your rights", above.
NexusGrade's registered legal entity name, CIN, GSTIN and registered office address are [to be added on legal review] and will appear here once confirmed.