Security & data protection
A school is handing us children's records, so this page states what protects them in terms you can check — and says where we fall short, because a security page that only lists strengths tells you nothing about the one that matters.
Keeping schools apart
One database per school
Your school does not share tables with anyone. Each school gets its own MySQL database, and the connection is switched per request from the school's own address. A query written for one school cannot reach another's rows, because they are not in the same place — this is the difference between real isolation and a school_id column somebody has to remember to filter on.
Roles, then scope
What a person can open is decided twice: their role (what a class teacher may do at all) and their scope (which classes are theirs). A teacher assigned to 6-B sees 6-B's students, attendance, homework and fee records — not the school's. The check runs on the server for every request, not in the app's menu.
Admin writes need a second factor
Super-admin accounts — the ones that can reach across schools — must pass a TOTP challenge before any write. Reading and signing in are never blocked by it; changing something is.
Credentials and encryption
Passwords are hashed, never stored
Passwords go through bcrypt. Nobody at Pathsala can read yours, and neither can anyone who obtained a copy of the database. Password-reset tokens and OTPs are hashed the same way, so a leaked reset row is not a working link.
Your integration keys are encrypted at rest
The Razorpay keys, SMS credentials and mail keys a school connects are encrypted with the application key before they are written, and carry a version marker so old rows migrate as they are saved. They are masked when read back into the admin screens.
Traffic is encrypted end to end
Every school address — including the free subdomain — is served over HTTPS with its own certificate. There is no plain-HTTP path into the application.
Biometrics stay on the device or in your database
Face recognition runs on the phone or tablet at the gate; what reaches the server is a mathematical template, encrypted, in your school's own database — not a photograph, and not reversible into one. Fingerprint verification happens entirely on the person's own phone and never reaches us at all.
How long things are kept
These are enforced by the software, not by someone remembering to run something.
| Record | Kept for | Notes |
|---|---|---|
| Live location pings | 7 days | Pruned automatically on every upload, not by a nightly job that can fail silently. |
| Email send log | 180 days | Answers “did that message go out?” for as long as that is a useful question. |
| Nightly backup of every database | 14 days | Taken at 1:30 AM IST, compressed, restore-tested. |
| Pre-update database snapshots | 30 days | Separate clock, so a nightly copy cannot evict one a rollback needs. |
| A school that leaves | 15 days, then deleted | The account is disconnected first and stays recoverable for the grace period. A snapshot is taken before deletion. |
| Everything else | While your school is with us | Ask for an export or a deletion at any time, trial or paid, and we will do it. |
Backups
Every night, every database
At 1:30 AM IST every database is dumped in full — your school's, and the platform database that holds logins, plans and subscriptions. A school's records are not much use without the second one, so both are taken together. Copies are compressed and kept for 14 days, so there are fourteen different days to go back to rather than one.
And again before anything risky
Separately, before any release that changes a school's database structure, that school gets its own snapshot, kept 30 days on its own clock so a nightly copy can never evict it. If the snapshot cannot be taken, the update refuses to start rather than proceeding with no way back. One is taken before a leaving school's database is deleted, too.
They have been restored, not just written
A backup nobody has restored is a file, not a backup. Ours are restored into a scratch database and checked table by table and row by row against the original. Doing that is how we found that they did not restore: a handful of wide tables could not be re-created on import and the restore stopped partway through. That is fixed, and every backup file now carries what it needs to be restored by hand with one command.
What is still missing
The copies sit on the same machine as the databases. That protects you from a bad release, a wrong delete or a corrupted table — not from that machine being lost. Copying them off the machine is the next thing on this list, and until it is done this paragraph stays here.
Where the data is, and who else touches it
Your school's records are on a server in India. Some things necessarily leave it, and the privacy policy names every one of them and says exactly what each receives — email through Brevo, push notifications and sign-in through Google, live classes through Jitsi, online fee payments through Razorpay.
If something goes wrong
India's Digital Personal Data Protection Act, 2023 requires us to report a personal data breach to the Data Protection Board and to the people affected. If your school's data is ever exposed, you will hear it from us — what happened, what was reached, and what to do about it.
We hold no external security certification — no ISO 27001, no SOC 2 — and have not been through a third-party audit. Anyone claiming otherwise about us is wrong. What we can offer instead is this page, the privacy policy, and answers to any question your IT person wants to put to us directly.