Security Practices
Summary
Security is built into every layer of EMStudio — from encrypted storage and row-level database isolation to automated PII scrubbing and a dedicated incident response process. This page details exactly how we protect your data and your students' data.
1. Our Security Commitments
Before the technical details, here is what we promise:
| Commitment | Status |
|---|---|
| We will never sell or rent your data | Always |
| We will never use student data for advertising or behavioral targeting | Always |
| We will never build profiles about students for non-educational purposes | Always |
| We will never train AI models on your content or student data | Always |
| We will never place third-party tracking in student data areas | Always |
| Analytics only with consent where required by law | Always |
| Notify affected users of any material data breach | Always |
These commitments are formalized in our 12 Privacy Commitments, our Terms of Service, and our Data Processing Addendum for schools.
2. Technical Safeguards
EMStudio implements the following technical measures to protect all data, in accordance with GDPR Article 32 (security of processing):
| Layer | Measure | Details |
|---|---|---|
| Transport | TLS 1.3 | All connections encrypted. HSTS enforced (max-age 1 year). HTTP auto-redirects to HTTPS. |
| Storage | AES-256 at rest | All data encrypted at rest via Supabase (PostgreSQL on AWS). File storage encrypted via Cloudflare R2. |
| Database | Row-Level Security (RLS) | PostgreSQL RLS policies on every table. Each teacher can only query their own data. No teacher can ever see another teacher's students. |
| Authentication | Supabase Auth + OAuth | Email/password with secure hashing. OAuth via Google, Microsoft, Apple. Session tokens in encrypted HttpOnly cookies. |
| API | Rate limiting | Per-user and per-IP rate limits on all sensitive operations (login, AI, export, deletion). Sliding window algorithm via Upstash Redis. |
| Browser | Content Security Policy | Strict CSP headers prevent XSS, clickjacking, and injection attacks. Violations reported to our monitoring endpoint. |
| Headers | Security headers | X-Frame-Options (SAMEORIGIN), X-Content-Type-Options (nosniff), Referrer-Policy (strict-origin-when-cross-origin), Permissions-Policy (camera, mic, geo disabled). |
| Secrets | Environment variables | All API keys, database credentials, and secrets stored as environment variables. Never committed to source code. |
| Input | Validation & sanitization | All server inputs validated with Zod schemas. User-generated content sanitized. PostgREST filter values sanitized. |
3. Infrastructure & Hosting
EMStudio runs on production-grade infrastructure from industry-leading providers:
- Application hosting: Vercel — global edge network with automatic HTTPS, DDoS protection, and serverless compute
- Database: Supabase — managed PostgreSQL on AWS (us-east-1) with automated backups, encryption, and row-level security
- File storage: Cloudflare R2 — S3-compatible object storage with global edge distribution and encryption
- Payments: Stripe — PCI DSS Level 1 certified payment processing. EMStudio never sees or stores full card numbers.
For the complete list of all vendors, see our Sub-Processors page.
4. Access Control
EMStudio enforces strict access control at every level:
User-level isolation
Every database query is scoped to the authenticated user via PostgreSQL Row-Level Security. A teacher can only see, edit, and delete data they created. There is no admin panel, no shared data view, and no way for one teacher to access another teacher's data.
Internal access
Access to production systems is limited to essential personnel only. Database credentials use the Supabase service role and are restricted to server-side operations (webhooks, cron jobs). Client-side code only uses the Supabase anonymous key, which is gated by RLS policies.
Third-party access
No third party has standing access to your data. Sub-processors receive only the minimum data needed for their function. Most never receive student data at all.
5. Privacy by Design
GDPR Article 25 requires “data protection by design and by default.” EMStudio implements this through:
- Data minimization: We only store what teachers enter. We never prompt for additional student data. See our data minimization framework.
- Privacy-protective defaults: Analytics are off by default in consent-required regions. Marketing emails are opt-in only. AI features can be disabled.
- AI privacy guard: A code-level allowlist strips all student data before any information reaches our AI provider. This is an architectural safeguard, not a policy — it cannot be bypassed.
- PII scrubbing: Error logs and monitoring data are automatically scrubbed of personally identifiable information (emails, UUIDs, query parameters) before storage.
- Soft-delete protection: When teachers delete data, it enters a 30-day soft-delete period (allowing undo) before permanent erasure. This prevents accidental data loss while still respecting retention limits.
6. AI Security
EMStudio's AI features have dedicated security measures:
- Data isolation: The AI privacy guard is a code-level allowlist that permits only lesson metadata (title, subject, class name, sanitized content preview) to reach the AI provider. Student names, grades, attendance, and all PII are stripped automatically.
- Zero retention: Our AI provider (OpenRouter, routing to Google Gemini) operates under a zero-retention policy. Prompts and responses are not stored or used for training.
- Rate limiting: AI requests are rate-limited per user (20/minute) and per IP (100/hour) to prevent abuse.
- Credit system: AI usage is metered via a credit system that prevents runaway costs and abuse.
- Kill switch: AI features can be disabled per-user from profile settings, or globally by EMStudio in the event of a security concern.
For the complete AI data flow, see our Transparency page.
7. Incident Response
EMStudio maintains a structured incident response process for security events:
| Phase | Timeline | Actions |
|---|---|---|
| Detection & triage | 0–4 hours | Identify the incident, assess severity, assemble response team |
| Containment | 4–24 hours | Isolate affected systems, stop ongoing breach, preserve evidence |
| Notification assessment | 24–48 hours | Determine notification obligations, prepare communications |
| Notification | 48–72 hours | Notify supervisory authority (GDPR Art. 33: 72h), notify schools with DPAs (24h), notify affected users |
| Eradication | As needed | Remove the root cause, patch vulnerabilities, restore from backups if needed |
| Post-incident review | Within 2 weeks | Document lessons learned, update security measures, publish transparency report if warranted |
For regulation-specific breach notification timelines, see our DPA breach notification table and Privacy Policy breach response section.
8. Backups & Disaster Recovery
- Automated daily backups: Full database backups run daily via Supabase, with point-in-time recovery available
- Geographic redundancy: Backups are stored in a separate AWS availability zone from the primary database
- File storage redundancy: Cloudflare R2 provides built-in redundancy across multiple data centers
- Recovery time: In the event of a catastrophic failure, we target recovery within hours, not days
9. Monitoring & Logging
- Error monitoring: Production errors are captured via a Vercel log drain and stored for 90 days. All logs are scrubbed of PII (emails, UUIDs, query strings) before storage.
- CSP violation monitoring: Content Security Policy violations are reported and tracked to detect potential injection attacks. Reports are scrubbed and retained for 30 days.
- Analytics: Product analytics via PostHog (teacher usage only, consent-gated in EU/UK/CA). No student data is ever sent to analytics.
- Uptime: Application availability is monitored continuously via Vercel's infrastructure.
10. Responsible Disclosure
We welcome security researchers who help us keep EMStudio safe. If you discover a vulnerability, please report it responsibly:
- Email: info@emstudio.pro with “Security Vulnerability” in the subject line
- Scope: Any vulnerability in emstudio.pro or the EMStudio application that could impact user data, authentication, or availability
- Safe harbor: We will not pursue legal action against researchers who report vulnerabilities in good faith, follow responsible disclosure practices, and do not access or modify other users' data
- Response time: We aim to acknowledge reports within 48 hours and provide a resolution timeline within 5 business days
Out of scope
The following are out of scope for responsible disclosure: social engineering, phishing, denial of service attacks, and vulnerabilities in third-party services (report those to the vendor directly).
11. Compliance Alignment
EMStudio's security practices are aligned with the following frameworks and regulations:
| Framework | Status | Details |
|---|---|---|
| GDPR Art. 32 | Aligned | Encryption, access control, resilience, and regular assessment. See our GDPR page. |
| FERPA | Aligned | Reasonable security safeguards for education records. See our FERPA page. |
| COPPA | Aligned | Reasonable security for children's data. See our COPPA page. |
| NIST Privacy Framework | Aligned | Our privacy practices follow NIST v1.1 identify, govern, control, communicate, and protect functions. |
| SOC 2 Type II | Planned | Formal certification planned as we scale to school district contracts. |
12. Contact
For security questions, vulnerability reports, or to request our security documentation:
Education Management Studio
d/b/a EMStudio
Email: info@emstudio.pro
Related Policies
- Privacy Policy — what data we collect and how we protect it
- Data Processing Addendum — formal security commitments for schools (Annex B)
- Sub-Processors — every vendor with their security posture
- GDPR Compliance — Article 32 security of processing
- FERPA Compliance — education records security
- COPPA Compliance — children's data security
- Transparency — data flow and access details
- Our Commitments — 12 privacy promises