Engenharia PCI DSS para equipes de pagamentos: construímos os controles, seu avaliador os valida
O PCI DSS v4.0.1 se aplica a toda entidade que armazena, processa ou transmite dados do titular do cartão ou dados sensíveis de autenticação, ou pode afetar a sua segurança. Boa parte dos seus 12 requisitos recai sobre a engenharia: escopo e segmentação, criptografia, software seguro, acesso e MFA, logs, varreduras e testes. Construímos esses controles. Um Avaliador de Segurança Qualificado (QSA) ou a sua própria autoavaliação os valida, e o seu adquirente e as bandeiras de pagamento decidem qual. Não avaliamos nem atestamos.
- Seu QSA ou adquirente
- Avalia o seu escopo, ou recebe o seu atestado
- Sua empresa
- Nossos engenheiros constroem os controles no seu ambiente
- Clouditive
A Clouditive não avalia, não atesta nem assina um Atestado de Conformidade
A norma
O que o PCI DSS v4.0.1 pede da engenharia?
O PCI DSS v4.0.1 (junho de 2024) tem 12 requisitos principais: controles de segurança de rede, configurações seguras, proteção dos dados de conta armazenados, criptografia na transmissão, proteção contra malware, sistemas e software seguros, acesso conforme a necessidade de conhecer, identificação e autenticação, acesso físico, registro e monitoramento, testes periódicos e políticas organizacionais. A engenharia carrega a maior parte dos Requisitos 1 a 8, 10 e 11. Se você deve cumprir ou validar, e como, é decidido pelas bandeiras de pagamento e pelo seu adquirente.
Os requisitos que a v4.0 marcou como boa prática até 31 de março de 2025 agora são obrigatórios. O PCI DSS v4.0 foi aposentado em 31 de dezembro de 2024, e a v4.0.1 não acrescentou nem removeu requisitos. Esta é a versão que lemos.
Escopo
O que decide quanto da sua stack entra no escopo?
Os requisitos se aplicam ao ambiente de dados do titular do cartão, os sistemas que armazenam, processam ou transmitem dados de conta, e aos sistemas que podem afetar a sua segurança. Terceirizar as operações de pagamento não tira de você a responsabilidade de garantir que os dados de conta estejam protegidos. O escopo deve ser documentado e confirmado ao menos a cada 12 meses e após uma mudança significativa (12.5.2), e exige-se um diagrama de fluxo de dados preciso (1.2.4).
É na engenharia que o escopo se ganha ou se perde: quais serviços veem um número de cartão, como as redes são segmentadas, onde um token substitui os dados do cartão. Mapeamos os fluxos de dados e propomos a arquitetura que mantém os dados de cartão no menor número de sistemas. A decisão de escopo, e se a sua segmentação é aceita, cabem à sua empresa e ao seu avaliador.
O que não afirmamos
O que não afirmamos?
Não temos nenhum Atestado de Conformidade PCI DSS. Não somos um QSA, um Avaliador de Segurança Interno nem um Fornecedor Aprovado de Varredura (ASV), e não temos nenhum caso publicado de pagamentos.
- O nosso caso fintech é de análise de investimentos, não de pagamentos. Os casos linkados abaixo mostram os mesmos controles em outros trabalhos, e não são uma implementação do PCI DSS.
- Não preenchemos o seu Relatório de Conformidade (ROC) nem o seu questionário de autoavaliação, não assinamos um Atestado de Conformidade nem rodamos as varreduras externas de vulnerabilidades, que devem vir de um Fornecedor Aprovado de Varredura (11.3.2).
- As políticas, a decisão de escopo, a gestão dos seus provedores de serviço e a segurança física dos seus locais ficam com a sua empresa.
- Não garantimos o resultado de uma avaliação, e não afirmamos nenhuma parceria com um processador de pagamentos nem com uma plataforma de automação de conformidade (GRC).
Os controles
Quais requisitos a equipe de engenharia constrói?
Seis grupos de requisitos recaem sobre a engenharia: escopo e segmentação, proteção dos dados de conta, software seguro e mudanças, acesso e MFA, registro, e varreduras com resposta a incidentes. Para cada um: o que o requisito pede, o trabalho de engenharia e onde o fizemos em um caso publicado.
Escopo, segmentação e fluxos de dados
O que exige da engenhariaPara onde vão os dados de cartão e o que está conectado a eles?
O Requisito 1 cobre os controles de segurança de rede, o 1.2.4 pede um diagrama de fluxo de dados preciso e o 12.5.2 um escopo documentado e confirmado ao menos a cada 12 meses. A engenharia: infraestrutura definida como código, para que a rede seja o diagrama; caminhos com negação por padrão entre segmentos; e um mapa de fluxo de dados guardado no repositório ao lado do código que o altera.
Onde já fizemos
- Toda a plataforma do Google Cloud é OpenTofu, coberta por 43 testes com provedores simulados que rodam sem tocar a conta da nuvem.Ler o caso da plataforma de marketing com IA
- O plano do Terraform tem um freio que barra mudanças destrutivas.Ler o caso da plataforma proptech de moradia
- O serviço fica atrás de um balanceador HTTPS global com um WAF do Cloud Armor.Ler o caso da plataforma de marketing com IA
Entregue por
- CI/CD e IaC: construção ou reestruturaçãoUS$ 4.000 · 2 semanas
Proteção dos dados de conta
O que exige da engenhariaQuais dados de conta você guarda, de que forma e como eles trafegam?
O 3.3.1 pede que os dados sensíveis de autenticação não sejam armazenados após a autorização, mesmo criptografados, e o 3.5.1 que o PAN fique ilegível onde quer que seja armazenado. O 4.2.1 pede criptografia forte e protocolos de segurança quando o PAN cruza redes públicas abertas. A engenharia: guardar só o necessário, tokenizar ou truncar o resto, chaves gerenciadas, TLS em cada caminho e caminhos de rede privados até os repositórios de dados.
Onde já fizemos
- O Cloud SQL roda com IP privado, com KMS e Workload Identity.Ler o caso da plataforma de marketing com IA
- O serviço fica atrás de um balanceador HTTPS global com um WAF do Cloud Armor.Ler o caso da plataforma de marketing com IA
- A borda da Cloudflare usa DNSSEC, CAA e MTA-STS.Ler o caso da plataforma proptech de moradia
Nenhum pacote fixo cobre criptografia e proteção de dados sozinhas. Definimos o escopo no Discovery ou com engenheiros por hora.
Software seguro e mudanças
O que exige da engenhariaComo o software sob medida é desenvolvido com segurança e como uma mudança chega à produção?
O 6.2.1 e o 6.2.4 pedem desenvolvimento seguro e técnicas que previnam os ataques de software comuns, o 6.3.2 um inventário do software sob medida e dos seus componentes de terceiros, e o 6.5.1 mudanças feitas com motivo, impacto de segurança, aprovação e testes. O 6.4.3 pede que cada script carregado em uma página de pagamento seja autorizado, tenha a integridade verificada e esteja inventariado, e o 11.6.1 detecção de mudanças e adulteração nas páginas de pagamento. A engenharia: um pipeline cujos gates podem barrar um release, inventários de dependências e de scripts, e releases rastreáveis.
Onde já fizemos
- A produção espera uma hora sob observação e precisa passar por gates de saúde e de taxa de erros. O rollback por nova promoção foi ensaiado em dev: 72 segundos para voltar, 124 para avançar.Ler o caso do pipeline de releases fintech
- Uma tag de release constrói as imagens, roda as migrações, faz o deploy por digest de imagem e lê de volta o digest que está realmente no ar.Ler o caso da plataforma de marketing com IA
- Cada release é uma imagem assinada com cosign, implantada sem tráfego, verificada e só então promovida.Ler o caso do portal govtech de coordenação
- Um gate antes do push verifica segredos, tipos, lint e build antes de o código sair da máquina do engenheiro.Ler o caso do portal govtech de coordenação
Entregue por
- CI/CD e IaC: construção ou reestruturaçãoUS$ 4.000 · 2 semanas
- Fundamentos de automação de QAUS$ 5.000 · 2 semanas
Controle de acesso e MFA
O que exige da engenhariaQuem pode chegar ao ambiente de dados do titular do cartão e como prova quem é?
O Requisito 7 restringe o acesso conforme a necessidade de conhecer, e o Requisito 8 pede identificação e autenticação, incluindo o 8.4.2, MFA para todo acesso sem console ao ambiente de dados do titular do cartão. A engenharia: identidades no seu SSO, MFA, privilégio mínimo, segredos em um cofre gerenciado e identidade de workload para os serviços. Nossos engenheiros usam as suas contas, e o acesso é revogado quando o contrato termina.
Onde já fizemos
- Os segredos ficam em um cofre de segredos gerenciado, e o gate de vulnerabilidades roda em cada merge request.Ler o caso do pipeline de releases fintech
- O Cloud SQL roda com IP privado, com KMS e Workload Identity.Ler o caso da plataforma de marketing com IA
- O envio de e-mail pelo Gmail usa delegação de domínio, então nenhuma chave de e-mail é armazenada.Ler o caso do portal govtech de coordenação
- A stack de observabilidade é lida no Grafana com single sign-on.Ler o caso de engenharia de plataforma em transporte
Nenhum pacote fixo cobre o controle de acesso sozinho. Definimos o escopo no Discovery ou com engenheiros por hora.
Registro e monitoramento
O que exige da engenhariaOs logs de auditoria estão ativos em cada componente, são mantidos por tempo suficiente e alguém os acompanha?
O 10.2.1 pede que os logs de auditoria estejam habilitados e ativos em todos os componentes e dados do titular, e o 10.5.1 que o histórico seja mantido por ao menos 12 meses, com os últimos três meses disponíveis de imediato para análise. A engenharia: logs de cada componente em um só lugar, desenhados para que números de cartão nunca caiam em uma linha de log, alertas testados até dispararem e um runbook.
Onde já fizemos
- De zero alertas em produção a 275 regras de alerta, cada uma testada até disparar.Ler o caso do pipeline de releases fintech
- Coletores do OpenTelemetry em cada cluster enviam para Mimir, Loki, Tempo e Pyroscope centrais. Os dashboards foram de 18 para 135.Ler o caso de engenharia de plataforma em transporte
- Os traces do OpenTelemetry vão para o Google Cloud e 18 políticas de alerta vigiam o serviço.Ler o caso da plataforma de marketing com IA
Entregue por
- Fundamentos de SRE e observabilidadeUS$ 5.000 · 2 semanas
Varreduras, testes e resposta a incidentes
O que exige da engenhariaCom que frequência você varre e testa, e qual é o plano quando algo dá errado?
O 11.3.1 pede varreduras internas de vulnerabilidades ao menos a cada três meses, com novas varreduras até resolver os achados críticos e de alto risco, o 11.4.1 uma metodologia de testes de intrusão definida, e o 12.10.1 um plano de resposta a incidentes que inclua avisar as bandeiras de pagamento e os adquirentes e cubra recuperação e backup de dados. A engenharia: varreduras no pipeline em cada mudança com exceções que expiram, e um runbook que diz quem decide e quem é avisado.
Onde já fizemos
- Um gate de vulnerabilidades orientado a SOC 2 roda em cada merge request, com exceções que expiram. Não é uma certificação.Ler o caso do pipeline de releases fintech
- Desde fevereiro de 2026 um workflow compartilhado roda varreduras de dependências, segredos, CodeQL e contêineres. O reforço da cadeia de suprimentos de CI está em andamento.Ler o caso de engenharia de plataforma em transporte
- Os backups são criptografados e agendados, e o ensaio de restauração recupera os dados em 13 segundos.Ler o caso da plataforma de RPG online
Entregue por
- CI/CD e IaC: construção ou reestruturaçãoUS$ 4.000 · 2 semanas
Os testes de intrusão e as varreduras externas trimestrais vêm de terceiros independentes e qualificados. Nós construímos as varreduras que rodam no seu pipeline.
Como entregamos
Como os nossos pacotes e engenheiros entregam isso?
Comece com um pacote de preço fixo, ou contrate engenheiros por hora. O pacote de CI/CD e IaC constrói o pipeline e a infraestrutura como código. Os Fundamentos de SRE e observabilidade conectam o monitoramento. Os Fundamentos de automação de QA colocam testes no seu CI. O Discovery transforma o seu diagrama de escopo, os achados do seu avaliador ou as lacunas da sua autoavaliação em um roadmap com backlog.
Pipeline e infraestrutura como código
Uma construção ou redesenho de 2 semanas dos seus pipelines de CI/CD e da sua infraestrutura como código. Os gates que entram no pipeline, como uma varredura de vulnerabilidades, são combinados no SOW.
Entregue por
- CI/CD e IaC: construção ou reestruturaçãoUS$ 4.000 · 2 semanas
Registro e monitoramento
Métricas, logs e traces conectados, 3 SLOs definidos, alertas testados até dispararem e um runbook.
Entregue por
- Fundamentos de SRE e observabilidadeUS$ 5.000 · 2 semanas
Testes em cada mudança
Uma suíte de Playwright para os seus 5 fluxos críticos, rodando no seu CI, com verificações de acessibilidade.
Entregue por
- Fundamentos de automação de QAUS$ 5.000 · 2 semanas
Da lista de requisitos a um backlog
O Discovery entende o seu produto e a configuração dele de ponta a ponta e entrega um roadmap com backlog, papéis, mudanças críticas e necessidades. Traga o seu diagrama de escopo, os achados do avaliador ou as lacunas da sua autoavaliação e os transformamos em trabalho de engenharia.
Entregue por
- DiscoveryUS$ 7.000 · 1 a 4 semanas
Engenheiros por hora
Para o trabalho que continua depois de um pacote: Sênior US$ 45–50 por hora, Líder ou Arquiteto US$ 55–60, com mínimo de 6 meses, faturado por hora trabalhada. Você entrevista o engenheiro que fará o trabalho.
Fontes
Quais textos lemos?
Textos primários, lidos em 2026-10-09.
- Payment Card Industry Data Security Standard: Requirements and Testing Procedures, v4.0.1, junho de 2024, PCI Security Standards Council. Seções 2 e 11 a 12, Requisitos 1 a 12.
- PCI Security Standards Council, "Just Published: PCI DSS v4.0.1", sobre a aposentadoria da v4.0 e a data de 31 de março de 2025.
Perguntas frequentes
A Clouditive está em conformidade com o PCI DSS ou é certificada?
Não. Não temos nenhum Atestado de Conformidade PCI DSS e não afirmamos nenhum para nenhum cliente. A norma pede conformidade às entidades que lidam com dados de cartões, e as bandeiras de pagamento e os adquirentes decidem como a conformidade é validada.
Vocês podem substituir o nosso QSA?
Não. Um QSA é uma empresa qualificada pelo PCI Security Standards Council para avaliar e redigir o Relatório de Conformidade. Construímos os controles de engenharia que essa avaliação testa, e não somos um QSA.
Vocês têm um cliente de pagamentos?
Não temos nenhum caso publicado de pagamentos. O nosso caso fintech é de análise de investimentos. Os casos linkados nesta página mostram os mesmos controles em trabalhos de análise fintech, govtech, proptech, IA e transporte.
Vocês conseguem reduzir o nosso escopo de PCI?
Desenhamos a arquitetura para que os dados de cartão fiquem no menor número de sistemas, e documentamos os fluxos de dados. Se o resultado é aceito quem decide é o seu avaliador. Terceirizar as operações de pagamento não tira de você a responsabilidade de garantir que os dados de conta estejam protegidos.
Em qual versão do PCI DSS vocês trabalham?
Na 4.0.1, publicada em junho de 2024. O PCI DSS v4.0 foi aposentado em 31 de dezembro de 2024, e os requisitos que eram boa prática até 31 de março de 2025 agora são obrigatórios.
Quanto tempo leva para ficar pronto?
Depende do seu escopo e do que você já tem, e não damos nenhuma garantia sobre uma avaliação. Um pacote de 2 semanas constrói uma área, como o pipeline de CI/CD e a infraestrutura como código, e o Discovery, de 1 a 4 semanas, transforma o resto em um roadmap.
Como isso se relaciona com SOC 2 e os outros frameworks?
A engenharia se sobrepõe bastante: releases com gates, acessos demonstráveis, alertas testados e recuperação ensaiada servem a vários frameworks ao mesmo tempo. A página de engenharia de conformidade mostra qual cláusula de cada framework pede qual controle.
Como os engenheiros acessam os nossos sistemas?
Pelas suas próprias contas e identidades, com o seu SSO, o seu MFA e acesso de privilégio mínimo, revogado quando o contrato termina. Todo engenheiro passa por uma verificação de antecedentes antes de ser alocado.
Quem faz o trabalho?
Mat Caniglia lidera cada projeto de ponta a ponta, e os engenheiros estão na América Latina e compartilham o seu dia de trabalho. Apresentamos candidatos em até 1 semana, e você entrevista o engenheiro que fará o trabalho.
O que você precisa resolver?
Respondemos a todo pedido em até 1 dia útil. Assinamos um NDA antes da conversa, se você pedir.