DRAFT — not legal advice — requires review by a qualified lawyer before use.

This document describes what Hebrabic actually does today, but it has not been reviewed by a lawyer and is not in force. Text in [square brackets] is a placeholder for the owner to complete.

Draft

School Data Processing Agreement

Draft of September 30, 2026

This template is meant to be signed between a school (or school network, or local authority) that uses Hebrabic with its students and the operator of Hebrabic. The school decides why its students use Hebrabic; Hebrabic processes the students' and staff's personal data on the school's behalf to provide the service. The factual parts below describe how Hebrabic works today.

1. Parties and roles

The School: [school's legal name, address, contact person] ("the School").

The Provider: [operator's legal name, registered address and company number] ("the Provider"), which runs Hebrabic.

Confirm the legal roles (for example controller and processor, or the equivalent terms in the applicable law) and the laws this agreement is made under.

2. Subject, duration, and purpose

Subject: providing the Hebrabic School plan to the School: classes with join codes, assignments, progress dashboards and spreadsheet exports for teachers, an admin console for the School, and learning features (including cloud sync) for everyone holding a seat.

Duration: for as long as the School has a Hebrabic subscription, and afterwards only as described in section 9.

Purpose: only to provide and secure the service for the School and its users. The Provider does not use the School's personal data for advertising, does not sell it, and does not build profiles of students for any other purpose.

3. Whose data

  • Students who join the School's classes.
  • Teachers, admins, and owners the School adds to its Hebrabic organization.
  • People the School invites by email (for example through the Google Classroom roster import, where it is enabled).

4. What data

  • Account: name, email address, whether the email is verified, a one-way hash of the password if one is set (or a link to the person's Google account), and a Stripe customer ID: while billing is switched on, a Stripe customer record holding the person's name and email address is created with every account, so that they can subscribe later.
  • Sessions, for security: when a session started and expires, and the IP address and browser (user agent) it came from.
  • Learning progress synced from the device: flashcard scheduling, quiz totals, completed lessons, and display preferences.
  • Activity while signed in: which drill, lesson, dialogue, or quiz was done, when, and the score (0–100) where there is one.
  • Class data: class memberships with join and leave dates, assignments, and notices to teachers (for example when a student couldn't join because the seats were full).
  • Organization data: the School's name, members and their roles, invitations (email address, name if known, who invited them and when), and the School's subscription (plan, status, seat count, dates).

The Provider does not ask for dates of birth, addresses, phone numbers, photos, or any special category of data. Speaking practice runs in the browser: the browser may send the student's voice to its maker's speech service, and Hebrabic receives only the recognized text, which it does not store. Card details for the School's payments are handled by Stripe and never reach the Provider.

5. Who can see it

  • Each person can see and export their own data.
  • A class's teacher sees each enrolled student's name, email address, and activity in the class since that student joined, and assignment completion. Activity from before joining is never shown. A student who leaves or is removed disappears from the roster and dashboard.
  • The School's owners and admins see the same for all of the School's classes, the School's members, and seat usage, and can export it.
  • The Provider's staff access personal data only when needed to run, secure, or support the service. [Named roles and access policy to be completed.]

6. The Provider's commitments

  • Process the School's personal data only on the School's documented instructions, which are this agreement and the School's use of the service's settings.
  • Make sure everyone with access is bound to confidentiality.
  • Keep the security measures in section 7 in place.
  • Help the School answer requests from students, parents, and staff to access, correct, export, or delete data. The service already lets any user download their data and delete their account.
  • Tell the School without undue delay, and at most within [number] hours, after becoming aware of a personal data breach affecting the School's data, with what is known at the time.
  • Give the School the information needed to show compliance with this agreement. [Audit terms to be agreed.]

7. Security measures

  • The site is served only over HTTPS.
  • Passwords are stored as one-way hashes. The sign-in cookie is HttpOnly (page scripts can't read it) and marked secure on the live site; sessions last 7 days and are renewed while in use.
  • Every request for class, school, or progress data is checked on the server against the signed-in person's role: teachers reach only their own classes, and school admins only their own school.
  • Paid content is checked on the server as well, not only in the browser.
  • Deleting an account removes the person's data from the database in the same operation (cascading deletes).
  • Error monitoring, where enabled, is configured to send no IP addresses, cookies, request contents, or email addresses.
  • [Database encryption at rest, backups and their retention, and staff access controls to be confirmed with the hosting providers' settings.]

8. Sub-processors

The School authorizes the Provider to use the following sub-processors. The Provider will tell the School about new sub-processors [number] days in advance, and the School may object.

  • Vercel — hosting of the website and cookieless anonymous usage statistics. [Region to confirm.]
  • Neon (through the Vercel Marketplace) — the Postgres database. [Provider and region to confirm.]
  • Stripe — payments and invoices; also receives each account's name and email address when the account is created (see section 4).
  • Resend — account emails (sign-in links, invitations, confirmations).
  • Google — only if a user signs in with Google or the School uses the Google Classroom roster import.
  • Sentry — error monitoring, only if enabled, and configured to exclude personal data as described in section 7.

International transfers: identify where each sub-processor stores data and the legal mechanism for any transfer, with counsel.

9. Retention and deletion

  • Account data is kept until the person deletes their account, or until it is deleted at the School's request.
  • When a student leaves a class or is removed, the enrollment is marked as ended; the teacher no longer sees the student. The student's own activity stays in their account until it is deleted.
  • Classes can be archived; archived classes and their assignments are kept until deleted with the account or at the School's request.
  • Stripe keeps payment records as the law requires.
  • When the School's subscription ends, [the Provider deletes or returns the School's data within [number] days, at the School's choice — to be agreed]. Students' personal accounts [remain theirs / are deleted — to be decided with the School].

10. The School's commitments

  • Have a lawful basis, and any consent required from parents or guardians, before students use Hebrabic.
  • Tell students and parents how Hebrabic is used, for example by sharing the note on students' data.
  • Give Hebrabic access only to staff who need it, and remove staff who leave.

11. Liability, term, and signatures

Liability, precedence over other agreements, governing law, and signature blocks to be completed by counsel.

For the School: [name, role, date, signature]. For the Provider: [name, role, date, signature].