אSecurity & student privacy, plainly explained

Built for schools that
answer to parents.

Or Hadash runs the office work your school depends on — with access rules, audit trails, and AI safety limits enforced in the code itself, not just written in a policy. Here's exactly how it works, in plain language, with nothing rounded up.

Every claim on this page is verified against the live product — last checked July 30, 2026.

No ads, ever

Zero analytics or ad trackers anywhere in the product — especially on student pages.

Humans confirm

Or drafts sensitive actions; a person approves before anything actually happens.

US-based hosting

Vercel and Supabase, both US regions — your school's data doesn't leave the country.

Access & roles

Five roles. Nothing more than each one needs.

Or Hadash has five account roles — student, parent, teacher, admin, and school_admin — each seeing a deliberately narrower set of menus and pages built for what that role actually does. Hiding a menu isn't the security; the server-side check behind it is.

Children never self-register. Every student, parent, and teacher account is created by the school itself — individually or through a roster import. There is no public sign-up path for a child anywhere in the product.
Every page is checked twice. What a role's menu doesn't show is also independently blocked on the server if visited directly — and every API request re-checks who's actually signed in against the database, every single time.
First login forces a real password. A school-assigned starting password can't linger as anyone's permanent credential — every new account must set its own password before it can do anything else.
"Preview as user" is read-only. When an admin looks at the app the way a specific teacher or family sees it — for troubleshooting — that preview session cannot change any data. The server rejects any attempt, not just the screen.

Student privacy & COPPA

The safe assumption, not the convenient one.

Or Hadash is built for schools serving children under 13, so COPPA — the Children's Online Privacy Protection Act — is a design constraint, not an afterthought. Schools act as the consenting party for their own students, consistent with the FTC's school-official guidance.

Unknown age means AI is off. If a student's date of birth is ever missing, the system treats them as if they were confirmed under 13 and turns AI off for them by default — the safe assumption, not the convenient one.
Some things AI is never allowed to do. Regardless of any setting, AI cannot autonomously assign a final grade, decide discipline, or issue a suspension — those are hard-blocked, not just discouraged.
AI drafts; a human publishes. Any AI-written feedback comment, suggested grade, or rubric sits as a draft until a teacher explicitly reviews and saves it — AI never sends anything to a student or family on its own.
A student's name or photo is never public by default. A public fundraiser page or leaderboard defaults to "First L." or full anonymity, and only shows a full name once an active, specific parental consent is on file.
Parents can turn AI off for their child, any time, from their own account — it takes effect immediately, everywhere.
No ads, no trackers, ever. There are no analytics or advertising scripts anywhere in the product, including every student-facing page — nothing reports usage data to an outside company.

AI safety

One gateway. Humans confirm what matters.

Every AI call in the product — no exceptions — passes through a single, audited gateway rather than being wired up ad hoc inside individual features. That's enforced by a lint rule, not just a convention someone could forget.

Zero data retention, by default. Every request to our AI provider sends a header instructing it not to retain the data, and identifying details are stripped or tokenized before anything leaves for the model — restored only in the reply that comes back to the school.
A human confirms before anything sensitive happens. Or (the assistant) drafts and shows exactly what it will do; grades, money, and deletions require a person to explicitly confirm — the model can never confirm its own action.
Switching AI providers is a legal gate, not a setting. A separate, code-level check keeps any AI provider other than our primary one from touching student data at all unless an explicit legal and consent review has been completed for that provider.
Every school has a spending ceiling. A monthly AI budget per school means no single school's usage can run away unbounded.

Data protection

Isolated by school. Provable, not just promised.

Every school's data is scoped to that school on every database query today, enforced in our application code and re-checked against the signed-in user's school on every request.

A second lock is written and staged, not flipped on yet. We've built an additional, database-level enforcement layer (Postgres row-level security) that would make cross-school access structurally impossible even if a future bug ever slipped past the application check above. It isn't switched on for any table yet — turning it on safely means confirming every query works correctly under it first, so the plan is to enable it table-by-table rather than flip one switch for the whole database at once.
Encrypted in transit and at rest, on US infrastructure. All traffic to and from Or Hadash is encrypted; the database and hosting run on Vercel and Supabase, both in US regions.
Every sensitive action leaves a tamper-evident trail. Logins, AI calls, opt-outs, data erasures, and role changes all write to an append-only log, chained so a deleted or altered entry would be detectable — the database itself refuses to let any row be changed or removed, even from our own application's account. Money-related actions (donations, receipts, refunds) get their own separate audit trail on top of that.
Full deletion, on request. Or Hadash can permanently erase one person's data or an entire school's data — both are real, working, logged operations, not a policy promise.

Where your data lives

US infrastructure, named plainly.

No vague references to 'the cloud' — here is exactly which companies host Or Hadash and where.

Hosting & application: Vercel, region sfo1 (San Francisco).
Database: Supabase Postgres, region us-west-2 (Oregon).
Email: Receipts, password resets, and notifications send through Resend from a verified sending domain, authenticated with SPF and DKIM so school email doesn't land in spam and provably came from Or Hadash.

Honest about where we are

We'd rather tell you than round up.

Schools trust honesty more than badges. As of July 30, 2026, here is exactly what's still in progress — not glossed over, not buried in a footnote.

Data processing agreements with our infrastructure and AI subprocessors (Vercel, Supabase, Anthropic) are being finalized. The technical protections described above — zero-retention headers, identity tokenization, US-only hosting — are live today; the signed paperwork confirming them contractually is in progress, not yet complete.
SOC 2 has not yet been pursued. Worth knowing if your procurement process requires it as a checkbox — it isn't a reflection of the underlying controls, which this page describes as they actually exist in the product today.
The database-level isolation layer described above is written and tested but not yet enabled for any table. Application-level isolation is real and enforced today; turning on the database-level backstop table-by-table is our current, active hardening focus.

Questions about how we
handle your school's data?

Reach us through the contact page and we'll route it to the right person — a signed data processing agreement for your school is available on request.

We're pointing you to the channel we know is actually staffed, rather than publish a security inbox that might not be monitored.

Built for schools thatanswer to parents.