Security

• In transit — TLS 1.3 on all public endpoints. HSTS preload. Modern cipher suites only; SSLLabs A+ score.
• At rest — AES-256 on managed Postgres, object storage, and per-tenant audit-log shards.
• Field-level encryption for PII columns (student names, parent emails, phone numbers, billing details). Decryption keys live in a separate KMS.
• Backups — encrypted at rest with separate keys, tested quarterly for restorability.

• Passwordless email-link sign-in by default.
• OAuth (Google, Microsoft) for school + family tenants.
• SAML 2.0 SSO on the District plan.
• MFA available on all paid tiers; required by default for school admin + district admin roles.
• Role-based access control with seven canonical roles (super-admin, school-admin, teacher, student, parent, DPO, viewer). Permissions are deny-by-default.

Every tenant has its own row-level-security boundary in the database; every query is scoped at the ORM layer with a non-overridable tenant guard. Penetration tests specifically target tenant-crossing attacks (IDOR, JWT scope manipulation, cache poisoning).

Per-tenant audit-log shards keep TraceLayer entries physically partitioned, so a compromise in one tenant’s storage layer can’t leak another tenant’s history.

Full list at /compliance#sub-processors. Each entry includes:

• What the sub-processor does for us.
• Their certification posture (SOC 2 Type II, ISO 27001, etc.).
• Where their infrastructure is located.
• The DPA we’ve signed with them.

Annual external penetration test by a CREST-accredited firm, scoped to the public web app + API. Targeted re-tests after any critical-severity finding. Results are NDA-gated; available to school admins under a mutual NDA on request.

Continuous automated scanning (DAST + dependency scanning) on every deploy.

Our IR runbook follows five stages, with a target of 72 hours from detection to first regulator notification (24 hours to school-admin notification under the DPA).

1. Detection — alerts from continuous monitoring, customer report, or our bug-bounty channel.
2. Triage — severity assigned within 1 hour; on-call engineer + DPO paged.
3. Containment — affected systems isolated; new data flow paused if needed.
4. Notification — affected tenants notified per the DPA; data subjects + supervisory authorities notified per GDPR Article 33/34 timelines.
5. Post-mortem — written within 7 days, shared with affected tenants on request, action items tracked publicly in our changelog.

See /legal/privacy#retention for full retention windows by data category. Highlights:

• Active data: kept while the account is active.
• Cancelled accounts: 30-day reactivation window, then hard-deleted.
• Backups: purged within 90 days of cancellation. Encrypted with separate keys; never restored selectively for a single tenant without your permission.
• TraceLayer audit log: 90 days (Free) → 7 years (Standard+), customisable on Campus + District.

We don’t run a paid bug-bounty programme yet, but we welcome responsible disclosure. If you find a vulnerability:

• Email security@moizlabs.com (PGP key on request).
• Don’t test against production tenants you don’t own — stick to your own account or our staging environment.
• Give us a reasonable disclosure window (typically 90 days) before publishing.
• We’ll respond within 1 business day. We publicly credit researchers (with permission) in our security changelog.

Security disclosures: security@moizlabs.com. Compliance / DPO: compliance@moizlabs.com.