Trust

Security and data

A school is handing over its students’ records. This page is the specific answer to “what happens to them”, not a page of badges.

Last updated 26 July 2026

One school cannot see another

Separation between schools is not a setting that can be misconfigured — it is built into how data is read. Every record belongs to exactly one school, and every query the application makes is scoped to the school of the signed-in user before it runs. There is no screen, no export and no report that can return another school’s rows, because there is no code path that asks for them.

Inside a school, role decides what you see

Access is checked against the signed-in user’s role on every request — not hidden in the interface and trusted to stay hidden. In practice:

  • a teacher sees the classes they are assigned to, and marks and attendance for those students;
  • an accountant sees fees, invoices and payments, not academic records;
  • a librarian sees the catalogue and circulation, not fees or marks;
  • a parent sees their own child and nothing else — never another family’s records;
  • an administrator sees the school, and decides who holds which role.

Because the check happens on the server for every request, a user cannot reach data by editing a URL or a page in their browser.

Credentials

Passwords are stored as bcrypt hashes and never in plain text — we cannot read a user’s password, and neither can anyone who obtained a copy of the database. Sessions are authenticated per request, and an administrator can revoke a person’s access immediately when they leave.

Documents and photographs

Admission documents, certificates and student and staff photographs are held in private object storage. Nothing there is publicly readable and nothing can be found by guessing a URL: when an authorised user opens a document, the application issues a signed link that works for a few minutes and then stops working. Copying that link to someone else does not give them lasting access.

Payments

Online fee payments are handled by Razorpay. Card numbers, UPI IDs and banking credentials are entered on Razorpay’s checkout and never reach Vidyum’s servers, so there is no card data in our systems to lose. Money settles to the school’s own payment account — it does not pass through us. Payment confirmations arriving back into Vidyum are cryptographically verified before any fee is marked as paid, so a forged confirmation cannot clear a fee.

In transit

Every connection to Vidyum and to this website is encrypted with HTTPS, and plain HTTP requests are redirected to it rather than served.

Your data remains yours

A school’s records belong to the school. They are not sold, not shared between schools, and not used to train anything or to build products for anyone else. A school can export its data while it is a customer and when it leaves — see the Terms of Service and the Privacy Policy for how that works.

What we don’t claim

We would rather be specific than impressive. Vidyum does not currently hold an external security certification such as ISO 27001 or SOC 2, and we are not going to imply one with a badge. If your school needs documented answers on backups, data residency, retention periods or a security questionnaire, ask us at hello@vidyum.in and you will get a direct answer about your deployment rather than a link back to this page.

Reporting a vulnerability

If you believe you have found a security problem, email hello@vidyum.in with enough detail to reproduce it. Please give us a reasonable chance to fix it before disclosing it publicly. We will not pursue anyone who reports an issue in good faith and does not access or alter other people’s data while finding it.