Agências acreditadas IATA
Não é a acreditação que está em jogo, é a forma de pagamento que sustenta a maior parte das suas vendas. A DM11 prepara sua agência para demonstrar conformidade com o PCI DSS, do desenho do escopo à evidência que sustenta a declaração.
A DM11 prepara a sua agência. Quem assina a autoavaliação e a atestação é a própria agência, e onde o caso exigir avaliação formal por um QSA, ela é conduzida por um parceiro credenciado.
Quem conduz a preparação
O que a IATA exige, de fato
Circula por aí que toda agência acreditada precisa ser PCI DSS. A regra é mais precisa que isso, e entender a diferença muda o tamanho do problema. A Resolução 812 condiciona a autorização para usar o Customer Card Payment Method à conformidade com o padrão. Quem não aceita, transmite nem armazena dado de cartão declara isso à IATA e encerra o assunto.
Resolução 812, seção 2.6.3.1: a autorização para usar o Customer Card Payment Method está condicionada à plena conformidade da agência com o PCI DSS. O BSP Manual for Agents reforça e acrescenta a Resolução 890, e diz que a IATA monitora o cumprimento.
Vale se a sua agência aceita cartão contra o próprio credenciamento ou emite bilhete com cartão do passageiro pelo BSP. Se a sua operação não toca dado de cartão em nenhum momento, existe a declaração própria para esse caso, e ela substitui a evidência de conformidade.
No IATA Customer Portal, em Accreditation & Changes, no serviço de atualização de conformidade PCI DSS. Só contatos com perfil de administrador ou signatário autorizado conseguem submeter. Anexa-se a atestação, e o ciclo é anual.
O padrão
O PCI DSS é o padrão de segurança do setor de cartões, mantido pelo PCI Security Standards Council. Ele não pergunta o tamanho da sua empresa: pergunta se você aceita, transmite ou armazena dado de cartão. Numa agência, esse dado entra por mais portas do que a maioria imagina.
PCI DSS v4.0.1. A v3.2.1 foi aposentada em março de 2024 e a v4.0 em dezembro de 2024, então qualquer avaliação atual é contra a 4.0.1. Documento e política escritos na versão antiga não sustentam mais uma declaração.
A maior parte dos requisitos novos da versão 4 era boa prática até 31 de março de 2025 e passou a ser obrigatória naquela data. Entre eles, autenticação em duas etapas para todo acesso ao ambiente de cartão, senhas mais longas e treinamento que cubra phishing e engenharia social.
O BSP Manual for Agents é direto: a agência nunca deve armazenar nem anotar o código de verificação do cartão. O padrão diz o mesmo: dado de autenticação não pode ser retido depois da autorização, e criptografar não resolve. É a regra mais violada e a mais fácil de comprovar numa investigação.
O padrão veda enviar o número do cartão sem proteção por tecnologias de mensagem de usuário final, o que inclui e-mail, SMS e aplicativos de mensagem. Na prática, é o hábito mais comum e mais caro de uma agência, porque deixa o dado espalhado em caixas de entrada que ninguém controla.
Tudo o que armazena, processa ou transmite dado de cartão entra no escopo, e junto vem o que está conectado a esses sistemas. Por isso o primeiro trabalho não é comprar controle, é diminuir o território: tirar o dado de onde ele não precisa estar reduz esforço em todos os requisitos de uma vez.
Se a sua central grava chamadas e o cliente dita o cartão, esse áudio passa a conter dado de cartão. Quando a gravação pode ser pesquisada, isso conflita com a proibição de reter dado de autenticação. A saída usual é pausar a gravação no momento do pagamento ou suprimir o trecho.
Qual é o seu caso
SAQ é a autoavaliação: um questionário que a própria agência responde e assina. Existe mais de um tipo, e o certo depende do canal pelo qual você recebe o cartão, não do seu faturamento. Escolher o tipo errado é o erro mais caro, porque produz uma declaração que não se sustenta.
| Como o cartão chega até você | Autoavaliação aplicável | O que isso exige |
|---|---|---|
| Site próprio que redireciona o pagamento para o gateway, sem tocar no dado | SAQ A | O menor conjunto de controles. Em contrapartida, você atesta que a sua página de pagamento não é suscetível a ataque de script, uma afirmação que só se sustenta com monitoração real da página. |
| Site próprio com página de pagamento que toca o dado antes de enviar | SAQ A-EP | Bem mais extenso que o SAQ A: seu ambiente web entra no escopo, com gestão de vulnerabilidades e controle de alterações. |
| Apenas terminal virtual do adquirente, num computador isolado, sem guardar nada em meio digital | SAQ C-VT | Exige isolamento real da estação e nenhum outro canal eletrônico de cartão. Não serve se a agência também vende pela internet. |
| Cartão digitado no campo de forma de pagamento do sistema de reservas | SAQ D | O dado passa pelos seus sistemas e pelo registro da reserva, então o ambiente entra no escopo. É o cenário mais comum nas agências brasileiras, e o mais subestimado. |
| Cartão recebido por telefone, e-mail ou aplicativo de mensagem | SAQ D | Além do escopo ampliado, há uma correção anterior a fazer: recebimento de cartão por mensagem já contraria o padrão, e precisa de um canal alternativo antes de qualquer declaração. |
| Cartão anotado, guardado em planilha, sistema de gestão ou gravação de ligação | SAQ D | Armazenamento é o que mais amplia escopo e risco. Aqui o trabalho começa por localizar e eliminar o dado onde ele não deveria estar. |
É comum ler que agência de viagens se enquadra no SAQ C-VT. Na maioria dos casos brasileiros não se enquadra: o C-VT exige terminal virtual do adquirente em máquina isolada e não admite venda pela internet. Quem digita cartão no sistema de reservas está em outro cenário, e declarar o tipo errado cria uma exposição maior do que não declarar.
O que acontece na prática
Muita gente imagina perda de acreditação ou multa, e por isso adia. O que a Resolução 812 prevê é diferente, e para a operação é pior no curto prazo: o cartão do cliente sai como forma de pagamento e o histórico da agência fica marcado.
A falta de conformidade é um evento de risco formalmente tipificado na Resolução 812, na mesma tabela que trata dos demais eventos de risco da agência.
A Resolução determina que a IATA restrinja imediatamente o uso do Customer Card Payment Method. Se o provedor do sistema de emissão não conseguir aplicar a restrição, as companhias aéreas do BSP são informadas para agir.
Uma única ocorrência registrada já pesa na avaliação do histórico de risco da agência, na mesma categoria de gravidade de um inadimplemento. Mudança de status de risco pode disparar exigência de garantia financeira e remessa mais frequente.
A restrição permanece até a agência demonstrar, a contento da IATA, que atende aos requisitos para voltar a usar o método. Ou seja, o caminho de saída é o mesmo que teria evitado o problema.
Quem faz o quê
Este é um mercado em que se promete certificado que não se pode emitir. Preferimos deixar claro desde já quem assina o quê, porque isso muda o que você deve cobrar de nós e o que precisa resolver com outros.
Autodiagnóstico
Quatorze perguntas sobre como o cartão circula na sua operação. O resultado aparece inteiro na tela, com a nota de cada área e uma leitura honesta do que precisa mudar primeiro. Não pedimos e-mail para mostrar o resultado.
Telefone, e-mail, aplicativo de mensagem, site, balcão, sistema de reservas, terminal do adquirente.
Como conduzimos
Cada fase termina com entregável. Você sabe o que recebe antes de começar.
Levantamos todos os pontos por onde o dado entra, passa e para na sua operação, incluindo os informais que ninguém documenta. É o passo que define o tamanho de tudo o que vem depois.
Você recebe
Antes de implantar controle, tiramos o dado de onde ele não precisa estar. Trocar o canal de recebimento e eliminar armazenamento desnecessário costuma encolher o projeto de forma drástica.
Você recebe
Executamos junto com o seu time o que o padrão exige para o escopo que sobrou: acesso, autenticação, separação de rede, atualização, registro e monitoramento, e a gestão dos fornecedores que tocam cartão.
Você recebe
O consultor de viagens é quem recebe o cartão. Treinamos a equipe no procedimento novo e em como reconhecer golpe por e-mail e telefone, que a versão atual do padrão exige expressamente.
Você recebe
Montamos o dossiê que sustenta cada resposta da autoavaliação e orientamos o preenchimento correto. Quem assina é a agência, e assina sabendo o que há por trás de cada item.
Você recebe
A declaração é anual e a operação muda no meio do caminho. Acompanhamos as mudanças que afetam escopo e preparamos o ciclo seguinte antes que ele vire urgência.
Você recebe
Histórias
Anonimizamos os clientes pelo mesmo sigilo que vai proteger a sua agência depois. Os nomes mudam, e o padrão dos problemas se repete.
Dúvidas frequentes
Respostas ancoradas nas resoluções da IATA e no padrão do PCI Security Standards Council. Onde não existe dado oficial, dizemos que não existe.
Não exatamente, e a diferença importa. A Resolução 812 condiciona a autorização para usar o Customer Card Payment Method à conformidade com o PCI DSS. Se a sua agência aceita cartão contra o próprio credenciamento ou emite bilhete com cartão do passageiro, a exigência se aplica. Se a operação não aceita, não transmite nem armazena dado de cartão em nenhum momento, existe uma declaração específica para esse caso, que substitui a evidência de conformidade.
Mais dúvidas? Fale com a DM11
Uma conversa de trinta minutos costuma bastar para dizer qual autoavaliação tende a se aplicar à sua agência e o que dá para resolver logo. Sem compromisso.