Comprar software, cloud ou serviço de tecnologia significa introduzir código, acessos e dependências no ambiente da empresa.
O risco não depende apenas do preço ou do porte do fornecedor. Uma ferramenta barata pode processar dados sensíveis, instalar agente em dispositivos ou integrar-se a sistemas críticos.
A homologação de TI precisa responder:
O risco residual deste fornecedor e desta solução é compatível com o uso pretendido?
Cibersegurança não deve ser sempre o "primeiro critério" em sentido absoluto. A decisão de compra combina funcionalidade, segurança, privacidade, arquitetura, continuidade, custo e valor. Entretanto, segurança precisa entrar antes do contrato e da implantação.
Homologue o uso, não apenas a empresa
O mesmo fornecedor pode oferecer:
- ferramenta pública de marketing;
- sistema de folha;
- aplicação com dados de saúde;
- software instalado em ambiente industrial.
O risco muda conforme:
- produto;
- versão;
- configuração;
- dados;
- acesso;
- integração;
- criticidade;
- localização;
- suboperadores.
A aprovação deve ser vinculada ao caso de uso.
Triagem inicial
Perguntas:
- que problema resolve?
- quais dados processa?
- integra com quais sistemas?
- exige acesso remoto?
- instala software?
- utiliza IA?
- hospeda em qual ambiente?
- qual impacto da indisponibilidade?
- possui suboperadores?
- será usado por quantas pessoas?
- qual é a classificação da informação?
A triagem define a profundidade.
Tiering de risco
Tier baixo
Sem dado sensível, sem integração crítica e baixa dependência.
Tier médio
Dados corporativos, integrações limitadas ou impacto operacional moderado.
Tier alto
Dados pessoais relevantes, acesso privilegiado, software crítico, cloud, infraestrutura ou grande impacto de continuidade.
Tier crítico
Ambiente operacional, segurança física, alta concentração, serviço essencial ou impacto regulatório severo.
A nomenclatura pode variar. O importante é ligar tier a controles.
Due diligence mínima
O NIST trabalha em um guia de início rápido para due diligence de C-SCRM e reforça que a organização adquirente precisa desenvolver um nível mínimo de compreensão sobre seus fornecedores.
Informações mínimas:
- identidade;
- propriedade;
- produto;
- arquitetura;
- desenvolvimento;
- vulnerabilidades;
- incidentes;
- suporte;
- continuidade;
- subfornecedores;
- práticas de segurança;
- contatos;
- fim de vida.
Secure by Design e Secure by Demand
A CISA orienta compradores a exigir segurança incorporada ao produto e a avaliar práticas do fabricante.
Perguntas:
- MFA está disponível e habilitado?
- logs são acessíveis?
- vulnerabilidades são comunicadas?
- atualizações são assinadas?
- recursos inseguros são padrão?
- existe política de divulgação?
- qual é o prazo de correção?
- o produto continua recebendo suporte?
- segurança básica exige custo adicional?
O comprador pode influenciar o mercado ao tratar segurança como requisito.
Certificações e relatórios
Possíveis evidências:
- ISO/IEC 27001;
- SOC 2;
- testes de penetração;
- relatórios de auditoria;
- certificações setoriais;
- atestados;
- políticas;
- arquitetura.
Cuidados:
- escopo;
- período;
- entidade;
- ressalvas;
- controles não testados;
- bridge letter;
- compartilhamento restrito;
- plano de correção.
Certificação não é aprovação automática.
Segurança do desenvolvimento
Avalie:
- SDLC seguro;
- revisão de código;
- dependências;
- componentes open source;
- testes;
- segredo;
- CI/CD;
- assinatura;
- vulnerabilidade;
- correção;
- SBOM;
- versionamento.
Produtos com IA também exigem práticas específicas de desenvolvimento e avaliação.
Vulnerability management
Perguntas:
- como vulnerabilidades são descobertas?
- existe canal de reporte?
- qual SLA de correção?
- como severidade é definida?
- como clientes são notificados?
- existe compensating control?
- há histórico de atrasos?
- como versões antigas são tratadas?
O contrato deve refletir compromissos.
Dados e privacidade
Mapeie:
- categorias de dados;
- finalidade;
- localização;
- retenção;
- criptografia;
- suboperadores;
- acesso;
- treinamento de modelo;
- exclusão;
- portabilidade;
- incidente.
Criptografia "em repouso e em trânsito" é apenas o início da análise.
Identidade e acesso
Controles:
- SSO;
- MFA;
- RBAC;
- menor privilégio;
- contas administrativas;
- logs;
- sessão;
- revisão;
- provisionamento;
- deprovisioning;
- acesso do suporte.
O acesso de suporte do fornecedor deve ser limitado e registrado.
Arquitetura e integrações
Avalie:
- API;
- webhook;
- agente;
- VPN;
- banco;
- firewall;
- rede;
- tenant;
- segredo;
- isolamento;
- fluxo de dados.
Uma integração amplia a superfície de risco.
Continuidade e recuperação
Perguntas:
- RTO e RPO;
- backups;
- testes;
- região;
- redundância;
- dependência de cloud;
- plano de crise;
- comunicação;
- exportação;
- suporte.
A recuperação declarada precisa ser compatível com a criticidade.
Histórico de incidentes
O fornecedor deve explicar:
- incidentes relevantes;
- impacto;
- causa;
- notificação;
- correção;
- prevenção;
- situação atual.
Ter sofrido um incidente não desqualifica automaticamente. Ocultar ou não aprender pode ser mais preocupante.
Questionários
Questionários são úteis quando:
- proporcionais;
- claros;
- reutilizáveis;
- acompanhados de evidência;
- revisados por especialistas;
- atualizados por risco.
Perguntas binárias podem esconder maturidade.
Piloto seguro
Quando a solução precisa ser testada antes da aprovação completa:
- dados fictícios ou minimizados;
- ambiente isolado;
- usuários limitados;
- sem integração crítica;
- prazo;
- critérios;
- monitoramento;
- encerramento;
- proibição de escala automática.
Piloto não deve virar produção sem nova decisão.
Decisão de risco
Possíveis decisões:
- aprovar;
- aprovar com condições;
- aprovar piloto;
- exigir remediação;
- aceitar risco formalmente;
- escolher alternativa;
- reprovar.
A decisão precisa registrar:
- risco;
- evidências;
- exceções;
- owner;
- validade;
- controles;
- revisão.
Contrato
Cláusulas:
- segurança;
- privacidade;
- incidente;
- vulnerabilidade;
- auditoria;
- suboperadores;
- logs;
- acesso;
- continuidade;
- portabilidade;
- exclusão;
- cooperação;
- término;
- atualização;
- fim de vida;
- responsabilidade.
Homologação e contrato devem ser coerentes.
Tempo de homologação
Segurança não precisa significar meses de atraso.
A empresa pode criar:
- tiers;
- evidências reutilizáveis;
- catálogo;
- fast track;
- sandbox;
- SLA;
- automação;
- aprovação condicional;
- revisão por amostra.
O objetivo é tratar alto risco profundamente e baixo risco com agilidade.
Indicadores
- fornecedores triados;
- tiers;
- tempo;
- evidências completas;
- exceções;
- riscos aceitos;
- planos;
- soluções não aprovadas;
- pilotos;
- incidentes após homologação;
- contratos com cláusulas;
- revisões vencidas.
Caso prático: ferramenta de IA
Uma área quer utilizar um assistente com documentos internos.
A homologação:
- identifica tipos de documentos;
- verifica treinamento com dados;
- avalia retenção;
- analisa SSO e acesso;
- revisa suboperadores;
- testa em sandbox;
- define proibições;
- negocia contrato;
- aprova grupo limitado;
- monitora uso.
O produto não é aprovado para todos os dados apenas porque funciona bem.
Erros comuns
- avaliar fornecedor, não uso;
- questionário único;
- certificado como garantia;
- segurança depois do contrato;
- piloto com dado real;
- ausência de owner;
- aceitar "não aplicável" sem explicação;
- não revisar suboperadores;
- reprovar sem alternativa;
- aprovação sem validade.
Como a CapturaMe se conecta a esse cenário
A CapturaMe pode automatizar intake, tiering, questionários, evidências, aprovações e planos de remediação.
A plataforma também pode relacionar homologação ao sourcing e ao contrato, impedindo que uma solução seja utilizada fora do escopo aprovado.
Conclusão
Homologação cibernética precisa ser rápida onde o risco é baixo e rigorosa onde o impacto é alto.
O objetivo não é certificar que um fornecedor é "100% seguro". É compreender o caso de uso, exigir evidências e decidir conscientemente quais riscos serão tratados, aceitos ou evitados.
Conheça a CapturaMe para empresas privadas
Perguntas frequentes
ISO 27001 garante que um software é seguro?
Não. É preciso avaliar escopo, produto, configuração e uso.
Todo fornecedor precisa do mesmo questionário?
Não. A profundidade deve seguir risco e criticidade.
O que é homologação condicional?
É uma aprovação limitada por controles, prazo, escopo ou remediação.
Piloto pode usar dados reais?
Somente após avaliação e controles adequados; dados fictícios ou minimizados são preferíveis no início.
Segurança deve vencer todos os outros critérios?
Deve estabelecer limites mínimos e influenciar a decisão proporcionalmente ao risco.
Quando revisar a homologação?
Por prazo e por eventos como incidente, mudança de produto, suboperador ou arquitetura.
