A segurança é o produto.

O Comerciante confia à Paybyrd dois bens dificilmente recuperáveis em caso de dano: o seu dinheiro em trânsito e os dados de cartão dos seus clientes. A nossa promessa é que ambos são tratados com mais cuidado do que os nossos próprios. A empresa opera sob a supervisão de reguladores de serviços financeiros, detém a certificação PCI DSS Nível 1 — o mais elevado nível de comerciante/prestador de serviços da indústria de cartões de pagamento — e trata os dados de titulares de cartão como radioativos: são tocados pelo menor número possível de sistemas, pelo menor número possível de pessoas e pelo menor número possível de motivos que o serviço permite.

Esta página abrange a totalidade do parque de produção dos serviços de pagamento da Paybyrd: as APIs públicas, o painel do comerciante, a frota POS e a plataforma de suporte onde correm autorizações, capturas, reembolsos e entrega de webhooks. TI corporativa e ferramentas internas regem-se por políticas equivalentes mas encontram-se fora do âmbito deste documento.

Os compromissos que se seguem são escritos para serem verificáveis. Toda a afirmação nesta página é algo que estamos preparados para demonstrar num questionário de segurança, numa auditoria do regulador ou num exame de esquema de cartões.

A Paybyrd alinha o seu programa de segurança pelos referenciais relevantes em pagamentos, na UE e nas jurisdições em que atua.

• PCI DSS Nível 1 — certificada. Relatório anual de Conformidade (RoC) emitido todos os 12 meses por um Qualified Security Assessor independente; varrimentos ASV trimestrais contra a ingestão pública; atestação disponibilizada ao Comerciante sob NDA.
• ISO/IEC 27001 — sistema de gestão da segurança da informação mantido em toda a plataforma; certificação independente em curso.
• SOC 2 Tipo II — relatório em preparação, com janela de observação de 12 meses iniciada em 2026; bridge letter disponível mediante pedido após a emissão do primeiro relatório.
• PSD2 — autenticação forte do cliente. Os fluxos de autenticação implementam SCA conforme as RTS, com tratamento de exceções (TRA, valor reduzido, MIT) e 3-D Secure 2.x para transações de cartão à distância.
• RGPD. Pleno alinhamento com o Regulamento (UE) 2016/679 e a respetiva legislação nacional; DPO designado; registos de atividades de tratamento mantidos; procedimento de notificação de violações alinhado com os artigos 33.º e 34.º (ver Política de Privacidade).
• NIS2. Quando a Diretiva se aplica à Paybyrd ou a uma entidade do grupo, operamos um regime alinhado de gestão de risco, cadeia de fornecimento e reporte de incidentes.

Não reivindicamos certificações que não detemos. Quando um controlo ou certificação se encontra em curso, dizemo-lo.

A plataforma é concebida de modo a que o comprometimento de qualquer componente isolado não comprometa os dados de titulares de cartão nem a via de movimentação de dinheiro.

• Tokenização do PAN na ingestão. Os números primários de conta (PAN) são tokenizados no primeiro sistema que os observa; os serviços a jusante detêm e transmitem tokens, não PAN. A destokenização está protegida, auditada e limitada ao conjunto mínimo de processos que dela necessita.
• Cifra em trânsito. TLS 1.2+ aplicado em todos os endpoints públicos (TLS 1.0 e 1.1 desativados); HSTS com preload; apenas suites de cifra modernas; mTLS para comunicações serviço-a-serviço sensíveis e integrações com parceiros que o exijam.
• Cifra em repouso. Cifra AES-256 para todos os repositórios de dados de produção, backups e snapshots; domínios de cifra separados para dados no âmbito PCI.
• Gestão de chaves. As chaves criptográficas são geradas, armazenadas e utilizadas em infraestrutura de gestão de chaves suportada por HSM; a utilização das chaves é registada; a rotação segue uma cadência publicada com procedimentos de re-cifra de emergência.
• Segmentação de rede. A produção corre em VPCs isoladas com subredes privadas, NAT apenas de saída e sem alcançabilidade de entrada a partir da Internet para computação. O âmbito PCI DSS é um ambiente distinto, com a sua própria ingestão, identidades e controlo de alterações.
• Registos de auditoria imutáveis. Os eventos relevantes para a segurança — autenticação, autorização, alterações de configuração, acessos a dados — são escritos em armazenamento append-only com retenção resistente a adulteração adequada a análise forense.

Quem pode tocar a produção é tão importante quanto a forma como a produção é construída.

• Privilégio mínimo. O acesso é concedido através de controlo de acesso baseado em funções, provisionado a partir dos sistemas de RH e revisto face à função do colaborador. O valor por defeito é ausência de acesso.
• MFA por chave de hardware. As chaves de segurança por hardware (WebAuthn / FIDO2) são obrigatórias para todo e qualquer ponto de acesso à produção — SSO, consola de cloud, bastion, pipelines de deployment, ferramentas administrativas. Códigos de uso único por software não são aceites para produção.
• Revisões trimestrais de acesso. Todo o direito sobre produção é recertificado, pelo menos, a cada 90 dias pelo responsável hierárquico; concessões desatualizadas são revogadas automaticamente no termo da janela de revisão.
• Elevação just-in-time. Para resposta a incidentes e tarefas operacionais raras, o acesso privilegiado é obtido através de concessões JIT com limite temporal e justificação documentada; os direitos permanentes de administração são evitados sempre que possível.
• Gravação de sessão. As shells privilegiadas são gravadas e conservadas para reprodução forense.
• SLA de offboarding. Em caso de cessação ou alteração de função, o acesso a produção é revogado no prazo de uma hora a contar do evento de RH que o despoleta, independentemente do horário de expediente.

Os ataques são detetados pelos controlos que os observam, e não pela esperança.

• Correlação SIEM 24/7. A telemetria de segurança da plataforma, do plano de controlo da cloud, dos endpoints e dos fornecedores de identidade é centralizada e correlacionada em tempo real; as regras de deteção cobrem técnicas de atacante conhecidas e são afinadas ao modelo de ameaça específico da Paybyrd.
• Deteção de anomalias. Eventos de autenticação, fluxos de transação e padrões de utilização de API são modelados quanto a desvio; comportamentos anómalos desencadeiam contenção automatizada e revisão humana.
• Piquete e SLA de pager. Um piquete de segurança responde a alertas Sev-1 em 15 minutos, 24/7. Os piquetes de engenharia, plataforma e fraude são acionados em paralelo para incidentes que atravessem domínios.
• Dotação SOC. A monitorização é assegurada por uma função interna de operações de segurança, apoiada por um parceiro de deteção gerida devidamente avaliado para cobertura fora de horas; os runbooks de transferência são ensaiados.

Detetar problemas cedo é mais barato do que explicá-los mais tarde.

• Testes de intrusão por terceiros. Pentests independentes são contratados, pelo menos, trimestralmente, abrangendo as APIs públicas, o painel do comerciante, o parque POS e a superfície interna autenticada. As conclusões são acompanhadas até encerramento com SLA de remediação.
• SAST e DAST contínuos. A análise estática e o teste dinâmico de segurança aplicacional correm em cada deployment; os pipelines bloqueiam merges que introduzam descobertas críticas.
• Análise de composição de software. Todas as dependências são continuamente avaliadas contra feeds CVE de referência; os patches críticos são disponibilizados com um SLA de 7 dias a partir da divulgação, menor quando é observada exploração ativa.
• Bug bounty. A Paybyrd opera um programa de divulgação responsável aberto a investigadores de segurança de boa-fé. Os reportes deverão ser dirigidos a security@paybyrd.com.
• Safe harbour. A investigação de boa-fé dentro do âmbito do programa está autorizada e não será objeto de ação legal por parte da Paybyrd. Os investigadores que respeitem o âmbito, evitem a degradação do serviço e não exfiltrem ou divulguem dados além do estritamente necessário para evidenciar uma descoberta estão abrangidos por este safe harbour.

Os incidentes são ensaiados, não improvisados.

• Classificação. Os incidentes são triados em quatro severidades — Sev-1 (pagamentos sistemicamente impactados, suspeita de violação de dados, exposição regulatória), Sev-2 (degradação significativa sem impacto sistémico), Sev-3 (impacto localizado ou num único comerciante/parceiro), Sev-4 (baixo impacto, com workaround disponível).
• Notificação de violação em 72 horas. Quando uma violação de dados pessoais atinge o limiar do artigo 33.º do RGPD, a Paybyrd notifica a autoridade de controlo competente sem demora injustificada e, sempre que possível, no prazo de 72 horas. Os comerciantes afetados são notificados em paralelo para que possam cumprir as suas próprias obrigações enquanto responsáveis pelo tratamento; quando a violação seja suscetível de implicar elevado risco para os titulares, segue-se a notificação do artigo 34.º sem demora injustificada.
• Reporte a esquemas e reguladores. Os reportes operacionais aos esquemas de cartões e as notificações ao regulador financeiro são apresentados nos prazos previstos nas regras aplicáveis.
• Exercícios mensais de IR. A equipa de resposta executa pelo menos um exercício tabletop ou técnico por mês, abrangendo uma rotação de cenários (ransomware, comprometimento de chaves, onda de fraude, indisponibilidade de terceiro).
• Post-mortem público. Para cada Sev-1 que afete o Comerciante, a Paybyrd publica uma revisão pós-incidente na página de estado dentro de um prazo razoável, descrevendo impacto, causa-raiz e remediação.

Os dados são tratados segundo o princípio de que o registo mais seguro é aquele que nunca recolhemos, e o segundo mais seguro é aquele que já destruímos.

• Residência. Os dados de produção da plataforma de pagamentos são armazenados por defeito no Espaço Económico Europeu (região primária: eu-central-1, Frankfurt). As transferências transfronteiriças apenas ocorrem com salvaguardas adequadas do artigo 46.º e encontram-se documentadas na Política de Privacidade.
• Conservação. Os dados são conservados pelos períodos exigidos por obrigações legais, regulatórias e de esquema, conforme estabelecido na Política de Privacidade. A retenção é imposta por automatismos, não por memória.
• Destruição. No termo da retenção, os dados são destruídos através de cryptographic shredding — as chaves de cifra que protegem os dados são destruídas no HSM, tornando o texto cifrado irrecuperável — em acréscimo à eliminação lógica no repositório.
• Separação de ambientes. Os ambientes live e sandbox estão estritamente separados: redes separadas, identidades separadas, chaves separadas, conjuntos de dados separados. Os dados de produção não são utilizados em sandbox nem em desenvolvimento.

Os pagamentos não podem parar, e a plataforma é projetada para continuar a funcionar quando componentes falham.

• Deployment multi-AZ. Os serviços de pagamento centrais correm em múltiplas zonas de disponibilidade dentro de uma região; a perda de uma única zona é esperada e tratada automaticamente.
• Failover automatizado. Os primários das bases de dados, gateways de API e brokers de mensagens são configurados para failover automatizado com routing sujeito a health checks.
• RTO e RPO. Para os serviços de pagamento em produção, o objetivo de tempo de recuperação é ≤ 4 horas e o objetivo de ponto de recuperação é ≤ 15 minutos para um evento ao nível regional que exija a ativação do plano de recuperação de desastre.
• Exercícios tabletop. Os planos de continuidade de negócio e de recuperação de desastre são exercitados pelo menos trimestralmente, com, pelo menos, um exercício de âmbito total por ano que abranja engenharia, segurança, operações e funções de atendimento.