School data addendum — YeshivaSync

1.What this is for

This addendum is part of the terms of service. It is written to be read on its own by a board or a vaad that wants to know what happens to its boys' records, without reading the whole privacy policy first.

Where this addendum and the terms of service disagree about handling school data, this addendum governs. Where a board wants more detail than is here, the privacy policy has it, field by field.

YeshivaSync is operated by YeshivaSuite LLC, a New York limited liability company, so the school is contracting with a company rather than with an individual. Where a commitment below is written as "we will do this by hand" rather than as an automated guarantee, that is deliberate and it means what it says.

2.Who owns the data

The school does. The records the school and its staff and parents put into the service belong to the school, not to us.

We hold and process them on the school's behalf, only in order to provide the service. The school decides what is recorded, who at the school may see it, what is sent to parents, and how long it is kept. We claim no ownership and no licence to it beyond what running the service requires.

3.The mechanics of that arrangement, stated plainly

Several state privacy laws require a written agreement between a school and a supplier that handles its records, and require that agreement to say certain things on its face. This section says them, so that a school can point at it rather than ask us for a separate document.

Who is who: The school decides the purposes and means of the processing. We act only on the school's instructions. In the language those laws use, the school is the controller and we are the processor. If we ever wanted to use a school's records for a purpose of our own, that would make us a controller for that purpose, and we would have to ask first — which is why the commitment never to sell data, including anonymised or aggregated data, matters more than it looks.
Subject matter and purpose: The processing is of student, staff and parent records, for the sole purpose of providing the service the school has subscribed to: attendance, marks, the skill rubric, reports, and the parent portal.
How long: For as long as the school's subscription runs, and then for the window described under "What happens when the school leaves". Nothing about a student, parent or staff member is kept beyond that except where the school has asked us to keep it. Two things that are not about them do outlive it: the entries in our change log, which hold record numbers and mostly field names rather than values, and the row recording that somebody agreed to these documents on the school's behalf. Both are evidence about us, not data about a boy.
What is processed, and about whom: The categories are listed under "What is held about a student". The people are the school's students, their parents or guardians, and its staff.
The school can have us checked: A school may appoint an independent third party, at the school's own cost and on reasonable written notice, to assess our technical and organisational security measures, and we will cooperate with that assessment. We are saying the school has the right, not that such an assessment has happened: as stated under "What we do not claim", nobody has audited us.
Sub-processors: The companies that hold data for us are listed under "The other companies that hold it". We remain responsible to the school for what they do with it, we require them to be bound by protections at least as strong as these, and we tell the school at least 30 days before adding or changing one so that it can object, cancel, and take a full copy of its data.
Helping with requests: Where a parent, student or member of staff exercises a right under a privacy law — to see, correct, export or delete what is held — the request belongs to the school to answer, and we will help the school answer it.

One thing this section deliberately does not do is decide anything for the school. Where a law requires a school to obtain a parent's consent before a category of information is recorded — the medical field is the usual example — that consent is the school's to obtain, not ours, and the field can be switched off entirely for a school that would rather not hold it.

4.What we commit to

These are the commitments a board will want on one page. They are in the terms of service too, and we have promised there not to weaken them without the school's agreement.

Only for your school: We use the data only to provide and support the service for the school that entered it, and only on the school's instructions. Not for our own purposes, and not for another school's benefit.
Never sold: 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.
No advertising, no profiling: There is no advertising in the service and we do not target advertising at a student or a family. We do not build a profile of a student for any purpose other than showing his own school its own records.
No machine learning, no artificial intelligence: 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.
Not passed on: We do not disclose the data to anyone except the companies listed below that we need in order to run the service, and except where a law compels us — in which case we tell the school first unless we are legally forbidden to. We stay responsible to the school for what those companies do.
No new company without notice: If we add or change one of those companies in a way that affects the school's data, we tell the school's administrators at least 30 days beforehand. A school that objects can cancel and take a full copy of its data.
Returned or destroyed on your say-so: The school can ask for a complete copy of its data at any time, and can ask us to delete it. Copy within 30 days, at no charge. Deletion within 30 days, confirmed in writing.
Told quickly if something goes wrong: If information held for the school has been exposed, we tell the school without unreasonable delay and within 72 hours of confirming it, with what we know and what we are doing. Telling families is the school's call, not ours.
We help with a family's request: If a family asks the school for a copy of its son's record, or asks for something to be corrected or removed, we will help the school answer it. If a family writes to us directly, we pass it to the school rather than acting over the school's head.
Never held to ransom: We do not withhold a school's data to force a payment, and we never delete it for non-payment.

5.What is held about a student

In summary: names and Hebrew name, date of birth, a photograph, class and enrolment history, attendance for every seder, test and quiz marks, rubric scores covering learning, avodah and middos, written assessments from staff, follow-ups and any knas amount, leave and excuse records, subject exemptions, medical information a parent supplies, previous schools, notes a parent writes, admissions applications and their answers, and a copy of each report sent to a parent.

Plus, about the family: names, relationship, email, phone, home address, language and contact preferences, requests they make, and a log of the changes they make to their own details.

The privacy policy lists all of it field by field, including every place a staff member can write free text about a boy. A board reviewing this should read that section, and should think about what its staff write there.

6.Date of birth and medical information

The service holds both on purpose. A yeshiva needs a boy's date of birth, and a yeshiva responsible for a boy needs to know about his allergies, his conditions, his medications and his dietary needs. Parents fill the medical field in through the parent portal.

Because it is the most sensitive thing in the database, it is handled more narrowly than the rest:

Only staff who can open a student's profile can read it. At most schools that is the hanhala.
It is never in a parent progress report, never in a report link, and never in any automatic email.
It is never shown on our operator screens and never appears in a 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 statistics, research, or any aggregate figure.
When a student is deleted, it is deleted, including the old versions of it kept in the log of parent edits.

The limit a board should know: it sits in the database as ordinary readable text, because we do not add an encryption layer of our own on top of the database. Anyone with database access could read it. That is why the list of people with that access is kept short, and why the school can ask at any time who is on it.

7.The other companies that hold it

Clerk: Logins for staff and parents — email address, name and password credential. No student data.
Supabase: The database holding everything described above, including photographs, medical information and notes, and its backups.
Vercel: Runs the software and holds the server logs, so data passes through it in use.
Resend: Sends the email, so it receives recipients' addresses and the full content, including PDF progress reports.
Device notification services: Google, Mozilla or Apple, depending on the staff member's device, if they turn notifications on. They relay an encrypted message they cannot read.
Cloudflare: A bot check on our public enquiry form only. It sees no student or parent data.
Sentry: Fault reports, if we have switched it on, configured not to include request contents or network addresses.

That is the whole list. There is no analytics or advertising service and no payment processor. Progress report PDFs are produced by our own software, and roster spreadsheets are read by our own code — neither is sent to an outside service. The database and the application are hosted in the United States. Two of the companies above work differently by nature: the bot check on our public enquiry form runs at whichever of Cloudflare's locations is nearest the visitor, and a push notification is relayed by the visitor's own browser or device maker. Neither of those receives student data.

When paid card payment is switched on, a payment processor will be added here. It will receive the school's billing details and no student data, and card numbers will go to it rather than to us.

We will tell schools at least 30 days before adding a company to this list.

8.If your school treats itself as bound by FERPA

Many private yeshivas are outside the federal student-records law, because it applies to schools that receive US Department of Education funding. Whether that is true of your school is your school's question, with its own advisers. Some boards want to be held to the standard regardless. Either way, this is what we commit to, so a board can see there is nothing to negotiate about it:

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 the records only to provide the service to that school, and for nothing else.
We do not pass the records on, except to the companies listed above that we need in order to run the service.
We return or destroy the records at the school's direction, within 30 days, and confirm it in writing.

One thing we cannot do for you: if the school treats itself as bound, its own annual notice to families has to say that outside service providers may be treated as school officials with a legitimate educational interest. That is the school's notice, not ours. Ask us and we will remind you about it rather than assume it is handled.

This is not a claim that the service is compliant with that law, or with any other. It is a list of what we commit to. A school that needs a formal answer should get it from its own lawyer, and we will answer that lawyer's questions in writing.

9.Archiving is not deletion

This is the single point most likely to be misunderstood, so it is worth a board's attention.

When a boy leaves or graduates, the normal action is to archive him. Archiving keeps everything. His full history — attendance, marks, rubric, notes, follow-ups — and his medical information and his photograph stay in the database and stay readable on the school's former-student screens, with no time limit.

Deleting a student is a separate action, restricted to a hanhala account, and requires typing his name when he has any recorded history. It permanently removes his record and everything attached to it, including his medical information, the saved copies of every report ever sent about him, and the old values kept in the log of parent edits. It runs as one database transaction, so it either all happens or none of it does.

One thing survives it: the access and change log, which records that this student was deleted, by whom, and when, using his record number rather than his name. That is the trail of who destroyed the record, and it is deliberately kept.

There is no automatic expiry anywhere in the service. Nothing is deleted on a timer, and no retention period runs in the background. If the school wants a retention rule, it has to tell us and ask us to confirm each time it has been carried out, because we will be doing it by hand.

10.Getting your data out

The school can ask for a complete copy of its data at any time, for any reason, at no charge, and we provide it within 30 days. That applies as much on the way out as on the way in, and we will not make leaving harder than arriving.

What the software can do for the school without asking us: reports, class views and parent progress reports print or save as PDF, and the test gradebook downloads as a spreadsheet. Everything else — the full roster, attendance history, rubric scores, notes, follow-ups, contact details — we export by hand on request. There is no self-service whole-school export button yet, and a board should know that rather than discover it.

11.What happens when the school leaves

The school can ask for a copy of all of its data at any time, including on the way out. Ask at privacy@yeshivasuite.com.
The school can ask us to delete its data. We will do it within 30 days of the request, and confirm in writing when it is done.
If the school does not ask for deletion, we keep the data so the school can come back to it, for as long as that takes. We do not delete a school's records on our own initiative.
We will never delete a school's data because an invoice is unpaid. If payment stops, the account becomes read-only — staff can still sign in, read, print and export everything already recorded — and the data is kept.
If this business is ever sold or transferred, every school is told at least 30 days beforehand, the buyer is bound by the same commitments, and any school that would rather not continue can cancel and take a full copy of its data.
Copies may remain in the database provider's backups for a period after deletion, and in email that has already been sent. Neither can be recalled.

The read-only state is the intended behaviour and is written into the terms of service. It is not built yet, because there is no billing system in the service today. Deleting a whole school is also done by hand, with database commands, because there is no button for it — which is why the commitment above is 30 days and not 24 hours.

12.If something goes wrong

If personal information held for the school has been exposed, we will tell the school without unreasonable delay, and in any case within 72 hours of confirming it. We will tell the school what happened, when, what was affected as far as we then know, what we have done, and what we recommend. That first message may be short and incomplete; we would rather send it inside 72 hours than wait for a complete picture.

We will not tell a third party about it before we have told the school, unless a law requires it. We will keep the school updated as we learn more, including if it turns out to be worse than the first message said.

The school decides what to tell its families and any authority, since the school is the one with the relationship to the family. Those rules differ by the state each family lives in, and in some states they are counted in days. 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, at no charge.

13.What we do not claim

A board should have the short version of this in front of it, not buried in a policy:

We hold no security certification, we are not audited by anyone, and we have not had an outside penetration test.
We rely on our hosting and database providers for the security of the servers and the data they store, and we add no encryption layer of our own on top of theirs.
There is no service level agreement and no promised uptime.
Our liability is capped, and the caps are low in absolute terms. A board should read the limitation of liability section of the terms of service itself rather than rely on a summary of it.
Parent report links open without a sign-in — 90 days for a progress report, 400 for a report card — and we cannot tell a school whether or by whom one was read.
Opening a boy's record is logged and a hanhala can read its own school's log, but it is a strong record of what happened rather than complete proof of it.

A school that needs more than this should say so before signing rather than after. Some of it we can fix, and knowing which parts a board actually cares about is how it gets prioritised.

14.Signing this

This addendum is part of the terms of service, which is accepted when a school creates an account. The terms of service and the privacy policy are the fuller documents and they govern, except that this addendum wins on anything to do with handling school data.

If the school needs a countersigned data agreement, or wants this on its own paper, or has its own form of data processing agreement it needs signed, write to privacy@yeshivasuite.com and we will arrange it. A board asking for that is a reasonable thing to ask for, not an obstacle.

Operated by YeshivaSuite LLC, 418 Broadway, Ste N, Albany, NY 12207. Governed by the law of the State of New York.