1. Âmbito e Objetivos

1.1 Âmbito de Aplicação

Esta Política de Segurança da Cadeia de Fornecimento aplica-se a [nome da organização] e abrange todas as relações com fornecedores, prestadores de serviços, contratantes e parceiros que têm acesso a sistemas, dados ou infraestrutura críticos da organização.

Enquadramento Regulatório: Esta política cumpre com os requisitos da [NIS2 Artigo 21(2)(d), ISO 27036, regulamentações nacionais] e estabelece critérios mínimos de segurança para toda a cadeia de fornecimento.

1.2 Objetivos de Segurança

• [Objetivo 1: Minimizar riscos de segurança introduzidos por fornecedores e terceiros]
• [Objetivo 2: Garantir conformidade regulatória e contratual]
• [Objetivo 3: Estabelecer processos de due diligence e avaliação de riscos]
• [Objetivo 4: Assegurar monitorização e auditoria contínua de fornecedores]
• [Objetivo 5: Implementar requisitos contratuais de segurança]

1.3 Tipos de Fornecedores Abrangidos

Esta política aplica-se a:

• Fornecedores Críticos: [empresas que fornecem infraestrutura, aplicações, dados ou serviços essenciais]
• Prestadores de Serviços: [consultores, integradores, provedores de cloud, outsourcing IT]
• Contratantes: [subcontratantes que podem ter acesso a sistemas ou dados]
• Parceiros Tecnológicos: [parceiros de integração, resellers, desenvolvimentos customizados]

2. Definições e Classificação de Fornecedores

2.1 Definições-Chave

2.2 Níveis de Criticidade de Fornecedores

Nível Crítico

[Definição: Fornecedores com acesso total a dados sensíveis, sistemas críticos ou infraestrutura essencial. Falha no fornecedor causa impacto direto em operações ou segurança.]

Requisitos Mínimos:

• [Auditoria anual obrigatória]
• [Certificação ISO 27001 ou equivalente]
• [SLAs de segurança específicos no contrato]
• [Monitorização em tempo real de segurança]

Nível Alto

[Definição: Fornecedores com acesso a dados importantes, sistemas de suporte crítico ou funcionalidades essenciais.]

Requisitos Mínimos:

• [Auditoria a cada 18-24 meses]
• [Certificação reconhecida (ISO 27001, SOC 2) ou questionário de segurança validado]
• [SLAs de segurança no contrato]
• [Monitorização periódica de vulnerabilidades]

Nível Médio

[Definição: Fornecedores com acesso limitado a dados não-críticos ou funções de suporte.]

Requisitos Mínimos:

• [Auditoria a cada 2-3 anos]
• [Questionário de segurança anual]
• [Cláusulas básicas de segurança no contrato]

Nível Baixo

[Definição: Fornecedores com acesso mínimo a dados públicos ou funções periféricas.]

Requisitos Mínimos:

• [Avaliação inicial de segurança]
• [Cláusulas básicas de confidencialidade no contrato]

2.3 Critérios de Classificação

A criticidade é determinada com base nos seguintes critérios:

3. Processo de Gestão do Ciclo de Vida de Fornecedores

O ciclo de vida de um fornecedor compreende cinco fases principais: onboarding, avaliação, contratualização, monitorização e offboarding.

3.1 Due Diligence e Onboarding

3.1.1 Pré-Avaliação

Antes de qualquer contratação, deve ser efetuada uma pré-avaliação que inclui:

• Informações Gerais: [Nome da organização, tipo de fornecedor, localização geográfica, número de funcionários]
• Histórico de Segurança: [Incidentes anteriores, breaches conhecidos, reclamações de clientes]
• Certificações Existentes: [ISO 27001, SOC 2, NIS2, GDPR compliance, auditorias de terceiros]
• Referências: [Contacto com clientes atuais para referências de segurança]
• Avaliação Preliminar de Risco: [Classificação inicial de criticidade e nível de risco]

3.1.2 Assinatura de Acordos Preliminares

[O fornecedor deve assinar NDA e/ou Master Service Agreement com cláusulas de segurança antes de onboarding formal]

3.1.3 Documentação Inicial

Recolher a seguinte documentação:

• [Política de Segurança da Informação do fornecedor]
• [Declaração de conformidade com GDPR/proteção de dados]
• [Plano de Continuidade e Recuperação de Desastres]
• [Documentação de certificações de segurança]
• [Contactos de segurança e gestão de incidentes do fornecedor]

3.2 Avaliação de Risco Inicial

3.2.1 Questionário de Segurança

[Baseado na criticidade, deve ser preenchido um questionário de segurança com 30+ perguntas cobrindo: políticas de segurança, controles técnicos, conformidade, incidentes anteriores, etc.]

3.2.2 Avaliação Técnica

Dependendo da criticidade, podem incluir-se:

• [Teste de penetração inicial]
• [Verificação de vulnerabilidades conhecidas]
• [Inspeção de controles de acesso e autenticação]
• [Avaliação de conformidade de dados (GDPR, etc.)]

3.2.3 Decisão de Onboarding

[Com base na avaliação, a decisão é: Aprovado (com ou sem condições), Suspenso (até correções) ou Rejeitado]

3.3 Contratualização

3.3.1 Requisitos de SLA de Segurança

O contrato deve incluir SLAs de segurança que especifiquem:

• Disponibilidade de Serviço: [Uptime mínimo (ex: 99.9%), tempo de recuperação de falhas]
• Tempo de Resposta a Incidentes: [Detecção: 4h; Notificação: 24h; Remediação: 72h (ou conforme aplicável)]
• Patch Management: [Crítico: 7 dias; Importante: 14 dias; Normal: 30 dias]
• Auditorias: [Frequência e direitos de auditoria da organização]

3.3.2 Cláusulas de Segurança Obrigatórias

O contrato deve incluir:

• [Confidencialidade e proteção de dados]
• [Notificação de incidentes (24h-72h conforme regulação)]
• [Auditoria de segurança e direitos de inspeção]
• [Subcontratação restrita (consentimento prévio)]
• [Requisitos de segurança mínimos técnicos]
• [Devolução/destruição de dados no término do contrato]
• [Conformidade com leis de proteção de dados (GDPR, etc.)]
• [Restrições geográficas de dados (localização, transferências)]

3.4 Monitorização Contínua

3.4.1 Monitorização de Conformidade

[Verificações regulares (trimestrais/semestrais/anuais conforme criticidade) de: cumprimento de SLAs, aplicação de patches, conformidade de dados, alertas de segurança]

3.4.2 Auditorias Periódicas

• Fornecedores Críticos: [Auditoria anual; revisões de segurança semestrais]
• Fornecedores Alto Risco: [Auditoria a cada 18-24 meses; revisões anuais]
• Fornecedores Médio Risco: [Auditoria a cada 2-3 anos; revisões conforme necessário]
• Fornecedores Baixo Risco: [Avaliação inicial; revisões conforme necessário]

3.4.3 Gestão de Alertas de Segurança

[Monitorização de CVEs, alertas de segurança, notícias de breaches que afetem fornecedores; avaliação de impacto e necessidade de ação]

3.5 Offboarding

3.5.1 Processo de Encerramento

Quando um contrato termina ou é cancelado:

• [Notificação formal ao fornecedor com cronograma de encerramento]
• [Remoção de acessos a sistemas e dados em data específica]
• [Confirmação de destruição de dados/informações confidenciais]
• [Verificação de retorno de equipamentos, chaves, certificados]
• [Relatório final de segurança]

3.5.2 Verificação de Conformidade

[Auditoria de offboarding para confirmar que todas as obrigações contratuais foram cumpridas, dados foram removidos, e acessos foram revogados]

4. Avaliação de Riscos de Fornecedores

4.1 Metodologia de Avaliação de Risco

4.1.1 Abordagem Estruturada

A avaliação de risco de fornecedores segue uma metodologia estruturada em fases:

1. Identificação de Ativos: [Quais dados, sistemas, funcionalidades críticas o fornecedor acede]
2. Identificação de Ameaças: [Potenciais falhas de segurança, incidentes que afetam este fornecedor]
3. Avaliação de Vulnerabilidades: [Falhas de segurança técnica, processos inadequados, certificações ausentes]
4. Cálculo de Risco: [Risco = Probabilidade de Ameaça x Impacto de Falha]
5. Decisão Mitigação: [Implementar controlos, exigir certificações, monitorizar, recusar contratação]

4.1.2 Matriz de Risco

4.2 Questionário de Segurança de Fornecedores

4.2.1 Seção 1: Organização e Governança (5 questões)

1. [Questão 1: Existe uma política de segurança da informação documentada e comunicada a todos os funcionários?]
2. [Questão 2: Existe um CISO ou responsável de segurança designado?]
3. [Questão 3: Qual é a estrutura de governança de segurança? (comité, direção, responsabilidades)]
4. [Questão 4: Com que frequência são realizadas auditorias internas ou externas de segurança?]
5. [Questão 5: Existe um programa de gestão de conformidade regulatória?]

4.2.2 Seção 2: Segurança Técnica (8 questões)

6. [Questão 6: Como é implementada a autenticação de utilizadores? (senhas, MFA, SSO)]
7. [Questão 7: Quais controles de acesso são implementados? (RBAC, segregação de funções)]
8. [Questão 8: Como é feita a criptografia de dados em trânsito e em repouso?]
9. [Questão 9: Existe um processo de gestão de vulnerabilidades e patch management?]
10. [Questão 10: Como é implementada a monitorização e logging de segurança?]
11. [Questão 11: Qual é a política de backup e recuperação de desastres?]
12. [Questão 12: Existe segmentação de rede ou isolamento de sistemas críticos?]
13. [Questão 13: Como são tratados os acessos privilegiados (PAM)?]

4.2.3 Seção 3: Proteção de Dados (6 questões)

14. [Questão 14: Como é garantida a conformidade com GDPR? (DPA, processamento lícito)]
15. [Questão 15: Existe classificação de dados e controles por nível de sensibilidade?]
16. [Questão 16: Como é gerida a retenção e eliminação segura de dados?]
17. [Questão 17: Qual é a política de transferências internacionais de dados?]
18. [Questão 18: Existe documentação de Privacy Impact Assessment (DPIA) para dados sensíveis?]
19. [Questão 19: Como é gerida a transparência e direitos dos titulares de dados?]

4.2.4 Seção 4: Incidentes e Continuidade (6 questões)

20. [Questão 20: Existe um plano de resposta a incidentes documentado?]
21. [Questão 21: Qual é o processo de notificação de incidentes? (tempo, escalação)]
22. [Questão 22: Existe um plano de continuidade de negócio e recuperação de desastres?]
23. [Questão 23: Qual é o RTO/RPO (Recovery Time/Point Objective) documentado?]
24. [Questão 24: Com que frequência são testados os planos de continuidade?]
25. [Questão 25: Existe uma política de ciberseguro ou cobertura de incidentes?]

4.2.5 Seção 5: Conformidade e Certificações (5 questões)

26. [Questão 26: Possui certificação ISO 27001? (ou equivalente)]
27. [Questão 27: Possui certificação SOC 2 ou relatório de auditoria externa?]
28. [Questão 28: Cumpre com regulações específicas do sector? (PSD2, HIPAA, etc.)]
29. [Questão 29: Teve incidentes de segurança nos últimos 3 anos? (descrever)]
30. [Questão 30: Está disposto a auditorias de segurança periódicas pela nossa organização?]

4.3 Scoring e Rating de Segurança

4.3.1 Critérios de Scoring

4.4 Auditorias e Certificações

4.4.1 Certificações Reconhecidas

As seguintes certificações são reconhecidas como equivalente a avaliação interna:

• ISO/IEC 27001: [Sistema de Gestão de Segurança da Informação - Reconhecida para fornecedores críticos]
• SOC 2 Type II: [Service Organization Control - Reconhecida para fornecedores de serviços cloud]
• NIS2 Compliance: [Operadores de Serviços Essenciais - Reconhecida conforme aplicável]
• GDPR Compliance Report: [Auditoria de conformidade GDPR por terceiro independente]
• Certificações Específicas do Sector: [PSD2, HIPAA, TISAX, conforme aplicável]

4.4.2 Processo de Auditoria de Fornecedores

[Auditorias podem ser: on-site, remota, virtual walkthrough, questionário detalhado, teste de penetração. A frequência e tipo dependem da criticidade e resultados anteriores.]

4.4.3 Direitos de Auditoria

O contrato com fornecedores críticos deve garantir:

• [Acesso a relatórios de segurança (internos ou de terceiros) com freqência pré-acordada]
• [Direito a auditar on-site com pré-aviso de 14-30 dias]
• [Acesso a logs de segurança conforme contrato]
• [Direito a testes de penetração (com concordância prévia)]
• [Notificação de qualquer mudança estrutural que afete segurança]

5. Requisitos Contratuais de Segurança

5.1 Cláusulas Obrigatórias de Segurança

5.1.1 Cláusula de Confidencialidade e Proteção de Dados

[O fornecedor compromete-se a manter a confidencialidade de toda a informação não pública acedida, incluindo dados de clientes, dados técnicos, propriedade intelectual. Tal informação não pode ser divulgada a terceiros sem consentimento por escrito, salvo se legalmente obrigado (com notificação prévia).]

5.1.2 Cláusula de Conformidade com Legislação de Proteção de Dados

[O fornecedor compromete-se a cumprir com GDPR e legislação local de proteção de dados, incluindo: processamento conforme instrções, medidas de segurança técnicas/organizacionais, documentação de DPA, notificação de incidentes, direitos dos titulares de dados.]

5.1.3 Cláusula de Notificação de Incidentes de Segurança

[O fornecedor compromete-se a notificar a nossa organização de qualquer suspeita ou confirmação de incidente de segurança ou acesso não autorizado, no prazo máximo de: Suspeita - 24h; Confirmação - 72h (conforme NIS2). Inclui detalhes: tipo de incidente, dados afetados, ações tomadas, contactos.]

5.1.4 Cláusula de Auditoria e Direitos de Inspeção

[A nossa organização tem o direito a: (a) auditar as práticas de segurança do fornecedor, (b) requerer relatórios de conformidade, (c) inspecionar instalações com aviso prévio, (d) verificar cumprimento de requisitos contratuais. O fornecedor cobre custos de auditoria (até X auditorias por ano são sem custo).]

5.1.5 Cláusula de Requisitos Técnicos de Segurança Mínimos

O fornecedor compromete-se a implementar no mínimo:

• [Autenticação multifator (MFA) para acessos à nossa infraestrutura]
• [Criptografia de dados em trânsito (TLS 1.2+) e em repouso (AES 256)]
• [Controles de acesso baseados em função (RBAC) com segregação de funções]
• [Logging e monitorização de todas as atividades críticas]
• [Firewalls, anti-malware, sistemas de detecção de intrusão]
• [Gestão de vulnerabilidades: scanning regular, patch management]

5.1.6 Cláusula de Devolução/Destruição de Dados

[Ao término do contrato, o fornecedor compromete-se a: (a) devolver ou destruir de forma segura todos os dados e informações confidenciais, (b) remover acessos a sistemas, (c) certificar por escrito que todas as obrigações foram cumpridas, (d) nenhuma cópia retida, salvo se legalmente obrigado.]

5.1.7 Cláusula de Subcontratação Restrita

[O fornecedor não pode subcontratar qualquer parte do serviço sem consentimento prévio por escrito. Qualquer subcontratante deve estar sujeito aos mesmos requisitos de segurança. A organização mantém direitos de auditoria sobre subcontratantes.]

5.2 SLAs de Segurança

5.2.1 Definição de SLA

5.3 Direitos de Auditoria

5.3.1 Tipos de Auditoria

• Auditoria Documental: [Revisão de políticas, procedimentos, certificações do fornecedor]
• Auditoria On-Site: [Inspeção de instalações, entrevistas, verificação de controles implementados]
• Teste de Penetração: [Teste de segurança técnica, vulnerabilidades, contra-medidas]
• Revisão de Logs: [Acesso a logs de segurança, logs de acesso, auditoria de atividades]
• Questionário Detalhado: [Respostas a perguntas específicas sobre práticas de segurança]

5.3.2 Frequência e Escopo

[A frequência de auditoria é determinada pela criticidade e últimos resultados. Escopo inclui: acesso físico, controles técnicos, procedimentos operacionais, gestão de pessoal, conformidade regulatória.]

5.4 Notificação de Incidentes (24h/72h)

5.4.1 Prazos de Notificação

• 24 horas: [Notificação inicial de suspeita ou confirmação de incidente (informação imediata, confirmação de recepção)]
• 72 horas: [Relatório detalhado com análise: tipo de incidente, dados afetados, impacto, ações tomadas, cronograma de investigação]

5.4.2 Informações Requeridas na Notificação

• [Tipo de incidente (breach de dados, indisponibilidade, malware, acesso não autorizado)]
• [Data/hora de descoberta e potencial ocorrência do incidente]
• [Sistemas/dados afetados]
• [Estimativa de número de registos/pessoas afetadas]
• [Ações imediatas tomadas]
• [Contacto 24/7 para escalação]

5.5 Proteção de Dados (Alinhamento GDPR)

5.5.1 Conformidade GDPR

• Data Processing Agreement (DPA): [Deve ser assinado em conformidade com GDPR Artigo 28 antes do processamento de dados pessoais]
• Legitimidade de Processamento: [Fornecedor processa dados apenas conforme instrções da organização, para fins específicos]
• Subprocessadores: [Autorização prévia e notificação para qualquer subprocessador de dados pessoais]
• Direitos de Titulares: [Acesso, retificação, eliminação, portabilidade - fornecedor deve facilitar exercício de direitos]
• Transferências Internacionais: [Mecanismos legais apropriados (Standard Contractual Clauses, Binding Corporate Rules) para transferências fora da UE]

5.5.2 Medidas de Segurança Técnicas e Organizacionais

• [Criptografia de dados em trânsito e em repouso]
• [Controles de acesso e autenticação forte]
• [Segregação de dados de diferentes clientes/entidades]
• [Logging de acessos a dados pessoais]
• [Procedimentos de resposta a incidentes e notificação]
• [Programa de formação sobre proteção de dados para pessoal]

6. Gestão de Acessos de Terceiros

6.1 Princípio do Menor Privilégio

6.1.1 Definição

[O Princípio do Menor Privilégio (PoLP - Principle of Least Privilege) significa que cada fornecedor/terceiro recebe apenas o acesso mínimo necessário para executar as suas tarefas, nada mais.]

6.1.2 Aplicação Prática

• Por Função: [Acesso diferenciado conforme função (administrador, operador, auditor, consultor)]
• Por Sistema: [Acesso apenas aos sistemas necessários para realizar o trabalho]
• Por Dados: [Acesso apenas aos tipos de dados necessários (não a dados sensíveis se desnecessário)]
• Por Tempo: [Acessos temporários com expiração automática; acessos permanentes apenas quando necessário]
• Por Operação: [Permissões granulares (ex: ler mas não escrever, criar mas não eliminar)]

6.2 Autenticação e Autorização

6.2.1 Autenticação

Todos os fornecedores com acesso a sistemas críticos devem ser autenticados através de:

• Contas Individuais: [Cada utilizador tem conta única e identificável (não partilhada)]
• Credenciais Fortes: [Senhas com 12+ caracteres, complexidade, histórico sem reutilização]
• Autenticação Multifator (MFA): [Obrigatória para acessos remotos (MFA baseado em app, token hardware, SMS como último recurso)]
• Integração com Directory: [Se possível, integração com diretório corporativo (LDAP, Azure AD) com sincronização]]

6.2.2 Autorização

• RBAC (Role-Based Access Control): [Acessos baseados em papéis (roles) pré-definidos com permissões específicas]
• Segregação de Funções (SoD): [Funções conflitantes não são atribuídas ao mesmo utilizador (ex: autorizar e aprovar)]
• Access Review Periódica: [Revisão trimestral/semestral de acessos ativos para garantir conformidade]
• Aprovação de Acessos: [Manager do fornecedor aprova; IT valida necessidade; dono do sistema autoriza]

6.3 Autenticação Multifator Obrigatória

6.3.1 Requisitos de MFA

[MFA é obrigatória para: (1) Acessos VPN/remotos, (2) Acessos administrativos/privilegiados, (3) Acessos a dados críticos/sensíveis, (4) Fornecedores com acesso crítico]

6.3.2 Métodos Aceites

• Preferido: [Authenticator app (Google Authenticator, Microsoft Authenticator, Duo)]
• Aceitável: [Token hardware (FIDO2, YubiKey)]
• Último Recurso: [SMS/push notifications (conforme NIS2, não recomendado)]
• Não Aceite: [Segurança de perguntas, geolocalização apenas]

6.3.3 Gestão de Backup Codes

[Backup codes são gerados aquando ativação de MFA; armazenados com segurança; utilizador responsável pela segurança; revogação imediata se comprometidos]

6.4 Monitorização de Acessos

6.4.1 Logging de Acessos

• O quê Logar: [Todas as autenticações (sucesso/falha), acessos a recursos críticos, operações administrativas, transferências de dados]
• Informação Registada: [Utilizador, timestamp, ação, recurso, origem IP, resultado (sucesso/falha), detalhes adicionais]
• Retenção: [Logs mantidos por mínimo 12 meses; logs críticos por 24 meses; conforme regulação]
• Segurança: [Logs protegidos contra alteração; integridade verificada; acesso restrito a auditores/segurança]

6.4.2 Monitorização em Tempo Real

• [Alertas para múltiplas autenticações falhadas (ex: >3 em 10 min)]
• [Alertas para acessos fora de horário normal ou localização incomum]
• [Alertas para operações sensíveis (criação de contas, alteração de permissões, eliminação de dados)]
• [Alertas para tentativas de escalação de privilégios]

6.4.3 Análise de Anomalias

[Análise regular de padrões de acesso para detectar: acessos não autorizados, atividades anómalas, potencial insider threat, comprometimento de credenciais]

6.5 Revogação de Acessos

6.5.1 Cenários de Revogação

• Fim de Contrato: [Acesso revogado no dia final do contrato (ou até 1 hora após término)]
• Fim de Projeto: [Acesso revogado imediatamente após conclusão do projeto]
• Mudança de Função: [Acessos desnecessários revogados quando função muda]
• Incidente de Segurança: [Revogação imediata se credenciais comprometidas ou violação de política]
• Demissão/Saída: [Se fornecedor é uma pessoa física e deixa a organização, acesso revogado imediatamente]
• Inatividade: [Acessos não utilizados há 90+ dias revistos e potencialmente revogados]

6.5.2 Processo de Revogação

1. [1. Notificação formal ao fornecedor da data/hora de revogação]
2. [2. Aviso ao utilizador de revogação pendente]
3. [3. Execução da revogação (acesso desativado/eliminado)]
4. [4. Confirmação de que não há acesso residual]
5. [5. Documentação da revogação no registo]
6. [6. Comunicação de confirmação da revogação ao fornecedor]

6.5.3 Verificação de Revogação Completa

[Após revogação, verificar que: (1) Credenciais/tokens não funcionam, (2) Sem acesso residual por conta de sistema, (3) Equipamentos devolvidos, (4) Chaves/certificados revogados, (5) VPN/remote access desativado]

7. Monitorização Contínua de Fornecedores

7.1 Framework de Monitorização Contínua

7.1.1 Objetivos da Monitorização

A monitorização contínua tem como objetivos:

• [Verificar cumprimento de SLAs de segurança contratualizados]
• [Detetar desvios de conformidade, vulnerabilidades ou anomalias]
• [Identificar mudanças no perfil de risco do fornecedor]
• [Garantir visibilidade sobre segurança da cadeia de fornecimento]
• [Facilitar decisões de continuidade ou terminação de contratos]

7.1.2 Frequência de Monitorização

7.2 Métricas de Segurança a Monitorizar

7.2.1 Métricas de Disponibilidade

• Uptime: [Percentagem de disponibilidade do serviço (mensal/trimestral)]
• MTTR (Mean Time To Repair): [Tempo médio de recuperação após falha]
• MTBF (Mean Time Between Failures): [Tempo médio entre falhas consecutivas]
• Incidentes de Indisponibilidade: [Número e duração de incidentes no período]

7.2.2 Métricas de Segurança Técnica

• Vulnerabilidades Críticas Abertas: [Número de CVEs críticos não remediados]
• Tempo de Aplicação de Patches: [Tempo médio para aplicar patches críticos/importantes]
• Tentativas de Autenticação Falhadas: [Número de autenticações falhadas (potencial brute force)]
• Alertas de Segurança: [Número de alertas de segurança gerados por SIEM/monitoring]
• Compliance Score: [Pontuação de conformidade (ex: % de controlos implementados)]

7.2.3 Métricas de Conformidade

• SLA Compliance: [% de cumprimento de SLAs contratualizados]
• Certificações Válidas: [Status de certificações (ISO 27001, SOC 2, etc.)]
• Auditorias Concluídas: [Número de auditorias realizadas e status de remediações]
• Incidentes Notificados: [Número de incidentes notificados dentro do prazo (24h/72h)]

7.3 Calendário de Revisão de Desempenho

7.3.1 Revisões Trimestrais

[A cada trimestre, realiza-se revisão com fornecedores críticos para avaliar: métricas de disponibilidade, incidentes de segurança, compliance de SLAs, vulnerabilidades identificadas, planos de remediação]

7.3.2 Revisões Semestrais

[A cada semestre, realiza-se revisão com fornecedores de alto risco para avaliar: conformidade geral, resultados de auditorias, atualizações de certificações, mudanças de infraestrutura ou processos]

7.3.3 Revisões Anuais

[Anualmente, todos os fornecedores são revistos: reclassificação de criticidade, renovação de avaliação de risco, atualização de contratos/SLAs, decisão de continuidade ou terminação]

7.4 Procedimentos de Escalação para Não-Conformidade

7.4.1 Níveis de Não-Conformidade

7.4.2 Processo de Escalação

1. Nível 1: [Account Manager do fornecedor - prazo de resposta: 24-48h]
2. Nível 2: [Diretor de Operações do fornecedor - prazo de resposta: 12-24h]
3. Nível 3: [C-Level do fornecedor (CTO/CISO/CEO) - prazo de resposta: 4-12h]
4. Nível 4: [Ativação de cláusulas contratuais/legais - imediato]

7.4.3 Registo de Não-Conformidades

[Todas as não-conformidades devem ser registadas com: data identificação, tipo de não-conformidade, fornecedor afetado, impacto, ações tomadas, prazo de remediação, status de resolução, data resolução]

8. Gestão de Incidentes de Fornecedores

8.1 Requisitos de Notificação de Incidentes (24h/72h)

8.1.1 Notificação Inicial (24 horas)

O fornecedor deve notificar a organização no prazo máximo de 24 horas após tomar conhecimento de qualquer suspeita ou confirmação de incidente que afete:

• [Segurança de dados da nossa organização ou clientes]
• [Disponibilidade de serviços críticos contratualizados]
• [Infraestrutura ou sistemas que processam dados da organização]
• [Acesso não autorizado a recursos da organização]

Informação Mínima Requerida (24h):

• [Data e hora de descoberta do incidente]
• [Tipo de incidente (breach, indisponibilidade, malware, acesso não autorizado)]
• [Sistemas/serviços potencialmente afetados]
• [Estimativa preliminar de impacto]
• [Contactos do fornecedor para escalação 24/7]
• [Ações imediatas tomadas para contenção]

8.1.2 Relatório Detalhado (72 horas)

O fornecedor deve fornecer relatório detalhado no prazo de 72 horas contendo:

• [Descrição completa do incidente e cronologia de eventos]
• [Análise de causa raiz (se identificada)]
• [Escopo completo: sistemas, dados, utilizadores afetados]
• [Número estimado de registos/pessoas impactadas]
• [Medidas de contenção e remediação implementadas]
• [Plano de recuperação e cronograma]
• [Impacto em conformidade regulatória (GDPR, NIS2, etc.)]
• [Recomendações para prevenção futura]

8.1.3 Atualizações Contínuas

[Após o relatório de 72h, o fornecedor deve fornecer atualizações regulares (diárias/semanais conforme gravidade) até resolução completa e encerramento formal do incidente]

8.2 Procedimentos de Resposta Conjunta

8.2.1 Ativação de Resposta Conjunta

Para incidentes graves/críticos, ativar resposta conjunta:

1. [Fornecedor notifica conforme procedimento 24h]
2. [CSIRT interno da organização é ativado]
3. [Estabelecer ponte de comunicação (call bridge 24/7)]
4. [Definir Incident Commander e papéis de cada parte]
5. [Coordenar contenção, investigação, remediação]
6. [Comunicação coordenada com stakeholders/reguladores]

8.2.2 Matriz de Responsabilidades na Resposta

8.3 Protocolos de Comunicação Durante Incidentes

8.3.1 Canais de Comunicação

Canal Primário: [Email dedicado: security-incidents@[organização].pt]

Canal de Escalação: [Telefone 24/7 do CISO: +351 XXX XXX XXX]

Canal de Coordenação: [Conference bridge/Teams dedicado durante incidente]

Canal de Updates: [Portal seguro para partilha de relatórios e evidências]

8.3.2 Frequência de Comunicação

• Incidentes Críticos: [Updates de 4 em 4 horas até contenção; depois diários]
• Incidentes Graves: [Updates de 8 em 8 horas até contenção; depois diários]
• Incidentes Moderados: [Updates diários até resolução]
• Incidentes Menores: [Update inicial + update de resolução]

8.3.3 Confidencialidade na Comunicação

[Toda a comunicação sobre incidentes é confidencial. Informação partilhada em canais encriptados. Acordos de NDA aplicam-se. Comunicação externa coordenada entre as partes.]

8.4 Processo de Post-Incident Review

8.4.1 Relatório Final de Incidente

No prazo de [30 dias] após resolução, o fornecedor deve fornecer relatório final contendo:

• [Executive summary do incidente]
• [Timeline detalhado de eventos]
• [Causa raiz confirmada]
• [Impacto total quantificado (dados, sistemas, utilizadores)]
• [Ações de remediação implementadas]
• [Lessons learned e recomendações]
• [Plano de ação preventiva para evitar recorrência]

8.4.2 Reunião de Post-Mortem

[Organizar reunião conjunta de post-mortem para discutir: o que correu bem, o que correu mal, melhorias de processo, atualizações de contratos/SLAs se necessário]

8.4.3 Acompanhamento de Remediações

[Estabelecer plano de acompanhamento para verificar implementação de melhorias recomendadas. Incluir verificação em próxima auditoria de fornecedor.]

9. Auditorias e Inspeções

9.1 Calendário Anual de Auditorias

9.1.1 Planeamento de Auditorias

O calendário anual de auditorias é planeado com base em:

• [Criticidade do fornecedor (conforme classificação)]
• [Resultados de auditorias anteriores]
• [Incidentes ou não-conformidades recentes]
• [Alterações significativas em serviços ou infraestrutura]
• [Requisitos regulatórios (NIS2, GDPR, etc.)]

9.1.2 Calendário Típico

9.2 Escopo e Procedimentos de Auditoria

9.2.1 Escopo de Auditoria

O escopo de uma auditoria de fornecedor inclui:

• Governança de Segurança: [Políticas, procedimentos, responsabilidades, comité de segurança]
• Controles Técnicos: [Autenticação, autorização, criptografia, firewalls, IDS/IPS, SIEM]
• Gestão de Vulnerabilidades: [Scanning, patch management, remediação]
• Gestão de Acessos: [Provisão, revisão, revogação de acessos; MFA; PAM]
• Proteção de Dados: [Conformidade GDPR, classificação, retenção, destruição]
• Continuidade e Recuperação: [BCP, DRP, backups, testes de recuperação]
• Resposta a Incidentes: [Plano de resposta, CSIRT, logging, notificação]
• Segurança Física: [Controles de acesso físico, monitorização, proteção de equipamentos]

9.2.2 Metodologia de Auditoria

1. Preparação: [Definir escopo, enviar checklist, agendar com fornecedor (14-30 dias de aviso)]
2. Revisão Documental: [Análise de políticas, procedimentos, certificações, relatórios anteriores]
3. Entrevistas: [Entrevistas com CISO, IT managers, operadores, compliance]
4. Inspeção Técnica: [Revisão de configurações, logs, acesso a sistemas (se on-site)]
5. Testes: [Testes de controlos (se aplicável), simulações]
6. Análise de Findings: [Identificação de não-conformidades, vulnerabilidades, gaps]
7. Relatório de Auditoria: [Relatório formal com findings, classificação de severidade, recomendações]
8. Follow-up: [Plano de remediação acordado; verificação de implementação]

9.3 Cláusulas de Direito de Auditoria

9.3.1 Direitos Contratualizados

Os contratos com fornecedores críticos e de alto risco devem incluir:

• [Direito de auditoria on-site com pré-aviso de 14-30 dias]
• [Direito a auditorias remotas/documentais sem pré-aviso em caso de incidente]
• [Acesso a relatórios de auditorias externas (SOC 2, ISO 27001, etc.)]
• [Direito a testes de penetração (com concordância prévia sobre metodologia)]
• [Acesso a logs de segurança relevantes (mediante pedido justificado)]
• [Direito a auditar subcontratantes em condições similares]

9.3.2 Custos de Auditoria

[Os custos de auditoria são da responsabilidade da nossa organização. No entanto, o fornecedor cobre custos de remediação de não-conformidades identificadas. O contrato pode estipular que até X auditorias por ano são sem custos adicionais para o fornecedor.]

9.4 Processo de Remediação de Findings

9.4.1 Classificação de Findings

9.4.2 Plano de Remediação

Para cada finding, o fornecedor deve fornecer:

• [Reconhecimento do finding]
• [Análise de causa raiz]
• [Plano de ação detalhado com milestones]
• [Responsável pela remediação]
• [Data prevista de conclusão]
• [Evidência de remediação (screenshots, logs, documentação atualizada)]

9.4.3 Verificação de Remediação

[Após o prazo de remediação, a organização verifica implementação através de: revisão de evidências, teste de controlos, auditoria de follow-up. Findings não remediados escalam conforme procedimento de não-conformidade.]

9.5 Templates de Relatórios de Auditoria

9.5.1 Estrutura do Relatório

1. Executive Summary: [Resumo de alto nível, conclusão geral, principais findings]
2. Escopo da Auditoria: [Sistemas auditados, período, metodologia]
3. Findings por Categoria: [Governança, técnicos, proteção dados, continuidade, etc.]
4. Matriz de Risco: [Severidade x impacto de cada finding]
5. Recomendações: [Ações recomendadas priorizadas]
6. Plano de Remediação: [Acordado com fornecedor, com prazos]
7. Anexos: [Evidências, screenshots, checklists utilizados]

9.5.2 Distribuição do Relatório

[Relatórios de auditoria são distribuídos a: CISO da organização, Account Manager do fornecedor, Gestão de Contratos, Compliance Officer. Classificados como confidencial.]

10. Rescisão e Offboarding

10.1 Procedimentos de Terminação de Contrato

10.1.1 Motivos de Terminação

• Término Natural: [Fim do período contratual sem renovação]
• Por Conveniência: [Mudança de estratégia, redução de custos, in-sourcing]
• Por Não-Conformidade: [Violação de SLAs, não-conformidades graves não remediadas]
• Por Incidente: [Breach de dados, violação de segurança grave]
• Por Insolvência: [Falência ou situação financeira crítica do fornecedor]

10.1.2 Período de Aviso

10.1.3 Notificação Formal

A terminação de contrato deve ser formalizada por escrito contendo:

• [Data efetiva de terminação]
• [Motivo da terminação (se aplicável)]
• [Cronograma de offboarding]
• [Responsabilidades de cada parte durante transição]
• [Condições financeiras (pagamento final, indemnizações)]

10.2 Requisitos de Devolução/Destruição de Dados

10.2.1 Inventário de Dados

Antes da terminação, criar inventário de:

• [Todos os dados da organização em posse do fornecedor]
• [Localização dos dados (servidores, backups, sistemas)]
• [Formato dos dados e possibilidade de exportação]
• [Dados em subcontratantes (se aplicável)]

10.2.2 Opções de Devolução

• Devolução: [Fornecedor exporta todos os dados em formato utilizável (JSON, CSV, SQL dump) e fornece à organização via transferência segura]
• Destruição: [Fornecedor destrói de forma segura todos os dados conforme padrão de destruição certificado (DoD 5220.22-M, NIST 800-88)]
• Mista: [Devolução de dados críticos + destruição de dados temporários/logs]

10.2.3 Certificação de Destruição

O fornecedor deve fornecer:

• [Certificado de destruição assinado por responsável do fornecedor]
• [Método de destruição utilizado]
• [Data e hora de destruição]
• [Confirmação de destruição em todos os sistemas, backups, subcontratantes]
• [Declaração de que nenhuma cópia foi retida (salvo se legalmente obrigado)]

10.2.4 Prazo de Devolução/Destruição

[Dados devem ser devolvidos ou destruídos no prazo de 30 dias após término do contrato (ou conforme acordado contratualmente). Extensões apenas com justificação e acordo por escrito.]

10.3 Checklist de Revogação de Acessos

10.3.1 Acessos a Sistemas

• [☐ Desativar todas as contas de utilizadores do fornecedor]
• [☐ Revogar acessos VPN e acesso remoto]
• [☐ Remover acessos a aplicações e plataformas]
• [☐ Desativar acessos privilegiados/administrativos]
• [☐ Revogar API keys, tokens, certificados]
• [☐ Remover acessos a cloud platforms (AWS, Azure, GCP)]

10.3.2 Acessos Físicos

• [☐ Desativar badges/cartões de acesso]
• [☐ Revogar acessos a instalações e datacenters]
• [☐ Atualizar listas de visitantes autorizados]

10.3.3 Equipamentos e Ativos

• [☐ Recolher laptops, tablets, telefones fornecidos]
• [☐ Recuperar tokens hardware, YubiKeys, smartcards]
• [☐ Recolher documentação confidencial em papel]

10.3.4 Comunicações

• [☐ Remover de listas de distribuição de email]
• [☐ Revogar acessos a Slack/Teams/comunicações]
• [☐ Atualizar contactos de emergência/escalação]

10.4 Avaliação Final de Segurança

10.4.1 Auditoria de Offboarding

Realizar auditoria final para verificar:

• [Todos os acessos foram revogados (teste de acesso negado)]
• [Dados foram devolvidos ou destruídos conforme acordado]
• [Equipamentos e ativos foram devolvidos]
• [Documentação confidencial foi devolvida ou destruída]
• [Certificações de destruição foram recebidas]

10.4.2 Relatório de Offboarding

[Criar relatório final documentando: data de terminação, motivo, processos completados, confirmação de revogação de acessos, status de devolução de dados, issues pendentes (se houver), lições aprendidas]

10.5 Processo de Transferência de Conhecimento

10.5.1 Documentação de Transição

O fornecedor deve fornecer:

• [Documentação técnica de sistemas/serviços fornecidos]
• [Runbooks e procedimentos operacionais]
• [Credenciais de sistemas (se transferência para novo fornecedor)]
• [Histórico de incidentes e resoluções]
• [Contactos técnicos e escalação]

10.5.2 Sessões de Handover

[Organizar sessões de transferência de conhecimento entre fornecedor cessante, equipa interna e novo fornecedor (se aplicável). Incluir: overview técnico, demonstrações, Q&A, shadowing period]

10.5.3 Período de Suporte de Transição

[Acordar período de suporte de transição (ex: 30-60 dias) durante o qual o fornecedor cessante fornece suporte para dúvidas/questões. Definir modalidades de contacto e SLA de resposta.]

11. Métricas e KPIs de Gestão de Fornecedores

11.1 Key Performance Indicators (KPIs)

11.1.1 KPIs de Segurança

11.1.2 KPIs de Disponibilidade

11.1.3 KPIs de Gestão de Fornecedores

11.2 Reporting Mensal e Trimestral

11.2.1 Relatório Mensal

Destinatários: [CISO, Gestão de Procurement, Responsáveis de Contratos]

Conteúdo:

• [KPIs mensais (uptime, SLA compliance, vulnerabilidades)]
• [Incidentes de segurança reportados por fornecedores]
• [Não-conformidades identificadas e status de remediação]
• [Novos fornecedores onboarded]
• [Fornecedores em processo de offboarding]
• [Top 5 riscos de fornecedores]

11.2.2 Relatório Trimestral

Destinatários: [C-Level, Board, Comité de Risco]

Conteúdo:

• [Executive summary de segurança da cadeia de fornecimento]
• [Tendências de KPIs trimestrais]
• [Auditorias realizadas e principais findings]
• [Reclassificações de criticidade de fornecedores]
• [Investimentos em segurança de fornecedores]
• [Iniciativas de melhoria contínua]

11.3 Dashboard de Métricas

11.3.1 Visualização em Tempo Real

O dashboard de gestão de fornecedores apresenta:

• Vendor Risk Heatmap: [Mapa de calor com criticidade vs risco de cada fornecedor]
• SLA Compliance Gauge: [Indicador visual de % de compliance geral]
• Open Vulnerabilities by Severity: [Gráfico de barras com vulnerabilidades críticas/altas/médias abertas]
• Incident Trend: [Linha do tempo de incidentes reportados nos últimos 12 meses]
• Audit Status: [Status de auditorias agendadas, em curso, completadas]
• Top 10 Fornecedores por Risco: [Ranking de fornecedores com maior risco atual]

11.3.2 Alertas Automáticos

O sistema gera alertas para:

• [SLA breach (incumprimento de SLA)]
• [Vulnerabilidade crítica não remediada após prazo]
• [Incidente grave reportado por fornecedor]
• [Certificação de fornecedor crítico a expirar em 60 dias]
• [Auditoria agendada não completada]
• [Não-conformidade grave identificada]

11.4 Metas de Melhoria Contínua

11.4.1 Objetivos Anuais

• [Reduzir tempo médio de onboarding em 20%]
• [Aumentar % de fornecedores críticos com certificação ISO 27001 para 100%]
• [Reduzir número de findings críticos em auditorias em 50%]
• [Implementar automação de revisão de acessos (reduzir tempo em 60%)]
• [Melhorar compliance de notificação de incidentes para 100%]

11.4.2 Iniciativas de Melhoria

• [Implementar plataforma de TPRM (Third-Party Risk Management) automatizada]
• [Desenvolver programa de formação para fornecedores em cibersegurança]
• [Estabelecer Security Champions em fornecedores críticos]
• [Criar biblioteca de cláusulas contratuais de segurança pré-aprovadas]
• [Implementar continuous monitoring de fornecedores com threat intelligence]

11.4.3 Revisão de Metas

[As metas de KPIs são revistas anualmente com base em: benchmark da indústria, evolução de ameaças, feedback de auditorias externas, mudanças regulatórias (NIS2, GDPR), incidentes ocorridos]

🛠️ Ferramentas Interativas