Security Overview
What this is, and what it is not
A New Jersey district evaluating DataVot has a security question on its checklist, and its technology director generally answers it before anyone is asked for anything. This page is that answer, with the evidence named rather than asserted.
It is a summary. The full assessment is a longer internal document that names file paths, individual controls and every open weakness in detail. NDPA §5.2 is what governs it: we provide a copy to a district on written request, subject to a confidentiality agreement and reasonable redaction. Ask for it — this page exists so you can decide whether it is worth asking, not to stand in for it.
It is not an audit. DataVot has no SOC 2 report, no ISO 27001 certification and no external penetration test. Saying so here is deliberate, and our Questions and answers page and Data Privacy Agreement say the same thing. A self-declared posture dressed up as an audit is worse than an honest self-assessment, and a district that discovers the difference later has every reason to distrust everything else we have told it.
How your data is protected
The controls below are the ones a district security questionnaire asks about, in roughly the order it asks them. Where a row says a build check enforces something, that is the substantive claim on this page — it means the release is blocked if the control regresses, rather than the control depending on somebody remembering it during a future change. That is unusual, and it is the part of this posture we would ask you to weigh most heavily.
| Control | What is implemented |
|---|---|
| Encryption at rest | Uploaded results are gzip-compressed then AES-GCM encrypted before they are stored. A build check fails the release if any write path stores them another way, so this cannot be bypassed by a future change. The encryption key is held as a platform secret that the database itself does not contain — a copy of the database alone decrypts nothing. |
| Encryption in transit | TLS throughout. The certificate is checked on a schedule by the same job that runs the dependency audit, so an approaching expiry surfaces before a browser reports it. |
| Student data never leaves the server | Dashboards are aggregated server-side and return counts only. Raw student rows are never sent to a browser to draw a chart, so what a compromised laptop or a shared screen can expose is bounded by design rather than by policy. |
| No student PII in the clear | A build check fails on a database column named for student PII, so identifiable data cannot be moved out of the encrypted blob into a place the admin browser and the backup file would carry it. A second check keeps student rows and name fields out of the diagnostic log. |
| Two-factor authentication | Required for our own System Administrators and enforced at the gate, not offered as a setting — an account that has merely begun enrolment does not satisfy it, because a stored secret nobody has proved they hold is not protection. Available to your school administrators, opt-in per district. Codes to an email address are offered as the weaker second method and the screen says so in those words; our own administrators may not use it, since that account’s second factor must not be the channel already carrying its own password reset. |
| Password and session handling | Passwords are hashed with bcrypt at a cost floor enforced as a build check. Sessions are signed tokens in httpOnly, same-site cookies, bounded at both ends to NIST SP 800-63B AAL2 figures — a 30-minute idle window and an absolute cap measured from sign-in, so a sliding window cannot renew for ever. The tight default is what a shared classroom machine gets. |
| Revoking access | A password change invalidates every existing session for that account, and every authenticated route re-checks this on every request rather than trusting a token that still verifies. A build check fails the release on a route that resolves a caller without making that check. |
| Who can see which schools | Row-level access is applied by one function, after four divergent copies were found and consolidated. It is tested against a seeded database with a fixture deliberately containing both Lincoln High School and Lincoln High School Annex, so a regression that matched on a substring — silently widening every teacher’s scope — fails instead of passing. |
| Support access to your data | Only with your consent, and visible while it happens: a time-boxed, audited session that never uses or reveals a password, with a banner on screen throughout and an email record every time. Optionally the affected user is emailed directly as well. There is no silent path. |
| Tamper-evident audit trail | Every log row commits to its own content and to the row before it, under a keyed hash whose key the database does not hold — so a database dump, the admin viewer and a stolen backup all lack what would be needed to forge or quietly edit an entry. The head of the chain is mailed out nightly, which is what closes truncation: removing the end of the trail destroys an anchor rather than leaving no trace. |
| Backup and restore | A full restorable export at any moment, with the encryption key backed up separately and deliberately never travelling with the data, plus 30 days of point-in-time restore from the database provider. The restore is exercised on every release — dump, restore into an empty database, compare every value, decrypt a student record out of the restored copy, and confirm each teacher’s access restrictions survived. A restore that quietly widened everyone’s scope is the worst way for one to "work". |
| Application hardening | A Content-Security-Policy emitted per request with a script nonce and no inline scripts; all six security headers enforced; state-changing requests rejected from an unknown origin; uploads typed by magic bytes rather than by what the browser claims the file is; stored HTML re-sanitised on read through an allowlist. Each is pinned by a build check rather than by review. |
| No trackers, no advertising, no model training | Verified two ways, because "no analytics vendor" is a claim about a shipped JavaScript bundle and not an intention: a dependency check, and a pinned allowlist of the external hosts the browser is permitted to contact at all. School data is never used to train any model. |
Where the data is, and who else touches it
The primary database runs in Cloudflare's Eastern North America region, and read replication is switched off, so no copy exists anywhere else. A build check fails the release if replication is ever enabled — because the database carries no jurisdiction setting, turning it on would place a replica in every available region and change this answer into a list of countries. It is presented by the platform as a latency feature, which is exactly why it needs a guard: whoever reaches for it is thinking about query speed, not about a contract.
2 subprocessors, and no others. There is no advertising network, no analytics vendor building a profile of your staff, and no third party other than the providers named above ever receives student data.
| Subprocessor | Role | Data involved | Location |
|---|---|---|---|
| Cloudflare, Inc. | Hosting, edge compute, encrypted database storage, security and request processing | Application data, uploaded data when saved, account data, logs | United States |
| Resend | Transactional email (no student records are sent by email) | Email address and email content for invitations, password resets, verification and support notices | United States |
Our DPA commits us to telling your school before any new subprocessor handles student data. The list is defined once in the codebase and rendered everywhere it appears, so the copy your business office is holding cannot disagree with this page.
Assessment results
Every one of the 22 categories in the NIST Cybersecurity Framework 2.0 was rated against the code as it actually stands. Met means implemented and there is a check, test or artifact that would fail if it regressed. Partial means implemented in substance but undocumented, unmeasured or incomplete. Gap means not implemented. A control claimed with nothing a reader could open is recorded as a gap.
| Function | Met | Partial | Gap |
|---|---|---|---|
| Govern | 3 | 3 | 0 |
| Identify | 2 | 1 | 0 |
| Protect | 4 | 1 | 0 |
| Detect | 0 | 2 | 0 |
| Respond | 1 | 3 | 0 |
| Recover | 1 | 1 | 0 |
| Total (22 categories) | 11 | 11 | 0 |
The shape of that result is the finding, and it is worth reading rather than scoring. The technical controls over student data are strong and unusually machine-enforced. What was thin was everything organizational — incident response, recovery communication, oversight cadence, written policy. That is the predictable profile of a small engineering-led product, and it is exactly the half a district's counsel asks about, so it is the half that has had the most attention since the first assessment.
The remaining 11 Partials are not 11 near-misses. Most are documentation of something already built — a written policy behind a practice already enforced in code, a stated risk tolerance behind a risk register that already works. Two would move with engineering we have already scheduled: extending two-factor enforcement beyond our own administrators without locking a school out of its own account, and correlating security events rather than reviewing them reactively. Weigh each Partial by what it asks for, not by the count.
If there is a breach
There is a written data breach response plan, built from the U.S. Department of Education's PTAC Data Breach Response Checklist and NIST SP 800-61 rather than invented. NDPA §5.4(3) requires it to exist and requires us to give any district a summary on reasonable written request; ask and you will get one.
- You are notified within 72 hours of confirmation, and that is a contractual commitment in our DPA rather than an aspiration — including the nature of the incident, the data involved and the remediation steps, with a first notice inside the window even where facts are still emerging.
- The written incident log starts before validation, not after. The confirmation timestamp that starts the 72-hour clock is therefore recorded rather than reconstructed afterwards.
- New Jersey requires the State Police to be notified before individuals are (N.J.S.A. 56:8-163(c)(1)). That order of operations is written into the plan as a numbered step, because it is the one most generic breach plans get wrong.
- During recovery you get an update at least daily until service is restored and scope is settled — including when the update is “no change”, each stating what is and is not working, what you need to do, and when the next update will come.
- We support your obligations, not just ours. The plan covers cooperating with the district's own notification duties under New Jersey law and FERPA, and the decision on identity-protection services.
Known limits
Stated here rather than buried, because your reviewer will find them and we would rather you learn them from us. The first three are structural — no amount of writing closes them.
- This is a vendor self-assessment. No SOC 2 report, no ISO 27001 certification and no external penetration test has been performed.
- DataVot is operated by one person, so there is no separation of duties and no deputy incident manager. External counsel is engaged at incident confirmation instead.
- Cloudflare reports database placement by region rather than by country, so the location commitment below is a region and an undertaking to notify — not a country-level guarantee.
- Two-factor authentication is mandatory for our administrators and opt-in for yours. Making it mandatory for an existing school without a supported enrolment window would lock out the one person who can invite anybody back in, so the sequencing is scheduled rather than waved away.
- Security events are analysed reactively. Failed sign-ins and support sessions are all recorded and the trail is tamper-evident, but nothing yet correlates them into an alert on an authentication anomaly.
- No recovery time or recovery point objective is published. The restore path is tested on every release, but we have not committed to a number, and one restore rehearsal against production data rather than a fixture is still outstanding.
- There is no uptime guarantee. The service is provided on a best-efforts basis, as our Terms of Service state.
For your security questionnaire
If your district requires a vendor questionnaire completed, a DPA signed, or a copy of the full assessment, ask for all three at once — they are one piece of work at this end and we return them together, within 10 business days.
- We sign your DPA, or the New Jersey SDPC National Data Privacy Agreement, whichever your board already uses — and we sign it before any student data is uploaded, not after. Our template is published at /dpa if you would rather start from ours.
- The full assessment comes under a confidentiality agreement, per NDPA §5.2.
- A summary of the breach response plan, per NDPA §5.4(3).
- The accessibility self-assessment is already published, at /accessibility — all 52 WCAG 2.1 A and AA criteria with the evidence for each.
Write to info@datavot.com with the subject “Security — [School or District Name]”, or use the contact page. That is also the address for reporting a suspected incident. DataVot is operated by one person, so the security contact and the incident manager are the same individual; that is disclosed rather than presented as a team.