Skip to content

Legal centre

Policies for schools, staff and parents

Section 1 of 13 · Who is responsible

HomeData protection terms

Data protection terms

How we handle the personal data in your school’s Scoolin account, as your Data Processor under the Digital Personal Data Protection Act, 2023.

Last updated 15 Oct 2026

Section 1Who is responsible

These data protection terms are part of the terms of use between the school and HeySERP Marketing Services. They are the contract between a Data Fiduciary and its Data Processor that the Digital Personal Data Protection Act, 2023 (the DPDP Act) and its rules ask for.

  • The school is the Data Fiduciary. It decides what personal data to keep in Scoolin and why.
  • We are the Data Processor. We process that data only to run Scoolin for the school, on its instructions.

For the data we collect for our own purposes, such as sign-ups, billing contacts and website enquiries, we are the Data Fiduciary, and the privacy policy applies.

Section 2What we process

Whose data: students, their parents and guardians, the school’s staff, visitors to the school, admission enquiries, and anyone else the school records.

What data: whatever the school chooses to keep in Scoolin, which may include names, dates of birth, contact details, addresses, photos, class and admission details, attendance and gate-scan times, fees and receipts, marks and results, behaviour notes, leave, library loans, certificates, ID cards, health notes (such as allergies and blood group), category, religion, government identity numbers (such as Aadhaar, APAAR and PEN) and fields the school adds itself.

Why: to provide, secure, support and improve Scoolin for the school, as the terms of use describe.

How long: for as long as the school’s account is open, then as section 10 says.

Section 3Our promises

As the school’s Data Processor, we will:

  • process school data only to provide Scoolin, on the school’s documented instructions (the terms of use, and what the school and its users do in Scoolin), unless Indian law requires otherwise, in which case we will tell the school where the law allows;
  • not sell school data, use it for advertising or profiling, or use it to train artificial intelligence models;
  • make sure our staff and contractors who can reach school data need it for their work and are bound to keep it confidential;
  • take the reasonable security safeguards in section 5;
  • use other service providers only as section 6 allows, under written terms that protect the data at least as well as these; and
  • help the school, as described below, meet its duties under the DPDP Act.

Section 4The school’s promises

The school confirms, and is responsible, that:

  • it has a lawful reason under the DPDP Act for every piece of personal data it keeps in Scoolin, and keeps only what it needs;
  • it gives the notices, and gets the consents, the law requires, including verifiable consent of a parent or lawful guardian before processing a child’s data where the law requires it. Where the school relies on an exemption meant for educational institutions, it decides that the exemption applies and keeps to its limits;
  • it records government identity numbers, such as Aadhaar, only where the law allows it to;
  • its instructions to us are lawful; and
  • it answers requests and grievances from the people its data is about.

Section 5How we protect it

We take reasonable security safeguards suited to a school’s data. Today they include:

  • Separate schools. Every school’s data is kept apart, and every request is checked against the school it belongs to, with a database-level rule as a second guard.
  • Role-based access. Each user sees only what their role allows. The server leaves out what a role can’t see. Contact, health and personal details of students are separate levels of access.
  • Encryption in transit. Scoolin is served only over HTTPS.
  • Sealed identity numbers. Aadhaar, passport, visa and national ID numbers are stored encrypted and shown masked; only the last four digits are shown by default.
  • Safe sign-in. Passwords are stored as Argon2id hashes, never as written. One-time codes and sign-in links are stored only as keyed hashes, expire quickly, and are limited in tries. Repeated failed logins lock the account for a while. Passkeys are supported.
  • Sessions. Session cookies can’t be read by scripts and are sent only over HTTPS. Users can log out of one device or every device, and a school can switch off any user’s access at once.
  • Limits. Requests are rate-limited, and the public pages that check an ID card or certificate are limited and show only what the privacy policy lists.
  • Records of changes. Changes to student records and marks are logged with who made them.

We review and improve these safeguards over time, and will meet the minimum safeguards the DPDP rules set as they come into force. We may change a safeguard as long as overall protection is not reduced.

Section 6Service providers

The school agrees that we may use these service providers to run Scoolin, each only for the job listed:

  • Vultr (Delhi, India): hosting the application, database and uploaded files.
  • Emailit: delivering email, such as sign-in codes, fee reminders and gate alerts. A school can choose to send through its own email server instead.
  • Lemon Squeezy (merchant of record): taking payment for Scoolin subscriptions. It receives the school’s billing contact and payment details, never student data.
  • Google: “Sign in with Google”, if a user chooses it; book details looked up by ISBN (only the ISBN is sent); and India’s public holiday list.
  • Open Library: book details looked up by ISBN, when Google has none (only the ISBN is sent).
  • Cloudflare Turnstile: telling people from bots on sign-in forms.
  • Gravatar: showing a user’s profile picture, if they have one there (a one-way hash of the user’s email is sent).
  • Sentry, where enabled: reporting errors so we can fix them, with personal details removed before sending.

We will tell school owners by email at least 14 days before we add or replace a provider that will process school data. If the school objects on reasonable data protection grounds, it can end its paid plan before the change and get a refund of the unused part of any period paid in advance. We remain responsible to the school for our providers’ processing of school data, subject to section 12.

Section 7If something goes wrong

If we become aware of a personal data breach affecting school data, we will:

  • tell the school owner without undue delay, with what we know about what happened, the data and people likely affected, and what we are doing about it, and keep them updated as we learn more;
  • take reasonable steps to contain it and reduce harm; and
  • help the school, as far as we reasonably can, to inform the Data Protection Board of India and the people affected, as the DPDP Act and its rules require.

We also report cyber security incidents to CERT-In where Indian law requires us to. Telling the school about a breach is not an admission of fault.

Section 8Requests from people

Students, parents, staff and others have rights over their data under the DPDP Act, such as to get a summary of it, to have it corrected or completed, and to have it erased.

  • Most requests can be met by the school itself in Scoolin, which lets it see, correct, export and delete records.
  • If someone sends such a request to us about school data, we will pass it to the school and won’t answer it ourselves unless the school asks us to or the law requires it.
  • Where the school can’t meet a request in Scoolin, we will help it within a reasonable time, normally 7 working days of its asking.

Section 9Where data is kept

School data is stored with our hosting provider named in section 6. Some of our service providers may process limited data outside India, only for the job listed. We will not transfer personal data to any country or territory that the Government of India restricts under section 16 of the DPDP Act.

Section 10Keeping and deleting data

  • School data stays in Scoolin while the school’s account is open, until the school deletes it.
  • When a school asks to close its account, its data is kept for a 30-day grace period, then permanently deleted, together with its uploaded files.
  • The history of changes to records is kept for 90 days. Sent-email records are kept for 30 days after sending.
  • We may keep security logs, and records the law requires us to keep (such as invoices, and logs the DPDP rules or CERT-In require), for the periods the law sets, after which they are deleted.

The school should export what it needs before closing its account. Once deleted, data can’t be recovered.

Section 11Information and checks

On the school owner’s written request, no more than once a year (or after a breach affecting the school), we will answer reasonable written questions about how we protect school data. Any information we share is confidential. We don’t offer on-site audits, except where the law requires them; then they happen with reasonable notice, during working hours, at the school’s cost, and without access to other schools’ data.

Section 12Liability

Each of us is responsible for our own duties under the DPDP Act and these terms. Our liability under these data protection terms is part of, and counts towards, the total limit in section 13 of the terms of use.

Section 13Grievance officer

Our grievance officer is Sunny Kumar, [email protected], +91-9258583838, at HeySERP Marketing Services, Plot No. 17, S/F, Sector 7 Dwarka, New Delhi, India.

Questions about this page?Write to us from the contact page and we’ll answer in plain words.