Cibersegurança NIS2: como auditar fornecedores de TI industriais

O artigo 21.º da NIS2 obriga-o a gerir o risco da cadeia de fornecimento. Na prática, isto significa que a sua fábrica têxtil responde perante a autoridade pelo que o fornecedor que aloja o seu ERP MULTI faz — ou não faz — em matéria de segurança. Mas como é que um IT lead de uma empresa de 90 pessoas audita o datacenter que lhe vende cloud, o integrador que lhe mantém o MES e o fabricante dos terminais de chão-de-fábrica? Neste artigo resolve-se isto em detalhe técnico: que cláusulas exigir, que evidências recolher, que thresholds definir, e onde a auditoria falha na vida real.

A tese, antes de mais: a maioria das auditorias de fornecedores de TI em PME industriais portuguesas falha não por falta de rigor, mas por auditar a empresa errada. Gasta-se energia a exigir ISO 27001 ao fornecedor de cloud — que já a tem — e ignora-se o pequeno integrador local que tem acesso remoto permanente ao ERP com uma password partilhada por três técnicos. O risco mora no elo mais pequeno, não no maior. E esse elo quase nunca aparece na folha de Excel do dossier NIS2.

Há uma segunda razão, menos confortável de admitir. Em muitas PME industriais do Norte, a auditoria de fornecedores de TI não existe sequer como processo — existe como reacção. Alguém levou um susto, correu um ransomware num cliente do mesmo cluster, e de repente há uma reunião onde se decide «pedir os certificados aos fornecedores». Pedem-se, chegam PDFs, arquivam-se, e dá-se o assunto por fechado. Seis meses depois, ninguém se lembra onde está o dossier, e o técnico do integrador continua a entrar no servidor de produção com a mesma conta genérica de sempre. A NIS2 veio obrigar a transformar esse susto pontual num processo recorrente, auditável e defensável perante a autoridade competente. É disso que trata este texto.

Convém ser preciso sobre quem está no âmbito. A NIS2 abrange entidades essenciais e importantes acima de certos limiares — tipicamente média empresa e acima, em setores definidos no anexo da diretiva. Muitas confeções e fábricas de calçado de pequena dimensão não estão diretamente no âmbito. Mas estão na cadeia de fornecimento de quem está: uma multinacional da moda, um distribuidor alimentar, um fabricante de componentes auto. E o artigo 21.º empurra a obrigação para baixo pela cadeia. Quem subcontrata para a Inditex, a Decathlon ou a Lacoste vai receber, mais cedo ou mais tarde, um questionário de segurança da casa-mãe. Estar preparado para o responder deixou de ser opcional.

1: Arquitetura recomendada do processo de auditoria

Auditar fornecedores não é um evento anual — é um pipeline. Desenhe-o em quatro camadas, da classificação à monitorização contínua, porque uma auditoria pontual envelhece em semanas. Cada camada tem um objetivo próprio e produz um artefacto concreto: um inventário, um dossier de evidências, um relatório técnico, um fluxo de alertas. Se uma camada não produzir nada arquivável, não a fez — teve uma conversa.

A ordem importa. Não se faz due diligence documental antes de classificar, porque não se sabe a quem exigir o quê. Não se faz verificação técnica antes de ler os documentos, porque se perde tempo a testar o que o papel já descartava. E não se monta monitorização contínua antes de saber quem são os fornecedores de Faixa A, porque se gasta orçamento de SIEM a vigiar quem imprime etiquetas. A sequência protege o orçamento que a PME não tem.

Camada 1 — Inventário e classificação de fornecedores

Não pode auditar o que não lista. O primeiro erro é não ter um registo canónico de fornecedores de TI com o nível de acesso real a sistemas e dados. Construa-o com cinco atributos mínimos por fornecedor: tipo de serviço, dados a que acede, nível de privilégio (leitura / escrita / administrativo), modo de acesso (VPN, RDP, agente, API) e criticidade para a continuidade da produção.

Classifique cada fornecedor numa de três faixas. Faixa A: acesso administrativo a sistemas que, se caírem, param a linha (ERP, MES, firewall, datacenter). Faixa B: acesso a dados mas sem privilégio de parar produção (BI, folha de vencimentos, gestão documental). Faixa C: sem acesso a sistemas críticos (consumíveis, hardware de secretária). A profundidade da auditoria escala com a faixa — auditar um fornecedor de Faixa C com o mesmo questionário de um de Faixa A é desperdiçar o orçamento que não tem.

Na vida real, a surpresa da Camada 1 é quase sempre a mesma: a lista fica maior do que o IT lead esperava. Numa fábrica têxtil média do Vale do Ave, um inventário sério costuma revelar entre quinze e trinta entidades com acesso a algum sistema — o fornecedor de ERP, o de cloud, o de BI, o integrador de automação dos teares, o técnico do sistema de ponto, a empresa de câmaras de videovigilância que afinal está no mesmo segmento de rede, o fornecedor do software da balança do armazém, a empresa de contabilidade que puxa ficheiros do ERP. Metade não constava de nenhum registo. Esse é o valor imediato da camada: tornar visível a superfície de ataque real, não a imaginada.

Um detalhe que distingue um inventário útil de um decorativo: registe o modo de acesso com honestidade técnica. «VPN» não é uma resposta suficiente. Interessa saber se é VPN site-to-site permanente, VPN de utilizador sob demanda, ou — o pior caso, mais comum do que se admite — um TeamViewer ou AnyDesk instalado no servidor e sempre ligado. A diferença de risco entre estes modos é de ordens de grandeza. O acesso permanente não supervisionado é o que mantém os responsáveis de segurança acordados.

Se o seu inventário de fornecedores de TI cabe de cabeça na memória do IT lead, não é um inventário — é uma lista de favoritos. O risco mora precisamente nos acessos de que ninguém se lembra.

Camada 2 — Due diligence documental

Recolha evidências, não promessas. Um certificado ISO 27001 válido vale mais do que qualquer resposta a questionário, porque foi um terceiro independente a verificar. Para fornecedores de Faixa A exija: certificado ISO 27001 em vigor (com anexo de âmbito — o diabo mora no âmbito), relatório SOC 2 Type II quando existir, política de gestão de patches, plano de resposta a incidentes com SLA de notificação, e evidência de testes de disaster recovery no último ano.

Um certificado ISO 27001 cujo âmbito cobre só «serviços de consultoria» e não «operação de datacenter» é um certificado que não cobre nada do que lhe interessa. Leia sempre o anexo de âmbito.

Para além da ISO 27001, há normas relacionadas que importam consoante o serviço. A ISO 27017 estende os controlos à cloud e a ISO 27018 cobre a proteção de dados pessoais em ambientes de cloud. Se o seu fornecedor aloja dados de colaboradores — e aloja, se corre a folha de vencimentos ou o pplPortal —, a existência destas certificações diz-lhe mais sobre a maturidade real do que meia dúzia de respostas a um questionário. Não exija tudo a toda a gente; exija o que é proporcional ao dado concreto que o fornecedor toca.

O questionário tem o seu lugar, mas conheça os seus limites. Um questionário de segurança é uma auto-declaração. Serve para fornecedores de Faixa B e C, e serve como triagem para Faixa A antes de pedir evidências. Não serve como prova. Quando um fornecedor de Faixa A responde «sim» a «tem MFA imposto em todas as contas administrativas?», essa resposta é uma afirmação que a Camada 3 vai verificar — não um facto estabelecido. Trate o questionário como hipótese, não como conclusão.

Estabeleça critérios de rejeição documental logo à partida, por escrito. Um fornecedor de Faixa A que não consegue apresentar um plano de resposta a incidentes, nem evidência de um único teste de restauro no último ano, nem política de gestão de patches, não é um fornecedor a melhorar — é um fornecedor a substituir ou a conter com controlos compensatórios da sua parte. A due diligence só tem valor se puder produzir um «não».

Camada 3 — Verificação técnica

Documentos mentem com elegância. Para Faixa A, valide tecnicamente o que o papel afirma: teste de restauro de backup presencial, revisão de contas com acesso remoto, verificação de que o MFA está realmente ativo (e não apenas «disponível»), e scan de vulnerabilidades do perímetro exposto. Esta camada é a que distingue uma auditoria a sério de um exercício de arquivo.

A verificação técnica mais reveladora é também a mais desconfortável de pedir: assista a um restauro real. Não ao relatório de um restauro — ao restauro. Marque com o fornecedor de datacenter uma janela em que ele repõe uma cópia do seu ERP num ambiente isolado, e cronometre. É nesse momento que o RTO de papel encontra a realidade. Vimos restauros «de 4 horas» revelarem-se restauros de 18 horas quando se contou o tempo de localizar a cópia correta, descomprimir, remontar a base de dados e validar a integridade. Esse número verdadeiro é o único que interessa ao seu plano de continuidade.

A revisão de contas de acesso remoto costuma ser igualmente produtiva. Peça a lista completa de contas que o fornecedor usa para aceder aos seus sistemas, com data da última utilização. Compare com a lista de técnicos atualmente ao serviço desse fornecedor. A diferença entre as duas listas — contas ativas de pessoas que já saíram — é um dos indicadores mais fiáveis da postura de segurança real do fornecedor. Uma empresa que gere bem os seus acessos não deixa contas órfãs penduradas no servidor de um cliente.

Quanto ao scan de vulnerabilidades do perímetro, mantenha-o dentro do que é legal e contratualizado. Não corra scans agressivos contra infraestrutura de terceiros sem autorização escrita — isso expõe-no a si. O que pode e deve fazer é verificar a superfície exposta do serviço que o afeta diretamente: portas abertas desnecessariamente, serviços desatualizados visíveis de fora, certificados TLS expirados. É verificação de higiene, não teste de intrusão.

Camada 4 — Monitorização contínua

Entre auditorias, o fornecedor muda de pessoal, de subcontratados e de postura. Monitorize em contínuo o que puder automatizar: alertas de acesso remoto fora de janela, revisão trimestral de contas privilegiadas, e cláusula contratual de notificação de incidente em prazo definido. A NIS2 não perdoa o «não sabíamos».

A palavra-chave desta camada é «automatizar o que puder». Uma PME industrial de 90 pessoas não tem um SOC 24/7, e fingir que tem é construir um processo que ninguém vai manter. O realismo manda escolher dois ou três sinais de alto valor e automatizá-los bem, em vez de montar um painel com quarenta métricas que ninguém olha. Os sinais de maior retorno costumam ser três: acesso remoto de fornecedor fora da janela acordada, criação de nova conta privilegiada, e falha de um backup agendado. Estes três, bem alertados para o telemóvel do IT lead, cobrem a maioria dos cenários que importam.

A revisão trimestral de contas privilegiadas não precisa de ferramenta cara — precisa de disciplina e de um lembrete no calendário. Quatro vezes por ano, alguém puxa a lista de contas de fornecedor, confirma com cada fornecedor quais ainda são necessárias, e desativa as restantes. É trabalho entediante de meia hora que evita o cenário clássico: o técnico que saiu há oito meses e ainda tem VPN ativa.

2: Parâmetros, métricas e thresholds

Auditoria sem números é opinião. Defina thresholds concretos e torne-os critério de aceitação ou rejeição do fornecedor. Os valores abaixo são defensáveis para uma PME industrial portuguesa típica — ajuste à sua criticidade, mas ajuste por escrito.

Dois números de mercado para calibrar a urgência. Em 2024 o CERT.PT registou 2.758 incidentes de cibersegurança em Portugal — mais 36% do que em 2023 — e cerca de 78% ocorreram em entidades privadas (CNCS, 2024). E nas PME, o ransomware esteve presente em 88% das violações analisadas, contra 39% nas grandes organizações (Verizon DBIR, 2025). O alvo preferido não é a multinacional com SOC 24/7 — é a confeção de Famalicão cujo fornecedor de TI usa a mesma password desde 2019.

Como calibrar os thresholds à sua realidade

Os valores da tabela são um ponto de partida, não dogma. A calibração faz-se olhando para duas coisas: o custo de uma hora de paragem de produção e a janela de tolerância do seu cliente mais exigente. Uma fábrica de calçado em plena campanha de amostras para os compradores de agosto não tem a mesma tolerância a paragem que a mesma fábrica em período de baixa. O RTO que negoceia com o fornecedor de datacenter deve refletir o pior momento do seu calendário, não a média do ano.

O RPO merece atenção especial numa indústria de produção. Um RPO de 24 horas significa que, num incidente, pode perder até um dia inteiro de registos. Numa confeção que captura produção em tempo real pelos terminais de chão-de-fábrica, isso são potencialmente centenas de operações de costura por recuperar manualmente — quem fez o quê, quantas peças, em que ordem de fabrico. O custo de reconstruir esse dia à mão, contra o custo de um backup mais frequente, costuma resolver a discussão a favor de um RPO curto. Faça essa conta antes de aceitar o RPO standard que o fornecedor oferece.

Se o seu fornecedor de cloud não lhe consegue dizer em quanto tempo restaura o ERP depois de um ransomware, o RTO dele é «não sei» — e «não sei» não passa auditoria NIS2.

A janela de patching e o conflito com a produção

O threshold de patching de vulnerabilidades críticas em sete dias é defensável em ambiente de TI. Em ambiente OT — os autómatos e terminais do chão-de-fábrica — esse prazo colide com a realidade de que não se reinicia um PLC a meio de um turno. O conflito é real e a resposta não é fingir que não existe. A resposta é separar os dois domínios na política: TI segue a janela agressiva; OT segue uma janela mais longa, compensada com segmentação de rede que isola os sistemas OT vulneráveis enquanto não são corrigidos. A segmentação é o controlo que compra tempo para o patch que só pode esperar pela paragem programada.

3: Configuração prática

A auditoria produz requisitos técnicos que têm de viver na configuração, não no PDF. Três exemplos ilustrativos do que exigir e validar.

Restrição de acesso remoto por janela e origem

O integrador que mantém o seu ERP não precisa de RDP aberto 24/7 contra a internet inteira. Limite por IP de origem e por janela temporal, e force VPN com MFA. Exemplo ilustrativo de regra de firewall para o acesso de um fornecedor de Faixa A:

# Regra de acesso de fornecedor de TI — ilustrativa
Permite RDP ao servidor ERP APENAS da VPN do integrador
e apenas em janela de manutenção (seg-sex, 08-20h)
allow proto tcp \
     src 10.44.12.0/29         # sub-rede VPN do fornecedor (nominativa)
     dst 192.168.30.10         # servidor ERP MULTI
     port 3389 \
     schedule "mon-fri 08:00-20:00" \
     require-mfa yes \
     log all                   # registo obrigatório para evidência NIS2
Tudo o resto para este destino: negado e registado
deny  proto tcp dst 192.168.30.10 port 3389 log all

A regra ilustra dois princípios que valem mais do que a sintaxe específica. Primeiro, o acesso é concedido a partir de uma origem conhecida e nominativa — não da internet inteira. Segundo, tudo o que não é explicitamente permitido é negado e registado. Esse log all no fim não é decorativo: é a evidência que mostra à autoridade, no dia de uma inspeção ou de um incidente, que o acesso de fornecedores estava controlado e monitorizado. Sem registo, não há como provar que o controlo existia.

Repare na janela temporal. O fornecedor acede em horário de manutenção, não às três da manhã de domingo. Qualquer tentativa de acesso fora da janela é, por si só, um alerta — ou é um técnico a trabalhar fora do combinado (a corrigir, falando com ele), ou é uma credencial comprometida a ser usada por um atacante (a investigar, com urgência). A janela transforma cada acesso anómalo num sinal acionável.

Verificação de MFA ativo (não apenas disponível)

«Temos MFA» e «o MFA está imposto a todas as contas» são frases diferentes. Audite a imposição, não a disponibilidade. Numa consulta a um diretório, confirme que não há contas privilegiadas isentas:

# Verificar contas de administração SEM MFA imposto (ilustrativo)
PowerShell / Microsoft Entra — correr durante a auditoria
Get-MgUser -Filter "accountEnabled eq true" -All |
  Where-Object { $_.AssignedRoles -match "Admin" } |
  ForEach-Object {
    $mfa = Get-MgUserAuthenticationMethod -UserId $_.Id
    if (-not $mfa) {
      Write-Output "SEM MFA: $($_.UserPrincipalName)"  # falha de auditoria
    }
  }

A distinção entre «disponível» e «imposto» é a diferença entre segurança teórica e segurança real. Muitas organizações ativam o MFA como opção e depois nunca o tornam obrigatório, deixando contas de administração a autenticar só com password «porque dá jeito ao técnico que entra à pressa». Essas contas são exatamente as que um atacante procura. A verificação programática durante a auditoria produz uma lista objetiva de exceções — e cada exceção é uma falha a corrigir antes de assinar o relatório.

Cláusula contratual de notificação (minuta técnica)

O SLA de notificação tem de estar no contrato, não no email de boas intenções. Minuta ilustrativa:

Cláusula X — Notificação de incidente de segurança
O Fornecedor obriga-se a notificar o Cliente de qualquer
incidente de segurança que afete, ou possa afetar, os
sistemas ou dados do Cliente no prazo máximo de 24 horas
após deteção, por canal escrito e por contacto telefónico
ao responsável de segurança do Cliente.
A notificação inclui: natureza do incidente, sistemas
afetados, dados potencialmente comprometidos e medidas
de contenção em curso.
O incumprimento constitui fundamento de resolução contratual.

A frase final da minuta é a que dá dentes ao resto. Uma obrigação de notificação sem consequência contratual é um pedido educado. Ao fazer do incumprimento um fundamento de resolução, o IT lead ganha alavancagem real na negociação com um fornecedor que, de outro modo, trataria a notificação como opcional. Note também o prazo alinhado com a sua própria obrigação: a NIS2 impõe ao operador prazos apertados de comunicação às autoridades, e você só os cumpre se o fornecedor o avisar a tempo. O prazo de 24 horas na cláusula é, no fundo, a condição para que você próprio cumpra a lei.

Registo de atividade como obrigação contratual

Acrescente à minuta uma cláusula de retenção de registos. O fornecedor que acede aos seus sistemas deve manter logs de acesso durante um período definido — seis meses é um mínimo razoável — e disponibilizá-los a pedido em caso de incidente. Sem esta cláusula, descobre no pior momento que o fornecedor não guardou os registos que provariam o que aconteceu. A evidência que não existe não se recupera depois do facto.

4: Integrações e dependências

A auditoria de fornecedores não vive isolada — alimenta e é alimentada por outros sistemas. Mapeie as dependências antes de começar, senão descobre a meio que não tem os dados que precisa.

O detalhe que escapa: se o seu ERP corre em cloud, o RTO do fornecedor de cloud e o RPO do seu backup têm de ser coerentes com o seu próprio plano de continuidade. Não adianta ter um objetivo de restauro de 4 horas se o contrato do fornecedor diz «best effort». Para quem está a dimensionar a infraestrutura de origem, vale rever o que considerar na infraestrutura de rede para ERP cloud em fábrica. E se tem ambiente OT — autómatos, terminais de recolha de produção com MQTT, sensores IIoT — a auditoria do fornecedor de automação segue a mesma lógica, mas com as particularidades da gestão de patches e vulnerabilidades em ambiente OT, onde não pode simplesmente reiniciar um PLC a meio de um turno.

O elo da identidade: o IdP como ponto único de controlo

Se tem um fornecedor de identidade centralizado, use-o como ponto de aplicação das regras de acesso de fornecedores. Em vez de gerir contas de fornecedor espalhadas por cada sistema, concentre-as no IdP, aplique aí o MFA obrigatório e a revisão de acessos, e deixe os sistemas confiarem na autenticação central. Esta centralização não é só comodidade — é a diferença entre revogar um acesso num sítio e ter de o caçar por doze sistemas quando um técnico sai do fornecedor. O IdP bem configurado transforma a revogação de acesso numa operação de um clique.

A coerência entre o seu DR e o do fornecedor

Há uma armadilha de coerência que só aparece em teste. O seu plano de disaster recovery assume um RTO de 4 horas para o ERP. Mas o ERP corre no datacenter do fornecedor, cujo contrato promete «best effort». No papel, os dois números nunca se encontram — até ao dia do incidente, em que descobre que o seu plano dependia de um compromisso que o fornecedor nunca assumiu. A auditoria serve precisamente para forçar este encontro antes do incidente: ou o fornecedor assume um RTO contratual coerente com o seu plano, ou o seu plano está escrito sobre areia.

5: Armadilhas operacionais

O que vemos repetir-se em fábricas e distribuidores portugueses — e como se resolve.

Armadilha 1 — Password partilhada do integrador. Três técnicos do fornecedor acedem ao ERP com a mesma conta «suporte». Quando há incidente, ninguém sabe quem entrou. Solução: exija contas nominativas por técnico, imponha contratualmente e valide no log. Se o fornecedor resiste, é um sinal — não de inconveniência, mas de maturidade de segurança.

Armadilha 2 — Auditar o grande, ignorar o pequeno. Dedica-se o dossier inteiro ao hyperscaler certificado e esquece-se o técnico local que tem TeamViewer sempre ligado ao servidor de produção. Solução: a faixa de risco manda na profundidade, não a dimensão do fornecedor.

Armadilha 3 — Certificado sem âmbito lido. Aceita-se um ISO 27001 cujo âmbito não cobre o serviço contratado. Solução: leia o anexo de âmbito e confirme que inclui a operação concreta que o afeta.

Armadilha 4 — RTO no papel, nunca testado. O contrato promete restauro em 4 horas mas nunca houve um teste real. No dia do incidente descobre-se que o restauro demora 19 horas. Solução: exija evidência de teste de restauro nos últimos 12 meses — assista a um, se for Faixa A.

Armadilha 5 — Acesso remoto que ninguém revoga. O técnico que saiu do fornecedor há oito meses ainda tem VPN ativa. Solução: revisão trimestral de contas de fornecedor e cláusula de notificação de alterações de pessoal com acesso.

Armadilha 6 — Sub-subcontratação invisível. O seu fornecedor de cloud subcontrata o suporte a uma empresa terceira que não auditou. A cadeia tem três elos e você só vê o primeiro. Solução: exija por contrato a divulgação de subcontratados com acesso a dados, e o direito de os auditar ou de os recusar.

Armadilha 7 — Dossier NIS2 congelado. Faz-se a auditoria uma vez, arquiva-se, e dá-se por cumprida a obrigação. Seis meses depois está desatualizada. Solução: trate a auditoria como processo recorrente, com revisão mínima anual para Faixa A e sempre que o serviço muda de contorno.

Armadilha 8 — O questionário que ninguém verifica. Envia-se um questionário de cinquenta perguntas, o fornecedor responde «sim» a todas, arquiva-se o PDF e considera-se o fornecedor auditado. Solução: para Faixa A, nenhuma resposta a questionário vale sem evidência. Escolha três ou quatro respostas críticas — MFA, backup, notificação, contas nominativas — e verifique-as tecnicamente. Um «sim» não verificado é pior do que nenhuma resposta, porque dá uma falsa sensação de controlo.

Armadilha 9 — O atalho do chão-de-fábrica. A auditoria está impecável no papel, mas o chefe de armazém dá a password do servidor ao técnico «para ser mais rápido» porque a linha está parada e o fim de mês aperta. Solução: a segurança técnica tem de ser acompanhada de formação de quem está no terreno. Se o processo nominativo for mais lento do que o atalho, o atalho ganha sempre. Desenhe o acesso legítimo para ser rápido — VPN com MFA bem configurada entra em segundos — para que ninguém tenha incentivo a contorná-lo.

O chefe de armazém não vai à reunião de NIS2, mas é ele que, numa quinta-feira à tarde, dá a password do servidor ao técnico «para ser mais rápido». A segurança da cadeia morre no atalho, não no documento.

6: Decisão técnica final

Sem hedging: o nível de auditoria que montar depende da sua dimensão e da criticidade do que subcontrata. Esta matriz dá-lhe a escolha direta.

A regra que não muda em nenhuma faixa: contas nominativas, MFA imposto e notificação de incidente contratualizada. Estes três são o mínimo não-negociável, independentemente da dimensão. Tudo o resto escala com o risco. Em 2024 o custo médio global de uma violação de dados atingiu 4,88 milhões de dólares, mais 10% do que no ano anterior (IBM, 2024) — e a fatia que uma PME industrial não sobrevive não é a multa, é a paragem de produção durante o fim de mês. Quem combina esta auditoria com zero trust nas redes OT e controlos técnicos ao nível da fábrica deixa de reagir e passa a prevenir.

Prioridade no primeiro ano: três ações antes de tudo o resto

Se a leitura desta matriz deixou a sensação de que é muito para fazer de uma vez, concentre-se no que dá maior retorno imediato. Primeiro, faça o inventário — sem ele, nada do resto faz sentido, e já expõe a superfície de ataque real. Segundo, elimine as passwords partilhadas de fornecedor, começando pelos de Faixa A; é o controlo de maior impacto por unidade de esforço. Terceiro, meta a cláusula de notificação de incidente em todos os contratos de Faixa A, aproveitando a próxima renovação. Estas três ações, concluídas em seis meses, movem a maior parte do risco. O pipeline completo constrói-se por cima delas.

O que a autoridade vai querer ver

Quando a inspeção chegar — e para as entidades no âmbito, chega —, o que distingue uma empresa preparada de uma apanhada de surpresa não é o número de controlos, é a existência de evidência arquivada e datada. Um inventário de fornecedores atualizado. Um dossier de due diligence por fornecedor de Faixa A. Registos de acesso remoto. Relatórios de teste de restauro. Atas de revisão trimestral de acessos. A auditoria interna não produz segurança apenas; produz a prova documentada de que a segurança foi gerida. Essa prova é o que responde à autoridade.

7: Como a INFOS implementa

Como fornecedor de software vertical para indústria, a INFOS é, para os seus clientes, um fornecedor de Faixa A — e sabemos o que isso implica. O ERP MULTI e os módulos KORA Productivity de chão-de-fábrica operam com acessos nominativos, registo de atividade para evidência e integração com soluções de monitorização, e a nossa área de cibersegurança apoia a avaliação técnica da cadeia de fornecimento e a verificação de restauros no datacenter. Não lhe vendemos um certificado para arquivar — ajudamos a construir o processo que resiste à primeira auditoria a sério e ao primeiro incidente real.

Na prática, quando uma fábrica têxtil ou de calçado nos pede apoio no dossier NIS2, começamos pelo que nos diz respeito diretamente: como o nosso acesso ao ERP está controlado, que registos produzimos, que RTO e RPO são realistas para a arquitetura que montámos juntos. Um fornecedor de Faixa A que não consegue responder a estas perguntas sobre si próprio não tem autoridade para ajudar ninguém a auditar os outros. Preferimos chegar à conversa com as nossas próprias respostas já em ordem.

No fim, auditar fornecedores de TI sob a NIS2 é menos sobre papelada e mais sobre uma pergunta incómoda: se o seu integrador fosse comprometido esta noite, a que horas de amanhã é que a sua linha volta a produzir? Se não tem a resposta em horas e por escrito, a auditoria ainda não começou.

Fontes

• Diretiva (UE) 2022/2555 (NIS2) — Jornal Oficial da União Europeia; transposição em Portugal pelo Decreto-Lei n.º 65/2025 (Diário da República).
• CNCS — Centro Nacional de Cibersegurança / CERT.PT, Relatório de incidentes 2024 (2.758 incidentes, +36% face a 2023; ~78% em entidades privadas).
• IBM — Cost of a Data Breach Report 2024 (custo médio global de 4,88 milhões de dólares).
• Verizon — Data Breach Investigations Report (DBIR) 2025 (ransomware em 88% das violações em PME).
• ISO/IEC 27001 — Information security management systems (requisitos de certificação).
• ISO/IEC 27017 e ISO/IEC 27018 — controlos de segurança e proteção de dados pessoais em ambientes de cloud.

Perguntas frequentes

O que é o artigo 21.º da NIS2 e como me afeta?

O artigo 21.º obriga-o a gerir o risco da cadeia de fornecimento. Isto significa que a sua empresa responde perante a autoridade pelo que os seus fornecedores de TI fazem — ou não fazem — em matéria de segurança. Se o fornecedor que aloja o seu ERP sofrer um incidente, você é responsável perante o regulador.

Como classifico os meus fornecedores de TI?

Divida-os em três faixas. Faixa A: acesso administrativo a sistemas críticos (ERP, MES, firewall). Faixa B: acesso a dados sem privilégio de parar produção (BI, folha de vencimentos). Faixa C: sem acesso a sistemas críticos (consumíveis, hardware). A profundidade da auditoria escala com a faixa — não gaste o mesmo esforço em todos.

Qual é o erro mais comum nas auditorias de fornecedores?

Auditar a empresa errada. Gasta-se energia a exigir ISO 27001 ao grande fornecedor de cloud — que já a tem — e ignora-se o pequeno integrador local com acesso remoto permanente ao ERP com password partilhada. O risco mora no elo mais pequeno, não no maior.

O que devo registar no inventário de fornecedores?

Registe cinco atributos por fornecedor: tipo de serviço, dados a que acede, nível de privilégio (leitura/escrita/administrativo), modo de acesso (VPN, RDP, agente, API) e criticidade para a produção. Seja honesto sobre o modo de acesso — «VPN» não é suficiente; diferencie entre site-to-site permanente, utilizador sob demanda ou acesso permanente não supervisionado.

Sou PME pequena — a NIS2 aplica-se-me?

Muitas pequenas fábricas não estão diretamente no âmbito. Mas se subcontrata para multinacionais (Inditex, Decathlon, Lacoste) ou distribuidores, está na cadeia de fornecimento de quem está. O artigo 21.º empurra a obrigação para baixo. Vai receber questionários de segurança — estar preparado deixou de ser opcional.

Como devo estruturar o processo de auditoria?

Desenhe um pipeline em quatro camadas: inventário e classificação, due diligence documental, verificação técnica e monitorização contínua. A ordem importa — não faz due diligence antes de classificar, porque não sabe a quem exigir o quê. Cada camada produz um artefacto arquivável: inventário, dossier, relatório, alertas.

Qual é a diferença entre uma auditoria pontual e um processo defensável?

Uma auditoria pontual é uma reacção — alguém levou um susto, pedem-se certificados, arquivam-se PDFs, fecha-se o assunto. Seis meses depois, ninguém se lembra do dossier. A NIS2 obriga a transformar isso num processo recorrente, auditável e defensável perante a autoridade competente, com evidências e rastreabilidade.