Tag-a-Tutor — Security & Hosting Overview

1. What we store

Only what's needed to run the service. We do not collect:

• Social Security numbers, government IDs, or biometrics
• Academic grades, GPAs, or transcripts
• Health, medical, or counseling records
• Precise geolocation
• Financial or payment data

Full inventory in DPA Schedule A at tagatutor.org/dpa.

2. Where it runs

School-data record processing happens entirely in the US (Vercel + Neon). Per DPA §5.2, schools receive at least 30 days written notice before any change to this list.

3. Encryption & transport

• HTTPS-only — TLS 1.2+ enforced; HSTS max-age=63072000; preload (2 years)
• Encryption at rest — Neon disk-level encryption for the database
• Passwords hashed — Werkzeug PBKDF2-SHA256, ~260k iterations, per-record salt; we cannot read them
• HaveIBeenPwned check — passwords are checked against 13B+ known-breached passwords at signup and reset; matched passwords are refused
• Sessions — signed cookies, flagged Secure / HttpOnly / SameSite=Lax, 7-day expiry
• Tokens are single-use + time-bounded — password-reset tokens are bound to the current password hash so a leaked link works at most once; email-verification is idempotent; OAuth uses PKCE

4. Authentication gates

• Email verification required before parents can act on the platform
• Visibility consent — parents must explicitly confirm they understand who sees their child's information at signup
• TAG Parent Acknowledgment — separately signed before any TAG request can be created; record stored with name, IP, timestamp, version
• Google OAuth for students/teachers/admins (no password we manage)
• MFA on all operator and admin/facilitator accounts — every account with elevated platform access (Tag-a-Tutor operator accounts; school facilitator/admin Google accounts) is required to have multi-factor authentication enabled. Schools' Google Workspace 2FA policy is inherited for OAuth-based admin sign-ins
• Per-route role checks — every admin/facilitator/parent action re-validates the role against the database, not just session flags

5. Application defenses

• Security headers — strict CSP (no 'unsafe-inline' in script-src), X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin, Permissions-Policy restricting geolocation/microphone/camera. Grade A+ on securityheaders.com
• Rate limiting with proper Retry-After headers — login (per-email + per-IP), signup, password reset (per-email + per-IP), message send, public application form
• Input validation — length caps on every text field (1–5000 chars), email format validation at every entry point, enum validation on TAG-specific fields, numeric bounds on age
• Generic error messages — server errors return "Server error" to the client; full detail logged server-side only
• Audit log records every admin / facilitator action and read with actor, IP, timestamp, target — including parent submissions and admin TAG-data reads. Retained for 13 months minimum, longer where a school's contract requires it
• Multi-tenant isolation — every record is tagged with a School ID; the application layer enforces it on every read and write
• SQL safety — all queries use parameterized statements; no user input is concatenated into SQL. Static column / table names are sourced from a hardcoded allow-list

6. Access, operations & supply chain

• Tag-a-Tutor is currently operated by a single individual (Jack Cleveland, the founder). Production access is limited to that account, with all credentials in a password manager and recovery codes stored offline. A continuity plan covering succession, data hand-off, and operational responsibilities is documented and reviewed quarterly
• 2FA is enabled on every account that touches production (Vercel, GCP, Neon, Cloudflare, Zoho, GitHub) — verified at each quarterly review
• All secrets (database URLs, OAuth, API keys, signing keys) stored as encrypted environment variables, never in source code
• Source code not publicly available; private repository
• Dependencies pinned + audited — pip-audit --strict runs in CI before each deploy, blocks on any known CVE
• OAuth credentials rotated after any potential exposure; rotation procedure documented internally

7. Continuous testing

• 145+ automated security tests run on every change — covering authorization, state-machine integrity, input validation, session handling, and token reuse
• Cross-tenant isolation is explicitly tested. Dedicated tests confirm a request from School A's session cannot read or modify any record belonging to School B. This is the highest-stakes test in the suite and runs on every change
• Auto-discovered route coverage — every API route is automatically tested against unauthenticated access; new routes get tested without anyone updating the test file
• CI gate — tests + dependency CVE scan must pass before any deploy
• External validation — securityheaders.com grades the production site A+

8. Data ownership & deletion

• Schools own their data. Tag-a-Tutor processes it only as a service provider
• School-level export — machine-readable (CSV / JSON) within 30 days of a written request
• On contract termination — full export then permanent deletion within 60 days, including backups
• Individual-account deletion — a parent or student may request deletion of their own account at any time; we complete it within 30 days of receipt and confirm in writing on request
• Deletion of any record can be certified in writing on request

9. What we do not do

• We do not sell, rent, or trade school data
• We do not use school data for advertising or behavioral targeting
• We do not use school data to train AI / ML models
• We do not share data with marketers or unrelated third parties
• We will not redisclose education records except as authorized by the school in writing

10. Compliance posture

• FERPA-aligned — Tag-a-Tutor is designated as a "school official" with legitimate educational interest under 34 CFR § 99.31(a)(1)(i)(B), conditional on a signed Data Processing Agreement
• COPPA-aligned — for children under 13, our school-authorization pathway depends on the school engaging Tag-a-Tutor under a written DPA in which the school explicitly designates Tag-a-Tutor as a school official acting "for the use and benefit of the school." A separate parent acknowledgment is also collected. Schools should confirm with their counsel before relying on the school-authorization model
• 72-hour breach notification commitment, written, to the school's designated security contact

11. Backup, recovery & incident response

• Daily automated backups via Neon, with 7-day point-in-time recovery
• Quarterly restore tests — production database is restored to a Neon branch and the application booted against it; outcome documented internally
• Incident response runbook documented internally (decision tree for what counts as an incident, immediate actions, notification template, post-incident review). Tabletop drills run quarterly
• 72-hour breach notification to the school's designated contact under DPA §7
• Continuity plan documented and reviewed quarterly — covers the single-operator risk noted in §6, including succession, credential transfer, and a 30-day data hand-off path under DPA §9 if Tag-a-Tutor were ever wound down