Neste artigo
Antes de dar aceite num sistema, sete verificações protegem você de assinar um problema. São elas: acesso ao código e ao banco em nome da sua empresa, backup restaurado na sua frente, teste de permissão entre usuários, segredo fora do código. Log sem dado pessoal, dependência sem vulnerabilidade conhecida, e documentação que permite outra pessoa assumir.
Nenhuma delas exige que você seja técnico, mas todas exigem que alguém demonstre, não que afirme.
Por que o aceite é o último momento com poder?
Antes do aceite, o fornecedor tem incentivo para resolver, mas depois tudo vira pedido de manutenção, e às vezes vira orçamento novo.
Não é desconfiança, é o momento certo do processo, e um fornecedor sério prefere que essas coisas apareçam agora, porque incidente depois é problema dele também.
Quais são as sete verificações?
1) Você tem o código e o banco, em conta sua. Entre no repositório com o seu login, na organização da sua empresa, e peça um dump do banco para confirmar que abre. Se o repositório está na conta pessoal de alguém do fornecedor, isso se resolve antes do aceite, não depois.
2) Backup restaurado na sua frente. Não pergunte se tem backup, peça para restaurar em um ambiente separado enquanto você assiste, porque é a verificação que mais reprova e a que mais economiza sofrimento.
3) Teste de permissão, com dois usuários reais. Peça dois acessos de perfis diferentes, ou de clientes diferentes se for multi-cliente. Logue com o primeiro, copie o endereço de uma tela com dado, e abra logado como o segundo.
Se aparecer conteúdo do primeiro, existe falha grave de isolamento, mas se der erro de “não encontrado”, está certo. Essa checagem leva dois minutos e é a mais importante das sete.
4) Segredo fora do código: pergunte onde ficam as senhas de banco e as chaves de integração. A resposta certa envolve variável de ambiente ou cofre. Mas se a resposta for “está no arquivo de configuração no repositório”, precisa ser corrigido e as chaves precisam ser trocadas, porque já ficaram no histórico.
5) Log sem dado pessoal: peça para ver um erro real no log. Se aparecer CPF, e-mail, telefone ou token, isso é problema de LGPD e vaza em qualquer ferramenta que receba log.
6) Dependências sem vulnerabilidade conhecida: peça o resultado da auditoria do gerenciador de pacotes. Item conhecido e sem correção precisa ter justificativa; lista cheia de crítico sem ninguém ter olhado é sinal do resto.
7) Documentação suficiente para outra pessoa assumir: como subir o ambiente, como fazer deploy, onde roda, quais integrações existem, e como restaurar backup. O teste: se o fornecedor sumir amanhã, outro consegue assumir com esse documento?
Como fica a tabela de aceite?
| Verificação | Como comprovar | Reprova se |
|---|---|---|
| Código e banco | Você acessa com seu login | Está na conta pessoal de alguém |
| Backup | Restauração feita na sua frente | Nunca foi testada |
| Permissão | Dois usuários, tentativa cruzada, leva 2 minutos | Um vê dado do outro |
| Segredo | Mostrar onde está | Está no repositório |
| Log | Ver um erro real | Tem dado pessoal |
| Dependência | Saída da auditoria | Crítico sem justificativa |
| Documentação | Ler e entender | Só existe na cabeça de alguém |
| Fonte: checklist de auditoria de aceite da SyntaxLab, apurado em 29/08/2026 | ||
O que esse checklist não cobre?
Sendo honesto sobre o limite: esse checklist é higiene de aceite, não teste de invasão, e pega o que é comum e evitável.
Se o sistema trata dado de saúde, financeiro regulado ou volume grande de dado pessoal, contrate um teste de segurança independente, feito por quem não construiu. E vale uma fração do custo de um incidente.
Como fazer isso sem virar briga?
Mande a lista no começo do projeto, não no fim, porque quando o fornecedor sabe desde o início que o aceite tem essas sete verificações, ele constrói com elas em mente, e o aceite vira formalidade.
Mandar a lista no dia da entrega gera atrito legítimo, porque muda a régua depois do jogo. É o mesmo raciocínio de deixar tudo escrito na proposta, como está em o que exigir num orçamento de software.
O que mais perguntam sobre o aceite de entrega?
E se o fornecedor recusar alguma verificação?
Recusar mostrar backup, permissão ou onde ficam os segredos é resposta suficiente, e nenhuma das sete expõe propriedade intelectual dele.
Posso contratar alguém só para o aceite?
Pode, e em projeto grande costuma valer, porque um técnico independente por algumas horas custa pouco perto de assinar um sistema com falha de isolamento.
Vocês auditam sistema de outro fornecedor?
Auditamos, com relatório que diz honestamente o que precisa ser corrigido e o que está adequado. Peça um diagnóstico.
