Contrato com fornecedor de TI após a NIS2: cláusulas de segurança, SLA e notificação de incidentes

Um contrato com um fornecedor de TI no contexto da NIS2 não deve limitar-se a uma declaração de conformidade, a uma cláusula genérica de segurança e a um indicador mensal de disponibilidade. Deve converter o risco associado ao serviço numa divisão inequívoca de responsabilidades, níveis de serviço mensuráveis, comunicação célere de incidentes, acesso a evidências e um plano de saída exequível. O ponto de partida é a criticidade do serviço e a distribuição efetiva do controlo entre as partes. Só com esta base é possível definir as medidas de segurança, os prazos, os direitos de verificação e as obrigações de notificação que devem constar do contrato.

O contrato como mecanismo de controlo do risco

A revisão contratual não deve começar por um modelo predefinido de cláusula de segurança, mas pelo mapeamento das dependências da organização relativamente aos seus fornecedores. Para cada fornecedor, é necessário identificar os serviços, processos, sistemas, dados e localizações abrangidos e avaliar, em seguida, o impacto de uma indisponibilidade ou violação de segurança. A prioridade deve incidir nas dependências cuja perturbação possa interromper a atividade, comprometer o cumprimento de obrigações ou dificultar a resposta a um incidente. Nem todos os serviços de TI exigem, portanto, as mesmas salvaguardas contratuais.

A classificação da criticidade do fornecedor deve resultar da análise de impacto no negócio e da avaliação do risco, e não apenas do valor do contrato. Exigem especial atenção os serviços cuja continuidade e gestão de incidentes permanecem sob responsabilidade da organização, embora seja o fornecedor a controlar a informação técnica, os registos de eventos, as cópias de segurança ou o ambiente necessário à recuperação do serviço. A organização deve também designar um responsável pelo risco associado ao fornecedor. Sem esta função, as responsabilidades entre compras, TI, segurança e o proprietário do processo permanecem dispersas.

O contrato deve ser concebido a partir de cenários de perturbação: falha do serviço, ataque, perda ou corrupção de dados, indisponibilidade do pessoal do fornecedor, interrupção da cadeia de subcontratantes e cessação da relação contratual. Para cada cenário, devem ser definidos os atos de cada parte, as responsabilidades, o fluxo de informação e as condições de recuperação. É desta análise que decorrem os níveis de disponibilidade, os tempos de resposta e recuperação, a documentação exigida e os direitos de verificação.

Uma declaração de elevada disponibilidade não esclarece durante quanto tempo pode permanecer indisponível um sistema de controlo da produção, a partir de que momento se contabiliza a interrupção nem quem deve fornecer os dados necessários para avaliar o incidente. Também não assegura o acesso a cópias dos registos de eventos, a informação sobre subcontratantes ou aos dados necessários para migrar o serviço em segurança. Estas lacunas tornam-se normalmente visíveis durante uma falha, quando a divisão de responsabilidades já não pode ficar implícita.

A referência à NIS2 ou aos requisitos aplicáveis do KSC deve concluir a análise de risco e de responsabilidades, não substituir o conteúdo operacional do contrato. O enquadramento mais amplo de gestão é apresentado no artigo NIS2 para empresas industriais: entidades abrangidas, obrigações introduzidas e preparação da organização sem reduzir o tema exclusivamente às TI. As alterações contratuais devem ser sempre ajustadas ao papel da organização, à criticidade do serviço e à distribuição real do controlo entre as partes.

Âmbito do serviço e responsabilidades

A divisão de responsabilidades deve ser descrita num anexo técnico, em vez de ficar diluída numa definição genérica do objeto do contrato. O anexo deve identificar os ativos e ambientes abrangidos, os tipos de dados, os locais de tratamento e de prestação do serviço, as interfaces, os horários de suporte e as exclusões. Sem esta informação, não é possível determinar claramente onde termina a responsabilidade do fornecedor, que evento inicia a medição do SLA ou quem protege os elementos situados na interface entre sistemas.

É recomendável descrever as medidas de segurança através do resultado esperado, da parte responsável e da evidência de execução, mantendo os detalhes tecnológicos na documentação técnica sujeita a controlo. Esta abordagem reduz o risco de rápida desatualização do contrato. O catálogo normalizado de controlos do fornecedor só deve ser aceite após comparação com o risco específico do serviço e tratamento das lacunas identificadas. A matriz de responsabilidades deve distinguir o proprietário do controlo, quem o executa e quem tem autoridade para aprovar exceções.

Quando o ambiente é administrado pelo fornecedor, o contrato deve ainda regular os acessos privilegiados: segregação de funções, método de autenticação, registo das atividades administrativas e revogação imediata dos privilégios após uma mudança de função ou o termo da colaboração. Uma simples declaração de execução de cópias de segurança é insuficiente se o cliente desconhecer quem as cifra, onde são armazenadas, quem as pode restaurar e que documento comprova o resultado do teste de recuperação.

O fornecedor deve manter uma lista atualizada dos subcontratantes com impacto no serviço, incluindo a descrição das respetivas funções e localizações de tratamento, e impor-lhes requisitos não menos exigentes do que os acordados com o cliente. O contrato deve estabelecer que alterações exigem aprovação prévia e quais requerem apenas notificação e uma nova avaliação do risco. A certificação de um sistema de gestão pode apoiar esta avaliação, mas não substitui as responsabilidades definidas para o serviço concreto. Esta relação é desenvolvida no artigo NIS2 e NP EN ISO 27001: o que proporciona o certificado e o que continua a faltar para a conformidade com o KSC.

Cláusulas de segurança passíveis de verificação

Uma cláusula de segurança só se torna verificável quando define o resultado esperado, o âmbito de aplicação, a frequência da atividade, o método de comprovação e o processo de gestão de exceções. Expressões como “de acordo com as melhores práticas” ou “com a devida diligência” podem complementar os requisitos, mas não permitem avaliar se o fornecedor cumpriu adequadamente a obrigação. Para cada controlo, é necessário identificar o responsável pelo requisito, o período de retenção das evidências e a parte autorizada a aceitar uma exceção.

Os requisitos assim estruturados devem abranger, pelo menos, a gestão de vulnerabilidades e atualizações, a manutenção de configurações seguras, a cifragem, a proteção e retenção dos registos de eventos, a execução de cópias de segurança, os testes de recuperação, a gestão de alterações e o controlo de acessos. A frequência das revisões de privilégios, dos testes de recuperação e dos relatórios, bem como os prazos para tratar vulnerabilidades, deve resultar da avaliação do risco do serviço. Não deve ser idêntica para todos os fornecedores.

Cada exceção deve ser incluída num registo, com a respetiva fundamentação, prazo de resolução, proprietário do risco e controlos compensatórios. A sua aprovação exige avaliar se esses controlos reduzem efetivamente o risco ao nível aceite pela organização.

Uma disposição sobre a execução regular de cópias de segurança permanece incompleta se não indicar os dados e sistemas abrangidos, o período de retenção, a proteção contra alteração ou eliminação, as regras de acesso e a frequência dos testes de recuperação. Deve ainda definir como o fornecedor comunica uma cópia ou teste sem êxito, quem aprova as ações corretivas e que relatório comprova o respetivo encerramento. Do mesmo modo, a obrigação de tratar vulnerabilidades exige a definição do método de classificação, dos prazos de resposta em função do risco, das regras para adiar atualizações e da documentação dos controlos temporários.

As evidências devem ser divididas entre as fornecidas periodicamente e as disponibilizadas mediante pedido. O primeiro grupo pode incluir resumos de vulnerabilidades, relatórios de atualizações, resultados de testes de recuperação e confirmações das revisões de acessos. Após um incidente, uma alteração significativa ou a identificação de uma exceção, podem ser necessários resultados detalhados dos testes, registos de eventos, histórico de alterações, registo de exceções e plano de ações corretivas. O âmbito, os responsáveis e o período de retenção destes elementos devem ser articulados com as regras apresentadas no artigo Documentação NIS2 e KSC antes de uma inspeção: políticas, registos e evidências efetivamente necessários.

O direito de verificação deve ser graduado e exequível, incluindo no relacionamento com fornecedores de serviços em nuvem. O primeiro nível pode compreender a análise documental e uma reunião de esclarecimento; o seguinte, relatórios independentes ou testes acordados; e a auditoria no local pode ser reservada para situações de risco elevado, incidentes significativos ou ausência de evidências credíveis. O contrato deve regular os prazos, a confidencialidade, o âmbito técnico e o tratamento das constatações, sem conceder ao cliente direitos inexequíveis num ambiente partilhado.

SLA orientado para a resiliência, não apenas para a disponibilidade

O SLA deve resultar da análise de impacto no negócio, e não do catálogo normalizado de parâmetros do fornecedor. O proprietário do processo começa por definir o período tolerável de interrupção, a perda de dados admissível e o impacto da indisponibilidade na produção, no atendimento ao cliente, na faturação e nas obrigações legais. Só depois se estabelecem os objetivos de tempo de recuperação, os requisitos relativos ao serviço alternativo e ao modo de contingência e as prioridades dos pedidos. Um indicador mensal de disponibilidade não permite determinar se uma única falha, ocorrida num momento crítico, interromperá o processo durante mais tempo do que a organização pode aceitar.

Além da disponibilidade, o contrato deve definir o tempo para confirmar a receção do pedido, iniciar o diagnóstico, repor a funcionalidade e eliminar a causa, bem como a frequência das comunicações, os níveis de escalonamento e o modo de intervenção fora do horário normal. O tempo de resposta não corresponde ao tempo de recuperação, e a ativação de uma solução alternativa não significa a resolução integral do problema. A separação destes conceitos permite à equipa operacional saber quando poderá retomar o trabalho e ao proprietário do serviço determinar quando o fornecedor concluirá a análise da causa e implementará uma ação corretiva duradoura.

No caso de um sistema de controlo de um processo de produção, um incidente crítico pode exigir escalonamento imediato e comunicação contínua até à ativação do modo de contingência. A mesma anomalia num ambiente de formação pode receber uma prioridade inferior. A classificação deve, por isso, assentar no impacto no negócio, e não apenas na descrição técnica do erro. Quando existam dados históricos fiáveis, a definição dos limiares deve considerar os tempos reais de resposta e recuperação, os resultados de disponibilidade e o número de falhas recorrentes.

O mecanismo de medição deve identificar a fonte dos dados, o fuso horário, o momento de início e paragem do contador, o horário acordado para a prestação do serviço, as janelas de manutenção e as regras para alteração da classificação do incidente. As exclusões da medição devem constar de uma lista fechada e verificável. Não podem abranger eventos incluídos na esfera de responsabilidade do fornecedor. A coerência destes acordos com a capacidade operacional efetiva pode ser avaliada através de uma Auditoria NIS2 numa empresa industrial — como verificar se a organização está preparada para as novas obrigações.

Os créditos de serviço ou compensações simbólicas não recuperam o processo nem reduzem o impacto da interrupção. São mais relevantes a obrigação de apresentar um plano de correção, o escalonamento para a gestão, a realização de testes adicionais de resiliência e o direito de cessar o contrato em caso de incumprimento persistente ou recorrente dos níveis acordados. Uma sanção financeira pode reforçar a responsabilização, mas não substitui o mecanismo de recuperação do serviço, eliminação das causas e prevenção de novas falhas.

Incidentes e obrigações de notificação

O contrato deve obrigar o fornecedor a comunicar sem demora qualquer evento suscetível de afetar o serviço, os dados, a continuidade operacional ou a segurança do cliente. A primeira notificação não pode depender da confirmação integral da causa, da dimensão do dano ou da qualificação jurídica do evento. O prazo contratual deve incluir uma margem que permita ao cliente realizar a sua própria avaliação e cumprir eventuais prazos externos. Deve resultar da criticidade do serviço e da disponibilidade de um ponto de contacto permanente, e não da conveniência organizacional das partes.

O fluxo de informação deve ser dividido em alerta inicial, atualizações de situação, relatório pós-incidente e análise da causa raiz. Para cada etapa, devem ser definidos o conjunto de dados, o canal autorizado, os destinatários, a frequência das atualizações e as regras de escalonamento na ausência de contacto. A primeira comunicação deve incluir, pelo menos, a hora da deteção, os ativos e serviços afetados, o impacto previsto, as medidas adotadas, os indicadores técnicos disponíveis, a avaliação do risco de propagação e o prazo da atualização seguinte. A lista de contactos deve incluir substitutos e ser testada periodicamente, também fora do horário normal.

Se o fornecedor detetar tráfego anómalo no ambiente que suporta uma aplicação crítica, deve alertar o cliente antes de determinar se ocorreu efetivamente uma violação. O cliente ativa o seu próprio processo de gestão de incidentes, designa o responsável pelas decisões, mobiliza a equipa de resposta e, quando aplicável, a seguradora, e determina quem aprova a notificação externa e a comunicação aos clientes. O fornecedor preserva os registos e vestígios técnicos acordados e apoia a análise, a contenção e a determinação do âmbito do evento, mas não assume a responsabilidade regulatória do cliente.

As cláusulas devem ainda definir as regras de preservação e disponibilização das evidências, de proteção da sua integridade, de documentação das decisões e de preparação dos dados necessários às notificações e à posterior análise da causa raiz. Os prazos, destinatários e conteúdo das notificações externas devem ser verificados caso a caso, tendo em conta a legislação em vigor, o estatuto da organização e a natureza do evento. Os registos de notificações, decisões, escalonamentos e ações devem ser articulados com o artigo Documentação NIS2 e KSC antes de uma inspeção: políticas, registos e evidências efetivamente necessários, e o calendário de adaptação com o artigo Implementação da NIS2 após a inscrição no registo KSC — plano de ação até 3 de abril de 2027.

Implementação, monitorização e saída segura

A assinatura de uma adenda não encerra o processo de gestão do fornecedor. O responsável pelo contrato deve realizar revisões periódicas dos resultados do SLA, dos incidentes, das exceções, das ações corretivas, das alterações de subcontratantes e da atualidade das evidências que comprovam o cumprimento dos requisitos. A base desta monitorização é um registo de contratos que inclua, pelo menos, a data de renovação, o responsável, a criticidade do serviço e o estado de implementação das medidas de segurança acordadas. Uma declaração de conformidade não substitui relatórios, resultados de testes ou registos que demonstrem o cumprimento das obrigações.

Antes da renovação do contrato ou de uma alteração significativa do serviço, devem ser reavaliadas a sua criticidade, as dependências técnicas e processuais, a concentração de serviços num único fornecedor, a exequibilidade dos controlos e a possibilidade de transição para uma solução alternativa. Esta revisão permite decidir se uma adenda é suficiente ou se será necessário iniciar um novo processo de contratação. Se um fornecedor estratégico recusar uma auditoria ou a alteração das condições, a organização deve documentar a lacuna e decidir entre implementar um controlo compensatório, aceitar formalmente o risco residual ou substituir o fornecedor.

O plano de saída deve ser exequível antes de o contrato ser denunciado. Deve abranger a devolução e migração dos dados num formato utilizável, a assistência à migração, a manutenção da continuidade durante o período de transição, a revogação dos acessos, a eliminação das cópias e a confirmação da execução destas atividades. Em paralelo, devem ser preservados os registos necessários para fins legais, probatórios e de auditoria. Um teste prático consiste na recuperação dos dados junto de outro fornecedor, acompanhada da verificação da sua integridade, do tempo de migração e da possibilidade de desativar as contas anteriores.

A modernização da carteira contratual deve começar pelos serviços com maior impacto no negócio, priorizando as lacunas segundo a gravidade e a urgência. A eficácia dos mecanismos adotados deve ser testada através de um exercício de resposta a incidentes e de uma auditoria por amostragem das evidências. Os resultados das revisões de SLA, dos incidentes, das exceções, das ações corretivas e dos testes ao plano de saída demonstrarão se os requisitos funcionam na prática ou permanecem apenas no texto contratual.

O âmbito da avaliação pode ser articulado com o artigo Auditoria NIS2 numa empresa industrial — como verificar se a organização está preparada para as novas obrigações. As obrigações da organização devem também ser determinadas em função do seu estatuto, abordado no artigo Diretiva NIS2 — a quem se aplica e que empresas têm de cumprir os novos requisitos?