1 Responsabilidades e aplicação
A gestão da ROOT deve designar um responsável pela segurança, manter canais de reporte e acompanhar correções. Quem administra um ambiente responde pela configuração e pelo registro dos acessos sob sua gestão. Clientes indicam pessoas autorizadas, aprovam instruções de tratamento e comunicam mudanças de equipe. Fornecedores devem assumir obrigações compatíveis com seu acesso.
Antes de colocar um projeto em produção, a equipe deve registrar quais dados ele usa, quem pode acessá-los, quais serviços externos participam e como recuperar a operação. Exceções precisam de justificativa, responsável, medida compensatória e prazo de revisão.
2 Acesso e credenciais
O acesso deve ser individual, concedido pela necessidade da função e revogado quando deixar de ser necessário. Privilégios administrativos exigem cuidado adicional e autenticação multifator quando o serviço oferecer esse recurso. Contas compartilhadas só podem existir por necessidade técnica documentada, com responsável e rastreabilidade.
Senhas, chaves de API e certificados devem ficar em mecanismos próprios de gestão de segredos, com acesso restrito. É vedado incluí-los em páginas públicas, repositórios de código, materiais de treinamento ou conversas sem proteção adequada. Suspeita de exposição exige avaliação e rotação ou revogação das credenciais afetadas.
3 Proteção dos dados e ambientes
A coleta e a cópia de informações devem se limitar à necessidade do trabalho. Dados reais de clientes não devem ser usados em demonstrações públicas. Sempre que viável, desenvolvimento e testes devem usar dados fictícios ou anonimizados.
A transmissão de informações confidenciais deve usar canais protegidos. Armazenamento, isolamento entre clientes, permissões e registros precisam ser definidos conforme os riscos do ambiente. A criptografia em repouso deve ser avaliada e implementada nos repositórios que guardem dados sensíveis ou segredos. Não se deve prometer uma cobertura de criptografia sem verificar cada componente.
Dispositivos utilizados no trabalho devem ter bloqueio de tela, atualizações e mecanismos de proteção compatíveis com o acesso. Perda, furto ou comprometimento devem ser comunicados imediatamente à gestão.
4 Desenvolvimento e mudanças
Alterações devem ter registro, revisão proporcional ao risco e testes antes de entrar em produção. Mudanças que afetem dados, permissões ou integrações precisam de plano de reversão ou recuperação. Falhas conhecidas devem ser priorizadas conforme gravidade, exposição e impacto.
Os registros de operação devem permitir investigar eventos relevantes sem copiar senhas, tokens ou conteúdo pessoal desnecessário. Acesso e prazo de conservação desses registros precisam ser limitados. A revisão dos controles deve ocorrer diante de mudança relevante, incidente ou identificação de uma falha.
5 Fornecedores e inteligência artificial
Antes de disponibilizar informações a um fornecedor, a equipe deve avaliar finalidade, dados envolvidos, acesso, retenção, localização do processamento e condições contratuais. Um fornecedor novo ou uma alteração material requer atualização do registro do projeto.
Dados confidenciais não devem ser enviados a ferramentas de IA de uso pessoal ou sem configuração e autorização adequadas. O uso para treinamento de modelos gerais não se presume autorizado. Respostas de IA precisam de verificação proporcional ao impacto. Ações financeiras, fiscais, jurídicas, de publicação ou de exclusão exigem autorizações e limites definidos para o projeto; o uso de IA não amplia a autorização recebida.
6 Cópias de segurança e continuidade
Cada ambiente que exigir recuperação deve ter uma rotina documentada de cópias, retenção, acesso e testes de restauração. A equipe deve definir a perda de dados tolerável e o tempo de recuperação esperado antes de assumir compromissos contratuais. A existência de uma cópia sem teste não comprova a capacidade de restauração.
Disponibilidade, horários de suporte e tempos de atendimento dependem do contrato específico. Esta política não estabelece atendimento permanente nem uma porcentagem universal de disponibilidade.
7 Incidentes e comunicação
Qualquer suspeita de acesso indevido, exposição, perda ou indisponibilidade relevante deve ser reportada sem demora. O atendimento deve registrar o evento, conter seus efeitos, preservar evidências, avaliar os dados e pessoas envolvidos e acompanhar a recuperação.
Nos ambientes de clientes, a ROOT deve informar o controlador sem demora injustificada, com os elementos conhecidos e atualizações posteriores. Quando atuar como controladora, deverá avaliar as comunicações exigidas pela regulamentação. O prazo interno de aviso ao cliente não substitui prazos legais.
Para reportar um problema, inicie o contato pelo Direct oficial @operacao.root, em Direct da ROOT, identificando o assunto como segurança. Clientes também podem usar o canal contratual. Não envie senhas nem dados completos de terceiros; descreva o ocorrido e combine um meio seguro para evidências. Esse canal público não implica monitoramento 24 horas.
8 Encerramento e revisão
Ao fim do vínculo ou projeto, devem ser revogados os acessos desnecessários e executadas as rotinas de devolução, exportação e eliminação previstas, respeitada a retenção obrigatória. A equipe deve revisar esta política ao menos anualmente e após mudanças relevantes. Compromissos adicionais só devem ser assumidos após verificação de sua viabilidade e registro no contrato.