The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
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 prove it meets PCI DSS, the security standard for card data, 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 the case calls for a formal assessment by a QSA (an accredited auditor), it is carried out by a 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. IATA, the airlines' global association, only clears an agency to take payment with the customer's card if it meets the standard, through its Resolution 812. An agency that does not accept, transmit or store card data tells IATA exactly that and the matter ends there.
Resolution 812, section 2.6.3.1: permission to use the Customer Card Payment Method (paying with the customer's card) depends on the agent's full compliance with PCI DSS. The BSP Manual for Agents, the manual that governs agents in IATA's billing and settlement system, 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 shrinking the territory, before buying any control: taking data out of where it does not need to be reduces effort across every requirement at once.
If your call center 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 (the payment processor's page), 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 recognizing 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.
Resolution 812 treats non-compliance as a risk event and provides that IATA will immediately restrict use of the Customer Card Payment Method. The agency stays in the BSP but stops issuing with the customer's card. If the ticketing system provider cannot apply the restriction, the BSP airlines are informed. The restriction remains until the agency demonstrates it meets the requirements. A single recorded occurrence also weighs on the risk history, which can lead to financial guarantee requirements.
We found no provision for an IATA fine in the text of Resolution 812. What IATA does is restrict the payment method and record the risk event. Fines do exist in the card ecosystem, but they belong to the card brands, sit in contracts and are charged through the acquirer, usually after a breach. These are different things, and it pays not to confuse them, because the response differs depending on where the charge comes from.
No. DM11 is not a QSA and does not issue certificates. We prepare your agency: we design and reduce the scope, implement the controls, write the policies, train the team and organize the evidence. The self-assessment and attestation are signed by the agency itself, which is how the mechanism works. When a case calls for a formal QSA assessment, we work alongside an accredited partner, and the assessment is conducted by them.
In most cases, no. For most merchants, including practically every travel agency, the path is a self-assessment signed by the merchant. A formal QSA assessment is usually required at very high transaction volumes, or when the acquirer specifically asks for it, which can happen after an incident. That is decided by your acquirer together with the card brand, not by IATA and not by us.
It depends on how the card comes in and whether it gets stored, not on your revenue. A warning is worth making: it is often written that travel agencies fall under SAQ C-VT, and in most Brazilian cases they do not. That type requires the acquirer's virtual terminal on an isolated machine and does not allow online sales. An agency typing cards into the reservation system's form of payment field is in a different, usually broader scenario. Declaring the wrong type creates more exposure than not declaring, because the attestation then asserts something the operation cannot support.
It depends on your environment, not your size. An external scan by an approved vendor is required when there are internet-facing components in scope, such as your own booking site or an exposed remote access. An agency operating only by phone and reservation system, with no public asset in scope, may legitimately not have that requirement. IATA does not define this: the standard does, according to your environment, together with your acquirer.
The verification code, never. The BSP Manual for Agents is explicit that agents must not store or write down that code, and the standard prohibits retaining authentication data after authorisation, with no exception and with encryption offering no way around it. The card number itself may be retained where there is a business need, with proper protection and a defined disposal deadline. In practice most agencies discover they do not need to keep it, and that single decision cuts both risk and effort at once.
Sending an unprotected card number over end-user messaging technologies breaches the standard, and that includes email, SMS and messaging apps. We know it is the industry's most entrenched habit, and the answer is not to ban it without an alternative: it is to offer a channel customers accept just as easily, usually a payment link. Changing the channel is usually the project's first step, because it stops new data entering while everything else is still being handled.
No. A virtual card is still a card number: if your agency receives it, types it and transmits it, it stays in scope. The real benefit of a virtual card is different and not small, because single use and spending limits cut the damage from fraud or a breach. But that is risk reduction, not scope exemption, and it is worth being wary of anyone presenting the two as the same thing.
Version 4.0.1. Version 3.2.1 was retired in March 2024 and 4.0 in December 2024. One date catches a lot of people out: most of the new requirements in version 4 were best practice until 31 March 2025 and became mandatory then, among them multi-factor authentication for all access to the card environment and training that covers phishing. Anyone who prepared documentation before that and has not revisited it is probably declaring against a version that no longer exists.
It depends how far cards have spread today and how much scope can be cut at the start. An agency that only needs to change its intake channel and organize evidence moves quickly. One that stores cards across several systems and records calls has earlier work to do. We would rather not publish a standard timeline because it would be guesswork: after the diagnosis we can put a date on your specific case.
No. Remediation happens alongside operations, and the first step usually improves sales rather than hindering them, because a payment link tends to be quicker for the customer than reading out a card over the phone. What needs planning is your team's time: consultants have to learn the new procedure, and evidence does not produce itself.
It is, and solving both together saves effort. Card data is personal data, so the same breach that triggers contractual penalties from the card brands also triggers privacy obligations, including notifying the authority and the individuals. Much of what PCI DSS asks for, such as knowing where data lives, limiting access and defining disposal, is exactly what privacy law requires. We handle both in the same project when the agency wants it.
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.
Comparisons on this subject
See all 13 comparisons