How we protect your data

Teaching holds names and phone numbers of students and parents, lessons and payments. This page says what we do to protect them, without promises we cannot check. Every sentence here rests on an automatic test or on the code, and what we have not done yet is written plainly.

Each teacher sees only their own data

  • Every teacher's and every school's data sits in one database, but the separation is enforced by the database itself: row level security is switched on and forced on every table that holds customer data, so a query made for one teacher cannot return a row of another.
  • The teacher's identity is taken only from the verified sign-in on the server. A value the browser sends about who it is, is never read.
  • An automatic check blocks any change that adds a data table without this protection, and other tests actually try to read one teacher's data as another teacher and expect to find nothing.
  • The public portal reads only a view of published profiles. A teacher's exact address, phone and email are not in it; they are shown only after the visitor passes a controlled reveal step.

Sign-in and access

  • Passwords are stored only as a salted argon2id hash, never as text. Failed sign-in attempts are slowed down per address and per account.
  • The access token is valid for 15 minutes. Staying signed in lasts up to 30 days and ends on sign-out or a password reset.
  • School teachers sign in with a single-use personal link, and the students of a private teacher with a personal link that the teacher can revoke. In both cases only a hash of the link is stored. A school teacher's session lasts 12 hours.
  • Signing in with Google is optional, and your Google password never reaches us.
  • The owner's sign-in to the management dashboard is a separate system with its own protection, and every attempt is logged for 90 days.

What data we hold, and for how long

  • A private teacher enters names and contact details of students and parents, lessons and payments. That data is the teacher's: we process it on her behalf.
  • Teaching School is built around teachers, classes and a timetable. It has no student fields or records, and an automatic test checks that no table of the school area has a column for a student.
  • Portal searches are kept for 90 days, and conversations with the support assistant for 90 days.
  • When an account is deleted it is locked at once, and the personal and business data are erased for good after 30 days. Billing records stay without personal details, as the law requires.
  • A teacher can export her data to a file at any time.

Payments

  • Teaching does not store full card numbers. A card payment is made on the payment provider's page (iCount); we keep only the amount, the status and the invoice number.
  • A student's payment to a teacher (Bit, PayBox, cash) does not pass through us. Teaching records what the teacher marks as paid and moves no money.
  • The keys that connect us to providers (payments, mail, AI) are stored encrypted and shown masked, and none is written into the code or the logs.

Hosting, encryption and infrastructure

  • Traffic to the site is encrypted (HTTPS), and security headers are on: a content security policy (CSP) and a ban on embedding the pages in frames.
  • The system runs in the Amazon cloud in the Israel (Tel Aviv) region.
  • Integration keys are encrypted with AES-256-GCM, and the key that encrypts them is kept apart from the database.
  • Database roles are limited: the application connects with a role that has no superuser power and does not own the tables, and the public portal uses a separate role that can only write searches and read one view.

AI features

  • The support assistant and the reading of school constraints use external AI providers, named in the privacy policy. The text is sent to the provider for processing and may be processed outside Israel.
  • The support assistant can see only the product guide and the figures of the teacher who asks. In our automated tests it does not reveal another teacher's data, even when it is pushed to.
  • A constraint that the AI read from a school's text waits for the school's approval. No constraint enters the calculation until a person approves it.

Monitoring and incidents

  • Errors are collected automatically and grouped by fingerprint, and a critical incident alerts the owner at once.
  • The status page shows the state of the system now and for the last 90 days. It is computed from live system data and is not edited by hand.
  • An incident that hurt the service appears on the status page with its start and end time.

What we do not claim

  • We hold no formal information security certificate (such as ISO 27001 or SOC 2), and we show no badge that suggests otherwise.
  • Registration as an approved vendor in the Ministry of Education's Gefen is in progress and not complete. Until it is, schools join directly.
  • No system is immune. When something goes wrong we record it, fix it, and list on the status page every incident that hurt the service.

Found a security problem?

  • If you found a weakness, write to us before you publish it. A person reads every report.
  • Until the reporting address is published here, write to us through the support chat in the corner of this page.