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. DataVot is operated by one person, so there is no separation of duties behind these controls and no deputy incident manager. 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. Any user can switch it on for their own account, and a district can require it of all its staff — a Settings toggle a School Admin controls, which opens a 14-day grace window before it locks anyone out. The second factor is an authenticator app, for every account. Codes sent by email are no longer offered, because password resets go to the same mailbox and a code there adds no second lock; an account that set them up earlier keeps signing in with them, but from October 20, 2026 they no longer satisfy a district’s requirement until the person switches, which the Security screen always lets them do. |
| 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 | Database in Cloudflare’s Eastern North America region; requests handled at the Cloudflare data center nearest the user |
| Resend | Transactional email (no student records are sent by email) | Email address and email content for invitations, password resets, verification, emailed two-factor sign-in codes, support notices, forum notifications, contact-form messages, and error alerts to our own staff | 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 engineering items this section used to name as tracked work both shipped 5 September 2026: extending two-factor enforcement to a district's own staff, and correlating security events instead of only alerting on one at a time. Neither closed its Partial outright — see Known limits below for what each still does not cover — but both moved from nothing to something tested. 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, but for school staff it is the district’s choice — a Settings toggle a School Admin controls, starting a 14-day grace window rather than an immediate lock, so nobody (including the admin who turned it on) can be locked out of the account that would undo it. We do not yet require it of every account that can see student records. Where it is on, it means an authenticator app: emailed codes were retired, and stop counting on October 20, 2026.
- Security events are correlated nightly, not continuously. A cluster of failed sign-ins across several accounts from one address, or an unusual burst of support-access sessions, now raises an alert automatically — but the check runs once a night on the same schedule as our data-retention sweep, so detection can lag up to a day, and the thresholds are reasoned defaults rather than ones checked against real attack traffic.
- 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 50 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.