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 run on the API routes that read or change school data, and an automated check in our build flags any new route that reads personal data without one.

Runtime tenant-boundary guard (reads + writes)

Our database client adds your school's ID to most reads and refuses any write that doesn't carry it. Look-ups by a record's own ID are checked by the feature that makes them rather than by this guard, and database-level enforcement is still in progress.

Tamper-evident audit log

Grade changes, role assignments, fee adjustments, sign-in attempts and privileged actions are recorded with who, when, IP address and browser, and entries are chained with a cryptographic hash so an edit or deletion is detectable. Counselling and health records are logged as field names only, never their content. Logs are kept for three years.

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. Every sign-in to a platform staff account emails the account holder, flagged when the location is new.

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: many schools share one database, and each school's data is kept apart by the layers below — in our application today, with database-level enforcement in progress:

• Every school's data carries its school's ID, and the application scopes each query to the signed-in school. Automated checks on every pull request flag API routes that query without it.
• A runtime guard wraps the database client: it adds your school's ID to most reads and refuses any write that doesn't carry it. Look-ups by a record's own ID are not covered by the guard and are checked by the feature that makes them.
• Database-level separation (in progress): PostgreSQL row-level security policies exist for every tenant data table, and automated checks make new tables get them too. Making them the final safeguard beneath the application is still under way — until it is, the two layers above are what keep schools apart.
• 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 visitor-record retention settings — 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:

• Built database-level Row-Level Security policies for every tenant data table, with automated checks so new tables get them too. Making them the final safeguard beneath our application-level guards is in progress.
• 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.
• Added security headers across the platform (HSTS, frame, content-type and referrer policies). Our Content-Security-Policy still allows inline scripts; tightening it is next.
• Made parents' choices take effect everywhere: a parent's "no AI" or "no photos", or a withdrawal of consent, now applies across the product at once.
• Stopped copying counselling notes and health details into the audit log.

An independent penetration test is planned. When it is done 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 you can switch off

Our AI providers do not use our requests to train their models. AI budgets are per school, and a parent can switch AI off for their own child — from that moment nothing about the child is sent.

Audit logs kept for three years

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

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 24 hours of our confirming it, 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.