Os necessários fazem o site funcionar. Os outros medem quais páginas ajudam e quais anúncios trazem quem precisa da DM11. Você escolhe, e pode rever pelo rodapé.
Gateways, prestadores de pagamento (PSP) e processadoras
O PCI DSS, o padrão de segurança de dados de cartão, tem uma lista de exigências que só vale para quem presta serviço a outras empresas, e ainda um apêndice inteiro para quem hospeda vários clientes no mesmo ambiente. A DM11 leva a sua empresa pelo caminho certo, sem aquela surpresa de descobrir o tamanho real do trabalho no meio da avaliação.
A DM11 prepara a sua empresa. Não somos QSA, o avaliador credenciado, e não emitimos o relatório de conformidade (RoC), o atestado (AOC) nem certificado. Quando a avaliação formal é exigida, quem conduz é um QSA parceiro, credenciado pelo PCI SSC, o conselho que mantém o padrão.
Quem conduz a preparação
A pergunta que define tudo
A resposta muda tudo: quais requisitos valem, como você comprova e com que frequência repete cada rotina. O padrão chama de prestador de serviço quem processa, guarda ou transmite dado de cartão em nome de outra empresa, ou quem pode afetar a segurança desse dado. Gateway, subadquirente, facilitador e processadora entram nessa conta. E quem vende direto e ainda processa para terceiros acumula os dois papéis ao mesmo tempo.
O próprio padrão prevê isso: quando a empresa é comerciante e prestadora ao mesmo tempo, os requisitos que só valem para prestador se aplicam à parte do negócio que presta serviço. Na prática, são dois escopos dentro da mesma avaliação. Tratar os dois como um só é um erro que sai caro.
Quem contrata você precisa acompanhar a sua conformidade pelo menos uma vez a cada doze meses e saber quais requisitos são seus, quais são dele e quais vocês dividem. Não é curiosidade: é uma obrigação dele. E a resposta que você der decide se o contrato anda ou trava.
Aparecer na lista de prestadores conformes de uma bandeira ajuda o seu cliente a cumprir o acompanhamento anual. Mas o padrão é claro: para provar os requisitos que você cumpre em nome dele, só a lista não serve como prova. Espera-se que você entregue o AOC quando pedirem.
O que muda para prestador
O PCI DSS marca vários requisitos como válidos só para prestador de serviço e ainda dobra a frequência de rotinas que o comerciante faz uma vez por ano. Quem monta o programa pensando em comerciante só percebe isso tarde demais.
A versão em vigor é a PCI DSS v4.0.1, publicada em junho de 2024. A v4.0 foi aposentada em dezembro de 2024, então essa é a única versão ativa. O modelo do relatório de conformidade (Report on Compliance) está na revisão 3, de janeiro de 2025.
Boa parte dos requisitos novos da versão 4 era só recomendação até 31 de março de 2025 e virou obrigação nessa data. Vários deles pesam mais para o prestador, principalmente os de escopo a cada seis meses e os do apêndice de ambiente compartilhado.
O SAQ D-Service Provider é o único questionário de autoavaliação (SAQ) para prestador, e vale apenas para quem a bandeira considera elegível. Ele traz todos os requisitos exclusivos de prestador e o apêndice de ambiente compartilhado, que não aparecem no SAQ de comerciante.
O comerciante confirma o escopo uma vez por ano. O prestador confirma a cada seis meses, e também depois de qualquer mudança importante. O próprio padrão explica por quê: a rede de um prestador costuma ser maior, mais complexa e mudar mais.
Onde o comerciante testa a segmentação uma vez por ano, o prestador testa a cada seis meses e depois de qualquer mudança nos controles de segmentação. E quem hospeda vários clientes ainda tem um segundo teste, somado a esse.
O padrão dá duas opções ao prestador: fazer uma avaliação por ano e entregar a prova aos clientes, ou ser avaliado sob demanda por cada cliente e participar da avaliação de cada um. Na segunda, você troca um projeto por ano por uma fila deles.
Qual é o seu caminho
A sua rota depende de como o dado circula, de quem você atende e do volume que processa em nome de terceiros. Quem define o limite e a forma de validar são as bandeiras e o adquirente, não o PCI Security Standards Council.
| Seu perfil | Rota de validação | O que ela exige |
|---|---|---|
| O dado nunca toca o seu ambiente | SAQ A | O conjunto mais curto de controles. Não vale para prestador de serviço: é rota de comerciante. |
| O dado passa por você, mas você vende para os seus próprios clientes finais | SAQ D Comerciante | A norma inteira na visão de comerciante, sem os requisitos exclusivos de prestador. |
| Você processa, armazena ou transmite em nome de outras empresas, dentro do limiar da bandeira | SAQ D Prestador | A norma inteira, mais os requisitos exclusivos de prestador, mais o apêndice de ambiente compartilhado se você hospeda vários clientes. Aqui você precisa descrever o resultado de cada teste, requisito por requisito, e não só marcar sim ou não. |
| Acima do limiar da bandeira, ou quando o adquirente exige | Report on Compliance | Avaliação formal conduzida por um QSA, no modelo oficial, com o avaliador confirmando o escopo por conta própria. É também o caminho para entrar nas listas de prestadores conformes das bandeiras. |
A Visa publica o limite de 300 mil transações por ano para separar o prestador Nível 1 do Nível 2: no Nível 1 vai Report on Compliance por QSA, e no Nível 2, autoavaliação. O escaneamento externo trimestral, feito por empresa aprovada, vale para os dois níveis. A Mastercard usa outro critério, por categoria de serviço e volume anual, em programa próprio. Confirme o seu enquadramento com o adquirente antes de escolher a rota.
O que só vale para você
O padrão marca esses requisitos como válidos só para prestador de serviço. Quem monta o programa a partir de um material genérico de PCI DSS simplesmente não os vê, e descobre a falta quando o avaliador pergunta.
Uma descrição de todos os algoritmos, protocolos e chaves que protegem o dado guardado, com força e prazo de validade, mais o inventário dos módulos de criptografia, com tipo e localização. E chave usada em produção não pode ser reaproveitada no ambiente de teste.
Se você compartilha chave de criptografia com quem atende, precisa documentar e passar orientação de como transmitir, guardar e atualizar essas chaves com segurança.
Se você acessa de longe o ambiente de quem atende, o fator de autenticação precisa ser único para cada cliente. A credencial usada num cliente não pode servir para outro.
Quando a senha é o único jeito de o usuário do seu cliente chegar ao dado de cartão, você tem duas saídas: ou ela muda a cada noventa dias, ou você analisa a situação da conta em tempo real e decide o acesso na hora.
A cada seis meses, e depois de qualquer mudança nos controles de segmentação, para confirmar que o ambiente de cartão está isolado de todos os sistemas fora de escopo. Quem executa precisa de independência dentro da empresa, mas não precisa ser QSA.
A detecção de invasão precisa achar, alertar e tratar os canais de comunicação escondidos que o malware usa. E o plano de resposta a incidentes precisa prever o que fazer quando isso for detectado.
A alta direção assume formalmente a responsabilidade pelo programa, com uma carta que deixa isso registrado e comunicado a ela. E a cada três meses alguém confirma que as tarefas estão sendo feitas conforme a política, sempre uma pessoa diferente de quem executa a tarefa.
Confirmação de escopo a cada seis meses, e uma revisão documentada de impacto sempre que a empresa muda de forma relevante, como fusão, aquisição ou troca de quem responde pelos controles, com o resultado comunicado à direção.
Um acordo por escrito reconhecendo que você é responsável pela segurança do dado que guarda em nome do cliente. E responder, quando pedirem, às perguntas sobre o seu status de conformidade e sobre quem responde por cada requisito.
Ambiente compartilhado
O padrão trata em separado quem oferece serviço compartilhado a vários clientes, com sistema, infraestrutura, aplicação ou banco de dados em comum. O texto cita pelo nome os serviços de gateway e de processamento em ambiente compartilhado. Quem só oferece data center compartilhado, o modelo de colocation, fica de fora desse apêndice.
O provedor não entra no ambiente do cliente sem autorização, e o cliente não entra no ambiente do provedor sem autorização. Cada cliente alcança só o próprio dado de cartão e usa só os recursos reservados a ele, sem atrapalhar os outros.
A cada seis meses, um teste de invasão confirma que a separação entre os ambientes dos clientes está funcionando. O padrão é claro: esse teste é somado ao pentest de segmentação, e não o substitui. São dois exercícios diferentes no mesmo semestre.
O registro (log) fica ligado por padrão para o ambiente de cada cliente e só o cliente dono daquele ambiente pode consultar, com a localização do log avisada com clareza a ele.
Capacidade de apoiar na hora a investigação forense em um incidente de qualquer cliente, e um canal seguro para os clientes avisarem sobre incidentes e vulnerabilidades, com tratamento e correção.
Quem opera ambiente compartilhado precisa apoiar o teste de invasão externo dos clientes. E o padrão diz por quê, sem rodeios: proibir deixaria os sistemas deles abertos a ataque.
Vale registrar o que o próprio padrão observa: mesmo que o provedor cumpra esses requisitos, cada cliente continua responsável por cumprir e validar os requisitos do próprio ambiente. A sua conformidade não passa conformidade para quem você atende, e prometer isso na venda vira problema depois.
O que você entrega à sua carteira
Aqui está uma vantagem competitiva que pouca gente aproveita. A forma como você entrega a página de pagamento decide qual autoavaliação o seu cliente comerciante vai poder usar, e a diferença entre a mais curta e a seguinte é grande. Isso é argumento de venda para a sua carteira, e dá para comprovar no material do PCI Security Standards Council.
| Como você integra | Autoavaliação do seu cliente | Condição |
|---|---|---|
| Terceirização total, como link de pagamento enviado ao portador | SAQ A | A exigência de proteger a página contra script não vale para esse modelo. |
| Redirecionamento do site do cliente para o seu ambiente | SAQ A | A exigência de script também não vale no redirecionamento, desde que os outros critérios sejam atendidos. |
| Página ou formulário embarcado, tipicamente por iframe | SAQ A | Só se o cliente proteger a página por conta própria, ou se você der uma confirmação por escrito de que a sua solução, instalada conforme as suas instruções, protege a página contra ataque de script. |
| O site do cliente controla o fluxo e afeta a integridade da página | SAQ A-EP | Bem mais extenso. Se você hospeda o site e opera ambiente compartilhado, cumprir o apêndice de multicliente é pré-requisito para o seu cliente ser elegível. |
| O dado de cartão chega ao próprio site do cliente | SAQ D Comerciante | O ambiente do cliente entra inteiro em escopo. |
A terceira linha é a oportunidade. O provedor que coloca a gestão de scripts e a detecção de alteração dentro da própria solução de iframe, e emite a confirmação por escrito, mantém a carteira na autoavaliação mais curta em vez de empurrá-la para a seguinte. Quem não faz, empurra. A decisão final sobre qual autoavaliação vale é sempre do adquirente ou da bandeira do cliente.
Quem faz o quê
Num mercado em que se promete certificado que não se pode emitir, a gente prefere deixar claro desde já quem assina o quê. Isso muda o que você deve cobrar de nós e o que precisa resolver com outros.
Autodiagnóstico
As primeiras perguntas classificam o seu caso e apontam a rota de validação. As outras passam pelos capítulos da norma e mostram onde estão as lacunas. O resultado aparece inteiro na tela, com a rota, a nota de cada capítulo e o que fecha cada lacuna. E não pedimos e-mail para mostrar.
Como conduzimos
Cada fase termina com entregável. Você sabe o que recebe antes de começar.
Mapeamos o fluxo do dado, os sistemas conectados e os que afetam a segurança do ambiente. Separamos a trilha de comerciante da de prestador quando a empresa acumula os dois papéis, porque tratar as duas como uma só distorce todo o resto.
Você recebe
Antes de instalar controle, tiramos da frente o que não precisa estar em escopo. Segmentação, fim do armazenamento desnecessário e revisão de integração encolhem o programa inteiro de uma vez.
Você recebe
Executamos junto com o seu time o que falta em cada capítulo, com atenção especial aos requisitos exclusivos de prestador e ao apêndice de ambiente compartilhado, que costumam estar de fora.
Você recebe
Conformidade de prestador é calendário, não projeto. Estruturamos as revisões trimestrais, a confirmação de escopo a cada seis meses, os pentests na frequência certa e o escaneamento trimestral.
Você recebe
Montamos o que a due diligence dos seus clientes vai pedir: matriz de responsabilidade por requisito, acordo por escrito de responsabilidade e o processo de resposta aos pedidos de status.
Você recebe
Organizamos a prova no formato que o avaliador espera e fazemos um ensaio antes da avaliação de verdade. Quando a rota é Report on Compliance, alinhamos com o QSA parceiro, mantendo os papéis separados.
Você recebe
Histórias
Trocamos os nomes dos clientes pelo mesmo sigilo que vai proteger a sua empresa depois. Os nomes mudam, e o padrão dos problemas se repete.
Dúvidas frequentes
Respostas baseadas no padrão do PCI Security Standards Council e nos programas das bandeiras. Onde não existe dado oficial, a gente diz que não existe.
Não. A DM11 não é QSA e não emite Report on Compliance, atestação nem certificado. A gente prepara: desenha e reduz o escopo, instala os controles, monta as rotinas recorrentes, faz o pentest de segmentação e organiza a prova. Quando a sua rota exige avaliação formal, quem conduz é um QSA parceiro credenciado, com os papéis separados entre quem preparou e quem avalia.
Depende do seu nível, que é definido pelas bandeiras e administrado pelo adquirente, não pelo PCI SSC. A Visa publica o limite de 300 mil transações por ano: acima disso, prestador Nível 1, com Report on Compliance por QSA; abaixo, Nível 2, com autoavaliação. A Mastercard usa categoria de serviço e volume anual em programa próprio. O escaneamento externo trimestral por empresa aprovada vale para os dois níveis. Confirme o enquadramento com o seu adquirente antes de decidir.
Só existe um: o SAQ D para prestadores de serviço. E ele vale apenas para quem a bandeira considera elegível a autoavaliação. Ele traz todos os requisitos exclusivos de prestador e o apêndice de ambiente compartilhado, que não existem no SAQ de comerciante. Outra diferença que pega quem vem do mundo de comerciante: a versão atual pede para descrever o resultado do teste de cada requisito, e não só marcar se atende.
O padrão prevê exatamente essa situação: os requisitos marcados como exclusivos de prestador valem para a parte do negócio que presta serviço. Na prática, são duas trilhas de escopo dentro da mesma avaliação, e tratar as duas como uma só distorce o dimensionamento. É uma das primeiras coisas que a gente separa no começo do projeto, porque tudo o que vem depois depende disso.
Além de uma lista de requisitos que simplesmente não existe para comerciante, muda a frequência de rotinas importantes. A confirmação de escopo passa de anual para semestral. O teste de invasão de segmentação passa de anual para semestral, e também depois de qualquer mudança nos controles de segmentação. Entram revisões trimestrais de execução, feitas por quem não executa a tarefa, e a responsabilidade formal da direção pelo programa. O próprio padrão explica por quê: a rede de prestador é maior, mais complexa e muda mais.
Acrescenta um apêndice inteiro, que o padrão criou para esse caso e no qual cita pelo nome os serviços de gateway e de processamento em ambiente compartilhado. Ele exige separação nos dois sentidos entre provedor e cliente, garantia de que um cliente não chega ao dado nem aos recursos de outro, log por cliente visível só ao dono, canal para reportar incidente e apoio à investigação forense. E exige um teste de invasão a cada seis meses da separação entre clientes, que o padrão diz de forma expressa ser somado ao teste de segmentação. São dois exercícios diferentes no mesmo semestre. Quem oferece só data center compartilhado, no modelo de colocation, fica de fora desse apêndice.
Não, e prometer isso na venda vira problema depois. O padrão registra que, mesmo com o provedor cumprindo os requisitos do ambiente compartilhado, cada cliente continua responsável por cumprir e validar os requisitos do próprio ambiente. O que você faz pelo cliente é reduzir o esforço dele, entregar prova e assumir a parte que é sua na matriz de responsabilidade. É bastante coisa, e dá para vender, mas não é transferência de conformidade.
Afeta bastante, e é uma alavanca comercial que poucos aproveitam. Se você entrega por redirecionamento ou terceirização total, a exigência de proteger a página contra script não recai sobre o cliente. Se entrega página embarcada por iframe, o cliente só sustenta a autoavaliação mais curta se proteger a página por conta própria ou se receber de você a confirmação por escrito de que a sua solução, instalada conforme as suas instruções, protege contra ataque de script. O provedor que instala o inventário de scripts e a detecção de alteração e emite essa confirmação mantém a carteira na rota mais curta. Quem não faz, empurra o cliente para a rota seguinte, que é bem mais extensa.
Vale, com uma ressalva. O padrão reconhece que estar na lista de uma bandeira pode ser prova suficiente para o cliente cumprir o acompanhamento anual de status, desde que fique claro que os serviços contratados por ele estavam cobertos pela avaliação. Mas para provar os requisitos que você cumpre em nome do cliente, a lista não basta: espera-se que você entregue a atestação quando pedirem. Nas duas bandeiras principais, o caminho para entrar na lista passa por avaliação formal com QSA e por um registro feito pelo adquirente ou pela instituição que patrocina você.
Pode, e o padrão prevê essa opção, mas vale entender o que ela significa na prática. As duas alternativas oficiais são: fazer uma avaliação por ano e entregar a prova aos clientes, ou ser avaliado sob demanda por cada cliente e participar da avaliação de cada um, entregando o resultado a cada um. Na segunda, você troca um exercício por ano por uma fila deles, com times diferentes, prazos diferentes e escopos diferentes. Para quem tem carteira relevante, costuma sair mais caro em dinheiro e em tempo de time técnico.
É a novidade da versão 4 que permite atender ao objetivo de um requisito com um controle diferente do que o padrão descreve. O texto é claro sobre para quem serve: empresas maduras em gestão de risco, dispostas a um esforço de documentação e validação maior que o da abordagem tradicional. Exige matriz de controles, análise de risco por controle e teste documentado de eficácia, e precisa ser documentada por um QSA ou por um avaliador interno qualificado. Quem faz autoavaliação não pode usar. Também não combina com controle compensatório. Costuma fazer sentido em arquitetura moderna, onde o controle real não se parece com o texto do padrão.
A v4.0.1, publicada em junho de 2024. A v4.0 foi aposentada em dezembro de 2024, então ela é a única versão ativa. O modelo de Report on Compliance está na revisão 3, de janeiro de 2025. Vale registrar a data que pega muita gente: a maior parte dos requisitos novos da versão 4 era só recomendação até 31 de março de 2025 e virou obrigação nessa data. Programa documentado antes disso e não revisado provavelmente tem lacuna.
Depende de duas coisas que só ficam claras no diagnóstico: o tamanho real do escopo e quanto dele dá para reduzir logo no começo. A gente não publica prazo padrão porque seria chute, e porque o PCI SSC não divulga duração típica de projeto. O que dá para dizer com segurança é que a definição de escopo é o que mais mexe no cronograma, e que contratar avaliação antes de saber o tamanho do ambiente costuma custar um ciclo inteiro.
O PCI SSC não publica estatística de reprovação, então a gente não repete ranking de blog. O que o próprio material oficial avisa é útil e dá para checar: o requisito não conta como atendido só por estar planejado para depois; a resposta não pode ser copiada de outro requisito nem de ciclo anterior; e requisito excluído sem análise precisa ser marcado como não testado, o que aparece na atestação como avaliação parcial. No lado do escopo, a regra prática publicada é começar assumindo que tudo está em escopo até provar o contrário, e o avaliador confere o escopo por conta própria, anotando onde discordou do seu.
Mais dúvidas? Fale com a DM11
Uma conversa de trinta minutos costuma bastar para separar o que é obrigação de prestador, o que é de comerciante e qual rota de validação vale para o seu caso. Sem compromisso.