💻 Seu fornecedor de tecnologia pode parar sua empresa? O risco pode estar fora dos seus sistemas

Seu fornecedor de tecnologia pode parar sua empresa? Veja os riscos que precisam ser avaliados

ERPs, nuvem, folha, atendimento, integrações e sistemas financeiros concentram dados e processos críticos; falhas externas podem afetar a operação mesmo quando a empresa mantém bons controles internos

Por Cleiton Celini e Gledson Alves, sócios e contadores da AUDICONT Contabilidade

A empresa protege seus computadores, controla os acessos, utiliza autenticação multifator e mantém políticas internas de segurança. Ainda assim, uma parte crítica da operação pode ficar indisponível sem que nenhum equipamento interno tenha sido comprometido.

Basta que o problema esteja em um fornecedor.

ERPs, sistemas financeiros, plataformas de folha de pagamento, emissão de documentos fiscais, armazenamento em nuvem, ferramentas de atendimento, assinaturas eletrônicas, integrações bancárias e aplicações de inteligência artificial colocaram terceiros no centro da rotina empresarial.

Essa transformação trouxe produtividade, escala e especialização. Também criou uma nova dependência: em muitos negócios, uma falha externa pode interromper faturamento, pagamentos, folha, atendimento ou acesso a documentos.

Na segurança cibernética, esse problema integra o chamado risco da cadeia de suprimentos, situação em que uma organização pode ser afetada por vulnerabilidades, incidentes ou falhas em fornecedores e parceiros tecnológicos.

O CTIR Gov, Centro de Prevenção, Tratamento e Resposta a Incidentes Cibernéticos de Governo, já publicou orientações específicas para incidentes dessa natureza, incluindo revisão de credenciais, chaves de API e integrações expostas.

Para pequenas e médias empresas, a principal conclusão é direta:

terceirizar um sistema não significa terceirizar todo o risco associado a ele.

A empresa pode estar protegida por dentro e vulnerável por fora

A segurança digital costuma ser analisada olhando apenas para o ambiente interno.

A empresa verifica:

• computadores;
• antivírus;
• senhas;
• redes;
• usuários;
• backups;
• acessos administrativos.

Mas parte relevante da infraestrutura pode estar fora desse perímetro.

Uma empresa pode depender de terceiros para:

• ERP;
• folha de pagamento;
• sistema fiscal;
• documentos eletrônicos;
• armazenamento em nuvem;
• CRM;
• e-mail;
• internet banking;
• assinatura eletrônica;
• atendimento;
• integração de sistemas;
• backup;
• automações;
• APIs;
• inteligência artificial;
• suporte remoto.

Cada relacionamento acrescenta uma dependência.

O risco cresce quando o fornecedor:

• armazena informações críticas;
• possui acesso remoto;
• processa dados pessoais;
• mantém credenciais;
• conecta-se a outros sistemas;
• controla parte essencial da operação;
• não pode ser substituído rapidamente.

Nesse caso, a análise de segurança precisa ultrapassar os limites físicos e digitais da própria empresa.

O erro começa quando a contratação considera apenas preço e funcionalidade

É comum avaliar um software perguntando:

• Quanto custa?
• Faz o que precisamos?
• É fácil de usar?
• Integra com nossos sistemas?
• O suporte funciona?

Todas são perguntas necessárias.

Mas uma contratação tecnológica madura também deveria responder:

• Onde os dados serão armazenados?
• Quem pode acessá-los?
• Como funciona o backup?
• Qual é o prazo de recuperação?
• Existe autenticação multifator?
• Há registros de acesso?
• O fornecedor utiliza terceiros?
• Como um incidente será comunicado?
• Os dados podem ser exportados?
• Em qual formato?
• O que acontece no encerramento do contrato?
• Quanto tempo conseguimos trabalhar sem esse serviço?

Essas respostas permitem avaliar algo que normalmente não aparece na proposta comercial:

quanto a empresa passará a depender daquele fornecedor.

Nem todo fornecedor merece o mesmo nível de controle

Uma política eficiente não deve exigir o mesmo processo para todos os terceiros.

O nível de análise deve ser proporcional ao risco.

Fornecedor de baixo impacto

Sua indisponibilidade provoca pouco efeito operacional e ele não possui acesso a informações relevantes.

Exemplo: uma ferramenta utilizada para editar conteúdo público.

Fornecedor relevante

Participa de atividades importantes ou armazena informações internas, mas a empresa possui alternativas temporárias.

Fornecedor crítico

Sua indisponibilidade ou comprometimento pode impedir:

• faturamento;
• emissão fiscal;
• pagamento;
• processamento da folha;
• vendas;
• atendimento;
• acesso a documentos;
• produção;
• integração financeira;
• cumprimento de obrigações.

Quanto mais crítica a dependência, maior deve ser a atenção a segurança, contratos, continuidade, backups e capacidade de saída.

A pergunta mais importante: o que acontece se esse fornecedor parar amanhã?

Essa pergunta deveria fazer parte de toda contratação crítica.

Considere alguns cenários.

O ERP fica indisponível por um dia.

A folha não pode ser processada.

A plataforma de documentos deixa de responder.

O sistema de atendimento para.

A integração bancária deixa de funcionar.

A empresa consegue continuar?

O impacto precisa ser analisado antes do problema.

Para cada fornecedor crítico, a organização deveria saber:

1. quanto tempo consegue permanecer sem o serviço;
2. quais atividades serão interrompidas;
3. se existe procedimento temporário;
4. quem deve ser acionado;
5. como os dados serão recuperados;
6. quando o contrato prevê suporte emergencial;
7. quais informações precisam estar disponíveis fora da plataforma.

Essa análise conecta tecnologia à continuidade do negócio.

Seus dados conseguem sair do sistema?

Um dos riscos menos percebidos aparece quando a empresa precisa trocar de fornecedor.

Enquanto tudo funciona, pouco se pergunta sobre exportação.

A dificuldade surge no encerramento do contrato.

A empresa deveria conhecer antecipadamente:

• quais dados podem ser exportados;
• em qual formato;
• se o histórico completo está incluído;
• quanto tempo a extração demora;
• se existe custo adicional;
• se os arquivos podem ser importados por outro sistema;
• quais documentos ficam disponíveis;
• por quanto tempo o fornecedor mantém cópias após o encerramento.

Quanto maior a dificuldade de migração, maior pode ser o chamado vendor lock-in, expressão usada para definir uma forte dependência tecnológica de determinado fornecedor.

Essa dependência não é necessariamente negativa.

Sistemas especializados frequentemente exigem parametrizações, integrações e treinamento que tornam uma migração complexa.

O risco aparece quando a empresa só descobre isso no momento em que precisa sair.

“Está na nuvem” não responde à pergunta sobre backup

A computação em nuvem aumentou a confiabilidade de muitos serviços, mas a frase “o fornecedor faz backup” não deve encerrar a análise.

É necessário compreender:

• qual é a frequência das cópias;
• quanto tempo elas ficam armazenadas;
• quais informações são incluídas;
• onde são mantidas;
• como funciona a restauração;
• quanto tempo a recuperação demora;
• quem pode solicitá-la;
• se existem versões anteriores;
• quais situações estão cobertas.

Também é importante distinguir:

• sincronização;
• histórico de versões;
• redundância;
• backup;
• recuperação de desastre.

São mecanismos relacionados, mas não necessariamente equivalentes.

O objetivo não é exigir conhecimento técnico profundo do empresário.

É saber se, diante de uma perda ou indisponibilidade, existe uma forma conhecida e viável de recuperar o que é necessário para continuar operando.

O acesso de suporte também precisa ser controlado

Muitos fornecedores precisam acessar sistemas de clientes para executar:

• implantação;
• manutenção;
• atualização;
• diagnóstico;
• integração;
• suporte.

Esse acesso pode ser necessário, mas não deveria ser ilimitado.

A empresa deve saber:

• qual fornecedor possui acesso;
• quais sistemas ele alcança;
• quem utiliza a credencial;
• quais permissões foram concedidas;
• se existe autenticação multifator;
• se as sessões ficam registradas;
• se o acesso é permanente;
• quando será removido.

Uma conta criada para uma implantação temporária não deveria continuar ativa por anos sem revisão.

O mesmo vale para consultores, desenvolvedores, integradores e prestadores que deixaram de atender a empresa.

Credenciais técnicas podem conectar um incidente a vários sistemas

As integrações modernas utilizam mecanismos como:

• tokens;
• chaves de API;
• certificados digitais;
• usuários técnicos;
• credenciais de serviço.

Esses recursos permitem que sistemas troquem dados automaticamente.

Também podem ampliar o impacto de um incidente caso sejam expostos.

Por isso, a empresa deve manter, ao menos para integrações críticas, um registro de:

• sistema conectado;
• fornecedor responsável;
• finalidade;
• credencial utilizada;
• responsável interno;
• forma de revogação;
• data da última revisão.

Quando há suspeita de comprometimento, essas credenciais podem precisar ser substituídas rapidamente.

Em incidentes envolvendo cadeia de suprimentos, o CTIR Gov já recomendou auditoria de chaves de API, credenciais e outros segredos potencialmente expostos.

A empresa sabe quantos terceiros têm acesso aos seus sistemas?

Essa pergunta parece simples, mas frequentemente não tem uma resposta pronta.

Ao longo do tempo, acessos podem ter sido concedidos a:

• suporte técnico;
• fornecedor de ERP;
• desenvolvedor;
• consultoria;
• agência;
• integrador;
• empresa de automação;
• prestador temporário;
• parceiro comercial.

Sem uma revisão, essas permissões se acumulam.

A empresa não precisa necessariamente de uma plataforma sofisticada para começar.

Um inventário simples pode registrar:

• fornecedor;
• sistema;
• finalidade do acesso;
• tipo de permissão;
• responsável interno;
• data da concessão;
• última revisão;
• situação atual.

O importante é transformar acessos externos em informação conhecida, e não em memória informal.

Trocar de fornecedor exige encerrar a relação tecnológica, não apenas financeira

Cancelar um contrato não significa que todos os vínculos digitais foram encerrados.

Ao trocar de fornecedor, devem ser revisados:

• usuários;
• acessos administrativos;
• VPN;
• acesso remoto;
• tokens;
• APIs;
• certificados;
• integrações;
• arquivos compartilhados;
• contas de serviço;
• dados armazenados.

Também é necessário saber o que acontecerá com as informações mantidas pelo terceiro.

Quando houver dados pessoais, a retenção e a exclusão precisam ser avaliadas conforme a finalidade, as obrigações aplicáveis e as condições da relação entre as partes.

A saída de um fornecedor deveria possuir um checklist tão claro quanto sua implantação.

Seu fornecedor também depende de outros fornecedores

A cadeia tecnológica raramente termina na empresa contratada.

Um sistema pode depender de:

• provedor de nuvem;
• empresa de pagamentos;
• serviço de autenticação;
• banco de dados;
• serviço de e-mail;
• API de terceiro;
• empresa de monitoramento;
• ferramenta de inteligência artificial.

Isso significa que uma solução aparentemente única pode depender de diferentes organizações para funcionar.

Não é razoável exigir que uma pequena empresa audite tecnicamente todas as organizações dessa cadeia.

Mas, quando o fornecedor é crítico, algumas perguntas são importantes:

• existem dependências relevantes?
• o serviço utiliza infraestrutura de terceiros?
• existe redundância?
• como uma indisponibilidade externa é tratada?
• há previsão de comunicação quando um subfornecedor compromete o serviço?

Esse entendimento ajuda a dimensionar o verdadeiro risco de continuidade.

Inteligência artificial torna essa cadeia ainda mais complexa

Ferramentas de inteligência artificial podem acrescentar novas camadas ao relacionamento tecnológico.

Uma solução oferecida por determinada empresa pode utilizar:

• modelo de IA de outro fornecedor;
• infraestrutura de nuvem de terceiro;
• banco de dados externo;
• serviço de busca;
• APIs;
• agentes adicionais.

Em ambientes com agentes de inteligência artificial, uma ferramenta pode inclusive acionar outros sistemas autonomamente para executar determinada tarefa.

Isso aumenta a importância de entender:

• quais dados são enviados;
• quais empresas participam do processamento;
• quais sistemas podem ser acionados;
• quais permissões são concedidas;
• quais ações dependem de revisão humana.

A pergunta de contratação deixa de ser apenas:

“qual ferramenta estamos usando?”

E passa a incluir:

“quem mais participa desse processamento?”

O fornecedor sofreu um incidente: o que fazer?

Quando um fornecedor comunica uma falha ou incidente, a primeira reação não deve ser apenas aguardar.

A empresa precisa avaliar seu próprio impacto.

Um procedimento inicial pode incluir:

1. identificar serviços atingidos;
2. confirmar quais dados estavam envolvidos;
3. mapear acessos e integrações existentes;
4. verificar logs disponíveis;
5. revisar credenciais;
6. trocar ou revogar acessos quando necessário;
7. suspender integrações potencialmente comprometidas;
8. confirmar situação dos backups;
9. verificar efeitos sobre a continuidade;
10. documentar as providências adotadas.

Se houver dados pessoais envolvidos, também será necessário avaliar o incidente sob a perspectiva da LGPD e das normas aplicáveis.

Nem todo incidente de fornecedor gera automaticamente obrigação de comunicação à ANPD ou aos titulares.

A avaliação depende da natureza dos dados, do risco e das circunstâncias concretas.

LGPD: fornecedor de software pode ser operador, mas isso depende da realidade

Quando um terceiro trata dados pessoais em nome da empresa, é comum existir uma relação entre controlador e operador.

A Agência Nacional de Proteção de Dados define o controlador como o agente que toma as principais decisões referentes ao tratamento e o operador como aquele que realiza o tratamento em nome do controlador.

Entretanto, os papéis não devem ser definidos apenas pelo título escrito no contrato.

É necessário analisar quem efetivamente decide:

• finalidade;
• meios relevantes;
• utilização dos dados;
• duração;
• compartilhamento.

Em determinadas operações, um fornecedor pode possuir maior autonomia e assumir responsabilidades diferentes.

Por isso, contratos precisam refletir a realidade do tratamento.

Incidente no operador também exige resposta do controlador

Quando um fornecedor atua como operador e identifica um incidente envolvendo dados tratados em nome de um cliente, a ANPD orienta que o controlador seja informado sem demora injustificada e receba elementos suficientes para avaliar as providências.

Isso reforça a importância de o contrato prever:

• canal de comunicação;
• responsáveis;
• informações mínimas;
• prazo operacional;
• cooperação;
• preservação de evidências.

Descobrir somente após o incidente que ninguém sabe quem deve avisar quem representa uma falha de governança.

Dependência tecnológica também pode afetar a contabilidade

A contabilidade moderna depende cada vez mais da qualidade e disponibilidade das informações geradas pelos sistemas.

Podem fazer parte desse fluxo:

• ERP;
• folha;
• emissão fiscal;
• bancos;
• integrações;
• captura de documentos;
• armazenamento;
• automações.

Quando um fornecedor falha ou seus dados são comprometidos, surgem riscos como:

• perda de documentos;
• lançamentos duplicados;
• ausência de registros;
• alteração de cadastro;
• diferença entre bases;
• quebra da trilha de auditoria;
• divergência após restauração;
• movimentações sem origem confiável.

Segundo Cleiton Celini e Gledson Alves, sócios e contadores da AUDICONT Contabilidade, a gestão de fornecedores tecnológicos deve ser integrada aos controles internos da organização.

“Quando uma rotina financeira ou contábil depende de um sistema de terceiro, a confiabilidade daquele fornecedor passa a fazer parte do próprio processo empresarial. A empresa não precisa conhecer toda a infraestrutura técnica, mas deve saber onde estão suas informações, quem consegue acessá-las e como a operação continuará caso o serviço fique indisponível.”

Isso aproxima a gestão tecnológica de uma lógica já conhecida pela contabilidade: identificar riscos, documentar controles e garantir rastreabilidade.

O preço mais barato pode esconder um custo maior de dependência

O custo de um sistema não termina na mensalidade.

Também podem existir custos relacionados a:

• migração;
• integração;
• indisponibilidade;
• perda de produtividade;
• exportação de dados;
• suporte;
• recuperação;
• treinamento;
• substituição;
• dependência contratual.

Um fornecedor mais barato pode se tornar caro se:

• os dados forem difíceis de recuperar;
• o suporte não responder em incidentes;
• a empresa não conseguir migrar;
• integrações forem frágeis;
• a indisponibilidade afetar faturamento.

A análise deve considerar o custo total de dependência, e não apenas o preço da licença.

Cinco perguntas antes de contratar um fornecedor crítico

1. Quais informações ficarão com esse fornecedor?

Quanto mais críticas ou sensíveis, maior deve ser a diligência.

2. O que acontece se o serviço parar?

A empresa precisa conhecer o impacto e a alternativa temporária.

3. Como recuperamos ou exportamos nossos dados?

Essa resposta precisa existir antes do encerramento da relação.

4. Quem terá acesso?

Devem ser considerados equipe do fornecedor, suporte, subcontratados e integrações.

5. Como seremos informados sobre um incidente?

A comunicação deve possuir canal, responsáveis e procedimento definidos.

Essas perguntas não eliminam riscos.

Mas ajudam a evitar uma contratação baseada apenas em funcionalidade, preço e promessa comercial.

Sinais de dependência tecnológica que merecem revisão

• ninguém sabe exportar os dados;
• apenas o fornecedor possui acesso administrativo;
• não existe informação clara sobre backup;
• a empresa desconhece integrações ativas;
• acessos antigos continuam habilitados;
• tokens e credenciais nunca são revisados;
• o contrato não trata de incidentes;
• ninguém conhece o prazo de recuperação;
• a troca de sistema parece inviável;
• não existe procedimento para encerramento;
• todos os processos críticos dependem de uma única plataforma;
• a empresa desconhece quem são os subfornecedores relevantes.

Nenhum desses sinais comprova, isoladamente, que o fornecedor seja inseguro.

Eles indicam que a dependência precisa ser melhor conhecida e administrada.

Perguntas frequentes

O que é risco de cadeia de suprimentos em tecnologia?

É o risco de uma empresa ser afetada por falhas, vulnerabilidades ou incidentes ocorridos em fornecedores ou outros integrantes da cadeia tecnológica. Um prestador comprometido pode impactar vários clientes quando mantém sistemas, acessos, integrações, credenciais ou dados compartilhados.

Terceirizar um sistema transfere toda a responsabilidade pela segurança?

Não. O fornecedor assume responsabilidades sobre o serviço contratado, mas a empresa continua responsável por diversos controles, como escolha de usuários, permissões, informações compartilhadas, gestão de acessos e avaliação dos impactos sobre sua própria operação.

O que é vendor lock-in?

Vendor lock-in é uma dependência que torna difícil ou onerosa a migração para outro fornecedor. Pode decorrer de formatos proprietários, integrações, dados difíceis de exportar, treinamento, personalizações ou ausência de alternativas. O problema não é a dependência em si, mas desconhecê-la ou não planejar uma possível saída.

Ter os dados na nuvem elimina a necessidade de avaliar backup?

Não. A empresa precisa entender quais mecanismos de cópia e recuperação o fornecedor oferece, o tempo necessário para restauração e quais responsabilidades continuam com o cliente. Estar na nuvem não significa automaticamente que qualquer informação possa ser recuperada em qualquer situação.

O fornecedor precisa comunicar um incidente de segurança?

Quando atua como operador e o incidente envolve dados pessoais tratados em nome do controlador, a ANPD orienta que o controlador seja informado sem demora injustificada e receba informações que permitam avaliar as providências necessárias.

Como avaliar um fornecedor de tecnologia antes da contratação?

Comece pela criticidade. Identifique quais dados serão processados, que acessos serão concedidos, como funciona o backup, como os dados podem ser exportados, qual o prazo de recuperação e como incidentes serão comunicados. Quanto maior o impacto potencial de uma falha, maior deve ser a análise.

Uma pequena empresa precisa avaliar todos os fornecedores com o mesmo rigor?

Não. O nível de diligência deve ser proporcional ao risco. Fornecedores que armazenam dados sensíveis, possuem acesso aos sistemas ou podem interromper atividades essenciais merecem avaliação mais detalhada do que serviços de baixo impacto.

Fontes consultadas

CTIR Gov - Centro de Prevenção, Tratamento e Resposta a Incidentes Cibernéticos de Governo
Recomendação 05/2026 - orientações relacionadas a incidente envolvendo fornecedor tecnológico e risco de cadeia de suprimentos.

Agência Nacional de Proteção de Dados - ANPD
Guia Orientativo para Definições dos Agentes de Tratamento de Dados Pessoais e do Encarregado.

Agência Nacional de Proteção de Dados - ANPD
Orientações sobre comunicação de incidentes de segurança e responsabilidades entre controlador e operador.

Agência Nacional de Proteção de Dados - ANPD
Materiais técnicos de 2026 relacionados à distribuição de responsabilidades em arquiteturas de inteligência artificial com múltiplos agentes e fornecedores.