Política de Segurança da Informação do Customer Builder

1. Abrangência e responsabilidades

A Política abrange produção, desenvolvimento, testes, dispositivos de trabalho, repositórios, documentos, credenciais, integrações, provedores de IA, dados de leads e cópias de segurança. Aplica-se a administradores, empregados, prestadores e terceiros autorizados, na extensão de suas atividades e contratos.

A direção deverá aprovar a Política, atribuir responsáveis e prover recursos compatíveis com o risco. O responsável de segurança deverá coordenar controles e incidentes. O responsável de privacidade deverá avaliar direitos, bases legais e comunicações. Engenharia deverá aplicar os controles técnicos, e o suporte deverá seguir procedimentos de identificação, acesso e encaminhamento. Fornecedores deverão cumprir obrigações contratuais equivalentes.

O Cliente deverá gerir usuários, dispositivos e integrações sob seu controle, revisar permissões, proteger suas credenciais e comunicar suspeitas. A divisão de responsabilidades não afasta deveres próprios da Fornecedora nem transfere ao Cliente falhas de isolamento ou proteção da infraestrutura contratada.

2. Inventário, classificação e minimização

Ativos e fluxos relevantes deverão ser inventariados com proprietário, finalidade, localização, categoria de informação e dependências. Dados pessoais, estratégias de Marca, bases de leads, prompts, chaves, tokens e backups deverão receber classificação proporcional à sensibilidade.

Deverá ser coletado e conservado apenas o necessário. Dados reais não deverão ser copiados para testes, demonstrações, ferramentas pessoais ou serviços de IA não autorizados. Quando seu uso excepcional for indispensável, deverá haver autorização, base legal, minimização, proteção equivalente e prazo de descarte.

3. Identidades, acessos e separação de contas

A concessão de acesso deverá observar necessidade funcional, privilégio mínimo, identificação individual, aprovação e registro. Contas compartilhadas deverão ser evitadas; acessos privilegiados deverão possuir autenticação conforme implantação validada. Usuários deverão receber instruções claras sobre os mecanismos de autenticação disponíveis.

Admissão, mudança de função e desligamento deverão acionar revisão ou revogação de permissões. Haverá revisão periódica e o acesso emergencial deverá ser limitado, registrado e revisto. Senhas não deverão ser enviadas em texto aberto nem recuperadas por suporte; o procedimento de redefinição deverá verificar a legitimidade do solicitante.

A autorização deverá ser aplicada no servidor e abranger conta, marca, projeto, objetos, arquivos, relatórios, APIs e tarefas de agentes. Testes deverão verificar acesso cruzado entre clientes e tentativas de adivinhar identificadores. Contextos, índices de busca, memória e arquivos utilizados por IA deverão respeitar os mesmos limites de isolamento.

Acesso humano a dados de clientes deverá ter motivo documentado, escopo mínimo e rastreabilidade. Atendimento a uma conta não autoriza copiar seus dados para outra nem incorporá-los ao conhecimento geral de Segmento.

4. Proteção técnica e segredos

Conexões que transportem dados ou credenciais deverão utilizar proteção criptográfica adequada. A proteção de armazenamento e backups, os algoritmos, os escopos cobertos e a gestão de chaves deverão estar definidos. Não se anunciará criptografia ponta a ponta se servidores ou provedores precisarem acessar conteúdo em texto legível.

Chaves de API, tokens, senhas técnicas e certificados deverão ser armazenados em solução apropriada, fora do código público e de registros desnecessários. Deverão existir mecanismos de rotação, revogação, restrição de escopo e resposta a exposição. Credenciais de um canal deverão limitar-se às contas e operações autorizadas.

Ambientes deverão ser separados, com proteção de rede, configuração segura e limitação de serviços expostos. Dispositivos e serviços administrativos deverão receber atualizações e proteção compatível com o risco. Alterações relevantes deverão ter responsável, revisão, validação e possibilidade de reversão.

5. Desenvolvimento seguro e vulnerabilidades

O ciclo de desenvolvimento deverá incluir revisão de código, análise de dependências e segredos, validação de entradas, controles de autorização e testes das funções críticas. Deverão ser consideradas injeções, falhas de sessão, acessos entre contas, arquivos maliciosos e execução indevida por integrações.

Vulnerabilidades deverão ser classificadas por gravidade, exposição e possibilidade de exploração. Os prazos de triagem, mitigação e correção serão definidos por gravidade; quando não houver correção imediata, deverão ser aplicadas medidas compensatórias e registrada a aceitação temporária de risco por responsável competente.

Pesquisadores poderão relatar falhas por e-mail para [email protected], com descrição, impacto e evidência mínima. O canal de relato não autoriza testes invasivos, exfiltração, acesso a dados alheios, indisponibilidade ou engenharia social. Testes ativos exigem autorização e escopo específicos. Não se presume programa de recompensa ou imunidade jurídica sem regulamento próprio.

6. Segurança de agentes e integrações

Agentes deverão operar com ferramentas, dados e ações previamente autorizados. Conteúdo externo, mensagens e documentos não deverão ser tratados como autorização para alterar regras de segurança, ampliar permissões ou enviar dados a destinatários não aprovados.

Deverão existir controles para reduzir injeção de instruções maliciosas em prompts, divulgação de segredos, mistura de contextos, uso de fontes não autorizadas e execução de ações com custo ou impacto indevido. Ações sensíveis deverão exigir aprovação humana ou limites previamente definidos e registrados.

Os procedimentos deverão permitir identificar o agente, instrução, contexto autorizado e ação realizada, respeitando minimização dos registros. Deverão ser previstos mecanismos de interrupção e revogação de ferramentas. Logs não deverão expor senhas, tokens ou conteúdo pessoal excessivo.

Conexões externas deverão utilizar escopos mínimos, validação de origem de webhooks, proteção contra repetição indevida e revogação quando desativadas. O inventário deverá distinguir fornecedor contratado pela Fornecedora de serviço conectado diretamente pelo Cliente.

7. Fornecedores e transferências

Fornecedores que acessem dados deverão passar por avaliação proporcional ao risco, incluindo finalidade, controles, subcontratações, países, retenção, exclusão, incidentes e uso de dados para treinamento. A aprovação deverá estar documentada antes do compartilhamento.

Contratos deverão impor confidencialidade, segurança, limites de uso, assistência e comunicação de incidentes. Certificações de um provedor não equivalem a certificação do Customer Builder. Transferências internacionais deverão observar os instrumentos válidos.

8. Registros, monitoramento e continuidade

Eventos relevantes de autenticação, administração, alteração de permissões, exportação e execução crítica deverão ser registrados com integridade e acesso restrito. A retenção deverá distinguir registros legalmente exigidos dos registros operacionais. Monitoramento deverá respeitar a Política de Privacidade e a finalidade de segurança.

Backups deverão observar frequência, retenção, proteção, segregação e testes de restauração. A restauração deverá reaplicar exclusões e listas de supressão. A existência de backup não equivale a capacidade comprovada de recuperação.

O plano de continuidade deverá identificar serviços essenciais, dependências, responsáveis, comunicação e recuperação. O tempo de recuperação pretendido e a perda máxima de dados tolerada, RTO e RPO, constarão e somente integrarão compromisso comercial quando expressamente contratados. Testes e resultados deverão ser registrados.

9. Resposta a incidentes

Qualquer suspeita deverá ser encaminhada por e-mail para [email protected]. A equipe deverá registrar os horários de detecção e de conhecimento, classificar gravidade, preservar evidências, conter o evento e avaliar impacto sobre dados, contas e serviços. Não deverá apagar evidências para acelerar o retorno da operação.

O responsável coordenará engenharia, privacidade, jurídico, suporte e fornecedores, limitando o acesso à investigação. A comunicação deverá distinguir fatos confirmados de hipóteses. Ações de contenção poderão incluir revogação de chaves, restrição de acessos, suspensão de automações e isolamento de componentes.

Quando atuarmos como operadora, o Cliente será avisado sem demora injustificada e no prazo máximo de 72 (setenta e duas) horas, com informações disponíveis e atualizações. Não será necessário concluir a causa raiz para emitir a comunicação inicial. O contato de emergência do Cliente deverá ser mantido atualizado.

Quando atuarmos como controladora e o incidente puder acarretar risco ou dano relevante aos titulares, a comunicação à ANPD e aos titulares deverá observar a Resolução CD/ANPD nº 15/2024: em regra, três dias úteis a partir do conhecimento de que o incidente afetou dados pessoais, ressalvadas as hipóteses legais. Informações à ANPD poderão ser complementadas justificadamente em vinte dias úteis. A contagem em dobro somente será considerada após comprovação de enquadramento no regime aplicável de pequeno porte; não decorre apenas de se apresentar como startup.

O conteúdo deverá incluir natureza e categorias de dados, pessoas afetadas, riscos, medidas e contato, conforme a norma. Incidentes com alcance internacional exigem análise das leis locais; o prazo brasileiro não substitui prazos estrangeiros. O prazo do operador também não prorroga o do controlador.

Registros de incidentes, inclusive dos não comunicados externamente, deverão ser mantidos por pelo menos cinco anos conforme a regulamentação brasileira, com justificativa das decisões. Após contenção, deverá haver recuperação controlada, análise de causa e plano de prevenção de recorrência.

10. Retenção, descarte e treinamento

Eliminação deverá seguir a matriz, os prazos de saída e as instruções válidas do controlador. Cópias, caches, índices de IA, ambientes temporários e suboperadores deverão ser considerados. Retenções excepcionais deverão ter fundamento, responsável e prazo.

Pessoas com acesso a informações deverão receber orientação sobre proteção de dados, phishing, credenciais, compartilhamento, uso de IA e incidentes. Descumprimentos poderão gerar medidas proporcionais, respeitados contratos e legislação.

11. Revisão, evidências e transparência

A Política deverá ser revista anualmente e sempre que houver mudanças relevantes, incidente, novo fornecedor ou exigência legal. Exceções exigem prazo, justificativa, responsável e controle compensatório; não poderão afastar obrigações legais.

Relatórios detalhados, arquitetura e procedimentos de resposta poderão ser compartilhados sob confidencialidade quando necessário. Não deverão ser divulgadas afirmações de ISO 27001, SOC 2, HIPAA, PCI DSS, proteção absoluta ou disponibilidade percentual sem evidência específica e escopo válido.