Security
A school ERP holds children's records. That changes the threat model.
Every control below is implemented in the product today. Nothing on this page claims a certification, because a certification is an audit rather than a feature.
Controls in the product
Grouped by what they actually prevent rather than by compliance framework.
Tenant isolation
Every record carries the organisation it belongs to, and queries are scoped to it. One school cannot read another's data.
Role-based access
Administrators, teachers, parents and students each get a distinct portal. A teacher's marks grid covers their own sections and nothing else.
Audit log
Actions are recorded against a user, an organisation and the specific entity affected — so 'who changed this mark' has an answer.
Invitation-only parent access
Guardians are invited against a specific student. Nobody registers their way into a child's record with an admission number.
Rate-limited authentication
Sign-in endpoints are rate limited per IP, which is what turns a credential-stuffing run into a wasted afternoon.
Signed payment webhooks
Every Razorpay webhook is HMAC-verified before it is processed, and duplicate deliveries are no-ops rather than double credits.
Hardened response headers
Framing denied, MIME sniffing off, a strict referrer policy, and camera, microphone and geolocation disabled by default.
Student data kept out of search
Result lookups and certificate verification carry noindex directives and a matching response header. A child's marks do not belong in a search index.
Immediate certificate revocation
The verification page is never cached, so a revoked certificate reads as revoked on the very next check.
Visible impersonation
When a support session is impersonating a user, a banner says so for the whole session. Silent impersonation is not available.
Soft deletes
Records are marked deleted rather than destroyed, so a mistaken deletion is recoverable and the audit trail stays intact.
Error monitoring
Server and client exceptions are reported to Sentry, so a failure in fee collection is noticed before a parent reports it.
The two decisions worth explaining
Result pages are crawlable and noindexed, not blocked. The instinct is to add a Disallow to robots.txt. That is the wrong tool: a blocked URL is never fetched, so the crawler never reads the noindex directive on it — and can still list the bare URL on the strength of an inbound link. Blocked is not the same as noindexed. To keep a page out of the index you have to let the crawler in to read the instruction.
Certificate verification is never cached. A cached “valid” for a certificate revoked an hour ago is the one failure this feature cannot have. The verification page is rendered fresh on every request, which costs a little performance on a page whose entire purpose is to be correct at the moment it is read.
Security questions we get asked
Can one school see another school's data?
No. Every record is scoped to the organisation that owns it, and queries are filtered by that organisation. The only deliberate exception is the shared board catalogue — CBSE is CBSE for every school — which contains no student data.
Are student results indexed by search engines?
No. Public result lookup and certificate verification pages carry noindex directives in their metadata and a matching X-Robots-Tag response header. They stay crawlable on purpose, because a page blocked in robots.txt is never fetched and so its noindex is never read.
Who can see a child's record?
School staff according to their role, the student themselves, and guardians the school has explicitly invited against that student. Parent access is granted by the school, never self-claimed.
How are online fee payments verified?
Payments are recorded from Razorpay's signed webhook, HMAC-verified before processing, rather than from the browser redirect. Duplicate deliveries are no-ops, so a gateway retry cannot double-credit an invoice.
Is there a record of who changed what?
Yes. Actions are written to an audit log against the acting user, the organisation and the specific entity, which is what makes a disputed mark or a reversed fee traceable.
Do you hold SOC 2 or ISO 27001 certification?
This page describes controls implemented in the product, not an audited certification. If your procurement process requires a formal attestation, contact us and we will tell you exactly where we stand rather than imply otherwise.
Send us your security questionnaire
If your trust or university has a diligence process, send it over. We would rather answer it precisely than have you infer the answers from a marketing page.