What is PCI DSS and why does it matter to travel agencies?
PCI DSS is the Payment Card Industry Data Security Standard, a set of technical and operational requirements for any organisation that stores, processes or transmits payment card data. It is maintained by the PCI Security Standards Council (PCI SSC). The card brands and acquiring banks enforce it through their merchant and service-provider agreements.
It matters to travel agencies because nearly every booking involves a card. Customers pay for flights, hotels, packages and transfers, and agencies pay suppliers with corporate or virtual cards. If any of that card data touches your website, staff, phones, inboxes or booking systems, those systems are in scope. For IATA-accredited agents there is a further reason: IATA says its accredited travel agents need to become PCI DSS compliant, because airlines asked for the BSP card sales channel to be compliant.
The standard is organised into 12 principal requirements. They cover network security, secure configuration, protecting stored data, encryption in transit, malware, secure software, access control, authentication, physical security, logging, testing and security policy.
Why are travel payments harder to secure?
Travel payments are harder to secure because one booking can pass card data between several companies and channels. A retailer usually takes a card once, at a checkout it controls. A travel booking often does not work that way.
- Several merchants per trip. The airline may be the merchant of record for the ticket, a hotel for the room and the agency for its service fee.
- Card details travel with the booking. Form-of-payment data can sit in a PNR inside a GDS, and be visible to anyone with access to that record.
- Assisted sales are common. Phone, walk-in and messaging bookings mean people, not just software, handle card numbers.
- Payments happen later. Deposits, balance payments, guarantees and changes tempt teams to keep card details "for later".
- Suppliers are paid by card too. Virtual card numbers sent to hotels and ground handlers are still card data.
- Long supply chains. Booking engines, payment gateways, consolidators, bed banks and mid-office tools each carry part of the risk.
Where are the most common payment security gaps in travel?
The most common gaps sit in the workflows around payment technology, not in the payment gateway itself. The table below lists where card data typically leaks in travel businesses and the usual way to close each gap.
| Area | Typical gap | How agencies usually close it |
|---|---|---|
| Booking website and checkout | Card form on your own page, or third-party scripts that can change a hosted form | PSP-hosted page or fields, script inventory and tamper detection (req. 6.4.3 and 11.6.1) |
| GDS, PNRs and queues | Full card numbers in form-of-payment fields, remarks, queues and printed itineraries | Masking, restricted access, retention rules, and moving payment capture out of the PNR |
| Call centre and sales desk | Agents hear, write down or key card details; recordings capture the security code | Pay-by-link, IVR or DTMF masking, clean-desk rules, recordings that never keep the code |
| Email, chat and fax | Customers and suppliers send card numbers in plain text; they persist in inboxes and backups | Policy that card data is never requested this way, detection, secure purge, hosted alternatives |
| Back office and reporting | Card numbers in exports, spreadsheets, refund files and reconciliation reports | Tokens and masked PANs only, documented retention, access reviews |
| Supplier and virtual card payments | Virtual card numbers emailed to hotels or stored in booking notes | Treat them as card data: secure delivery channels, limited access, short retention |
| Shared accounts and remote access | Generic logins to GDS, payment portals and admin tools; no MFA | Unique IDs, MFA for all access into the CDE (req. 8.4.2), joiner-mover-leaver reviews |
What applies in 2026 under PCI DSS v4.0.1?
In 2026 every PCI DSS v4.0.1 requirement applies, including the ones that were introduced as future-dated. The PCI SSC published v4.0.1 on 11 June 2024 as a limited revision with no new or deleted requirements, and retired v4.0 on 31 December 2024. The 51 future-dated requirements were best practice until 31 March 2025. After that date they must be fully considered in every assessment.
Several of those requirements land squarely on travel workflows:
- Payment-page scripts (6.4.3) and tamper detection (11.6.1). Scripts on payment pages must be authorised, integrity-checked and inventoried, and unauthorised changes to the page must be detected. This targets e-skimming on booking checkouts.
- MFA for all access into the CDE (8.4.2). Multi-factor authentication now applies to all access into the cardholder data environment, not only remote or administrator access.
- Anti-phishing (5.4.1) and awareness training (12.6.3.1). Controls and training must address phishing and social engineering, a frequent route into agency inboxes and GDS accounts.
- Automated log review (10.4.1.1). Audit logs must be reviewed with automated mechanisms.
- Targeted risk analysis (12.3.1). Where the standard lets you set a frequency, you must justify it with a documented risk analysis.
The PCI SSC also revised SAQ A for v4.0.1. It removed requirements 6.4.3, 11.6.1 and 12.3.1 from that questionnaire and added an eligibility criterion instead. The merchant must confirm its site is not susceptible to script attacks that could affect its e-commerce systems. PCI SSC FAQ 1588 explains ways to meet it. The requirements themselves remain in the standard.
How do you define and reduce your PCI DSS scope?
You define scope by finding every system, person and process that stores, processes or transmits card data, plus anything connected to or able to affect them. Together these form the cardholder data environment (CDE). Requirement 12.5.2 asks merchants to document and confirm that scope at least once every 12 months.
A practical way to do it:
- Map every payment channel. Website, app, phone, email, chat, branch terminals, GDS form of payment, supplier payments and refunds.
- Draw the data flow. For each channel, show where card data enters, which systems and people it passes through, where it is stored and where it leaves.
- Find stored data. Search databases, PNR remarks, spreadsheets, shared drives, call recordings and mailboxes for card numbers.
- Remove what you do not need. Every copy you delete or stop collecting shrinks scope.
- Segment what remains. Isolate card-handling systems from the general office network so the rest of the business stays out of scope.
Scope reduction is the single biggest lever for a travel business. The fewer places card data can reach, the fewer controls you must operate and evidence.
What do tokenisation and hosted payment pages actually remove?
Tokenisation and hosted payment pages remove the full card number from your own systems, which can remove those systems from most of PCI DSS. They do not remove the parts of your environment that can still change or redirect the payment flow.
- Hosted payment pages and iframes. The payment provider renders the card form. Your server never receives the card number. Your page that loads the form can still be attacked, which is why script controls and the SAQ A eligibility criterion exist.
- Tokenisation. The provider returns a token that stands in for the card. You can store the token on the booking, use it for later charges or refunds, and show a masked number to staff.
- Pay-by-link and IVR. For phone and messaging bookings, the traveller enters the card on the provider's page or keypad, so agents never hear or type it.
- Third-party integrations. Every supplier API that carries card data, such as a hotel guarantee or an airline payment, needs encryption in transit. Check whether a tokenised form of payment is supported instead.
When you evaluate a B2B travel portal or travel API, ask how it captures payments, whether it tokenises, and what it stores in booking records. Our vendor evaluation checklist includes those questions.
Which security controls matter most for a travel business?
The controls that matter most protect the people and systems that touch card data every day: access, authentication, encryption, patching, monitoring and response. The 12 PCI DSS requirements map onto travel operations as follows.
| Req. | PCI DSS v4.0.1 requirement | What it means in a travel business |
|---|---|---|
| 1 | Install and maintain network security controls | Segment the payment environment from the office, Wi-Fi and booking servers |
| 2 | Apply secure configurations to all system components | Harden servers, terminals and cloud accounts; remove vendor defaults |
| 3 | Protect stored account data | Do not store the security code; mask and protect any PAN you must keep |
| 4 | Protect cardholder data with strong cryptography during transmission | TLS on every link that carries card data, including supplier APIs |
| 5 | Protect systems and networks from malicious software | Anti-malware and anti-phishing controls for agent workstations |
| 6 | Develop and maintain secure systems and software | Patch booking engines; manage payment-page scripts |
| 7 | Restrict access by business need to know | Only roles that need card data can see it in GDS or back office |
| 8 | Identify users and authenticate access | Unique logins and MFA for anyone reaching the CDE |
| 9 | Restrict physical access to cardholder data | Secure terminals, paper forms and branch devices |
| 10 | Log and monitor all access | Logs for payment systems, reviewed with automated tools |
| 11 | Test security of systems and networks regularly | ASV scans, penetration tests, payment-page change detection |
| 12 | Support information security with policies and programmes | Policies, training, risk analysis, vendor management, incident response |
Access control and MFA
Give every person a unique login to the GDS, payment portal and back office. Grant access to card data only to roles that need it. Turn on MFA for all access into the CDE, and remove access the day someone leaves.
Encryption and stored data
Never keep the card security code after authorisation, even encrypted. If you must store a card number, make it unreadable with strong cryptography, mask it on screen and keep it only as long as your retention policy allows.
Vulnerability management
Patch booking engines, CMS plugins, payment modules and workstations on a defined schedule. Run the scans and penetration tests that apply to your environment, including quarterly external scans by an Approved Scanning Vendor where required.
Logging and monitoring
Log access to payment systems and card data, protect the logs, and review them with automated tools so suspicious activity is spotted quickly.
Incident response
Requirement 12.10 expects a tested incident response plan. For travel, it should cover a compromised agent account, skimming code on a checkout, and card numbers found in an inbox or shared drive. It should also say who informs the acquirer and when.
Who is responsible when a GDS, payment provider or booking platform is involved?
Responsibility is shared, and you remain accountable for the parts you control. Requirement 12.8 asks you to keep a list of third-party service providers (TPSPs), have written agreements, do due diligence, monitor their compliance status at least once a year, and record which requirements each provider covers. Requirement 12.9 asks service providers to acknowledge their responsibilities in writing and support their customers' compliance requests.
In travel, typical TPSPs include payment gateways, GDSs, consolidators, booking engines, hosting and cloud providers, call-recording and IVR vendors, and managed IT providers. For each one, ask for a current Attestation of Compliance and a responsibility matrix. A consolidator or GDS handling a ticket payment securely does not cover your own staff writing card numbers in a remark field.
If you are a travel technology provider, the roles reverse. Agencies will ask you for your AOC and responsibility matrix, so it helps to publish clearly what your platform does and does not store.
How is PCI DSS compliance validated: SAQ, ROC and AOC?
Compliance is validated either by a Self-Assessment Questionnaire (SAQ) or by a Report on Compliance (ROC), and each is accompanied by an Attestation of Compliance (AOC). Which route applies depends on whether you are a merchant or a service provider, your transaction volumes, and the rules of your acquirer and the card brands. The PCI SSC publishes the standard and the forms. It does not decide which route an individual merchant must use.
| SAQ | Intended for | Travel example |
|---|---|---|
| SAQ A | Card-not-present merchants that fully outsource all payment functions, such as a PSP-hosted page or iframe | OTA or agency website with a redirect or PSP-hosted payment fields |
| SAQ A-EP | E-commerce merchants whose website does not receive card data but can affect how the payment page is delivered | Agency page that hosts the PSP's JavaScript payment form directly |
| SAQ B / B-IP | Merchants using standalone imprint machines or standalone dial-out or IP-connected terminals only | Branch or ticket office taking card-present payments on a standalone terminal |
| SAQ C-VT | Merchants keying transactions one at a time into a PSP's web-based virtual terminal on an isolated device | Sales desk entering phone bookings into a virtual terminal |
| SAQ C | Merchants with payment applications connected to the internet, with no electronic card storage | Agency with a connected payment application on its own network |
| SAQ P2PE | Merchants using only a PCI-listed point-to-point encryption solution | Card-present payments on validated P2PE terminals |
| SAQ D | All other merchants, and every service provider that is eligible to self-assess | Agencies storing card data, booking platforms, TMCs acting as service providers |
Eligibility criteria are set out at the start of each SAQ in the PCI SSC document library. There is also an SAQ for software-based PIN entry on COTS (SPoC). Confirm the right form with your acquirer before you start.
A ROC is completed by a Qualified Security Assessor (QSA), or in some cases a suitably qualified internal assessor, after an on-site or remote assessment. Larger merchants and many service providers validate this way. IATA-accredited agents also update their PCI DSS status through the IATA Customer Portal, attaching documentation where it applies.
Is there such a thing as "PCI certification" for travel agencies?
Not in the sense many people expect. The PCI SSC does not issue certificates to merchants. What exists is compliance, meaning the controls are in place and working, and validation, meaning the formal evidence in an SAQ or ROC with an AOC. Some vendors issue their own certificates, but these are not PCI SSC credentials.
Validation is also a point-in-time check. Not every agency follows the same process, and passing an assessment does not guarantee that you are secure next month. Treat compliance as the minimum and keep the controls running all year.
Practical examples from travel
Airline ticketing through a GDS
An agent issues a ticket with the customer's card as form of payment. The airline is usually the merchant, but the card number passes through the agent's screen, the GDS entry and possibly the PNR history. The agency is still handling card data. Masking, restricted access and avoiding manual re-keying all reduce exposure.
Hotel reservations and guarantees
A hotel needs a card to guarantee a booking. Sending the full number in a booking note or email spreads it to the hotel's inbox, your sent items and backups. Tokenised guarantees or the supplier's secure payment channel avoid that.
OTA web payments
An OTA moves its checkout to PSP-hosted payment fields. Its servers no longer receive card numbers, so it may become eligible for a lighter SAQ. It still has to protect the page that loads those fields against script injection, and keep its booking engine patched.
Virtual cards for supplier payments
A tour operator pays hotels and ground handlers with single-use virtual cards. These numbers are still card data. Deliver them through secure channels, limit who can view them and keep them only as long as needed. Check with your acquirer or assessor how they affect your scope.
What are the most common PCI DSS mistakes, and what is at risk?
The most common mistakes are assuming someone else is responsible and underestimating how far card data spreads. Typical examples:
- Believing a compliant GDS, consolidator or gateway makes the agency compliant.
- Keeping security codes "to charge later", in notes, spreadsheets or call recordings.
- Accepting card details by email or chat because customers send them anyway.
- Shared logins to the GDS or payment portal, and no MFA.
- Filling in the wrong SAQ, or one that no longer matches how payments work.
- Treating validation as a once-a-year form instead of continuous practice.
The business risks are real even without a headline breach. They include fraud losses and chargebacks, the cost of investigating and fixing a compromise, disruption to sales while systems are cleaned, contractual consequences from acquirers and card brands, possible loss of the ability to accept cards, and damage to customer and partner trust. In Europe, a card-data breach can also raise obligations under data-protection law.
PCI DSS readiness checklist for travel businesses
Use this checklist to see where you stand before you talk to your acquirer or an assessor.
- Name an owner for payment security and give them time and budget.
- List every way you accept cards: website, app, phone, email, chat, terminals, GDS and supplier payments.
- Draw a data-flow diagram for each channel, showing where card data enters, moves, is stored and leaves.
- Search systems and inboxes for stored card numbers and security codes; purge what you do not need.
- Move capture to PSP-hosted pages, fields, pay-by-link or IVR so your staff and servers never see the full number.
- Mask card numbers in GDS remarks, queues, itineraries and back-office screens.
- Separate any remaining card-handling systems from the rest of the office network.
- Give every user a unique login and turn on MFA for all access into the cardholder data environment.
- Inventory and authorise every script on your payment pages, and monitor them for unauthorised change.
- Patch booking engines, plugins and workstations on a schedule; run quarterly ASV scans if they apply to you.
- List all third-party service providers, get written responsibility statements and check their AOCs every year.
- Write an incident response plan that covers a suspected card-data leak, and test it.
- Train agents to refuse card details by email or chat and to spot phishing and social engineering.
- Confirm with your acquirer which SAQ or assessment applies, and diarise annual scope confirmation.
How Innovate Solution helps travel businesses with PCI DSS readiness
Innovate Solution builds travel booking and distribution technology, so we know where card data hides in GDS, NDC, booking-engine and back-office workflows. We help travel agencies, tour operators, TMCs, OTAs and travel technology providers in Europe and internationally prepare for and improve PCI DSS readiness:
- PCI DSS readiness assessments and gap analysis
- Payment-flow and cardholder data environment reviews
- Travel technology and booking-platform security reviews
- Remediation planning and implementation support
- Policy and documentation support, including SAQ evidence preparation
- Coordination with your acquirer and with Qualified Security Assessors where an assessment is needed
Please note: Innovate Solution is not a PCI SSC Qualified Security Assessor (QSA) or Approved Scanning Vendor (ASV), is not affiliated with the PCI Security Standards Council or IATA, and does not issue PCI DSS certificates or Attestations of Compliance. Formal validation is performed by the appropriate authorised parties.
See our IATA & PCI DSS compliance services for how an engagement works. If you are running booking technology for European markets, our travel technology for Europe page explains how we work with agencies there.
Discuss your PCI DSS readiness
Tell us how you take card payments today and we will help you map your scope and plan the next steps. Please do not send card numbers, security codes or passwords.
Frequently asked questions
Do travel agencies need to be PCI DSS compliant?
Yes, if they store, process or transmit payment card data, or can affect the security of systems that do. That covers most agencies that take cards on a website, by phone, by email or through a GDS. IATA also asks its accredited travel agents to become PCI DSS compliant and to report their status through the IATA Customer Portal.
Which PCI DSS version applies in 2026?
PCI DSS v4.0.1. The PCI Security Standards Council published it on 11 June 2024 as a limited revision with no new or deleted requirements, and retired v4.0 on 31 December 2024. The requirements that v4.0 marked as future-dated became effective on 31 March 2025, so in 2026 they are assessed like any other requirement.
Is there an official PCI DSS certificate for travel agencies?
Not from the PCI Security Standards Council. Organisations validate compliance with a Self-Assessment Questionnaire or a Report on Compliance, each backed by an Attestation of Compliance. Which route you use depends on your role, transaction volumes and the rules of your acquirer and the card brands. A "certificate" from a vendor is not a PCI SSC credential.
Does using a GDS, consolidator or payment gateway make us compliant?
No. Using PCI DSS compliant providers can reduce your scope, but your own staff, phones, inboxes, devices and procedures can still touch card data. PCI DSS requirement 12.8 expects you to manage those third-party service providers and know which requirements each one covers for you.
Can we store the card security code (CVV) to charge a hotel or airline later?
No. Sensitive authentication data, which includes the card verification code, must not be kept after authorisation, even if it is encrypted. Card-on-file or later charges should use a payment provider's tokenisation or stored-credential features instead of keeping the code yourself.
Which SAQ does a travel agency use?
It depends on how cards are accepted. A fully outsourced e-commerce checkout may fit SAQ A, a page that influences the payment form may need SAQ A-EP, keyed virtual-terminal payments may fit SAQ C-VT, and anything that stores card data electronically usually needs SAQ D. Your acquirer confirms which applies.
Are call recordings and emails containing card numbers in scope?
Yes. Any system that stores or transmits card data is in scope. Recordings must never keep the security code after authorisation, and card numbers arriving by email, chat or fax spread scope to inboxes, backups and every device that opens them. Most agencies switch to pay-by-link, IVR or hosted capture to avoid this.
Is PCI DSS the same as GDPR or PSD2 strong customer authentication?
No. PCI DSS is a card-industry security standard enforced through card-brand and acquirer contracts. GDPR is EU data-protection law covering all personal data, and PSD2 strong customer authentication is a payment-authentication rule. European travel businesses usually have to satisfy all three, and the controls overlap only in part.
Sources and further reading
- PCI SSC — Just published: PCI DSS v4.0.1
- PCI SSC — Guidance for e-commerce requirements effective after 31 March 2025
- PCI SSC FAQ — Can card verification codes be stored for card-on-file transactions?
- PCI SSC information supplement — Protecting telephone-based payment card data
- PCI SSC document library (PCI DSS v4.0.1, SAQs, AOCs)
- IATA — PCI DSS for travel agents
- Further reading: Travel Agency PCI Compliance in 2026: Closing the Payment Security Gap — SecureTrust (independent third-party article; no affiliation implied)
This guide is general information for travel businesses and is not legal advice or a formal PCI DSS assessment. Requirements and validation rules can change; always confirm with the PCI SSC, your acquirer and, where applicable, a Qualified Security Assessor.
