Data processing

Data Processing Addendum

Effective September 3, 2026

1. What this document is

This Addendum is part of the Terms of Service between Fireside WiFi LLC, doing business as Cordelle, of Salt Lake City, Utah, USA (“Cordelle”, the processor) and the tour operator with a Cordelle account (“you”, the controller). It applies automatically to every account — you do not have to ask for it or sign anything separate. Where it conflicts with the Terms about the handling of personal data, this Addendum wins.

It is written to satisfy Article 28 of the UK and EU General Data Protection Regulation. If you are not subject to the GDPR it still describes accurately what we do, and we are happy to be held to it either way. Words like controller, processor, personal data, data subject, processing and personal data breach carry their GDPR meanings.

Cordelle also acts as a controller for a small separate set of data: your staff’s account and billing records, our own website analytics, and the support correspondence you send us. That part is covered by the Privacy notice, not by this Addendum.

2. Subject matter, nature, purpose and duration

• Subject matter: providing the Cordelle service — the operator dashboard, the traveler and guide apps, and the API — to you.
• Nature of the processing: collecting, storing, organizing, structuring, publishing to invited devices, transmitting by push notification and email, retrieving, erasing, and backing up.
• Purpose: running your group tours. Nothing else. We do not use your travelers’ personal data for our own analytics, for product research, for marketing, or to train machine-learning models.
• Duration: for as long as your account exists, plus the deletion and backup windows in § 13.

3. Whose data this is about

• Travelers on your departures — the people who join with a code.
• Guides you employ or contract, including guides you have archived, whose record of the trips they worked is kept.
• Your office staff, including people you have invited but who have not yet accepted.
• Emergency contacts named by a traveler — a third party who never uses Cordelle and usually does not know it exists. Worth a thought when you decide what to collect.
• People named in trip content you type in yourself: a hotel manager’s name in an itinerary note, a local driver in a day’s details. Whatever you put in free-text fields, we hold.

4. What personal data we process

This is the real list, taken from the database itself rather than written from memory. Only the fields you fill in exist for a given person — almost everything about a traveler except their name is optional.

Server logs record the ordinary technical facts of a request — time, path, status, and the identifiers of the records involved. They are not designed as a store of personal data, and we do not mine them.

5. Health data, said out loud

Dietary notes and mobility notes are health data. Under Article 9 of the GDPR they are special-category personal data, and so is anything that reveals a condition indirectly — “coeliac”, “uses a wheelchair”, “nut allergy, carries an EpiPen”. The Cordelle importer deliberately accepts a column headed Medical or Medical notes into the mobility field, because that is what operators’ spreadsheets actually call it, and the guide app shows the two fields together under the heading Dietary & medical notes. Calling them anything softer here would be a lie of omission.

How they are handled:

• They are stored in the same database as the rest of the roster, scoped to your agency, and are readable by your own staff and by the guides you assign to that departure.
• On a guide’s phone, the screens that show them sit behind a PIN the guide sets themselves, and lock again after the app has been closed a while. The PIN is stored only as a salted hash.
• They ride inside the published trip bundle held on guide devices so the roster works offline. A guide who leaves the trip clears that copy from their phone.
• They are never shown to other travelers, never used by us for anything, and never sent to any third party. The airline data feed receives flight numbers and dates only.
• They are included in the nightly database backup described in § 10 and § 13.

What this asks of you. As the controller you need an Article 9 condition for holding this data — in practice the traveler’s explicit consent, given when they book. Ask only for what a guide genuinely needs in order to look after somebody, tell travelers it will be visible to their guide, and take it out when the trip is over and you no longer need it.

6. Location data

Location is the other category worth its own section, and the product rule is stricter than the law requires:

• Off by default for every traveler on every departure. Nobody — not you, not us — can switch it on for someone else.
• A session the traveler starts, with a length between 15 minutes and 4 hours (the app offers one hour), which expires on its own. They can stop it early, and a stop tapped with no signal is honored the moment the phone reconnects.
• Foreground only. The app never asks the phone for background location permission. Continuous tracking is not a setting we hid; it is not built.
• SOS is the exception, and only that: an SOS or a deliberate “send my location once” sends a single position with sharing off. The tap is the consent and it covers that one position.
• Guides see a last known position with its time, never a track.
• Pings are deleted from the live database by a daily sweep once they are more than 30 days old, counted from when our server received them. Backups extend that tail — see § 13.

You must not make location sharing a condition of joining a trip, and you must not press travelers to turn it on. That is in the Terms as well.

7. Our instructions come from you

We process personal data only on your documented instructions. Your instructions are: the Terms of Service, this Addendum, and the ordinary use of the dashboard, the API and the integrations by you and your staff. What you type, upload, publish, message, sync or delete is the instruction.

• We will not process your travelers’ personal data for any purpose of our own.
• We will not sell it, share it for advertising, or use it to train machine-learning models.
• If a law we are subject to requires us to process or disclose data beyond your instructions, we will tell you before we do, unless that law forbids telling you.
• If we think an instruction breaks data-protection law, we will say so.
• If we receive a government or law-enforcement demand for your data, we will redirect it to you where we lawfully can, challenge anything overbroad, and tell you unless we are legally gagged.

8. Confidentiality

Everyone with access to personal data processed under this Addendum is bound to keep it confidential, and access is limited to the people who need it to run and support the service.

Plainly: Cordelle is a very small company. Today production access is held by the founder alone. There is no support team browsing your roster, and equally there is no rota of colleagues to check each other’s work — you should weigh both halves of that. If that changes, anyone added will be under a written confidentiality obligation before they are given access.

9. Security measures

These are the technical and organizational measures that exist in the product today. Nothing here is aspirational.

• Separation between operators. Every dashboard query is filtered by the agency behind the signed-in staff token, and every guest request is scoped to the traveler behind their token. A guide token opens exactly one departure. This is enforced in the server, not in the interface, and the test suite covers cross-account denial.
• Encryption in transit. Everything travels over HTTPS/TLS, with HSTS on our websites.
• Encryption at rest. The database is managed Postgres on Neon, which encrypts its storage; backups are stored in a private object-storage bucket.
• Passwords and PINs are stored only as scrypt hashes with a per-record random salt. We cannot read them, and neither can anyone who steals the database.
• Session tokens are opaque and stored hashed. They carry no information, they are revocable, and a database dump does not yield a working token. Traveler and guide sessions last 180 days so the app never demands a login mid-trip; staff sessions last 30 days; expired rows are deleted daily.
• Two-factor authentication (TOTP) is available for staff accounts, with hashed one-time recovery codes. Secrets are sealed with AES-256-GCM under a key held only in the server’s environment, so a database dump yields ciphertext. A code cannot be replayed.
• Brute-force limits. Staff logins and guide PINs lock the individual account after repeated failures; join and login endpoints are rate-limited per address.
• Guide access is revocable in one tap — a new code, and every session on the old one ends immediately. Archiving a guide revokes their sessions at that moment.
• Care notes behind a PIN on guide devices, as described in § 5.
• API keys are stored hashed, shown once, revocable, and can reach only the small /api/v1 surface — never billing, team, two-factor or key management. Integration tokens for outside systems are sealed with AES-256-GCM.
• Least privilege between our own systems. The backup job runs as a separate application with its own storage bucket and its own keys; the API machine holds none of them, so a compromise of the API cannot reach the backups.
• Backups. A full database dump is taken nightly and kept for 14 days, plus the hosting provider’s own short point-in-time restore window. A written restore procedure is kept with the job.
• Content limits. Every field the API accepts has a hard length ceiling, and uploads such as your logo are size-capped, so no single record can be used to flood the store.

What we do not have

A security page that lists only strengths is not much use to a buyer, so:

• Cordelle holds no SOC 2, ISO 27001 or comparable certification, and there is no third-party audit report to send you.
• There is no 24/7 security monitoring and no on-call rota. Alerting is what our hosting providers offer plus our own checks.
• There is no customer-facing audit log of who in your office viewed which traveler.
• There is no self-serve data export yet — see § 12.
• Backup restores are documented but not yet on a published rehearsal schedule.

We will keep this section honest as those change, in either direction.

10. Subprocessors

You give general authorization for the subprocessors below. Each holds only what its job needs and none of them may use the data for their own purposes. This list is the same one published in the Privacy notice, with the backup vault spelled out.

Changes. We will email your account owner at least 30 days before adding or replacing a subprocessor that handles traveler personal data. If you reasonably object on data-protection grounds, tell us within those 30 days and we will look for an alternative; if there isn’t a workable one, you may cancel without penalty, and your plan runs to the end of the month you have already paid for. Note that Cordelle does not refund prepaid fees (§ 7 of the Terms) — which is why the notice period is 30 days rather than the shortest one we could get away with: you always get the chance to cancel before the change takes effect and before the next invoice.

Each subprocessor is engaged under a written contract with data-protection terms no less protective than these, and we remain responsible to you for what they do.

11. Where the data is

Cordelle’s API and database both run in the United States, in the same US region as each other, and the nightly backup is written to storage reached through the same hosting provider. Several subprocessors (Cloudflare, Expo, Apple, Google, Stripe) operate global networks by nature, so data may be handled in other countries by them. If you need the exact region named in a contract or a records-of- processing entry, ask and we will confirm it in writing.

For personal data coming from the UK or the European Economic Area, transfers to Cordelle rely on the European Commission’s Standard Contractual Clauses (module two, controller to processor), with the UK Addendum where the UK GDPR applies. Those clauses are incorporated into this Addendum by reference; the details in §§ 2–4 serve as their Annex I, and § 9 as their Annex II. Ask us at [email protected] if you need them as a signed document for your own file.

12. Helping you with your travelers’ rights

Requests from travelers, guides or staff about their own data come to you — you are the controller and you hold the relationship. If one reaches us instead, we will not answer it ourselves; we will pass it to you promptly and tell the person we have done so.

Most requests you can satisfy yourself, in the dashboard, immediately:

• Access and correction: every field the roster holds is visible and editable on the traveler’s record.
• Erasure: deleting a traveler removes that person; deleting a departure removes its travelers, join codes, sessions, messages, location pings, push tokens and published bundles with it. Both are immediate and permanent in the live database.
• Objection to location processing: nothing to do — sharing is already off unless the traveler turned it on, and they can stop it themselves at any moment.
• Restriction: ask us; there is no self-serve switch for it.

Portability is the gap. There is no export button today. If a traveler asks for a copy of their data, or you want your whole account’s data out, write to [email protected] and we will produce a machine-readable copy by hand, without charge, within 14 days — sooner if you tell us a statutory deadline is running.

We will also give you the information you reasonably need for a data-protection impact assessment or a consultation with your supervisory authority.

13. Keeping it, returning it, deleting it

We keep your travelers’ data for as long as you keep it. We do not delete your content on our own initiative — not when a trip ends, not when a trial lapses, not when a subscription is canceled. Some things do expire on their own:

• Location pings: deleted from the live database by a daily sweep once more than 30 days old.
• Push tokens: removed when someone leaves a trip, and swept once the departure ended more than 30 days ago.
• Join codes: stop working 90 days after a departure’s end date, whether or not the record is still there.
• Sessions, invitations, reset links and sign-in challenges: deleted daily once expired or used.

On termination. Tell us what you want and we will do it: return a machine-readable copy of your data, delete it, or both. A full account deletion is performed by hand within 30 days of your request. If you say nothing after canceling, your data stays as it is — dormant, not deleted — because deleting a tour operator’s history because they missed an email would be worse than keeping it. We will not hold data hostage over an unpaid invoice.

The backup tail, honestly. Deleting something removes it from the live database at once, but nightly dumps are kept for 14 days. So a deleted record can survive in a backup for up to 14 days after deletion — and a location ping, which is already 30 days old when the sweep takes it, can therefore exist somewhere for as much as 44 days in total. Backups are never used to resurrect data that was deliberately deleted; they exist to restore the whole database after a disaster, and if one were ever restored we would re-apply your deletions. We will not claim a deletion is instantaneous everywhere when it is not.

14. If there is a breach

If we become aware of a personal data breach affecting data we process for you, we will notify you without undue delay, and in any event within 72 hours of becoming aware. The notice goes by email to your account owner, and will tell you what we know at the time: what happened, when, which categories and roughly how many people are affected, what the likely consequences are, what we have done, and what we suggest you do. If the picture is incomplete we will send what we have and follow up rather than wait.

We will help you meet your own obligations to your supervisory authority and to the people affected. Notifying regulators and data subjects is your call as controller — we will not do it in your name without your instruction.

15. Audit and information

We will give you the information you reasonably need to satisfy yourself that we are meeting this Addendum: we will answer a written security questionnaire, walk through the measures in § 9 on a call, and confirm our subprocessors and where data sits.

What we cannot offer today is what a larger vendor would: there is no third-party audit report to hand you, and we do not host on-site inspections. If your own regulator or your contract requires an inspection or an independent audit, write to us and we will agree something workable rather than refuse — at your cost, at a reasonable time, no more than once a year unless a regulator or a breach makes it necessary, and without giving anyone access to another operator’s data.

16. Liability and precedence

Each party’s liability under this Addendum is subject to the limits in § 13 of the Terms of Service, except where the GDPR does not permit it to be limited. Where the Standard Contractual Clauses conflict with this Addendum, the Clauses win; where this Addendum conflicts with the Terms about personal data, this Addendum wins; otherwise the Terms apply.

17. Changes to this Addendum

Changes appear on this page with a new effective date. For any change that materially affects your position as controller, we will email your account owner at least 30 days beforehand. We will not quietly weaken it.

18. Contact

Data-protection questions, subprocessor objections, deletion and export requests, and breach correspondence: [email protected]. A person reads it, usually within a business day.

The processor under this Addendum is Fireside WiFi LLC, doing business as Cordelle, whose place of business is Salt Lake City, Utah, USA. Notices under this Addendum — including a subprocessor objection and anything about a breach — are given by email to [email protected] and are effective when sent.