Most security pages are a list of assurances. This one is a list of things a district can check — because the same controls described here are probed inside the product, against your own database, on a screen you can open.
A security page is usually written to be believed. This one is written to be checked.
Every claim below is a structural fact about how the system is built — a grant, a policy, a constraint, a function — and each is the subject of a probe that runs against your own district’s database and prints what it found. The probes are on the Security screen inside the product. They read; they change nothing; they stamp the time on the answer.
Every district’s data sits behind row-level security in Postgres. Each private table has RLS enabled and a policy behind it, so a query that asks for another district’s rows does not get them — even if the application asking has a defect, and even if the query is written by hand.
The fence is identity-based, not parameter-based. A request carries a signed session; the database resolves the acting person and their district from that session, and a request it cannot identify is refused rather than defaulted. Neither the role nor the district on an account is writable by the client.
| Wall | What it stops | Where it lives |
|---|---|---|
| Row-level security | Reading another district’s rows | Postgres policy |
| Identity fence | An unidentified actor falling back to a district | Postgres function |
| No write grants | Writing anything without going through a door | Grants |
| Immutable role & district | An account rewriting its own authority | Column privileges |
A posting is never edited and never deleted. A correction is a reversing entry that carries its own author, date and written reason, and both sides stay on the record — which is what an auditor is actually asking for when they ask what changed.
Every entry is sealed behind the one before it. The chain can be verified on demand, in the product, and a ledger that has been altered outside the application does not verify and says so on the screen rather than quietly reporting a total.
Three dimensions, and all three are enforced in the database as well as in the interface. Role says which actions. Scope says which funds, buildings, programs and grants. Separation of duties is a set of hard constraints rather than a policy a district writes down and hopes about.
TLS for everything in transit, including the API and the SFTP path districts use to send extracts. AES-256 at rest for the database and its backups. SFTP authenticates with SSH keys rather than passwords.
Credentials are never held in the application: sign-in goes to the identity provider, the browser holds a short-lived session token, and no page in this product asks a person to type a password anywhere except the sign-in screen.
The database is managed Postgres with automated backups and point-in-time recovery. The application itself is a static bundle served from a CDN, so a deployment is an atomic swap and a rollback is the previous bundle — there is no partially-updated state to be caught in.
Because the ledger is append-only and chained, a restore is verifiable: the chain either verifies to the point of restore or it does not, and the product says which.
Every third party that touches district data is named. Adding one is a change to this page and to the Privacy Policy, not a quiet configuration change.
| Sub-processor | What it does | Bound by |
|---|---|---|
| Supabase | Database and authentication — where the ledger lives | DPA |
| Netlify | Static hosting and content delivery for the application | DPA |
| Anthropic | The AI that drafts insights, packets and exception reports | DPA |
| Sentry | Error and performance monitoring | DPA |
Every change to the product runs an automated battery before it ships — more than one hundred and fifty suites covering the accounting, the statutory tests, the doors, the screens and the security posture itself. A red suite is a defect, and the battery is the thing that decides whether something ships.
Database changes are migrations: written down, reviewed, applied in order, and readable afterwards. A function is never replaced without first reading out what it currently does.
If district data is affected by a security incident, the affected districts are notified without undue delay and told what happened, what data was involved, what has been done and what they should do — in that order, in plain words.
Errors and anomalies in the running application are monitored continuously. A door that fails between accepting an entry and confirming it reports itself, because the one outcome a finance system must never have is a person who cannot tell whether their entry posted.
A district’s books are the district’s. On cancellation the full data set is exported in a portable format and the data is then permanently deleted after ninety days.
Inside the product, records carry a retention class under the New York State LGS-1 schedule and a computed eligibility date — and nothing is ever destroyed automatically. Destruction of a public record is signed for by a records access officer; software that tidies up on a schedule has destroyed evidence. A record under audit, under litigation hold or subject to a FOIL request is held whatever its class says, and the hold, the release and both names stay on the change history.
FERPA. No individual student record enters the platform, so there is no education record to protect here. That is a scope statement rather than a control, and it is the strongest form the answer can take.
SOC 2. WhiteOak is built to the Trust Services Criteria and is not yet SOC 2 certified. A readiness programme with continuous control monitoring is in progress; when a report is issued it will be published here and available under NDA. We would rather say that plainly than let a badge imply something that has not happened yet.
New York State. The statutory tests the product enforces — RPTL §1318, GML §103 and §104-b, Education Law §1724 and §1716, 8 NYCRR §170.8 — are implemented as dated rules rather than constants, so a transaction is tested against the threshold that was in force on its own date.
If you believe you have found a security issue, email security@whiteoakio.net with enough detail to reproduce it. We will acknowledge within two business days and keep you updated until it is resolved. We will not pursue anyone acting in good faith who reports an issue to us and gives us a reasonable chance to fix it before disclosing it.
Please do not test against a district’s live data. Ask us and we will arrange somewhere for you to test.
A district’s counsel, an auditor or an investor reading this before signing is exactly the reader it is written for. Send the question and you get an answer from a person — and where the answer is a probe, you get to run it yourself.
Email security@whiteoakio.net Or read the Privacy Policy · Terms of Service