Security Whitepaper

Version: [SECURITY_WHITEPAPER_VERSION] Last updated: [LAST_UPDATED_DATE]

This document describes the security controls and practices we apply to [PRODUCT_NAME]. It is written for parents, school IT teams, and prospective business customers. It is incorporated by reference into our Data Processing Addendum (Annex II).

1. Security principles

We design security around three commitments:

1. Minimise child data. The most defensible data is the data we never collect or store. We hold only first names, ages, parent-selected preferences, short summaries of activity, and safety events. Full transcripts are off by default.
2. Defence in depth. Multiple, overlapping controls — no single failure exposes data.
3. Boring infrastructure. We use mainstream, well-staffed providers rather than experimental components, so the underlying platform inherits years of hardening.

2. Architecture overview

[PRODUCT_NAME] is a Next.js application hosted on [HOSTING_PROVIDER, e.g., Vercel], with a Postgres database and authentication service provided by [DATABASE_AUTH_PROVIDER, e.g., Supabase]. The AI tutor calls a third-party model provider ([PRIMARY_AI_PROVIDER]) from server code only — never from the browser. All requests are served over HTTPS.

Browser  ──TLS──▶  Edge / Application Hosting  ──TLS──▶  Database (Postgres)
                                  │
                                  └──TLS──▶  AI Provider (Anthropic / OpenAI)

The browser never holds AI provider API keys, service role keys, or database credentials. Only short-lived authentication cookies are issued to the client.

3. Encryption

• In transit: TLS 1.2+ for all traffic, with HSTS enforced. TLS 1.3 negotiated where the client supports it.
• At rest: Database storage encrypted with AES-256 by the cloud provider. Backups encrypted.
• Backups: Encrypted, retained on a rolling [BACKUP_WINDOW, e.g., 35-day] window, isolated from primary storage.
• Secrets: Application secrets stored in the hosting provider's encrypted secrets manager. Not in source code. Rotation cadence: at least every [SECRET_ROTATION_MONTHS, e.g., 12] months and immediately on suspected compromise.

4. Access control

Customer access

• Parent authentication via Supabase Auth (password + email confirmation; OAuth providers configurable). Passwords are hashed with bcrypt by the auth provider — never stored in plaintext.
• Session cookies are HttpOnly, Secure, SameSite=Lax, with short lifetimes and refresh-token rotation.
• Authorization is enforced in every API route. Parents can only see and modify their own children's data. We verify ownership at the database layer on every read and write.

Staff access

• Single sign-on (SSO) with MFA required for all staff accounts on critical systems.
• Principle of least privilege: access is granted by role, reviewed quarterly, and revoked promptly on role change or departure.
• Production database access is restricted to engineers on call, logged, and requires a documented reason for each session.
• Customer support has read access only to non-content metadata (account email, child profile name and settings). They cannot read transcripts or summaries without an explicit parent-authorised request.

Audit logging

We log:

• All administrative access to production data (who, when, what, why)
• Privileged actions (e.g., DSAR fulfilment, account deletion)
• Authentication failures
• Configuration changes

Audit logs are retained for [AUDIT_RETENTION, e.g., 1 year], are write-once where supported, and are isolated from operational logs.

5. Application security

• Code review: all production code is reviewed by at least one engineer who did not author the change.
• Dependency scanning: automated scans for known vulnerabilities in third-party packages, run on every commit.
• Static analysis: TypeScript strict mode, ESLint, and security-focused lints enforced in CI.
• Input validation: every API route validates request bodies with Zod schemas.
• Output encoding: React's default escaping; we don't use dangerouslySetInnerHTML for any child-facing content.
• CSRF protection: for all state-changing routes.
• Security headers: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy restricting camera/geolocation/microphone use.
• Content Security Policy: restrictive CSP scheduled for [CSP_TARGET_DATE].
• Rate limiting: applied to authentication endpoints, the tutor message endpoint, and DSAR submissions.

6. Child-safety controls (security-relevant)

• Input safety classifier runs server-side on every child message before the AI is invoked.
• Output safety classifier runs server-side on every AI response before it's shown.
• Homework guardrail runs server-side and modifies the system prompt before invocation.
• Parent block-list is checked first and overrides everything else.
• Safety events are logged regardless of the parent's transcript-retention setting.

The full safety model is documented in docs/safety.md and the AI Disclosure.

7. Vulnerability management

• Internal: dependency vulnerability scans on every PR; weekly scheduled scans of the full deployment.
• External: annual penetration test by a qualified third party (planned: [PENTEST_TARGET_DATE]).
• Responsible disclosure: we welcome reports to [SECURITY_EMAIL] under the policy below.

Responsible disclosure policy (short)

If you discover a vulnerability:

• Report privately to [SECURITY_EMAIL] (PGP key at [PGP_KEY_URL]) with reproduction steps.
• Allow us [DISCLOSURE_WINDOW, e.g., 90] days to remediate before public disclosure.
• Do not access more data than necessary to demonstrate the issue. Do not access children's data.
• We will acknowledge within 3 business days and keep you informed.

8. Incident response

We maintain an Incident Response Plan ("IRP") with the following stages: detect → triage → contain → eradicate → recover → review.

• Detection: error monitoring, log alerts, customer reports, automated security alerts.
• Triage: on-call engineer classifies severity within [TRIAGE_HOURS, e.g., 1] hour. Incidents involving Personal Data, especially of children, are escalated to the DPO immediately.
• Notification: for personal-data breaches affecting EU/UK data subjects we notify the relevant supervisory authority within 72 hours of becoming aware where required by Art. 33 GDPR. Affected parents are notified without undue delay as required. Where notification would prejudice law-enforcement, we coordinate with them first.
• Review: every incident is reviewed in a blameless retrospective within 14 days, and any agreed actions are tracked to closure.

9. Business continuity & disaster recovery

• RPO (Recovery Point Objective): [RPO_HOURS, e.g., 24] hours.
• RTO (Recovery Time Objective): [RTO_HOURS, e.g., 8] hours.
• Backups: daily snapshots, encrypted, stored separately from primary.
• Restoration tests: at least every [RESTORE_TEST_MONTHS, e.g., 6] months.
• Provider redundancy: the underlying cloud providers operate multi-AZ. We do not currently run active-active across regions; we will add this if SLAs require.

10. Personnel security

• Background checks (where lawful) for staff with access to production data.
• Confidentiality and data-protection clauses in all employment and contractor agreements.
• Mandatory security and privacy training on onboarding and annually thereafter.
• Specific child-safety training for staff who handle support, content moderation, or DSARs.

11. Vendor management

See the Subprocessor List. Every subprocessor is reviewed before engagement, signs a DPA at least as protective as our customer DPA, and is re-reviewed annually.

12. Compliance roadmap

We have committed to obtaining the following independent attestations:

These are commitments, not current certifications. We will update this page promptly when we receive a report.

13. Reporting concerns

• Security: [SECURITY_EMAIL]
• Privacy / data: [PRIVACY_EMAIL]
• Safety (child-facing): [SAFETY_EMAIL]
• General: [SUPPORT_EMAIL]