← Back to NIKSHA OS

NIKSHA OS — Privacy Policy

Document version: 3.0
Last updated: 8 August 2026
Applies to: the NIKSHA OS mobile application for Android (package com.nikshaos.app), the NIKSHA OS web application, and the related backend services (together, the "Service").

1. Who we are, and our role

NIKSHA OS is a school-management platform. Schools and school groups ("Institutions") use it to run admissions, student records, attendance, examinations, fees, transport, hostel, library, health/infirmary records, staff administration and parent communication.

Two different roles apply, and the difference matters for your rights:

• The Institution is the Data Fiduciary (controller) for personal data about its students, parents and staff. The Institution decides what to record and why. We process that data on the Institution's instructions.
• We are the Data Processor for that data. Separately, we are the Data Fiduciary for the limited account, device and operational data we need to run the Service itself (for example login records, audit logs and diagnostic information).

This policy is written to be consistent with India's Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 (notified 14 November 2025; substantive compliance obligations apply from 13 May 2027), the Information Technology Act, 2000 and its rules, and the Google Play Developer Program and Data safety requirements.

Operator: NIKSHA OS, contact address — pending
Privacy / Data Protection contact: support@nikshaos.in
Grievance Officer: grievance officer name — pending, grievance officer designation — pending, support@nikshaos.in
Support: support@nikshaos.in

2. How accounts work

There is no public sign-up. You cannot create a NIKSHA OS account yourself. Every account is created by an Institution for its own staff, parents and students. You sign in with your mobile number and a one-time password (OTP); there is no password to set or remember.

This means the Institution — not you, and not us — decides who has an account, what role they hold, and what data is recorded about a student.

3. What we collect and process

3.1 Information provided by the Institution or its users

3.2 Information collected automatically

• Device and app information — app version, device model and operating system version, used for support and compatibility.
• Push notification token — a device identifier issued by Firebase Cloud Messaging so we can deliver notifications to your device.
• Session and security data — authentication tokens, session records, and OTP request records used to sign you in and to rate-limit abuse.
• Audit logs — a record of significant actions taken in the Service, including who acted, what they acted on, the time, the IP address and the browser/app user-agent. These exist so an Institution can investigate misuse of its own data.
• Policy acceptance records — when you accept this policy or our terms, we record the policy version, your user and role, the timestamp, the IP address, the user-agent and a device identifier, so the Institution can demonstrate who agreed to what and when.

3.3 Location

We collect location in two distinct situations, both of them while the app is in use. We do not collect location in the background, and the app does not request the Android background-location permission.

• Staff attendance. When a staff member checks in or out, the app takes a single precise GPS fix and sends it with the check-in. The server compares it against the school's configured geofence (its centre point and radius) and records the coordinates, the accuracy, the distance from the school, whether a mock-location app was detected, and whether verification succeeded. This exists to prevent attendance fraud. This applies to staff only — we do not track the location of students or parents.
• School transport. Where an Institution operates the transport module, the position of a school vehicle is recorded during a trip so that the school and parents can see the bus location. A parent can see a vehicle's position only while it is running a trip that is carrying their own child. This is the location of the vehicle, not of any individual.

3.4 Camera and photographs

The camera is used to capture student and staff photographs, to attach documents and evidence, and for staff face check-in (§3.5). Photographs and documents you upload are stored as described in §6 and served only through short-lived expiring links.

3.5 Face data used for staff attendance — please read this carefully

Where an Institution enables face-verified staff attendance:

• Who this applies to. Staff members only. There is no face recognition of students anywhere in the Service.
• What happens. When a staff member enrols or checks in, the app captures a small cropped image of their face and sends it over an encrypted connection to our own server.
• What we store. Our server converts that image into a mathematical representation (a numeric "embedding") and stores only that. The facial image is processed in memory and is not written to storage and not logged. The embedding is a list of numbers, not a photograph, and is not designed to allow an image of your face to be reconstructed from it.
• Where it is processed. The conversion happens on our own infrastructure. The facial image is not sent to any third-party or external AI service.
• How matching works. Matching is performed on our server. The app cannot declare a match by itself, and the stored embedding is never sent back to any device.
• This is biometric data. We treat it as sensitive. It is used only to verify staff attendance and for no other purpose. It is never used to identify anyone outside that function, and it is never sold or shared for advertising.
• Retention. When a face enrolment is revoked by your school, the record is marked revoked and retained as an audit record. When you delete your account, your face template is permanently erased — see §11.

Face verification is a function the Institution enables. A staff member who does not wish to enrol should raise this with their Institution, which is responsible for offering an alternative attendance method.

Note that a separate feature — unlocking the app with your device fingerprint or face — uses only your device's own biometric check. That never captures, transmits or stores any image or biometric template; the device simply tells the app "yes" or "no".

3.6 AI-assisted features — enabled by default

The Service includes optional AI assistance (for example an assistant that answers questions about data you can already see, and parent-facing insights).

Please note: AI features are currently switched ON by default for each school. An Institution can have them limited or switched off, but they are not off until someone asks.

When you use an AI feature:

• The text you type, and the relevant context from data you are already authorised to see, is sent to a third-party AI provider — Anthropic (United States), or OpenRouter (United States) where an Institution's deployment is configured to use it — to generate a response.
• That text may include personal data about students if you type it or if it forms part of the context of your question.
• Your conversation is stored in the Service so you can see your own history.
• We record usage metadata (which feature, which model, token counts, cost and latency) for cost control. This metadata does not contain your message text.
• We do not authorise the AI provider to use your data to train its models. How the provider actually handles data it receives is governed by that provider's own terms and our contract with it, which we cannot vary unilaterally.

AI output is assistive and can be wrong. It must be checked by a human before it is relied on. See AI Usage & Disclaimer.

3.7 Two limitations we want to state plainly

• Aadhaar. The masking described in §3.1 applies to the bulk enrolment import. On the walk-in admissions form, an Aadhaar number submitted through the API is discarded and never stored at all. We state this so the masking claim is not read as broader than it is.
• Retention. Please read §10 carefully. With one exception, the Service does not currently delete personal data automatically.

3.8 What we do not do

• We do not sell personal data.
• We do not use student data for advertising, and we serve no advertising.
• We embed no advertising SDKs, no third-party analytics SDKs, no behavioural tracking and no crash-reporting SDKs in the app. We do not use Google Analytics, Firebase Analytics, Firebase Crashlytics or Sentry.
• We do not collect your advertising ID, IMEI, MAC address or SIM serial.
• We do not collect your contacts, your calendar, your call logs, your SMS messages or your web browsing history.
• We do not track your location in the background.
• We do not perform face recognition on students.

4. Permissions the app asks for, and why

The app does not request permission to record your screen. It previously declared Android's screen-capture and foreground-service permissions for a teacher screen-sharing feature. That feature has been removed, and those permissions have been removed with it.

4.1 What we tell you before we use the microphone or camera in a class

Before a live class first turns on your microphone or camera, the app shows an explanation — not just Android's permission box. It tells you who can hear and see you, that a student joins muted with the camera off, that audio and video are sent live to run the class and are not recorded unless your school has switched recording on, and that you can decline and still take part. You can mute or turn your camera off at any time from the controls on screen.

4.2 Protection of class content

While you are viewing a live class, a class recording, or a lesson, the app asks Android to block screenshots and screen recording of that screen. This protects other people's children from being captured and shared, and protects the school's teaching material.

Please understand its limits, because we would rather be accurate than reassuring: this only stops the screenshot and screen-recording features built into the operating system. It cannot stop someone photographing the screen with another device, and it can be bypassed on a modified or "rooted" phone. It is a meaningful deterrent, not a guarantee. It applies only to class content — ordinary parts of the app, such as a fee receipt, can still be screenshotted normally.

5. Why we process personal data

• To authenticate you and keep accounts secure (OTP verification, rate limiting, session validation).
• To operate the modules the Institution uses — admissions, attendance, exams, fees, transport, hostel, library, health, communication.
• To send service notifications (results published, fee due, attendance alerts, transport updates).
• To verify staff attendance and prevent attendance fraud.
• To maintain security, investigate misuse and keep audit records.
• To provide AI assistance where enabled (§3.6).
• To meet legal obligations.

Our legal basis is the performance of our contract with the Institution and the Institution's own lawful basis for processing its students' and staff data. Where the law requires consent — including verifiable parental consent for a child's data beyond the school's educational function — the Institution is responsible for obtaining it. See Children's Data & Consent.

6. Where data is stored

• Database. Core service data is held in a managed Supabase Cloud PostgreSQL database hosted in India (Mumbai region). Production moved to it from our own servers on 8 August 2026. Our previous self-managed database is retained, in read-only form and in India, solely as a fallback.
• Application servers. The API and application services run on infrastructure we manage ourselves, located in India.
• Files, documents and photographs. By default these are stored in our self-managed storage. For Institutions that have been explicitly moved to it, files are instead stored in Cloudflare R2 object storage (bucket niksha-storage). This migration is currently limited to a single approved pilot Institution; every other Institution remains on self-managed storage. Cloudflare R2 is currently configured with an automatic region setting, so we cannot presently guarantee that these objects are stored only in India — this is recorded as an open item.
• Access to files. Storage is private. Files are never publicly readable. They are served only through expiring signed links (15 minutes).
• Separation between Institutions. Every stored object's path begins with the organisation and school identifier, and database access is restricted by row-level security so one Institution cannot read another's data.
• Backups. Encrypted database backups are taken for disaster recovery.

Planned change: we intend to widen Cloudflare R2 storage beyond the single pilot Institution. That has not happened yet. We will update this policy and notify Institutions before it does.

7. Who we share data with

We share personal data only as needed to run the Service. We do not share personal data with advertisers or data brokers.

Within the Service, data is visible to the Institution and its authorised staff under role-based access control: a parent sees only their own children; a teacher sees only their classes; clinical health records are restricted to health staff and authorised leadership, while teachers see only the minimum safety facts (for example an allergy alert).

Service providers who process data on our behalf:

Also disclosed to authorities, where required by valid legal process.

A current and fuller list, including integrations that exist in the product but are switched off, is in Sub-processors.

Online fee payment. The Service contains an integration with Razorpay for online fee payment. Based on our audit, this integration is not currently active in production; no payment data is currently transmitted to Razorpay. Where an Institution enables it, card details are entered into Razorpay's own checkout and are never received or stored by us. We hold only the payment reference, amount and receipt.

8. International transfers

Core service data is held in India. Some service providers — currently Google (Firebase Cloud Messaging), Anthropic, and OpenRouter where configured — process limited data outside India. Where that happens we send only the minimum necessary data, rely on contractual safeguards, and do not transfer personal data to any jurisdiction restricted by the Central Government under the DPDP Act. The storage region for Cloudflare R2 is an open item recorded in §6.

9. Security

We take technical and organisational measures appropriate to the sensitivity of the data, including:

• Encrypted transport (HTTPS/TLS) for all network traffic. The Android app blocks unencrypted connections in production builds.
• Authentication tokens stored in the device's secure keystore; short-lived, revocable sessions validated on every request.
• Role-based access control, plus database row-level security enforcing Institution, school and "your own child" boundaries.
• Storage that is private by default and reachable only through short-lived signed links.
• Face data stored only as a non-reversible numeric embedding, never as an image, and never returned to any device (§3.5).
• Sensitive tokens — pickup OTPs and QR codes — stored only as one-way hashes.
• Screenshots and screen recording blocked by the operating system while class content is on screen, within the limits described in §4.2.
• Offline drafts held on your device in an encrypted database, with the key in the device keystore. Android backup is deliberately disabled so school data is never copied to a personal cloud account.
• Audit logging of significant actions.
• Encrypted backups.

No system is perfectly secure, and we do not claim otherwise. We cannot guarantee that the Service will never be compromised. See the Security & Responsible Disclosure Policy.

10. How long we keep data — and an honest limitation

We keep personal data for as long as the Institution's account is active and as long as needed to provide the Service, and longer where the law requires it (for example financial records).

We want to be straightforward about the current position rather than describe an intention as though it were already built:

• The Service does not currently delete most personal data automatically. In practice, records are retained until someone deletes them deliberately — or until you delete your account (§11), which does erase the personal data listed there immediately.
• Where a record is "deleted" in the app, it is in many cases marked as deleted rather than erased, and remains in the database.
• Staff face enrolments revoked by a school are retained as audit records (§3.5). Deleting your account erases the template outright (§11.2).
• Staff check-in records, including their GPS coordinates, are retained indefinitely.
• School-vehicle position history has a 30-day retention rule defined in the database, but that rule is not currently scheduled to run, so older positions may persist.
• Files in storage are not automatically removed when the record that referenced them is deleted.
• Audit logs, AI conversations and notification records currently have no automatic expiry.

Reducing these retention periods and automating deletion is planned work. Until it exists, an Institution or individual who wants data removed should use §11.

Our stated intentions are in the Data Retention & Deletion Policy, which should be read together with this section.

11. Deletion, and your rights

11.1 Deleting your account

You can delete your account yourself, in two ways.

In the app. Go to Profile → Delete account. The app explains what will be removed, then asks you to confirm your identity with a one-time password sent to your registered mobile number, and to type DELETE. This is deliberate friction: the action cannot be undone. Once confirmed, it takes effect immediately and you are signed out of every device.

On the web, without the app. Visit https://nikshaos.in/delete-account. That page explains the process and how to request deletion by email if you can no longer sign in — for example because your access was already removed, or you no longer have the phone number on the account. We verify that a request genuinely comes from the account holder before acting on it, which protects you from someone else deleting your account. We aim to acknowledge within 7 days and complete verified requests within 30 days.

11.2 What deletion actually does

Erased:

• Your ability to sign in. Every session and sign-in token is destroyed immediately, and your memberships are revoked.
• The personal details on your user account — your name, mobile number and email address.
• Your device push-notification registrations.
• Your face-verification template, if you are a staff member who used face check-in. This is permanently erased, not merely marked revoked.
• Your AI assistant conversation history.
• Your saved app preferences.
• Any unused one-time passwords for your number.

Kept, because it belongs to your Institution and not to us:

• Student academic records, attendance registers, and examination results.
• Fee, invoice and receipt records — financial records carry statutory retention periods.
• Health and infirmary records, where the Institution operates that module.
• Staff employment and payroll records, where you are or were an employee. These are the Institution's HR records and are commonly required to be kept for tax and employment law.
• Audit and safeguarding records, which exist precisely so that actions can be accounted for afterwards and are therefore never rewritten.

Where these records mention you, your Institution is the data controller. To have them corrected or removed, contact your Institution directly — it decides, and we act on its instruction. If you ask us and we cannot act ourselves, we will tell you so and point you to the Institution.

11.3 If you need access again after deleting

Deleting your account cannot be undone, and it does not bring back the personal data we erased.

Because your Institution's own records survive (§11.2), it can restore your access to the app without re-creating anything — your children remain linked to you, and a student's academic history is untouched. When it does, it supplies your name and mobile number from its own records, and you sign in again with a one-time password as usual. We do not recover your previous email address, saved preferences, AI conversation history, or face-verification enrolment — those were deleted, and they stay deleted.

Only authorised Institution staff can do this, only for a person already recorded at their own Institution, and every such action is logged. If the mobile number you used has since been taken by someone else's account, your Institution will not be able to restore access to that number.

11.4 Your other rights

Subject to the DPDP Act and your relationship with your Institution, you may:

• Access and correct your personal data.
• Request erasure of personal data that is no longer required.
• Withdraw consent where processing relies on consent.
• Nominate another person to exercise your rights.
• Raise a grievance with us and, if unresolved, with the Data Protection Board of India.

Because the Institution is usually the Data Fiduciary, requests about student, exam, fee, attendance or health records are directed to your Institution first; we assist the Institution in responding. To exercise a right or raise a grievance, contact support@nikshaos.in, or our Grievance Officer grievance officer name — pending at support@nikshaos.in. We aim to respond within the timelines the law requires.

Data export. The Service does not currently provide a self-service data export. An Institution that needs a copy of its data should contact us.

12. Features that are present in the app but NOT active

We list these because the app contains code and permission declarations for them, and we would rather explain that than leave it unexplained. None of the following is currently switched on, and none of it is currently collecting any data.

• Live online classes (Digital Learning Platform). The app contains a live audio/video classroom, including microphone use, class recording, per-student participation logging and per-student video-watch progress. It would use LiveKit real-time video infrastructure, to which a participant's display name would be sent as their call identity. It is disabled in the released app and the supporting infrastructure is not deployed. No live class can be joined, no microphone or camera can be activated for a class, and no recording exists.
• Class recordings and recorded-lesson playback. Part of the same feature, and equally inactive.
• Teacher screen sharing has been removed entirely — it is not in this list because it is no longer in the app at all. The Android screen-capture and foreground-service permissions it required have been removed with it (§4).
• Wider use of Cloudflare R2 beyond the single pilot Institution (§6).
• Optional integrations that are switched off: Twilio, SendGrid, MSG91, Gupshup, Meta Graph API (Facebook/Instagram publishing), and Voyage AI embeddings. While off, no data is sent to them.

We will update this policy, and tell Institutions, before any of these becomes active. In particular, recording a child's voice or image in a live class would require its own consent step, which does not exist today.

13. Children's data

The Service is used by and about children in a school setting. Students do not sign themselves up — an Institution enrols them.

• We process children's data only to deliver school services, on the Institution's instructions.
• Verifiable parental consent is the Institution's responsibility, and the Institution confirms to us that it has obtained it.
• We do not undertake behavioural tracking or targeted advertising directed at children, and we serve no advertising at all.
• We do not transmit advertising identifiers or other persistent device identifiers of the kind restricted for children.
• We do not perform face recognition on students.
• We do not track students' personal location. School-vehicle tracking records the position of the vehicle (§3.3).

See Children's Data & Consent.

14. In-app acceptance

On first login, and whenever a mandatory policy changes materially, we ask you to review and accept the applicable policies before continuing. We record the policy version, your user and role, the timestamp, the IP address, the user-agent and a device identifier. These records are append-only and cannot be altered or deleted afterwards.

The current policies are reachable from the app. If our systems cannot confirm your acceptance status at that moment, the app allows you to continue and re-checks at your next login rather than locking you out.

15. Data breaches

If a personal-data breach occurs, we follow the process in our Security & Responsible Disclosure Policy. As Processor we notify the affected Institution without undue delay and assist it in notifying the Data Protection Board and affected individuals within the timelines the DPDP Rules require.

16. Changes to this policy

We may update this policy as the Service evolves or the law changes. Material changes are notified in the app or through your Institution and recorded in the the document changelog. The "Document version" and "Last updated" fields at the top reflect the current version. Where a change materially affects your rights, we ask you to accept the new version in the app.

17. Contact

NIKSHA OS contact address — pending Privacy: support@nikshaos.in · Support: support@nikshaos.in · Security: support@nikshaos.in Grievance Officer: grievance officer name — pending, grievance officer designation — pending, support@nikshaos.in

If you are not satisfied with our response, you may complain to the Data Protection Board of India.