IATA-accredited agencies
It is not your accreditation at stake, it is the payment method behind most of your sales. DM11 prepares your agency to demonstrate PCI DSS compliance, from designing the scope to the evidence that supports the declaration.
DM11 prepares your agency. The self-assessment and attestation are signed by the agency itself, and where a formal QSA assessment is required, it is carried out by an accredited partner.
Who runs the preparation
What IATA actually requires
It is widely repeated that every accredited agency must be PCI DSS compliant. The rule is more precise than that, and the difference changes the size of the problem. Resolution 812 makes authorisation to use the Customer Card Payment Method conditional on compliance with the standard. An agency that does not accept, transmit or store card data declares exactly that and the matter ends there.
Resolution 812, section 2.6.3.1: authorisation to use the Customer Card Payment Method is subject to the agent's full compliance with PCI DSS. The BSP Manual for Agents reinforces this, adds Resolution 890, and states that IATA monitors compliance.
It applies if your agency accepts cards against its own merchant agreement or issues tickets using the passenger's card through the BSP. If your operation never touches card data, there is a specific declaration for that case, and it replaces the compliance evidence.
In the IATA Customer Portal, under Accreditation & Changes, in the PCI DSS compliance update service. Only contacts with administrator or authorised signatory profiles can submit. You attach the attestation, and the cycle is annual.
The standard
PCI DSS is the card industry's security standard, maintained by the PCI Security Standards Council. It does not ask how big your company is: it asks whether you accept, transmit or store card data. In an agency, that data comes in through more doors than most people expect.
PCI DSS v4.0.1. Version 3.2.1 was retired in March 2024 and v4.0 in December 2024, so any current assessment is against 4.0.1. Documents and policies written against the old version no longer support a declaration.
Most of the new requirements in version 4 were best practice until 31 March 2025 and became mandatory on that date. Among them: multi-factor authentication for all access to the card environment, longer passwords, and training that covers phishing and social engineering.
The BSP Manual for Agents is explicit: agents must never store or write down the card verification value. The standard says the same: authentication data cannot be retained after authorisation, and encrypting it does not help. It is the most violated rule and the easiest to prove in an investigation.
The standard prohibits sending an unprotected card number over end-user messaging technologies, which includes email, SMS and messaging apps. In practice this is an agency's most common and most costly habit, because it leaves data scattered across inboxes nobody controls.
Everything that stores, processes or transmits card data is in scope, and so is whatever connects to those systems. That is why the first job is not buying controls, it is shrinking the territory: taking data out of where it does not need to be reduces effort across every requirement at once.
If your call centre records calls and customers read out card numbers, that audio now contains card data. Where recordings can be searched, this conflicts with the prohibition on retaining authentication data. The usual answer is to pause recording during payment or strip that segment.
Which case is yours
The SAQ is the self-assessment: a questionnaire the agency answers and signs itself. There is more than one type, and the right one depends on the channel through which you receive the card, not on your revenue. Choosing the wrong type is the costliest mistake, because it produces a declaration that does not hold up.
| How the card reaches you | Applicable self-assessment | What that demands |
|---|---|---|
| Your own site redirecting payment to the gateway, never touching the data | SAQ A | The smallest set of controls. In return, you attest that your payment page is not susceptible to script attacks, a statement that only holds up with real monitoring of that page. |
| Your own site with a payment page that touches the data before sending it | SAQ A-EP | Considerably broader than SAQ A: your web environment enters scope, with vulnerability management and change control. |
| Only the acquirer's virtual terminal, on an isolated computer, storing nothing digitally | SAQ C-VT | Requires genuine isolation of the workstation and no other electronic card channel. It does not apply if the agency also sells online. |
| Card typed into the form of payment field in the reservation system | SAQ D | The data passes through your systems and the booking record, so the environment is in scope. This is the most common scenario among Brazilian agencies, and the most underestimated. |
| Card received by phone, email or messaging app | SAQ D | Beyond the wider scope, there is an earlier correction to make: receiving cards over messaging already breaches the standard and needs an alternative channel before any declaration. |
| Card written down, kept in a spreadsheet, back-office system or call recording | SAQ D | Storage is what most expands scope and risk. Here the work starts by finding and removing data from where it should not be. |
It is often written that travel agencies fall under SAQ C-VT. In most Brazilian cases they do not: C-VT requires the acquirer's virtual terminal on an isolated machine and does not allow online sales. An agency typing cards into the reservation system is in a different scenario, and declaring the wrong type creates more exposure than not declaring at all.
What actually happens
Many people picture losing accreditation or paying a fine, and put the matter off. What Resolution 812 provides for is different, and in the short term worse for operations: the customer's card is removed as a payment method and the agency's record is marked.
Non-compliance is a formally listed risk event in Resolution 812, in the same table that covers the agency's other risk events.
The Resolution states that IATA will immediately restrict use of the Customer Card Payment Method. If the ticketing system provider cannot apply the restriction, the BSP airlines are informed so they can act.
A single recorded occurrence already weighs on the agency's risk history assessment, in the same severity category as a payment default. A change in risk status can trigger financial guarantee requirements and more frequent remittance.
The restriction stays in place until the agency demonstrates, to IATA's satisfaction, that it meets the requirements to use the method again. In other words, the way out is the same work that would have avoided the problem.
Who does what
This is a market where certificates get promised by people who cannot issue them. We would rather be clear from the start about who signs what, because it changes what you should demand from us and what you need to solve elsewhere.
Self-assessment
Fourteen questions about how cards move through your operation. The full result appears on screen, with a score per area and an honest read on what has to change first. We do not ask for your email to show it.
Phone, email, messaging app, website, counter, reservation system, acquirer terminal.
How we run it
Every phase ends with a deliverable. You know what you get before you start.
We chart every point where data enters, travels and stops in your operation, including the informal ones nobody documents. This step defines the size of everything that follows.
You get
Before implementing controls, we take data out of where it does not need to be. Changing the intake channel and eliminating unnecessary storage usually shrinks the project dramatically.
You get
We work with your team on what the standard requires for the scope that remains: access, authentication, network separation, patching, logging and monitoring, and management of the suppliers that touch cards.
You get
The travel consultant is the person who receives the card. We train the team on the new procedure and on recognising email and phone scams, which the current version of the standard explicitly requires.
You get
We build the file that supports every answer in the self-assessment and guide the correct completion. The agency signs, and signs knowing what sits behind each item.
You get
The declaration is annual and the operation changes along the way. We track the changes that affect scope and prepare the next cycle before it becomes urgent.
You get
Stories
We anonymise our clients with the same confidentiality that will protect your agency later. The names change, and the pattern of the problems repeats.
Frequently asked
Answers anchored in IATA's resolutions and the PCI Security Standards Council's standard. Where no official figure exists, we say so.
Not exactly, and the difference matters. Resolution 812 makes authorisation to use the Customer Card Payment Method conditional on PCI DSS compliance. If your agency accepts cards against its own merchant agreement or issues tickets with the passenger's card, the requirement applies. If your operation never accepts, transmits or stores card data, there is a specific declaration for that case which replaces the compliance evidence.
More questions? Talk to DM11
A thirty minute conversation is usually enough to say which self-assessment is likely to apply to your agency and what can be resolved quickly. No obligation.