Vidyalaya holds some of the most sensitive records a family will ever share — a child's identity, health, attendance and fees. We engineer for that. Access is least-privilege by default, tenants are isolated at the database, and privacy tooling is built in, not bolted on.
A cashier should never open a counselling note. A teacher should never touch payroll. Vidyalaya enforces that with a permission catalog that is defined in code — versioned, reviewed and tested — rather than an editable database table someone can quietly widen.
domain.action — e.g. exam.publish, payment.reconcile, privacy.erase — not coarse "admin/staff" gates.Every school is a separate tenant. Isolation is enforced twice, so a single mistake can't leak a record.
Every query filters by the caller's tenant_id, taken from their signed token — never from user input. Each service has tests proving a token for one tenant cannot read another's rows.
PostgreSQL row-level security adds a second, database-enforced boundary: a per-tenant policy means even a query that forgot its filter returns only the current tenant's rows. Shipped and tested on the student service as the reference for platform-wide rollout.
Belt and suspenders: the application filter is the primary guard and is enforced everywhere today; row-level security is additive hardening being rolled out service by service.
The mechanics of a data-subject request are the same whether you are under India's DPDP, the EU's GDPR or the US's FERPA. Vidyalaya ships the machinery; a per-country config pack sets the deadlines and retention numbers.
One endpoint returns a complete, consistent snapshot of everything held about a student — profile, guardians, documents and lifecycle events — as a single JSON bundle, read in one isolated transaction.
Anonymise-in-place: names become "Erased", identifying fields are nulled, documents are removed — while ledger references stay intact for statutory financial retention. A second erase is refused, not silently repeated.
Every export and erasure writes an audit record — who did what, to whom, when — queryable per tenant. DSAR fulfilment itself has to be demonstrable, so it is logged like any privileged action.
Country packs carry the privacy regime, retention window and consent rules per tenant, so a group can run schools under different regimes from one platform.
The same export and erase flows satisfy a DPDP data-principal request, a GDPR subject request or a FERPA records request — configuration changes the numbers, not the mechanics.
These controls are built to help your school meet DPDP, GDPR and FERPA duties. We are candid about scope — see the honesty note below — rather than claiming certifications we do not hold.
Getting in is the first thing an attacker tries, so it is the first thing we harden.
We do not currently hold SOC 2 or ISO 27001 certification, and we will not claim otherwise. What we can show you is real, working machinery — access control, tenant isolation, DSAR tooling, audit logging and hardened authentication — that is designed to support your compliance obligations under DPDP, GDPR and FERPA. Some hardening, such as platform-wide row-level security and automated retention enforcement, is being rolled out progressively; we are happy to walk you through exactly what is enforced today.
Bring your hardest security question. We would rather earn trust with detail than slogans.