Security Policy

School-Core is committed to protecting the confidentiality, integrity, and availability of all data processed through our platform. Given that we handle sensitive educational records, health data, financial information, and data of minors, we maintain comprehensive security practices aligned with industry standards and regulatory requirements.

This Security Policy describes the technical, organizational, and operational measures we implement to protect your data.

Our security program is designed in alignment with:

• ISO/IEC 27001 — Information Security Management
• SOC 2 Type II principles — Security, Availability, Confidentiality
• NIST Cybersecurity Framework (CSF) — Identify, Protect, Detect, Respond, Recover
• OWASP Top 10 — Web Application Security
• CIS Controls — Critical Security Controls

Cloud Hosting

The Service runs on SOC 2 Type II- and ISO 27001-aligned cloud providers across application hosting, database, object storage, and edge-caching layers. Our Sub-processors page lists each provider together with the category of data they process and the data-residency region in effect for your tenant. Each sub-processor is bound by a Data Processing Agreement and is reviewed at least annually.

Network Security

• TLS 1.2+ enforced on all connections (HTTPS only)
• HTTP Strict Transport Security (HSTS) in force
• Edge-level DDoS protection via the hosting provider's global infrastructure
• Content Security Policy (CSP) headers, X-Frame-Options, X-Content-Type-Options, and Referrer-Policy applied on every response
• DNS-level security with DNSSEC support

Database Security

• Connection pooling with conservative per-instance limits and timeouts
• Encrypted connections between application and database
• Automatic backups with point-in-time recovery
• Row-level tenant isolation enforced at the application layer; defense-in-depth scoping on all create / update / delete operations

Authentication

• Password hashing with bcrypt at industry-recommended cost factors
• Session management via encrypted, short-lived tokens with periodic refresh
• OAuth 2.0 SSO with Google Workspace and Microsoft Entra ID
• Multi-factor authentication (MFA) via TOTP authenticator apps (Google Authenticator, Authy, 1Password, etc.); required for administrative roles, available to all users. Single-use backup codes are issued at enrollment for recovery
• Cryptographically secure tokens for password reset and activation flows, time-limited and single-use
• Account status controls (active / suspended / inactive) enforced at the session layer

Authorization

Role-Based Access Control (RBAC): a comprehensive role catalog covering school, leadership, specialist, platform, and partner contexts, plus a CUSTOM role for tenant-defined permission sets. Permissions resolve in three layers:

1. Built-in role defaults
2. Tenant-level overrides (granted or revoked per role)
3. User-level overrides (granted or revoked per individual)

The principle of least privilege governs every default. Privileged role changes follow a two-person rule, and time-boxed elevated access ("just-in-time") is logged end-to-end.

Multi-tenant isolation:

• Every tenant-scoped database query enforces a mandatory tenant filter at the application layer; defense-in-depth scoping is applied to all create / update / delete operations so a single regression cannot leak data across tenants
• Cross-tenant access is architecturally prevented. An internal platform tenant houses our own staff data and is excluded from school-wide aggregates
• Platform-side context switching and support-team access to tenant data is logged end-to-end. Impersonation entries are written against the target tenant so school admins can see who accessed their data, when, and why

Input Validation

• Schema validation on every API input (Zod)
• Parameterized database access via Prisma ORM (no string-built SQL)
• Server-side HTML sanitization on all user-generated content
• File-upload validation with type and size restrictions; SVG uploads are not accepted

API Security

• All non-public API routes require authentication; public entry points are limited to marketing pages, authentication, pricing, and the contact-sales form
• Role-based authorization on every state-changing endpoint
• Rate limiting on authentication, account creation, password reset, MFA verification, and public form submissions, backed by a distributed Redis store
• Per-user request throttles enforced through the same store
• Request payload size limits enforced
• Restrictive Content-Security-Policy, X-Frame-Options, HSTS, and Permissions-Policy headers on every response

Secure Development Practices

• Code reviews for all changes
• Automated dependency vulnerability scanning
• Source maps uploaded to error monitoring and deleted from production builds
• All secrets in environment variables, never source-controlled
• Separate database credentials for migrations vs. runtime

Encryption

Data Classification

Data Minimization

• We collect only data necessary for the Service's educational purpose
• Optional fields are not required for core functionality
• AI features send minimal context necessary for the specific task
• Audit logs retain operational data; detailed PII changes are time-limited

Data Retention and Disposal

Audit Logging

All significant actions are logged via a centralised createAuditLog() helper that writes to a tenant-scoped AuditLog table. Every entry records:

• User identity (user ID, role; null for system actors such as Stripe webhooks and scheduled cron jobs)
• Action — drawn from a typed AuditAction catalog (95+ named actions covering auth, user CRUD, billing, AI subscriptions, Cloud Drive mutations, HR records, Stripe events, support operations) so logs can be filtered cleanly without spelling drift
• Entity affected (model/table and record ID)
• Previous and new values as a structured diff (only fields that actually changed; sensitive fields such as password hashes and bank-account numbers are omitted from the diff and represented by booleans like passwordChanged: true)
• Client information (IP address, user agent — captured via getClientInfo(request) whenever the actor is reaching us through HTTP)
• Timestamp (UTC)
• Additional metadata (Stripe event ID for webhook entries, target tenant for cross-tenant platform-admin actions, etc.)

Authentication is fully logged. Every login attempt is recorded as a success or failure, with the failure category captured for security review without exposing per-account details to the user. Sign-out, OAuth account linking, and OAuth-driven user creation are also logged.

Platform-admin actions are tenant-scoped. Impersonation, access reviews, DPA acknowledgements, and support-agent auto-suspension all set tenantId to the target tenant (or to the internal platform tenant for SupportAgent operations) so each school's audit-log view shows exactly who from the platform team touched their data, and why.

Retention. Audit logs are retained for at least three years for security investigations and longer where regulation requires it (FERPA disciplinary records, GDPR data-subject requests). Logs are append-only at the application layer and write failures are caught and surfaced in operational logs without ever blocking the underlying user-facing request.

Error Monitoring

• Sentry integration for real-time error tracking and alerting
• Source maps uploaded for debugging (deleted after upload for client security)
• Error reports exclude PII by design

System Health Monitoring

• Platform system health endpoint (/api/admin/system-health/)
• Database connectivity monitoring
• AI service availability tracking
• Automated alerting for service degradation

Incident Classification

Incident Response Process

1. Detection — Identify the incident through monitoring, alerts, or reports
2. Containment — Isolate affected systems, revoke compromised credentials
3. Assessment — Determine scope, affected data, and root cause
4. Notification — Notify affected parties per legal requirements:

• GDPR: Within 72 hours to supervisory authority
• Affected data subjects: Without undue delay
• Customer schools: Within 24 hours of confirmed breach

1. Remediation — Fix the vulnerability, restore services
2. Recovery — Verify system integrity, restore from backups if needed
3. Post-Incident Review — Document lessons learned, update procedures

Breach Notification

In the event of a Personal Data breach, we will:

• Notify the affected Customer (Data Controller) within 24 hours of confirmation
• Provide details of: the nature of the breach, categories and approximate number of data subjects affected, likely consequences, and measures taken or proposed
• Assist the Customer in meeting their notification obligations to supervisory authorities and data subjects
• Document the breach and remediation actions in our incident register

Backup and Recovery

• Database: Continuous replication with point-in-time recovery (managed by Supabase/AWS)
• File Storage: Redundant storage with automatic replication (Cloudflare R2)
• Application: Stateless architecture enabling instant redeployment
• Recovery Point Objective (RPO): < 1 hour
• Recovery Time Objective (RTO): < 4 hours

Disaster Recovery

• Multi-region infrastructure through Vercel's global edge network
• Database hosted on AWS with availability zone redundancy
• Automated failover capabilities
• Regular disaster recovery testing

Vendor Assessment

All sub-processors are evaluated for:

• Security certifications (SOC 2, ISO 27001)
• Data protection practices and DPA compliance
• Incident response capabilities
• Data processing locations
• Business continuity measures

Contractual Requirements

All sub-processors are bound by:

• Data Processing Agreements (DPAs)
• Confidentiality obligations
• Security standards requirements
• Breach notification obligations
• Data deletion requirements upon contract termination

Current Sub-processors

A maintained list of sub-processors with their security certifications is available in our Privacy Policy and upon request.

AI Data Handling

• AI requests are processed in real-time; no persistent storage by AI providers
• Prompts and responses are not used for AI model training
• AI providers are contractually bound by enterprise data processing agreements
• Minimal data is sent to AI providers (only context necessary for the specific feature)

AI Rate Limiting and Budget Controls

• Per-user rate limits enforced via distributed Redis
• Monthly token budgets per subscription
• Atomic token reservation system prevents budget overruns
• Budget enforcement occurs before API calls to AI providers

AI Response Caching

• AI responses may be cached (1-hour default TTL) to reduce unnecessary API calls
• Cache keys are hashed (no PII in cache keys)
• Cached data is ephemeral and automatically purged

All physical infrastructure is managed by our cloud providers (AWS, Vercel), which maintain:

• 24/7/365 physical security at data centers
• Multi-factor access controls to facilities
• Environmental controls (fire suppression, climate control, power redundancy)
• SOC 2 Type II and ISO 27001 certified facilities

School-Core does not operate any on-premises data centers.

Personnel Practices

• Background checks for all personnel with access to production systems
• Security awareness training upon onboarding and annually thereafter
• Signed confidentiality and non-disclosure agreements
• Principle of least privilege for system access
• Immediate access revocation upon role change or departure

Secure Development Training

• Regular training on OWASP Top 10 vulnerabilities
• Secure coding practices and code review requirements
• Incident response training and tabletop exercises

Vulnerability Scanning

• Automated dependency vulnerability scanning in CI/CD pipeline
• Regular security assessments of the application
• Third-party penetration testing [annually/bi-annually]

Patch Management

• Critical vulnerabilities: patched within 24 hours
• High vulnerabilities: patched within 7 days
• Medium vulnerabilities: patched within 30 days
• Low vulnerabilities: patched within 90 days

Responsible Disclosure

We welcome responsible security research. If you discover a vulnerability:

• Email: security@school-core.com
• Include: description, steps to reproduce, potential impact
• We will acknowledge receipt within 48 hours
• We will not pursue legal action against good-faith researchers
• We request that you do not publicly disclose the vulnerability until we have had reasonable time to address it

Regulatory Alignment

Data Protection Impact Assessments (DPIAs)

We conduct DPIAs for:

• New features involving sensitive personal data
• AI features processing children's data
• Changes to data processing infrastructure
• New sub-processor engagements

Security is a programme, not a milestone. Beyond the controls described above, we are actively investing in:

• SOC 2 Type II — our control set is designed to the SOC 2 trust criteria and we are working toward formal audit and certification.
• ISO 27001 — our information-security management system is aligned to ISO 27001 and we are progressing toward formal certification.
• Annual third-party penetration testing — independent black-box and grey-box engagements, with findings tracked to closure.
• Continuous expansion of application-level encryption — extending field-level protection to additional categories of sensitive data over time.
• Self-service data subject rights — moving more of the GDPR / CCPA access, portability, and erasure flows from operator-assisted to fully automated.
• Bug bounty programme — formalising our responsible-disclosure channel into a structured programme with researcher rewards.

Updates to certifications and audit reports will be made available to current customers under NDA as they are completed.

Security Team: security@school-core.com Vulnerability Reports: security@school-core.com Data Protection Officer: privacy@school-core.com

For urgent security matters, include "URGENT" in the email subject line.