Security questions to ask a school communication vendor
A generic vendor security questionnaire will not find the risks specific to a communications platform, because it was written for a system that stores data rather than one that transmits it to thousands of households. The questions below are the ones that matter when the product's job is sending. Our own bad answers are listed in full, with no hedging.
| Question | A strong answer contains | A hedge sounds like | End the conversation if |
|---|---|---|---|
| How is one district's data isolated from another's? | A named mechanism, enforced below the application, plus how it behaves when tenant context is missing | "Logical separation" with no mechanism | Isolation is enforced only by application code adding a WHERE clause |
| What happens if the tenant identifier is not set? | Zero rows — it fails closed, and there is a test proving it | "That cannot happen" | They have not thought about it |
| Is cross-tenant isolation tested automatically? | A suite in CI against a real database, including a privilege-escalation regression | "It is covered in our pen test" | Tested manually, annually, by the team that wrote it |
| What authentication methods do staff have? | The complete list, including what is not supported | "Enterprise-grade authentication" | Passwords with no second factor and no policy |
| Can the audit log be altered or deleted? | A mechanism at the storage layer, not a UI restriction | "Only administrators can modify records" | Log rows are ordinary rows a support engineer can update |
| How are API keys and webhook secrets stored? | Hashed at rest, plaintext shown once, revocable | "Securely stored" | Retrievable in plaintext from a support console |
| Where do outbound webhooks connect to? | A DNS-resolving guard rejecting loopback, private and link-local ranges before delivery | "We validate the URL" | Any URL is accepted — that is server-side request forgery on request |
| Who are the sub-processors? | Named entities, what each receives, and notice before adding one | "Industry-standard cloud providers" | Three published lists that disagree with each other |
| Does message content leave your system for translation? | The named engine, what is cached, and whether the cache indexes anything identifying | "Translation is handled internally" | They do not know where the text goes |
| What is the incident notification path and timeline? | Hours, a named role, and what the first notice contains | "Promptly, as required by law" | No named owner exists |
The pattern is consistent: strong answers name a mechanism and a test, weak answers name a category. A vendor whose engineer can describe the failure mode of their own isolation model in one sentence is a different proposition from one whose sales engineer says "multi-tenant with logical separation" and moves on.
The other twenty-eight, by section
Tenancy and access (6 questions). Which database role does application code run as, and does it own the tables? Can a support engineer read a district's message content, and is that access logged? How is access revoked when a vendor employee leaves? Are production and non-production data separated, and is production data ever copied into test? How are backups isolated per tenant? Who can restore a backup, and does a restore preserve tenant boundaries?
Authentication and session (5). What is the full list of supported staff authentication methods? What is the token or session lifetime, and can a session be bound to a device? Is there account enumeration on the login flow? How are sessions revoked centrally? Is any identifying network data stored in plaintext against a session?
Audit and records (5). Which events are logged, and which are not? Is the log ordered and chained, or merely timestamped? What can the vendor's own staff do to it? How is a records-request export produced, and in what format? What is the retention period for the log itself, and who can change it?
Data handling (5). Which record classes carry which retention default? Is retention enforced by a job, or documented as a policy? What is deleted on request, and what evidence is produced? Where is data resident? What happens to data in transit to telephony and email providers?
Integrations (4). How are roster credentials stored, and can a district paste a literal secret into a connector configuration? What rate limits apply, and are they per key, per organisation or per address? Are outbound webhooks signed, and over what payload? What happens after repeated delivery failures?
Incident response (3). What is the notification timeline in hours, to whom, containing what? Who is the named security owner? What is the disclosure path for an external researcher?
Where Kastr answers badly, stated flatly
No qualifiers, no roadmap language.
- Authentication. There is no SSO, no SAML, no OIDC, no Google or Microsoft sign-in, and no MFA. Magic link is the only authentication method that exists in the product. For a district with a federated identity mandate this is a legitimate and sufficient reason to reject us, and we will not argue the point in a security review.
- SOC 2. Not audited. We are pre-launch. We will not write "in progress" to earn partial credit.
- Uptime. We publish no availability figure and no status history, because we have no production operating history to compute one from.
- Load and delivery time. No published load-test result and no stated time to reach a full district. Any vendor's figure here should be treated as marketing unless it comes with a method.
- Retention. Defaults per record class are published. There is no purge job enforcing them today, so treat the retention table as a stated policy rather than an enforced control.
- Deletion evidence. There is no cryptographic deletion certificate. Deletion happens; a mathematical proof of it does not.
- Read-scope enforcement. API keys carry scopes, and scope enforcement is currently applied to send and provisioning operations rather than to read operations. Treat any non-revoked key as able to read organisation data, and manage keys accordingly.
- Rate limiting. Implemented in process. It behaves correctly on a single instance and resets on restart; it is not a distributed control.
Where our answers are good, and how to verify them in a trial
Tenancy isolation. Every request runs inside a transaction under a non-owner, DML-only database role, with Postgres row-level security policies enforcing organisation scope below the application. Table ownership cannot be used to bypass the policies, because the application role does not own the tables. Isolation is hierarchy-aware: a district sees its own rows and those of its child schools, never another district's. With no organisation context set, policies evaluate against NULL and return zero rows — it fails closed rather than open. A cross-tenant leakage suite runs in CI against real Postgres, including an owner-bypass regression check. To verify: ask for a trial tenant, an API key, and a second tenant's identifier, then try to read across.
Audit integrity. Each organisation has an append-only audit log whose entries are chained with SHA-256, each hash covering the previous hash and the canonical event. Chain writes are serialised under an advisory transaction lock so concurrency cannot corrupt the order. Append-only is enforced at two independent layers: UPDATE and DELETE are revoked at the database role, and the row-security policies grant only INSERT and SELECT. What that proves: that entries have not been altered or removed after the fact without the chain breaking. What it does not prove: that an event was correct when it was written, or that a message was delivered. A hash chain is evidence about the record, not about the world.
Keys, webhooks and connectors. API keys are SHA-256 hashed at rest and the plaintext is shown exactly once. Outbound webhooks are signed with an HMAC over a timestamp and the raw body, delivered through a DNS-resolving guard that rejects loopback, RFC1918 and link-local destinations, with backoff and auto-disable after repeated failures. Roster connector configurations reject literal credentials outright — strings that look like provider secrets are refused and you must supply a reference instead.
The translation question, answered specifically. Message text is translated by DeepL. Results are cached in a persistent global cache keyed by a SHA-256 hash of source language, target language and source text, so a row is retrievable only by someone who already possesses the exact source string — the cache carries no index of who sent what, or to whom. With no key configured, or on failure, the system passes the original text through honestly and still records the intended target language, rather than silently sending untranslated text as though it had been translated. Senders can preview the translation before the message goes out.
Questions people actually ask
What security questions should a district ask a communication vendor?
Start with the four that separate real answers from categories: what mechanism isolates one district's data from another's, what happens when tenant context is missing, whether that isolation is tested automatically in CI, and whether the audit log can be altered by the vendor's own staff. Then ask where message content goes for translation and telephony, and what the incident notification timeline is in hours.
Does Kastr support SSO, SAML or MFA?
No, to all three. Magic link is our only authentication method. There is no SAML, no OIDC, no Google or Microsoft sign-in and no multi-factor authentication anywhere in the product. If your district's identity policy requires federated staff login, that is a sufficient reason to reject us and we would rather you knew now than in week six of an evaluation.
Is Kastr SOC 2 certified?
No. We are pre-launch and have not been audited. We also publish no uptime figure and no load-test result, because we have no production operating history to compute either from. If a current SOC 2 Type II report is a hard requirement in your procurement, we cannot satisfy it today.
How does Kastr prevent one district seeing another district's data?
Postgres row-level security, enforced below the application, with every request running under a non-owner, DML-only database role so table ownership cannot bypass the policies. Isolation is hierarchy-aware so a district sees its own and its child schools' rows. With no organisation context set, policies evaluate against NULL and return zero rows, and a cross-tenant leakage suite runs in CI against real Postgres including an owner-bypass check.
What does a tamper-evident audit log actually prove?
That entries have not been modified or removed after they were written, because each entry's SHA-256 hash covers the previous one and any alteration breaks the chain. It does not prove that an event was recorded correctly in the first place, and it does not prove that a message reached a household. It is evidence about the integrity of the record, which is what a records request or an appeal actually tests.
How are API keys and webhook secrets protected?
API keys are hashed with SHA-256 at rest and the plaintext is displayed exactly once at creation, so a compromised console cannot reveal existing keys. Webhooks are signed with an HMAC over a timestamp and the raw request body, and delivery passes through a DNS-resolving guard that rejects loopback, private and link-local addresses before any request is made.
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.