Data Policy

School records are held in a managed PostgreSQL database with an object-storage layer for uploaded files (school logos, gallery images, student photos and assessment evidence). Infrastructure is operated on managed cloud providers; data is stored in the provider's region configured for this deployment, and static assets are served through a global CDN. Only non-sensitive public assets (for example a school's public profile logo) are served from public storage paths; student photos and evidence uploads are held in private buckets and reached only through short-lived signed URLs.

• Row-level security. Every table carrying school data enforces access rules in the database. A query issued by a teacher, an organisation admin or a guardian is filtered by the database itself, so a bug in the interface cannot expose another school's records.
• Organisation isolation. Records are tagged with their organisation and cross-organisation reads are blocked by policy, not convention.
• Encryption. Data is encrypted in transit (TLS) and at rest by the storage provider. Passwords are stored only as salted hashes and are never visible to us.
• Private file storage. Evidence and photo buckets are private, size-limited and restricted to standard image/document types. Access is granted per request via expiring signed URLs.
• Least privilege. Service credentials are held server-side only. Administrative roles are limited to named CAS Nepal staff.
• Audit logging. Administrative actions — school approval, credential issuance, account status changes — are recorded with actor, action and timestamp.

The database is backed up automatically by the managed platform with point-in-time recovery, retained on a rolling window (currently seven days for point-in-time restore, with daily snapshots). File storage is replicated by the storage provider. Restores are performed by CAS Nepal staff on request or in response to an incident; a School can ask us to restore its workspace to an earlier point after accidental bulk deletion.

A School can request a full export of its workspace at any time, and always receives one when leaving. An export includes:

• student roster and profile fields, including guardian details and health records;
• classes, subjects, themes, categories and rubric indicators;
• all rubric scores with phase, date, method, remarks and computed achievement;
• attendance records, portfolio items and academic year/term structure;
• evidence and photo files, delivered as an archive alongside the structured data.

Structured data is delivered as CSV (one file per entity) and, on request, as JSON. Exports are produced within 14 days of a written request.

On written instruction from an organisation administrator, we delete the School's workspace: database records, files in storage, and all user accounts issued under that organisation. Deletion is performed within 30 days of the request (after the export has been confirmed as received) and completes across backups as the backup window rolls forward — no later than 60 days in total. We confirm completion in writing.

Individual records — a withdrawn student, a mistaken evidence upload — can be deleted by the School directly from the platform at any time.

We use a small number of infrastructure sub-processors for database hosting, object storage, application hosting and transactional email. Sub-processors are contractually bound to equivalent confidentiality and security obligations and are not permitted to use School data for their own purposes. A current list is available on request, and we give notice before adding a sub-processor that handles student data.

If we become aware of a security incident affecting School data, we will investigate immediately, contain it, and notify the affected School's organisation administrators within 72 hours of confirming the incident. The notification states what happened, what data categories were involved, what we have done, and what the School should do — including whether guardians need to be informed. A written post-incident report follows once the investigation closes.

To report a suspected vulnerability or incident, contact security@casnepal.com. We do not pursue good-faith security researchers who report responsibly.