Guide for agencies · Data security

Travel Agency and Tour Operator Security: Protecting Data, Payments, and GDS Access

Travel agencies and tour operators handle personal information at every stage of a trip. This guide explains how to map the data you hold, secure access, protect payment information, review technology partners, and prepare for a security incident.

By mTripPublished
Protect the data behind every trip
TravelersTraveler and passport information
PaymentsPayments and supplier records
TripsItineraries and travel documents
AccessBooking and cloud systems

Where risk starts

Where security problems start in a travel agency

Most security incidents begin with a normal travel task. A new client wants an urgent group booking. A supplier sends a payment request. A message says your GDS login has expired. A former contractor still has access to a system that your team relies on every day.

These situations create pressure because your team wants to help the traveler and protect the booking. That pressure can make it easy to skip a verification step or enter credentials into the wrong page.

Travel data also tells a detailed story about a person. It can show where someone plans to go, when they will be away, who they travel with, and how to contact them. A family itinerary, a corporate travel booking, and a group tour file can each contain different types of personal information.

Exposure

Five points of exposure to look for in a booking

Follow one booking through your workflow

  • A new traveler or company asks for a high volume of tickets before you can verify who they represent.
  • An email links to a login page that looks like your GDS, payment provider, or supplier portal.
  • Passport copies, payment details, or current itineraries sit in inboxes, spreadsheets, or shared folders.
  • A branch, independent agent, vendor, or former employee still has access to booking systems.
  • A ransomware incident blocks the itinerary and contact data your team needs to support travelers.

Each problem affects more than privacy. It can create unauthorized ticketing, chargebacks, debit memos, client notifications, lost time, and disruption during an active trip.

A travel-specific threat

Fake traveler requests and GDS account takeovers

Travel agencies face a second type of security incident alongside data breaches: fraudsters can use a fake customer request or a stolen GDS login to make the agency issue tickets under its own account.

In 2026, the Airlines Reporting Corporation reported increased activity involving unauthorized GDS access. ARC described two routes into an agency: a fraudster impersonates a legitimate agency to obtain GDS access, or a phishing message captures an agent’s credentials. After access is obtained, the fraudster can issue tickets through the agency’s account without authorization.

ARC also reported fake Sabre Agency Workspace and training sites designed to steal agent credentials. The pages looked like trusted travel portals, but the links led to look-alike domains. A fake GDS page can give an attacker a valid login without any breach of the GDS provider itself.

Fake booking requests: urgency hides weak verification

ARC has warned agencies about fake corporate and group travel requests involving immediate departures, medical emergencies, incomplete payment details, unfamiliar routes, and requests to bypass normal checks.

Pause when: a new client wants a high volume of tickets before you can verify the company, travelers, itinerary, and payment.

Fake GDS sites: a familiar logo can hide a stolen login page

Phishing messages may claim that a GDS account has expired, a reservation needs verification, or a workspace requires an urgent re-authentication. The link can lead to a fake Sabre or agency portal.

Use: a trusted bookmark or a manually typed vendor address. Do not sign in through an unexpected email link.

Third-party access: your own system may not be the entry point

ARC reported a case where unauthorized tickets were issued after a third-party branch was breached, even though the agency’s own ticketing system was not directly compromised.

Review: access held by branches, contractors, independent agents, vendors, and former staff. Remove it when the relationship or role ends.

Before issuing a ticket, your team needs to answer two questions: “Is this request from a real customer?” and “Is this login reaching the real GDS?” Build both checks into the workflow before anyone issues a ticket.

01

Map the data your agency handles

You cannot protect information you cannot locate. Start with a simple data map. Follow a booking from the first inquiry to post-trip support and record each system, person, and supplier that touches it.

Questions

Ask these questions for every type of data

  • What information do we collect?
  • Why do we need it?
  • Where do we store it?
  • Who can view, change, download, or share it?
  • Which suppliers or platforms receive it?
  • When should we delete it?

Systems

Include the systems your team uses every day

  • Email, CRM, and GDS
  • Mid-office platform and accounting software
  • Payment provider, shared drives, and spreadsheets
  • Itinerary software, mobile apps, and supplier portals

Then group information by risk. Public destination content needs a different level of protection from passport details, payment information, or a corporate traveler’s emergency contact. Give the most restricted data the fewest access points.

Review what your team keeps. Old passport copies, duplicate spreadsheets, downloaded booking files, and email attachments create extra exposure. Set a retention period for each category and delete information when you no longer need it, while following the legal and contractual rules that apply to your market.

02

Secure accounts and access

Compromised accounts give attackers a direct path into booking data, email conversations, payment workflows, and client files. Protect each account with controls your team can apply consistently.

Require multi-factor authentication

Turn on multi-factor authentication for email, CRM, cloud storage, booking systems, payment tools, administrator accounts, and any platform that supports it. A stolen password should not provide the only key to a business system.

Use phishing-resistant authentication where a provider offers it. If that option does not exist, use an authenticator app or security key instead of relying on text messages alone.

Give each person an individual account

Do not share logins for a generic agency account. Individual accounts let you see who accessed a record, change permissions when someone changes roles, and remove access when an employee or contractor leaves.

Give people the access they need for their job. A sales coordinator may need to view traveler details, while an administrator may need to manage settings.

Use a password manager

A password manager helps your team create unique passwords and share access through controlled vaults instead of email or spreadsheets. Never reuse a password between your email account and a supplier or booking platform.

Review access at least twice a year and after every role change. Remove former employees, old contractors, unused integrations, and accounts that no longer support an active process.

GDS

Protect GDS and ticketing access

  • Enable multi-factor authentication wherever the GDS or connected service supports it.
  • Verify new corporate clients through contact details found independently, not only through the email request.
  • Review ticket activity frequently, especially near-term departures, unusual routes, one-way bookings, new traveler profiles, and sudden increases in volume.
  • Revoke access when an employee, contractor, branch, or vendor leaves the relationship.
  • If someone enters credentials into a suspicious page, reset the password, re-register MFA, scan the device, and contact the GDS and ARC immediately.

03

Train your team to spot real-world attacks

Most travel agencies receive messages that look familiar: a supplier invoice, a flight-change request, a hotel payment link, or an urgent message from an executive. Attackers use those familiar situations to create pressure.

Pause

Train your team to pause when a message asks for

  • A password, one-time code, or payment detail
  • A change to supplier bank information
  • An urgent transfer or refund
  • A passport copy or client list
  • A link to sign in to a booking or payment system

Verify sensitive requests through a known channel. Call the supplier using a phone number already in your records rather than the number in the message. Report suspicious messages quickly so your team can warn other colleagues.

CISA recommends that small and medium-sized businesses make phishing awareness, strong passwords, multi-factor authentication, and software updates part of their basic security practice. Those controls give a travel agency a useful starting point without requiring a large technical team.

04

Protect devices and business software

Your team can access travel data from laptops, phones, tablets, and home networks. Set a minimum standard for every device that connects to company systems.

Standard

A minimum standard for every device

  • Install operating system and application updates promptly.
  • Turn on full-disk encryption for laptops and mobile devices.
  • Use automatic screen locking after a short period of inactivity.
  • Keep malware protection active and restrict administrator privileges.
  • Separate business accounts from personal accounts where possible.
  • Avoid downloading client files to unmanaged personal devices.
  • Remove access from lost devices and wipe them when the technology allows it.

Review every integration connected to your main systems. An old connector or unused automation can retain access long after the original project ends. Keep a list of integrations, their purpose, their owner, and the data they can read or send.

05

Handle payment information with care

Payment details deserve their own process. Do not place full card numbers or security codes in email, chat, spreadsheets, itinerary documents, screenshots, or shared folders.

Provider

Use hosted payment forms or tokenization

When a provider stores the card data, confirm what your agency still needs to do and which PCI DSS obligations apply. The PCI Security Standards Council explains that PCI DSS applies to entities that store, process, or transmit payment account data, as well as systems that can affect its security.

Staff rule

Give staff a clear rule for payment requests

A client should know which payment page to use, and your team should know how to identify a legitimate payment message. Keep card data out of the itinerary workflow whenever the process allows it.

06

Check the security of your technology partners

An agency can follow good internal practices and still inherit risk from a supplier. Review the systems that handle traveler information, payment data, documents, and location data.

Ask each important technology provider:

Question What you want to understand
How do you encrypt data? Protection during transmission and while the provider stores it
How do users sign in? MFA, SSO, password rules, and account lockout controls
How do you limit staff access? Roles, least privilege, access reviews, and administrator controls
How do you recover from an incident? Backup frequency, recovery points, restore testing, and business continuity
How do you test the service? Independent testing, vulnerability management, and secure release practices
Where do you host and process data? Regions, subprocessors, cross-border transfers, and contractual safeguards
What happens at the end of the contract? Data export, deletion, retention, and confirmation of removal
How will you notify customers? Incident contacts, response process, and notification commitments

Ask for the provider’s security documentation, privacy terms, data processing agreement, and subprocessor list. Treat certifications as one part of your review. You still need to understand how the provider operates the specific service your agency will use.

07

Back up your data and test recovery

Backups help you recover from ransomware, accidental deletion, system failure, and other incidents. They only help if they cover the information your team needs and if you can restore it.

Identify your critical systems

For a travel agency, those systems may include booking records, current itineraries, traveler contact details, supplier confirmations, financial records, and support history.

Set a recovery target

Decide how much recent data you could afford to lose and how quickly your team must resume operations. Keep backups protected from everyday user accounts, and make sure an attacker cannot delete every copy with one compromised login.

Test a restore every year

Test a restore at least once a year. Ask someone to open the recovered files and confirm that the team could use them during a real disruption. Record the result and fix gaps while the exercise remains fresh.

08

Prepare an incident response plan

An incident plan reduces confusion when your team has limited information and time. Keep the first version short enough for everyone to use. Write down:

Plan

What your incident plan should cover

  • Who leads the response and who can make urgent decisions.
  • How staff report a suspicious email, lost device, or compromised account.
  • Which technology providers, insurers, legal advisers, and authorities to contact.
  • How to isolate a device or account without destroying evidence.
  • How to continue supporting travelers if booking or communication systems go offline.
  • How to assess affected data and communicate with clients under applicable rules.
  • How to restore systems and review the cause after the incident.

Run a short exercise once a year. Give the team a realistic scenario, such as a compromised mailbox that contains passport copies or a ransomware attack that blocks access to current itineraries. Check whether everyone knows who to call, where the backup sits, and how to support travelers while systems recover.

Legal notification requirements depend on the countries, data types, contracts, and people involved. Ask qualified legal advisers to confirm the rules that apply to your business. Your incident plan should give them the information they need quickly.

09

Build a security routine

Security improves when your team treats it as an operating habit. Add a small set of checks to your existing management rhythm.

Timing Review
Every day Report suspicious messages, follow payment procedures, and apply urgent security updates
Every month Review alerts, new users, former users, integrations, and unusual access
Every quarter Delete stale exports, review important suppliers, and refresh staff guidance
Twice a year Review user permissions and administrator accounts
Every year Test backups, exercise the incident plan, and review your data map

Keep a record of the owner and date for each check. A simple register gives your team a clear way to show what it reviewed and what it changed.

mTrip

How mTrip approaches data security

When you evaluate an itinerary platform or branded travel app, ask the provider to explain its security controls in the same practical terms. mTrip publishes its security practices for agencies, tour operators, and TMCs.

Hosted on Amazon Web Services

The platform runs on Amazon Web Services. European customers are hosted in Frankfurt, Germany, with uploaded files stored in London, United Kingdom. Other customers are hosted in North Virginia, United States.

Encrypted in transit and at rest

mTrip states that platform and API traffic uses TLS 1.2 or higher. It encrypts databases, file storage, and backups at rest with AES-256, and the application encrypts sensitive traveler fields such as email addresses, phone numbers, dates of birth, and booking references.

Daily backups, tested every year

The platform uses daily encrypted backups with seven-day point-in-time recovery. mTrip copies backups to a second AWS region, protects them against deletion, and tests a restore at least once a year.

Controlled access and independent testing

mTrip describes controlled access, multi-factor authentication, administrative logging, continuous threat detection, and independent testing of the platform and mobile apps at least once a year.

Clients can request security documents through the mTrip Trust Center. Review the current details with your own requirements before selecting any technology provider.

Security review

Questions to ask every travel technology provider

Ask where data is hosted, how access is controlled, how backups are tested, how incidents are reported, and what happens to your data when the contract ends.

Review mTrip security practices

Start here

Start with the controls that reduce the most risk

You can make meaningful progress with a short first project:

Action plan

Six controls for a first project

  • Map the data in your booking and itinerary workflow.
  • Turn on multi-factor authentication for every important account.
  • Remove old users, shared logins, and unused integrations.
  • Keep full payment card data out of email, documents, and spreadsheets.
  • Confirm that backups work by testing a restore.
  • Write an incident plan and practice it with your team.

Data security protects the traveler experience your agency works hard to create. It also gives your team a safer way to manage bookings, documents, and disruption support as trip volume grows.

For more guidance, read mTrip’s travel document best practices and duty of care software checklist.

The wider travel sector

What other travel companies have learned from attacks

These examples involve larger travel companies, but the underlying problems can appear in an agency or tour operator’s workflow too: old systems, stolen credentials, payment data, supplier access, and weak recovery plans.

Hotel group

Marriott and the Starwood reservation database

Marriott announced in November 2018 that an unauthorized party had accessed the Starwood network since 2014. The database held information on up to approximately 500 million guests. For about 327 million guests, the data included combinations of names, addresses, phone numbers, email addresses, passport numbers, loyalty account details, dates of birth, and arrival and departure information.

Relevant lesson: Review inherited systems, old integrations, and acquired databases. Keep a current data map, remove data you no longer need, and monitor access to reservation stores.

Read Marriott’s incident announcement

Airline

British Airways and website payment data

British Airways reported a 2018 incident involving customer information submitted through its website. The UK Information Commissioner’s Office later recorded that data belonging to about 429,000 people was involved, including login, payment card, travel booking, name, and address information.

Relevant lesson: Protect public booking forms, administrator accounts, payment workflows, and connected services. Keep payment data out of systems that do not need to hold it, and monitor unusual activity.

Read the ICO’s British Airways record

Airline

easyJet and a large customer database

easyJet disclosed a 2020 data breach that affected about 9 million customers. The incident also involved the card details of 2,208 customers. The scale shows how quickly one compromised system can become a customer communication, legal, and support problem.

Relevant lesson: Know which data categories you hold, who needs access, and how you will contact affected clients. Your incident plan should cover customer support as well as technical recovery.

Read the ICO’s easyJet record

Travel management company

CWT and ransomware disruption

In 2020, travel management company CWT suffered a ransomware attack. Reuters reported that the attackers claimed to have copied 30,000 files and that CWT paid a ransom during the response. The incident shows how quickly a systems outage can affect a company whose teams manage active trips and traveler support.

Relevant lesson: Backups and recovery procedures deserve the same attention as prevention. Test whether your team can access essential trip information and support travelers if your main systems go offline.

Read the Reuters report

Review your travel data workflow with mTrip

Discuss itinerary data, travel documents, branded mobile apps, and security requirements with the mTrip team. Read the mTrip security page first if you are starting a vendor review.

Request a Demo