The EdTech Vendor Security Questionnaire, and How to Read the Answers
Most district security questionnaires are inherited from a larger organisation and ask a small vendor about their data centre. The questions that matter for a communications platform are narrower and more answerable, and the useful skill is not writing them but reading the replies. This is the list we would want to be asked, including the questions we answer badly.
| Section | Questions | What it really tests | The answer to worry about |
|---|---|---|---|
| Company and posture | 5 | Whether there is anyone accountable | No named security owner |
| Tenant isolation | 7 | Whether another district can ever see your rows | “Logical separation” with no mechanism |
| Authentication and access | 6 | Who can get in, and how you would know | Shared administrator accounts |
| Audit and evidence | 6 | Whether an incident would be provable | Editable logs, 30-day retention |
| Data handling | 7 | What is held, where, for how long | No field inventory |
| Sub-processors and third parties | 5 | Who else touches it | A list that differs from the DPA's list |
| Delivery and telephony | 6 | The part unique to communications | Inability to explain what happens when a send fails |
| Incident response | 5 | Whether the clock can be met | A policy but no notice template |
| Exit | 5 | What leaving costs | Export “available on request” with no format or timeline |
Fifty-two questions is about ninety minutes of vendor time. If a vendor cannot turn it round inside a fortnight, that is itself an answer about the size of the team behind the product.
The questions that separate vendors, section by section
Tenant isolation
- By what mechanism is one district's data separated from another's? Name the layer.
- If the application forgets to set the tenant context, what happens — all rows, no rows, or an error?
- Does any part of the system run as the database owner, and if so, does that bypass your isolation policies?
- Do you test for cross-tenant leakage automatically? Against what — a mock, or a real database?
- Does a district see only its own rows, or also its schools' rows, and is that hierarchy enforced in the same layer?
Our answers, since we are asking you to ask them: Postgres row-level security; no rows, because with no organisation context the policies evaluate against NULL and it fails closed; no, every transaction sets a non-owner DML-only role so table ownership cannot silently bypass RLS; yes, a cross-tenant leakage suite runs in CI against real Postgres 16 including an owner-bypass regression check; hierarchy-aware, enforced in the same policies.
Authentication and access
- What authentication methods exist for staff? For families?
- Is SSO available? SAML, OIDC? Is MFA available?
- How are API credentials stored, and can they be retrieved after issue?
- What stops an administrator pasting a live third-party credential into a configuration field?
- Are session identifiers or IP addresses stored raw?
Ours: magic link only — no SSO, no SAML, no OIDC, no MFA, and if your standard requires any of them we fail here. The magic link itself is 32 random bytes with a 15-minute lifetime, single use, atomically consumed so a prefetching scanner cannot replay it, bound to the requesting device by a hashed cookie compared in constant time, and issued whether or not the address exists so it cannot be used to enumerate accounts. API keys are stored as SHA-256 hashes with the plaintext shown exactly once. Connector configuration hard-rejects literal credential patterns and requires a reference pointer instead. Session IP is stored hashed, never raw.
Delivery and telephony — the section nobody writes
- What happens when an SMS fails terminally? Is there a failover, and is the relationship between the two attempts recorded?
- Can the same message be delivered twice if a worker crashes mid-send?
- Are quiet hours enforced, and what bypasses them?
- Is there a cost estimate before a send, or does the district discover the cost afterwards?
- What is reported as “delivered”, precisely? Does it include messages merely accepted by a carrier?
- Is your A2P 10DLC brand and campaign registration current, and does the registered use case cover district traffic?
Ours: terminal SMS failure fails over to voice on the same contact with the two records linked; the queue claims work with SELECT FOR UPDATE SKIP LOCKED under a five-minute claim TTL so a crashed worker's rows auto-recover, with row-level idempotency keyed on broadcast, person and channel; network calls happen outside the transaction; quiet hours default to 21:00–07:00 and only an emergency-flagged send bypasses them; a live per-channel cost and reach estimate appears in the composer before you send. On the fifth question we will give you the uncomfortable answer: our current insights code counts an accepted-but-unconfirmed state inside its delivered figure, which contradicts our own stated principle that sent is not delivered. It is a known defect, it is on the list, and you should ask every vendor the same question and expect a worse answer.
How to read the replies
Four reading rules, learned from watching questionnaires go wrong.
- Specific beats reassuring. “We take security seriously” is a non-answer. “Row-level security policies evaluated under a non-owner role” is checkable, and you can ask a follow-up.
- A disclosed gap is worth more than a clean sheet. Nobody is fully green. A vendor with five honest gaps and a plan is a safer bet than one with none, because the second one is not reading the questions.
- Cross-check the sub-processor list against the DPA and the privacy policy. Three lists that disagree is the most common real finding in this exercise, and it usually means nobody owns the document.
- Ask one question that has no good marketing answer and watch what happens. “What is the worst outage you have had, and what did families experience?” works well. So does “what do you not do that your competitors do?”
The question to ask about SOC 2 before you require it. A SOC 2 Type II report is an auditor's opinion about controls the vendor selected, over a stated observation period, in a defined scope. It is meaningful. It is also routinely treated as a binary pass when the useful information is in the scope statement and the exceptions. Read those two sections first. And be aware that requiring SOC 2 filters out every pre-revenue vendor, including us — we have no report and have not been audited. That may well be the right policy for your district. It should be a decision rather than a default.
This page describes what a statute asks of a vendor. It is not legal advice, statutes are amended, and section numbering moves. Confirm the current text with your own counsel or your state education agency before you rely on any of it in a contract or a procurement file.
Questions people actually ask
What should a school district ask an edtech vendor about security?
Nine areas: accountability, tenant isolation, authentication, audit evidence, data handling, sub-processors, delivery mechanics, incident response and exit. For a communications platform specifically, the delivery section is the one generic questionnaires omit and the one where the real operational risk lives.
Is a SOC 2 report enough to approve a vendor?
It is evidence, not a verdict. The report's value is in its scope statement, the observation period and the exceptions, all of which are routinely skipped. A report scoped to a subsystem your district does not use proves little about the one you do.
How do we verify a vendor really separates district data?
Ask by what mechanism, at what layer, and what happens when the tenant context is absent. A mechanism named in the database layer with a failure mode of “no rows” is stronger than application-layer filtering, and an automated cross-tenant test running against a real database is stronger than either on its own.
Should we require SSO from a communications vendor?
If your district has an identity provider and a policy requiring it, yes, and be prepared for that to eliminate smaller vendors including us — we have no SSO of any kind. If you do not have that policy, the more useful questions are whether credentials can be retrieved after issue, whether administrator accounts are shared, and whether authentication events are logged in a way that cannot be edited.
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.