Security summary

Jettova for Schools coordinates a school trip: roster, chaperones, permission-form tracking, itinerary, rooming, announcements, and optional per-family payment collection.

• Students have no accounts and never use the platform. Every account belongs to an adult: a staff organizer or a parent or guardian.
• The school is the data controller. Jettova is a processor acting on the school's written instructions. Where the platform is used with US K-12 students, Jettova acts as a school official performing an institutional service under the school's direction.
• For family payments the school is the merchant of record. Money settles into the school's own Stripe account. Jettova never holds school or family funds.
• The optional student emergency, medical, and travel-roster layer is switched off in every environment and cannot be enabled without a separate written agreement. In the live product we do not ask for medical data, date of birth, gender, SSN, grades, discipline records, photos, or student geolocation. A school's own permission form can carry health, allergy or emergency-contact details; the signed copy a family uploads is stored privately and opened only by the trip's organizers, the program administrator, and the family that uploaded it.

Primary data store

Supabase (managed PostgreSQL), US-hosted

File storage

Supabase private buckets. Uploaded permission forms are never public; staff reach them only through short-lived signed URLs

Application hosting

Vercel

Database access model

Row-level security is on for every table. The tables that hold school data (trips, rosters, payments, student records, organizations and staff) grant no access at all to a browser's key or to a signed-in person's own credential, so they cannot be read or written directly. Every read and write goes through a Jettova server route that authenticates the caller and checks their current role in the school first, then uses a server-only credential that never reaches a browser. The one exception is Jettova's separate consumer trip planner, where a signed-in person can read and delete their own personal trips directly; school trips are excluded from that by the database policy itself. Browsers also hold a live connection, one channel per trip, that signals when the trip has changed and who in the room is online or typing

Role checks are enforced on every request, not once at login. A staff member's permission is re-checked per request against their current role, so a demotion or removal takes effect immediately rather than at their next sign-in.

Roles. The program administrator runs the whole program. Organizers (coaches) run only the trips they created or were added to. The Principal or Program Director oversees and can run every trip, approves trips, and sees families' names and contact details, but not medical records, legal identities or signed forms. Finance sees the program's money with anonymous family labels. A chaperone sees nothing about anyone until staff record their background-check clearance; then, on the day, they see the first names of the students in their own group and who in it is not travelling; once staff publish groups, they also see that group's pickup lists and can call that group's guardians (or an adult participant's own number), never another group's. A family sees only the trips it was invited to, and only its own record, its own students' pickup lists and what it owes. Cross-organization isolation is enforced on the server. The full table is on the student data privacy page.

Student names are treated as minor PII throughout. Staff who run a trip see real names because they need them. Seats and outputs that do not need names, such as Finance, drafted messages, and the tour-operator page, label families anonymously instead.

End-of-trip release. Pickup lists (name, relationship and phone of the people a guardian says may collect a student) and dismissal records live in their own tables, separate from the rest of the trip, and no browser can read them directly. Program staff see every list on a trip they run; a cleared chaperone sees only their published group's; Finance and other families never do. Only a guardian can let a student leave on their own; staff can remove that permission, never grant it. The program administrator's export includes pickup lists and dismissal records; the Principal's export, and every other seat's, does not. Releasing a student to someone not on the list needs a written reason and confirmation by a second, different staff account, checked by the server and by a database constraint. Every release records who released whom, to whom and when, and recording one needs a connection, so a student cannot be released twice from two offline phones.

• In transit: HTTPS with HTTP Strict Transport Security between the browser or app and our servers, and between our servers and every database and vendor API we call.
• At rest: managed database and object-storage encryption provided by our infrastructure provider.
• A production Content-Security-Policy is set, including frame-ancestors, so our pages cannot be framed by a third-party site.

• Sign-in runs on Supabase Auth: email and password, magic-link email, or OAuth with Apple and Google. Passwords are held only by the sign-in provider, as a one-way hash; Jettova's own tables never store one.
• A school can choose to create families' accounts itself. Staff never choose, see or reset a password: the account is created with none, and staff receive a one-time setup code, shown once and stored only as a one-way hash. That code cannot set a password by itself. Choosing one needs the link we email to the address on the roster, and a guardian also enters their student's first name. Codes expire after 7 days and stop working after 5 wrong tries.
• Staff can make a trip invitation-only. A personal invitation is stored as a one-way hash of its link, expires after 7 days, and opens only for a signed-in account whose verified email is the address on the roster, with the student's first name.
• On a school trip every family joins with a signed-in account, so every student has an adult of record. Returning a permission form needs that account. A device credential alone never opens a school trip: device requests must match the signed-in session. Device credentials are treated as bearer secrets and are redacted from every response to other members.
• One exception, by design: a family can send a pay-for link so someone outside the trip, such as a grandparent, can pay that family's share without an account. The link is signed, opens only that one payment, expires, and can be revoked.
• Administrative access to Jettova's own internal tooling is restricted to an explicit email allowlist held in server configuration, on top of an authenticated session.

Jettova is a small company. Access is constrained by mechanism rather than by headcount:

1. There is no internal console that browses school data by default. Internal pages are gated by the email allowlist above, server-side.
2. The server-only database credential lives in the hosting provider's encrypted environment configuration. Anyone who holds it can technically read the database; that is the true boundary, and we state it plainly rather than implying a stricter one.
3. Opening a student record and downloading a trip's departure pack (the offline roster staff carry) are logged to an append-only access log recording who, what, and when. Logging is best effort, so it never blocks a staff member doing their job. The log is purged on a roughly 400-day schedule by a daily production job, and survives deletion of the trip it refers to. The program administrator and the Principal or Program Director can see this log and export it as CSV; organizers (coaches) cannot.
4. The access log reports its own completeness: if an audit write is lost, we try to count the gap and show it to the school, so a known gap does not pass silently. That count is itself best effort.

Honest limits. We do not today publish a formal internal access register, a background-check policy, or evidence of enforced multi-factor authentication on every vendor account. Those are reasonable procurement questions and we will answer them specifically on request rather than assert them here.

Card numbers are entered directly into Stripe's hosted fields and never reach Jettova's servers, logs, or database. We hold only non-sensitive Stripe references and amounts. This is the SAQ-A handling model. Payment webhooks are cryptographically signature-verified before any state change. Money-moving endpoints are rate-limited.

The vendors that can touch school data are listed in one place, with what each receives, whether it can include a student's name, and when it is used. In summary:

No advertising network, affiliate tracking tag, ad-tech tag, marketing pixel, or third-party behavioural analytics tool runs on any Jettova for Schools surface. Jettova operates a commercial affiliate tag on its consumer travel site. That tag is blocked by code on every school surface (/schools, /nonprofits, every trip room /room/..., and the sign-in page /login a family passes through), and the block is pinned by an automated test. We do not run Google Analytics, Google Tag Manager, the Meta pixel, Segment, PostHog, Hotjar, or Microsoft Clarity anywhere in the product.

What does run on a school surface. The vendors that run on a school surface are Supabase, Vercel, Stripe, Resend, Sentry, Upstash, Anthropic (our AI provider), Foursquare, Duffel, Blackbaud, Google and Apple, Photon (komoot), OpenStreetMap Nominatim and Wikipedia, OpenStreetMap, Unsplash and Wikimedia Commons, Slack, Expedia and Ekta (affiliate links). Several only run when a school or a staff member turns a feature on. What each one receives, and when it is used, is on our school sub-processors list, the one list we keep for Jettova for Schools, so this summary and that page cannot disagree. None of them is an advertising vendor. The two affiliate programs appear only as optional links on staff pages and receive nothing from our systems.

School trips send no push notifications, so no app-store push service receives school trip content. Session Replay is not enabled in our error monitoring, and a family's payment link and device credential are stripped out before an error report is sent. An affiliate booking link a staff member follows carries the channel it came from, never the trip's room code.

While a trip is active, its data is kept so the trip can run. A school can remove a family or delete a trip that has no payment records at any time, close its account once any online payments on record are refunded, or ask us to do any of these, and we act on that request.

• One year after the trip's return date (or, if it has no dates, one year after the trip was last active, counted no later than the date its room expires), a nightly job removes the names families entered, including students' names, contact details, home locations, electronic-signature details, uploaded permission forms and room labels, including the copies of a name kept on payment records, polls and date votes, for families still on the trip and families removed earlier. The trip and its payment records remain, with each family shown as “Former member”, so the school's financial records stay complete. This job runs in production every night.
• Uploaded itineraries are deleted 30 days after the trip's return date, or when the trip room expires (normally two years after the trip was created) if the trip has no dates, by a daily job. The optional emergency and medical layer is off, so no such records exist; if a school turns it on, those records are deleted 30 days after the trip's current return date, so a postponed trip keeps them, or when the trip room expires if the trip has no dates.
• Removing a family takes them off the roster immediately. Their uploaded form is deleted 30 days later, so a mistaken removal can be undone. Their students' pickup lists and not-travelling marks are deleted with them, and the names, relationships and reasons on their students' dismissal records are removed. A family deleting its own account does the same for its pickup lists, not-travelling marks and dismissal records.
• At the one-year step, every pickup list and not-travelling mark is deleted, and dismissal records keep only that a student was released, how and when. Headcount taps, invitation records and setup codes hold no names; they stay with the trip until it is deleted, and an invitation or setup code stops working after 7 days.
• Messages, announcements, schedule notes, questions and poll answers typed into a trip are kept as written, because they are the school's record of it; a school can ask us to remove them. Organizers' private notes on a family's financial aid are removed at the one-year step; the aid amount stays with the payment records. A family removed from a trip has its own messages deleted with it.
• Access-log entries are purged after roughly 400 days by a scheduled job that runs daily in production. We report the job rather than the intention because a retention promise no job enforces is not a control.
• Itinerary and form deletions remove the underlying files. The one-year step anonymizes rather than deletes, for the financial-record reason above.
• Nothing deletes a school trip itself, its payment records, or the program's log of staff actions on a schedule today. They stay after the one-year step. Family names are removed from the trip and its payment records as described above; the log of staff actions keeps the email addresses of the staff who acted.
• On termination, the school chooses deletion or return of its data, except where a record must be retained for financial or legal reasons. Today that is a manual process we carry out with the school: a program that holds real payment records cannot yet be deleted in the product, and there is no way yet to delete the program's log of staff actions.
• Deleting a trip that carries real payment records is blocked, so financial records are preserved.

What is contractually committed: Jettova will notify the school without undue delay after becoming aware of a personal-data breach affecting the school's data, with the information the school reasonably needs to meet its own notification obligations. This is section 7 of our Data Processing Addendum and is the commitment your agreement can rely on.

What is in place operationally: continuous application error monitoring with alerting, an append-only audit log for student-record access, cryptographic verification of payment webhooks, and a published security contact at security.txt for researchers.

What is not yet in place, stated plainly: Jettova does not yet have a written, exercised incident-response runbook with named roles, a defined severity scale, a committed notification clock in hours, or a monitored dedicated security mailbox. Security reports currently route to the general contact channel. We would rather tell you this than imply a maturity we have not reached. If your district requires a specific notification window, propose it in your agreement and we will negotiate to it rather than point at a plan that does not exist.

We hold no security certification. Specifically:

• Not SOC 2 certified. A SOC 2 Type II examination is on our roadmap. We will not claim it until an auditor has issued a report.
• Not ISO 27001 certified.
• Not independently PCI DSS certified. Card handling is delegated to Stripe, which is PCI-compliant. Our own handling follows the SAQ-A model described in section 6; we have not completed a formal attestation.
• No independent penetration test of the payment surface has been commissioned yet.
• No independent accessibility audit. We aim at WCAG 2.1 AA on school and family surfaces, test as we build, and treat reported barriers as bugs.
• Where the data is, stated exactly. Data is encrypted in transit and at rest. Our database and the application servers that read and write it are in the United States. Other providers on our sub-processor list may process or store limited data outside the United States. The database runs in Amazon Web Services' Ohio region (us-east-2) and the application servers that read and write it run in Vercel's Washington, D.C. region (iad1). We publish the regions rather than the word “domestic” so the claim is one you can check instead of accept. What we do NOT have is a contractual residency guarantee: neither provider is under a term with us that pins those regions, and we hold no certified residency region. So this is where your data is today, verified, not a promise about where it will always be. The components that run at the edge, meaning they may execute nearer to whoever is asking, are the social preview images, the small pictures that appear when a link is pasted into a message. One of them covers a trip room. For a school trip it shows only a generic invite, with no trip name, destination or headcount, because a trip link is often forwarded and a preview is shown to whoever sees it. It reads no student record, no family contact, no permission form and no payment. The request router is not one of them. In this version of our framework it runs on the Node.js runtime and that is not configurable. Separately, our travel search provider may process lodging searches in the EU under data-protection terms, and that path carries no student data. If your district requires a strict United States-only guarantee, raise it as a contract term and we will scope it rather than assert it generally.

Jettova signs the Student Data Privacy Consortium National Data Privacy Agreement (NDPA) in your state's version, with the General Offer of Privacy Terms (Exhibit E) so other districts in your state can adopt it without renegotiating. We prefer your district's own instrument over a bespoke Jettova contract. For New York districts we support Education Law 2-d contracting, including a Parents' Bill of Rights supplement.

Related published documents:

• Student data privacy
• Data Processing Addendum
• Sub-processors
• Security overview
• Data residency