Versão 1.0 · 30 de julho de 2026 · revisão anual
Por que isto é público. Toda área de segurança que avalia um fornecedor pede estes documentos — e, no BPO financeiro, quem pergunta muitas vezes é o cliente do seu cliente. Publicá-los evita a semana perdida entre a pergunta e a resposta, e nos obriga a manter escrito aquilo que de fato praticamos.
São seis políticas curtas. Elas descrevem a operação real de hoje, não um estado desejado: onde algo ainda não é feito, está dito que não é.
Objetivo. Proteger a confidencialidade, a integridade e a disponibilidade dos dados que os escritórios confiam ao BPOx — e, por consequência, dos dados que os clientes deles confiaram a eles.
Alcance. Toda pessoa com acesso a sistemas de produção, ao repositório de código ou a dados de cliente, seja empregada, sócia ou prestadora.
Princípios que governam as decisões técnicas:
Responsável. A direção da Produtize responde pela política. Revisão anual, ou a qualquer momento após incidente relevante.
Concessão. Acesso a sistemas de produção é concedido pela direção, individualmente e pelo menor privilégio necessário à função. Não há credencial compartilhada entre pessoas.
Autenticação. Verificação em duas etapas é obrigatória para todo acesso administrativo ao provedor de banco de dados, ao provedor de hospedagem, ao meio de pagamento e ao provedor de e-mail. Dentro do produto ela ainda não existe para os usuários — está no plano, e está dito na página de Segurança.
Chaves de serviço. A chave de privilégio elevado do banco e a chave de criptografia das credenciais de ERP existem apenas como variáveis de ambiente no servidor. Nunca são versionadas, nunca vão ao navegador e são rotacionadas em caso de suspeita de exposição.
Revisão. Trimestral, com registro do que foi revisado e do que foi revogado. Inclui a conferência de quem tem privilégio de administrador da plataforma — a lista deve ser curta e conhecida.
Saída. Acesso revogado no mesmo dia útil do desligamento, em todos os sistemas, com registro.
Acesso a dados de cliente. A equipe da plataforma tem acesso à assinatura, ao consumo agregado e ao atendimento — não à operação do escritório. Acesso ao conteúdo de um escritório ocorre apenas pelo modo de suporte, a pedido dele, com faixa visível na tela durante todo o tempo, expiração automática em 6 horas e registro no log do próprio escritório.
O que é incidente. Acesso não autorizado a dado de cliente, indisponibilidade acima de quatro horas, perda de dado, exposição de credencial — nossa ou de ERP de cliente — ou envio indevido de dado a terceiro.
Primeiras horas:
Dados pessoais. Havendo risco relevante aos titulares, comunicação à ANPD e aos titulares conforme a LGPD, em prazo razoável a contar da ciência.
Depois. Registro do que causou, do que foi corrigido e do que muda para não repetir — publicado ao escritório afetado. Correção de causa vira teste automatizado sempre que possível.
Canal. seguranca@bpox.com.br, com resposta em até dois dias úteis.
Verificação obrigatória. Nenhuma alteração vai a produção sem compilar e passar pela verificação automática. Falha bloqueia a publicação.
Alterações de banco. Versionadas em arquivos, sempre idempotentes — podem rodar de novo sem estragar nada. Arquivo já aplicado não é editado: correção é arquivo novo, o que preserva a trilha do que foi feito e quando. Mudança que fecha uma falha crítica vai em transação própria, para que nenhuma outra parte do arquivo possa abortá-la.
Regras que exigem teste. Toda regra nova de acesso ou isolamento entra acompanhada de teste que tenta violá-la contra um banco PostgreSQL de verdade e verifica o efeito da tentativa.
Mudança que mexe em dinheiro ou em número entregue ao cliente final — cobrança, cota, importação de ERP, relatório — entra com verificação de cenário: o caso normal, o caso de borda e o caso em que a fonte externa responde errado.
Reversão. A publicação anterior permanece disponível na hospedagem e pode ser restaurada. Alterações de banco são projetadas para não destruir dado.
Cópias de segurança. Automáticas na infraestrutura de banco, com retenção conforme o plano contratado com o provedor.
Teste de restauração. Executado e cronometrado ao menos uma vez por ano, com registro do tempo e do resultado.
Objetivos declarados. Recuperação em até quatro horas; perda máxima aceitável de vinte e quatro horas de dado. São objetivos operacionais; o compromisso contratual é o da cláusula 10 dos Termos.
Saída de dados sem depender de nós. A exportação em planilha de tarefas, horas apontadas e financeiro está na interface e não exige a nossa participação. A exportação completa da base ainda passa por pedido — está declarado como pendência na página de Segurança e é uma prioridade nossa justamente porque continuidade que depende do fornecedor não é continuidade.
Dependência de fornecedor único. Reconhecida: banco e hospedagem estão concentrados em Supabase e Vercel. O formato é PostgreSQL padrão, sem recurso proprietário que impeça a migração, mas uma troca exigiria trabalho e não é instantânea.
Dependência de ERP de terceiro. A importação depende de APIs que não controlamos. Quando um provedor muda a API ou fica fora do ar, o financeiro do mês continua podendo ser lançado à mão ou por planilha — a operação do escritório não para por causa da integração.
Critério. Fornecedor que toca dado de cliente precisa de contrato aceito, acordo de tratamento de dados quando aplicável e localização de dados conhecida.
Registro. A lista completa de terceiros que participam do serviço é pública, na página de Segurança, com o que cada um recebe. A mesma lista aparece na Política de Privacidade, e as duas andam juntas.
Fornecedor novo que receba dado de cliente exige decisão registrada antes da adoção, com a pergunta explícita: o que sai daqui, e isso contradiz o que prometemos?
Provedor de IA. Recebe tratamento próprio nessa avaliação, porque recebe conteúdo de negócio. Condições exigidas: vedação contratual de treinamento com o conteúdo enviado, recurso opcional para o escritório, escopo mínimo de dados por chamada e teto de consumo por escritório.
Revisão anual da lista e das condições contratadas.
Não há auditoria independente. Estas políticas são nossas e não foram verificadas por terceiro. Não temos SOC 2 nem ISO 27001.
Não há teste de intrusão por empresa externa. Nossos testes de ataque são internos e automatizados.
Não há verificação em duas etapas dentro do produto, nem acesso corporativo por provedor de identidade. Estão no plano.
A operação é enxuta. Segregação de funções é limitada pelo tamanho da equipe — e dizer isso é mais útil do que descrever um organograma que não existe.
Publicamos assim mesmo porque um documento honesto e incompleto vale mais, numa avaliação de fornecedor, do que um documento completo e inventado.