How we protect your school's data

SchoolPilot is hosted on enterprise-grade cloud infrastructure provided by Vercel and Supabase, which maintain SOC 2 Type II certifications and comply with international security standards.

All data in transit is encrypted using TLS 1.2 or higher (HTTPS). Data at rest is encrypted using AES-256 encryption. Database backups are encrypted and stored in geographically distributed locations.

Our infrastructure is monitored 24/7 for availability, performance anomalies, and security threats. Automated alerts notify our engineering team of any unusual activity.

User authentication is handled through Supabase Auth with secure session management. Passwords are hashed using bcrypt with per-user salts and are never stored in plain text or transmitted in recoverable form.

Role-Based Access Control (RBAC) is enforced at every API endpoint and UI surface. The platform supports multiple distinct roles — platform admin, school admin, head teacher, class teacher, subject teacher, bursar, front desk, parent, and student — each with precisely scoped permissions.

Student authentication uses a separate credential system (admission number + PIN) that does not rely on email/password, ensuring age-appropriate access without requiring children to manage email accounts.

Session tokens are short-lived and automatically refreshed. Failed login attempts are rate-limited to prevent brute-force attacks.

SchoolPilot operates as a multi-tenant platform where each school's data is logically isolated. Every database query is scoped to the authenticated school's tenant, preventing cross-tenant data access.

Row-Level Security (RLS) policies are enforced at the database level, providing a defense-in-depth approach that prevents data leakage even if application-level checks are bypassed.

Tenant isolation is verified through automated testing and security reviews to ensure that no school can access another school's records, communications, or administrative data.

All API endpoints require authentication via bearer tokens (for mobile) or session cookies (for web). Unauthenticated requests are rejected with appropriate error responses.

API requests are validated using schema validation (Zod) to prevent injection attacks, malformed data, and type coercion vulnerabilities. Input sanitization is applied to all user-provided data.

Rate limiting is implemented on authentication endpoints, public APIs, and resource-intensive operations to prevent abuse and denial-of-service attacks.

Cross-Origin Resource Sharing (CORS) policies restrict API access to authorized domains only.

The application is built following OWASP Top 10 security guidelines. We actively protect against common vulnerabilities including SQL injection, cross-site scripting (XSS), cross-site request forgery (CSRF), and insecure direct object references.

Content Security Policy (CSP) headers are configured to prevent unauthorized script execution. All user-generated content is sanitized before rendering.

File uploads are validated for type, size, and content. Uploaded files are stored in isolated cloud storage (Cloudflare R2) with access controlled through signed URLs.

Dependencies are regularly audited for known vulnerabilities using automated scanning tools, and security patches are applied promptly.

We follow the principle of data minimization — we only collect and process data that is necessary for the Service to function. Sensitive data fields are encrypted at the application level where appropriate.

Access to production data is restricted to authorized engineering personnel on a need-to-know basis. All production access is logged and auditable.

We do not sell, share, or use school data for advertising, marketing, or any purpose unrelated to providing the Service. Our full data handling practices are described in our Privacy Policy.

We maintain a documented incident response plan that covers identification, containment, eradication, recovery, and post-incident review.

In the event of a security incident that affects user data, we will: (a) investigate and contain the incident promptly; (b) notify affected schools within 72 hours of confirmed unauthorized access to personal data; (c) provide a detailed incident report including scope, impact, and remediation steps; (d) implement measures to prevent recurrence.

Users can report security concerns to security@schoolpilot.xyz. We take all reports seriously and respond within one business day.

Database backups are performed automatically and continuously, with point-in-time recovery capability. Backups are stored in geographically separate locations.

Our infrastructure is designed for high availability with automatic failover capabilities. We target 99.9% uptime for the Service.

A disaster recovery plan is maintained and tested to ensure rapid restoration of service in the event of a major incident.

All code changes undergo peer review before deployment. Security-sensitive changes receive additional review from senior engineers.

We maintain separate development, staging, and production environments. Production deployments follow a controlled release process with rollback capabilities.

Automated security scanning is integrated into our CI/CD pipeline, catching vulnerabilities before they reach production.

For security-related questions, concerns, or to report a vulnerability, please contact us at: security@schoolpilot.xyz. We appreciate responsible disclosure and will acknowledge reports within one business day.