Security & Trust

Defense in depth

We do not rely on any single control. A request from a teacher to a student record passes through nine independent layers before any data is read or written.

TLS + HSTS on every connection

All traffic between your browser, our app, and our database is encrypted in transit. We refuse insecure connections.

CAPTCHA on sign-in, sign-up, and password reset

Cloudflare Turnstile blocks automated probes and credential-stuffing attacks before they reach the password layer.

Per-account brute-force lockout

Five failed attempts on the same account triggers a 15-minute lockout — regardless of how many IPs the attacker rotates through.

Multi-factor authentication (MFA)

Time-based one-time passwords (TOTP) plus single-use backup codes. Backup codes are hashed at rest and verified in constant time.

Email verification on public sign-up

Anyone registering a tenant from our marketing site must prove they own the inbox before they can sign in. Admin-provisioned student and staff accounts are exempt and must rotate their password on first login.

Per-request authorization

Role-based and resource-level permission checks fire on every API route. No request reaches the database without a permission decision.

Runtime tenant-boundary guard (reads + writes)

Our database client automatically scopes reads to your school's tenant and refuses any write that doesn't carry its tenant ID. A bug in our application code cannot accidentally read or write across schools.

Tamper-evident audit log

Every grade change, role assignment, fee adjustment, login attempt, and privileged action is recorded with actor, IP, and user agent — and entries are chained with a cryptographic hash, so a record can't be silently altered or deleted. Logs are retained for at least 365 days.

Real-time security monitoring

Privileged actions, failed-login spikes, mass deletions, and impersonation events are flagged in real time, raise alerts to our security team, and roll up into a daily security digest. A sign-in from a new device or IP notifies the account owner.

Your data is isolated from every other school

This is the first question that IT and data-protection teams ask. School-Core is multi-tenant by architecture, but every read and every write is automatically scoped to your school. We enforce this at multiple independent layers — in our application today, and, increasingly, in the database engine itself:

• Every database query in the application code includes your tenant ID — checked by automated tooling on every pull request.
• A runtime guard wraps the database client — it automatically scopes reads to your tenant and rejects any write that doesn't carry the caller's tenant ID, even ones an attacker might inject via a vulnerability we haven't yet found.
• Database-enforced Row-Level Security (rolling out): we have engineered and independently verified a layer where PostgreSQL itself filters every query by your school — so even a flaw we have not found in our application code cannot return another school's row. It fails closed: a query that ever lost its tenant context returns nothing, never another school's data. Automated checks ensure every new data table inherits this protection.
• Sensitive secrets — OAuth client secrets, payment integration keys — are AES-256-GCM encrypted at rest. A database snapshot is not enough to compromise your integrations.

We can demonstrate this isolation under your IT team's inspection during onboarding.

Shared responsibility

Security is a partnership. We are responsible for securing the platform; your school is responsible for securing its people, accounts, and devices. Knowing where the line sits is how the whole system stays safe — here is how the responsibility splits.

We give you the tools for your side — MFA, SSO, granular roles, your own audit log, and configurable retention — and we are glad to advise on rolling them out across your community.

We actively look for our own weaknesses

Security is a continuous practice, not a one-time review. Recently we have:

• Engineered a database-level Row-Level Security layer — PostgreSQL itself filters every query by your school's ID — and proved it fail-closed on our live database (a query that loses its tenant context returns nothing, never another school's data). It now covers every tenant data table, with automated checks so new tables inherit it, and is rolling out beneath our application-level guards as the deepest floor.
• Extended our runtime tenant-boundary guard to cover reads as well as writes — the database client now scopes queries to the caller's school, not just rejecting cross-tenant writes.
• Made the audit trail tamper-evident with a cryptographic hash-chain, so log entries cannot be silently altered or removed after the fact.
• Deployed automated anomaly detection and real-time alerting on privileged actions, failed-login spikes, and suspicious sign-ins, with a daily security digest to our security team.
• Completed a multi-perspective adversarial code review (hostile student, hostile teacher, external attacker, compromised admin). Every finding either fixed or documented with rationale.
• Hardened our AI features against prompt-injection — we use AI in tutoring, lesson planning, and report cards, and most school platforms have not yet addressed these attack patterns.
• Removed third-party dependencies with known unpatched vulnerabilities and replaced them with maintained alternatives.
• Tightened content-security and HTTP headers across the platform.
• Wired continuous automated dependency vulnerability scanning into our CI pipeline.

A third-party human penetration test is scheduled. We will share the executive summary with your IT and security teams under NDA.

Privacy posture

Student data stays in your tenant

We do not sell, share, or mine student data for advertising, analytics, or model training. Period.

AI features are subscription-gated

Student inputs to our AI tools are not used to train external models. Token budgets are per-school and exhaustion-protected.

Audit logs retained ≥ 365 days

Forensic visibility into who did what, when, from which IP, and via which user agent.

Data subject rights

Export and deletion endpoints implement access and erasure rights (GDPR Articles 15 & 17 and equivalents worldwide). We process within 30 days of a verified request.

Compliance posture

We are transparent about where we stand. We are a small team building deliberately — we would rather ship security controls that materially raise the cost of an attack than chase certifications.

If your institution requires SOC 2 Type II or ISO 27001 before signing, we will discuss accelerated certification under a paid pilot.

If something goes wrong

We maintain a written incident-response process. In the event of any security incident affecting your school, you will be notified within 72 hours with what happened, which data was involved, what we did to contain it, and what action you can take.

Contact

For security questions or to report a vulnerability, email security@school-core.com. We are happy to host a security deep-dive with your IT team — under NDA when needed.