Trust, security and compliance status
This is the page CTOs spend the most time on, so it is written as a board-meeting handout rather than a marketing page. Every status carries a date. The two rows that go against us are at the top of the first table, not buried under the badges.
| Certification or pledge | Status | What that actually means today |
|---|---|---|
| SOC 2 Type II | Planned — not started | No auditor engaged, no observation window open, no report to send you. Scope was defined in March 2026; the window opens at our first district cutover, and a Type II report requires months of observation after that. If your security review requires a completed report, we fail it today. |
| FERPA | Architecture compliant | School official / legitimate educational interest model, per-district isolation, no secondary use. Signed as a binding obligation in the DPA attached to the master agreement, not asserted on a page. |
| COPPA | Architecture compliant | Parental consent flows implemented. No behavioural advertising and no family-facing monetisation of any kind, under §9.4. |
| SOPIPA (California) | Architecture compliant | No targeted advertising, no profile building for non-educational purposes, no sale of student data. The same obligations carry across the state-level analogues. |
| Student Privacy Pledge 2.0 | Signed | Applies to every district in scope, with no carve-outs. |
| Texas SB 820 | In progress | Cybersecurity attestation drafting. We intend to file directly with TEA on behalf of Texas districts for the 2026/27 year. |
| iKeepSafe CSPC | Pledged | Certification filing planned at general availability. Pledged is not certified and we will not print the badge until it is. |
| NIST 800-171 Rev. 3 | Planned | Targeted for 2027. Nothing has been assessed against it yet. |
Two of the eight rows above are red and we put them at the top rather than the bottom. A vendor trust page whose every row is green is a design decision, not a compliance posture. This table is re-dated whenever a status changes; the date in the caption is the date of the last review, not the date of the last deploy.
Start here: we are pre-launch, and what that costs you
Kastr has no district in production. There is no SOC 2 report, no uptime history, no reference customer, and no incident record — good or bad — because there has been no production to have incidents in. If your evaluation requires any of those, we fail your review today, and the honest thing is to tell you on the first screen rather than on the fourth call.
What we can give you instead is everything that does not require a customer to exist: the architecture, the code-level security controls, the contract, the sub-processor list, the retention policy, and dated statements about what has and has not been audited. That is a smaller set of evidence than an incumbent can offer. It is also verifiable, which a logo wall is not.
The three questions a security reviewer usually asks first, answered up front. Do you have a completed SOC 2 Type II report? No — planned, not started, window opens at first district cutover. Do you support SSO or MFA? No — a magic link is the only authentication path that exists in the codebase. Can we see an uptime chart? No — there is no production uptime to chart, and there is no status subdomain, because publishing a green dashboard for a system nobody uses would be theatre.
The security model, control by control
These are the controls that exist in the code today, described precisely enough that your team can test each one during a review.
Tenant isolation
Every district's data sits behind Postgres row-level security, and the application connects under a non-owner, DML-only database role set per transaction. That detail is the whole point: table owners bypass RLS in Postgres by default, so a design where the app connects as the owner has row-level security that can be silently defeated by any query the ORM decides to run. Ours cannot be.
Isolation is hierarchy-aware — a district sees its own rows and its child schools' rows, and never another district's. It fails closed: with no current organisation set on the session, every policy evaluates against NULL and returns zero rows, so the failure mode of a bug is an empty screen rather than somebody else's students. A cross-tenant leakage suite runs in CI against real Postgres 16 on every commit, including a regression check specifically for the owner-bypass case.
The audit log
Per-organisation, tamper-evident, hash-chained: each entry stores sha256(previous_hash ‖ canonical(event)), and the chain is serialised under a transaction-scoped advisory lock so it stays correct under concurrent writes. Append-only is enforced at two independent layers — REVOKE UPDATE, DELETE at the grant level, and RLS policies that permit only INSERT and SELECT with no UPDATE or DELETE policy defined at all. Removing an entry after the fact requires breaking both, and breaks the chain visibly either way.
Authentication
A magic link, and only a magic link. The token is 32 random bytes with a 15-minute TTL, single-use, consumed atomically so that a mail-client prefetch cannot burn it and a replay cannot reuse it. It is bound to the device that requested it, by comparing a sha256(token) cookie with timingSafeEqual. There is no account enumeration — a token is issued whether or not the address exists, so the response cannot be used to test which staff emails are real. Session IPs are stored hashed, never raw.
Being plain about the gap: there is no SAML, no OIDC, no Google or ClassLink sign-in, no MFA and no password. For a district standardised on Entra ID or Google Workspace, that is a real operational difference and a legitimate reason to choose somebody else this year.
The API surface
28 REST endpoints, organisation-scoped and RLS-enforced, with API keys stored as SHA-256 hashes and the plaintext shown exactly once at creation. Rate limiting runs at four tiers — per key, per SCIM key, per organisation, and per IP for unauthenticated traffic — with correct X-RateLimit-* and Retry-After headers. The caveat your reviewer will want: that limiter is in-memory and per process, so it resets on restart and does not coordinate across instances. It is a fair-use control, not a DDoS defence, and we will not describe it as one.
Outbound webhooks are signed Stripe-style, with an HMAC-SHA256 over "${timestamp}.${rawBody}", a DNS-resolving SSRF guard that rejects loopback, RFC1918 and link-local destinations after resolution rather than by string matching, exponential backoff, and automatic endpoint disable after ten consecutive failures. Roster connector configurations hard-reject literal credentials pasted into them — anything matching a known key prefix is refused, and you must use a reference pointer instead.
Encryption and transport
AES-256 at rest, TLS 1.3 in transit. That is table stakes and we mention it only so its absence is not inferred.
Data ownership: the rights, and the tooling gap
Two different things get conflated in every vendor trust page, so we separate them here. There is what the contract entitles you to, and there is what a button in the product does today. The first is stronger than most vendors'. The second is incomplete, and pretending otherwise would be the exact behaviour this company exists to be an alternative to.
- Export rights — contract §7.1. You may export everything, at any time, machine-readable, with no notice period and no fee. It is a term of the master agreement rather than a policy we can change. The tooling gap: self-serve export is not built. There is no export endpoint and no generator in the product today; it ships with the May 2027 release. Until then we run the export for you on request, same day. The right is real; the button is not there yet.
- Retention. The defaults below are published and binding on our design. The tooling gap: no purge job runs, and per-district retention configuration does not exist. The table is a policy document today, not an enforcement mechanism.
- Deletion on exit — contract §11.2. On termination, or on a change of control or a material change to data terms, you may exit within 90 days with a full export, a prorated refund and no penalty, and your data is deleted. The tooling gap: there is no signed cryptographic deletion receipt. Earlier versions of this page claimed one. It was not built, so the claim is gone rather than the sentence being softened.
- No family monetisation — contract §9.4. We will not market or sell to your families, and will not derive revenue from family-facing subscriptions, fees or transaction processing. Ever, in writing, not as a values statement.
| Record class | Default retention | Why that number |
|---|---|---|
| Student PII and roster records | While enrolled, plus 7 years | FERPA cumulative file practice in most states |
| Mass broadcasts | 3 years | Public-records and discovery exposure |
| Direct messages | 7 years | Communications about an identified student are education records |
| Forms and signed permissions | 7 years | Liability window on a signed instrument |
| Delivery and open logs | 13 months | Operational; one full school year plus a comparison month |
| Audit log | 7 years, append-only | Compliance; the chain cannot be truncated without detection |
Read this caveat before you cite the table. These are published defaults and a design commitment. They are not yet enforced by a purge job — there is no scheduled deletion process running today, and per-district retention configuration is not built. Treat the table as the policy we are building to, and hold us to it at your first renewal. We would rather you learned that here than from your own auditor.
Sub-processors
Anyone who touches district data on our behalf is listed here, with what they do and which data class they see. This list previously disagreed with the list in the product settings screen; the product settings screen was right and this page was stale. Both now say the same thing.
| Sub-processor | What it does | Data class it touches | Region |
|---|---|---|---|
| Supabase (Postgres + Storage) | Primary database and object storage | All | US |
| Resend | Transactional and bulk email | Email address, message body | US |
| Bandwidth | SMS and voice carrier | Phone number, message body | US |
| DeepL | Machine translation; the cache holds no PII index | Message body only | US / EU |
| Firebase Cloud Messaging / Apple Push | Push notifications — contracted but not enabled, because push is not built | Device token | US |
| Sentry | Error monitoring, PII scrubbed | Stack traces | US |
Six, all US-hosted, all under DPAs. Earlier versions of this page listed AWS, Postmark and Cloudflare; that list was stale and has been corrected. We notify district administrators by email 30 days before adding or changing a sub-processor. Only three — Supabase, Resend and DeepL — carry live traffic today, because we have no district in production.
Incident response, and what we will not chart for you
Target response times, committed as policy and available in writing during a procurement review. Severity 1 means the service is down, data has been lost, or there has been a security breach; we target acknowledgement within 15 minutes. Severity 2 — major degradation, slow delivery, partial outage — targets one hour. Severity 3, a minor or isolated issue, targets one business day. A confirmed breach is notified to your primary administrator and data protection contact within 72 hours, and the notification includes what we know, what we do not yet know, and when the next update lands.
These are targets from a team with no production traffic. Treat them as a commitment we are willing to have written into an agreement, not as a track record, because we do not have a track record.
On uptime figures, and how to test any vendor's. We publish no availability percentage, because a percentage over zero months of production is a made-up number. A public status page goes up at our first district cutover, and its history will start empty and stay honest. If a competitor shows you 99.99%, the useful follow-up is not "is that true" — it is "over what window, measured by what probe, and may we see the incident log behind it, including the ones you classified as degradation rather than outage". Availability figures are almost always technically true and rarely answer the question you meant.
Security disclosure goes to security@getkastr.com and is acknowledged within one business day. We run a disclosure process rather than a paid bounty programme — an earlier version of this page advertised specific bounty amounts, which was aspirational rather than funded, so it has been removed.
Procurement documents, no email gate
Your legal team can have the whole set without filling in a form or signing an NDA to read a contract: the Master Service Agreement (v2026.05, 14 pages, redline-friendly Word and PDF), the Data Processing Addendum (v2026.05, 8 pages, aligned to the state student-privacy statutes), the current sub-processor list, a security overview covering the architecture, RLS model, audit log and incident response, and the data-flow and per-tenant isolation diagrams.
Email security@getkastr.com and they come back the same day. There is no download portal — building one that gates a contract behind a lead-capture form would be a strange thing for us to do given everything else on this page, and building one that does not gate anything is a use of a week we would rather spend on the export tooling.
Questions people actually ask
Is Kastr SOC 2 certified?
No. SOC 2 Type II is planned and not started: no auditor is engaged and no observation window is open. Scope was defined in March 2026, the window opens at our first district cutover, and a Type II report needs months of observation after that before it exists. If a completed report is a hard requirement for your review, we do not pass it today.
Where does district data live, and who can see it?
In Postgres on Supabase, US-hosted, behind row-level security enforced through a non-owner, DML-only database role so table ownership cannot silently bypass it. Isolation is hierarchy-aware and fails closed: with no organisation set on the session, policies evaluate against NULL and return zero rows. Five other sub-processors touch narrower data classes and are listed on this page with the class each one sees.
Does Kastr support SSO, SAML or MFA?
No. A magic link is the only authentication method in the codebase — 32 random bytes, 15-minute TTL, single-use, atomically consumed, bound to the requesting device, with no account enumeration. There is no SAML, OIDC, Google or ClassLink sign-in, no MFA and no password. For districts standardised on an identity provider, that is a genuine gap.
Can we get our data out, and what does that cost?
Contract §7.1 gives you the right to export everything at any time, machine-readable, with no notice and no fee. Precisely where that stands today: self-serve export tooling is not built and ships with the May 2027 release, so until then we run the export for you on request, same day. The right is contractual; the button does not exist yet.
How long does Kastr keep student data?
Published defaults: roster and student PII while enrolled plus seven years, direct messages seven years, forms and signed permissions seven years, mass broadcasts three years, delivery and open logs 13 months, audit log seven years append-only. Important caveat — these are policy defaults, not enforced by a purge job today, and per-district retention configuration is not built.
What is Kastr's uptime?
Unknown, because there is no production traffic to measure. We publish no availability figure and run no status subdomain. A public status page goes up at our first district cutover with an empty history that then stays honest.
One price. Every feature. Locked for three years.
$3.50 per student per year under 5,000 students. No tiers, no add-on modules, no per-message fees. Published on the site because you should not have to book a call to learn a price.