Privacy Policy

इस नीति को हिंदी में पढ़ें

Effective date: 30 October 2026 Applicable law: India — Digital Personal Data Protection Act, 2023 ("DPDP Act") and the rules made under it, as and when in force.

1. Who we are and the scope of this policy

1.1 EduSphere is a multi-tenant, software-as-a-service school enterprise-resource-planning (ERP) platform for schools in India ("EduSphere", the "Platform", "we", "us", "our"). EduSphere is operated by Avnish Kumar, trading as EduSphere, an individual sole proprietor resident in India, with the principal place of business at A.K Library, Shamli Road, Baghra, District Muzaffarnagar, Uttar Pradesh 251306.

1.2 Two distinct roles. The Platform is a business-to-business service. Each tenant is a school. How the DPDP Act applies to us depends on the role we play:

• (a) When we act as a Data Processor. For the Personal Data that a school and its users enter into, generate within, or upload to the Platform about its students, parents/guardians and staff ("School Data" or "Customer Data"), the school is the Data Fiduciary — it determines the purposes and means of processing — and EduSphere is the Data Processor acting on the school's documented instructions under a Data Processing Agreement (see DATA-PROCESSING-AGREEMENT.md). The school is primarily responsible to its data principals for that data, including for obtaining and maintaining any consent (including verifiable parental consent for children). This policy describes how we handle School Data so that the school and its data principals understand our practices, but it does not replace the school's own privacy notice.

• (b) When we act as a Data Fiduciary. For a limited set of data that we determine the purposes and means for — for example a school's billing and subscription contacts, the account and sign-in details of the administrators and staff who use the Platform, support-ticket correspondents, and privacy-safe product analytics about administrative and staff usage — EduSphere is the Data Fiduciary.

1.3 Scope. This policy covers the Platform's web application, its mobile (Android/iOS) applications, and the public EduSphere marketing website. It does not govern a school's own websites, a school's offline record-keeping, or third-party services a school chooses to use outside the Platform.

1.4 Audience. This policy is written for schools (our customers), for the parents/guardians and students whose data a school processes through the Platform, and for staff who use the Platform. Where an action is the school's responsibility rather than ours, we say so.

2. Personal data we collect

The Platform is configured and populated by each school. The categories below reflect what the Platform is capable of storing; an individual school may use only some of them. Fields marked (children's data) relate to students, who are generally under 18 — see Section 4.

2.1 Student data — (children's data)

• Identity and demographics: first/middle/last name, date of birth, gender, blood group, category, photograph.
• Enrolment: admission number (system-issued, permanent), admission date, class/section, roll number, house, status (active/left), leaving date and transfer-certificate history.
• Optional government identifiers, only if the school chooses to collect them: Permanent Education Number (UDISE+ PEN), APAAR ID.
• Optional health information: allergies, medical notes, and an emergency contact. These are stored encrypted (see Section 5).
• Aadhaar number — optional and OFF by default. The Platform can store a student's Aadhaar number, but this capability is not enabled by default and a school must deliberately turn it on and enter it. When stored, the Aadhaar number is validated (UIDAI Verhoeff check), kept encrypted, never logged or echoed, and shown only through a single audited reveal. Collecting Aadhaar is the school's decision and the school is responsible for having a lawful basis to do so. Counsel should confirm the Aadhaar handling before this feature is enabled in production.
• Documents and media a school uploads about a student: student documents, ID cards, report cards, admit cards, certificates, admission documents.
• Records generated about the student in use: attendance, exam marks and report cards, homework and submissions, quiz results, parent-teacher-meeting notes, leave records, library/transport assignment, and the student's own app login (where the school issues one).

2.2 Parent/guardian data — includes data used to reach families about children

• Name, relationship to the student, mobile number, email address, occupation.
• The guardian's app login (once invited), and consent records linking the guardian to each child and to each privacy-notice version and purpose (see Section 4).

2.3 Staff data

• Name, gender, date of birth, employee code, designation, department, qualification, experience, mobile, email, address, joining/relieving dates, exit reason, emergency contact.
• Payroll data processed by the school: salary/pay components and payslips. The school's payee bank account number used for fee settlement is stored encrypted.
• The staff member's Platform login, role and permission assignments.

2.4 Operational and transactional data

• Fees and payments: fee invoices, receipts, payment method (e.g. UPI/bank transfer), payment proofs and approval status. Fee and payment records are treated as financial records (see retention, Section 7).
• Admissions: enquiry/application data, admission documents, admit cards.
• Transport: routes, stops, vehicle and rider assignments, and — during an active trip only — live GPS location sourced from the driver's phone (used for live bus tracking while the trip is running). The Platform does not continuously track students' personal locations.
• Visitors: visitor-management records captured at the school gate.
• Communications: notices and messages sent to parents/staff and their delivery status, across in-app, SMS and WhatsApp/email channels.
• Support: support tickets and complaints and their correspondence.
• Certificates and exports: generated certificates, report cards and data exports.

2.5 Account, technical and billing data (where EduSphere is the Data Fiduciary)

• Account credentials and authentication data: login identifier (typically mobile), one-time passwords (OTP) sent over SMS, and session/JWT tokens.
• Security and audit logs, including an append-only audit trail of sensitive actions, and sign-in events.
• School subscription, invoicing and payment-for-the-Platform data (billing contact, plan, SaaS invoices and payments).
• Privacy-safe, server-side product analytics about administrative/staff usage — pseudonymised and aggregate only (see Section 10).

2.6 How we obtain this data

Almost all School Data is entered or uploaded by the school and its authorised users, or generated as they use the Platform. We do not buy personal data, and we do not collect personal data from children directly other than through the account the school issues and the actions the student takes in the app.

3. Purposes and legal bases

3.1 For School Data (we act as Processor). We process School Data only to provide the Platform to the school on its documented instructions — to run the modules the school has enabled (admissions, enrolment, attendance, exams, fees, communications, transport, certificates, support and the rest), to secure and back up the data, to provide support, and to meet our legal obligations. The lawful basis for collecting that data from parents, students and staff is the school's responsibility as Data Fiduciary — typically consent (including verifiable parental consent for children), the performance of the school's functions / contract, or a legitimate use permitted by the DPDP Act. We do not decide those purposes and we do not use School Data for our own purposes.

3.2 For data where we are the Data Fiduciary, our purposes and bases are:

3.3 No new or incompatible purposes. We will not use personal data for a purpose that is incompatible with the purpose for which it was collected without a fresh lawful basis.

3.4 Marketing. We do not send marketing messages to students. Any marketing to school decision-makers is sent only with a lawful basis and an easy way to opt out.

4. Children's data

Students are children (generally under 18). The DPDP Act gives children's data special protection, and both the school and EduSphere take the following positions.

4.1 Verifiable parental consent is the school's responsibility. The DPDP Act requires verifiable consent of a parent or lawful guardian before processing a child's personal data. Because the school is the Data Fiduciary for student data, the school must obtain and keep that consent. The Platform helps the school do this: it can present a versioned privacy notice (in English and Hindi) through a consent gate, record per-person, per-child, per-notice-version, per-purpose consent with evidence, ask again whenever a new notice version is published or a new child is linked, and let a parent withdraw an optional purpose at any time from Profile → Privacy. Two guardians of one child each record their own consent.

Note on the shipped notice text. The Platform ships only a clearly marked DRAFT placeholder notice, not approved wording. The actual notice text, the list of purposes, the consent method, retention periods and breach steps must be supplied and approved by qualified legal counsel before the school relies on them. Until counsel marks a notice "legally approved", every screen shows it as DRAFT.

4.2 No tracking or behavioural monitoring of children. Consistent with the DPDP Act's prohibition, EduSphere does not track, behaviourally monitor, or profile children. Concretely:

• The web and mobile apps contain no third-party analytics, tracking, session-replay, attribution or advertising SDKs (independently enforced — see Section 10).
• No analytics event is ever emitted from a student screen. Product analytics are server-side only and the recorder drops any actor who holds the student role; the analytics store cannot even record the student role category.
• We do not use children's data to build advertising or behavioural profiles, and we run no A/B experiments on student screens.

4.3 No targeted advertising to children. We do not serve advertising of any kind in the Platform, and we never direct advertising at children or use children's data for advertising.

4.4 Detrimental processing. We do not process children's data in a way that is likely to cause a detrimental effect on the wellbeing of a child.

4.5 The student's own login. Where a school issues a student their own login, the student can see their own records. Access is scoped so a student sees only their own data.

5. How we secure data

Security is built into the Platform. Key measures include:

5.1 Tenant isolation with database-enforced row-level security. Every school's data is separated at the database level using PostgreSQL row-level security (RLS), applied with FORCE ROW LEVEL SECURITY and a per-transaction tenant context, so one school can never read or write another school's rows — the isolation is enforced by the database, not only by application code.

5.2 Field-level encryption of sensitive values (AES-256-GCM). The most sensitive fields — a student's Aadhaar number (when enabled), health information (allergies, medical notes, emergency contact), and a school's payee bank account number — are encrypted at the field level using AES-256-GCM envelope encryption with a fresh random nonce per value and key wrapping, with blind-index support for lookups where needed. Ciphertext is bound to its field's purpose so a value cannot be copied into another column and still be read.

5.3 Encryption at rest and in transit. Data is transmitted over encrypted connections (TLS). In production, stored files and database storage are held on encrypted infrastructure (for example S3 server-side encryption / KMS where object storage is used).

5.4 Authentication and access control. Access requires authentication via JWT sessions with one-time passwords delivered over SMS (OTP). Access within a school is governed by role- and permission-based access control, with scopes that limit users (parent, student, staff) to the data they are entitled to see.

5.5 Upload scanning and content checks. Files uploaded to the Platform are scanned and content-sniffed to reduce the risk of malicious or mistyped files.

5.6 Audit logging and incident tracking. Sensitive actions are recorded in an append-only audit log. We maintain a breach/incident register to detect, record, assess and respond to security incidents (see Section 11).

5.7 No measure is perfect. We maintain reasonable security safeguards appropriate to the sensitivity of the data, and we review them over time. Schools and users also play a part — for example by protecting their login devices and not sharing OTPs.

6. Sharing and sub-processors

6.1 We do not sell personal data, and we do not share it except as described here.

6.2 Within a school (tenant). School Data is visible to the school's own authorised users according to their role and permissions. It is never shared with another school.

6.3 Sub-processors. To run the Platform we rely on a limited set of service providers ("sub-processors"), engaged under contractual terms consistent with the DPDP Act and our Data Processing Agreement. The categories are:

• Communications providers — SMS, WhatsApp and email providers used to deliver OTPs and the school's notices to parents and staff. SMS in India is sent through DLT-registered sender IDs and templates.
• Object storage — cloud object storage for files and documents (for example Amazon S3 in production, or MinIO / local disk in self-hosted or lower environments).
• Cloud hosting — cloud infrastructure on which the Platform runs (AWS in production).
• In-memory data store (optional) — Redis, where enabled for shared session/state storage.

A current, itemised list of sub-processors with their names and locations is maintained by EduSphere, made available to schools on request (and, where published, linked from this policy), and kept in step with the Data Processing Agreement.

6.4 Legal disclosures. We may disclose personal data where required by law, a lawful order, or to protect the rights, safety and security of users, the public, or EduSphere — limited to what is necessary.

6.5 Business transfers. If EduSphere is involved in a merger, acquisition or asset sale, personal data may be transferred subject to this policy and applicable law; we will give notice where required.

7. Data retention and deletion

7.1 Schools control their data. While a school's subscription is active, the school controls its data and can correct or remove records through the Platform, subject to the business rules below.

7.2 Configurable retention. The Platform provides configurable retention periods per data category. No retention period is hard-coded or applied automatically; every category is OFF until the school's administrator sets a period. The following are the default guidance periods (adjust to your own policy and confirm with counsel / a chartered accountant before relying on them):

These are starting defaults, not legal advice; the exact periods a school applies are set by the school's administrator and should be confirmed with counsel.

7.3 What the retention job may do. Depending on the category, past-period data may be deleted, anonymised (kept but free text cleared), or reported only (counted but never auto-deleted). Financial records (fees/payments) and the append-only audit log are not auto-purged — they are retained as financial/compliance records and their deletion requires counsel's confirmation. A transfer-certificate'd (left) student's record is retained as read-only history.

7.4 Erasure requests. A parent or a student with a login can ask the school to erase data. Only the actions that counsel has confirmed are applied; a request never results in a hard deletion of records the school must keep by law (for example financial records). See Section 8.

7.5 End of subscription. When a school's subscription ends, the school's tenant data is handled according to the Terms of Service and the Data Processing Agreement — typically made available for export for a defined window and then deleted. The Platform includes a foreign-key-safe deletion routine that removes a cancelled school's data in the correct order.

7.6 Backups. Data in routine backups is removed on the ordinary backup rotation after deletion from the live system.

8. Your rights as a data principal

8.1 Under the DPDP Act, a data principal (or, for a child, their parent/lawful guardian) has the following rights. Because the school is usually the Data Fiduciary for student, parent and staff records, you exercise most of these rights through your school; the Platform gives the school the tools to fulfil them, and EduSphere assists the school as its processor.

• (a) Right to access — a summary of the personal data processed and the processing activities. A parent or a student with a login can download their data themselves from within the app; no formal request is needed.
• (b) Right to correction — ask the school to correct inaccurate or incomplete data. The Platform supports a correction request flow.
• (c) Right to erasure — ask the school to delete data, subject to the retention limits in Section 7 (records the school must keep by law are not erased).
• (d) Right to withdraw consent — withdraw consent for any optional purpose at any time, from Profile → Privacy; this is recorded immediately on the consent records.
• (e) Right of grievance redressal — raise a grievance about how your data is handled (see Section 12). Note: the in-product grievance and nomination flows are pending counsel's confirmation before they are enabled; until then, grievances are handled through the contact channel in Section 12.
• (f) Right to nominate — nominate another individual to exercise your rights in the event of death or incapacity, once this flow is confirmed by counsel and enabled.

8.2 Where EduSphere is the Data Fiduciary (account, billing, support and analytics data per Section 2.5), you may exercise these rights directly with us using the contact details in Section 12.

8.3 Verifying requests. To protect data — especially children's data — we and the school may need to verify the identity and authority of the person making a request (for example that a requester is the child's parent/guardian) before acting.

9. Cross-border transfer

9.1 EduSphere is built to be hosted in India. In production, the Platform runs on cloud infrastructure in an Indian region (the default object-storage region is ap-south-1, Mumbai), and server-side product analytics are stored in the Platform's own database in India.

9.2 By default, personal data is stored and processed within India and is not transferred outside India. We will transfer personal data outside India only to the extent permitted by the DPDP Act and any restrictions the Central Government notifies, and only to recipients bound by appropriate safeguards. Any sub-processor located outside India is identified in the sub-processor list (Section 6.3). (The final data-localisation and transfer position should be confirmed with counsel against your production hosting configuration.)

10. Cookies, analytics and tracking

10.1 No third-party trackers. The EduSphere web and mobile apps contain no third-party analytics, tracking, session-replay, attribution or advertising SDKs. This is not just a policy statement — it is enforced in the build: a denylist and the check scripts/check-no-trackers.mjs scan every package manifest and the lock file (so even a transitive tracking dependency fails the build), and a web unit test backs it up.

10.2 Product analytics are privacy-safe and server-side only. Any product analytics are recorded on the server, off by default, never from a student screen, pseudonymised (a keyed hash, never a user's identifier, mobile or email), limited to an allow-listed set of events and properties (short codes, counts or yes/no — never free text, names, amounts or student IDs), recorded by date not time, and available to our platform team only as aggregates. There is no advertising ID and no cross-app tracking.

10.3 Cookies. The Platform uses only the cookies/tokens strictly necessary to keep you signed in and to keep the service secure. It does not use advertising or cross-site tracking cookies. The public marketing website likewise uses only strictly necessary cookies and no advertising or cross-site tracking cookies.

10.4 App-store disclosures. Our mobile app-store "Data safety" / privacy labels state that the app collects no data for analytics or advertising, performs no tracking, and uses no advertising ID.

11. Breach notification

11.1 We maintain a process and an incident/breach register to detect, record, contain, assess and respond to personal-data breaches, with a timeline of actions (reported, contained, assessed, schools notified, authority notified, individuals notified, closed) and a severity rating.

11.2 In the event of a personal-data breach, we will notify the affected schools and the Data Protection Board of India, and (where the school is the Data Fiduciary) support the school in notifying affected data principals, in the manner and within the timelines required by the DPDP Act and its rules. Where EduSphere is the Data Fiduciary, we will notify affected data principals and the Board directly as required.

11.3 Notifications will describe, to the extent known, the nature of the breach, its likely consequences, and the measures taken or proposed to address it and to mitigate harm.

12. Grievance Officer and contact

12.1 If you have a question, a request about your rights, or a grievance about how your personal data is handled by EduSphere, contact:

• Grievance Officer / Data Protection Officer: Avnish Kumar, Founder
• Email: support@edusphere.org.in
• Support email: support@edusphere.org.in
• Postal address: A.K Library, Shamli Road, Baghra, District Muzaffarnagar, Uttar Pradesh 251306

12.2 If your concern is about student, parent or staff records held by a school, the school is the Data Fiduciary and is the first point of contact; please also raise it with your school. EduSphere will support the school in responding.

12.3 We aim to acknowledge and respond to requests and grievances within the timelines required by the DPDP Act. If you are not satisfied with our response, you may have the right to complain to the Data Protection Board of India.

13. Changes to this policy and effective date

13.1 We may update this policy from time to time to reflect changes in the Platform, our practices, or the law. When we make a material change, we will update the effective date below and notify schools through the Platform or by email, and — where required — ask for fresh consent.

13.2 Effective date: 30 October 2026. This document supersedes any previous privacy policy for the EduSphere Platform from that date.