Data security & trust

Clear boundaries around school data.

SchoolDB uses layered application controls to authenticate users, resolve their school and role, restrict records, protect uploaded files and preserve operational accountability.

Security approach

Access is checked in context, not assumed.

Signing in is only the first step. SchoolDB also evaluates the user's active school membership, role, permissions and the requested record before allowing protected operations.

Authenticated access

Protected workspaces and APIs require an authenticated user session before school data is evaluated.

School membership boundaries

An active membership connects each user to a specific school before operational records are returned.

Role and permission checks

Administrative, teaching, finance, reception and self-service roles receive different capabilities.

Private file delivery

Sensitive uploads use private storage controls and authenticated download routes rather than public file links.

Operational audit records

Important actions can record the actor, school, role, module, action and affected record for review.

Application safeguards

Input validation, file type and size checks, security headers and server-side data scoping reduce common risks.

How a protected request is evaluated

  1. 01AuthenticateConfirm that a valid user session is present.
  2. 02Resolve schoolRequire an active membership for the requested school.
  3. 03Check authorityApply role, permission and resource-specific rules.
  4. 04Scope the dataQuery and return records within that school context.

How SchoolDB handles data

  • Schools determine which institutional records are entered.
  • Personal information is not sold.
  • Service providers are used where needed for hosting, authentication, storage, communications and payments.
  • Payment reconciliation uses transaction references and status; SchoolDB does not store UPI PINs or banking passwords.
Read the privacy policy

Shared responsibility

  • Schools should approve access only for authorised users and promptly remove access that is no longer required.
  • Users should protect sign-in methods, devices and verification codes and report suspected misuse promptly.
  • Schools remain responsible for lawful collection, accuracy, retention requirements and day-to-day use of their records.

Role boundaries inside each school

A successful sign-in does not grant access to every module. SchoolDB resolves the selected school, active membership, assigned role and any individual permissions before protected data is returned.

Super Admin

Creates school workspaces and controls administrator-level access across authorised schools.

School Admin / Principal

Runs one school workspace and manages its academic, operational and delegated staff access.

Teacher

Works with assigned teaching areas and only the additional modules explicitly enabled by the school.

Accountant

Uses approved finance and operational modules without receiving general administrator authority.

Receptionist

Uses approved admissions and front-office workflows without finance or academic administration by default.

Parent / Student

Uses a personal self-service space limited to linked student information and permitted actions.

Incident readiness

Security concerns need a clear response path.

Reports are assessed for scope and impact, affected access can be contained, relevant evidence can be preserved, and the school can be contacted using the agreed support and incident channels. Any contractual or legal notification is handled according to the facts and applicable requirements.

  1. 01Assess and contain
  2. 02Preserve evidence
  3. 03Inform affected schools
  4. 04Recover and prevent recurrence

Report a privacy or security concern

Contact us with the school name, a clear description and a safe way to reach you. Do not email passwords, OTPs, UPI PINs or unnecessary student records.

No internet service can guarantee absolute security. This page describes SchoolDB's application approach and does not claim a third-party certification, independent audit result, regulatory approval or an unconditional guarantee unless SchoolDB provides that evidence separately in writing.