Contratos NIS2 com fornecedores com evidência ISO 27001

São 07:40 de uma segunda-feira. O CISO de uma plataforma logística suportada por serviços cloud abre uma mensagem de correio eletrónico de um fornecedor de serviços geridos de deteção e resposta (MDR). A mensagem é curta, cautelosa e desconfortável: o fornecedor detetou acesso suspeito a um ambiente de suporte utilizado por vários clientes. Os detalhes são limitados. O fornecedor promete uma atualização “assim que for praticável”.

Às 08:15, o responsável de conformidade pergunta se isto pode desencadear reporte ao abrigo da NIS2. Às 08:40, a equipa de compras procura o contrato. Às 09:10, o secretário do conselho de administração quer um ponto de situação sobre a responsabilização da gestão. Às 10:00, a assessoria jurídica pergunta se o contrato inclui notificação em 24 horas, direitos de auditoria, controlos de subcontratantes, acesso a evidência, obrigações de continuidade de negócio, devolução de dados e disposições de apagamento.

Ninguém quer descobrir, durante um incidente em curso, que o acordo com um fornecedor crítico se limita a referir “medidas de segurança razoáveis”.

É aqui que as cláusulas contratuais NIS2 com fornecedores deixam de ser texto jurídico padrão e passam a ser controlos operacionais. Para entidades essenciais e importantes, a governação de fornecedores faz agora parte da responsabilização do órgão de administração, da evidência para supervisão, da preparação para incidentes, da garantia para clientes, do cumprimento em matéria de privacidade e do planeamento de resiliência. Um contrato assinado não basta. A organização deve demonstrar que os riscos de fornecedores são identificados, aprovados, tratados, monitorizados e suportados por evidência.

A abordagem da Clarysec parte de um princípio simples: se a cláusula do fornecedor não puder ser monitorizada, evidenciada e testada, não é um controlo.

O Zenith Blueprint: roteiro de 30 passos para auditores coloca as relações com fornecedores na fase Controls in Action, Passo 23, onde acordos, monitorização, integração, reavaliação e evidência de auditoria são traduzidos em trabalho prático de SGSI. O Zenith Controls: guia de conformidade cruzada mapeia depois os controlos de fornecedores ISO/IEC 27002:2022 para NIS2, DORA, RGPD da UE, NIST, COBIT 2019, normas ISO de suporte e metodologias de auditoria.

O resultado é um modelo de governação de fornecedores que pode ser usado por compras, jurídico, segurança, privacidade e pelo órgão de administração.

Porque é que a NIS2 transforma contratos com fornecedores em registos de evidência

O Article 20 da NIS2 exige que os órgãos de administração das entidades essenciais e importantes aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e sejam responsabilizados por infrações. O Article 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição e manutenção seguras, avaliação da eficácia, higiene de cibersegurança, criptografia, segurança dos recursos humanos, controlo de acesso, gestão de ativos e autenticação multifator (MFA), quando adequada.

O Article 21(3) torna explícita a diligência prévia sobre fornecedores. As organizações devem considerar vulnerabilidades específicas de fornecedores diretos e prestadores de serviços, a qualidade global dos produtos e das práticas de cibersegurança, bem como os procedimentos de desenvolvimento seguro.

Esta formulação cria uma obrigação prática: as relações com fornecedores devem ser baseadas no risco, contratualmente exigíveis e passíveis de revisão. Um questionário de fornecedor guardado numa pasta não basta. Um contrato genérico sem prazo de notificação de incidentes, sem direitos de acesso a evidência e sem visibilidade sobre subcontratantes não basta. Uma certificação de fornecedor que ninguém reviu não basta.

A ISO/IEC 27001:2022 fornece o modelo operacional. As cláusulas 4.1 a 4.4 exigem que a organização compreenda o contexto, as partes interessadas, as obrigações legais e contratuais, o âmbito do SGSI e as dependências. As cláusulas 5.1 a 5.3 exigem liderança, política, funções e reporte. As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos, tratamento de riscos e a Declaração de Aplicabilidade. As cláusulas 8.1 a 8.3 exigem controlo operacional, repetição de avaliações de riscos e resultados documentados.

Para a governação de fornecedores, os controlos mais importantes do Anexo A da ISO/IEC 27002:2022 incluem:

• A.5.19 Segurança da informação nas relações com fornecedores
• A.5.20 Tratamento da segurança da informação em acordos com fornecedores
• A.5.21 Gestão da segurança da informação na cadeia de fornecimento TIC
• A.5.22 Monitorização, revisão e gestão de alterações dos serviços de fornecedores
• A.5.24 Planeamento e preparação da gestão de incidentes
• A.5.25 Avaliação e decisão sobre eventos de segurança da informação
• A.5.26 Resposta a incidentes de segurança da informação
• A.5.27 Aprendizagem com incidentes de segurança da informação
• A.5.28 Recolha de evidência
• A.5.29 Segurança da informação durante perturbações
• A.5.30 Preparação das TIC para a continuidade de negócio
• A.5.31 Requisitos legais, estatutários, regulamentares e contratuais
• A.5.34 Privacidade e proteção de PII
• A.8.8 Gestão de vulnerabilidades técnicas
• A.8.13 Cópia de segurança da informação
• A.8.15 Registo
• A.8.16 Atividades de monitorização
• A.8.24 Utilização de criptografia
• A.8.32 Gestão de alterações

A questão central é a propriedade. Uma cláusula tem pouco valor se ninguém for proprietário do risco, se ninguém rever a evidência, se ninguém acompanhar exceções e se ninguém escalar incumprimentos.

A política Enterprise Política de segurança de terceiros e fornecedores explicita este ponto:

“Direitos de auditoria, inspeção e pedido de evidência de segurança”

Da secção “Requisitos de governação”, cláusula 5.3.4 da política.

Para PME, a Política de segurança de terceiros e fornecedores para PME estabelece a mesma expectativa prática:

“Direitos de auditoria ou disponibilidade de evidência de conformidade”

Da secção “Requisitos de governação”, cláusula 5.3.4 da política.

Esta distinção é importante. Uma organização de menor dimensão pode não conseguir auditar presencialmente todos os grandes prestadores de serviços cloud, mas pode exigir acesso a evidência de garantia, como o âmbito da certificação ISO/IEC 27001:2022, relatórios SOC, resumos de testes de intrusão, atestados de remediação de vulnerabilidades, resumos de incidentes, relatórios de testes de continuidade de negócio e confirmações de apagamento de dados.

A espinha dorsal de três controlos da garantia de fornecedores NIS2

No modelo de conformidade cruzada da Clarysec, três controlos ISO/IEC 27002:2022 formam a espinha dorsal da governação de fornecedores NIS2: 5.19, 5.20 e 5.22.

A.5.19 identifica o risco do fornecedor

O controlo A.5.19, Segurança da informação nas relações com fornecedores, é a base. Exige que as organizações protejam a informação e os ativos acedidos, tratados, armazenados ou geridos por fornecedores.

O Zenith Controls classifica-o como controlo preventivo que cobre confidencialidade, integridade e disponibilidade, com o conceito de cibersegurança “Identificar” e a capacidade operacional “Segurança das relações com fornecedores”. Liga o A.5.19 ao A.5.20, A.5.21, A.5.14, A.5.36 e A.5.10. Em termos práticos, a organização identifica o risco de fornecedor, define expectativas de segurança, controla a exposição da cadeia de fornecimento TIC, protege a transferência de informação, monitoriza a conformidade e estende as obrigações de utilização aceitável a partes externas.

Para a NIS2, isto mapeia diretamente para a segurança da cadeia de fornecimento do Article 21(2)(d) e para a diligência prévia sobre fornecedores do Article 21(3). Para o RGPD da UE, suporta o requisito de utilizar subcontratantes que ofereçam garantias suficientes. Para DORA, suporta a gestão de riscos de terceiros TIC, a diligência prévia pré-contratual, a revisão de criticidade, o risco de concentração e a supervisão ao longo do ciclo de vida.

A.5.20 torna o requisito exigível

O controlo A.5.20, Tratamento da segurança da informação em acordos com fornecedores, transforma expectativas de segurança em obrigações contratuais. O Zenith Controls explica claramente a relação entre A.5.19 e A.5.20:

“5.20 serve como formalização contratual das necessidades e riscos de segurança identificados em 5.19. Enquanto 5.19 envolve a avaliação de riscos de terceiros e a definição de expectativas de segurança, 5.20 assegura que essas expectativas são juridicamente vinculativas através de contratos ou acordos de nível de serviço (SLA). Sem 5.20, as medidas de segurança identificadas em 5.19 não teriam exigibilidade.”

É aqui que as decisões de risco NIS2 se transformam em cláusulas: notificação de violações, direitos de auditoria e de acesso a evidência, cifragem, controlo de acesso, gestão de vulnerabilidades, aprovação de subcontratantes, transferência segura, continuidade, cooperação regulamentar, apoio à saída e apagamento de dados.

A.5.22 demonstra que o contrato está vivo

O controlo A.5.22, Monitorização, revisão e gestão de alterações dos serviços de fornecedores, evita que a garantia de fornecedores se torne um exercício único de integração. O Zenith Controls liga o A.5.22 ao A.5.19 e A.5.20, mas também ao A.5.29 Segurança da informação durante perturbações, A.8.8 Gestão de vulnerabilidades técnicas, A.5.36 Cumprimento de políticas, regras e normas de segurança da informação, A.5.15 Controlo de acesso e A.8.27 Arquitetura segura de sistemas e princípios de engenharia.

Isto é relevante porque os serviços de fornecedores mudam. As localizações dos dados mudam. Os subcontratantes subsequentes mudam. Surgem vulnerabilidades. As certificações expiram. Padrões de incidentes emergem. Um fornecedor aceitável no ano passado pode representar um risco excessivo hoje.

O que devem incluir as cláusulas contratuais NIS2 com fornecedores

O Zenith Blueprint, na fase Controls in Action, Passo 23, apresenta um conjunto prático de áreas para acordos com fornecedores:

“As principais áreas normalmente tratadas em acordos com fornecedores incluem:

✓ Obrigações de confidencialidade, incluindo âmbito, duração e restrições de divulgação a terceiros; ✓ Responsabilidades de controlo de acesso, como quem pode aceder aos seus dados, como as credenciais são geridas e que monitorização está implementada; ✓ Medidas técnicas e organizativas para proteção de dados, cifragem, transmissão segura, cópia de segurança e compromissos de disponibilidade; ✓ Prazos e protocolos de reporte de incidentes, frequentemente com prazos definidos (por exemplo, “notificar no prazo de 24 horas”); ✓ Direito de auditoria, incluindo frequência, âmbito e acesso a evidência relevante (por exemplo, relatórios de testes de intrusão, SoA, certificações); ✓ Controlos de subcontratantes, exigindo que o fornecedor transmita obrigações de segurança equivalentes aos seus parceiros a jusante; ✓ Disposições de fim de contrato, como devolução ou destruição de dados, recuperação de ativos e desativação de contas.”

Da fase Controls in Action, Passo 23: Controlos organizacionais.

Uma cláusula NIS2 robusta para fornecedores é suficientemente específica para ser testada. “O fornecedor deve manter segurança adequada” é fraco. “O fornecedor deve notificar o contacto de segurança do cliente no prazo de 24 horas relativamente a incidentes confirmados ou suspeitos que afetem sistemas do cliente, dados do cliente, disponibilidade do serviço ou obrigações regulamentares de reporte” é auditável.

As cláusulas de incidentes devem alinhar com os prazos de reporte da NIS2

O Article 23 da NIS2 cria um modelo faseado de reporte para incidentes significativos: um alerta precoce no prazo de 24 horas após a tomada de conhecimento, uma notificação de incidente no prazo de 72 horas, relatórios intermédios quando solicitados e um relatório final no prazo de um mês após a notificação do incidente. Um incidente significativo é aquele que causou ou é capaz de causar perturbação operacional grave, perdas financeiras ou danos materiais ou imateriais consideráveis a terceiros.

Os contratos com fornecedores devem suportar essa cronologia. Se um prestador de serviços geridos crítico demorar quatro dias a confirmar se os ambientes dos clientes foram afetados, o cliente pode falhar a sua própria janela regulamentar.

A política Enterprise Política de segurança de terceiros e fornecedores exige:

“Prazos de notificação de violações (por exemplo, no prazo de 24 ou 72 horas, consoante a criticidade e os requisitos regulamentares)”

Da secção “Requisitos de governação”, cláusula 5.3.3 da política.

A política PME Política de segurança de terceiros e fornecedores para PME também exige prazos definidos de notificação de violações, da secção “Requisitos de governação”, cláusula 5.3.3 da política.

Para incidentes com PII, a política Enterprise Política de Gestão de Incidentes e Violações de PII liga o reporte de cibersegurança, do setor financeiro, a clientes e a destinatários de serviços:

“[Condicional] O Responsável de Privacidade / Gestor do PIMS DEVE coordenar qualquer reporte setorial, de cibersegurança, do setor financeiro, a clientes ou a destinatários de serviços exigido quando um incidente de alto impacto relativo a dados pessoais atingir um limiar de reporte aplicável, e DEVE registar a autoridade, destinatário, cronologia, submissão e evidência de confirmação de receção em REG01 e REG10.”

Da secção “Notificação e comunicações”, cláusula 4.4.6 da política.

Isto é evidência NIS2 madura: não apenas uma mensagem de notificação, mas um registo da autoridade, destinatário, cronologia, submissão, confirmação de receção, impacto, causa raiz e ações de seguimento.

Alinhamento com privacidade e DORA sem programas de fornecedores duplicados

Muitos fornecedores NIS2 também tratam dados pessoais. O Article 28 do RGPD da UE exige que os responsáveis pelo tratamento utilizem subcontratantes que ofereçam garantias suficientes e definam as obrigações do subcontratante num contrato escrito. O Article 5 do RGPD da UE exige responsabilização pelo tratamento seguro e lícito. As obrigações do RGPD da UE em matéria de violações também exigem cooperação rápida quando incidentes em fornecedores afetem dados pessoais.

A política Enterprise Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros define o ponto de controlo de aprovação:

“[Ambos] O Proprietário do Fornecedor / Compras DEVE assegurar que os contratos com subcontratantes e subcontratantes subsequentes incluem assistência em privacidade, garantia de segurança, interface de incidentes através da PII15, devolução ou apagamento através da PII10, ligação a transferências através da PII13 e cooperação em auditoria ou garantia antes da aprovação.”

Da secção “Controlos de contrato e instruções documentadas”, cláusula 4.3.6 da política.

Também exige revisão da evidência antes da aprovação:

“[Todos] O Responsável de Segurança da Informação DEVE rever a evidência de garantia de segurança para cada relação com subcontratante, subcontratante subsequente ou terceiro com acesso a PII ou alojamento de PII antes da aprovação, e DEVE registar o resultado em REG08 ou REG12.”

Da secção “Diligência prévia e avaliação de riscos”, cláusula 4.2.2 da política.

DORA acrescenta outra camada quando o fornecedor presta serviços a uma entidade financeira. Os Articles 28 a 30 de DORA exigem governação de terceiros TIC, registos de contratos de serviços TIC, diligência prévia baseada no risco, avaliação de criticidade, análise de risco de concentração, direitos de auditoria e inspeção, direitos de cessação, estratégias de saída e disposições contratuais obrigatórias. O Article 30 é especialmente relevante porque exige conteúdo contratual que cubra descrições de serviços, localizações, proteção de dados, acesso e recuperação, níveis de serviço, assistência em incidentes, cooperação com autoridades, direitos de auditoria, subcontratação, medidas de contingência e apoio à transição.

A resposta prática não é manter três programas de fornecedores separados para NIS2, RGPD da UE e DORA. É um único modelo harmonizado de evidência de fornecedores, mapeado entre referenciais.

O NIST CSF 2.0 é útil porque a sua função GOVERN exige compreender dependências, obrigações legais, obrigações contratuais, apetite ao risco, políticas, responsabilização e supervisão. A sua categoria de cadeia de fornecimento GV.SC cobre funções de fornecedores, criticidade, requisitos contratuais, diligência prévia, monitorização, inclusão em incidentes, monitorização do ciclo de vida e disposições de fim de relação.

Um fluxo de trabalho Clarysec para integrar um fornecedor crítico

Suponha que está a integrar um prestador de serviços de segurança geridos que irá monitorizar telemetria de endpoints, receber alertas contendo identificadores de utilizadores e apoiar a triagem de incidentes para uma organização abrangida pela NIS2.

Passo 1: classificar o fornecedor

Registe o fornecedor no registo centralizado de fornecedores com a descrição do serviço, sistemas e dados acedidos, envolvimento de PII, suporte a serviços essenciais ou importantes, acesso privilegiado, países de prestação do serviço, subcontratantes, dependências de quarta parte, classificação de criticidade, proprietário do risco, proprietário de compras e revisor de segurança da informação.

Isto implementa as cláusulas 4.2, 4.3, 6.1.2 e 8.1 da ISO/IEC 27001:2022 ao ligar requisitos de partes interessadas, dependências, propriedade do risco e controlo operacional.

Passo 2: mapear o risco para a SoA

No Zenith Blueprint, fase de Gestão de Riscos, Passo 13, a Clarysec recomenda referências cruzadas a regulamentos no Registo de Riscos ou na SoA:

“Referências cruzadas a regulamentos: se determinados controlos forem implementados especificamente para cumprir o RGPD da UE, NIS2 ou DORA, pode indicar isso no Registo de Riscos (como parte da justificação do impacto do risco) ou nas notas da SoA.”

Da fase de Gestão de Riscos, Passo 13: Planeamento do Tratamento do Risco e Declaração de Aplicabilidade.

Para o MSSP, inclua pelo menos A.5.19, A.5.20, A.5.21, A.5.22, A.5.24 a A.5.28, A.5.29, A.5.30, A.5.31, A.5.34, A.8.8, A.8.15, A.8.16 e A.8.24.

Passo 3: exigir cláusulas executáveis

Use uma adenda de segurança do fornecedor que exija notificação inicial de incidente em 24 horas, atualização detalhada em 72 horas, reporte final do incidente, MFA para acesso privilegiado, contas nominativas de utilizador, controlos de subcontratantes, transferência segura, cifragem, evidência de garantia, cooperação regulamentar, evidência BCP e DR, apoio à saída, devolução ou apagamento de dados e revogação de acessos.

A política Enterprise Política de Gestão do Risco de Dependência de Fornecedores fornece o requisito de continuidade:

“Quando aplicável, um requisito para que o fornecedor mantenha os seus próprios Planos de Continuidade de Negócio (BCP/DRP) e planos de gestão de incidentes, os teste e nos disponibilize resumos ou relatórios de teste mediante pedido.”

Da secção “Requisitos de implementação”, cláusula 6.8.4 da política.

Passo 4: construir o pacote de evidência de garantia

Antes da aprovação, solicite o acordo assinado, SLA, adenda de segurança, âmbito da certificação ISO/IEC 27001:2022 ou garantia equivalente, relatório SOC quando disponível, resumo executivo de teste de intrusão, resumo de gestão de vulnerabilidades, resumo do procedimento de resposta a incidentes, resumo de teste BCP ou DR, atestado de controlo de acesso e MFA, lista de subcontratantes, procedimento de apagamento de dados e saída, e DPA quando houver tratamento de PII.

A política PME Política de segurança de terceiros e fornecedores para PME torna mensurável a evidência contratual básica:

“Acordos e SLA assinados”

Da secção “Aplicação e cumprimento”, cláusula 8.3.2.1 da política.

Também identifica evidência recorrente de fornecedores:

“Certificações de segurança válidas ou evidência de controlo atualizada”

Da secção “Requisitos de implementação da política”, cláusula 6.3.1.2 da política.

Para diligência prévia de fornecedores mais ampla, a Política de Auditoria e Monitorização da Conformidade estabelece:

“A diligência prévia de fornecedores deve incluir a revisão de certificações (por exemplo, ISO 27001, SOC 2), questionários de segurança e registos de incidentes.”

Passo 5: monitorizar com base na criticidade

A política Enterprise Política de Gestão de Privacidade de Subcontratantes, Subcontratantes Subsequentes e Terceiros exige monitorização trimestral para relações de alto risco envolvendo PII:

“[Todos] O Proprietário do Fornecedor / Compras DEVE monitorizar trimestralmente as relações ativas de alto risco com subcontratantes e subcontratantes subsequentes e anualmente as restantes relações ativas com subcontratantes e subcontratantes subsequentes de PII, face às condições de diligência prévia, estado contratual, estado da garantia, questões em aberto e datas de revisão em REG08.”

Da secção “Monitorização contínua, assistência, interface de divulgação e saída”, cláusula 4.5.1 da política.

É assim que o A.5.22 se torna real. A revisão deve determinar se o fornecedor permanece dentro do apetite ao risco, se a evidência está atualizada, se existem questões em aberto, se ocorreram incidentes e se alterações ao serviço exigem reavaliação.

Como os auditores testam cláusulas NIS2 com fornecedores

Os auditores raramente começam por ler a política de forma isolada. Amostram fornecedores e seguem o trilho de evidência.

Um auditor ISO/IEC 27001:2022 solicitará o inventário de fornecedores, classificação de risco, critérios de fornecedores, registos de diligência prévia, contratos, evidência, mapeamento da SoA e histórico de monitorização. Para o Anexo A 5.20, o auditor verificará se os contratos amostrados contêm cláusulas exigíveis. Para o Anexo A 5.22, o auditor testará se os relatórios foram revistos, se as exceções foram registadas e se as ações tiveram seguimento.

Uma autoridade competente NIS2 pode concentrar-se em saber se as práticas de cibersegurança dos fornecedores e os procedimentos de desenvolvimento seguro foram avaliados ao abrigo do Article 21(3). Um revisor orientado para DORA pode pedir entradas do registo de contratos TIC, estratégias de saída, análise de risco de concentração e disposições obrigatórias do Article 30. Um auditor de privacidade pode testar contratos com subcontratantes, obrigações em cadeia para subcontratantes subsequentes, interfaces de violação e evidência de garantias suficientes.

A política Enterprise Política de Segurança e Controlo de Acesso a PII mostra como controlo de acesso, vulnerabilidades, configuração, monitorização e criptografia se ligam à ISO/IEC 27001:2022:

“ISO/IEC 27001:2022 — Cláusula 6.1.3; Cláusula 8.1; controlos do Anexo A 8.1, 8.2, 8.3, 8.5, 8.8, 8.9, 8.15, 8.16, 8.20, 8.24. Tratados pelas cláusulas [4.1.1; 4.1.2; 4.2.1; 4.2.3; 4.3.2; 4.4.1; 4.4.2; 4.5.1; 4.5.2; 4.6.1; 4.6.3; 4.7.1; 4.7.4; 4.7.5; 4.8.1; 4.8.2; 7.1.1; 7.1.2].”

Da secção “Normas e referenciais de referência”, cláusula 13.9 da política.

Quando um fornecedor tem acesso a PII, sistemas privilegiados ou dados de monitorização, a evidência de controlo de acesso não está separada da garantia de fornecedores. Faz parte do mesmo trilho de evidência.

A armadilha das compras: contratos assinados sem operações de garantia

A falha mais comum na governação de fornecedores NIS2 não é a ausência de contratos. É a lacuna entre a linguagem contratual e a operação diária.

Um contrato pode exigir resumos anuais de testes de intrusão, mas nenhum proprietário os solicita. Pode exigir notificação de incidentes em 24 horas, mas o fornecedor dispõe apenas de um endereço genérico de suporte. Pode exigir aprovação de subcontratantes, mas a equipa de compras nunca recebe notificações de alteração. Pode incluir direitos de auditoria, mas a organização não tem processo para avaliar exceções em relatórios SOC. Pode exigir apagamento de dados na saída, mas a TI nunca valida a desativação de contas.

O Zenith Blueprint, fase Controls in Action, Passo 23, explica como os controlos de fornecedores ganham vida:

“Na prática, este controlo ganha vida através de:

✓ Avaliações de risco de fornecedores, ✓ Questionários de diligência prévia antes da contratação, ✓ Modelos contratuais com termos de segurança incorporados, ✓ Listas de verificação de integração de fornecedores que incluem provisionamento de acessos e configuração da monitorização, ✓ Reavaliações contínuas, especialmente quando o âmbito do fornecedor muda, ocorrem incidentes ou se aproximam renovações.

E este controlo não termina nos fornecedores de primeiro nível. O seu fornecedor pode externalizar para os seus próprios prestadores, e a sua organização pode continuar a suportar o risco.”

Essa é a mensagem NIS2 ao nível do órgão de administração: externalizar a prestação do serviço não externaliza a responsabilização.

Lista de verificação de remediação de contratos NIS2 com fornecedores

Comece pelos 20 fornecedores mais críticos e execute um exercício de remediação focado:

• Identificar fornecedores que suportam serviços essenciais ou importantes.
• Confirmar se cada fornecedor trata PII, suporta serviços regulados ou tem acesso privilegiado.
• Atribuir um proprietário do negócio, um proprietário de compras e um revisor de segurança.
• Verificar se a avaliação de riscos do fornecedor está atualizada e alinhada com o âmbito real do serviço.
• Confirmar que o contrato inclui linha de base de segurança, notificação de incidentes, direitos de auditoria ou de acesso a evidência, controlos de subcontratantes, continuidade, transferência segura, controlo de acesso, cooperação em vulnerabilidades e cláusulas de saída.
• Confirmar que os prazos de violação suportam necessidades de escalonamento em 24 horas e 72 horas, quando relevantes.
• Solicitar evidência de garantia atualizada, incluindo certificações, relatórios SOC, resumos de testes de intrusão, testes BCP ou DR e histórico de incidentes.
• Rever a evidência; não se limite a armazená-la.
• Registar exceções e atribuir proprietários de remediação.
• Atualizar a SoA e o Registo de Riscos quando os controlos de fornecedores suportarem NIS2, RGPD da UE, DORA ou compromissos com clientes.
• Agendar a frequência de monitorização com base na criticidade do fornecedor.
• Testar uma via de escalonamento de incidentes de fornecedor.
• Testar uma via de cessação de fornecedor, incluindo devolução de dados, apagamento, recuperação de ativos e revogação de acessos.

Se não conseguir demonstrar estes pontos para um fornecedor crítico, o contrato ainda não está pronto para auditoria.

Transformar cláusulas de fornecedores em evidência para supervisão

A governação de fornecedores NIS2 é agora uma disciplina operacional ativa. Autoridades de supervisão, clientes, auditores de certificação, equipas de privacidade, parceiros do setor financeiro e órgãos de administração não perguntarão apenas se existem cláusulas de fornecedores. Perguntarão se as cláusulas são baseadas no risco, exigíveis, monitorizadas, suportadas por evidência e ligadas a reporte de incidentes, continuidade, controlo de acesso, gestão de vulnerabilidades, obrigações em cadeia para subcontratantes e saída.

A Clarysec ajuda as organizações a fechar essa lacuna com o Zenith Blueprint, que transforma controlos de fornecedores em fases do SGSI, tratamento de riscos, entradas da SoA, rotinas de integração e evidência de auditoria. O Zenith Controls mapeia os controlos de fornecedores ISO/IEC 27002:2022 A.5.19, A.5.20 e A.5.22 para NIS2, DORA, RGPD da UE, NIST, COBIT 2019, normas ISO de suporte e metodologias de auditoria. As políticas de fornecedores e privacidade da Clarysec fornecem a estrutura das cláusulas, as expectativas de evidência e as rotinas de monitorização que tornam a garantia de fornecedores defensável.

A sua próxima ação é simples: selecione cinco fornecedores críticos, amostre os respetivos contratos, mapeie cada cláusula para o tratamento de riscos ISO/IEC 27001:2022 e para os controlos do Anexo A, solicite evidência de garantia atualizada e execute um exercício tabletop de notificação de incidentes em 24 horas. Se o trilho de evidência falhar, os toolkits da Clarysec dão-lhe a estrutura para o reparar antes que um incidente, uma revisão de cliente ou um pedido de supervisão o façam por si.