Privacy policy — YeshivaSync

1.The short version

YeshivaSync is used by yeshivos to keep their own records. Most of the information in it is about students, and those students are minors — roughly ages 14 to 19.

The school decides what is recorded and who at the school can see it. The information belongs to the school.
We hold and process that information so the school can use the service. We do not sell it, we do not advertise, and we do not use it to train any kind of model.
The service deliberately holds date of birth and medical information, because schools need them to look after a boy. Section 4 is about that.
A parent sees their own children, and nobody else's.
One school never sees another school's students.
A small number of other companies hold the data as part of running the service. They are all listed by name in section 12.
Nothing is deleted on a timer. Records are kept until somebody deletes them or asks us to.
Archiving a student is not the same as deleting them. Deletion is a separate action. Both are explained in section 14, honestly.

This policy describes what the software actually does. Where the behaviour is imperfect or surprising, it says so rather than glossing over it. If you are a menahel deciding whether to trust this, section 16 on security and section 14 on deletion are the two to read.

2.Who we are, and the school's role

The service is operated by YeshivaSuite LLC, a New York limited liability company whose registered office is 418 Broadway, Ste N, Albany, NY 12207. You can reach us at privacy@yeshivasuite.com.

The school is the party that has a relationship with the family. The school decides what to record about a student, why, who may see it, and how long to keep it. We provide the software and hold the data on the school's instructions.

This means that if a parent wants to see, correct, or remove information about their child, the first place to ask is the school. We will help the school do it, but we do not make those decisions over the school's head. If a parent asks us directly, we will pass the request to their school and tell the parent we have done so.

The exact legal characterisation of the school's role and ours — controller and processor, or school and school official, or something else — is left to be settled by a lawyer. Section 19 explains the rules schools ask us about and what we commit to under each, without claiming compliance with any of them.

3.What the service holds about a student

This is the full list, as it exists in the database today. Not every school uses every part of it — a field is only filled in if someone at the school, or a parent, puts something there.

Names and identity: Full name, first and last name, the nickname the yeshiva actually uses, and Hebrew name. The mother's name, which is recorded for the office and is not shown in the app. An identifier carried over from a school's previous system, kept so records can be matched on re-import.
Date of birth: Both the civil date of birth and the Hebrew date of birth. See section 4.
Photograph: A photo of the student, which either the school or a parent can upload. It is stored inside the database itself, and it is served only to staff of that student's school and to members of his own family. It is not shown on the parent report links described in section 10.
Placement and enrolment: Which class or chaburah he is in, which learning groups he belongs to, enrolment and start dates, his status (active, withdrawn, graduated), and a record of enrolment periods including a free-text reason if an enrolment ended.
Attendance: For each seder on each day: present, late, absent, or excused; how many minutes late; how many minutes he left early; whether the absence or early leave was excused; a free-text note; and which staff member recorded it and when.
Tests and marks: Test and quiz titles, dates, scores and maximum scores, whether a test was excused or left ungraded, a free-text note, and which staff member recorded it.
Rubric scores: Scores against the school's own rubric, across learning, avodah, and middos — that is, including judgements about conduct and character. Each score can carry a free-text note, and records who scored it.
Written assessments from staff: Narrative write-ups about the student for a period, written by a rebbi or mashpia. These are held as a draft until someone publishes them, and only published ones are visible to a parent. They record the author and who published them.
Follow-ups and fines: Disciplinary follow-ups: what kind (for example a call over, a knas, a writing assignment), a money amount where a fine was given, the date and incident it relates to, due dates, a free-text note, a free-text note on how it was resolved, and which staff member gave it and which marked it done.
Leave and excuses: Records of the student being away, coming late, or leaving early: dates and times, which sedarim are affected, a reason chosen from a short list that includes medical, and a free-text note.
Subject exemptions: That the student does not take a particular subject, with a free-text reason.
Health information: A medical information field on the student's profile, for allergies, conditions, medications, and dietary needs. Usually filled in by a parent through the parent portal. See section 4.
Previous schools: A list of schools attended before, each of which can carry a free-text note. Usually supplied by a parent.
Notes from the parent: A free-text field where a parent can write about their own child, which the school can read.
Admissions applications: Applications to a school: the parent's covering message, the parent's answers to questions the school wrote itself, the school's own private review notes about the application, and the application fee amount and whether it was paid or waived. No fee is taken through the service; it only records what the school marked.
Reports that were sent: A saved copy of each report sent to a parent: the date range, what the report showed, any note written by the menahel, which parent it went to, whether it was delivered, and the secret link it was sent with.

Free-text notes deserve their own warning. Several parts of the service let staff write freely about a student. Those notes are records: they are stored, they can be read by other staff who have access to that student, some of them are shown to parents once published, and they are not automatically removed. There is a second reason to be careful, beyond the obvious one. A note or a rubric comment that reads as a diagnosis — naming a condition, a medication, or a suspected one — turns an ordinary note into health information, with everything that follows from that. Staff should describe what a boy did, not what they think is wrong with him. Schools should tell their staff so.

4.Date of birth and health information

These two are singled out because they are the most sensitive things in the database, and because they are here on purpose rather than by accident.

Date of birth is collected because a yeshiva needs it — for age-based placement, for a bar mitzvah date, for the office, and because it is on every roster a school imports. Both the civil and the Hebrew date are held.

Health information is collected because a school that has a boy in its care needs to know about his allergies, his conditions, his medications and his dietary needs. A school without that information is a school that cannot look after him properly. So the field exists, and parents are asked to fill it in.

Neither is a side note. A school's own record of a boy's health is treated, in the guidance schools are given, as part of his education record like any other — not as something separate with its own looser rules. Date of birth is treated as information that identifies him. So both are handled here as core student records, not as extras.

Being deliberate about it means being careful with it. What that means concretely:

Health information is part of the student profile, and only staff who can open that student's profile can read it. At most schools that is the hanhala.
It is never included in a parent progress report, and it is never in one of the report links described in section 10.
It is not included in any automatic email the service sends.
It is never shown on our operator screens, and it does not appear in any cross-school view.
It travels only where a parent sends it. When a parent applies to another yeshiva through the portal, the child's profile goes with the application and the medical field is part of it, so the receiving school's hanhala can read it. That is the parent's own act, and the apply screen says so before he submits. Nothing moves between schools unless a parent applies.
It is not used for anything except showing it to his own school. Not for statistics, not for research, not for any aggregate figure.
When a student is deleted, it is deleted — including the copies of it in the parent-edit log. Section 14 explains that.

Two limits, stated rather than hidden. Health information sits in the database as ordinary readable text like everything else: we do not add a separate encryption layer of our own on top of the database, so anyone with database access could read it, which is why the operator list is kept short. And a school can choose to give more of its staff access to student profiles than it should — that is the school's setting, not ours.

5.What the service holds about parents and families

Contact details: Name, Hebrew name, relationship to the student (father, mother, guardian, other), email address, and phone number. Both the school and the parent can hold their own version of these.
Address: Home address, city, region, postal code, and country. Addresses are stored per contact as well as per household, so that separated households can each have their own.
Preferences: Preferred language and preferred way of being contacted.
Household notes: A free-text note field on the household record.
Details of another parent: A parent can enter the name, email and phone of the other parent before that person has an account. That means the service can hold data about somebody who has not signed up and has not been asked. If you are that person and you would rather not be in here, write to privacy@yeshivasuite.com and we will take it to the school.
Requests they make: Leave and excuse requests submitted through the portal, the reason and note given, and the school's written reply — including a reply explaining a refusal.
A record of their edits: Every change a parent makes to their family's or their child's details is logged. The log keeps the field that changed, the value before, and the value after. Because the child's medical information, address, name, birthday, previous schools and parent notes are all editable from the portal, the log can contain the previous text of those fields. Section 13 explains this log, and section 14 explains when it is deleted.

6.What the service holds about staff

Name, Hebrew name, the display name used at that school, email address, and phone number.
Roles at the school, whether the membership is invited, active or suspended, and per-class and per-subject access assignments, including a date window for a substitute and a free-text note on the assignment.
Authorship. Every attendance mark, test score, rubric score, note, follow-up and leave record keeps a link to the staff member who entered it.
Internal messages, announcements and tasks, including their free text, who read them and when, and who acknowledged an announcement.
A count of reminders sent to a staff member about blocks they have not marked, and a record where a block was never marked at all.
If they turn on notifications, a per-device push identifier and their browser's user-agent string.
Their own app preferences.
A record of when they opened or changed an individual student's record. See section 13.
The email address on a staff invitation. Invitation records are kept after the invitation has been used or revoked, so an old invitation still holds the email address it was sent to.

There is also a separate public form for a yeshiva to ask about using the service. It collects the applicant's name, Hebrew name, email, phone, their role at the yeshiva, city and country, and anything they write in the notes box, plus our own notes when we review it. That form does not require an account.

7.Why we hold it

To provide the service the school signed up for — recording attendance and marks, producing reports, and sending the notices the school asks for.
To let the right people sign in, and to keep them out of records they should not see.
To send the automatic emails and notifications described in section 11.
To keep a record of who looked at or changed a student's record, so a question about it can be answered later.
To keep the service working — finding and fixing faults, and supporting the school when it asks.
To bill the school, and to keep the records of what it was billed.
To meet a legal obligation, or to deal with a legal claim, if one ever arises.

That is the whole list. If we ever want to use school or student data for something not on it, we will ask the school first.

The legal basis for each of these purposes — consent, contract, legitimate interests, a school's own legal duty, or whatever the applicable framework calls it — is left for a lawyer to set out, together with the school's own notices to families.

8.What we never do with it

These are promises in our own voice. We make them because they are right, not because we have worked out which law requires them of a service this size. They hold either way, and they are written into the terms of service as well, where we also promise not to weaken them without a school's agreement.

We do not sell student, family, or staff data. Not for money, not for anything else of value, and not in any form, including anonymised or aggregated.
We do not use student data for advertising of any kind, and we do not target advertising at a student or a family. There is no advertising anywhere in the service.
We do not build a profile of a student for any purpose other than showing his own school its own records. No cross-school profile, no scoring, no research dataset, no dataset for sale.
We do not use school or student data to train machine learning models, and no student record is sent to an artificial intelligence service by the software's own operation. There are two places where a member of staff can deliberately send text out. The in-app Help assistant passes the question a staff member types to Anthropic so it can compose an answer from our own manual, and a question can name a boy; nothing is kept — there is no chat log — and a person who would rather not send anything simply does not use it. And the microphone button, where a browser offers one, uses that browser's own dictation, which in Chrome means the spoken words go to Google; we neither store nor transmit them ourselves.
We do not use the data for our own product analytics. There is no analytics or tracking service in the software.
We do not disclose the data to anyone outside the companies listed in section 12, except where a law compels us — and then we will tell the school first unless we are legally forbidden to.
We do not use one school's data for another school's benefit.
We do not withhold a school's data to force a payment, and we do not delete it for non-payment.

9.Who can see what

Access is decided by the school, and enforced by the software. In practice:

A school's own staff: Every staff member signs in with their own account, and is attached to one or more schools. A staff member only ever sees the school they are signed in to. A membership that has been suspended grants nothing, even if the person is still logged in.
Hanhala: A hanhala account sees the whole school — every student, class, subject, mark, note, follow-up and contact detail, including medical information. It is the only role that can edit student profiles, manage parent contacts, invite staff, set other people's access, delete a student, and cut off a report link.
Other staff: Everyone else sees only what they have been assigned. Assignments are per subject and per class or group, at one of three levels: manager (can record), viewer (can read in reports), or hidden (explicitly no access). A substitute's assignment can be given a start and end date, and stops working outside it. Assigning a teacher to a class also gives them read access to that class's other subjects, so they can see the whole picture for their own boys.
Rubric access by role: The rubric is split by role: a maggid shiur scores the learning side, a mashpia scores avodah and middos, and a mashgiach and the office see no rubric data at all.
Parents: A parent signs in to a separate portal and sees only children linked to their own family. Every page re-checks that the child belongs to the parent's family before showing anything. A parent sees their child's attendance summary, test averages, rubric scores, published staff write-ups, profile details, application history, and their own leave requests. A parent does not see other families, other students, staff messages, follow-ups and fines, or a school's private review notes.
Us, as the operator: A small number of operator accounts can see across all schools. This is a named list held in the database, it can be withdrawn, and it is used to run and support the service. From the operator screens, an operator can see each school's staff list with names and email addresses, its class and subject lists, its student roster with names and class placement, and school- and class-level attendance percentages. Those screens do not show an individual student's daily attendance, marks, rubric scores, notes, or medical information. An operator with database access, however, can technically reach anything in the database — that is true of any hosted service, and it is why the operator list is kept short. A school can ask us at any time who is on it.
One school and another: A school cannot see another school's students. Separation is enforced by the application, which attaches the school to every query.

One school never sees another school's records. Every screen in the service is scoped to the school you are signed in to, and we test and review that separation as part of how we build.

10.Report links sent to parents

When a school sends a parent a progress report, the email contains a link that opens the report without signing in, and usually a PDF copy attached. It works like a private document link. This matters, so here is exactly how it behaves:

The link contains a long random code, generated with a cryptographic random number generator. It is not guessable.
Each link covers one student, over one date range, and shows only what was in the report when it was sent.
Anyone who has the link can open it. The page does not check who is looking. So if the email is forwarded, the person it is forwarded to can read the report.
A progress-report link stops working 90 days after the report was generated. A report-card link lasts 400 days, because a report card is a document a family keeps for the year. Both cut-offs are applied by the software every time the link is opened, and a hanhala can cut either off at once.
The school's hanhala can cut a link off immediately, which takes effect at once.
The pages are marked so that search engines do not index them.
The student's photo is never shown on these pages, and neither is his medical information.
The link is the only thing needed to open the report, which is why it is long and random, and why a school can cut it off.
Opening one of these links is not recorded in any log. We cannot tell a school whether a report was read, or how many times, or by whom.

A school that is not comfortable with a link that opens without a sign-in should send reports as PDF attachments only, or print them. The link is a convenience for parents, not a requirement.

11.Email and notifications we send

The service sends email, and it contains personal information. These are all of them:

To parents: A progress report, with the student's name and a link and PDF as described above. A decision on a leave request, with the student's name and dates. A welcome when their child is accepted, with the student's name and class. An acknowledgement if they applied through the portal.
To staff: A notice when a student will be away, late, or leaving early, naming the students and the sedarim affected. A notice that a seder or day was cancelled, which does not name students. A welcome email when their account is created. A weekly summary to the hanhala, which includes school attendance figures and a named list of the students most needing follow-up. A reminder to the hanhala that parent reports are ready to review.
To us: A notice when a yeshiva submits the public enquiry form, containing that person's name, email, phone and what they wrote.
Push notifications: If a staff member turns them on, the service can send notifications to their device — a reminder that a block has not been marked, or that a follow-up is due. A follow-up reminder can include a student's name. The content is encrypted so that the company relaying it cannot read it.

Four of these run automatically on a schedule: the weekly hanhala summary, a daily check for unmarked blocks, a daily follow-up reminder, and a daily check for parent reports to review. None of this email is marketing, and no medical information is ever in any of it. Email delivery depends on the receiving mail provider, and we cannot promise a message will arrive.

12.The other companies involved

We do not run our own servers. These companies hold or handle personal information in order for the service to work. This list is complete as far as the code shows:

Clerk — accounts and signing in: Holds the login details of every staff member and parent: email address, name, password credential and sessions. Because its code runs on every page, it also sees the network address and browser of visitors. It sends its own account emails, such as password resets. It holds no student data.
Supabase — the database: Holds the entire dataset described in this policy, including student photographs, medical information and all free-text notes, and takes the backups.
Vercel — hosting and running the software: Runs the application, so all data passes through it in the course of being displayed or saved. It also holds the server logs and runs the scheduled jobs that send the automatic emails.
Resend — sending email: Receives the recipient's address and the full content of every email described in section 11, including student names and the PDF progress reports attached to parent emails.
Device notification services: If a staff member turns on notifications, the notification is relayed by whichever service belongs to their browser or device — for example Google for Chrome and Android, Mozilla for Firefox, or Apple. They receive a device identifier and the encrypted message, which they cannot read.
Cloudflare — bot protection on the public enquiry form: Only on the public form a yeshiva uses to enquire. It receives the visitor's network address and browser signals to check they are not a bot. It receives no student or parent data. It is only active when we have configured it.
Anthropic — the in-app Help assistant: Receives the text of a question a member of staff types into Help, so it can compose an answer out of our own manual. A question can name a boy, because that is how a person asks about one. It receives nothing else — no record, no roster, no attendance — and nothing is stored: there is no chat log. It is only reached when somebody uses Help.
Sentry — fault reporting: If we have switched it on, receives error messages and technical details when something breaks. It is configured not to attach request contents, cookies, headers, or network addresses. An error message could still happen to contain data, which is why it is listed.

Two things we can state plainly. Student progress reports are turned into PDFs by our own software on our own servers — no outside document service is involved. Spreadsheet imports of a roster are read in the school's own browser and by our own code — the file is not sent to any third party.

There is no analytics, tracking, or advertising service in the software, and no payment processor. When paid card payment is switched on, a payment processor will be added to this list, and it will receive the school's billing details but no student data.

Each of these companies publishes its own data processing terms for business customers, which limit it to handling data on our instructions and forbid it using the data for its own purposes. We rely on those published terms. We have not negotiated bespoke terms with any of them. A school that wants to read them should ask and we will point to each one.

If we add a company to this list in a way that affects a school's data, we will tell the school's administrators at least 30 days beforehand and update this page. A school that objects can cancel and take a full copy of its data. We stay responsible to the school for what these companies do with the school's data.

13.The logs the service keeps

There are three, and they behave differently.

The access and change log: Records that a staff member opened a particular student's record, or created, changed or deleted something, and when. For most changes it keeps the name of the field that changed rather than its contents; for some — a leave reason, a mark, a status — it also keeps the new value. It holds no names, addresses, medical text or free-form notes. A hanhala account can read its own school's log under Settings, including entries for staff who only looked. ⚠️ It is a strong record of what happened rather than complete proof of it: opening a boy's record is logged, and dashboards, lists, parent-portal views and report-link views are not.
The parent-edit log: Records changes a parent makes to their family and their children, and unlike the log above it keeps the value before and the value after. So the previous text of a child's medical information, address, name or birthday can remain in this log after the current value has changed. Its purpose is to let a school see what a parent altered. It is cleared for a particular child when that child is deleted, but nothing else in the software removes from it.
The record that the school agreed: When somebody applies on behalf of a yeshiva, they tick two boxes — one for these documents, one for the subscription renewing on its own. We keep a row saying who ticked them, their email, which version of the documents they were shown, the date and time, and the network address and browser the tick came from. It is the only place in the service that keeps a network address next to a named person, and it is there for one reason: an agreement nobody can show was made is not an agreement. Nothing in the software edits or deletes one of these rows. We keep them for as long as we might need to show what was agreed, which outlasts the subscription itself.

Beyond those three, our hosting provider keeps ordinary server logs of requests, which it holds for its own period and which we do not control.

14.How long it is kept, and what deletion actually does

This is the section most often written vaguely. Here is what the software really does.

Records are kept indefinitely. There is no automatic expiry: nothing ages out, no scheduled job trims old records, and no retention period runs in the background. Data stays until a person deletes it, or until the school asks us to. That is a deliberate choice, because a school wants a boy's record years after he leaves. It also means a school that wants a retention rule has to ask for one.

Archiving a student is not deleting them: Archiving is the normal way a school takes a boy off its active lists, and it is what happens when he leaves or graduates. It marks the record as archived and changes his status. Nothing else is removed: his whole history of attendance, marks, rubric scores, notes, follow-ups and leave stays in the database, his medical information stays, his photo stays and is still served, and he remains visible and readable on the school's archived and former-student screens, with no time limit. Archiving can be undone.
Deleting a student: Deletion is a separate, deliberate action. Only a hanhala account can do it, and if the boy has any recorded history the person deleting has to type his name to confirm. It permanently removes the student record and, with it, his parent contact records, his photo, his medical information, all his attendance, all his test scores, all his rubric scores, staff write-ups about him, follow-ups and fines, leave records and leave requests, group memberships, subject exemptions, enrolment records, applications and their answers, the saved copies of every report ever sent about him together with their access links, and his entries in the parent-edit log including the previous values of anything a parent edited. It is done in one database transaction, so it either all happens or none of it does. It cannot be undone.
What survives deleting a student: One thing. The access and change log keeps its entries, plus a new entry recording that this student was deleted, by whom, and when. Those entries hold his record number, the staff member who acted, and the names of fields, not his name and not any values. That is the trail of who destroyed the record, which is the one thing that has to outlive it. Everything the trail refers to is gone.
Removing a staff member: Removing a staff member deletes their membership of the school and their access assignments. If they have no other school, are not a parent, and are not an operator, their login and account are deleted too. Their work stays: the marks, notes, messages and write-ups they wrote remain, and remain attached to their name unless their account itself was deleted, in which case the authorship becomes anonymous. The email address on an old staff invitation is not cleaned up, and stays until the school itself is deleted.
Closing a parent account: A parent can close their own account. That deletes their login and their personal account record. It does not delete their children's records, the household record with its address and notes, the contact details the school entered, or their entries in the parent-edit log. If they were the only adult on the household, the household stays without anyone able to sign in to it. A parent who wants their child's record removed has to ask the school, because it is the school's record.
A school leaving: A school's account is archived rather than deleted, which keeps everything and simply removes it from our operator dashboard and cuts off its staff. Deleting a school's data outright is something we do on request, within 30 days, by running database commands by hand, and we confirm in writing when it is done. One thing survives it, for the same reason the change log survives deleting a student: the row recording that the school agreed to these documents stays, with the name, email, version, time and network address of the person who agreed. It holds nothing about any student, and it is the evidence of the agreement itself — which has to outlive the agreement to be worth anything.
Backups: The database provider keeps backups. So a deleted record can still exist in a backup for a period after deletion. We have not set a backup retention window of our own and we cannot promise a particular one, which means we cannot honestly promise that a deletion has reached every backup on the day we confirm it.
Email already sent: We cannot recall an email that has already been delivered, and deleting a record does not remove a report that is already sitting in somebody's inbox. What we can do is cut off the report link, which stops the online copy opening.

Because there is no automatic retention limit, how long a school's records are kept is effectively the school's decision. A school that wants a retention rule — for example, deleting a former student's full record a set number of years after he leaves — should tell us, and should ask us to confirm each time it has been carried out. We will do it by hand and confirm in writing. There is nothing in the software that will do it on its own, and we would rather say that than let a school assume otherwise.

15.How to ask for a copy, a correction, or a deletion

A parent should ask their school first. The school holds the relationship, controls the records, and can make most changes itself through the portal and the app.

A school can write to us at privacy@yeshivasuite.com to ask us to:

Send a complete copy of the school's data, in a spreadsheet or database format, at no charge. This is the export commitment in the terms of service, and it applies whether the school is staying or leaving.
Send a copy of one student's record, for a family that has asked the school for it.
Correct something we hold that the school cannot correct itself.
Delete a particular student's record, or the school's data as a whole.
Confirm what remains after a deletion, including in the logs described in section 13.
Tell the school who currently has operator access, or remove an operator's access.

We will acknowledge a request within five business days and complete it within 30 days. If something will take longer, we will say so and why, before the 30 days are up. We may need to check that the request really comes from the school before acting on it, because a request to delete records is not something to take on trust from an email address.

If a parent writes to us directly, we will pass the request to their school and tell the parent we have done so. We will not hand over a child's records to somebody we cannot confirm is their parent. As a rule we do not delete a school's record because a parent asked us to, because it is the school's record and the school may have its own reasons to keep it — the right place for that conversation is with the school. If a law where the family lives gives that parent a direct right to have information deleted by us, we will honour it and tell the school we have.

What rights a parent or a student has to demand access, correction, or erasure depends on where the school and the family are, and is left for a lawyer to state. This section describes what we will do in practice, not the extent of anybody's legal rights.

16.Security — what we actually do

These are the protections that exist in the software today. We have deliberately not listed anything we cannot point to in the code.

Everyone signs in through a specialist accounts provider. We never see or store a password.
The staff app, the operator screens and the print pages are behind a sign-in check that runs before any page is built. The parent portal checks for a signed-in user before it renders.
Every query is tied to one school, so a staff member's session cannot reach another school's records.
A suspended membership grants no access, even while the person's session is still valid.
Access below hanhala level is limited to assigned classes and subjects, with an explicit setting for no access, and an optional date window that expires on its own.
Before a record is written, the software checks that the student, class or subject being written to belongs to the school making the request, so that passing in somebody else's record number does not work.
Whether one particular staff member may open one particular student's report is checked on the report page, on the print page and in the underlying data call.
Student photographs are served from a route that checks the requester is either staff of that student's school or a member of his family, and refuses everyone else.
Opening or changing an individual student's record is logged, usually with the field's name and sometimes with the changed value.
Report links are long and random, and a school can cut one off at once. A progress-report link expires after 90 days and a report-card link after 400.
Deleting a student runs in a single database transaction that also writes the record of the deletion, so a record can never be destroyed without the trail of who destroyed it.
The scheduled jobs that send email require a secret, and refuse to run in production if it is not configured.
The operator screens can be restricted to their own separate web address, and are hidden entirely on the school-facing one.
Traffic to the service is encrypted in transit, by the hosting provider.
The access rules and the separation between schools are tested and reviewed as part of how we build. Those are our own checks, not an outside auditor's.

And four things we would rather say plainly than leave a school to assume:

We rely on our hosting and database providers for the security of the servers, the network and the data they store, and on the protections they publish for their business customers.
We hold no security certification, we are not audited by anyone, and we have not had an outside penetration test.
The service is not monitored around the clock, and we do not promise a time within which a security problem will be noticed, contained, or fixed.
No system is perfectly secure, and we cannot promise that a breach will never happen.

That second list is unusual to publish. It is here because a menahel deciding whether to put his boys' records into somebody's software deserves to know what he is actually getting, and because a school that needs more than this should find out before it signs, not after.

17.If information is exposed

If we become aware that personal information held for a school has been exposed, this is what happens:

We tell the affected school without unreasonable delay, and in any case within 72 hours of confirming the exposure. The clock runs from confirming it, not from first suspecting something.
That first message may be short. We would rather tell the school inside 72 hours what we actually know than wait until we know everything.
We tell the school what happened, when, what information was affected as far as we then know, what we have done to stop it, and what we recommend the school do.
We keep the school updated as we learn more, including if the picture turns out to be worse than the first message said.
We do not tell a third party about an incident affecting a school's data before we have told that school, unless a law requires it.
We help the school work out what it has to tell families and any authority, and we give it the details it needs, promptly and at no charge.

Notifying families is the school's decision, because the school is the one with the relationship to the family. Whether a notification is legally required, and by when, depends on the state each affected family lives in, and those rules genuinely differ from one state to the next — some are counted in days. That is the school's question to answer with its own advisers. We do not promise a deadline for a notification we are not the one giving; we promise to get the school the facts in time to meet its own.

The 72-hour figure is a deliberate choice and it is the one commitment in this policy that is purely operational: it depends on a person reading his email. It is written to run from confirming an exposure, and to allow an incomplete first message, precisely so that it is a promise that can be kept rather than one that sounds good. It is not the shortest number available, and it is not meant to be.

18.Children, and students under 13

Most of the information in the service is about minors. We want to be plain about how that works.

Every record about a student is entered by the school or by his own parent — a boy cannot enter, change or delete anything about himself. Where his school has switched on the optional student portal, a boy can sign in to read his own attendance and marks. What we hold from him is an email address he confirms, a sign-in code he chooses, and when he signed in. The portal is off unless a school turns it on, and a school can withdraw a boy's access at any time.
The school is the party with the relationship to the family, and the school is responsible for having whatever permission or notice its own rules and local law require before recording information about a boy.
The information includes a date of birth, a photograph, health information, judgements about conduct and character, and free-text notes written by staff. A school should assume a parent may one day read all of it.
We do not advertise to anyone, we do not build profiles for any purpose beyond showing the school its own records, and we do not sell or share this information for anybody else's marketing.

On age specifically: the service is built for a mesivta and a beis medrash, so students are usually 14 to 19. We do not knowingly hold records about a child under 13, and nothing in the service is directed at a child of any age.

If a school does enrol a boy under 13, his record is entered by the school or by his own parent exactly like anybody else's, and we treat it identically — no advertising, no profiling, no selling, and deletion on request. But tell us if that happens. A service that holds records about children under 13 is looked at differently, and we would rather know than find out later.

19.The rules people ask us about

Schools ask whether the service is compliant with one law or another. We are not going to answer that with a yes, because a vendor's own claim to be compliant is worth little to a school on its own — and is worse than nothing if it later turns out to be wrong. What we can do is explain each rule honestly and say what we commit to. That is what this section is.

FERPA: The federal student-records law applies to schools that receive funding under a US Department of Education programme. The Department itself says that private and faith-based elementary and secondary schools generally do not receive such funding and so are generally not subject to it. Many yeshivas are in that position — but it is your school's question with its own advisers, not ours, and it is not always obvious: the funding test reaches sub-grants and sub-contracts as well as direct grants, and if any part of an institution receives covered funding the whole institution is covered. Plenty of private schools also choose to hold themselves to the standard regardless. So we do not ask which answer applies to you. What we commit to is the same either way, and it is the shape of what the law expects of an outside party a school brings inside its own walls: we perform a service the school would otherwise do with its own staff; we act under the school's direction as to how student records are used and kept; we use them only to provide the service to that school; we do not pass them on to anyone except the companies in section 12 that we need to run the service; and we return or destroy them at the school's direction. Two things only the school can do: name outside service providers as "school officials" with a legitimate educational interest in its own annual notice to families, and answer a parent's request to inspect the records. We will help with the second and remind you about the first, but neither is ours to do.
State student-privacy laws: This is the family of rules that actually points at a company like us rather than at the school. California's pupil online privacy law, and a couple of dozen state laws modelled on it, forbid an education technology company from targeting advertising at students, selling student information, or building profiles of students for anything other than school purposes, and several of them require us to delete a student's information when the school asks. Whether a particular one reaches a private yeshiva's vendor differs from state to state: some are written so that they only bite through a contract with a public school district, while at least one says in as many words that it covers private and non-public schools. We have not tried to work out which of them applies to us, because the answer would not change anything we do. Section 8 makes those promises directly, in every state, whether or not a statute requires them of us, and the terms of service says we will not weaken them without a school's agreement. Our deletion window is 30 days, which is shorter than any of these laws requires.
COPPA: The federal children's online privacy law is about information collected online from children under 13. Our students are roughly 14 to 19. Where a school switches on the optional student portal described in section 18, the only things we collect from a boy himself are an email address he confirms, a sign-in code he chooses, and when he signed in. He can enter no record about himself. A school planning to enrol a boy under 13 should tell us first, because a portal login for a younger child is a different question.
State privacy laws generally: The newer state privacy laws — California's and the others that have followed — mostly apply above revenue or data-volume thresholds far above a service this size. Several of them also set aside information that education-privacy rules already cover, but we do not lean on that: if a school is not itself covered by the federal student-records law, its records are probably not covered by that carve-out either. We are not claiming any exemption and nobody has confirmed one for us. We also know that a handful of states are moving to rules that turn on holding health information rather than on how big a company is, which would reach a service this size, and the medical field in section 4 is exactly what those rules are about. So our position is the simple one: the things those laws are aimed at are the things in section 8 that we already promise not to do, and we would rather be able to say that plainly than argue about whether we are in scope.
Health privacy rules: The federal health privacy law applies to healthcare providers, health plans, and the companies working for them. We are none of those, and neither, ordinarily, is a school keeping its own record of a boy's allergies so that it can feed him safely. So that law does not normally apply to what is in section 4, and we do not sign business associate agreements, because signing one would be claiming a role we do not have. If a school thinks it is a covered health provider, say so before signing up, because that is a different conversation. None of this makes the information less sensitive; section 4 sets out how we treat it.
Breach notification: There is no single federal rule. Every state has its own, and which one applies depends on where each affected family lives, not on where we are. Practically, the vendor's job is to tell the school fast and completely enough that the school can meet whatever rule applies to it. That is what section 17 commits us to.

Nothing in this section is a claim of compliance, a legal opinion, or advice. It is written so that a menahel or a board can see that we know what they are going to be asked and are not bluffing about it. A school that needs a formal answer should get one from its own lawyer, and we will answer that lawyer's questions in writing.

20.Where the service runs

The service is operated from the United States, and the companies in section 12 store and process the data in the United States. If your school or a family is outside the United States, their information is still stored and processed in the United States, and it is subject to United States law including lawful requests from United States authorities.

The service was built for American yeshivas and we have not put arrangements in place for transfers out of any other country's data-protection regime. If a school outside the United States wants to use it, say so before signing up, so that gets looked at properly rather than assumed.

21.Accessibility

The service is built with ordinary web pages and standard form controls, so it works with a keyboard, with browser zoom, and with the text size a person has set on their phone. Colour is not the only way anything is communicated, and marking screens are designed to be usable on a phone in a beis medrash.

The standard people ask about is WCAG 2.1 Level AA. We aim at it. We have not tested against it, we have had no outside audit, and we are not going to tell a school we conform to something we have not measured.

If a member of staff or a parent cannot use part of the service, write to privacy@yeshivasuite.com and describe what happens. We will fix it, and in the meantime we will get the information to them another way.

22.Changes to this policy, and how to reach us

We may update this policy. If a change materially affects what we do with personal information, we will tell the schools using the service by email to their administrators at least 30 days beforehand, and update the date at the top of this page. Corrections and clarifications we make by updating the page.

We will not make a change that weakens the promises in section 8 without the school's agreement.

Questions about anything here, or about what we hold, go to privacy@yeshivasuite.com. A real person reads it.