Copy-ready breach-notification & customer FAQ pack for tour operators (holding messages, confirmed-breach, resolution, 0–72h comms timeline and RACI)

The worst time to write a breach notification is while you're having one. Your acquirer is calling, forensics wants to image a server, legal is asking what you can and can't say, and your inbox is filling with "is my card safe?" emails from customers who already saw something on Reddit. Meanwhile your refund queue is backing up because your gateway is in a weird state and nobody knows if you're allowed to run cards right now.

This post gives you the actual language — holding statements, confirmed-breach notices, resolution messages, and a booking-specific FAQ — plus a 0–72 hour timeline and a RACI so there's no debate about who hits send. If you haven't read it yet, the companion piece on immediate PII, payments and incident-response changes after the late-August U.S. cyberattacks covers the prevention and detection side. This one is purely about communications once something has already happened.

One warning before the templates: nothing here is legal advice. Your outside counsel and your forensics lead decide what gets confirmed and when. These are starting points that keep you from drafting from scratch at 2 a.m.

The first mistake operators make in hour zero

Almost every botched breach response shares the same opening error: someone says too much, too early, on a public channel. A support agent replies to an angry tweet with "yes we had a data breach, we're looking into it" before forensics has even confirmed what was accessed. Now you've made a public admission lawyers can't walk back, and your cyber insurer is annoyed because you may have just complicated coverage.

The opposite failure is just as common — total silence for 48 hours while customers panic, chargebacks pile up, and the story writes itself without you. In practice, the right move in the first hours is almost always a holding statement: acknowledge that you're investigating a potential security issue, tell people what to do right now, and promise a follow-up by a specific time. You confirm nothing about scope until you actually know.

What tends to go sideways with small operators is that nobody decided in advance who is even allowed to approve a public message. So three people say three different things across email, Instagram, and the phone line — and the inconsistency becomes the story.

The 0–72 hour communications timeline

Here's the sequence that works. Times are from the moment your incident is declared internally, not from when the attack started.

Two things people consistently underestimate. First, the 72-hour mark matters because several U.S. state laws and card-brand rules start their clocks early — you want the regulatory notification language drafted before you hit the deadline, not scrambled together at hour 70. Second, "pause risky payment flows" in the 2–6h row is where operators lose the most money if they overreact. Shutting off your entire gateway kills new bookings. Usually you only need to pause the specific compromised path — say, a vulnerable checkout page — while keeping your main booking flow alive. Decide that with your acquirer, not in a panic.

Visual: a simple workflow of the 0–72h communications and approvals.

Use this as a quick reference for who approves what at each timeline step.

RACI: who sends what, and when

The single thing that prevents chaos is a one-page RACI agreed before an incident. Roles, not names, because the person on call changes.

1. 1
   Incident Lead (usually ops director or founder) — Accountable for the whole response. Approves timeline decisions, owns the bridge call.
2. 2
   Legal / Counsel — Accountable for what gets confirmed publicly. Every confirmed-breach or regulatory line goes through them. No exceptions.
3. 3
   Comms / Support Lead — Responsible for drafting and sending customer messages across email, SMS, IVR, banner, social.
4. 4
   Finance / Payments — Responsible for acquirer notification, chargeback monitoring, refund/voucher handling, and the decision on which payment flows pause.
5. 5
   Forensics (internal or vendor) — Consulted on scope. Nothing about "what was accessed" is confirmed without them.
6. 6
   Insurer / Breach Coach — Consulted and Informed early. Many policies require notice within a tight window or coverage gets contested.
7. 7
   Suppliers & key agents — Informed once customer messaging is out, so they don't freelance their own version.

The common mistake is treating Legal as Consulted instead of Accountable for public confirmations. In a payment breach, the difference between "a security incident affecting some accounts" and "a breach exposing card numbers" is the difference between a manageable event and a class-action magnet. Legal owns that line.

Copy-ready holding statements (hours 2–12)

These say we're on it, here's what to do now, more soon — and nothing about confirmed scope.

Website banner (keep under ~160 characters so it renders on mobile):

> We're investigating a potential security issue that may affect some accounts. Your bookings are safe. We'll update this page by [TIME]. Questions: [SUPPORT LINK].

IVR / phone greeting (spoken, keep to ~15 seconds):

> Thanks for calling [Operator]. We're currently investigating a potential security issue and are working with security experts. Your trip and booking are not affected. For updates, please visit [URL]. We appreciate your patience.

SMS holding (160-char limit, so no scope claims fit anyway):

> [Operator]: We're looking into a possible security issue. Your bookings are safe. No action needed yet. Updates: [SHORT URL]. We'll text again if anything changes.

Email holding — subject line options (keep under ~45 characters so they don't truncate in Gmail mobile):

1. 1
   "An update on your account security"
2. 2
   "Important

   a security issue we're investigating"

3. 3
   "Protecting your [Operator] account"

Email body:

> Hi [First name], > > We're writing to let you know we've identified a potential security issue and have launched a full investigation with outside security experts. We're sharing this early because we'd rather you hear it from us. > > Right now, your bookings and trips are not affected. You don't need to cancel or rebook anything. > > As a precaution, we recommend you stay alert for any suspicious emails or messages, and don't share payment details in response to unexpected requests. We will never ask for your full card number by email or text. > > We expect to share a fuller update by [DATE/TIME]. If you have questions in the meantime, reach us at [SUPPORT CHANNEL]. > > — The [Operator] Team

Notice what's missing: the words "breach," "hacked," "stolen," and anything about card data. That's deliberate until forensics confirms scope.

Confirmed-breach notice (hours 24–48, only after counsel sign-off)

Send this only when forensics has confirmed what was accessed and Legal approves the specific scope language. This is also where state-law and PCI content gets bolted on.

Email subject lines (under ~45 chars):

1. 1
   "Important security update about your information"
2. 2
   "Action recommended

   your [Operator] account"

Body:

> Hi [First name], > > We're following up on the security issue we told you about on [date]. Our investigation, conducted with outside forensic experts, has confirmed that an unauthorized party accessed certain information between [date range]. > > What was involved: [select only confirmed items — e.g., name, email, booking reference, and in some cases the last four digits and expiry of a payment card]. [If full card data: state it plainly.] [If NOT involved, say so: "Your full card number and CVV were not accessed."] > > What we've done: We contained the issue, engaged forensic specialists, notified our payment processor, and reported to the appropriate authorities. > > What we recommend you do: > - Monitor your card and bank statements for unfamiliar charges. > - If you see anything unusual, contact your bank and dispute the charge. > - Be cautious of anyone contacting you claiming to be from [Operator] and asking for payment details. > > [If offering remediation:] We're providing [free credit monitoring / identity protection] for [X months]. Enroll here: [LINK]. > > We're sorry this happened and we take it seriously. For questions, contact [DEDICATED LINE/EMAIL].

Regulatory snippet — U.S. state-law prompt (counsel fills jurisdiction specifics):

> This notice is provided in accordance with applicable state data breach notification laws. Residents of [state] may be entitled to [place a fraud alert / security freeze] at no cost. You may contact the three major credit bureaus and, where applicable, your state Attorney General's office.

PCI / acquirer notice line (for payment data cases — goes to your acquirer, not customers):

> Per our merchant agreement and PCI DSS incident obligations, we are notifying [Acquirer] of a confirmed cardholder data compromise. Affected account range: [tokens/BINs as advised]. Forensic investigator engaged: [PFI firm, if required]. We request guidance on card-brand notification and affected-card reporting.

Resolution / next-steps notice (hours 48–72)

Once the hole is closed and remediation is live:

> Hi [First name], > > An update: the security issue we contacted you about has been fully contained, and we've added [specific safeguards — e.g., additional monitoring, strengthened access controls, a re-secured checkout]. Working with our payment processor, we've also [reissued affected cards / confirmed no further unauthorized access]. > > Your bookings remain intact and no trips were disrupted. If you enrolled in [monitoring], it's now active. If you still have questions about a specific charge or refund, reply here and we'll handle it directly. > > Thank you for your patience. We know trust is earned, and we're committed to keeping yours.

Customer FAQ tailored to bookings, payments, vouchers and refunds

Generic breach packs skip this section entirely, and that's exactly the problem. Travel customers don't ask abstract privacy questions — they ask "is my July trip cancelled" and "do I get my deposit back." Publish this alongside the banner from day one.

Will my booking be cancelled or changed? No. The security issue did not affect trip operations. All confirmed bookings, dates, and itineraries stand.

Was my payment card stolen? [Only confirmed language.] Based on our investigation, [full card numbers were not accessed / the following card details were involved: last four and expiry]. We recommend monitoring your statement regardless.

Should I cancel my card? That's your call and your bank's. If your card was involved, your bank may reissue it automatically. A reissued card does not cancel your booking — we'll update the payment on file with no action needed from you.

I paid a deposit / have a voucher — is it still valid? Yes. Deposits and vouchers are tracked against your booking reference, which is unaffected. Your balance and any credits are intact.

I see a charge I don't recognize. What do I do? Contact your bank to dispute it, then let us know at [email]. If it's a legitimate [Operator] charge you forgot about, we'll help identify it so you don't file an unnecessary chargeback.

Can I get a refund because of this? The incident doesn't change our refund policy, but if you're uncomfortable traveling we'll work with you on [options per your policy]. Reach out and we'll find something fair.

Why didn't you tell me sooner? We shared a holding notice as soon as we identified a potential issue, and this fuller update once our investigation confirmed the facts. We chose accuracy over speed on the details.

A note on chargebacks — the hidden cost most operators miss

There's a pattern that quietly drains money after a payment breach: customers who read the news panic and file chargebacks on legitimate, fulfilled bookings instead of contacting you first. Each one costs the disputed amount plus a fee, and a cluster of them can trip your acquirer's chargeback monitoring thresholds — which is its own slow, expensive problem to dig out of.

The FAQ question "I see a charge I don't recognize" exists specifically to route people to you before they dispute. Operators who put a visible, fast support path in their breach comms typically see far fewer breach-triggered chargebacks than those who go quiet. A mid-sized operator running a few thousand bookings a season can see the difference between a dozen breach-related disputes and fifty-plus, just based on whether the messaging gave people a human to contact instead of a wall of silence.

That gap isn't about the severity of the incident. It's about whether customers had somewhere to go.

Translation and accessibility notes

Easy to forget under pressure, costly to skip.

1. 1
   Keep the banner screen-reader friendly — real text, not an image of text, with a clear link.
2. 2
   IVR should offer a language option before the security message if your phone line already does.
3. 3
   Avoid jargon in translation. "Unauthorized access to personal information" translates cleanly; "data exfiltration event" does not and will confuse people in every language.
4. 4
   Caption any video statement if your founder records one. Some operators do this; if you do, captions are non-negotiable.

None of this takes long to set up in advance. All of it takes much longer to fix after you've already sent the wrong version to the wrong audience.

Preparing this before you need it

The entire value of this pack is that it's drafted before an incident. Here's the pre-work checklist:

1. 1
   [ ] One-page RACI printed and shared with ops, finance, support, and counsel's contact
2. 2
   [ ] Holding statements saved as fill-in-the-blank drafts (email, SMS, IVR, banner)
3. 3
   [ ] Confirmed-breach and resolution templates reviewed by your counsel in advance
4. 4
   [ ] Booking/payment/voucher FAQ written and translated into your top languages
5. 5
   [ ] Acquirer's incident-reporting contact and process documented and findable
6. 6
   [ ] Cyber insurer's notification window and breach-coach hotline saved
7. 7
   [ ] A dedicated support inbox/line you can stand up fast for breach questions
8. 8
   [ ] A test run

   tabletop the first 6 hours once a year with the people who'd actually be on the call

The operators who come through a breach with their bookings and reputation intact aren't the ones with the fanciest security stack. They're the ones who, at hour two, already knew who approves the banner, what it says, and which payment flow to pause without killing new sales. Everything in this pack exists to buy you that clarity on the worst day — so the response is a process you follow, not a crisis you improvise.

The operators who come through a breach with their bookings and reputation intact aren't the ones with the fanciest security stack. They're the ones who, at hour two, already knew who approves the banner, what it says, and which payment flow to pause without killing new sales. Everything in this pack exists to buy you that clarity on the worst day — so the response is a process you follow, not a crisis you improvise.