Como cobrar o reteste de segurança após correções do cliente estrangeiro

Para cobrar um reteste de segurança após correções, confirme quais achados entram, quais ativos continuam autorizados e qual versão o cliente quer verificar. Defina a janela e a evidência esperada. O orçamento pode cobrir a confirmação de correções específicas ou uma avaliação mais ampla. Declare a cobertura antes de executar e vincule o aceite à invoice.

Defina o escopo e confirme a autorização

Recupere o relatório anterior e use o identificador de cada achado. Confirme se o cliente disponibilizou a correção no ambiente combinado e se as contas necessárias estão ativas. Registre o sistema, o ambiente, a janela e o responsável por autorizar o teste. Se o ativo mudou de endereço ou passou para outro fornecedor, confira a autorização aplicável antes de iniciar.

O guia de testes da OWASP organiza cenários com objetivos e orientação para verificação. O NIST publica orientação técnica para planejar avaliações de segurança. Use essas referências para desenhar uma checagem documentada. No orçamento, indique a cobertura acordada e o que depende de acesso e evidência do cliente. A autorização do trabalho inicial deve ser revisada quando o escopo ou o ambiente muda.

Diga o que o reteste entrega

Se a correção foi acompanhada de mudanças que afetam outras partes do sistema, confirme se a verificação dessas áreas está incluída. Uma confirmação pontual pode responder sobre um achado conhecido. Uma revisão mais ampla exige critérios e esforço próprios. Se o cliente quer checar uma nova versão inteira, prepare uma proposta que indique ambientes, cobertura e limites.

Exemplo de orçamento por pacote de achados

Uma consultoria entrega um relatório com sete achados. O cliente pede reteste de quatro já corrigidos em homologação. As partes aprovam um pacote ilustrativo de USD 900 para esses quatro achados, com uma execução e entrega do relatório. Ao iniciar, a consultoria recebe acesso e confirma a versão em que as correções foram disponibilizadas.

Três verificações são concluídas e uma fica bloqueada por falta de permissão. O relatório marca o bloqueio e registra o que o cliente precisa liberar. Se a autorização comercial permite reagendar a verificação bloqueada dentro da mesma janela, a equipe acompanha a pendência. Se exige uma segunda janela com novo acesso, confirme se o orçamento já a cobre. Na invoice, use a regra de aceite combinada e indique o vínculo com o pacote.

Planeje o que ocorre quando a falha persiste

Se a vulnerabilidade ainda puder ser verificada, registre o resultado de forma suficiente para o cliente revisar a correção, sem incluir dados além do necessário. Confirme a versão e a configuração testadas. Se o cliente prepara outra correção, diga se a repetição está incluída, se é cobrada separadamente ou se ficará para uma avaliação posterior. Preserve as evidências de cada tentativa.

Se o cliente pediu uma declaração de encerramento, descreva a condição efetivamente verificada. Inclua ambiente e data. Um resultado em homologação sustenta o que foi observado ali. Se for preciso confirmar em produção, planeje autorização, janela e procedimentos separados. Mantenha a comunicação de risco no canal acordado, com acesso limitado.

Feche o aceite e a cobrança

Guarde a autorização, a lista de achados, o relatório atualizado e a confirmação de entrega. No controle comercial, indique a moeda, o valor e o identificador do serviço. A invoice pode referenciar a versão e a entrega sem expor detalhes de vulnerabilidades. Envie à contabilidade os documentos comerciais necessários e mantenha evidências técnicas sensíveis no ambiente autorizado.

Quando houver retestes recorrentes, registre quantas vezes os clientes solicitam uma nova execução e quais condições aumentam o trabalho. Use esse histórico para diferenciar uma verificação pontual de um pacote de acompanhamento. Um orçamento que explicita acesso, versão e número de tentativas facilita comparar propostas e resolver divergências.

Registre as condições de repetição

Se o cliente disponibilizar a correção fora da janela, confirme nova data e revalide o acesso antes de testar. Registre a versão e o responsável pelo ambiente. Se a equipe recebeu uma versão intermediária e depois uma versão final, preserve a referência de cada uma. Na entrega, indique qual versão sustenta o resultado. Isso evita tratar como resolvido um achado que foi confirmado em um ambiente diferente daquele que o cliente pretende liberar.

Quando o serviço é contratado por unidade, informe como um achado bloqueado será contabilizado. Se houver uma regra de reagendamento sem custo, declare suas condições e a quantidade de tentativas. Se a janela extra gerar cobrança, vincule a aprovação ao mesmo caso e inclua a referência na invoice.

Perguntas frequentes

Posso reutilizar a autorização do teste anterior?

Confira se ela ainda cobre o ativo, o ambiente e a janela previstos. Solicite confirmação se houve mudança de escopo ou de responsável.

Como cobrar se um achado não pôde ser verificado?

Registre o motivo e aplique o procedimento previsto no contrato. Combine se haverá nova janela, ajuste de valor ou entrega com pendência.

Um reteste deve incluir todas as vulnerabilidades conhecidas?

Use a lista aprovada para o serviço. Se o cliente quer ampliar a cobertura, documente os itens adicionais e o aceite antes da execução.

Fontes oficiais

• OWASP — Web Security Testing Guide
• NIST SP 800-115 — guia de avaliação de segurança

Leituras relacionadas

• Como cobrar integração de API de um cliente estrangeiro
• Guias para exportadores de serviços

Como a Zen pode ajudar

A contabilidade para exportação de serviços da Zen ajuda a organizar documentos, conciliar recebimentos e analisar as regras da sua operação. Peça uma proposta personalizada para conversar sobre o seu caso.