Data processing

Data Processing Addendum

Effective October 2, 2026

The short version

You are the controller. Cordelle is your processor. Your travelers’ data is yours; we hold and move it to run the app for your trips, and for nothing else.
We process only on your instructions, and we never use your travelers’ data to train models, to advertise, or to build anything of our own.
Dietary, mobility and medical notes are health data under GDPR Article 9. So is the fact that they exist. Section 5 says exactly how they are handled and what that asks of you.
Location is consent-first: off by default, started only by the traveler, expiring on its own — a short timed session, or (from app version 1.3.0, if they choose it and grant the phone’s permission) occasional positions for the length of their trip, ending automatically when the trip does. Nothing runs that a traveler did not start, and everything stops at one tap.
Everyone who touches the data on our side is listed in § 10 — including the backup vault, which most vendors leave off the list.
Where a commitment does not exist yet, this page says so instead of inventing one.

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, the API, and, for operators who switch one on, a public tour catalog site with its inquiry form — 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 — including keeping your own notes, to-dos, readiness checklists and bookkeeping records about your guests and departures, building call lists from your own trip history, and receiving the inquiries your catalog site’s form sends you. 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.
People a traveler names in a group message, once you have turned on a departure’s group room (§ 4, Traveler-authored content). Whatever a traveler writes there, we hold on your behalf.
Guests in your guest book — the people in the cross-season record your office keeps, including guests from past seasons you import from your own spreadsheets, who may never have used a Cordelle app at all.
People who send your catalog site’s inquiry form — prospective travelers who typed their details into your public site (§ 4, Website inquiries).

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.

About	Fields
Travelers	First and last name; email address; phone number; traveling party or room grouping; dietary notes (the spreadsheet importer also accepts this column when it is headed “Diet”, “Dietary requirements”, “Allergies” or “Food”); mobility notes (likewise “Medical”, “Medical notes”, “Accessibility” or “Accessibility needs”); emergency contact’s name and phone number; the six-character join code; when they joined; when they were invited, to which email address, and how many times; and, for travelers created by an integration, the reference the outside system knows them by.
Your guest book	The cross-season record your office keeps of each guest: first and last name; email address; phone number; free-text tags; a do-not-contact flag; and the trips they have traveled with you — both departures run in Cordelle and seasons imported from your own spreadsheets, each with a label and a date. Travelers on your rosters are linked to their guest-book record by email address. Office-side only: never shown to travelers or guides, never in the published trip bundle, the printed packet or a webhook payload.
Your guest book’s notes and tasks	Notes your staff write about a guest — free text, up to 10,000 characters, with the writer’s name and the date, kept exactly as written (notes cannot be edited, only deleted and rewritten, so the record of who said what and when stays honest); and office to-dos — a title, an optional due date, who it is for and who wrote it. Both are visible to your office only: never to travelers, never to guides, never in the published trip bundle, the printed packet or a webhook.
Readiness checklist	For each departure, the paperwork items your office decides to track (“passport copy”, “insurance form”) and, per traveler, whether each has arrived — one of four fixed states, with who in your office marked it and when. Your office records what arrived by post, email or phone; travelers are never asked to upload anything, and none of this appears in their app. The one thing a traveler can receive is a reminder email your office triggers by hand, listing the missing items.
Money records	Bookkeeping rows your office types: what a traveler owes for a departure (a label, an amount, a kind — deposit, balance or other — and an optional due date) and what your office recorded as received (amount, your own word for the method, date, an optional note, and who recorded it). No card numbers, no bank details, no payment processing: Cordelle has no checkout and moves no money — these are your ledger book’s entries, visible to your office only and never to the traveler’s app. A balance reminder email, triggered by hand in your office, quotes the amount and your own payment instructions. Also: your agency’s own payment instructions text, and — for guests who came through a group leader — which of your contacts brought them, with the leader’s organization name and your free-text notes about the arrangement.
Website inquiries	Only for operators who run a tour catalog site through Cordelle. Each inquiry sent through the site’s form: the sender’s name, email address, phone number if given, party size, their message, which tour or departure they asked about, when it arrived, and the worklist state your office moves it through. Stored for you, emailed to the address you chose for the site (or your account owner’s address), never readable from anything public, and deleted row by row — or exported as CSV — from your dashboard.
Traveler activity	Which version of the trip their phone last synced and when; whether each group message was delivered and seen, with times; their push-notification device token and its platform (iOS, Android or web); their sign-in sessions; and, if they tapped one, their quick status — one of three fixed choices (on my way, running late, sitting this one out) with the time of the tap. There is no free-text field on it; the one place a traveler writes words is the group room, in the next row.
Traveler-authored content	Only for a departure whose group room your office has turned on. Each post: its text (up to 1,000 characters); whether it was marked a question; what it replied to; the time the phone stamped it and the time we received it; the writer’s name as the room shows it (a traveler’s first name and last initial, a guide’s or staff member’s name, an API key’s name), kept as it was when written; the replay key the phone minted; if removed, when and by which role; if a question, when a guide marked it answered. Each report: who reported which post, the reason (one of four), the post’s text as it read when reported, and your office’s decision. Each member’s record: when they accepted the group rules, how far they have read, their notification choice, any quiet period, whether they left or were removed, whether their posting is paused and until when, and which travelers they have hidden from their own view — the last shown to nobody, your office included. A post never enters the published trip bundle, the printed packet or a webhook payload.
Location	A consent record (off, or a session with an expiry time) and location pings: latitude, longitude, how accurate the position was, when the phone captured it, when our server received it, and the kind of ping — manual, automatic, check-in or SOS. SOS pings also record when they were cleared and whether the traveler or the guide cleared them.
Guides	Name; phone number; email address; their own six-character sign-in code; a hash of the PIN they chose, and when they chose it; the enrolment window for choosing one; failed-PIN count and any lock expiry; the date they were archived; which departures they work; their sessions and device tokens.
Your staff	Name; email address; role (owner or admin); a hash of their password; failed-login count and any lock expiry; two-factor state — the sealed TOTP secret, when it was verified, and the last code step used; hashed one-time recovery codes; password-reset and two-factor challenge records; and, for invitations, the invited email address, the role offered, and the invitation’s expiry.
Free-text trip content	Anything personal you type into itinerary items, hotel notes, hotel and flight confirmation numbers, the documents & confirmations list, packing notes or group messages, plus the name recorded against whoever sent each message.
Your company’s own record	Agency name, office phone number, brand colors and logo, plan and billing state, and the Stripe customer and subscription identifiers. No card details: those go straight to Stripe and never reach our servers.

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.
The notes you hold 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. What a traveler chooses to write about themselves in a group room is a different matter, below.
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.

Health facts a traveler volunteers in a group room. A group room is read by every traveler on the departure. A traveler who writes “I’m diabetic, does anyone know a pharmacy” has just put Article 9 data into a record you control, and no consent given at booking covers it. The “manifestly made public” exception in Article 9(2)(e) does not cover a closed group of invited travelers, so you cannot rely on it. Nothing here is legal advice, and you should take your own. What the product does about it: the rules every traveler must accept before writing say, in so many words, “Everyone on your trip can read this. Please don’t post medical details — call your guide.” The app never asks for, prompts for or structures health information in the room. Your guide and your office can remove any message at once, from the phone or the dashboard, and that blanks it on every phone at its next sync. What this asks of you: treat such a message as health data you hold, remove it, and handle what you read under the same condition as the roster’s notes. The rule for travelers is the rule for the product — anything medical, call your guide — and the room is not built to be the exception.

Health facts in your office notes. The guest book’s notes are free text, and the discipline above applies there too. Keep dietary and mobility facts in the roster’s own per-departure fields, where the product treats them as the health data they are and shows them only to the people looking after that trip — and keep medical detail out of free-text notes. “Prefers a ground-floor room” belongs in a note; a diagnosis does not. Notes are office-side only, but they are still a record you control and we host, and a guest’s export includes them word for word.

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.
Two modes, both the traveler’s. A short foreground session, as above; or, from app version 1.3.0, trip sharing: if the traveler chooses it in the app and separately grants the phone’s background permission, an occasional position (about every 15 minutes, and only after meaningful movement) while the app is closed, until the trip’s final day ends in the trip’s own timezone — an end time our server computes and the app cannot extend. The sharing state is always visible on the phone, and one tap stops it. Continuous or high-frequency tracking is not built, and the cadence above is a written ceiling, not a setting.
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.
The public catalog site is a whitelist. Where an operator switches on their tour catalog site, its pages are built by a serializer that names, field by field, the only columns allowed out: tour prose and dates, day titles and summaries, hotel names and cities, packing lists, country basics, and the operator’s own price line and booking link. Traveler records, the guest book, documents, flights, join codes and hotel details beyond name and city cannot reach it — the test suite walks every public payload and fails the build if a stray field appears — and the public reads and the inquiry form are rate-limited per address.
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.

Subprocessor	What it does, and what it holds
Neon	The production database: managed Postgres running on Amazon Web Services infrastructure in the United States. Holds everything in § 4. If you need the exact region named for a contract or a record of processing, see § 11.
Fly.io	Hosts the Cordelle API and the nightly backup job. Processes everything in transit.
Tigris	The backup vault. Object storage provided through Fly.io, holding a full nightly database dump for 14 days in a private bucket with its own credentials. Those dumps contain traveler personal data and join codes in readable form; passwords, session tokens, reset links and two-factor secrets are hashed or sealed and are not usable from a dump.
Cloudflare	Serves this website and the operator dashboard and routes mail sent to [email protected]. Sees requests in transit, and its cookieless Web Analytics counts page views on both sites, join-code pages included — page URL, referrer and coarse device facts, no cookie, no identifier that follows a person.
Stripe	Subscription billing for your company: your billing contact and payment details. Card numbers go directly to Stripe and never reach us. No traveler data.
Resend	Sends our email — traveler join codes, staff invitations, password resets. Receives the recipient’s address and the message.
Expo	Delivers push notifications, handing them to Apple and Google for the device, and serves over-the-air app updates. Receives device push tokens and the notification text.
Apple, Google	The push networks behind Expo, and the app stores the apps are installed from.
AeroDataBox	Live flight status on Pro and trial accounts. Receives each group flight’s number and date and a web address to post updates to. Nothing about any traveler goes to it.
Google (websites only)	Analytics and ads-conversion measurement on our marketing site and the operator dashboard, and Google Fonts on the operator dashboard only (cordelle.io serves its own typefaces). Nothing is loaded from Google Analytics or Google Ads until the person using the site accepts a cookie banner. That is true on cordelle.io and on the operator dashboard alike; the dashboard carries its own banner, shown on every screen including sign-in, and the answer is stored per address, so your staff are asked there separately. None of it runs inside the traveler app, and the join-code pages are excluded entirely. See the Privacy notice.
Anthropic	Only if AI tour import is switched on for your account. It receives the tour document you paste in — an itinerary or brochure — and returns a structured draft. It is never sent a roster, and the feature does nothing at all unless it is enabled.

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, and your plan runs to the end of the period you have already paid for — a month, or a year on an annual plan. Cordelle does not refund prepaid fees (§ 7 of the Terms): on an annual plan the unused months are not refunded, and the change takes effect on the date in the notice whether or not you have canceled. That is why the notice period is 30 days rather than the shortest one we could get away with — on a monthly plan 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, group room, location pings, push tokens and published bundles with it. Both are immediate and permanent in the live database.
Erasure of a guest-book record: deleting a contact removes the person’s cross-season record and their notes with it, at once; their roster rows on past departures are unlinked, never deleted, so your trip history stays whole. Inquiries delete row by row from the inbox.
Erasure of a single group message: the traveler deletes their own in the app; your office removes any from the departure’s Group tab; a guide removes any from their phone. Each blanks the text on every phone at its next sync and leaves a “removed” marker in its place. Deleting a traveler blanks every message of theirs first, then removes the record. The text survives only inside a report already made about it, for your office, until the room is deleted (§ 13).
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 narrower than it was. The guest book exports itself: the dashboard downloads every contact, or one person’s record — their trips and your notes included — as CSV, and the inquiry inbox exports the same way, so most of a subject-access answer for a guest is one download. A guest’s money records are not in that CSV, and a traveler’s roster record and trip content still have no export button. For those, or for your whole account’s data, 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.
Quick statuses: shown to guides and office staff for 12 hours after the tap, and deleted from the live database by the daily sweep once more than 30 days old.
Group room: read-only for travelers and guides from the day after the departure’s grace day; its messages, reports and memberships are deleted from the live database by the daily sweep once 30 days have passed since the departure’s end date. This is the one part of your content that expires on its own.
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.

Guest-book notes, office tasks, checklist records and money records follow the same rule as the guest book itself: kept while your account lives, deleted when you delete them. Deleting a guest’s record deletes their notes with it and detaches (never deletes) your office’s tasks; deleting a traveler deletes their checklist records but keeps the money records (unlinked from the roster row, keeping the traveler’s name as typed); deleting a departure deletes its checklist records and money records; each note, task, charge and payment can also be deleted on its own. A guest’s CSV export includes their notes, so most of a subject-access answer is one download (§ 12 covers the rest). Website inquiries follow the same rule: kept while your account lives, deleted row by row from the dashboard’s inbox the moment your office deletes them.

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.