How DiveDay handles data

What we hold, where it lives, and how it leaves

Describes DiveDay as it works today.

DiveDay is dive-shop software. Most of the personal data in it belongs neither to us nor to the shop alone: it is the shop’s divers’ data, held on the shop’s instruction. This page says what we hold, who else can touch it, and how it comes back out. It describes current behaviour rather than intentions, and where something is still being decided it says so.

Two different relationships

With a dive shop: we are the software they run their business on. Their staff hold accounts with us, and we hold what they put in.
With a shop’s divers: we hold data on the shop’s instruction. A waiver, medical answers and certification evidence are the shop’s records, in the shop’s own tenant. We do not sell them, do not train anything on them, and never move them between shops. A diver wanting to see or delete their record should ask their shop, which can do both from inside DiveDay.

What is stored

Shop accounts: a name, an email address, a hashed password, and the shop and role the account belongs to.
Diver records: name, contact details, an emergency contact, certification level and the evidence a shop verifies against, rental sizes, and the bookings they hold.
Waivers and medical answers: the signed release and the health questionnaire a shop asks before a dive. This is the most sensitive thing in the system and is treated that way: it renders only to the shop’s own staff and to the diver holding the link, and it never appears in a log line or an analytics event.
Payments: DiveDay never sees a card number. Cards are entered directly with Stripe on the shop’s own connected account. We keep the amount, the state and Stripe’s identifiers, so a shop can reconcile a refund without us holding anything worth stealing.
Operational trails: who moved a booking, who marked a diver aboard, whether a confirmation arrived. Short who-did-what-when rows, in the shop’s own tenant.
The copy on a boat phone: So that a head count still works with no signal, a crew phone holds its own copy of the next two days of manifests: the roster, emergency contacts, and whether each diver is cleared to board. It is stored encrypted on that phone, under a key the browser will not hand back out, so it cannot be read off the device’s storage. Anyone holding the unlocked phone can open it, the same as the paper manifest it replaces. It is removed when a different shop signs in on that phone, and it deletes itself at the earlier of fourteen days after it was saved or seven days after the trip ended.

Where it is processed

Primarily in the United States. The database is Neon, the application and its file storage run on Vercel, and the mail, messaging, backup and monitoring pieces run in AWS. Vercel serves the site from wherever the reader is, so a request is first answered near them before it reaches the United States.

Who else touches it

Each of these is a service DiveDay runs on, and each sees only the slice it needs:

Stripe: payments, on the shop’s own connected account. Card details go to Stripe directly and never through us.
AWS: sending email and SMS, storing the weekly backups, and holding logs and performance metrics.
Meta: WhatsApp messages, and only for a shop that has connected its own WhatsApp sender. A shop that has not connected one sends Meta nothing.
Vercel: hosting, the file storage that holds photos and certification evidence, and page-level analytics. Analytics records which pages are viewed; we do not attach a diver’s or a staff member’s identity to a page view.
Neon: the database itself.
Sentry: error reporting. When something breaks, the crash is sent here so we can fix it. The address of the page is stripped of any token before it goes, and we do not send diver records with it.
Google: the embedded map on a dive-site briefing and on a diver’s trip-prep page. Opening one of those pages reaches Google directly, so it sees the request the way any embedded map does; the page’s own link is withheld from it.
Apple, Google, Mozilla and Microsoft: browser push notifications for staff who turn them on. Each gets a device address and an encrypted payload it cannot read.

Links that work as keys

Some of what DiveDay sends is a link that needs no password: the waiver a diver signs, their trip-prep page, the recap after a dive. Holding the link is the permission, so it can be opened on a dock with one hand free. Those links are treated as credentials throughout: the token is removed before a page view is recorded, before an error is reported, and before any line reaches a log. They expire, and a shop can invalidate one.

How long it is kept

The shop’s own records are kept while the shop is using DiveDay, and go when the shop deletes them or ends its account. The append-only trails have fixed windows, and these are the real numbers the system prunes on:

Staff activity history: 3 years.
Message delivery attempts: 400 days. These hold provider identifiers and error codes rather than message bodies, though a provider’s own error text sometimes quotes the address it failed to reach.
Payment event history: 7 years, matching the ordinary horizon for financial records. The orders and payments themselves are the shop’s records and stay until the shop removes them.
Payment-processor event records: 400 days. These hold no diver data at all.
Expired sign-in and reset tokens: 90 days past their own expiry. A live one is never pruned.
Device notification registrations: 30 days.

Still being decided: how long a signed waiver and its medical answers should be kept after a diver stops diving with a shop. Today they stay until the shop removes them, because a release is evidence a shop may need years later, and shortening that without advice would be the wrong kind of guess. It is under review with the same counsel reviewing the waiver text, and this page will say the answer when there is one.

Getting data out, and getting it deleted

Export: A shop can download its records from DiveDay as one ZIP, from its own settings, on any day, without asking us and without a fee. It is the same bundle our own backups are made of. A few internal tables are left out of it (delivery retry mechanics, device registrations, the sealed credentials for a shop’s own backup destination), and nothing left out is a record of a diver.
A diver’s own copy: A diver may ask a shop for a copy of what it holds about them, and staff can download it from the diver’s own record page as one ZIP: their bookings, certifications, waivers, payments and reviews at that shop, never another diver’s. Signed medical answers are left out of it for now, pending a decision recorded at docs/product/human-decisions.md.
Erasure: A shop can erase a diver’s record. Where that record reached a payment processor, the erasure is tracked as owed until it is discharged rather than being declared done at our own edge. A customer object DiveDay deletes itself and confirms. An invoice a processor has already issued is a request a person has to file, and the shop can see it sitting there until they do.

Asking us something

Write to support@dive.day. If you are a diver rather than a shop, your shop holds your record and can answer faster; if they cannot, we will help them.

What this page does not yet say

DiveDay is in early access and some of this is unsettled: the retention period for waivers and medical answers, and the formal data-processing terms a shop signs. Rather than publish a policy that reads complete and is not, those are named here as open. Nothing above is aspirational. It describes what the code does today.