Segurança da Informação e Defesa Cibernética

Prévia do material em texto

FACULDADE INFNET 
ESTI – Escola Superior de Tecnologia da Informação 
Faculdade de Engenharia de Redes e Cibersegurança 
Segurança da Informação e Defesa Cibernética 
 
 
 
 
Projeto de Bloco – PB 
 
 
Disciplina: Projeto de Bloco 
Aluno: Ana Carolina Melo Pereira 
Professor: Christiana Couto 
 
 
RIO DE JANEIRO – RJ 
Junho de 2025 
Sumário 
TESTE DE PERFORMANCE – TP1 ............................................................................................... 5 
Contexto ..................................................................................................................................... 5 
Desafio ....................................................................................................................................... 5 
Entrega ....................................................................................................................................... 5 
Evidências ................................................................................................................................. 6 
TESTE DE PERFORMANCE – TP2 ............................................................................................. 21 
Contexto ................................................................................................................................... 21 
Desafio ..................................................................................................................................... 21 
Entrega ..................................................................................................................................... 21 
Diagrama de rede e inventário de ativos ............................................................................... 22 
Análise de Ameaças Cibernéticas e Vulnerabilidades – Health Labs .................................. 25 
1. Introdução .................................................................................................................... 25 
2. Visão geral da Health Labs e seus sistemas críticos ................................................ 25 
3. Metodologia de análise ............................................................................................... 30 
4. Análise detalhada das vulnerabilidades e ameaças potenciais ............................... 30 
5. Controles implementados e seus resultados ............................................................ 37 
6. Governança de dados e seus desafios ...................................................................... 41 
7. Análise da governança de dados sob a LGPD .......................................................... 43 
8. Conexões e interdependências .................................................................................. 44 
9. Recomendações e próximos passos ......................................................................... 45 
10. Conclusão ................................................................................................................ 48 
TESTE DE PERFORMANCE – TP3 ............................................................................................. 49 
Projeto ...................................................................................................................................... 49 
Desafio ..................................................................................................................................... 49 
Entrega ..................................................................................................................................... 49 
Plano de Continuidade de Negócios ...................................................................................... 50 
1. Introdução .................................................................................................................... 50 
2. Objetivo e benefícios................................................................................................... 50 
3. Metodologia ................................................................................................................. 51 
4. Contexto Organizacional ............................................................................................ 51 
5. Política de continuidade de negócios ........................................................................ 54 
6. Análise de Impacto nos Negócios (BIA) .................................................................... 57 
7. Avaliação de riscos ..................................................................................................... 59 
8. Estratégias de continuidade ....................................................................................... 62 
9. Procedimentos de Resposta e Recuperação............................................................. 64 
10. Exercícios, Testes e Melhoria Contínua ................................................................. 67 
11. Gestão e revisão do PCN ........................................................................................ 70 
Plano de Recuperação De Desastres ..................................................................................... 73 
1. Introdução e escopo do plano .................................................................................... 73 
2. Governança e responsabilidades ............................................................................... 75 
3. Análise de Impacto nos Negócios (BIA) e Avaliação de Riscos ............................... 77 
4. Estratégias de recuperação ........................................................................................ 80 
5. Procedimentos de ativação do plano ......................................................................... 83 
6. Considerações de Segurança da Informação (durante a recuperação) .................. 85 
7. Procedimentos de retorno às operações normais (Failback) .................................. 87 
8. Plano de Comunicação ............................................................................................... 90 
9. Testes e manutenção do plano ................................................................................... 92 
Relatório de Análise de Riscos Cibernéticos – Health Labs ................................................ 95 
1. Introdução .................................................................................................................... 95 
2. Metodologia de avaliação de riscos ........................................................................... 95 
3. Principais ameaças cibernéticas identificadas ......................................................... 95 
4. Engenharia social: análise detalhada ........................................................................ 96 
5. Impactos Potenciais na Continuidade Operacional .................................................. 97 
6. Estratégias de mitigação ............................................................................................ 98 
7. Conclusão .................................................................................................................... 98 
Plano de Classificação de Dados Sensíveis.......................................................................... 99 
1. Definição e escopo ...................................................................................................... 99 
2. Nível de classificação de dados ............................................................................... 101 
3. Metodologia de classificação ................................................................................... 104 
4. Requisitos de manuseio por nível de classificação ................................................ 106 
5. Atribuição de responsabilidades.............................................................................. 108 
6. Revisão e manutenção ..............................................................................................envio de e-mails falsos com aparência legítima, simulando 
comunicação de hospitais parceiros ou órgãos reguladores, induzindo 
colaboradores a clicar em links maliciosos ou baixar arquivos contaminados; 
 Spear-phishing: e-mails direcionados a membros da equipe de TI ou gestores 
com informações personalizadas, aumentando a credibilidade da mensagem 
e a chance de sucesso na instalação de malwares; 
 Pretexting: contato telefônico ou via mensagens por parte de atacantes que 
se passam por técnicos de suporte ou parceiros estratégicos, solicitando 
informações confidenciais ou o compartilhamento de acessos. 
Táticas psicológicas utilizadas: 
 Urgência falsa: pressão sobre o colaborador para tomar decisões rápidas (“se 
não responder em 30 minutos, o sistema será desativado”); 
 Autoridade falsa: utilização do nome de gestores, diretores ou órgãos públicos 
para gerar confiança e induzir obediência; 
 Curiosidade ou recompensa: atração por mensagens que prometem bônus, 
convites para eventos exclusivos ou relatórios sigilosos; 
 Medo e intimidação: ameaças sobre penalidades, demissões ou vazamento 
de dados caso o colaborador não siga instruções. 
Esses ataques, se bem-sucedidos, podem resultar na inserção de ransomwares, 
roubo de credenciais administrativas ou exfiltração de dados sensíveis, comprometendo 
severamente a continuidade dos serviços prestados. 
4.3. Escopo do Plano de Continuidade de Negócio 
Este PCN abrange as unidades operacionais e áreas funcionais da Health Labs que 
desempenham atividades críticas à sustentação dos serviços e à proteção de dados, 
incluindo: 
 Desenvolvimento e manutenção de sistemas de saúde; 
 Infraestrutura de tecnologia da informação (data centers, redes, segurança 
cibernética); 
 Suporte técnico e atendimento ao cliente; 
 Gestão de dados e análise preditiva; 
 Compliance, jurídico e segurança da informação; 
 Comunicação institucional (interna e externa); 
 Suporte à telemedicina e interoperabilidade de sistemas. 
O escopo contempla a identificação e tratamento de interrupções causadas por 
falhas tecnológicas, indisponibilidade de pessoal chave, ciberataques (incluindo engenharia 
social) e indisponibilidade de infraestrutura crítica. 
4.4. Impacto potencial das interrupções 
A interrupção das operações pode gerar consequências severas para a Health Labs 
e seus stakeholders, tais como: 
 Clientes: impossibilidade de acessar prontuários, agendar consultas ou utilizar 
recursos de telemedicina, comprometendo o atendimento clínico e colocando 
pacientes em risco; 
 Parceiros e fornecedores: dificuldade na integração de sistemas e 
cumprimento de SLAs, afetando a cadeia de valor; 
 Empresa: danos financeiros diretos (multas, resgates), prejuízo à reputação, 
perda de contratos e ações judiciais por descumprimento de obrigações 
contratuais e legais; 
 Reguladores: não conformidade com a LGPD e demais normativas setoriais, 
podendo gerar sanções e interdições operacionais. 
4.5. Expectativas das partes interessadas 
A Health Labs deve alinhar seu plano de continuidade com as expectativas e 
exigências das seguintes partes interessadas: 
 Clientes: esperam alta disponibilidade dos sistemas, proteção das 
informações sensíveis e resposta rápida a incidentes, conforme acordos de 
nível de serviço (SLAs); 
 Reguladores: demandam conformidade com a LGPD, boas práticas de 
governança em TI e evidências de gestão de riscos e continuidade 
operacional; 
 Fornecedores e parceiros: requerem garantias de continuidade das 
integrações e trocas de dados, bem como proteção mútua frente a riscos 
compartilhados; 
 Funcionários: esperam clareza sobre seus papéis e responsabilidades em 
situações de crise, bem como treinamentos e comunicações adequadas; 
 Investidores e diretores: requerem mitigação de riscos reputacionais e 
operacionais que possam comprometer o valor e a sustentabilidade da 
empresa. 
5. Política de continuidade de negócios 
5.1. Declaração de compromisso da Alta Direção 
A Health Labs é uma empresa de médio porte especializada no desenvolvimento e 
fornecimento de soluções tecnológicas para o setor da saúde. Suas atividades abrangem 
o desenvolvimento de sistemas (como prontuários eletrônicos e plataformas de gestão 
hospitalar), suporte à telemedicina, análise de dados médicos, segurança da informação e 
integração entre sistemas diversos. 
A Health Labs, por meio de sua alta direção, reconhece que a continuidade dos 
serviços prestados é fundamental para garantir a segurança dos pacientes, a confiança dos 
clientes, a conformidade regulatória e a sustentabilidade da empresa. Diante da crescente 
complexidade do ambiente digital e das ameaças cibernéticas (em especial os riscos 
associados à engenharia social), a empresa reafirma seu compromisso em adotar uma 
abordagem sistemática para a gestão da continuidade de negócios. 
 
A diretoria executiva da Health Labs se compromete a: 
 Apoiar integralmente a implementação e a manutenção do Plano de 
Continuidade de Negócio (PCN); 
 Disponibilizar os recursos necessários (humanos, financeiros, tecnológicos) 
para assegurar sua eficácia; 
 Garantir que todos os colaboradores compreendam seus papéis em situações 
de crise; 
 Promover a melhoria contínua do plano com base em lições aprendidas, 
testes e auditorias; 
 Atuar de forma transparente e responsável com todas as partes interessadas. 
Esta política está alinhada com os valores estratégicos da organização e integra o 
sistema de governança corporativa da empresa. 
5.2. Objetivos e escopo do PCN 
O Plano de Continuidade de Negócio da Health Labs tem como principais objetivos: 
 Reduzir os impactos negativos causados por eventos disruptivos que possam 
comprometer os serviços prestados e os dados sob responsabilidade da 
empresa; 
 Recuperar rapidamente as operações críticas, assegurando a retomada dos 
processos em prazos aceitáveis conforme os RTOs (Recovery Time 
Objectives) definidos; 
 Proteger a reputação e a confiança da marca, preservando a imagem da 
organização perante clientes, parceiros, reguladores e o mercado em geral. 
O escopo do PCN compreende todas as áreas e processos da organização 
considerados críticos, com destaque para: 
 Serviços de desenvolvimento e suporte a sistemas de saúde; 
 Infraestrutura de TI e segurança da informação; 
 Operações de suporte à telemedicina; 
 Processos de gestão de dados e análise preditiva; 
 Comunicação com stakeholders durante crises; 
 Atendimento a requisitos regulatórios, especialmente os relacionados à LGPD 
e às normas da saúde. 
5.3. Papeis e responsabilidades 
A implementação e execução do PCN envolvem diversos níveis hierárquicos e áreas 
da Health Labs, organizados conforme as seguintes atribuições: 
Alta Direção 
 Aprova a política de continuidade de negócios e garante seu alinhamento com 
os objetivos estratégicos da empresa; 
 Avalia periodicamente os resultados do PCN e promove ajustes necessários; 
 Toma decisões críticas em situações de crise (ativação do plano, declaração 
de emergência, escalonamento de ações). 
Comitê de continuidade de negócios 
 Coordena o desenvolvimento, implementação, testes e atualização do PCN; 
 Realiza análises de impacto nos negócios (BIA) e avaliações de risco; 
 Define prioridades de recuperação e critérios de retomada. 
Gestores das áreas críticas 
 Implementam os procedimentos de resposta e recuperação definidos para 
suas respectivas áreas; 
 Garantem a capacitação de suas equipes sobre os protocolos de 
continuidade; 
 Atuam como pontos focais durante simulações e eventos reais. 
Equipe de Segurança da Informação e TI 
 Monitora incidentes de segurança e gerencia a resposta a ataques 
cibernéticos, especialmente aqueles originados por engenharia social; 
 Garante a disponibilidade das infraestruturas essenciais (sistemas, redes, 
backups); 
 Apoia tecnicamente osprocessos de recuperação. 
Colaboradores 
 Devem conhecer os procedimentos do PCN aplicáveis à sua função; 
 Participam de treinamentos e simulados; 
 Reportam comportamentos suspeitos ou incidentes que possam comprometer 
a continuidade. 
6. Análise de Impacto nos Negócios (BIA) 
A Análise de Impacto nos Negócios (BIA) é uma etapa essencial na elaboração do 
Plano de Continuidade de Negócios, pois permite identificar e priorizar os processos críticos 
da Health Labs, avaliar os impactos de sua interrupção e estabelecer os limites de tempo 
para recuperação aceitáveis antes que os prejuízos se tornem inaceitáveis. 
6.1. Processos críticos identificados 
Com base na estrutura organizacional e na relevância para a entrega de valor aos 
clientes e parceiros, os seguintes processos foram identificados como críticos para a 
continuidade do negócio da Health Labs: 
 
Processo Justificativa de Criticidade 
Suporte à Telemedicina 
Impacta diretamente o atendimento clínico remoto e 
monitoramento de pacientes. 
Plataforma de Prontuário 
Eletrônico (PEP) 
Contém dados médicos sensíveis e históricos clínicos 
essenciais. 
Gestão de Infraestrutura de 
TI 
Sustenta a operação de todos os sistemas e serviços. 
Segurança da Informação 
Responsável por proteger ativos digitais e dados 
sensíveis. 
Suporte Técnico e Help Desk 
Primeiro ponto de contato com clientes diante de 
falhas. 
Gestão de Dados e Business 
Intelligence 
Suporte à tomada de decisão clínica e operacional 
com dados analíticos. 
Comunicação Institucional 
em Crises 
Fundamental para mitigar danos reputacionais e 
manter transparência com stakeholders. 
 
6.2. Critérios de impacto 
Os impactos da interrupção de cada processo foram analisados considerando os 
seguintes critérios: 
 Financeiro: perda de receita, penalidades contratuais, multas regulatórias; 
 Operacional: inviabilidade da entrega de serviços, paralisia de operações-
chave; 
 Legal e regulatória: não conformidade com LGPD e obrigações contratuais; 
 Reputacional: comprometimento da imagem da empresa, perda de confiança 
de clientes e parceiros; 
 Segurança do paciente: potenciais riscos à saúde dos pacientes, em especial 
no uso de plataformas clínicas. 
6.3. Principais dependências 
Cada processo crítico apresenta dependências específicas que, se comprometidas, 
ampliam o impacto das interrupções. As principais são: 
 Tecnologia: servidores, bancos de dados, redes, backups e conectividade 
com a nuvem; 
 Fornecedores: provedores de nuvem, empresas de telecomunicações, 
fornecedores de segurança cibernética; 
 Equipes-chave: desenvolvedores, analistas de segurança, engenheiros de 
infraestrutura, time de atendimento ao cliente, jurídico e compliance. 
6.4. Consequências da interrupção 
A tabela a seguir ilustra as consequências da interrupção de processos críticos: 
 
Processo Consequência de Interrupção 
Suporte à 
Telemedicina 
Suspensão de atendimentos remotos; riscos à saúde de 
pacientes em acompanhamento. 
Plataforma PEP 
Inacessibilidade a prontuários; falhas em diagnósticos e 
continuidade clínica. 
Infraestrutura de TI Inoperância total dos sistemas; paralisação generalizada. 
Segurança da 
Informação 
Risco de vazamento de dados; sanções legais e exposição 
negativa na mídia. 
Suporte Técnico 
Atrasos na resposta a incidentes; aumento na insatisfação de 
clientes. 
Gestão de Dados 
Falta de suporte à decisão e gestão de recursos; perda de 
previsibilidade. 
Comunicação 
Institucional 
Falha na gestão de crise e na transparência; amplificação de 
danos reputacionais. 
 
6.5. Tempos Máximos de Paralisação Aceitáveis (RTO) 
Com base na análise de impacto, foram definidos os RTOs (Recovery Time 
Objectives), que são o tempo máximo que cada processo pode permanecer inoperante sem 
comprometer a viabilidade da empresa: 
 
Processo RTO (Tempo Máximo de Interrupção) 
Suporte à Telemedicina 2 horas 
Plataforma de Prontuário Eletrônico 4 horas 
Infraestrutura de TI 1 hora 
Segurança da Informação 2 horas 
Suporte Técnico 4 horas 
Gestão de Dados 8 horas 
Comunicação Institucional em Crises 2 horas 
 
Esses tempos orientam a definição das estratégias de resposta e recuperação que 
serão detalhadas nas próximas seções do PCN. 
7. Avaliação de riscos 
A avaliação de riscos tem como objetivo identificar, analisar e tratar as ameaças que 
podem impactar a continuidade dos serviços prestados pela Health Labs, com foco na 
manutenção da integridade, disponibilidade e confidencialidade das informações, bem 
como na preservação dos processos críticos. 
7.1. Ameaças internas e externas 
A tabela a seguir resume as principais ameaças identificadas no contexto da 
empresa: 
Tipo Ameaça Origem Descrição 
Externa 
Engenharia social 
(phishing, 
pretexting, spear-
phishing) 
Cibercriminosos 
Manipulação psicológica de 
colaboradores para obtenção 
de credenciais ou inserção de 
malwares. 
Interna Erro humano Colaboradores 
Configurações incorretas, 
exclusão acidental de dados ou 
resposta inadequada a 
incidentes. 
Externa 
Falhas na 
infraestrutura de TI 
Fornecedores ou 
falhas técnicas 
Queda de servidores, 
indisponibilidade de rede ou 
problemas na nuvem. 
Externa 
Ataques cibernéticos 
diversos 
(ransomware, DDoS) 
Hackers 
Invasões que comprometem a 
operação e os dados da 
empresa. 
Interna 
Falha de 
comunicação em 
crises 
Equipes internas 
Respostas descoordenadas e 
falhas no relacionamento com 
stakeholders. 
Externa Desastres naturais Ambiente físico 
Alagamentos, incêndios ou 
quedas de energia que afetem 
data centers locais. 
 
7.2. Análise de Probabilidade e Impacto 
A matriz a seguir classifica os riscos segundo dois critérios: 
 Probabilidade: alta, média ou baixa; 
 Impacto: crítico, alto, médio ou baixo. 
 
Ameaça Probabilidade Impacto Nível de Risco 
Engenharia Social Alta Crítico Crítico 
Erro Humano Média Alto Alto 
Falhas de Infraestrutura Média Alto Alto 
Ataques cibernéticos (não sociais) Média Crítico Alto 
Falha de comunicação em crise Baixa Alto Médio 
Desastres naturais Baixa Crítico Médio 
 
Nota: A engenharia social é considerada o risco mais crítico por ser altamente 
provável e capaz de dar origem a outros ataques, como ransomware e exfiltração de dados. 
7.3. Plano de Mitigação dos Riscos Críticos 
7.3.1. Engenharia social 
Descrição: Técnicas como phishing, pretexting e spear-phishing são utilizadas por 
atacantes para enganar colaboradores, induzindo-os a fornecer informações sensíveis ou 
realizar ações que comprometam a segurança da empresa. 
Táticas usadas: 
 E-mails fraudulentos com aparência legítima; 
 Uso de nomes e cargos reais de gestores; 
 Simulações de parceiros estratégicos ou agências reguladoras; 
 Mensagens com senso de urgência, recompensa ou medo. 
Medidas de mitigação: 
 Treinamento recorrente de todos os colaboradores sobre identificação de 
tentativas de engenharia social (campanhas de conscientização, simulações 
de phishing, vídeos e quizzes); 
 Política de verificação de identidade, exigindo duplo fator para solicitações 
sensíveis; 
 Canal de denúncia rápido para relatos de mensagens suspeitas; 
 Monitoramento contínuo de anomalias comportamentais em contas e 
acessos; 
 Bloqueio técnico de anexos e links maliciosos com uso de filtros avançados 
de e-mail. 
7.3.2. Falhas de Infraestrutura e TI 
Medidas de mitigação: 
 Adoção de soluções em nuvem com alta disponibilidade (HA); 
 Contratos com SLA rigoroso junto a provedores; 
 Manutenção preventiva e testes periódicos em sistemas críticos; 
 Monitoramento ativo de serviços e dispositivos. 
7.3.3. Erro humano 
Medidas de mitigação: 
 Adoção de controles automatizados para operações críticas; 
 Validação em duplo fator para ações sensíveis; 
 Treinamentos regulares sobre procedimentos e segurança; 
 Criação de checklists e manuais operacionais. 
7.4. Acompanhamentoe revisão dos riscos 
Os riscos identificados nesta seção serão monitorados continuamente por meio de: 
 Reavaliações periódicas com base em eventos internos e externos; 
 Registros de incidentes e lições aprendidas; 
 Auditorias internas e revisões do plano; 
 Atualização da matriz de riscos conforme mudanças no ambiente 
organizacional ou tecnológico. 
8. Estratégias de continuidade 
As estratégias de continuidade definem como a Health Labs irá manter ou 
restabelecer suas operações críticas em situações de interrupção. As estratégias foram 
elaboradas com base na Análise de Impacto nos Negócios (BIA) e na Avaliação de Riscos, 
considerando o cenário realista de ataques cibernéticos, falhas técnicas, erros humanos e 
outras ameaças identificadas. 
8.1. Princípios das estratégias 
As ações de resposta e recuperação devem observar os seguintes princípios: 
 Priorizar a continuidade dos serviços essenciais aos clientes, em especial os 
que afetam diretamente a assistência à saúde; 
 Reduzir o tempo de interrupção, observando os RTOs definidos na BIA; 
 Proteger a integridade dos dados e evitar vazamentos de informações 
sensíveis; 
 Manter a comunicação clara e eficaz com todas as partes interessadas; 
 Assegurar a conformidade legal e regulatória, especialmente com a LGPD. 
8.2. Ações por processo crítico 
 
Processo Crítico Estratégia de Continuidade 
Suporte à 
Telemedicina 
Redundância de servidores; priorização de tráfego de rede; 
contingência por meio de provedores alternativos de vídeo e 
comunicação; priorização na equipe de suporte técnico. 
Plataforma de 
Prontuário 
Eletrônico (PEP) 
Replicação de dados em ambientes redundantes (cloud); 
backups em tempo real; plano de recuperação baseado em 
snapshots de bancos de dados. 
Infraestrutura de TI 
Monitoramento 24/7; failover automático; contratação de 
serviços com alta disponibilidade (mínimo 99,9%); políticas de 
escalonamento rápido para suporte técnico. 
Segurança da 
Informação 
Segmentação de rede; detecção e resposta a incidentes (EDR); 
simulações periódicas de incidentes de engenharia social; plano 
de resposta a incidentes cibernéticos. 
Suporte Técnico 
Atendimento remoto com acesso seguro via VPN; plano de 
revezamento de pessoal; base de conhecimento acessível 
mesmo em contingência. 
Gestão de Dados e 
BI 
Backups automáticos; redundância em múltiplas zonas de 
disponibilidade; acesso controlado por RBAC (Role-Based 
Access Control). 
Comunicação 
Institucional em 
Crises 
Protocolos de ativação de plano de comunicação; porta-vozes 
treinados; mensagens predefinidas para diversos cenários 
(dados vazados, sistemas fora do ar etc.); uso de múltiplos 
canais (e-mail, redes sociais, telefone). 
 
8.3. Estratégias gerais de continuidade 
Além das ações específicas por processo, a Health Labs adota estratégias 
transversais para fortalecer sua resiliência organizacional: 
 Ambiente de contingência (disaster recovery site) pronto para ativação 
imediata; 
 Backups diários e testes de restauração semanais; 
 Simulados de continuidade de negócios com foco em cenários realistas, como 
phishing seguido de ataque ransomware; 
 Procedimentos operacionais padrão (POPs) para recuperação e manutenção 
de sistemas críticos; 
 Treinamentos recorrentes sobre conduta em situações de crise, incluindo 
protocolos de comunicação e segurança da informação; 
 Registro e rastreamento de incidentes, com base em análise de causa raiz e 
planos de melhoria contínua. 
8.4. Planos de comunicação de crises 
A comunicação em momentos de crise é fundamental para preservar a confiança de 
clientes, parceiros, colaboradores e órgãos reguladores. Para isso, a Health Labs 
estruturou um plano de comunicação de crises com os seguintes componentes: 
Objetivos: 
 Informar de maneira clara e tempestiva sobre a situação; 
 Garantir a consistência e veracidade das mensagens; 
 Reduzir rumores, desinformação e reações negativas; 
 Demonstrar controle, responsabilidade e transparência. 
Canais e Ferramentas: 
 E-mail corporativo com mensagens previamente modeladas; 
 Painel de status online atualizado em tempo real (disponível ao público); 
 Mensagens de voz e SMS para clientes-chave em casos de urgência; 
 Redes sociais para comunicados rápidos; 
 Ponto de contato exclusivo para a imprensa e autoridades. 
Funções e Responsabilidades: 
 Comitê de Crise: avalia o contexto e aprova mensagens externas; 
 Equipe de Comunicação: redige, valida e distribui mensagens; 
 Lideranças Técnicas: apoiam com informações técnicas verificadas; 
 Executivos: atuam como porta-vozes oficiais, quando necessário. 
Fluxo de Ativação: 
 Identificação do evento disruptivo; 
 Avaliação de necessidade de comunicação externa; 
 Definição da narrativa oficial; 
 Distribuição aos canais apropriados; 
 Monitoramento de reações e feedbacks. 
9. Procedimentos de Resposta e Recuperação 
Os procedimentos de resposta e recuperação definem as ações coordenadas que 
devem ser executadas imediatamente após a ocorrência de um incidente disruptivo. O 
objetivo é conter os danos, manter ou restabelecer os processos críticos dentro dos tempos 
definidos na BIA e retornar à normalidade com o menor impacto possível. 
9.1. Ativação do Plano de Continuidade 
A ativação do Plano de Continuidade de Negócio ocorrerá quando: 
 Houver uma interrupção significativa em qualquer processo crítico identificado 
na BIA; 
 For detectada uma ameaça iminente com alto potencial de impacto (por 
exemplo, um ataque de ransomware ativo ou comprometimento de dados 
sensíveis); 
 Houver recomendação expressa da equipe de segurança da informação ou 
do Comitê de Crise. 
Passos para ativação: 
1. Detecção do incidente: qualquer colaborador pode relatar incidentes por meio 
dos canais de alerta interno; 
2. Análise preliminar: a equipe de segurança e continuidade avalia o impacto 
potencial e recomenda ou não a ativação; 
3. Decisão de ativação: cabe ao Comitê de Crise autorizar formalmente a 
ativação do PCN; 
4. Notificação: as equipes envolvidas são alertadas e os planos de resposta são 
colocados em prática; 
5. Registro: toda a sequência de eventos e decisões deve ser documentada no 
sistema de gestão de incidentes. 
9.2. Estrutura de resposta 
 Comitê de Crise (CC): responsável por tomar decisões estratégicas, 
coordenar as equipes de resposta, interagir com stakeholders externos e 
aprovar comunicações oficiais. 
 Coordenador de Continuidade (CCN): responsável por garantir a execução 
dos procedimentos técnicos, mobilizar os recursos necessários e manter o 
Comitê de Crise informado. 
 Equipes Técnicas: executam ações específicas de contenção, mitigação, 
recuperação de sistemas e restabelecimento de serviços. 
 Equipe de Comunicação: cuida da comunicação interna e externa conforme 
os protocolos definidos no Plano de Comunicação em Crises. 
9.3. Procedimentos de Resposta Imediata 
As ações de resposta visam a conter o incidente, evitar sua propagação e proteger 
os ativos críticos. 
Exemplo de resposta a incidente de engenharia social com malware (spear-
phishing): 
Etapa Ação 
1. Isolamento 
Desconectar sistemas e dispositivos comprometidos da rede 
para evitar propagação. 
2. Contenção 
Revogar credenciais suspeitas, bloquear acessos e 
interromper processos maliciosos. 
3. Análise forense 
Identificar origem, vetor de ataque e escopo do 
comprometimento. 
4. Comunicação 
Acionar Comitê de Crise e iniciar o protocolo de 
comunicação com stakeholders. 
5. Preservação de 
evidências 
Registrar logs, capturas de tela, cópias de arquivos e todas 
as ações realizadas. 
 
9.4. Procedimentos de recuperação 
Os procedimentos de recuperação são orientados por planos de contingência 
específicos para cada processo crítico e seguem as seguintes etapas gerais: 
1. Avaliação de danos: verificação do que foi comprometido e quais sistemasou 
dados precisam ser restaurados; 
2. Ativação de ambientes alternativos: uso de backups, servidores secundários 
ou soluções em nuvem para retomar serviços; 
3. Restabelecimento gradual de operações: priorização de processos com 
menor tempo de tolerância à interrupção (RTO mais curto); 
4. Validação e testes de integridade: confirmação de que sistemas restaurados 
estão íntegros, funcionais e seguros; 
5. Reintegração ao ambiente normal: desativação de contingências e retorno à 
operação padrão; 
6. Atualização de partes interessadas: comunicação formal do retorno à 
normalidade. 
9.5. Retorno à normalidade 
Após a recuperação total dos processos afetados: 
 O Comitê de Crise declara formalmente o encerramento da situação de 
contingência; 
 É realizada uma reunião de encerramento, com coleta de informações, lições 
aprendidas e avaliação de desempenho; 
 Todos os eventos, decisões e tempos de resposta são registrados; 
 São propostas ações corretivas e melhorias ao plano com base na experiência 
vivenciada. 
9.6. Checklist Operacional para Incidentes 
 
Item Verificado (✓) Observações 
Equipe técnica notificada ☐ 
Comitê de Crise acionado ☐ 
Comunicação aos stakeholders enviada ☐ 
Isolamento de sistemas afetados ☐ 
Backup restaurado/testado ☐ 
Serviços críticos reativados ☐ 
Documentação do incidente iniciada ☐ 
Revisão pós-incidente agendada ☐ 
 
10. Exercícios, Testes e Melhoria Contínua 
A Health Labs reconhece que um plano de continuidade eficaz não depende apenas 
de sua elaboração formal, mas da prática constante, da preparação das equipes e da 
melhoria contínua dos processos. Para isso, a empresa adota um programa sistemático de 
exercícios e testes, com foco no fortalecimento da resiliência organizacional e na formação 
de uma cultura de continuidade. 
10.1. Objetivos dos exercícios e testes 
 Validar a eficácia dos procedimentos de resposta e recuperação em cenários 
simulados; 
 Identificar lacunas e pontos de melhoria nos planos existentes; 
 Treinar colaboradores para atuação em situações de crise, reduzindo erros e 
tempo de resposta; 
 Testar a interoperabilidade entre equipes, sistemas e fornecedores; 
 Promover o aprendizado contínuo com base em resultados reais de 
simulações; 
 Aumentar o nível de conscientização sobre riscos, especialmente os 
relacionados à engenharia social. 
10.2. Tipos de exercícios realizados 
 
Tipo de Exercício Descrição Periodicidade 
Simulações de 
Crise (tabletop) 
Simulações teóricas com os principais 
tomadores de decisão, envolvendo cenários 
como ransomware, falhas de infraestrutura e 
vazamento de dados. 
Semestral 
Testes Técnicos de 
Recuperação 
Testes práticos de recuperação de backups, 
failover entre ambientes e restauração de 
serviços críticos. 
Trimestral 
Simulados de 
Ataques de 
Engenharia Social 
Envio de e-mails simulados de phishing e 
campanhas de pretexting para avaliar 
comportamento dos colaboradores e 
reforçar boas práticas. 
Trimestral 
Treinamentos 
Anuais de 
Continuidade 
Sessões de capacitação sobre o PCN, plano 
de resposta a incidentes e 
responsabilidades dos times. 
Anual 
Drills Operacionais 
por Equipe 
Execução prática de rotinas específicas, 
como acesso a ambientes alternativos ou 
uso de checklists de crise. 
Pontual (mín. 
1x/ano por área) 
 
10.3. Conscientização sobre engenharia social 
Dada a natureza do negócio da Health Labs, que envolve dados sensíveis de 
pacientes e sistemas de missão crítica para o setor de saúde, a empresa adota uma política 
proativa de conscientização sobre ataques de engenharia social. As ações incluem: 
 Campanhas internas educativas sobre phishing, spear-phishing, baiting e 
pretexting; 
 Simulações reais de ataques com relatórios de desempenho individual e 
feedback personalizado; 
 Cartilhas e e-mails periódicos com dicas de segurança e exemplos de golpes 
reais; 
 Treinamentos gamificados e interativos, que reforçam a tomada de decisão 
sob pressão; 
 Sessões de aprendizado com análise de incidentes internos ou do setor, 
promovendo cultura de transparência e aprendizado contínuo. 
10.4. Aprendizado contínuo e melhoria do plano 
Após cada exercício, simulação ou incidente real, é obrigatória a realização de um 
processo estruturado de lições aprendidas, com os seguintes passos: 
1. Reunião de debriefing com todos os envolvidos; 
2. Análise crítica do que funcionou e do que falhou; 
3. Registro de recomendações de melhoria no repositório de lições aprendidas; 
4. Atualização do PCN, checklists e procedimentos técnicos, quando necessário; 
5. Revisão das métricas e indicadores de desempenho, com ajustes nas metas; 
6. Planejamento de treinamentos ou reforços adicionais, conforme os 
resultados. 
10.5. Indicadores de maturidade 
Para monitorar a eficácia do programa de testes e melhoria contínua, a Health Labs 
acompanha os seguintes indicadores: 
 % de colaboradores aprovados em testes de phishing simulado; 
 Tempo médio de resposta a incidentes durante simulações; 
 % de recuperação bem-sucedida nos testes de backups; 
 % de planos atualizados após exercícios de crise; 
 Participação em treinamentos e drills por área. 
Com essas práticas, a Health Labs busca não apenas manter a eficácia técnica do 
seu PCN, mas cultivar uma mentalidade de prontidão contínua, na qual todos os 
colaboradores compreendam seu papel na manutenção da resiliência organizacional. 
11. Gestão e revisão do PCN 
A Health Labs reconhece que a eficácia de um Plano de Continuidade de Negócio 
(PCN) depende de sua manutenção sistemática, atualização constante e avaliação 
periódica. Esta seção define os processos que asseguram que o PCN permaneça 
adequado aos objetivos da organização, às mudanças tecnológicas, estruturais e 
regulatórias, e à evolução dos riscos. 
11.1. Governança e responsabilidades 
A gestão do PCN é coordenada pela área de Segurança da Informação e 
Continuidade, com apoio do Comitê de Continuidade de Negócio e da Alta Direção. As 
responsabilidades incluem: 
 Gestão e atualização contínua do conteúdo do plano; 
 Coleta e análise de indicadores de desempenho relacionados à continuidade; 
 Coordenação de auditorias internas e externas; 
 Condução de reuniões de revisão e melhoria; 
 Articulação com áreas técnicas, operacionais e jurídicas para garantir 
alinhamento. 
11.2. Indicadores de desempenho 
Para avaliar a eficácia do PCN, a Health Labs acompanha os seguintes indicadores-
chave (KPIs): 
 
Indicador Descrição Meta 
Tempo de Resposta ao 
Incidente (MTTI) 
Tempo entre a detecção de uma falha e 
o início da resposta formal 
≤ 30 minutos 
Tempo de Recuperação 
(RTO Real) 
Tempo para restabelecer processos 
críticos após uma interrupção 
≤ tempos 
definidos na BIA 
Impacto Reduzido 
Percentual de incidentes com impacto 
abaixo do limiar aceitável 
≥ 90% 
Taxa de Atualização do 
PCN 
% do conteúdo revisado dentro do ciclo 
previsto 
100%/ano 
Cobertura de 
Treinamentos 
% de colaboradores treinados 
anualmente em continuidade e 
engenharia social 
≥ 95% 
 
11.3. Auditorias internas e externas 
A conformidade e a eficácia do PCN são verificadas por meio de: 
 Auditorias internas anuais, conduzidas pela equipe de Governança e Riscos; 
 Auditorias externas bienais, conduzidas por consultorias especializadas ou 
órgãos certificadores, com base nas normas ISO 22301 e 22313; 
 Revisões documentais cruzadas, com apoio da área de Compliance e 
Jurídico; 
 Acompanhamento de recomendações corretivas, com prazos definidos e 
responsáveis atribuídos. 
11.4. Ciclo de atualização contínua 
O PCN será atualizado sempre que houver: 
 Mudança estrutural relevante (ex.: novas unidades, fusões, mudança de 
processos críticos); 
 Implantação ou descontinuação de tecnologias que afetam a continuidade; 
 Revisão na BIA ou avaliação de riscos que altere as prioridades de resposta; Ocorrência de incidentes reais que evidenciem falhas ou lacunas no plano; 
 Atualizações legais ou normativas, como alterações na LGPD ou diretrizes da 
ANS. 
Periodicidade mínima de revisão completa: anualmente, com publicação de nova 
versão e disseminação às partes interessadas. 
11.5. Registro e controle de versões 
O controle documental do PCN seguirá as práticas definidas pela Política de Gestão 
de Documentos da Health Labs, garantindo: 
 Histórico completo de alterações com data, responsável e justificativa; 
 Controle de versões com numeração sequencial; 
 Aprovação formal pela Alta Direção antes da entrada em vigor; 
 Disponibilização da versão vigente no repositório oficial e em plataformas 
seguras de fácil acesso às equipes envolvidas. 
11.6. Melhoria contínua 
A melhoria do PCN está inserida no ciclo PDCA (Planejar-Executar-Verificar-Agir). 
As entradas para esse ciclo incluem: 
 Resultados de testes, simulações e auditorias; 
 Lições aprendidas de incidentes e simulações; 
 Feedbacks de stakeholders internos e externos; 
 Mudanças no cenário de risco e ambiente regulatório. 
A melhoria contínua não é apenas operacional, mas estratégica, com o objetivo de 
garantir a resiliência organizacional de forma integrada e alinhada ao crescimento e à 
transformação digital da empresa. 
 
Plano de Recuperação De Desastres 
1. Introdução e escopo do plano 
1.1. Propósito 
Este plano de recuperação de desastres (Disaster Recovery Plan – DRP) da Health 
Labs tem como objetivo estabelecer os procedimentos, recursos e responsabilidades 
necessários para restaurar, dentro de prazos aceitáveis, as operações críticas de tecnologia 
da informação e comunicação (TIC) após a ocorrência de um evento disruptivo significativo. 
O DRP visa a minimizar os impactos operacionais, financeiros, legais e reputacionais 
decorrentes de desastres, assegurando a continuidade dos serviços essenciais fornecidos 
pela organização ao setor de saúde. 
Em alinhamento com os princípios das normas ABNT NBR ISO 22301:2020, ABNT 
NBR ISO 27001:2024 e ABNT NBR ISO 27031:2023, este plano contribui para a resiliência 
organizacional ao: 
 Garantir a rápida recuperação de sistemas, dados e infraestrutura 
tecnológica; 
 Proteger a integridade, confidencialidade e disponibilidade das informações 
sensíveis, em conformidade com a Lei Geral de Proteção de Dados (LGPD); 
 Apoiar a continuidade dos serviços de saúde mediados por tecnologia, 
contribuindo para a segurança e bem-estar dos pacientes. 
1.2. Escopo 
O presente plano abrange os ativos e processos críticos de TIC da Health Labs, que 
sustentam os principais serviços oferecidos à cadeia de valor da saúde. Estão incluídos 
neste escopo: 
 Sistemas e aplicações críticas: 
o Plataforma de Prontuário Eletrônico do Paciente (PEP); 
o Sistema de Gestão Hospitalar (SGH); 
o Ferramentas de agendamento de consultas; 
o Infraestrutura de suporte à telemedicina e monitoramento remoto de 
pacientes; 
o Soluções de integração entre dispositivos médicos e sistemas legados; 
o Plataformas de análise preditiva e geração de insights clínicos e 
operacionais. 
 Dados sensíveis e regulatórios: 
o Informações pessoais e médicas de pacientes; 
o Dados operacionais de instituições de saúde clientes; 
o Bases de dados internas e repositórios de inteligência. 
 Infraestrutura e serviços de TIC: 
o Servidores locais e em nuvem; 
o Conectividade e comunicação de dados; 
o Ambientes de backup e redundância; 
o Serviços de autenticação, controle de acesso e monitoramento de 
segurança. 
 Processos de negócio associados: 
o Suporte técnico e manutenção de sistemas críticos; 
o Processos de atendimento a clientes e parceiros; 
o Processos de gestão da segurança da informação; 
o Procedimentos de resposta a incidentes e notificações regulatórias. 
O plano considera desastres de origem física (ex.: incêndios, inundações), lógica 
(ex.: falhas sistêmicas, ataques cibernéticos) e humana (ex.: erro operacional, sabotagem), 
com foco na restauração da funcionalidade mínima necessária para operação segura e 
contínua. 
1.3. Público-alvo 
Este documento é destinado a todos os colaboradores, parceiros e prestadores de 
serviço da Health Labs que tenham papel ou responsabilidade na preparação, execução e 
manutenção da capacidade de recuperação da organização frente a desastres. O público-
alvo inclui, mas não se limita a: 
 Equipe de Tecnologia da Informação e Segurança da Informação; 
 Gestores das áreas de negócio impactadas (como produto, atendimento, 
compliance e operações); 
 Time de Continuidade de Negócios e Resposta a Incidentes; 
 Alta direção e Comitê de Riscos; 
 Fornecedores de serviços terceirizados essenciais (incluindo provedores de 
nuvem e telecomunicações). 
Todos os usuários deste plano devem estar cientes de suas responsabilidades 
específicas no processo de recuperação, bem como manter familiaridade com os 
procedimentos descritos, conforme definido nos programas de treinamento e testes 
periódicos de continuidade. 
2. Governança e responsabilidades 
2.1. Estrutura de governança do DRP 
A governança do Plano de Recuperação de Desastres (DRP) da Health Labs é 
fundamentada em uma abordagem corporativa de gestão integrada de continuidade de 
negócios e segurança da informação. A estrutura de governança visa a assegurar que as 
decisões estratégicas, os recursos e os processos de resposta e recuperação sejam 
devidamente coordenados, monitorados e continuamente aprimorados. 
A governança do DRP está inserida no modelo mais amplo de gestão de riscos da 
organização, reportando-se diretamente ao Comitê de Continuidade de Negócios e 
Segurança da Informação, que atua como instância supervisora e decisória em situações 
de crise. 
A estrutura organizacional do DRP está composta pelos seguintes grupos e funções 
principais: 
 Comitê de Continuidade e Recuperação (CCR) – instância diretiva e 
estratégica; 
 Gerência de Resposta a Incidentes e DRP – coordenação tática da execução 
do plano; 
 Equipes Técnicas de Recuperação – execução operacional dos 
procedimentos; 
 Áreas de Suporte ao Negócio – apoio às ações de comunicação, atendimento 
e legalidade. 
2.2. Papeis e responsabilidades 
2.2.1. Comitê de Continuidade e Recuperação (CCR) 
Responsável por: 
 Aprovar e revisar periodicamente o DRP e seus testes; 
 Tomar decisões críticas em situações de desastre; 
 Garantir alinhamento do DRP com os objetivos estratégicos da Health Labs 
e com os requisitos das normas ISO; 
 Alocar recursos e suportar financeiramente a implementação do plano; 
 Analisar relatórios pós-incidente e promover ações de melhoria. 
 
Composição sugerida: Diretores das áreas de Tecnologia, Segurança da Informação, 
Operações, Jurídico e Compliance. 
2.2.2. Gerente de DRP / Coordenador de Resposta a 
Incidentes 
Responsável por: 
 Ativar e coordenar a execução do DRP em caso de desastre; 
 Servir como ponto central de comando durante a resposta e recuperação; 
 Garantir a comunicação entre todas as partes envolvidas (internas e 
externas); 
 Supervisionar testes, treinamentos e revisões periódicas do plano; 
 Manter documentação atualizada sobre riscos, impactos, RTOs e RPOs. 
2.2.3. Equipes Técnicas de Recuperação 
Responsável por: 
 Restaurar sistemas, serviços e infraestrutura crítica conforme os 
procedimentos definidos; 
 Executar os planos de backup e recuperação de dados; 
 Implementar medidas provisórias para retomada dos serviços essenciais; 
 Monitorar o funcionamento dos ativos recuperados; 
 Registrar evidências e lições aprendidas ao longo do processo. 
Áreas envolvidas: Infraestrutura, Desenvolvimento de Software, Segurança da 
Informação, Suporte Técnico. 
2.2.4. Representantes das Áreas de Negócio 
Responsável por: 
 Informar prioridades de recuperação baseadas nos processos de negócio 
afetados; 
 Auxiliar na identificaçãode requisitos mínimos operacionais; 
 Apoiar a comunicação com clientes, parceiros e autoridades reguladoras; 
 Participar de simulações e avaliações de impacto. 
2.2.5. Equipe de Comunicação e Relacionamento 
Responsável por: 
 Coordenar a comunicação institucional durante e após o desastre; 
 Redigir comunicados internos e externos com base em diretrizes da alta 
gestão; 
 Gerenciar o relacionamento com imprensa, clientes e órgãos reguladores, 
assegurando a conformidade com a LGPD e demais exigências legais. 
2.3. Papeis e responsabilidades 
Todos os papéis definidos neste plano devem ser formalmente designados e 
documentados, com substitutos previamente identificados. Os responsáveis devem ser 
periodicamente treinados e envolvidos em testes de recuperação, contribuindo para o 
aprimoramento contínuo do DRP. 
O monitoramento e revisão do desempenho do DRP, bem como das 
responsabilidades atribuídas, são conduzidos conforme o ciclo PDCA (Planejar, Executar, 
Verificar, Agir), em conformidade com os princípios da ABNT NBR ISO 22301:2020 e ABNT 
NBR ISO 27001:2024. 
3. Análise de Impacto nos Negócios (BIA) e Avaliação de 
Riscos 
3.1. Objetivo da BIA e Avaliação de Riscos 
A Análise de Impacto nos Negócios (Business Impact Analysis – BIA) e a Avaliação 
de Riscos são componentes fundamentais do plano de recuperação de desastres da Health 
Labs. Essas análises permitem: 
 Identificar os processos de negócio mais críticos e suas dependências 
tecnológicas; 
 Avaliar os impactos operacionais, legais e reputacionais da interrupção 
desses processos; 
 Estabelecer os parâmetros de recuperação (RTO e RPO); 
 Identificar ameaças relevantes e vulnerabilidades existentes; 
 Apoiar a definição de estratégias de recuperação adequadas e priorizadas. 
3.2. Identificação de processos críticos 
Os seguintes processos e serviços podem ser classificados como críticos para a 
continuidade das operações da Health Labs: 
Processo Crítico Descrição Sistemas Suporte 
Gestão de Prontuário 
Eletrônico 
Acesso, edição e armazenamento 
de dados clínicos de pacientes 
Plataforma PEP 
Agendamento de 
Consultas e Exames 
Organização de agendas e 
encaminhamentos médicos 
Sistema de 
Agendamento 
Integrado 
Telemedicina e 
Monitoramento 
Remoto 
Consultas virtuais e 
acompanhamento de pacientes à 
distância 
Plataforma de 
Telemedicina 
Análise de Dados 
Clínicos e 
Operacionais 
Geração de relatórios e insights 
para tomada de decisão médica e 
gerencial 
Sistema de BI e 
Analytics 
Segurança e 
Integridade de Dados 
Controle de acessos, criptografia, 
detecção de intrusos 
SIEM, Firewall, DLP, 
Servidores de Logs 
Integração de Sistemas 
Hospitalares 
Comunicação entre sistemas de 
terceiros e dispositivos médicos 
Middleware de 
Integração e APIs 
HL7/FHIR 
 
3.3. Definição de RTO (Recovery Time Objective) 
O RTO (Objetivo de Tempo de Recuperação) representa o tempo máximo tolerável 
para restaurar uma função crítica após uma interrupção. Os RTOs definidos para os 
principais processos são os seguintes: 
Processo Crítico RTO Máximo Tolerável 
Gestão de Prontuário Eletrônico 4 horas 
Agendamento de Consultas e Exames 8 horas 
Telemedicina e Monitoramento Remoto 2 horas 
Análise de Dados Clínicos 24 horas 
Segurança de Dados e Autenticação 1 hora 
Integração de Sistemas Hospitalares 4 horas 
 
3.4. Definição de RPO (Recovery Point Objective) 
O RPO (Objetivo de Ponto de Recuperação) define a quantidade máxima aceitável 
de perda de dados, mensurada em tempo, considerando a última cópia válida disponível 
para recuperação. Os RPOs estabelecidos são: 
Processo / Sistema RPO Máximo Aceitável 
Plataforma de Prontuário Eletrônico 15 minutos 
Plataforma de Agendamento 1 hora 
Plataforma de Telemedicina 5 minutos 
Sistema de BI e Analytics 4 horas 
Serviços de Autenticação e Logs 15 minutos 
Middleware de Integração 30 minutos 
 
3.5. Identificação de ameaças e vulnerabilidades 
A avaliação de riscos considerou cenários disruptivos plausíveis, suas 
probabilidades relativas e os impactos esperados. Abaixo estão listadas as ameaças mais 
relevantes para a organização, bem como as vulnerabilidades associadas: 
Tipo de 
Ameaça 
Exemplos 
Vulnerabilidades 
Identificadas 
Impacto 
Potencial 
Natural 
Inundações, raios, 
incêndios acidentais 
Localização do datacenter em 
área urbana densa; falta de 
sensores ambientais 
avançados 
Alto 
Tecnológica 
Falha de hardware, 
corrupção de banco 
de dados, ransomware 
Sistemas legados sem 
redundância; backups não 
automatizados em alguns 
serviços 
Crítico 
Humana 
(acidental) 
Erros de configuração, 
exclusão acidental de 
dados 
Falta de revisão em mudanças 
críticas; treinamento 
insuficiente 
Médio 
Humana 
(intencional) 
Ameaças internas, 
sabotagem, ataques 
cibernéticos 
Acessos privilegiados mal 
gerenciados; ausência de MFA 
em alguns sistemas 
Crítico 
Dependência 
externa 
Queda de serviços de 
nuvem, falha de 
internet 
Provedores únicos; ausência 
de contrato com SLA robusto 
Alto 
 
3.6. Conclusões da análise 
A partir dos resultados obtidos nesta seção, a Health Labs priorizará a alocação de 
recursos para proteger e recuperar os processos críticos identificados, garantindo que os 
RTOs e RPOs definidos sejam atingíveis por meio de estratégias de recuperação 
específicas. Além disso, serão implementadas medidas de mitigação de risco para reduzir 
a exposição às ameaças identificadas, em conformidade com o plano de tratamento de 
riscos definido pela organização. 
4. Estratégias de recuperação 
4.1. Objetivo 
Esta seção descreve as estratégias de recuperação adotadas pela Health Labs para 
garantir a restauração eficaz de seus ativos de tecnologia da informação e comunicação 
(TIC) após um evento disruptivo. As estratégias aqui documentadas têm como base os 
requisitos identificados na Análise de Impacto nos Negócios (BIA) e na Avaliação de Riscos, 
visando a atender aos RTOs e RPOs definidos. 
4.2. Estratégias para infraestrutura 
A infraestrutura de TIC da Health Labs está desenhada para garantir redundância, 
escalabilidade e resiliência. As principais estratégias adotadas são: 
 Cloud computing com redundância geográfica: utilização de provedores de 
nuvem com data centers em múltiplas regiões, permitindo rápida migração 
entre zonas em caso de falha localizada. 
 Ambientes de recuperação: 
o Warm site: ambiente pré-configurado em nuvem, com recursos 
computacionais prontos para serem ativados em até 4 horas; 
o Cold site (descontinuado): estratégia substituída por ambientes de 
nuvem com provisionamento sob demanda; 
o Hot site (não utilizado): considerado não viável para o porte da 
organização e custo-benefício atual. 
 Replicação contínua de dados: serviços críticos contam com replicação em 
tempo real para instâncias secundárias hospedadas em outra região da 
nuvem. 
 Automação de provisionamento (IaC): utilização de infraestrutura como 
código para reconstrução rápida de servidores e serviços com consistência. 
4.3. Estratégias para dados 
A estratégia de proteção de dados da Health Labs é centrada na resiliência, 
disponibilidade e conformidade com a LGPD, por meio de práticas robustas de backup e 
restauração: 
 Métodos de Backup: 
o Backups incrementais diários e completos semanais; 
o Backup de banco de dados via dump encriptado e snapshot 
automatizado na nuvem. 
 Frequência: 
o Dados críticos (prontuários, telemedicina, autenticação): backup a 
cada 15 minutos via replicação; 
o Dados operacionais e analíticos: backup diário. 
 Retenção: 
o Dados críticos: 90 dias com versionamento; 
o Dados analíticos: 180 dias; 
o Logs de segurança e auditoria: 1 ano. 
 Localização: armazenamento de backups em regiões distintas da nuvem e 
cópia adicional criptografada em provedor secundário externo. 
 Testes de restauração: realizados trimestralmente,com simulações de perda 
parcial e total de dados. 
4.4. Estratégias para aplicações 
A Health Labs adota uma abordagem modular e resiliente para recuperação de 
software e aplicações críticas, com foco em alta disponibilidade e automação: 
 Containerização de aplicações: aplicações críticas são executadas em 
containers Docker, permitindo rápida instanciação em qualquer ambiente 
compatível. 
 Orquestração com Kubernetes: clusters replicados para balanceamento e 
failover automático em caso de falha de nó ou região. 
 Repositório de código seguro e automatização CI/CD: código-fonte 
versionado com pipelines automatizados que permitem restauração e 
reimplantação completa em menos de 1 hora. 
 Ambientes de contingência pré-configurados: ambientes secundários 
preparados para ativação em caso de falha generalizada do ambiente 
principal. 
4.5. Estratégias para redes 
A recuperação de conectividade e comunicação é essencial para o funcionamento 
das aplicações da Health Labs. As principais estratégias adotadas incluem: 
 Arquitetura multi-WAN: conectividade redundante com dois provedores de 
internet e failover automático. 
 VPN redundante e IPsec com alta disponibilidade: túneis seguros entre 
unidades e a nuvem, com monitoramento ativo e comutação automática. 
 Redes virtuais segmentadas na nuvem (VPCs): isolamento de ambientes 
críticos com roteamento definido por políticas, para facilitar a recuperação 
seletiva. 
 DNS com failover dinâmico: utilização de serviços de DNS que redirecionam 
automaticamente para ambientes secundários em caso de indisponibilidade. 
 Monitoramento de conectividade e tráfego: ferramentas de observabilidade 
em tempo real (como NOC-as-a-Service) para detectar e reagir a incidentes 
de rede com rapidez. 
4.6. Conclusão 
As estratégias de recuperação aqui descritas garantem que a Health Labs esteja 
preparada para restaurar rapidamente sua operação após eventos disruptivos, protegendo 
tanto seus ativos digitais quanto a continuidade dos serviços prestados ao setor de saúde. 
Todas as estratégias são periodicamente testadas, documentadas e aprimoradas de acordo 
com as lições aprendidas, riscos emergentes e evolução tecnológica. 
5. Procedimentos de ativação do plano 
5.1. Objetivo 
Esta seção descreve os procedimentos formais para ativação do Plano de 
Recuperação de Desastres (DRP) da Health Labs. Esses procedimentos garantem uma 
resposta coordenada, ágil e eficaz diante de eventos disruptivos que comprometam 
operações críticas da organização. 
5.2. Critérios de declaração de desastre 
Um desastre será formalmente declarado quando ocorrerem eventos que: 
 Causarem interrupção total ou parcial de sistemas ou serviços classificados 
como críticos no BIA; 
 Tenham impacto significativo na continuidade dos serviços de saúde 
prestados aos clientes da Health Labs; 
 Envolvam violação de segurança da informação com perda de 
disponibilidade, integridade ou confidencialidade de dados sensíveis; 
 Impliquem riscos à conformidade legal e regulatória, como a LGPD; 
 Ultrapassem a capacidade operacional de resolução por equipes técnicas de 
primeira linha. 
5.2.1. Autoridade para Declaração de Desastre 
A declaração oficial de desastre é de responsabilidade das seguintes funções, em 
ordem de prioridade: 
 Diretor de Tecnologia da Informação (CTO) – autoridade primária; 
 Gerente de Continuidade de Negócios e DRP – autoridade secundária; 
 Gerente de Segurança da Informação (CISO) – em casos de incidentes 
cibernéticos; 
 Diretor Executivo (CEO) – em situações que envolvam a organização como 
um todo. 
A declaração deve ser registrada formalmente em ata ou sistema de incidentes, com 
data, hora e justificativa documentadas. 
5.3. Procedimentos de notificação 
Após a declaração de desastre, devem ser iniciados os procedimentos de notificação 
e comunicação com as partes interessadas, conforme descrito abaixo: 
 Equipes internas: 
o Ativação do Comitê de Recuperação: notificação imediata por e-mail e 
canal seguro (Signal/Slack corporativo); 
o Equipes técnicas (TI, DevOps, Segurança): alertadas via sistema de 
incidentes com chamadas automáticas de escalonamento. 
 Direção e Liderança: 
o Notificação formal à Diretoria Executiva e Comitê de Riscos; 
o Geração de boletins internos a cada 2 horas com status da situação. 
 Partes externas: 
o Clientes e hospitais parceiros: comunicação via e-mail institucional e 
canais de atendimento com informações iniciais e orientações; 
o Fornecedores e prestadores de serviços: acionados conforme 
necessidade técnica; 
o Autoridades regulatórias (se aplicável): notificação conforme previsto 
na LGPD, em até 48h após constatação de vazamento ou incidente de 
segurança relevante. 
5.4. Passos iniciais de resposta 
Após a ativação do plano, as seguintes ações devem ser executadas imediatamente, 
em paralelo e de forma coordenada: 
1. Ativação do Comitê de Recuperação 
 Reunião virtual em até 30 minutos após a declaração; 
 Definição de prioridades com base na matriz de impacto dos serviços 
afetados; 
 Registro de todas as decisões e ações no sistema de gestão de crises. 
2. Avaliação inicial do incidente 
 Coleta de evidências do evento ocorrido (logs, mensagens de erro, 
relatórios de anomalias); 
 Verificação dos serviços afetados e avaliação dos danos preliminares; 
 Isolamento de sistemas comprometidos, se necessário. 
3. Comunicação inicial 
 Envio de comunicado interno e externo (modelo pré-aprovado); 
 Designação de um porta-voz para interação com a imprensa ou 
clientes, se aplicável; 
 Atualização do status em dashboards internos. 
4. Preparação para recuperação 
 Ativação dos ambientes alternativos (warm site ou ambiente na 
nuvem); 
 Disponibilização dos backups e preparação para restauração; 
 Confirmação de disponibilidade das equipes técnicas em regime de 
contingência. 
5.5. Considerações finais 
Todos os procedimentos de ativação devem ser executados com base nos valores 
organizacionais da Health Labs, priorizando a segurança dos dados dos pacientes, a 
continuidade dos serviços de saúde e a transparência com os clientes e reguladores. O 
sucesso da ativação depende do treinamento prévio, da prontidão das equipes e da clareza 
nas comunicações. 
6. Considerações de Segurança da Informação (durante a 
recuperação) 
6.1. Objetivo 
Garantir que todas as ações realizadas durante o processo de recuperação de 
desastres estejam em conformidade com os princípios de confidencialidade, integridade e 
disponibilidade das informações, protegendo os dados sensíveis e os sistemas críticos da 
Health Labs contra acessos indevidos, falhas de integridade e novas vulnerabilidades. 
6.2. Controle de acesso 
Durante a fase de recuperação, é essencial garantir que somente pessoal autorizado 
possa acessar os sistemas, aplicações e dados em processo de restauração. Para isso, 
devem ser aplicadas as seguintes medidas: 
 Revalidação de perfis de acesso: antes da liberação de qualquer sistema 
restaurado, a equipe de Segurança da Informação deve revisar e revalidar os 
perfis de usuários; 
 Autenticação multifator (MFA): acesso a ambientes restaurados deve requerer 
autenticação multifator, especialmente para funções administrativas; 
 Listas de controle de acesso (ACLs): atualizadas com base nos requisitos 
mínimos de privilégio; 
 Acesso temporário com auditoria: a concessão de acessos administrativos 
emergenciais deve ser documentada, temporária e monitorada. 
6.3. Integridade e confidencialidade dos dados 
Para proteger os dados sensíveis (especialmente os dados de saúde de pacientes), 
as seguintes práticas devem ser aplicadas: 
 Durante a restauração: 
o Validação de integridade de backups: verificação de hash (ex: SHA-
256) antes da restauração; 
o Canal seguro de transferência: utilização de conexões criptografadas 
(ex: TLS 1.2+ ou VPN corporativa) para recuperaçãode dados em 
trânsito; 
o Isolamento do ambiente restaurado: inicialmente, sistemas 
restaurados devem operar em ambientes isolados (“zona de 
quarentena”) até a validação completa. 
 Após a restauração: 
o Reaplicação de criptografia em repouso: certificar que todos os dados 
armazenados estejam criptografados conforme padrão organizacional 
(ex: AES-256); 
o Sanitização de dados temporários: eliminação segura de dados 
residuais ou intermediários utilizados no processo de restauração. 
6.4. Gerenciamento de vulnerabilidades 
Antes de reintegrar sistemas ao ambiente de produção, é fundamental identificar e 
mitigar possíveis vulnerabilidades técnicas que possam ter sido introduzidas ou exploradas 
durante o desastre. 
 Varredura de vulnerabilidades (Vulnerability Scan): utilizar ferramentas 
automatizadas (ex: Nessus, OpenVAS) para detectar falhas conhecidas; 
 Verificação de conformidade com baseline de segurança: conferir se as 
configurações restauradas seguem os padrões de hardening definidos pela 
organização; 
 Aplicação de patches críticos: instalar imediatamente correções de segurança 
pendentes, especialmente para sistemas expostos à internet; 
 Registro de anomalias: toda vulnerabilidade identificada deve ser registrada e 
acompanhada no sistema de gestão de riscos. 
6.5. Monitoramento 
O monitoramento contínuo dos sistemas restaurados é essencial para detectar 
comportamentos anômalos, possíveis tentativas de intrusão ou falhas residuais. 
 Ativação de ferramentas de SIEM: os sistemas restaurados devem ser 
reintegrados à plataforma de monitoramento de eventos de segurança (ex: 
Splunk, ELK, Wazuh); 
 Alertas em tempo real: configurar alertas automáticos para comportamentos 
suspeitos, como acessos fora do padrão, elevação de privilégios ou 
transferência de grandes volumes de dados; 
 Monitoramento de logs de acesso e sistema: garantir que todos os logs 
estejam sendo coletados, armazenados e protegidos contra alteração ou 
exclusão; 
 Relatórios periódicos: geração de relatórios de segurança diários durante os 
primeiros 7 dias após a recuperação. 
6.6. Considerações finais 
A segurança da informação deve ser tratada como componente inseparável da 
recuperação de desastres. A violação de dados ou falhas de controle após a restauração 
podem gerar danos tão significativos quanto o próprio desastre. A atuação conjunta entre 
as equipes de infraestrutura, segurança da informação e continuidade de negócios é 
essencial para garantir um retorno seguro e sustentável às operações da Health Labs. 
7. Procedimentos de retorno às operações normais (Failback) 
7.1. Objetivo 
Estabelecer as diretrizes e os procedimentos para realizar a transição segura, 
ordenada e controlada dos sistemas e operações da Health Labs do ambiente de 
recuperação (contingência) para o ambiente de produção (primário), garantindo 
continuidade, integridade e segurança das informações. 
7.2. Validação do ambiente de recuperação 
Antes de iniciar o processo de failback, é necessário garantir que o ambiente de 
contingência esteja operando de forma estável e confiável, validando que todos os serviços 
críticos estejam funcionando conforme o esperado. 
7.2.1. Critérios de validação 
 Monitoramento de performance: estabilidade e desempenho dos sistemas em 
níveis aceitáveis por, no mínimo, 48 horas consecutivas; 
 Validação funcional: todos os processos críticos operando conforme 
especificações (ex: EHR, banco de dados, autenticação); 
 Feedback de usuários chave: confirmação de que usuários das áreas clínicas, 
operacionais e administrativas estão conseguindo executar tarefas 
normalmente; 
 Análise de logs e alertas: ausência de erros recorrentes ou falhas de 
segurança. 
7.2.2. Documentos de validação 
 Checklist de serviços verificados; 
 Relatórios de testes funcionais; 
 Registro de incidentes ocorridos durante o período de contingência e suas 
resoluções. 
7.3. Procedimentos de transição de volta (Failback) 
O processo de failback deve ser cuidadosamente planejado para minimizar riscos e 
interrupções adicionais. Caso o ambiente principal tenha sido reparado ou reconstruído, a 
migração deverá ocorrer seguindo os passos abaixo: 
7.3.1. Pré-requisitos 
 Ambiente primário reconstruído e validado (infraestrutura, rede, banco de 
dados, aplicações); 
 Patches e configurações de segurança aplicados de acordo com o baseline 
atualizado; 
 Disponibilidade de janelas de manutenção previamente acordadas com as 
áreas de negócio. 
7.3.2. Etapas do failback 
1. Congelamento de transações no ambiente de contingência (data cutoff); 
2. Sincronização final dos dados do ambiente de contingência para o ambiente 
primário; 
3. Testes técnicos no ambiente primário: 
o Verificação de integridade dos dados migrados; 
o Testes de conectividade e serviços; 
o Execução de testes automatizados de aplicações; 
4. Redirecionamento de DNS e acessos para o ambiente primário; 
5. Desligamento progressivo do ambiente de contingência após confirmação da 
operação normal no primário; 
6. Atualização de documentação técnica refletindo o novo estado dos sistemas. 
7.4. Verificação pós-retorno 
Após a conclusão do failback, devem ser conduzidas verificações pós-retorno para 
confirmar a estabilidade e funcionalidade dos sistemas, bem como para identificar e mitigar 
qualquer anomalia residual. 
7.4.1. Testes de validação 
 Testes de regressão dos principais fluxos funcionais (ex: login, inserção e 
consulta de registros, relatórios, integrações); 
 Testes de desempenho (tempo de resposta e uso de recursos); 
 Validação de segurança (controle de acesso, monitoramento ativo, 
integridade dos logs). 
7.4.2. Monitoramento inicial 
 Período intensivo de monitoramento de 72 horas; 
 Acompanhamento por equipes de TI, Segurança da Informação e áreas 
usuárias; 
 Geração de relatórios de estabilidade e disponibilidade. 
7.4.3. Reunião de post mortem 
 Realização de reunião com as partes interessadas para: 
o Avaliar a eficácia do failback; 
o Registrar lições aprendidas; 
o Atualizar o DRP com base nas experiências da recuperação e retorno. 
7.5. Considerações Finais 
A fase de failback é crítica para encerrar com sucesso o ciclo de recuperação e 
retornar à operação normal da Health Labs com segurança. O retorno deve ser tratado 
com o mesmo nível de planejamento e rigor que a ativação do plano, garantindo que os 
riscos não sejam reintroduzidos no ambiente primário. 
8. Plano de Comunicação 
8.1. Objetivo 
Estabelecer um plano estruturado de comunicação durante situações de desastre 
para garantir que todas as partes interessadas sejam devidamente informadas, 
coordenadas e orientadas, contribuindo para a tomada de decisões ágeis, mitigação de 
impactos e manutenção da confiança institucional. 
8.2. Comunicação interna 
A comunicação interna visa a garantir que funcionários, líderes e a equipe de 
resposta a crises estejam alinhados quanto à situação, ações em andamento e 
procedimentos esperados. 
8.2.1. Destinatários 
 Equipe de resposta a incidentes e desastres (ERID); 
 Colaboradores em geral; 
 Gestores e lideranças operacionais; 
 Diretoria Executiva e Comitê de Continuidade 
8.2.2. Conteúdos comuns 
 Estado atual do incidente/disponibilidade dos serviços; 
 Ações tomadas e próximas etapas; 
 Orientações operacionais (ex.: home office, desligamento de sistemas); 
 Canais de suporte disponíveis. 
8.2.3. Responsabilidades 
 
Papel Responsabilidade 
Gerente de Continuidade Coordenar o fluxo de informações internas 
Comunicação Corporativa Redigir e padronizar mensagens internas 
RH Apoiar com orientações aos colaboradores 
Equipe Técnica Fornecer atualizações técnicas para mensagens oficiais 
 
8.3. Comunicação externa 
A comunicação externa deve ser transparente e controlada, minimizando ruídos e 
mantendo a credibilidade institucional junto a clientes, fornecedores,parceiros e, se 
necessário, autoridades e mídia. 
8.3.1. Partes externas 
 Clientes e hospitais parceiros; 
 Fornecedores de tecnologia e serviços essenciais; 
 Órgãos reguladores (ex: ANS, ANVISA, Ministério da Saúde); 
 Imprensa, caso aplicável. 
8.3.2. Tipos de mensagens 
 Notificações sobre indisponibilidade ou degradação de serviços; 
 Estimativas de normalização (quando possível); 
 Garantias quanto à integridade e segurança dos dados; 
 Atualizações periódicas conforme evolução do cenário. 
8.3.3. Responsabilidades 
 
Papel Responsabilidade 
Diretor de Comunicação Porta-voz oficial em situações externas 
Jurídico/Compliance 
Garantir que a comunicação esteja em conformidade 
legal/regulatória 
Suporte ao Cliente Interagir com usuários finais e registrar dúvidas 
Segurança da 
Informação 
Validar dados sensíveis antes da divulgação 
 
8.4. Canais de comunicação de emergência 
Em caso de falha nos canais convencionais de comunicação (ex.: e-mail, VoIP, 
servidores de mensagens), a Health Labs manterá alternativas previamente estabelecidas 
para garantir a continuidade das comunicações críticas. 
8.4.1. Canais alternativos 
 
Canal Finalidade 
Grupos de WhatsApp Corporativo (pré-
criados) 
Comunicação rápida entre líderes e 
ERID 
Aplicativo de Mensagens Offline (ex: 
Bridgefy, FireChat) 
Comunicação em ambientes sem 
rede 
Rede privada de rádio (HT) 
Comunicação interna em locais 
estratégicos 
Telefones celulares pessoais autorizados Contato direto entre gestores 
Canal de emergência via portal externo 
Atualizações para clientes e 
fornecedores 
 
8.4.2. Procedimentos 
 Cada equipe crítica deve possuir ao menos dois meios alternativos de contato. 
 Testes periódicos devem ser realizados para validar esses canais. 
 As informações compartilhadas por canais alternativos devem ser registradas 
posteriormente no sistema oficial da empresa (quando disponível), para fins 
de auditoria e rastreabilidade. 
8.5. Considerações finais 
O sucesso de um plano de recuperação depende diretamente da eficácia da 
comunicação durante todas as fases do desastre. A Health Labs se compromete a manter 
suas equipes e partes interessadas bem informadas, com clareza, agilidade e 
responsabilidade, promovendo a continuidade dos serviços com o menor impacto possível 
à sociedade e aos seus clientes. 
9. Testes e manutenção do plano 
9.1. Objetivo 
Assegurar que o Plano de Recuperação de Desastres (DRP) da Health Labs seja 
regularmente testado, mantido e atualizado, de forma a garantir sua eficácia prática diante 
de situações reais, bem como o preparo adequado das equipes responsáveis por sua 
execução. 
9.2. Frequência dos testes 
Os testes do DRP devem ser realizados com a seguinte frequência mínima: 
Tipo de Atividade Frequência Recomendada 
Teste de mesa (tabletop) 
Trimestral ou sempre que houver alterações 
significativas 
Simulação parcial ou 
controlada 
Semestral 
Teste de restauração de 
dados 
Trimestral 
Teste de recuperação total 
Anual (se viável tecnicamente e com aprovação da 
diretoria) 
 
Testes adicionais devem ser realizados sempre que houver: 
 Alterações na infraestrutura de TI (ex: mudança de data center, sistemas 
críticos, fornecedores de nuvem); 
 Mudanças relevantes nos processos de negócio; 
 Após incidentes reais que demandem ativação parcial ou total do DRP; 
 Atualizações regulatórias com impacto na continuidade dos serviços. 
9.3. Tipos de testes 
9.3.1. Testes de mesa (tabletop) 
 Objetivo: validar a compreensão do plano pelas equipes envolvidas, sem 
afetar o ambiente produtivo. 
 Descrição: simulação teórica de um cenário de desastre, com discussão 
orientada dos procedimentos de resposta. 
9.3.2. Simulações 
 Objetivo: executar partes do plano em ambiente controlado para avaliar 
prazos, decisões e recursos. 
 Descrição: envolve ações práticas como failover de servidores, testes de 
backups e uso de canais de comunicação alternativos. 
9.3.3. Testes de restauração de dados 
 Objetivo: validar a integridade, disponibilidade e tempo de recuperação dos 
backups. 
 Descrição: realização periódica de restauração total ou parcial de bases de 
dados críticas em ambiente de homologação. 
9.4. Atualização do plano 
Para manter a eficácia do DRP, é necessário que ele seja revisado periodicamente 
e atualizado sempre que houver mudanças relevantes. 
9.4.1. Procedimentos de atualização 
 Revisão formal do plano: anual ou após cada teste importante; 
 Atualização após: 
o Mudanças de infraestrutura (hardware, software, arquitetura); 
o Reestruturações organizacionais; 
o Alterações em fornecedores ou SLAs; 
o Incidentes reais ou falhas detectadas em testes. 
9.5. Treinamento das equipes 
A capacitação contínua das equipes envolvidas no DRP é essencial para garantir 
uma resposta coordenada e eficaz em situações reais de crise. 
9.5.1. Público-Alvo 
 Equipe de Resposta a Incidentes e Desastres (ERID); 
 Equipes de infraestrutura e segurança da informação; 
 Representantes das áreas de negócio críticas; 
 Gestores operacionais e líderes de comunicação. 
9.5.2. Formatos de treinamento 
 Workshops práticos baseados em cenários reais; 
 Treinamentos presenciais e/ou virtuais sobre responsabilidades e fluxos do 
DRP; 
 Atualizações regulares após mudanças no plano ou nos sistemas; 
 Avaliações de conhecimento com base em simulações e questionários. 
9.5.3. Frequência 
 Treinamento básico obrigatório: anualmente para todos os envolvidos; 
 Reciclagens: após cada atualização significativa do DRP ou troca de equipe; 
 Treinamento de novos colaboradores: incluído no processo de integração, 
quando aplicável. 
9.6. Considerações finais 
A eficácia do DRP da Health Labs depende diretamente da prática, revisão contínua 
e capacitação das equipes envolvidas. Os testes regulares e o aprendizado decorrente 
desses exercícios são fundamentais para que, diante de uma crise real, a organização 
possa responder de forma segura, coordenada e com o mínimo impacto aos serviços de 
saúde que apoia. 
 
Relatório de Análise de Riscos Cibernéticos – Health Labs 
1. Introdução 
Este relatório apresenta a análise dos principais riscos cibernéticos que podem 
impactar a continuidade operacional da Health Labs, uma empresa de médio porte 
especializada em soluções tecnológicas para o setor de saúde. O documento faz parte 
integrante do Plano de Continuidade de Negócios (PCN) e visa a identificar, avaliar e 
classificar ameaças, com especial atenção à engenharia social, reconhecida como uma das 
principais vulnerabilidades atuais. 
2. Metodologia de avaliação de riscos 
A metodologia adotada baseia-se em princípios da ABNT NBR ISO 27005:2023 e 
ABNT NBR ISO 22301:2020, com ênfase na: 
 Identificação de ameaças internas e externas; 
 Avaliação de probabilidade de ocorrência e impacto potencial; 
 Classificação de riscos conforme matriz de criticidade (baixa, média, alta, 
crítica); 
 Proposição de estratégias de mitigação. 
3. Principais ameaças cibernéticas identificadas 
 
Ameaça Descrição Probabilidade Impacto Risco 
Engenharia Social 
Manipulação psicológica 
de colaboradores para 
obtenção de acesso ou 
inserção de malware 
Alta Crítico Crítico 
Ransomware 
Criptografia de dados 
críticos, exigindo resgate 
para liberação 
Média Crítico Alto 
Phishing (genérico) 
E-mails falsos para coleta 
de credenciais 
Alta Alto Alto 
Exploração de 
vulnerabilidades 
técnicas 
Ataques por falhas em 
sistemas, APIs ou redes 
Média Alto Médio 
Erro humano 
Exclusão acidental, falha 
de configuração, 
negligência em backups 
Alta Médio Médio 
Falha de 
infraestrutura 
Queda de energia, rede ou 
servidores 
Média Médio Médio 
Ataques de negação 
de serviço (DDoS) 
Interrupção proposital de 
serviços por sobrecarga 
Baixa Médio Baixo 
Acesso não 
autorizado (interno) 
Uso indevido de 
credenciais por insidersou 
ex-funcionários 
Baixa Alto Médio 
 
4. Engenharia social: análise detalhada 
4.1. Visão geral 
A engenharia social é considerada a principal ameaça cibernética à continuidade da 
Health Labs, pois atua sobre o elo mais vulnerável da segurança: o comportamento 
humano. Esses ataques utilizam técnicas psicológicas sofisticadas para enganar, manipular 
ou coagir colaboradores, levando-os a cometer ações prejudiciais à segurança da 
informação. 
4.2. Principais cenários de ataque 
1. Phishing direcionado (spear-phishing) 
E-mails altamente personalizados, com nomes reais de colegas ou gestores, 
solicitando o download de arquivos infectados ou o fornecimento de senhas. 
2. Pretexting (uso de pretextos falsos) 
Contatos via telefone, chat ou e-mail fingindo ser técnicos de TI, auditores 
externos ou até fornecedores solicitando credenciais de acesso. 
3. Baiting 
Promessas de recompensas (ex: cupons, acessos antecipados a recursos, 
falsos bônus de produtividade) vinculadas a links maliciosos ou download de 
arquivos com malware. 
4. Quid pro quo 
Oferecimento de ajuda ou informações técnicas em troca de acessos 
(“Estamos atualizando seu sistema; por favor, informe sua senha para que 
possamos continuar”). 
5. Vishing (phishing por voz) 
Ligações com tom de urgência ou autoridade (“Sou do jurídico; há um 
vazamento e precisamos agir imediatamente com acesso ao sistema X”). 
6. Smishing (phishing via SMS/WhatsApp) 
Mensagens com links falsos, alertas de segurança e solicitações de resposta 
urgente via canais móveis. 
4.3. Táticas psicológicas utilizadas 
 
Tática Descrição Exemplo 
Autoridade 
Atacante finge ser gestor, 
fornecedor ou auditor para 
forçar obediência 
“Sou da área jurídica, preciso da 
senha para auditoria urgente” 
Urgência 
Pressão para tomada de 
decisão rápida, sem tempo 
para reflexão 
“Responda em 10 minutos ou o 
sistema será suspenso” 
Empatia ou 
Cortesia 
Criar laços emocionais ou se 
passar por alguém simpático e 
prestativo 
“Bom dia! Tudo certo com seu 
sistema? Podemos ajudar, mas 
preciso de um acesso…” 
Curiosidade 
Usar temas intrigantes ou 
chamativos para provocar 
cliques 
“Clique aqui para ver a lista dos 
colaboradores promovidos” 
Recompensa 
Promessas de ganhos ou 
acessos exclusivos 
“Ganhe um vale-presente 
completando este cadastro” 
Medo ou 
intimidação 
Ameaça de consequências 
graves se não houver 
colaboração 
“Sua conta será desativada por uso 
irregular. Colabore agora” 
 
5. Impactos Potenciais na Continuidade Operacional 
 Perda de dados sensíveis de pacientes e parceiros; 
 Paralisação de sistemas críticos, como prontuário eletrônico ou plataforma de 
telemedicina; 
 Danos à reputação institucional e à confiança de clientes; 
 Multas e sanções por não conformidade com a LGPD e ANS; 
 Comprometimento da capacidade de atendimento em tempo real; 
 Necessidade de resposta a incidentes com alto custo técnico e jurídico. 
6. Estratégias de mitigação 
Para Engenharia Social: 
 Campanhas contínuas de conscientização e simulações reais; 
 Treinamentos obrigatórios com foco em tomada de decisão sob pressão; 
 Políticas de confirmação de identidade por múltiplos canais (ex: call-back); 
 Implementação de duplo fator de autenticação (MFA) em todos os sistemas; 
 Restrições a downloads, pendrives e acessos externos não autorizados; 
 Canal de denúncia imediata e sem retaliação para tentativas de ataque. 
Para demais ameaças: 
 Atualização constante de sistemas e aplicações; 
 Testes regulares de backup e recuperação; 
 Gestão de vulnerabilidades e correções de segurança; 
 Planos de resposta a incidentes com procedimentos validados; 
 Monitoração 24/7 dos ativos críticos e correlação de eventos (SIEM). 
7. Conclusão 
A Health Labs está ciente de que os riscos cibernéticos, especialmente os 
associados à engenharia social, representam uma ameaça concreta à continuidade dos 
negócios. Este relatório subsidia a tomada de decisão estratégica e reforça a necessidade 
de ações coordenadas envolvendo tecnologia, processos e pessoas. A empresa se 
compromete com a prevenção, detecção e resposta efetiva para proteger suas operações, 
clientes e dados. 
 
Plano de Classificação de Dados Sensíveis 
1. Definição e escopo 
1.1. Definição de dados sensíveis 
Para os fins deste plano de classificação de dados sensíveis, a Health Labs adota 
a seguinte definição de dados sensíveis: informações que, se acessadas, divulgadas, 
modificadas ou destruídas de forma não autorizada, podem causar impactos significativos 
à privacidade de indivíduos, à continuidade das operações da organização, à sua reputação 
ou ao seu posicionamento estratégico no mercado. 
Conforme estabelecido pelas normas ABNT NBR ISO 27001:2024 e ABNT NBR ISO 
27701:2019, e em conformidade com a Lei Geral de Proteção de Dados Pessoais (Lei nº 
13.709/2018 – LGPD), são considerados dados sensíveis na Health Labs os seguintes 
tipos de informação: 
 Dados pessoais e dados pessoais sensíveis (PII): informações relacionadas 
a pessoas naturais identificadas ou identificáveis, incluindo, mas não se 
limitando a: 
o Nome completo, CPF, RG; 
o Dados de saúde (histórico clínico, diagnósticos, exames, tratamentos); 
o Dados genéticos e biométricos; 
o Informações sobre localização, contato e perfil comportamental; 
o Registros de acesso e logs de sistemas utilizados por titulares. 
 Propriedade intelectual: informações relacionadas a algoritmos proprietários, 
códigos-fonte, documentação técnica, metodologias de desenvolvimento, e 
quaisquer inovações criadas internamente pela Health Labs. 
 Segredos comerciais: estratégias de mercado, acordos comerciais, parcerias, 
planos de produto, negociações e qualquer informação estratégica não 
pública. 
 Dados financeiros: registros contábeis, dados bancários, informações sobre 
faturamento, contratos com fornecedores e clientes, e projeções financeiras. 
 Dados operacionais e de sistema: logs de auditoria, configurações críticas de 
segurança, arquitetura de sistemas, e informações técnicas que sustentam a 
operação de serviços como: 
o Sistemas de prontuário eletrônico; 
o Plataformas de gestão hospitalar; 
o Ferramentas de telemedicina e análise de dados; 
o Ambientes de integração entre sistemas e dispositivos médicos. 
1.2. Escopo do plano 
O presente Plano de Classificação de Dados Sensíveis aplica-se a todas as 
informações e ativos de informação que são produzidos, processados, armazenados ou 
transmitidos no contexto das operações da Health Labs, abrangendo os seguintes 
domínios: 
 Sistemas e plataformas digitais: incluindo soluções desenvolvidas 
internamente, ambientes de desenvolvimento, teste e produção, bem como 
sistemas terceirizados que tratam dados sensíveis em nome da organização; 
 Infraestrutura de TI e serviços em nuvem: servidores, bancos de dados, 
dispositivos de rede, ambientes de virtualização e quaisquer outros recursos 
que suportem o processamento e armazenamento de dados sensíveis; 
 Ambientes físicos e lógicos: instalações, dispositivos de acesso físico, 
estações de trabalho, dispositivos móveis, mídia de armazenamento e 
mecanismos de controle de acesso lógico; 
 Colaboradores, terceiros e prestadores de serviço: pessoas e entidades que, 
de forma direta ou indireta, tenham acesso a dados sensíveis no contexto das 
atividades da Health Labs, incluindo funcionários, consultores, parceiros 
tecnológicos, operadoras de saúde e profissionais da área médica; 
 Processos e fluxos de informação: toda e qualquer atividade operacional, 
administrativa, técnica ou estratégica que envolva o tratamento de dados 
sensíveis, incluindo coleta, armazenamento, compartilhamento, análise, 
descarte e anonimização de dados. 
Este plano tem como objetivo estabelecer diretrizes claras para a identificação, 
classificação, proteção e monitoramento de dados sensíveis, contribuindo110 
Política de Governança de Dados ........................................................................................ 113 
1. Visão, princípios e objetivos .................................................................................... 113 
2. Estrutura organizacional e responsabilidades ........................................................ 114 
3. Gestão do ciclo de vida dos dados .......................................................................... 117 
4. Qualidade dos dados ................................................................................................ 119 
5. Segurança da Informação e Privacidade dos Dados .............................................. 121 
6. Gestão de riscos e conformidade ............................................................................ 125 
7. Resposta a incidentes de segurança e privacidade................................................ 127 
8. Conscientização e treinamento ................................................................................ 131 
9. Medição e melhoria contínua .................................................................................... 133 
TESTE DE PERFORMANCE – TP4 ........................................................................................... 136 
Parte 1 .................................................................................................................................... 136 
Parte 2 .................................................................................................................................... 138 
Parte 3 .................................................................................................................................... 140 
Cenário Prático Fictício ........................................................................................................ 142 
TESTE DE PERFORMANCE – TP5 ........................................................................................... 153 
Projeto .................................................................................................................................... 153 
Desafio ................................................................................................................................... 153 
Entrega ................................................................................................................................... 154 
 
 
TESTE DE PERFORMANCE – TP1 
Contexto 
Você foi contratado como consultor de segurança da informação para uma 
empresa fictícia que opera em diversos países e lida com grandes volumes de 
dados sensíveis, tanto de clientes quanto de colaboradores. A empresa está 
em processo de conformidade com a ISO/IEC 27001 e precisa implementar 
um Sistema de Gestão da Segurança da Informação (SGSI) robusto para 
proteger suas informações e se adequar às exigências de regulamentações 
como o GDPR e a LGPD. 
O cenário envolve vários desafios de segurança e conformidade, incluindo a 
proteção de dados pessoais, a gestão de acessos, o controle de riscos e a 
implementação de uma estrutura de governança de dados, de acordo com as 
regulamentações legais, para garantir a consistência, integridade e qualidade 
dos dados. 
Desafio 
Após a apresentação do contexto da situação da empresa (como ela funciona, 
situação, dificuldades) pelo professor, sua missão é conduzir uma análise 
detalhada da situação de segurança da informação da empresa, identificar 
vulnerabilidades, implementar os controles necessários para a proteção de 
dados sensíveis e assegurar a conformidade com as normas da ISO/IEC 
27001, além de regulamentos como o GDPR e a LGPD. 
Entrega 
Relatório de análise de segurança da informação, destacando as 
vulnerabilidades e os ativos críticos. 
Plano detalhado para implementação do SGSI com as políticas, normas legais 
e controles propostos. 
Nome da empresa: Health Labs 
Setor: Saúde e Saúde Pública 
Indústria: Health IT (TI da saúde) 
Cidade: Rio de Janeiro 
Estado: Rio de Janeiro 
País: Brasil 
Descrição: Trata-se de uma empresa de médio porte que desenvolve e oferece 
soluções tecnológicas voltadas para o setor de saúde, tais como: desenvolvimento de 
sistemas, com a criação de plataformas como prontuários eletrônicos, sistemas de gestão 
hospitalar e ferramentas para agendamento de consultas; suporte à telemedicina, 
empregando tecnologias que permitem consultas online, monitoramento remoto de 
pacientes e troca de informações médicas entre profissionais; análise de dados, a partir da 
utilização de ferramentas para análise preditiva, gestão de dados médicos e geração de 
insights para melhorar a tomada de decisões clínicas e operacionais; segurança de dados, 
com a implementação de soluções para proteger informações sensíveis de pacientes, 
seguindo normas como a LGPD (Lei Geral de Proteção de Dados); e integração de 
sistemas, garantindo que diferentes softwares e dispositivos médicos possam se comunicar 
entre si de forma eficiente. 
Unidade de Negócios/Agência: Sede 
Tipo de Organização: Local 
Ponto de contato da organização: Ana Carolina Melo Pereira 
Facilitador: Ana Carolina Melo Pereira 
Qual é o valor bruto do ativo que você está tentando proteger? Inferior a um 
milhão de dólares 
Qual é o esforço relativo esperado para esta avaliação? 2 semanas 
Evidências 
Informações preliminares: 
 
 
 
Security Assurance Level (SAL): 
 
 
 
Diagrama de rede: 
 
Inventário de Ativos: 
 
 
 
 
 
 
Resumo de respostas: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
TESTE DE PERFORMANCE – TP2 
Contexto 
Você foi designado como líder do projeto para desenvolver uma estratégia 
robusta que cubra desde a identificação de ameaças até a implementação de 
uma arquitetura eficiente de dados. O projeto também inclui o gerenciamento 
de metadados e a linhagem de dados, assim como a gestão dos programas 
de segurança da informação, assegurando conformidade com as políticas 
internas e regulamentações externas. 
Desafio 
O aluno deve realizar uma análise de ameaças cibernéticas e vulnerabilidades 
nos sistemas críticos da empresa, focando em governança de dados. Após 
essa análise, propor e implementar uma arquitetura de dados otimizada que 
suporte o fluxo eficiente de informações, de acordo com as necessidades da 
empresa, desenvolvendo estratégia para gerenciamento de metadados, 
focando na rastreabilidade do ciclo de vida dos dados (linhagem) e 
assegurando a consistência e qualidade dos dados ao longo de seu uso. 
Entrega 
O aluno deverá compilar todas as atividades e relatórios em um único 
documento, detalhando a análise da situação, os controles implementados, os 
resultados obtidos e como cada competência foi abordada. 
 
Diagrama de rede e inventário de ativos 
Diagrama de rede da Health Labs: 
 
 
Inventário de ativos da Health Labs: 
Zona – Sistema de Câmeras de Circuito Fechado 
SAL Nível: Alto 
Tipo de Componente Nome do Componente 
Servidor de aplicação Servidor de vídeo 
Internet Protocol Camera Câmera IP 1 
Internet Protocol Camera Câmera IP 2 
Computador pessoal PC da Câmera 
Switch Serial Switch da Câmera 
 
Zona – Corporativo – Baixo 
SAL Nível: Baixo 
Tipo de Componente Nome do Componente 
Conector CON-2 
Servidor de Banco de Dados Servidor de Banco de Dados Corporativo 
Firewall Firewall Externo 
Historiador Historiador Público 
Sistema de Detecção de Intrusão (IDS) IDS Corporativo 
Impressoras Sem Fio Impressoras Sem Fio Corporativas 
Computador pessoal Dispositivos Corporativos 
Servidor de Acesso Remoto Servidor de Acesso Remoto 
Roteador Roteador Corporativo 
Switch Serial Switch Corporativo 1 
Switch Serial Switch Corporativo 2 
Switch Serial Switch Corporativo 3 
Servidor de Máquina Virtual Máquinas Virtuais Corporativas 
 
Zona - Sistemas de Controle de Acesso (Crachás e Travas de Portas) – 
Moderado 
SAL Nível: Moderado 
Tipo de Componente Nomepara a 
preservação da confidencialidade, integridade e disponibilidade das informações críticas da 
organização, em conformidade com seus objetivos de segurança da informação e 
privacidade. 
2. Nível de classificação de dados 
Para garantir a adequada proteção das informações tratadas pela Health Labs, este 
plano adota uma estrutura hierárquica de quatro níveis de classificação de dados, baseada 
no impacto potencial à confidencialidade, integridade e disponibilidade da informação, caso 
haja divulgação, modificação ou indisponibilidade não autorizada. 
Cada nível está associado a um conjunto de critérios objetivos e tipos de danos 
potenciais (financeiros, legais, reputacionais e operacionais), de forma a orientar 
corretamente os processos de identificação, rotulagem, manuseio, armazenamento, 
compartilhamento e descarte de informações. 
2.1. Nível 1 – Público 
Descrição: informações que podem ser divulgadas ao público em geral sem causar 
prejuízo à organização ou a qualquer indivíduo. 
Critérios de classificação: 
 Acesso irrestrito permitido; 
 Não há exigência de proteção especial; 
 Sua divulgação não compromete a segurança, a privacidade ou a operação 
da empresa. 
Impacto em caso de violação: 
 Confidencialidade: nenhum impacto; 
 Integridade: baixo impacto, desde que a informação não esteja sendo utilizada 
em contexto regulatório ou contratual; 
 Disponibilidade: baixo impacto operacional. 
Tipos de danos potenciais: Nenhum ou impacto negligenciável. 
Exemplos: 
 Conteúdos institucionais no site corporativo; 
 Materiais de divulgação pública; 
 Políticas e manuais amplamente distribuídos ao mercado. 
2.2. Nível 2 – Interno 
Descrição: informações destinadas ao uso interno da Health Labs que, embora não 
sensíveis, não devem ser compartilhadas com o público externo. 
Critérios de classificação: 
 Acesso restrito a colaboradores e partes autorizadas; 
 Sua divulgação não autorizada pode causar transtornos administrativos ou 
comprometer processos internos. 
Impacto em caso de violação: 
 Confidencialidade: impacto baixo a moderado (risco de exposição de 
processos internos); 
 Integridade: moderado, especialmente se dados forem usados para tomada 
de decisão interna; 
 Disponibilidade: pode causar atrasos operacionais ou retrabalho. 
Tipos de danos potenciais: 
 Operacional: interrupções de processos internos; 
 Reputacional: baixo impacto, limitado ao ambiente interno. 
Exemplos: 
 Relatórios gerenciais não estratégicos; 
 Procedimentos operacionais internos; 
 Dados de desempenho de equipes e produtividade. 
2.3. Nível – Confidencial 
Descrição: informações sensíveis cujo acesso deve ser limitado a grupos específicos 
dentro da organização. Sua exposição, modificação ou perda pode causar danos 
significativos à empresa ou a terceiros. 
Critérios de classificação: 
 Dados regulados pela LGPD ou outros marcos legais; 
 Requer proteção contra divulgação não autorizada; 
 Pode envolver dados pessoais, comerciais ou operacionais críticos. 
Impacto em caso de violação: 
 Confidencialidade: alto impacto, podendo incluir violações legais; 
 Integridade: alto impacto, podendo comprometer decisões clínicas ou 
operacionais; 
 Disponibilidade: interrupções críticas em serviços ou processos. 
Tipos de danos potenciais: 
 Legal: multas e sanções regulatórias (ex.: LGPD); 
 Financeiro: perda de contratos, custos com contenção; 
 Reputacional: danos à imagem institucional; 
 Operacional: comprometimento de sistemas essenciais. 
Exemplos: 
 Dados de pacientes (PII e prontuários eletrônicos); 
 Códigos-fonte de produtos; 
 Relatórios financeiros e projeções; 
 Contratos com cláusulas sigilosas. 
2.4. Nível 4 – Restrito/Altamente Confidencial 
Descrição: informações críticas cujo acesso deve ser rigidamente controlado e 
restrito ao menor número possível de pessoas. O comprometimento desses dados pode 
colocar em risco a existência, continuidade ou segurança jurídica da empresa. 
Critérios de classificação: 
 Informações estratégicas de alto valor; 
 Dados sob acordos de confidencialidade com terceiros; 
 Informações que, se comprometidas, podem causar impactos catastróficos. 
Impacto em caso de violação: 
 Confidencialidade: impacto muito alto, com risco de perda de vantagem 
competitiva e responsabilização jurídica grave; 
 Integridade: impacto muito alto, afetando diretamente decisões vitais ou 
compromissos contratuais; 
 Disponibilidade: interrupção de serviços críticos e compromissos com 
parceiros. 
Tipos de danos potenciais: 
 Financeiro: prejuízos severos e imediatos; 
 Legal: risco de litígios e perdas contratuais; 
 Reputacional: quebra de confiança com clientes e parceiros; 
 Operacional: paralisação de atividades críticas. 
Exemplos: 
 Chaves criptográficas e segredos de autenticação; 
 Algoritmos proprietários de predição clínica; 
 Dados integrados de múltiplos sistemas com riscos de reidentificação; 
 Estratégias de aquisição, fusões e expansão de mercado. 
Essa estrutura de classificação será aplicada em conjunto com os processos de 
inventário, rotulagem, controle de acesso, armazenamento seguro e descarte de 
informações, conforme descrito nas seções posteriores deste plano. 
3. Metodologia de classificação 
A classificação de dados na Health Labs é realizada com o objetivo de assegurar 
que as informações sejam protegidas de acordo com sua criticidade e sensibilidade, ao 
longo de todo o seu ciclo de vida. Este processo envolve a identificação, rotulagem, 
documentação e, quando necessário, a reclassificação das informações, com base em 
critérios técnicos e organizacionais. 
3.1. Papeis e responsabilidades 
Descrição: informações que podem ser divulgadas ao público em geral sem causar 
prejuízo à organização ou a qualquer indivíduo. 
O processo de classificação de dados envolve as seguintes partes: 
 Proprietários dos dados (Data Owners): são responsáveis primários pela 
correta classificação das informações sob sua titularidade. Cabe a eles 
avaliarem a sensibilidade dos dados, definir os níveis de acesso apropriados 
e autorizar o compartilhamento. 
 Criadores de conteúdo: todo colaborador, terceirizado ou parceiro que cria 
informações deve aplicar a classificação adequada no momento da criação 
do dado, conforme as diretrizes estabelecidas neste plano e sob orientação 
do proprietário da informação. 
 Área de Segurança da Informação: responsável por definir a política de 
classificação, fornecer orientações, treinar os colaboradores, realizar 
auditorias e validar a consistência da aplicação das classificações. 
 Equipe de Tecnologia da Informação: dá suporte técnico à implementação de 
mecanismos de classificação, armazenamento seguro e controle de acesso 
com base nos níveis definidos. 
3.2. Processo de classificação 
A classificação de dados pode ocorrer de forma manual, automatizada ou híbrida, 
conforme descrito a seguir: 
 Classificação manual: realizada pelos criadores ou proprietários dos dados no 
momento da geração ou manipulação de um ativo de informação. É o método 
principal para documentos textuais, apresentações, planilhas, e-mails e 
registros clínicos não estruturados. 
 Classificação automatizada: utiliza sistemas de Data Loss Prevention (DLP), 
inteligência artificial ou mecanismos de identificação baseados em padrões 
(como expressões regulares para CPFs, dados de saúde etc.) para atribuir 
classificações automaticamente. Utilizado especialmente em grandes 
volumes de dados estruturados, bancos de dados e sistemas corporativos. 
 Classificação híbrida: combina as abordagens anteriores, permitindo que 
sistemas realizem uma classificação preliminar, sujeita à revisão e validação 
por um responsável humano. 
3.3. Documentação da classificação 
A classificação deve ser registrada e identificável nos seguintes formatos: 
 Rótulos visuais: aplicados diretamentenos documentos (ex.: cabeçalhos de 
documentos Word, marcas d'água em PDFs, nomenclatura de arquivos); 
 Metadados: campos estruturados inseridos em arquivos digitais, bancos de 
dados ou registros de sistemas que indiquem o nível de classificação; 
 Etiquetas lógicas (tags): usadas em sistemas de informação, como soluções 
de ECM (Enterprise Content Management) ou sistemas de prontuário 
eletrônico, para facilitar o controle de acesso e monitoramento. 
A documentação da classificação deve ser armazenada junto ao ativo de informação 
e mantida atualizada em caso de alterações. 
3.4. Reclassificação de dados 
Informações podem ter sua sensibilidade alterada ao longo do tempo. Por isso, o 
processo de reclassificação é essencial para garantir que os dados continuem sendo 
protegidos de forma proporcional ao seu valor e risco. 
Diretrizes para reclassificação: 
 Mudança de contexto ou conteúdo: caso novos elementos tornem a 
informação mais sensível (ex.: adição de dados pessoais a um relatório), a 
classificação deve ser elevada imediatamente. 
 Fim de validade legal ou operacional: dados que deixam de ter valor 
estratégico ou sensível (ex.: contratos vencidos, resultados de testes 
obsoletos) podem ser rebaixados ou encaminhados para descarte seguro. 
 Ciclo de vida da informação: a cada etapa (criação, uso, armazenamento, 
arquivamento e descarte) os responsáveis devem revisar se a classificação 
ainda é adequada. 
Responsáveis pela reclassificação: o proprietário do dado é o responsável final pela 
decisão de reclassificar, podendo ser apoiado por áreas como segurança da informação, 
jurídico ou compliance, conforme a natureza do dado. 
Registro da reclassificação: toda alteração de classificação deve ser registrada, com 
data, justificativa e identificação do responsável, de forma rastreável (logs, versionamento, 
sistema de gestão de documentos etc.). 
Essa metodologia busca assegurar que a classificação da informação seja 
proporcional ao risco, coerente ao longo do tempo e integrada às rotinas operacionais da 
Health Labs, como parte de sua governança de segurança da informação e privacidade. 
4. Requisitos de manuseio por nível de classificação 
O manuseio seguro das informações da Health Labs requer que todos os dados 
sejam tratados conforme seu nível de sensibilidade, com medidas técnicas e 
organizacionais proporcionais aos riscos associados. Abaixo estão os requisitos específicos 
por nível de classificação: 
4.1. Nível 1 – Público 
Aspecto Requisitos 
Armazenamento 
Pode ser armazenado em repositórios públicos, sites, redes 
internas ou nuvens públicas sem restrições. Não requer 
criptografia, mas recomenda-se controle de versão e backup 
periódico. 
Transmissão 
Permitido via e-mail, web, redes abertas, ou compartilhamento em 
mídias sociais. 
Processamento 
Pode ser processado em qualquer ambiente, inclusive por 
terceiros, desde que não envolva dados de níveis superiores. 
Acesso 
Acesso irrestrito. Pode ser visualizado, copiado ou distribuído por 
qualquer parte, interna ou externa. 
Retenção e 
Descarte 
Retido conforme valor histórico ou estratégico. Descarte pode ser 
realizado por exclusão simples. 
 
4.2. Nível 2 – Interno 
Aspecto Requisitos 
Armazenamento 
Deve ser armazenado em sistemas internos com autenticação (ex: 
servidores corporativos, SharePoint, OneDrive empresarial). 
Criptografia em repouso é recomendada. 
Transmissão 
Permitido somente por canais autenticados e protegidos (ex: e-
mail corporativo, VPN, HTTPS, SFTP). 
Processamento 
Permitido em ambientes controlados da organização. Terceirizados 
devem ter acordos de confidencialidade. 
Acesso 
Restrito a colaboradores autorizados. Controles baseados em 
funções (RBAC) devem ser aplicados. 
Retenção e 
Descarte 
Retenção conforme necessidade operacional. Descarte 
preferencial por exclusão segura (ex: sobregravação). 
 
4.3. Nível 3 – Confidencial 
Aspecto Requisitos 
Armazenamento 
Armazenamento apenas em sistemas com criptografia em 
repouso (ex: AES-256), controle de acesso lógico com 
autenticação forte (ex: MFA) e proteção contra perda de dados 
(DLP). 
Transmissão 
Apenas por canais criptografados (ex: TLS 1.2+, VPN, e-mails com 
criptografia ponta a ponta). Compartilhamento por ferramentas com 
controle de acesso e logs de auditoria (ex: plataformas com link 
seguro e expiração automática). 
Processamento 
Deve ocorrer exclusivamente em ambientes internos controlados 
ou nuvens certificadas (ex: ISO 27001, HIPAA). Aplicar princípio 
do menor privilégio e segregação de ambientes. 
Acesso 
Apenas por pessoas autorizadas com justificativa documentada e 
conforme a função. Registros de acesso devem ser mantidos. 
Retenção e 
Descarte 
Retido conforme requisitos legais e contratuais (ex: até 20 anos 
para dados clínicos). Descarte por meios seguros (ex: limpeza 
criptográfica, destruição física de mídia). 
 
4.4. Nível 4 – Restrito/Altamente Confidencial 
Aspecto Requisitos 
Armazenamento 
Armazenamento somente em ambientes com criptografia forte, 
segregação lógica, logs de acesso, controle físico de acesso (salas 
seguras, cofres de dados). Deve ter redundância e backup 
criptografado em ambientes protegidos. 
Transmissão 
Altamente restrita. Permitida apenas via canais com autenticação 
de ponta a ponta e criptografia forte. Devem ser utilizados tokens 
temporários, assinatura digital e logs completos de auditoria. 
Processamento 
Autorizado apenas em ambientes isolados, com monitoramento 
contínuo e controle reforçado de mudanças. Processamento 
externo proibido, salvo sob contrato com cláusulas específicas de 
segurança e auditoria. 
Acesso 
Exclusivo a indivíduos previamente autorizados, com registro 
formal, auditoria contínua e renovação periódica de permissões. 
Autenticação multifator obrigatória. 
Retenção e 
Descarte 
Retenção mínima necessária, com base em obrigações 
regulatórias. Descarte apenas por métodos certificados: destruição 
física (mídia) ou sanitização com ferramentas aprovadas (ex: 
DBAN, Blancco). Registro de descarte obrigatório. 
 
Esses requisitos devem ser incorporados a todos os processos, tecnologias e 
políticas da Health Labs, e são parte integrante do Sistema de Gestão de Segurança da 
Informação (SGSI) da organização. Auditorias internas e revisões periódicas garantirão sua 
aplicação contínua. 
5. Atribuição de responsabilidades 
A proteção eficaz das informações classificadas requer uma divisão clara de 
responsabilidades entre os diferentes atores envolvidos no ciclo de vida dos dados. A 
Health Labs adota um modelo baseado em três papéis principais: 
 Proprietários de dados (Data Owners) 
 Custodiantes de dados (Data Custodians) 
 Usuários de dados 
Cada grupo tem funções e obrigações específicas, conforme descrito abaixo. 
5.1. Proprietários de dados (Data Owners) 
São os responsáveis finais pelos dados sob sua titularidade. Tipicamente, são líderes 
de áreas de negócio ou de projeto (ex.: gerente de produto, diretor de TI, coordenador 
médico). 
Responsabilidades: 
 Avaliar a sensibilidade e criticidade das informações sob sua 
responsabilidade. 
 Determinar e revisar o nível de classificação apropriado para os dados, 
conforme diretrizes da organização. 
 Definir os requisitos de acesso, compartilhamento e retenção. 
 Aprovar solicitações de reclassificação ou descarte. 
 Assegurar a conformidade com leis e regulamentações, como a LGPD, HIPAA 
e normas setoriais de saúde. 
 Trabalhar com a área de Segurança da Informação na definição de controles 
apropriados para os dados classificados. 
5.2. Custodiantes de dados (Data Custodians) 
São os responsáveis técnicos pela implementação e manutenção dos controles de 
segurança, atuando em nome dos proprietários dos dados. Normalmente, são membros da 
equipe de TI, infraestrutura ou segurança da informação. 
Responsabilidades: 
 Implementar controlestécnicos de proteção conforme o nível de classificação: 
criptografia, controle de acesso, backup, monitoramento etc. 
 Manter e operar os sistemas que armazenam, processam ou transmitem 
dados classificados. 
 Garantir que os dados estejam armazenados e transmitidos conforme os 
requisitos de confidencialidade, integridade e disponibilidade. 
 Auxiliar na resposta a incidentes envolvendo dados classificados. 
 Fornecer suporte ao processo de revisão de acessos, auditoria e 
reclassificação. 
 Garantir que os ambientes estejam em conformidade com normas de 
segurança da informação e privacidade. 
5.3. Usuários de dados 
Englobam todos os colaboradores, terceirizados e parceiros que acessam, 
manipulam ou consomem dados classificados durante suas atividades profissionais. 
Responsabilidades: 
 Conhecer e seguir as políticas, diretrizes e normas de manuseio de dados da 
Health Labs. 
 Garantir que os dados sejam usados, armazenados e compartilhados de 
acordo com sua classificação. 
 Não reclassificar, copiar, transferir ou divulgar dados sem a devida 
autorização do proprietário dos dados. 
 Notificar imediatamente a área de Segurança da Informação em caso de 
incidente, uso indevido ou suspeita de violação. 
 Participar de treinamentos obrigatórios sobre proteção de dados e 
privacidade. 
Essa divisão de papéis visa a garantir que a gestão da informação classificada seja 
feita de forma responsável, segura e rastreável, permitindo à Health Labs proteger seus 
ativos informacionais e manter a conformidade regulatória. 
6. Revisão e manutenção 
A eficácia do plano de classificação de dados da Health Labs depende da sua 
capacidade de se adaptar a novas ameaças, tecnologias, exigências regulatórias e 
mudanças no negócio. Para isso, são estabelecidos processos formais de revisão e 
atualização periódica, assegurando sua contínua relevância, consistência e conformidade. 
6.1. Frequência de revisão 
O plano deverá ser revisado de forma: 
 Regular: Pelo menos anualmente, como parte do ciclo de revisão do Sistema 
de Gestão de Segurança da Informação (SGSI). 
 Eventual, sempre que ocorrerem mudanças significativas, tais como: 
o Alterações em leis e regulamentos (ex.: atualizações na LGPD, novas 
normas da ANPD); 
o Incidentes relevantes de segurança ou vazamentos de dados; 
o Adoção de novas tecnologias ou arquiteturas (ex.: cloud, IA, 
interoperabilidade com dispositivos médicos); 
o Mudanças estruturais no negócio ou nos serviços oferecidos pela 
Health Labs; 
o Resultados de auditorias, avaliações de risco ou testes de 
conformidade que apontem deficiências. 
6.2. Processo de revisão 
A revisão do plano seguirá as etapas abaixo: 
1. Planejamento da Revisão 
 Definição do cronograma e dos responsáveis pela revisão. 
 Coleta de feedback de stakeholders (TI, Jurídico, Segurança, áreas de 
negócio). 
2. Avaliação de Conformidade e Riscos 
 Verificação de aderência a normas aplicáveis (ex: ISO 27001, LGPD, 
normas do setor de saúde). 
 Análise de novos riscos e vulnerabilidades identificadas. 
3. Atualização do Conteúdo 
 Ajuste dos critérios de classificação, níveis, responsabilidades e 
requisitos de manuseio, conforme necessário. 
 Inclusão de novos controles técnicos ou mudanças na metodologia. 
4. Validação 
 Revisão pelo Comitê de Segurança da Informação ou grupo designado. 
 Aprovação formal pelo responsável pelo SGSI e liderança executiva, 
se aplicável. 
5. Comunicação e Treinamento 
 Divulgação das mudanças para os usuários impactados. 
 Atualização de materiais de treinamento e reorientação das áreas 
envolvidas. 
6. Registro e Controle de Versões 
 Toda revisão deve ser documentada com data, responsáveis, 
justificativas e nova numeração de versão. 
 O histórico de versões deve estar disponível para consulta e auditoria. 
6.3. Responsáveis pela manutenção 
A responsabilidade geral pela revisão e manutenção do plano é da área de 
Segurança da Informação, com apoio dos seguintes grupos: 
 Data Owners: avaliam a aplicabilidade das classificações em suas áreas e 
sugerem melhorias; 
 TI e Infraestrutura: avaliam impactos técnicos das mudanças; 
 Jurídico e Compliance: validam alinhamento com legislações e contratos; 
 Gestores de processos: verificam se os controles continuam viáveis e eficazes 
na prática. 
6.4. Indicadores e melhorias 
A eficácia do plano será monitorada com base em indicadores como: 
 Percentual de dados corretamente classificados; 
 Incidentes relacionados a manuseio inadequado de dados sensíveis; 
 Nível de conformidade identificado em auditorias; 
 Frequência de reclassificações e adequações corretivas. 
Esses dados serão usados para melhoria contínua do plano, em alinhamento com 
os princípios da ISO 27001. 
 
Política de Governança de Dados 
1. Visão, princípios e objetivos 
1.1. Visão da governança de dados 
Na Health Labs, a governança de dados é orientada pela visão de que os dados são 
ativos estratégicos essenciais para a inovação, a qualidade dos serviços em saúde, a 
segurança da informação e a confiança dos clientes e parceiros. O objetivo é garantir que 
os dados, especialmente os sensíveis e pessoais relacionados à saúde, sejam tratados 
com responsabilidade, transparência e excelência, promovendo valor para a organização e 
seus stakeholders por meio do uso ético, seguro e inteligente da informação. 
1.2. Princípios orientadores 
A governança de dados da Health Labs é sustentada pelos seguintes princípios 
fundamentais, em conformidade com os marcos regulatórios aplicáveis e as melhores 
práticas internacionais: 
 Precisão e Qualidade: os dados devem ser completos, atualizados, 
consistentes e relevantes para suas finalidades de uso. 
 Segurança da Informação: a confidencialidade, integridade e disponibilidade 
dos dados serão asseguradas por meio de controles técnicos e 
organizacionais robustos, conforme a ABNT NBR ISO 27001:2024. 
 Privacidade por Design e por Padrão: a proteção de dados pessoais será 
incorporada desde a concepção das soluções tecnológicas, respeitando os 
princípios da ABNT NBR ISO 27701:2019 e da Lei Geral de Proteção de 
Dados Pessoais (Lei nº 13.709/2018 – LGPD). 
 Acessibilidade e Disponibilidade: os dados devem estar acessíveis, quando 
autorizados, para as partes interessadas relevantes, de forma oportuna e 
segura, conforme os níveis de acesso definidos. 
 Responsabilidade e Transparência: todas as partes envolvidas no ciclo de 
vida dos dados devem compreender suas responsabilidades e atuar com 
transparência na coleta, processamento, armazenamento, compartilhamento 
e descarte das informações. 
 Conformidade Legal e Regulatória: o tratamento de dados observará 
rigorosamente os requisitos legais, regulatórios e normativos aplicáveis, 
nacionais e internacionais. 
 Minimização de Dados: apenas os dados estritamente necessários para as 
finalidades específicas serão coletados e mantidos, evitando excessos e 
reduzindo riscos. 
 Interoperabilidade e Integração Segura: os sistemas da organização devem 
favorecer a troca segura e eficiente de dados entre diferentes plataformas e 
dispositivos, especialmente em ambientes hospitalares e de saúde digital. 
1.3. Objetivos da governança de dados 
A política de governança de dados da Health Labs tem como objetivos principais: 
 Assegurar a conformidade com leis e normas aplicáveis, como a Lei Geral de 
Proteção de Dados Pessoais (Lei nº 13.709/2018 – LGPD), ABNT NBR ISO 
27001:2024, ABNT NBR ISO 27701:2019, e demais regulamentações de 
saúde e segurança da informação; 
 Proteger os dados sensíveis dos pacientes e usuários contra acessos não 
autorizados, vazamentos, perdas e alterações indevidas; 
 Mitigar riscos relacionados ao tratamento de dados, especialmente aqueles 
que podem impactar a privacidade, a continuidade dos negócios e a reputação 
da organização; 
 Melhorar a qualidade e o uso estratégicodos dados, tornando-os confiáveis 
para análises, geração de insights, inovação e suporte à tomada de decisões 
clínicas e operacionais; 
 Promover a cultura organizacional voltada à proteção de dados, 
conscientizando colaboradores, parceiros e clientes sobre boas práticas e 
deveres relacionados ao uso da informação; 
 Favorecer a interoperabilidade e eficiência dos sistemas, assegurando que a 
troca de dados entre diferentes aplicações e dispositivos ocorra de forma 
padronizada, segura e eficaz. 
2. Estrutura organizacional e responsabilidades 
2.1. Estrutura de governança 
A governança de dados na Health Labs é apoiada por uma estrutura organizacional 
multidisciplinar, composta por instâncias de decisão, coordenação e execução, com o 
objetivo de garantir a gestão eficaz, segura e ética dos dados em todo o seu ciclo de vida. 
 
A principal instância responsável pela supervisão estratégica da governança de 
dados é o Comitê de Governança de Dados (CGD), que é um órgão deliberativo e consultivo 
composto por representantes das áreas de Tecnologia da Informação, Segurança da 
Informação, Jurídico, Negócios, Compliance, Qualidade, Produtos e demais áreas 
envolvidas com o tratamento de dados. O CGD é responsável por definir diretrizes, revisar 
políticas, acompanhar indicadores e aprovar decisões relevantes relacionadas à gestão de 
dados. 
O CGD é apoiado por estruturas operacionais responsáveis pela execução e 
monitoramento das práticas de governança, especialmente os papéis definidos a seguir. 
2.2. Papeis e responsabilidades 
2.2.1. Proprietários de dados (Data Owners) 
Descrição: São responsáveis por uma área de negócio ou processo específico que 
gera ou utiliza dados, sendo os "donos" dos dados sob sua responsabilidade. 
Responsabilidades: 
 Garantir que os dados sob sua titularidade estejam classificados corretamente 
e protegidos conforme seu nível de sensibilidade; 
 Autorizar o acesso e uso dos dados por outras áreas ou sistemas; 
 Zelar pela conformidade legal e regulatória no tratamento dos dados; 
 Participar de decisões estratégicas no Comitê de Governança de Dados; 
 Aprovar políticas e procedimentos relacionados ao uso e à qualidade dos 
dados. 
2.2.2. Guardiões de dados (Data Stewards) 
Descrição: São responsáveis pela gestão operacional da qualidade, consistência e 
integridade dos dados, atuando como elo entre os proprietários e os usuários. 
Responsabilidades: 
 Aplicar as diretrizes de governança estabelecidas para os dados sob sua 
gestão; 
 Monitorar e corrigir problemas de qualidade dos dados (ex.: dados duplicados, 
inconsistentes, desatualizados); 
 Promover boas práticas de documentação, padronização e metadados; 
 Apoiar os proprietários de dados na definição de regras de negócio e 
classificação da informação; 
 Colaborar em projetos de integração e análise de dados. 
2.2.3. Custodiantes de dados (Data Custodians) 
Descrição: São os responsáveis pela infraestrutura técnica, segurança e 
disponibilidade dos dados, geralmente vinculados às equipes de TI e Segurança da 
Informação. 
Responsabilidades: 
 Implementar e manter os controles técnicos de segurança (criptografia, 
backup, controle de acesso, logs etc.); 
 Garantir a disponibilidade e integridade dos dados nos sistemas sob sua 
custódia; 
 Apoiar as auditorias internas e externas no fornecimento de evidências 
técnicas; 
 Aplicar as políticas de retenção, descarte e recuperação de dados; 
 Trabalhar em conjunto com os proprietários e guardiões para assegurar a 
proteção e o desempenho adequado dos sistemas de dados. 
2.2.4. Usuários de dados 
Descrição: São os profissionais da organização que acessam e utilizam os dados 
para suas atividades de negócio, conforme suas permissões. 
Responsabilidades: 
 Utilizar os dados de forma ética, segura e em conformidade com os princípios 
da governança e as políticas internas; 
 Reportar inconsistências, falhas ou acessos indevidos aos dados; 
 Manter a confidencialidade das informações sensíveis ou pessoais às quais 
tiver acesso; 
 Participar de treinamentos e ações de conscientização sobre privacidade e 
segurança da informação. 
2.3. Interações entre os papéis 
A governança de dados exige colaboração contínua entre os diferentes papéis, 
conforme descrito a seguir: 
 Os Proprietários de Dados definem diretrizes e autorizações que são 
operacionalizadas pelos Guardiões de Dados e suportadas tecnicamente 
pelos Custodiantes; 
 Os Guardiões de Dados garantem a consistência e a usabilidade dos dados 
para os Usuários, ao mesmo tempo em que asseguram que as políticas dos 
proprietários sejam respeitadas; 
 Os Custodiantes de Dados atuam transversalmente, garantindo a segurança, 
disponibilidade e performance dos dados usados por todos os demais papéis; 
 O Comitê de Governança de Dados supervisiona a atuação integrada dos 
papéis, resolve conflitos, alinha iniciativas estratégicas e avalia riscos 
associados ao uso dos dados. 
3. Gestão do ciclo de vida dos dados 
A Health Labs adota uma abordagem estruturada para a gestão do ciclo de vida dos 
dados, desde a sua criação ou coleta até o seu descarte seguro, assegurando que cada 
etapa esteja em conformidade com os princípios de segurança da informação, privacidade 
e governança. Esta abordagem busca garantir que os dados estejam sempre protegidos, 
atualizados, pertinentes e utilizados de forma ética e legal. 
3.1. Coleta e criação de dados 
A coleta e criação de dados, especialmente dados pessoais identificáveis (PII) e 
dados sensíveis de saúde, devem seguir critérios claros e transparentes: 
 Consentimento e bases legais: toda coleta de dados pessoais deve estar 
fundamentada em uma base legal válida, preferencialmente o consentimento 
livre, informado e explícito do titular, conforme previsto na LGPD e na ISO/IEC 
27701 (cláusula 6.3). O consentimento deve ser registrado e vinculado à 
finalidade da coleta. 
 Finalidade específica: os dados só poderão ser coletados ou gerados quando 
estritamente necessários para finalidades legítimas, específicas e 
previamente determinadas, alinhadas às atividades-fim da empresa (ISO/IEC 
27701, 6.4). 
 Minimização de dados: apenas os dados essenciais devem ser coletados. 
Informações excessivas, irrelevantes ou desnecessárias para a finalidade 
declarada devem ser evitadas (ISO/IEC 27701, 6.5). 
 Documentação: a coleta e a criação de dados devem ser documentadas e 
incluídas nos registros de atividades de tratamento (RAT), incluindo as bases 
legais, os responsáveis, os tipos de dados e os sistemas envolvidos. 
3.2. Armazenamento e uso dos dados 
O armazenamento e uso de dados devem respeitar critérios de segurança, 
classificação e necessidade operacional: 
 Plano de classificação da informação: todos os dados devem ser classificados 
de acordo com seu grau de sensibilidade (ex.: público, interno, confidencial, 
sensível) e tratados conforme os controles apropriados a cada categoria, 
conforme definido na política de classificação da Health Labs. 
 Ambientes controlados: os dados devem ser armazenados em ambientes 
seguros, com controle de acesso baseado em papéis (RBAC), segregação de 
ambientes (produção, testes, desenvolvimento) e mecanismos de 
rastreabilidade. 
 Uso ético e limitado: o uso dos dados deve estar sempre vinculado à finalidade 
original para a qual foram coletados, salvo nos casos em que a nova finalidade 
esteja respaldada legalmente ou tenha novo consentimento dos titulares. 
 Auditoria e monitoramento: a manipulação de dados sensíveis e pessoais 
será auditada periodicamente, com logs de acesso e uso mantidos conforme 
a política de segurança da informação. 
3.3. Compartilhamento e transferência de dados 
O compartilhamento e a transferência de dados, internos ou com terceiros, devem 
observar critérios de necessidade, segurança e conformidade regulatória: 
 Compartilhamento interno: deveocorrer de forma controlada, com base na 
necessidade de conhecimento, respeitando as permissões definidas para 
cada função ou equipe. 
 Transferência para terceiros: sempre que houver compartilhamento de dados 
com fornecedores, parceiros ou prestadores de serviço, deve haver um 
Acordo de Tratamento de Dados (DPA - Data Processing Agreement) 
formalizado, definindo responsabilidades, medidas de segurança, finalidades 
autorizadas e obrigações de confidencialidade (ISO/IEC 27001, A.15; ISO/IEC 
27701, 6.12). 
 Transferência internacional de dados: a exportação de dados para fora do 
Brasil só será permitida quando garantidas as condições previstas na LGPD 
e nas normas aplicáveis, como cláusulas contratuais específicas, certificações 
reconhecidas ou garantias adequadas de proteção. 
 Registros de compartilhamento: toda transferência relevante de dados deve 
ser registrada, documentando as partes envolvidas, as finalidades e os tipos 
de dados compartilhados. 
3.4. Retenção e descarte de dados 
A Health Labs estabelece políticas claras de retenção e descarte de dados, com 
base em exigências legais, regulatórias e necessidades de negócio: 
 Política de retenção: os dados devem ser mantidos pelo tempo mínimo 
necessário para o cumprimento de sua finalidade, respeitando prazos legais 
(como exigências da ANS, CNES, LGPD e obrigações fiscais) e as 
necessidades contratuais ou operacionais da empresa. 
 Eliminação segura: o descarte de dados deve ocorrer de forma segura e 
irreversível, com métodos como sobrescrita segura (para dados digitais) e 
trituração ou incineração (para documentos físicos), conforme boas práticas 
estabelecidas (ISO/IEC 27001, A.17; ISO/IEC 27701, 6.7.2). 
 Bloqueio e anonimização: quando aplicável, os dados poderão ser 
bloqueados (inativados sem acesso operacional) ou anonimizados, de forma 
a eliminar a possibilidade de identificação do titular, especialmente quando 
exigido por regulamentações de saúde ou por solicitações de titulares. 
 Auditoria do descarte: procedimentos de descarte devem ser auditáveis, com 
registro de evidências, responsáveis e datas, especialmente no caso de 
dados pessoais e sensíveis. 
4. Qualidade dos dados 
A qualidade dos dados é um pilar fundamental para a efetividade das soluções 
oferecidas pela Health Labs, especialmente em um contexto sensível como o da saúde. 
Dados de baixa qualidade podem comprometer diagnósticos, decisões clínicas, análises 
operacionais e a conformidade legal da empresa. Por isso, a organização estabelece 
práticas sistemáticas para garantir que os dados sejam precisos, completos, consistentes 
e atualizados ao longo de todo o seu ciclo de vida. 
4.1. Dimensões da qualidade dos dados 
A Health Labs adota as seguintes dimensões de qualidade como referência para 
avaliação e gestão dos dados: 
 Precisão: os dados devem refletir com fidelidade os fatos ou entidades que 
representam, evitando erros de digitação, medição ou categorização. 
 Completude: todas as informações essenciais devem estar registradas, 
evitando lacunas em campos obrigatórios ou ausências de dados-chave. 
 Consistência: os dados devem ser coerentes entre diferentes fontes e 
sistemas, sem contradições ou duplicidades. 
 Atualidade: as informações devem estar atualizadas, refletindo as mudanças 
relevantes em tempo adequado para o seu uso. 
 Validade: os dados devem seguir formatos, padrões e regras de negócio pré-
estabelecidos (ex.: datas válidas, CPF com dígitos corretos, classificações 
médicas padronizadas). 
4.2. Processos para garantia da qualidade 
A garantia da qualidade dos dados na Health Labs é realizada por meio dos 
seguintes processos contínuos: 
 Definição de regras e padrões de dados: cada tipo de dado deve ter regras 
claras de validação, formato, obrigatoriedade e relacionamento, definidas em 
conjunto pelos Proprietários e Guardiões de Dados. 
 Documentação e metadados: todas as bases de dados e sistemas devem 
possuir documentação clara sobre o significado, origem, regras e restrições 
dos dados (catálogo de dados e dicionário de dados). 
 Validações automatizadas: durante a entrada e atualização de dados nos 
sistemas, devem ser aplicadas regras de validação automática para impedir 
registros incorretos ou incompletos. 
 Padronização de códigos e terminologias: devem ser utilizados padrões 
amplamente aceitos, como CID, TUSS, HL7, SNOMED, entre outros, 
especialmente para dados clínicos. 
 Auditorias e monitoramento contínuo: devem ser realizados monitoramentos 
periódicos da qualidade dos dados com base em indicadores específicos, 
permitindo análise proativa de falhas e desvios. 
4.3. Mecanismos de correção de problemas 
A identificação e correção de problemas de qualidade de dados são conduzidas por 
meio de mecanismos estruturados e colaborativos: 
 Detecção de erros: os erros podem ser identificados por validações 
automáticas, por auditorias internas, por análises de inconsistências 
intersistêmicas ou por reportes de usuários. 
 Canais de comunicação: usuários e colaboradores devem ter acesso a canais 
específicos para reportar inconsistências, erros ou dúvidas sobre dados, 
garantindo agilidade na resolução. 
 Plano de tratamento de dados inválidos: sempre que forem detectados dados 
incorretos, deve ser acionado um plano de correção, que inclui: 
o Identificação da origem do erro; 
o Registro da não conformidade; 
o Correção controlada, preferencialmente pelos responsáveis diretos; 
o Comunicação aos afetados, quando necessário (ex.: em registros 
clínicos); 
o Adoção de medidas preventivas para evitar reincidência. 
 Papéis responsáveis: 
o Os Guardiões de Dados são os principais responsáveis por monitorar 
a qualidade e coordenar a correção de problemas; 
o Os Proprietários de Dados devem aprovar alterações sensíveis e 
avaliar impactos de correções em processos de negócio; 
o Os Usuários de Dados têm o dever de reportar falhas identificadas e 
colaborar com a acurácia das informações sob seu uso. 
5. Segurança da Informação e Privacidade dos Dados 
A Health Labs reconhece que a proteção dos dados é fundamental para garantir a 
confiança de seus clientes, parceiros e pacientes, bem como para assegurar a continuidade 
de suas operações e a conformidade legal. Por isso, adota uma abordagem integrada de 
segurança da informação e privacidade, conforme os princípios das normas ABNT NBR 
ISO 27001:2024 e ABNT NBR ISO 27701:2019. 
A empresa estabelece políticas e controles técnicos, organizacionais e 
comportamentais para prevenir, detectar, responder e recuperar-se de incidentes 
relacionados ao uso indevido, vazamento ou perda de dados, especialmente os que 
envolvem informações pessoais identificáveis (PII). 
5.1. Integração entre Segurança da Informação e Privacidade 
A governança da Health Labs adota uma visão unificada entre segurança da 
informação (confidencialidade, integridade e disponibilidade) e privacidade de dados 
(transparência, finalidade, minimização, autodeterminação informacional), garantindo que: 
 Toda medida de proteção técnica (como criptografia, autenticação ou 
segregação) também considere os impactos à privacidade dos titulares; 
 Os processos de segurança sejam aplicados de forma proporcional à 
sensibilidade e ao risco dos dados; 
 A governança de segurança esteja alinhada com os controles de privacidade, 
especialmente no tratamento de dados pessoais e sensíveis, conforme 
previsto na LGPD e na ISO/IEC 27701. 
5.2. Controle de acesso 
A Health Labs adota uma política de controle de acesso baseado no princípio do 
menor privilégio e na necessidade de saber (ISO/IEC 27001, A.8), observando os seguintes 
critérios: 
 Autenticação forte para todos os sistemas e bases de dados com informações 
sensíveis; 
 Gestão de Identidades e Acessos (IAM) centralizada, com revisão periódica 
de perfis e permissões; 
 Segregação de funções, evitando conflitosde interesse ou acessos indevidos; 
 Revogação imediata de acessos em casos de desligamento ou mudança de 
função; 
 Auditoria de acessos, com registros (logs) de ações críticas em sistemas que 
tratam dados pessoais e clínicos. 
Mitigação de Riscos de Engenharia Social: 
A Health Labs reconhece que ataques de engenharia social, tais como phishing, 
pretexting, baiting e vishing, frequentemente visam a obter credenciais de acesso ou 
convencer usuários a realizar ações não autorizadas. Para mitigar esse tipo de ameaça: 
 Nenhum colaborador deve compartilhar credenciais ou senhas, 
independentemente da aparente legitimidade do solicitante (inclusive se for 
apresentado como membro da TI, gestor ou auditor); 
 Procedimentos claros são estabelecidos para verificação de identidade em 
pedidos de redefinição de senha ou concessão de acesso; 
 Mensagens suspeitas ou tentativas de manipulação devem ser relatadas 
imediatamente à Equipe de Segurança da Informação; 
 É realizado treinamento contínuo sobre técnicas de engenharia social e como 
reconhecê-las; 
 Simulações periódicas de ataques (ex.: campanhas de phishing awareness) 
são conduzidas para avaliar a resiliência dos usuários; 
 Os sistemas críticos contam com restrições baseadas em geolocalização, 
horário de uso e dispositivos confiáveis, reduzindo a efetividade de 
credenciais eventualmente comprometidas. 
Revisão de Acessos: 
 Os acessos são revisados periodicamente (pelo menos semestralmente) para 
garantir que estejam adequados ao perfil do usuário; 
 Os logs de acesso são monitorados quanto a padrões anômalos que possam 
indicar compromissos por engenharia social; 
 Tentativas de acesso fora dos padrões normais (ex.: em horários incomuns, 
de locais não reconhecidos ou após tentativas de phishing relatadas) são 
tratadas com prioridade pela equipe de segurança. 
5.3. Criptografia 
Com base na ISO/IEC 27001 (A.9), a Health Labs estabelece diretrizes para o uso 
de criptografia na proteção de dados sensíveis: 
 Dados em trânsito (entre sistemas, APIs, dispositivos médicos, ambientes de 
nuvem etc.) devem ser protegidos por protocolos criptográficos atualizados, 
como TLS 1.2+ ou VPN com autenticação forte; 
 Dados em repouso (armazenados em bancos de dados, servidores, 
dispositivos móveis ou backups) devem ser criptografados com algoritmos 
robustos (ex.: AES-256), principalmente se contiverem dados pessoais ou 
sensíveis; 
 As chaves criptográficas devem ser gerenciadas de forma segura, com 
controle de acesso, rotação periódica e políticas de recuperação; 
 O uso de criptografia deve estar documentado nos inventários de ativos e 
sistemas e ser avaliado periodicamente quanto à sua eficácia e conformidade. 
5.4. Princípios de Privacidade 
A Health Labs adota uma política robusta de privacidade de dados, em 
conformidade com a ISO/IEC 27701 e a LGPD, respeitando os seguintes princípios: 
 Transparência: os titulares de dados devem ser informados, de forma clara e 
acessível, sobre como seus dados são coletados, usados, compartilhados e 
armazenados, por meio de avisos de privacidade e termos de uso. 
 Limitação de Finalidade: os dados são utilizados apenas para os fins 
previamente informados e consentidos, sem desvios de uso que 
comprometam os direitos dos titulares. 
 Minimização de Dados: são tratados apenas os dados estritamente 
necessários para a realização das finalidades definidas. 
 Exatidão: os dados devem ser mantidos corretos, atualizados e pertinentes, 
com mecanismos para retificação e atualização pelos próprios titulares. 
 Acesso e Direitos dos Titulares: os titulares têm direito de acesso, retificação, 
exclusão, portabilidade, entre outros, e podem exercer esses direitos por 
canais específicos definidos pela empresa. 
 Responsabilidade e Prestação de Contas: a Health Labs mantém evidências 
de conformidade com as obrigações legais e regulatórias relacionadas à 
privacidade, por meio de políticas, registros, auditorias e treinamentos 
contínuos (ISO/IEC 27701, 6.8–6.10). 
5.5. Privacidade por Design e por Padrão 
Conforme a ISO/IEC 27701 (6.6), a Health Labs implementa o conceito de 
privacidade por design e por padrão (Privacy by Design & by Default) em seus processos, 
sistemas e produtos tecnológicos: 
 Desde o início de cada projeto (ex.: nova funcionalidade em prontuário 
eletrônico, novo sistema de agendamento ou módulo de telemedicina), a 
privacidade deve ser considerada como um requisito fundamental; 
 Requisitos de privacidade devem ser documentados nas fases de análise, 
design, desenvolvimento, testes e implantação de sistemas; 
 Configurações padrão dos sistemas devem favorecer a privacidade do titular 
(ex.: compartilhamento desativado por padrão, dados mínimos exigidos em 
formulários, anonimização automática de registros inativos); 
 Devem ser realizados Privacy Impact Assessments (PIA) ou avaliações de 
risco à privacidade sempre que houver alterações significativas no tratamento 
de dados pessoais. 
6. Gestão de riscos e conformidade 
A Health Labs adota uma abordagem proativa e contínua de identificação, avaliação, 
tratamento e monitoramento de riscos relacionados ao uso de dados, assegurando a 
conformidade com legislações aplicáveis, como a LGPD e a GDPR, e com os próprios 
requisitos internos de segurança e privacidade. 
Essa abordagem permite não apenas minimizar exposições a ameaças e 
vulnerabilidades, mas também garantir a integridade da operação e a confiança de clientes, 
parceiros e usuários. 
6.1. Avaliação contínua de riscos 
Com base na ISO/IEC 27001 (6.1.2) e na ISO/IEC 27701 (6.11), a Health Labs 
estabelece um processo sistemático de gestão de riscos que inclui: 
 Identificação de riscos associados à confidencialidade, integridade e 
disponibilidade dos dados, bem como ao tratamento de dados pessoais e 
sensíveis; 
 Análise e avaliação de riscos, considerando ameaças, vulnerabilidades, 
impactos e probabilidade de ocorrência, com foco em dados utilizados em 
sistemas como prontuários eletrônicos, agendamento online, telemedicina e 
análise preditiva; 
 Priorização dos riscos com base em critérios definidos (ex.: matriz de risco); 
 Definição de controles de mitigação, aceitação, transferência ou eliminação 
dos riscos; 
 Monitoramento contínuo do ambiente, com revisões periódicas e reavaliações 
sempre que houver mudanças significativas em sistemas, processos ou 
legislações. 
Avaliações de Impacto à Proteção de Dados (DPIAs) 
Nos casos de tratamento de dados pessoais identificáveis (PII) que possam 
representar alto risco aos direitos e liberdades dos titulares, são realizados Data Protection 
Impact Assessments (DPIAs), com base na ISO/IEC 27701: 
 O DPIA deve identificar: 
o A finalidade do tratamento; 
o Os tipos de dados envolvidos; 
o Os riscos à privacidade dos titulares; 
o As salvaguardas técnicas e organizacionais adotadas; 
 O resultado do DPIA deve ser documentado e aprovado pelo Comitê de 
Governança de Dados e, se necessário, submetido à Autoridade Nacional de 
Proteção de Dados (ANPD). 
6.2. Monitoramento e auditoria da conformidade 
A Health Labs estabelece mecanismos para monitorar e auditar a conformidade com 
as leis, normas e políticas internas relativas à governança, segurança e privacidade dos 
dados: 
 Auditorias internas regulares são realizadas para verificar a aderência aos 
controles de segurança (ISO/IEC 27001) e às práticas de proteção de dados 
pessoais (ISO/IEC 27701); 
 Revisões de conformidade legal garantem a aderência contínua à LGPD, 
GDPR e demais legislações relevantes; 
 Monitoramento automatizado dos sistemas e registros de logs, alertas de 
segurança, uso de dados e acesso a informações sensíveis; 
 Indicadores de conformidade e relatórios periódicos são apresentados ao 
Comitê de Governança de Dados e à alta direção; 
 Treinamentos e campanhas de conscientização são promovidoscontinuamente para manter a cultura de conformidade entre colaboradores, 
parceiros e terceiros. 
6.3. Tratamento de não conformidades 
A Health Labs mantém um processo estruturado para o tratamento de não 
conformidades identificadas em auditorias, testes, denúncias, incidentes de segurança ou 
falhas operacionais: 
1. Registro da não conformidade com data, descrição, origem e responsável; 
2. Análise da causa raiz para identificar fatores contribuintes e recorrência; 
3. Avaliação dos impactos à segurança da informação, privacidade dos titulares 
e obrigações legais; 
4. Definição e implementação de ações corretivas e preventivas, com prazos e 
responsáveis definidos; 
5. Acompanhamento e verificação da eficácia das ações tomadas; 
6. Comunicação às partes interessadas, inclusive aos titulares e autoridades 
competentes, nos casos legalmente exigidos. 
Além disso, a empresa possui um canal interno de denúncias que pode ser utilizado 
de forma confidencial para comunicar suspeitas de violações à política de governança de 
dados. 
7. Resposta a incidentes de segurança e privacidade 
A Health Labs estabelece políticas e procedimentos claros para detecção, resposta 
e recuperação diante de incidentes de segurança da informação e violações de dados 
pessoais, com o objetivo de: 
 Minimizar impactos operacionais, legais e reputacionais; 
 Restaurar a normalidade dos serviços de forma segura e eficaz; 
 Cumprir obrigações legais e regulatórias, especialmente no que se refere à 
notificação de incidentes às autoridades competentes e aos titulares de 
dados. 
Esses procedimentos são parte integrante do Sistema de Gestão de Segurança da 
Informação (SGSI) e do Programa de Privacidade da empresa. 
Dado o seu perfil de atuação no setor de saúde e o tratamento de dados pessoais 
sensíveis, a Health Labs é um alvo recorrente de ataques de engenharia social, como 
phishing, vishing e manipulações baseadas em engenharia comportamental. Esses 
ataques representam uma ameaça crítica, exigindo atenção especializada e protocolos 
específicos de resposta. 
7.1. Política de resposta a incidentes 
A política de resposta a incidentes da Health Labs estabelece que: 
 Todos os incidentes relacionados à segurança da informação, acesso 
indevido, vazamento de dados ou suspeita de violação de privacidade devem 
ser reportados imediatamente aos canais definidos (ex: Service Desk, DPO 
ou equipe de segurança); 
 Um time de resposta a incidentes (IRT – Incident Response Team) é 
responsável por avaliar, conter, investigar, mitigar e registrar os eventos; 
 Incidentes decorrentes de engenharia social são tratados como prioridade 
alta, mesmo na ausência de evidências técnicas iniciais, dada a natureza 
dissimulada desses ataques; 
 Todos os incidentes devem ser documentados, analisados e classificados de 
acordo com sua criticidade, abrangência e impacto sobre os dados pessoais, 
operacionais ou regulatórios. 
7.2. Detecção e registro de incidentes 
A detecção de incidentes pode ocorrer por diversas fontes: 
 Sistemas de monitoramento automatizado (SIEM, DLP, antivírus etc.); 
 Alertas de comportamento anômalo em sistemas e usuários; 
 Denúncias internas ou notificações de terceiros (clientes, parceiros, órgãos 
reguladores); 
 Comportamentos suspeitos induzidos por tentativas de engenharia social, 
como: 
o Solicitação de credenciais por e-mail ou telefone; 
o Falsas instruções vindas de “executivos”; 
o Envio de documentos maliciosos com aparência legítima. 
A Health Labs mantém mecanismos técnicos e organizacionais para a identificação 
precoce de incidentes que possam comprometer a confidencialidade, integridade ou 
disponibilidade de dados, ou ainda violar direitos dos titulares. Entre esses mecanismos 
estão: 
 Monitoramento contínuo de sistemas e redes, com detecção automatizada de 
eventos suspeitos (ex.: acessos não autorizados, uso anômalo de dados, 
falhas de segurança); 
 Canal de comunicação interna para que colaboradores relatem falhas, 
comportamentos incomuns ou vazamentos suspeitos; 
 Registro centralizado de incidentes, com dados como data/hora, descrição do 
evento, sistemas impactados, dados comprometidos e ações iniciais. 
Todos os incidentes registrados são analisados conforme sua gravidade e possível 
impacto à segurança da informação e à privacidade dos dados pessoais. 
7.3. Classificação e análise de impacto 
Os incidentes são classificados de acordo com sua criticidade, considerando: 
 Natureza e volume dos dados afetados (especial atenção a dados pessoais e 
sensíveis); 
 Número de titulares impactados; 
 Riscos à integridade física ou moral dos indivíduos; 
 Dano à reputação institucional ou impacto regulatório; 
 Violação de obrigações contratuais ou legais. 
Nos casos que envolvam dados pessoais identificáveis (PII), especialmente os de 
saúde, é conduzida uma avaliação de impacto à privacidade para orientar a resposta 
adequada, conforme diretrizes da ISO/IEC 27701 (6.13). 
7.4. Resposta e contenção 
Ao identificar um incidente, a Health Labs executa procedimentos de resposta 
coordenados pelo Comitê de Resposta a Incidentes, que atua com base nos seguintes 
princípios: 
 Isolamento e contenção do incidente para evitar propagação; 
 Preservação de evidências técnicas para fins de auditoria e investigação; 
 Notificação imediata às equipes técnicas, jurídicas e de privacidade; 
 Engajamento dos responsáveis pelos dados e pelas aplicações afetadas, com 
definição de plano de ação emergencial. 
Após a detecção do incidente, o processo de resposta envolve: 
1. Contenção inicial para evitar a propagação ou agravamento do impacto; 
2. Análise forense e técnica, incluindo a investigação de vetores de ataque 
utilizados, especialmente quando envolverem engenharia social que explore 
fragilidades humanas; 
3. Erradicação e recuperação, com aplicação de medidas corretivas (ex: 
redefinição de senhas, atualização de sistemas, revogação de acessos, 
correção de falhas); 
4. Documentação completa do incidente, incluindo causas, impactos, medidas 
adotadas e recomendações. 
Para casos de engenharia social, a análise também abrange: 
 Avaliação do comportamento do colaborador afetado; 
 Identificação de falhas nos treinamentos ou processos que permitiram o 
ataque; 
 Adoção de medidas educativas, disciplinares ou reforço de controles, 
conforme a gravidade. 
7.5. Recuperação e lições aprendidas 
Após a contenção inicial, são adotadas medidas para: 
 Restaurar os dados e serviços afetados, com base em planos de continuidade 
e recuperação (BCP/DRP); 
 Analisar a causa raiz do incidente para evitar recorrência; 
 Revisar os controles e procedimentos envolvidos no evento; 
 Documentar o incidente e suas respectivas ações corretivas e preventivas. 
Relatórios pós-incidente são elaborados e apresentados ao Comitê de Governança 
de Dados e à Alta Direção. 
7.6. Notificação de incidentes 
Nos casos de incidentes que envolvam dados pessoais e que possam acarretar 
riscos significativos aos direitos e liberdades dos titulares, a Health Labs cumpre as 
obrigações legais de notificação, conforme exige a LGPD e alinhado à ISO/IEC 27701: 
 À Autoridade Nacional de Proteção de Dados (ANPD), contendo: descrição 
da natureza dos dados afetados, titulares envolvidos, medidas adotadas e 
riscos associados; 
 Aos titulares de dados afetados, de forma clara, objetiva e tempestiva, com 
informações sobre o ocorrido e orientações para mitigação de possíveis 
danos; 
 A terceiros contratados ou parceiros, nos casos em que o incidente impacte 
dados compartilhados ou tratados por operadores externos. 
A decisão de notificar é baseada em avaliação de risco, com o suporte da equipe de 
privacidade e jurídica. 
7.7. Treinamentos e simulações 
Para garantir a eficácia da resposta a incidentes: 
 São realizados treinamentos periódicos com as equipes envolvidas, incluindoprofissionais de TI, segurança, jurídico, privacidade e negócios; 
 A empresa realiza simulações e testes de incidentes, com base em cenários 
reais (ex: vazamento de prontuário eletrônico, sequestro de base de dados 
via ransomware, acesso indevido a dados de pacientes); 
 As lições aprendidas são incorporadas à melhoria contínua do plano de 
resposta. 
8. Conscientização e treinamento 
A Health Labs reconhece que a efetividade da governança de dados depende 
fortemente da capacitação e do engajamento das pessoas. Por isso, adota uma abordagem 
estruturada para a conscientização e o treinamento contínuo de todos os envolvidos no 
tratamento de dados, incluindo colaboradores, prestadores de serviço, estagiários e 
terceiros autorizados. 
Essas ações visam a fortalecer a cultura organizacional de proteção de dados, 
garantir o entendimento das políticas e práticas internas e reduzir os riscos relacionados a 
erros humanos, vazamentos acidentais ou uso indevido de informações. 
8.1. Requisitos gerais 
Conforme a ISO/IEC 27001 (A.6.2), todos os funcionários e partes externas 
relevantes devem receber treinamento apropriado e regular em segurança da informação, 
privacidade e governança de dados, de acordo com suas funções e níveis de acesso. 
A Health Labs define os seguintes requisitos: 
 Treinamento obrigatório de integração para todos os novos colaboradores e 
terceiros com acesso a dados; 
 Capacitação contínua anual sobre: 
o Políticas de governança de dados; 
o Classificação e tratamento de dados sensíveis; 
o Princípios da LGPD e GDPR; 
o Práticas seguras de manuseio de dados (inclusive em ambientes 
digitais e remotos); 
o Procedimentos de resposta a incidentes; 
 Reciclagens em caso de mudanças regulatórias, tecnológicas ou 
organizacionais relevantes; 
 Registros formais da participação em treinamentos, com evidências de 
conclusão. 
8.2. Conteúdo dos programas de conscientização 
Os programas de treinamento são elaborados para atender diferentes perfis 
profissionais da organização e incluem: 
 Fundamentos da governança de dados e seu papel estratégico na Health 
Labs; 
 Conceitos de dados pessoais e dados sensíveis, com exemplos aplicados ao 
contexto de saúde; 
 Princípios de privacidade por design e por padrão; 
 Classificação da informação e medidas de proteção correspondentes; 
 Uso seguro de sistemas e plataformas, com foco em acesso, 
compartilhamento e descarte de dados; 
 Responsabilidades individuais e canais de denúncia de não conformidades; 
 Simulações de incidentes, como vazamentos ou acessos indevidos, com 
orientações práticas de resposta. 
8.2.1. Ênfase em Engenharia Social 
Dada a frequência e sofisticação crescente de ataques de engenharia social 
direcionados à Health Labs, os programas de conscientização incluem módulos 
específicos para identificação, prevenção e resposta a esse tipo de ameaça, abordando: 
 Reconhecimento de e-mails e mensagens suspeitas (phishing, spear 
phishing); 
 Técnicas de manipulação psicológica (pretexting, vishing, engenharia de 
autoridade); 
 Cuidados em ligações telefônicas, interações por aplicativos e redes sociais; 
 Boas práticas para proteger credenciais de acesso e evitar exposição 
indevida; 
 Procedimentos para relatar imediatamente situações suspeitas ou 
confirmadas; 
 Estudos de caso reais e simulações internas para reforçar o aprendizado 
prático. 
Os colaboradores são orientados a nunca fornecer informações confidenciais ou 
executar ações solicitadas sem validação formal, mesmo quando a solicitação aparenta vir 
de um superior hierárquico ou da equipe de TI. 
8.3. Públicos-alvo específicos 
Para garantir a efetividade das ações, os treinamentos são adaptados de acordo com 
o perfil dos participantes: 
 Colaboradores operacionais: foco em boas práticas no uso de sistemas, 
manuseio de dados de pacientes e proteção de credenciais; 
 Equipes técnicas (TI, desenvolvimento): ênfase em privacidade por design, 
criptografia, controles de acesso e testes de segurança; 
 Gestores e líderes de processo: reforço das responsabilidades legais, 
classificação de dados e governança de riscos; 
 Terceiros, parceiros e prestadores: entendimento dos requisitos contratuais 
relacionados à proteção e confidencialidade dos dados. 
8.4. Avaliação e melhoria contínua 
A eficácia dos programas de conscientização e treinamento é continuamente 
avaliada por meio de: 
 Pesquisas de percepção e testes de retenção de conhecimento; 
 Métricas de engajamento, como taxa de participação, conclusão e feedback 
dos participantes; 
 Resultados de testes de conhecimento e simulações (phishing tests); 
 Auditorias e verificações amostrais para confirmar a aplicação prática dos 
conhecimentos; 
 Revisões periódicas dos conteúdos com base em novas ameaças, lições 
aprendidas e atualizações regulatórias. 
9. Medição e melhoria contínua 
A Health Labs está comprometida com a eficácia, relevância e atualização 
permanente de sua política de governança de dados. Para isso, estabelece mecanismos 
formais de medição de desempenho, revisão periódica e melhoria contínua, assegurando 
que os controles, processos e práticas estejam alinhados com os objetivos estratégicos da 
organização e com as exigências legais e regulatórias aplicáveis. 
9.1. Indicadores de desempenho 
São definidos Indicadores-Chave de Desempenho (KPIs) e Métricas de Controle 
para mensurar a eficácia da governança de dados nas seguintes dimensões: 
Dimensão Indicadores Exemplares 
Conformidade 
% de conformidade com políticas de classificação de dados; 
número de não conformidades registradas em auditorias. 
Segurança e 
Privacidade 
Número de incidentes de segurança com impacto em dados; 
tempo médio de resposta a incidentes; % de dados pessoais 
tratados com base legal adequada. 
Qualidade dos 
Dados 
Taxa de dados inconsistentes ou incompletos identificados; tempo 
médio de correção de erros; % de sistemas com validações 
automáticas de dados. 
Engajamento 
Taxa de conclusão de treinamentos obrigatórios; número de 
contribuições/sugestões de melhoria enviadas por colaboradores. 
Gestão de Ciclo 
de Vida 
% de dados armazenados com plano de retenção definido; % de 
dados descartados conforme política. 
 
Essas métricas são monitoradas trimestralmente pela Equipe de Governança de 
Dados e reportadas ao Comitê de Governança de Dados e à Alta Direção. 
9.2. Revisões periódicas 
A Política de Governança de Dados é revista, no mínimo, anualmente ou sempre que 
ocorrerem mudanças significativas no ambiente interno ou externo da organização, tais 
como: 
 Alterações nas leis e regulamentos aplicáveis (ex.: atualizações da LGPD, 
GDPR, resoluções setoriais da saúde); 
 Introdução de novas tecnologias ou sistemas (ex.: plataformas de inteligência 
artificial, soluções em nuvem); 
 Mudanças relevantes no modelo de negócio ou processos organizacionais; 
 Resultados de auditorias internas ou externas, análises de risco ou 
investigações de incidentes; 
 Sugestões de melhoria propostas por colaboradores ou partes interessadas. 
As revisões envolvem representantes das áreas de TI, segurança, privacidade, 
jurídico e negócio, garantindo uma abordagem multidisciplinar e alinhada aos princípios da 
melhoria contínua (PDCA). 
9.3. Processo de melhoria contínua 
A Health Labs adota um ciclo sistemático de melhoria baseado na metodologia 
PDCA (Planejar – Executar – Verificar – Agir), conforme preconizado pela ISO/IEC 27001: 
1. Planejar: Definição de metas de desempenho e revisão de políticas e 
controles existentes; 
2. Executar: Implementação das melhorias planejadas e atualização dos 
documentos e processos; 
3. Verificar: Avaliação dos resultados com base nas métricas definidas e na 
análise de feedbacks; 
4. Agir: Correção de desvios, reforço de boas práticas e disseminação das lições 
aprendidas. 
Além disso, são mantidos registrosdas ações corretivas, preventivas e de melhoria 
tomadas, permitindo rastreabilidade e avaliação de impacto ao longo do tempo. 
9.4. Cultura de melhoria colaborativa 
A Health Labs incentiva uma cultura de melhoria colaborativa, na qual colaboradores 
e parceiros são convidados a: 
 Reportar inconsistências, ineficiências ou riscos percebidos relacionados ao 
uso de dados; 
 Sugerir melhorias de processos, controles ou treinamentos; 
 Participar ativamente de fóruns e iniciativas de governança. 
As sugestões são avaliadas pela equipe de governança de dados e, quando 
pertinentes, incorporadas aos planos de ação e revisões futuras da política. 
 
TESTE DE PERFORMANCE – TP4 
Parte 1 
Você deverá estudar e descrever os princípios psicológicos por trás das 
técnicas de engenharia social (phishing, spear-phishing, vishing, spoofing, 
squat etc.) e explicar como esses métodos são utilizados para enganar alvos 
e coletar dados. 
Importante destacar a importância do uso ético dessas técnicas em contextos 
controlados, como testes de segurança em organizações. 
Em seguida, você deverá aplicar ferramentas de OSINT para coletar e analisar 
informações sensíveis de empresas e indivíduos (nome, preferências, 
conexões sociais, dados expostos). Além disso, você deve analisar como 
esses dados poderiam ser explorados em ataques de engenharia social e 
fornecer um relatório detalhado que identifique os dados potencialmente 
comprometedores. 
As técnicas de engenharia social baseiam-se em princípios psicológicos 
profundamente enraizados no comportamento humano, explorando vulnerabilidades 
cognitivas, emocionais e sociais para manipular indivíduos e obter acesso a informações 
ou sistemas restritos. Entre os principais princípios psicológicos explorados estão a 
autoridade, a escassez, o medo, a urgência, a curiosidade, a confiança e o conformismo 
social. Essas técnicas não dependem de falhas técnicas em sistemas, mas sim da 
tendência humana a confiar, agir por impulso ou ceder à pressão de contextos artificiais 
cuidadosamente construídos. 
No phishing, por exemplo, os atacantes enviam e-mails genéricos que simulam 
comunicações legítimas, geralmente de instituições financeiras, plataformas conhecidas ou 
departamentos internos de uma empresa. A intenção é criar um senso de urgência e induzir 
a vítima a clicar em um link malicioso ou fornecer credenciais. Spear-phishing, por sua vez, 
é uma versão mais sofisticada e direcionada, baseada na coleta prévia de informações 
específicas sobre a vítima – como nome, cargo, relações profissionais e preferências – que 
tornam o ataque mais crível. Essa personalização reforça a confiança da vítima na 
veracidade da mensagem, aumentando a chance de sucesso. 
No caso de vishing (voice phishing), os criminosos utilizam ligações telefônicas como 
meio de ataque, explorando o tom de voz autoritário ou empático para persuadir a vítima a 
compartilhar dados sensíveis. Já o spoofing se refere à falsificação de identidade, seja por 
e-mail, telefone ou sites, em que o atacante simula um remetente confiável ou uma 
identidade visual legítima para enganar a vítima. Técnicas como typosquatting ou URL 
squat também são comuns: o atacante registra domínios com grafias semelhantes aos de 
empresas reais, esperando que usuários desatentos acessem essas páginas e insiram 
dados confidenciais. 
O uso dessas técnicas deve ser estritamente ético e regulado, aplicando-se 
unicamente em cenários controlados, como testes de intrusão (red teaming) realizados por 
profissionais de segurança da informação com autorização prévia da organização. O 
objetivo nesses testes é identificar vulnerabilidades humanas e propor medidas de 
conscientização e mitigação, sem causar danos reais. 
Para coletar e analisar informações sensíveis de empresas ou indivíduos, 
profissionais de segurança usam ferramentas de OSINT (Open Source Intelligence), que 
permitem a extração legal de dados publicamente disponíveis. Ferramentas como Maltego, 
theHarvester, SpiderFoot, Recon-ng, Shodan, Google Dorks e Have I Been Pwned são 
amplamente utilizadas nesse processo. Elas permitem mapear nomes de colaboradores, 
e-mails, domínios associados, relacionamentos em redes sociais, dados vazados em 
breaches, preferências declaradas em postagens públicas, infraestrutura digital exposta 
(como servidores, câmeras, roteadores) e muito mais. 
Um atacante mal-intencionado, ao analisar essas informações, poderia, por 
exemplo, descobrir que um diretor de TI frequentemente comenta sobre tecnologia em 
fóruns online, usa a mesma senha há anos e já teve dados vazados em violações 
anteriores. Ele também poderia identificar que determinado funcionário compartilha fotos 
do ambiente de trabalho no LinkedIn, revelando detalhes do layout do escritório, nomes de 
colegas e uso de tecnologias específicas. Com base nesses dados, seria possível criar um 
ataque de spear-phishing muito convincente – como um e-mail que parece vir do setor de 
RH solicitando a atualização de senhas em um sistema interno –, levando a vítima a 
entregar credenciais de acesso. 
A análise desses dados, quando feita em ambientes corporativos como parte de 
testes de segurança, permite gerar relatórios detalhados que apontam os dados 
potencialmente comprometedores. Um relatório eficaz indicaria, por exemplo, a exposição 
de e-mails institucionais em vazamentos, a facilidade de mapear a hierarquia da empresa 
via LinkedIn, o uso de domínios secundários vulneráveis ou abandonados, e a presença de 
endpoints expostos na internet sem autenticação adequada. A partir disso, recomenda-se 
a implementação de medidas de proteção, como campanhas de conscientização, 
configuração de filtros de e-mail mais rigorosos, adoção de autenticação multifator e 
controle da superfície de exposição digital da organização. 
 
Parte 2 
Você deverá propor soluções de proteção de dados, utilizando metodologias 
de anonimização, ofuscação de dados e outras estratégias de mitigação de 
vulnerabilidades. 
Para tal, você deve desenvolver e descrever um plano para garantir a proteção 
de dados em movimento e em repouso, assegurando que informações 
sensíveis sejam devidamente protegidas durante o compartilhamento e 
implementar e testar controles de proteção de dados que garantam a 
integridade, segurança e rastreabilidade das informações. 
Analise e assegure que as soluções propostas estejam em conformidade com 
as regulamentações de proteção de dados, como LGPD e GDPR. 
Para garantir a proteção de dados em um ambiente corporativo ou organizacional, é 
fundamental adotar uma abordagem abrangente que envolva metodologias de 
anonimização, ofuscação e demais estratégias de mitigação de vulnerabilidades, tanto para 
dados em repouso quanto em movimento. Um plano robusto de proteção deve considerar 
aspectos técnicos, organizacionais e legais, assegurando a confidencialidade, integridade 
e rastreabilidade das informações sensíveis, conforme exigido por regulamentações como 
a LGPD (Lei Geral de Proteção de Dados do Brasil) e o GDPR (Regulamento Geral de 
Proteção de Dados da União Europeia). 
A primeira etapa consiste em classificar os dados conforme seu nível de 
sensibilidade e contexto de uso. Informações pessoais identificáveis (PII), dados 
financeiros, registros de saúde e segredos comerciais devem ser tratados como de alta 
criticidade. Com base nessa classificação, são definidas políticas específicas para cada tipo 
de dado. Para os dados em repouso, recomenda-se o uso de criptografia forte, como AES-
256, aplicada tanto em bancos de dados quanto em backups e arquivos armazenados 
localmente ou em nuvem. A gestão das chaves criptográficas deve ser feita com soluções 
seguras e segregadas, utilizando módulos de segurança de hardware (HSM) quando 
possível, para evitar acessos não autorizados. 
A anonimização dos dados, especialmente no caso de conjuntos utilizados para 
análises estatísticasou desenvolvimento de modelos de machine learning, é uma técnica 
eficaz para preservar a privacidade sem comprometer a utilidade da informação. Devem 
ser utilizadas metodologias como k-anonymity, l-diversity ou differential privacy, 
dependendo do contexto, assegurando que os dados anonimizados não possam ser 
revertidos ou reidentificados. Em situações nas quais a anonimização completa não é 
viável, pode-se aplicar técnicas de ofuscação, como mascaramento de dados, truncamento 
de campos e substituição de valores reais por fictícios, especialmente em ambientes de 
desenvolvimento, testes ou demonstração. 
Para dados em movimento, o uso de protocolos seguros de comunicação, como TLS 
1.3, é essencial para proteger as informações enquanto trafegam por redes internas ou 
externas. Sistemas de e-mail corporativo e plataformas de compartilhamento devem adotar 
criptografia de ponta a ponta e autenticação multifator para reduzir o risco de 
interceptações. Além disso, soluções de DLP (Data Loss Prevention) devem ser 
implementadas para monitorar, controlar e registrar tentativas de extração não autorizada 
de dados, garantindo a rastreabilidade das ações. 
A implementação de controles de acesso baseados em princípios de privilégio 
mínimo e separação de funções reforça a integridade e segurança das informações. Cada 
usuário deve ter acesso apenas aos dados estritamente necessários para suas atividades, 
com registros detalhados (logs) de todas as operações realizadas. Esses registros devem 
ser protegidos contra adulteração e auditáveis, servindo como base para investigações e 
para garantir a responsabilização em caso de incidentes. 
Outro aspecto fundamental é a realização periódica de testes de segurança, como 
análises de vulnerabilidades e testes de intrusão (pentests), para verificar a eficácia dos 
controles implementados. Essas ações devem ser acompanhadas de avaliações de 
impacto à proteção de dados (DPIA – Data Protection Impact Assessment), especialmente 
quando novos sistemas são implementados ou quando dados sensíveis serão tratados em 
larga escala. Tais avaliações são exigidas tanto pela LGPD quanto pelo GDPR e devem 
documentar os riscos identificados e as medidas adotadas para mitigá-los. 
Do ponto de vista legal e regulatório, todas as práticas adotadas devem ser 
registradas em políticas internas de privacidade e segurança da informação, as quais 
devem ser comunicadas e aplicadas a todos os colaboradores. É necessário manter um 
programa contínuo de conscientização e treinamento, assegurando que todos 
compreendam suas responsabilidades no tratamento de dados pessoais. 
Em suma, a proteção eficaz dos dados requer um plano integrado que envolva 
anonimização e ofuscação nos momentos apropriados, criptografia robusta para dados em 
repouso e em trânsito, mecanismos de controle de acesso e rastreamento, além da 
conformidade rigorosa com os preceitos legais da LGPD e do GDPR. 
Parte 3 
Você deverá realizar uma análise crítica nos controles de proteção de dados, 
analisando quais fatores, inclusive humanos, poderão ser utilizados por 
técnicas de Engenharia Social, com o objetivo de burlar estes controles e obter 
a coleta de dados. 
A eficácia dos controles de proteção de dados, mesmo quando baseados em 
tecnologias avançadas e políticas bem estruturadas, pode ser comprometida por fatores 
humanos e comportamentais, que são frequentemente explorados por técnicas de 
engenharia social. A análise crítica desses controles revela que, embora eles possam 
mitigar riscos técnicos, a vulnerabilidade humana permanece um dos elos mais frágeis da 
segurança da informação. Técnicas como phishing, pretexting, baiting e vishing utilizam 
elementos como persuasão, manipulação emocional e exploração da confiança para 
contornar barreiras técnicas e obter acesso não autorizado a dados. 
O primeiro ponto de fragilidade recai sobre a gestão de acessos. Embora muitas 
organizações implementem controles baseados no princípio do menor privilégio e 
autenticação multifator, essas barreiras podem ser subvertidas quando um usuário legítimo 
é induzido a compartilhar suas credenciais com um atacante que se passa por um técnico 
de suporte, gestor ou parceiro externo. A autoridade percebida da pessoa que faz a 
solicitação e o uso de situações de urgência – como alegações de incidentes graves, perda 
de acesso ou necessidade de manutenção imediata – são recursos clássicos utilizados 
para levar a vítima a ignorar os protocolos estabelecidos. 
Outro fator crítico é a familiaridade e rotina dos usuários em relação aos sistemas. 
Colaboradores que acessam diariamente plataformas sensíveis podem desenvolver uma 
falsa sensação de segurança e ceder a pedidos que aparentemente fazem parte de seus 
fluxos normais de trabalho. Isso é especialmente perigoso em ambientes onde as 
campanhas de conscientização são esporádicas ou genéricas, não abordando cenários 
realistas e atualizados. A engenharia social também explora a falta de validação rigorosa 
na comunicação interna. Em muitos casos, e-mails com domínios similares ou mensagens 
instantâneas com perfis clonados são suficientes para convencer usuários a compartilhar 
informações estratégicas ou executar ações que comprometem a segurança. 
Mesmo controles técnicos robustos, como criptografia, podem ser ineficazes se o 
atacante conseguir enganar um usuário para enviar documentos descriptografados ou com 
senhas fracas associadas. Além disso, o uso de mídias removíveis, links encurtados e 
dispositivos aparentemente inofensivos (como pendrives maliciosos) ainda encontra 
espaço em ambientes corporativos mal supervisionados, sendo um canal de entrada para 
coleta de dados ou instalação de malware. O compartilhamento excessivo de informações 
em redes sociais e plataformas profissionais também colabora com ataques 
personalizados, como spear-phishing, que aumentam exponencialmente as chances de 
sucesso por estarem contextualizados com dados reais sobre o alvo. 
Além dos fatores humanos, há aspectos organizacionais que podem facilitar a ação 
de engenheiros sociais. A falta de uma cultura de segurança sólida, com processos pouco 
claros sobre quem pode acessar o quê, ausência de canais seguros de verificação de 
identidade e negligência na revogação de acessos de ex-colaboradores ou terceirizados, 
expande significativamente a superfície de ataque. A engenharia social prospera em 
ambientes onde o fator humano é subestimado e onde há excesso de confiança entre 
colegas ou setores, sem validação de identidade ou registro de atividades críticas. 
Portanto, a análise crítica dos controles de proteção de dados deve considerar não 
apenas a eficácia técnica, mas também a resiliência humana e organizacional frente a 
manipulações. Controles técnicos não são suficientes por si só quando os usuários não são 
treinados, monitorados ou preparados para reconhecer e resistir a tentativas de 
manipulação. A mitigação dessa vulnerabilidade exige um esforço contínuo de 
conscientização contextualizada, políticas de segurança aplicadas com clareza e rigor, 
simulações regulares de ataques e, acima de tudo, uma cultura organizacional em que a 
segurança seja compreendida como responsabilidade de todos. Sem isso, os controles 
existentes tornam-se frágeis diante das sutilezas da engenharia social, que se aproveita 
justamente das brechas comportamentais para contornar as proteções mais sofisticadas. 
Cenário Prático Fictício 
Desenvolver um projeto prático que conecte a aplicação das técnicas de 
engenharia social para descoberta de dados com estratégias de proteção e 
mitigação desses ataques. Você será desafiado a entender o processo de 
coleta de dados por meio de técnicas de engenharia social e, em seguida, 
propor e implementar controles de proteção de dados, garantindo 
conformidade com regulamentações e uso ético da informação. 
A empresa fictícia “VaultX” é uma fintech de médiodo Componente 
Unidade de controle de porta de acesso 
à porta 
Trava de Porta 1 
Unidade de controle de porta de acesso 
à porta 
Trava de Porta 2 
Eletromiógrafo Banco de Dados Central de Crachás 
Computador pessoal Estação de Registro de Crachás 
Unidade Terminal Remota RTU 
Switch Serial Switch de Controle de Acesso 
Desconhecido Leitor de Crachás 
 
Zona – Sistema de Controle de Energia/Iluminação 
SAL Nível: Alto 
Tipo de Componente Nome do Componente 
Computador pessoal PC de Energia/Iluminação 
Controlador Lógico Programável PLC-22 
Switch Serial Switch de Energia/Iluminação 
 
Zona – Sistema de Controle de Elevador – Moderado 
SAL Nível: Moderado 
Tipo de Componente Nome do Componente 
Controlador Lógico Programável PLC 
 
Zona – Sistema Instrumentado de Segurança 
SAL Nível: Alto 
Tipo de Componente Nome do Componente 
Sistema Instrumentado de Segurança 
(SIS) 
SIS de Supressão de Incêndio 
Desconhecido Botão de Puxar 
Desconhecido Alarme de Fumaça 
 
Zona – Sem Zona Atribuída 
SAL Nível: (Não especificado para a zona em si) 
Tipo de Componente Nome do Componente 
Conector CON-28 
Conector CON-48 
Conector CON-48 
Firewall Firewall de Controle de Acesso 
Firewall Firewall de Câmera 
Firewall Firewall de Elevador 
Firewall Firewall de Supressão de Incêndio 
Firewall Firewall Principal 
Firewall Firewall de Energia/Iluminação 
Sistema de Detecção de Intrusão (IDS) IDS de Controle de Acesso 
Sistema de Detecção de Intrusão (IDS) IDS de Câmera 
Sistema de Detecção de Intrusão (IDS) IDS de Elevador 
Sistema de Detecção de Intrusão (IDS) IDS de Supressão de Incêndio 
Sistema de Detecção de Intrusão (IDS) IDS Principal 
Sistema de Detecção de Intrusão (IDS) IDS de Energia/Iluminação 
Switch Serial Switch(es) 
Web Web 
 
Análise de Ameaças Cibernéticas e Vulnerabilidades – Health Labs 
1. Introdução 
A Health Labs, uma empresa líder no setor de pesquisa e diagnóstico em saúde, lida 
com um volume massivo de dados sensíveis de pacientes, incluindo informações de saúde 
protegidas (PHI - Protected Health Information), histórico médico, resultados de exames e 
dados genéticos. A natureza crítica desses dados, combinada com a interconexão de seus 
sistemas, torna a segurança cibernética e a governança de dados pilares fundamentais 
para a continuidade dos negócios, a proteção da privacidade dos pacientes e a 
conformidade regulatória. 
Este relatório tem como objetivo apresentar uma análise aprofundada das ameaças 
cibernéticas e vulnerabilidades identificadas nos sistemas críticos da Health Labs, com um 
foco especial em como esses elementos impactam e são impactados pela governança de 
dados. A análise é fundamentada nas informações contidas nos documentos "Executive 
Summary", "Site Summary", "Site Detail Report" e "Site Cybersecurity Plan". 
2. Visão geral da Health Labs e seus sistemas críticos 
2.1. Visão geral 
A Health Labs opera em um ambiente de TI híbrido, combinando servidores on-
premise com serviços de nuvem, e possui laboratórios de diagnóstico interconectados. Sua 
missão central envolve a pesquisa e o diagnóstico, o que implica o processamento e 
armazenamento de dados altamente confidenciais. 
Os sistemas críticos da Health Labs, conforme detalhado nos documentos, incluem: 
 Sistemas de prontuários eletrônicos (EHR): essenciais para o registro e 
acesso ao histórico médico dos pacientes. 
 Sistemas de gerenciamento de informações laboratoriais (LIMS): cruciais para 
o processamento de resultados de exames e dados de diagnóstico. 
 Repositórios de dados de pesquisa: contêm dados genéticos e outras 
informações sensíveis utilizadas em estudos científicos. 
 Sistemas de faturamento: embora não diretamente relacionados à saúde, 
contêm informações financeiras e de identificação pessoal. 
 Redes de equipamentos de diagnóstico: a infraestrutura que suporta a 
operação dos equipamentos médicos. 
A integridade, confidencialidade e disponibilidade desses sistemas e dos dados que 
eles contêm são de suma importância. Qualquer comprometimento pode levar a sérias 
consequências, desde a interrupção das operações até violações de privacidade e multas 
regulatórias. 
2.2. Papeis e responsabilidades 
A definição clara dos papeis e responsabilidades é um pilar fundamental para 
qualquer programa de cibersegurança eficaz. No contexto da Health Labs, onde a proteção 
de dados sensíveis de pacientes é primordial, entender quem faz o quê garante a 
responsabilização e a execução coordenada das atividades de segurança. 
A seguir, são detalhados os principais papéis e suas respectivas responsabilidades: 
2.2.1. Gerência executiva 
A gerência executiva, que frequentemente inclui o Conselho de Diretores e o CEO, 
detém a responsabilidade final pela segurança da organização. No entanto, suas tarefas e 
a implementação efetiva são geralmente delegadas. 
2.2.2. Chief Security Officer (CSO) ou Chief Information Security Officer (CISO) 
O CSO ou CISO é um executivo sênior dentro da organização, responsável por 
estabelecer e manter a visão, estratégia e o programa corporativo para garantir que os 
ativos de informação sejam adequadamente protegidos. Este papel direciona a equipe na 
identificação, desenvolvimento, implementação e manutenção de processos em toda a 
organização para reduzir riscos de informação e tecnologia da informação (TI), responder 
a incidentes, estabelecer padrões e controles apropriados e direcionar o estabelecimento e 
a implementação de políticas e procedimentos. O CISO também é geralmente responsável 
pela conformidade relacionada à informação. 
As responsabilidades do CISO (ou CSO) tipicamente abrangem toda a organização 
e incluem: 
 Segurança da informação e garantia da informação. 
 Conformidade regulatória da informação (e.g., US PCI DSS, FISMA, GLBA, 
HIPAA; UK Data Protection Act 1998; Canada PIPEDA). Para a Health Labs, 
isso se estende à LGPD no Brasil. 
 Gestão de riscos da informação. 
 Gestão de riscos da cadeia de suprimentos. 
 Cibersegurança. 
 Controles de tecnologia da informação para sistemas financeiros e outros. 
 Privacidade da informação. 
 Computer Emergency Response Team / Computer Security Incident 
Response Team (CERT/CSIRT). 
 Gestão de identidade e acesso. 
 Arquitetura de segurança (e.g., Sherwood Applied Business Security 
Architecture). 
 Investigações de TI, perícia digital, eDiscovery. 
 Recuperação de desastres e gestão de continuidade de negócios. 
 Information Security Operations Center (ISOC). 
2.2.3. Comitê Diretor de Segurança 
Este comitê é composto por representantes de todas as partes interessadas na 
segurança de TI, incluindo membros do conselho executivo, CISO/CSO, gerência de TI, 
pessoal de segurança física, help desk e proprietários de ativos digitais e aplicações chave. 
O comitê se reúne regularmente (frequentemente trimestralmente) para revisar políticas e 
procedimentos, o progresso da implementação de controles de segurança e determinar a 
direção futura da segurança na empresa. 
 Suas responsabilidades incluem: 
 Definir o nível de risco aceitável para a organização. 
 Desenvolver objetivos e estratégias de segurança. 
 Determinar prioridades de iniciativas de segurança com base nas 
necessidades de negócio. 
 Revisar relatórios de avaliação de risco e auditoria. 
 Monitorar o impacto nos negócios dos riscos de segurança. 
 Revisar grandes violações e incidentes de segurança. 
 Aprovar qualquer mudança importante na política e no programa de 
segurança. 
É crucial que este comitê tenha uma visão clara e uma missão que apoie os objetivos 
de confidencialidade, integridade e disponibilidade em relação aos objetivos de negócio da 
organização. 
2.2.4. Proprietários de Sistemas (System Owners) 
O proprietário do sistema é responsável por um ou mais sistemas que podem conter 
e processar dados pertencentes a diferentes proprietários de dados. Ele é encarregado de 
integrarporte que fornece soluções de 
pagamentos digitais. Em 2024, a empresa inicia um projeto para expandir suas parcerias 
com outras startups. No entanto, um atacante (pentester ético ou cibercriminoso) decide 
realizar um teste de engenharia social para descobrir informações sensíveis prévias a um 
ataque direcionado. 
O atacante utiliza técnicas como phishing, spear-phishing, vishing, spoofing e 
typosquatting (squat) para atingir empregados e parceiros da VaultX. O objetivo é colher 
nomes, cargos, listas de e-mails, preferências e comportamentos, com foco especial em 
gestores de TI e de RH. 
Após o ataque simulado, a equipe de segurança da VaultX analisa as 
vulnerabilidades e propõe medidas de mitigação. 
 
1. Princípios psicológicos por trás das técnicas de engenharia social 
 Autoridade: pessoas tendem a obedecer a ordens de figuras percebidas como 
superiores ou especialistas. Exemplo: um e-mail falso do “CIO” solicitando 
urgência em atualizar um sistema. 
 Urgência/escassez: criar senso de pressão temporal (ex.: “responda em 10 
minutos ou terá a conta bloqueada”) reduz a racionalidade da vítima. 
 Reciprocidade: a vítima sente-se compelida a retribuir favores (“Enviamos um 
brinde, preencha aqui seus dados para recebê-lo”). 
 Afinidade/confiança: falsos contatos se passam por colegas ou parceiros 
próximos (“Vi seu LinkedIn, trabalhamos no mesmo lugar!”). 
 Curiosidade: promessas de novidades, promoções ou acessos exclusivos 
(“Veja as tendências do setor antes de todo mundo!”). 
 
2. Tipos de ataques exploram esses princípios 
 Phishing: disparo em massa de mensagens falsificadas tentando obter dados 
pessoais. 
 Spear-phishing: mensagens personalizadas, usando dados colhidos via 
OSINT ou vazamentos, com maior credibilidade. 
 Vishing: engenharia social por telefone, onde o atacante convence a vítima a 
passar dados. 
 Spoofing: falsificação de identidade (e-mail, telefone, site), criando confiança. 
 Typosquatting (Squat): registro de domínios parecidos com o legítimo para 
enganar usuários desavisados. 
 
3. Aplicação ética das técnicas 
O uso ético dessas técnicas ocorre em testes de segurança (pentests) autorizados, 
em ambientes controlados. Objetiva-se: 
 Avaliar a prontidão dos colaboradores. 
 Medir a eficácia das políticas de segurança. 
 Treinar equipes para identificar tentativas reais de ataque. 
Sem autorização, tais práticas são criminosas, configurando invasão de privacidade 
e fraude. 
 
4. Ferramentas OSINT para coleta e análise de dados 
Ferramentas e plataformas reconhecidas: 
 Recon-ng: framework para automação de coleta OSINT, especialmente sobre 
domínios e e-mails. 
 theHarvester: busca informações públicas (e-mail, IP, subdomínios) em várias 
fontes. 
 Maltego: mapeamento visual de redes de contatos, e-mails, conexões sociais 
e domínios. 
 SpiderFoot: automação de footprinting (busca vazamentos, perfis sociais, 
infraestruturas). 
 Shodan: busca por dispositivos expostos e vulneráveis. 
 Google Dorks: pesquisa avançada em mecanismos de busca para encontrar 
arquivos, documentações ou dados públicos acidentalmente expostos. 
 Pipl e Social Links: busca de perfis e conexões sociais de indivíduos. 
 
5. Análise dos dados coletados e potenciais explorações 
Exemplos de informações descobertas: 
 Nome completo dos funcionários e cargos (LinkedIn, site institucional). 
 Endereços de e-mail e padrões usados (site, blogs de colaboradores). 
 Lista de parceiros/confiança (apresentada em posts ou releases). 
 Preferências e hábitos (redes sociais, postagens, eventos participantes). 
 Softwares expostos (Shodan mostra hosts acessíveis com versões 
vulneráveis). 
 Documentos públicos indexados (Google Dorks encontra PDFs, planilhas 
abertas). 
 Telefone de contato central (Google, cadastros públicos). 
 
6. Como esses dados são usados em ataques 
 Phishing e Spear-phishing: Os e-mails coletados servem de alvo; informações 
sobre projetos aumentam a verossimilhança da mensagem. 
 Vishing: Contato direto por telefone simulando o suporte técnico ou parceiros, 
citando nomes, departamentos e detalhes específicos para convencer. 
 Spoofing: Criação de sites falsos que imitam domínios internos, usando o 
padrão descoberto nos e-mails e infraestrutura. 
 Squat: Registro de domínios parecidos, enviando e-mails que passam 
despercebidos por parte dos colaboradores. 
 
7. Medidas de proteção e mitigação 
 Treinamento regular de colaboradores sobre ataques de engenharia social. 
 Simulações controladas (exemplo: simulação de phishing). 
 Políticas de verificação (double-check para solicitações sensíveis). 
 Autenticação multifator (MFA). 
 Monitoramento de domínios semelhantes (Brand protection). 
 Inventário e controle de exposição online (monitoramento OSINT contínuo). 
 
8. Relatório de dados potencialmente comprometedores 
8.1. Sumário executivo 
Durante simulação de engenharia social, identificaram-se diversos dados 
potencialmente comprometedores para a VaultX, que facilitariam ataques personalizados e 
fraudes. 
8.2. Dados pessoais identificados 
Tipo de Informação Quantidade Fonte Risco Potencial 
E-mails corporativos 42 LinkedIn/Website 
Phishing direcionado 
e spear-phishing 
Estrutura 
organizacional 
Completa LinkedIn/Site 
Targeting de gestores 
para fraude BEC 
Documentos 
públicos 
8 Google Dorks 
Vazamento de 
políticas internas e 
dados 
Tecnologias 
expostas 
3 sistemas Shodan/Recon-ng 
Exploração de 
vulnerabilidades 
técnicas 
Redes sociais 15 perfis Facebook/LinkedIn 
Perfilização 
comportamental para 
vishing 
Parceiros/nome de 
clientes 
6 Site/Releases 
Spear-phishing 
usando nome de 
confiança 
Telefones internos 5 Site/Anúncios Vishing/Spoofing 
 
8.3. Impacto potencial 
 Comprometimento de contas por spear-phishing. 
 Acesso não autorizado a sistemas expostos. 
 Perda de confiança de clientes/parceiros. 
 Vazamento de dados internos. 
8.4. Recomendações 
 Reduzir exposição de informações públicas. 
 Revisar políticas de publicação de documentos. 
 Implementar programas de conscientização. 
 Monitorar domínios similares. 
 Realizar simulações contínuas de ataques. 
 
9. Conclusão 
Técnicas de engenharia social exploram vulnerabilidades humanas, baseando-se 
em princípios psicológicos, para obter acesso indevido a dados valiosos. O uso ético dessas 
técnicas, aliado a ferramentas OSINT, permite identificar pontos frágeis e fortalecer defesas, 
devendo sempre contemplar políticas de proteção, conscientização e mitigação proativa. 
 
10. Plano de proteção de dados – VaultX 
10.1. Objetivo 
Assegurar a proteção de dados sensíveis contra acessos não autorizados, 
vazamentos e explorações por técnicas de engenharia social, utilizando anonimização, 
ofuscação, criptografia e controles robustos tanto para dados em repouso quanto em 
movimento. 
10.2. Medidas metodológicas 
10.2.1. Anonimização de dados 
Definição: processo de eliminação ou modificação de informações que possam 
identificar indivíduos diretos ou indiretamente. 
 Pseudonimização: substituição de identificadores diretos (nome, RG, e-mail) 
por pseudônimos ou tokens, tornando a reidentificação impossível sem chave 
separada. 
 Exemplo: funcionários identificados por códigos internos. 
 Generalização: redução da precisão dos dados (“idade: 32” para “30-35 
anos”). 
 Supressão: remoção de dados sensíveis em relatórios, dashboards e logs. 
 Troca/Agrupamento: mistura de dados para evitar associação direta (shuffling, 
k-anonymity). 
Aplicação: Utilizar essas técnicas em: 
 Relatórios compartilhados entre áreas 
 Extração de dados para análises externas 
 Compartilhamento com parceiros e fornecedores 
10.2.2. Ofuscação de dados 
Definição: transformação de dados sensíveis em formatos não facilmente legíveis ou 
compreensíveis. 
 Mascaramento (masking): recurso para esconder partedos dados exibidos. 
 Exemplo: exibir CPF como .123.-09. 
 Hashing: dados convertidos em hashes criptográficos (sem possibilidade de 
reversão, apenas comparação). 
 Tokenização: Substituição de dados sensíveis por tokens “descartáveis”, 
utilizados apenas em contexto específico. 
Aplicação: 
 Exibição de dados em telas de sistemas acessíveis a múltiplos usuários 
 Logs de auditoria 
 Ambientes de homologação ou desenvolvimento. 
10.2.3. Estratégias complementares de mitigação 
 Segregação de dados: compartimentalizar informações sensíveis em 
múltiplos sistemas/bancos, restringindo acesso por necessidade de negócio 
(princípio do menor privilégio). 
 Controle de acesso: acesso restrito por autenticação forte (MFA) e 
autorização granular. 
 Monitoramento contínuo: logging detalhado, análise de comportamento 
anômalo e alertas automáticos. 
 Destruição segura de dados: apagamento permanente, sem possibilidade de 
recuperação, conforme políticas internas e LGPD. 
10.3. Proteção de dados em movimento e em repouso 
10.3.1. Dados em movimento (em trânsito) 
Definição: dados transmitidos entre usuários, sistemas, nuvem, parceiros ou clientes. 
Estratégias: 
 Criptografia ponta a ponta (E2EE): utilizar TLS 1.3 para toda transmissão de 
dados via internet, VPN segura entre filiais e conexões com parceiros. 
 Transmissão autenticada: autenticação forte em APIs (OAuth, JWT, 
certificados digitais). 
 Assinatura digital: para garantir integridade e autenticidade de 
arquivos/documentos transmitidos. 
 Classificação de dados: identificar o nível de sensibilidade para aplicar 
proteção adequada antes do envio. 
10.3.2. Dados em repouso 
Definição: dados armazenados em bancos de dados, servidores, dispositivos locais, 
backups. 
Estratégias: 
 Criptografia de banco de dados/disco: ativar criptografia nativa (AES-256, 
TDE) em bancos SQL, arquivos, máquinas virtuais e backups. 
 Gestão de chaves separada: chaves de criptografia sob controle dedicado, 
segregação física/lógica, rotação periódica. 
 Controle de acesso e logging: permissões restritas, logs detalhados e 
imutáveis de acessos a bancos e arquivos. 
 Backups protegidos: sempre criptografados e com controle rígido de 
acesso/recuperação. 
10.4. Controles de proteção para Integridade, Segurança e Rastreabilidade 
10.4.1. Controles de integridade 
 Hashes e checksums: garantia de que arquivos e registros mantenham 
integridade nas transferências e no armazenamento. 
 Assinatura digital: previne alterações não autorizadas em documentos 
críticos. 
10.4.2. Controles de segurança 
 Autenticação multifator (MFA): para acesso a sistemas e dashboards 
sensíveis. 
 Gestão de identidade e acesso (IAM): perfis mínimos necessários, revisão 
periódica de permissões. 
 Monitoramento e resposta a incidentes: ferramentas SIEM/SOC detectando 
acessos suspeitos e enviando alertas para resposta imediata. 
10.4.3. Controles de rastreabilidade 
 Logging detalhado: registro de todas as operações sensíveis, acesso, 
modificação, envio ou exclusão de dados. 
 Logs invioláveis: guardados em espaço seguro/imune a adulteração (WORM, 
blockchain). 
 Auditorias regulares: revisão periódica dos registros e configurações. 
 Data lineage: rastreabilidade de como, quando e por quem os dados foram 
tratados durante seu ciclo de vida. 
10.5. Conclusão 
Combinar técnicas de anonimização, ofuscação, criptografia avançada, segregação 
de acessos e monitoramento permite reduzir drasticamente os riscos de comprometimento 
em ataques de engenharia social e vazamentos. Integridade, segurança e rastreabilidade 
são garantidas por controles técnicos e administrativos, alinhados às melhores práticas e 
regulamentações, tais como LGPD e ISO 27001. 
 
11. Análise crítica dos controles de proteção de dados: vulnerabilidades à 
engenharia social 
Embora a implementação de técnicas como anonimização, ofuscação, criptografia e 
controles de acesso seja essencial para a proteção dos dados da VaultX, nenhum sistema 
é infalível. A engenharia social explora justamente aspectos humanos e operacionais para 
contornar controles técnicos. Veja abaixo uma análise crítica das fragilidades e potenciais 
pontos de exploração: 
11.1. Fatores humanos e operacionais 
11.1.1. Falhas de consciência e treinamento 
 Solução técnica em fronteiras mal treinadas: por mais robusto que seja o 
controle de acesso ou a exigência de MFA, usuários desatentos ou ingênuos 
podem ser induzidos a compartilhar credenciais ou segredos criptográficos 
após um contato falso, e-mails de phishing ou ligações de “suporte de TI”. 
 Compartilhamento indevido: funcionários podem, por pressão ou por falta de 
orientação, compartilhar dados “anonimizados” que, combinados a outros 
conjuntos de dados, podem reidentificar clientes. 
 Uso de canais não oficiais: com a pressa do dia a dia, colaboradores podem 
receber solicitações urgentes por WhatsApp, Teams ou e-mail pessoal, 
contornando os controles estabelecidos. 
11.1.2. Privilégios excessivos e revisão infrequente 
 Privilégio além do necessário: empregados com acesso mais amplo que o 
exigido para a função podem ser convencidos a compartilhar ou manipular 
dados. 
 Falta de rotatividade de senhas e revalidação de acessos: permite que ex-
funcionários ou terceiros com informações antigas tentem acessar o sistema. 
11.1.3. Engajamento social sutil e desatenção 
 Pretexting: atacante se passa por autoridade interna ou fornecedor. Um 
simples contato pode sufocar a vigilância do funcionário. 
 Spear phishing: mensagens altamente personalizadas exploram informações 
de redes sociais/corporativas para reforçar a credibilidade de e-mails 
fraudulentos. 
11.2. Fatores técnicos, processuais e reais limitantes dos controles 
11.2.1. Limitações de anonimização e ofuscação 
 Re-identificação cruzada: dados anonimizados podem ser revertidos caso 
sejam cruzados com fontes externas, principalmente se a anonimização não 
for rigorosa (ex.: pseudonimização sem chave segregada). 
 Logs e ambientes de homologação: dados reais copiados sem anonimização 
adequada podem vazar em ambientes menos protegidos. 
11.2.2. Segredos, chaves e códigos humanamente geridos 
 Armazenamento inseguro de chaves (post-it, arquivos locais): funcionários 
guardam senhas, 2FA ou chaves criptográficas de modo inseguro. 
 Engenharia social para obtenção de tokens e códigos temporários: atacantes 
se aproveitam de distrações ou simulam contexto de emergência para obter 
códigos MFA enviados por SMS ou apps. 
11.2.3. Controles excessivamente automatizados 
 Alerta de monitoração ignorados: dependência total de automação pode 
sofrer com “fadiga de alerta” ou configurações erradas, gerando brechas não 
detectadas. 
 Permissões temporárias esquecidas: atrasos ou falhas administrativas na 
retirada de acessos provisórios. 
11.3. Técnicas de engenharia social potencialmente utilizáveis 
 Phishing (e variantes): e-mails ou mensagens falsas, simulando comunicação 
interna para capturar credenciais. 
 Vishing (voice phishing): ligações aparentando origem confiável, solicitando 
códigos, informações ou destravamentos de acesso. 
 Smishing: uso de SMS/WhatsApp com links suspeitos para induzir ao 
fornecimento de dados. 
 Impersonation/presença física: alguém se passando por funcionário 
terceirizado (ex.: manutenção, limpeza) coletando informações visualmente 
(screen peeking, shoulder surfing). 
11.4. Possíveis estratégias de evasão de controles 
Controle Implementado 
Vulnerabilidade 
Humana 
Técnica de 
Engenharia Social 
Exemplo Prático 
Criptografia/MFA 
Solicitação de 
códigos por terceiros 
Vishing/Spear 
phishing 
“Sou do suporte, 
preciso do código 
que você recebeu 
para atualizar seu 
acesso!” 
Segregação e controle 
de acesso 
Compartilhamento de 
senhas/credenciais 
Pretexting 
“Seu gestor pediu 
para eu acessar 
esse dashboard,pode compartilhar o 
login?” 
Tokenização e 
mascaramento 
Vazamento de 
informações 
contextuais 
Engenharia social de 
informação pública 
Cruzar dados 
mascarados 
públicos com 
LinkedIn ou redes 
sociais 
Logging/rastreabilidade 
Falta de atenção a 
alertas de segurança 
Overload/fadiga de 
alerta, rotina 
automatizada 
Alertas ignorados 
em SIEM devido ao 
excesso de 
notificações 
Processos de backup 
Armazenamento 
inseguro fora de 
produção 
Influenciar backups 
em ambientes 
inadequados 
Cópias exportadas 
para pen drives ou 
e-mails pessoais 
 
11.5. Recomendações para minimizar o fator humano 
 Treinamento contínuo e simulado: campanhas regulares de conscientização, 
simulações de ataques de phishing/vishing e feedback personalizado. 
 Política forte de gestão de privilégios: least privilege, revisão frequente de 
acessos e procedimentos claros para revogação. 
 Dificultar identificação de informações sensíveis: ambientes de 
desenvolvimento sempre com dados sintéticos, mascaramento extremo em 
logs e telas genéricas. 
 Gestão rigorosa de chaves e segredos: proibir armazenamento local, uso de 
cofres de senhas e sistemas especializados. 
 Incentivo à cultura de reporte: facilitar canais confiáveis para denúncias de 
tentativas suspeitas, sem retaliação por parte da empresa. 
11.6. Conclusão 
Mesmo com tecnologia robusta, o elo humano continua sendo o principal vetor de 
ataque de engenharia social. Controles técnicos devem ser acompanhados de cultura 
organizacional de segurança, processos de revisão periódica, treinamento recorrente e 
incentivos ao reporte de tentativas suspeitas. A segurança total exige abordagem 
multidimensional e vigilância constante. 
 
TESTE DE PERFORMANCE – TP5 
Projeto 
Você deverá planejar, executar e avaliar um cenário prático, onde técnicas de 
engenharia social são aplicadas para obter informações sensíveis, seguido de 
uma análise crítica e a implementação de políticas de proteção de dados que 
previnam esses ataques. 
Desafio 
Você deverá trabalhar em um cenário fictício, no qual atua em dois papeis 
complementares: 
 Atacante: utilizando técnicas de engenharia social para obter 
informações confidenciais de uma organização; 
 Defensor: responsável por implementar políticas e controles de 
privacidade que poderiam mitigar esses ataques. 
O desafio é unir as duas abordagens em um fluxo coerente, onde as 
vulnerabilidades exploradas sirvam de base para as políticas de proteção de 
dados. Para isso, você deverá clonar uma página web legítima, utilizando 
ferramentas apropriadas para criar uma página de phishing realista. 
O objetivo será capturar dados simulados (como credenciais de login) de um 
grupo fictício de alvos. A simulação deve ser cuidadosamente projetada para 
refletir um cenário real em que uma organização negligencia suas políticas de 
privacidade e segurança. Para tornar o ataque de phishing mais eficaz, você 
deve criar pretextos realistas. Isso inclui a criação de personagens fictícios e 
histórias plausíveis que convençam os alvos a interagir com a página clonada. 
Após o ataque de phishing, avalie quais falhas de segurança da informação e 
políticas de privacidade permitiram que o ataque fosse bem-sucedido. Isso 
inclui a análise de erros no gerenciamento de consentimento, falta de políticas 
de exclusão de dados e erros de rastreabilidade de informações. 
Descreva como as medidas implementadas impactam diretamente na 
mitigação dos ataques de phishing e engenharia social. Por exemplo, um CMP 
robusto poderia alertar os usuários sobre tentativas de phishing, e uma política 
de exclusão poderia reduzir o impacto de credenciais vazadas. 
Entrega 
Um relatório final que una todas as etapas, conectando o ataque de phishing 
com a proposta de políticas de privacidade e proteção de dados. O relatório 
deve cobrir: 
 Detalhes do ataque de phishing (clonagem de página, criação de 
pretextos). 
 Análise das falhas de privacidade que permitiram o ataque. 
 Proposta detalhada de políticas de proteção de dados e como essas 
políticas podem mitigar ataques futuros. 
Este relatório apresenta um cenário prático envolvendo técnicas de engenharia 
social para obtenção de informações sensíveis, seguido por uma análise crítica e a proposta 
de políticas de proteção de dados com o objetivo de prevenir ataques semelhantes no 
futuro. A simulação é realizada a partir de dois papéis complementares dentro de uma 
organização fictícia: o atacante, responsável por planejar e executar o ataque de 
engenharia social, e o defensor, encarregado de avaliar as falhas que permitiram a 
ocorrência do ataque e implementar controles e políticas de privacidade para mitigá-lo. 
A organização fictícia utilizada como alvo foi a NovaClin Saúde Integrada, uma clínica 
de saúde de médio porte com sedes em duas capitais brasileiras, composta por cerca de 
150 funcionários entre médicos, equipe administrativa e time de tecnologia da informação. 
Recentemente, a NovaClin migrou seu sistema de prontuário eletrônico para uma nova 
plataforma online. A simulação teve como objetivo obter credenciais de login dos 
funcionários administrativos da NovaClin, com foco no acesso ao sistema de prontuários 
eletrônicos. 
Para atingir esse objetivo, foi utilizada a técnica de phishing com clonagem de uma 
página web legítima da plataforma de login utilizada pela clínica, cujo domínio legítimo seria 
`portal.novaclin.com.br`. Foram empregadas ferramentas apropriadas para criar uma 
réplica realista dessa página, entre elas o HTTrack Website Copier, utilizado para clonar a 
interface do portal; o SET (Social-Engineer Toolkit), empregado para montar o ataque de 
phishing com coleta de credenciais; ferramentas de design gráfico como Canva e 
Photoshop, para a criação de identidades visuais falsas de e-mails e campanhas; além de 
manipulação de SMTP para simular o envio de mensagens a partir de um domínio 
aparentemente legítimo, como “rh@novaclin.com.br”. 
O ataque foi construído a partir de um pretexto plausível. Criou-se a personagem 
fictícia Daniela Moura, uma suposta analista de RH sênior da NovaClin, que estaria 
coordenando uma atualização cadastral dos funcionários para a integração com um novo 
sistema de benefícios. A mensagem enviada aos alvos informava que, conforme anunciado 
em reunião, todos os colaboradores deveriam acessar um portal para confirmar seus dados 
cadastrais. O texto dizia: “Olá! Conforme anunciado na última reunião, estamos atualizando 
os cadastros de todos os colaboradores para a integração com o novo sistema de 
benefícios. Acesse o portal abaixo com seu login para confirmar seus dados: https://portal-
novaclin-saude.net/login. O prazo final é amanhã, 12h.” 
O e-mail foi direcionado a 35 funcionários da equipe administrativa, cujos contatos 
foram obtidos a partir de redes sociais e perfis no LinkedIn. A página clonada foi hospedada 
em um servidor privado com certificado HTTPS obtido por meio do Let’s Encrypt. Em menos 
de 48 horas, 19 usuários inseriram suas credenciais de login e senha no portal falso, 
demonstrando a eficácia do ataque. 
Em seguida, foi realizada uma análise das falhas de privacidade e segurança que 
permitiram que o ataque fosse bem-sucedido. A primeira falha observada foi a ausência de 
autenticação multifator no sistema, que aceitava login apenas com e-mail e senha. A 
segunda foi a inexistência de políticas claras de consentimento e conscientização, 
evidenciada pela falta de treinamentos que capacitassem os usuários a identificarem 
comunicações falsas. A terceira falha foi um gerenciamento de identidade negligente, com 
ausência de monitoramento de logins suspeitos ou realizados a partir de endereços IP 
externos. A quarta falha consistia na inexistência de políticas de exclusão ou anonimização 
de dados, o que permitiu que dados de ex-funcionários permanecessem ativos e fossem 
comprometidos. Por fim, identificou-seuma falha na rastreabilidade do consentimento de 
dados, já que não havia qualquer histórico sobre quando, como e por quem os dados dos 
colaboradores eram acessados ou utilizados. 
Com base nessas constatações, foram propostas medidas técnicas e administrativas 
para mitigar riscos futuros. A primeira medida sugerida foi a implementação de autenticação 
multifator (MFA), integrando um segundo fator obrigatório de autenticação por meio de 
aplicativo ou SMS, o que mitigaria o uso de credenciais vazadas. Em seguida, recomendou-
se a adoção de uma política robusta de gerenciamento de consentimento (CMP), capaz de 
documentar e gerenciar as permissões dadas pelo titular para cada uso de seus dados, 
proporcionando maior transparência e controle. Também foram sugeridas campanhas 
periódicas de conscientização e simulações de phishing internas, realizadas 
trimestralmente, para melhorar a detecção e resposta dos usuários. Foi indicada a criação 
de políticas de exclusão e retenção de dados, com ciclos automáticos de exclusão ou 
anonimização após o desligamento de colaboradores ou em caso de inatividade 
prolongada, reduzindo a exposição de dados obsoletos. Adicionalmente, recomendou-se o 
uso de ferramentas de monitoramento e alertas de acesso, como sistemas de SIEM 
(Security Information and Event Management), para detectar acessos incomuns, tanto em 
termos de geolocalização quanto de horários atípicos. Por fim, sugeriu-se a validação de 
domínios e implementação de SPF, DKIM e DMARC para reforçar a autenticação de e-
mails institucionais e impedir o uso de domínios falsos. 
Estabeleceu-se uma conexão direta entre cada fase do ataque e a política capaz de 
mitigá-la. O envio do e-mail falso foi viabilizado pela falta de autenticação de e-mails, o que 
poderia ser corrigido com uma política de segurança de e-mail baseada em SPF, DKIM e 
DMARC. O clique do usuário no link malicioso decorreu da falta de treinamento e 
conscientização, que seria resolvida com campanhas de educação em segurança. A 
inserção de credenciais na página falsa foi facilitada pela ausência de autenticação 
multifator e por não haver qualquer alerta de login em páginas externas, riscos que seriam 
evitados com a implementação de MFA e mecanismos de alerta. Por fim, a coleta de dados 
de ex-funcionários foi consequência da inexistência de uma política de exclusão de dados, 
o que seria sanado com a aplicação de diretrizes de retenção e anonimização. 
Desta forma, foi possível demonstrar como um ataque de engenharia social pode ser 
bem-sucedido mesmo com técnicas relativamente simples, quando há falhas de políticas 
de privacidade e proteção de dados. O uso de pretextos convincentes, aliado à clonagem 
de sites e à negligência na governança de dados, expõe a organização a riscos severos. 
Ao aplicar controles como autenticação multifator, gerenciamento de consentimento, 
treinamentos de conscientização, e gestão do ciclo de vida dos dados, a empresa pode 
reduzir significativamente o risco de comprometimento de informações sensíveis.considerações de segurança nas decisões de compra de aplicações e sistemas, 
bem como em projetos de desenvolvimento. 
As responsabilidades do proprietário do sistema incluem: 
 Garantir que a segurança adequada seja fornecida pelos controles 
necessários, gestão de senhas, controles de acesso remoto e configurações 
do sistema operacional. 
 Assegurar que os sistemas sejam devidamente avaliados quanto a 
vulnerabilidades. 
 Reportar quaisquer vulnerabilidades à equipe de resposta a incidentes e ao 
proprietário dos dados. 
2.2.5. Proprietários de Dados (Data Owners) 
O proprietário dos dados (ou proprietário da informação) é tipicamente um membro 
da gerência responsável por uma unidade de negócio específica, e é o responsável final 
pela proteção e uso de um subconjunto específico de informações. Ele tem 
responsabilidades de "due care" e, portanto, será responsabilizado por qualquer ato 
negligente que resulte na corrupção ou divulgação dos dados. 
As responsabilidades do proprietário dos dados são: 
 Decidir sobre a classificação dos dados sob sua responsabilidade e alterá-la 
conforme a necessidade de negócio. 
 Garantir que os controles de segurança necessários estejam em vigor. 
 Definir requisitos de segurança por classificação e requisitos de backup. 
 Aprovar quaisquer atividades de divulgação. 
 Garantir o uso de direitos de acesso adequados. 
 Definir critérios de acesso do usuário. 
 Lidar com violações de segurança relativas aos dados sob sua proteção. 
 Delegar a responsabilidade pela manutenção diária dos mecanismos de 
proteção de dados ao custodiante de dados. 
2.2.6. Administradores de Segurança (Security Administrators) 
São as pessoas que possuem direitos de administrador de segurança (e.g., conta 
'root' em sistemas Unix/Linux ou 'administrator' em Windows/Macintosh). Eles podem 
conceder e revogar permissões e definir configurações de segurança. 
As tarefas de um administrador de segurança incluem: 
 Criar novas contas de usuário do sistema. 
 Implementar novo software de segurança. 
 Testar patches e componentes de segurança. 
 Emitir novas senhas. 
 Garantir que os direitos de acesso concedidos aos usuários estejam em 
conformidade com as políticas e diretrizes do proprietário dos dados. (A 
aprovação de novas contas de usuário é responsabilidade do supervisor). 
2.2.7. Supervisores/Gerentes 
Também chamados de gerentes de usuário, são os responsáveis finais por toda a 
atividade do usuário e quaisquer ativos criados e de propriedade desses usuários. 
As responsabilidades do supervisor incluem: 
 Garantir que os funcionários compreendam suas responsabilidades em 
relação à segurança. 
 Distribuir senhas iniciais. 
 Garantir que as informações da conta dos funcionários estejam atualizadas. 
 Informar o administrador de segurança quando um funcionário é demitido, 
suspenso ou transferido, pois qualquer mudança no papel de um funcionário 
geralmente afeta os direitos de acesso. 
2.2.8. Usuários 
Qualquer indivíduo que utiliza rotineiramente os dados para tarefas relacionadas ao 
trabalho. 
As responsabilidades do usuário são: 
 Ter o nível de acesso necessário aos dados para desempenhar as funções de 
sua posição. 
 Seguir os procedimentos de segurança operacional para garantir a 
confidencialidade, integridade e disponibilidade dos dados para outros. 
3. Metodologia de análise 
A avaliação seguiu uma abordagem estruturada, categorizando as vulnerabilidades 
e controles de acordo com as funções do NIST Cybersecurity Framework: Identificar 
(Identify), Proteger (Protect), Detectar (Detect), Responder (Respond) e Recuperar 
(Recover), além da área de Governança (Govern). Um foco especial foi dado às implicações 
diretas e indiretas para a conformidade com a LGPD, dada a natureza dos dados tratados 
pela Health Labs. 
4. Análise detalhada das vulnerabilidades e ameaças potenciais 
4.1. Função "Identificar" (Identify) 
Esta função é a base para a gestão de riscos e a compreensão do ambiente de 
segurança. As deficiências aqui são críticas: 
 Gestão de ciclo de vida de ativos e dados (ID.AM-08): sistemas, hardware, 
software, serviços e, crucialmente, dados não são gerenciados ao longo de 
seu ciclo de vida. 
o Ameaça: vulnerabilidades não corrigidas, dados sensíveis (de 
pacientes) não descartados adequadamente (risco LGPD), dificuldade 
em garantir a integridade e disponibilidade. 
 Processos de divulgação de vulnerabilidades (ID.RA-08): não há processos 
estabelecidos para receber, analisar e responder a divulgações de 
vulnerabilidades. 
o Ameaça: lentidão ou incapacidade de reagir a vulnerabilidades 
conhecidas, deixando a empresa exposta a ataques. 
 Autenticidade e integridade de hardware/software (ID.RA-09): não há 
avaliação da autenticidade e integridade de hardware e software antes da 
aquisição e uso. 
o Ameaça: risco de ataques à cadeia de suprimentos, onde componentes 
maliciosos podem ser introduzidos nos sistemas. 
 Planos de resposta a incidentes (ID.IM-04): planos de resposta a incidentes e 
outros planos de cibersegurança que afetam as operações não estão 
estabelecidos, comunicados, mantidos e aprimorados. 
o Ameaça: incapacidade de reagir eficazmente a violações, resultando 
em maior dano, interrupção de serviços e não conformidade com 
notificações da LGPD. 
 Inteligência de ameaças cibernéticas (ID.RA-02): inteligência de ameaças não 
é recebida de fóruns e fontes de compartilhamento de informações. 
o Ameaça: a empresa atua sem conhecimento das ameaças emergentes 
e técnicas de ataque direcionadas ao setor de saúde. 
 Inventários de dados e metadados (ID.AM-07): não há manutenção de 
inventários de dados e metadados para tipos de dados designados. 
o Ameaça para LGPD (crítica): viola o princípio da transparência e da 
responsabilização. Impede a gestão eficaz dos dados pessoais, o 
mapeamento de fluxo de dados (data flow mapping), a realização de 
Avaliações de Impacto à Proteção de Dados (DPIAs) e a capacidade 
de responder a direitos dos titulares (acesso, correção, eliminação). 
 Inventários de software, serviços, sistemas e hardware (ID.AM-02, ID.AM-01): 
não há manutenção de inventários completos de software, serviços, sistemas 
e hardware. 
o Ameaça: dificuldade em identificar e gerenciar vulnerabilidades, 
existência de "Shadow IT". 
 Avaliação e priorização de riscos/ativos (ID.RA-04, ID.RA-05, ID.RA-03, 
ID.RA-06, ID.AM-05): há lacunas na identificação de impactos e 
probabilidades de ameaças, na utilização de ameaças/vulnerabilidades para 
entender riscos e priorizar respostas, na identificação de ameaças 
internas/externas, na escolha/priorização/acompanhamento de respostas a 
riscos e na priorização de ativos com base em criticidade. 
o Ameaça: alocação ineficiente de recursos de segurança e 
incapacidade de demonstrar uma gestão de riscos robusta exigida pela 
LGPD. 
4.2. Função "Proteger" (Protect) 
Esta função concentra-se na implementação de salvaguardas para garantir a entrega 
de serviços críticos. 
 Acesso e privilégios (PR.AA-05): permissões de acesso, direitos e 
autorizações não são definidas em política, gerenciadas, impostas e 
revisadas de acordo com os princípios de menor privilégio e segregação de 
funções. 
o Ameaça: acesso excessivo a dados sensíveis (de pacientes), 
aumentando o risco de uso indevido, vazamento acidental ou 
intencional (risco LGPD). 
 Backups de dados (PR.DS-11): backups de dados não são criados, 
protegidos, mantidos e testados adequadamente. 
o Ameaça: perda de dados críticos em caso de incidente (ransomware, 
falha de hardware) e incerteza sobre a capacidade de recuperação. 
 Gerenciamento de configuração e manutenção (PR.PS-01, PR.PS-02, 
PR.PS-03, PR.PS-05): práticas de gerenciamento de configuração não são 
estabelecidas/aplicadas; software/hardware não é mantido, substituído e 
removido de forma adequada; instalação/execução de softwarenão 
autorizado não é prevenida. 
o Ameaça: inconsistência de segurança, vulnerabilidades em sistemas 
desatualizados e introdução de software malicioso. 
 Registros de logs para monitoramento contínuo (PR.PS-04): registros de logs 
não são disponibilizados para monitoramento contínuo. 
o Ameaça: dificuldade em detectar atividades suspeitas em tempo real e 
atraso na resposta a incidentes. 
 Resiliência e capacidade de recursos (PR.IR-03, PR.IR-04): mecanismos de 
resiliência e capacidade de recursos adequada para garantir a disponibilidade 
não são mantidos. 
o Ameaça: interrupção de serviços críticos (telemedicina, prontuários) 
devido a ataques ou falhas. 
 Conscientização e treinamento em cibersegurança (PR.AT-02, PR.AT-01): 
não há treinamento de conscientização e habilidades para todo o pessoal, 
incluindo aqueles em funções especializadas. 
o Ameaça: funcionários como elo mais fraco, suscetíveis a ataques de 
engenharia social, resultando em violações de dados (risco à LGPD). 
4.3. Função "Detectar" (Detect) 
Esta função permite a identificação de eventos de cibersegurança. 
 Integração de inteligência de ameaças (DE.AE-07): inteligência de ameaças 
cibernéticas e outras informações contextuais não são integradas na análise. 
o Ameaça: dificuldade em detectar ataques sofisticados e falta de 
proatividade na defesa. 
 Correlação de informações (DE.AE-03): não há correlação de informações de 
múltiplas fontes. 
o Ameaça: dificuldade em identificar padrões de ataque complexos ou 
atividades que, isoladamente, parecem inofensivas. 
4.4. Função "Responder" (Respond) 
Esta função se concentra em atividades para tomar ações após um incidente. 
 Gravação e preservação de dados de investigação (RS.AN-06, RS.AN-07, 
RS.AN-08): ações durante uma investigação não são gravadas, a 
integridade/providência dos registros não é preservada, dados/metadados de 
incidentes não são coletados/preservados, e a magnitude do incidente não é 
estimada/validada. 
o Ameaça: dificuldade em realizar análises forenses eficazes, entender 
a extensão do dano e cumprir requisitos de notificação da LGPD. 
 Comunicação e notificação de incidentes (RS.CO-03, RS.CO-02): 
informações não são compartilhadas com partes interessadas designadas 
(internas/externas); partes interessadas internas/externas não são notificadas 
de incidentes. 
o Ameaça para LGPD (crítica): falha crítica na conformidade com o Art. 
48 da LGPD, que exige notificação à ANPD e aos titulares em caso de 
incidentes de dados. Leva a multas e danos à reputação. 
4.5. Função "Recuperar" (Recover) 
Esta função suporta a resiliência e a restauração de serviços normais. 
 Critérios de fim de recuperação e documentação (RC.RP-06): o fim da 
recuperação de incidentes não é declarado com base em critérios, e a 
documentação relacionada ao incidente não é concluída. 
o Ameaça: risco de persistência de problemas pós-incidente e falha em 
capitalizar as lições aprendidas. 
 Consideração de funções críticas pós-incidente (RC.RP-04): funções críticas 
da missão e gerenciamento de risco de cibersegurança não são consideradas 
para estabelecer normas operacionais pós-incidente. 
o Ameaça: retorno a um estado vulnerável, sem melhoria contínua da 
postura de segurança. 
4.6. Função "Governança" (Govern) 
Esta função define e monitora a estratégia de segurança da informação. As 
deficiências aqui são estruturais. 
Gestão Estratégica de Riscos (GV.RM-02, GV.RM-04, GV.RM-06): Declarações de 
apetite/tolerância a risco não estabelecidas/comunicadas; direção estratégica para opções 
de resposta a riscos não estabelecida/comunicada; método padronizado para 
cálculo/documentação/categorização/priorização de riscos cibernéticos não 
estabelecido/comunicado. 
Ameaça para LGPD: Inconsistência nas decisões de segurança, alocação ineficiente 
de recursos e incapacidade de demonstrar "accountability" sobre a gestão de riscos. 
Comunicação de Riscos e Terceiros (GV.RM-05, GV.SC-08, GV.SC-10): Linhas de 
comunicação para riscos cibernéticos (incluindo fornecedores) não estabelecidas; 
fornecedores/terceiros não incluídos em planejamento/resposta/recuperação de incidentes; 
planos de gestão de risco da cadeia de suprimentos não incluem provisões pós-conclusão 
de contrato. 
Ameaça para LGPD (CRÍTICA): Grande risco de violações de dados originadas de 
terceiros ou falha em gerenciar riscos em toda a cadeia de valor, o que é uma 
responsabilidade sob a LGPD. 
Alocação de Recursos e Revisão de Políticas/Estratégia (GV.RR-03, GV.PO-02, 
GV.OV-01, GV.OV-02, GV.OV-03): Recursos inadequados; políticas de gerenciamento de 
riscos não revisadas/atualizadas/comunicadas/aplicadas; resultados da estratégia de risco 
não revisados/ajustados; estratégia de risco não revisada/ajustada para cobertura; 
desempenho de gerenciamento de risco não avaliado/revisado. 
Ameaça: Estratégia de segurança estática, não adaptada a novas ameaças e 
requisitos (LGPD), levando a um programa de segurança ineficaz. 
 
 
4.7. Vulnerabilidades categorizadas por tipo 
As vulnerabilidades identificadas nos sistemas da Health Labs criam as brechas que 
as ameaças cibernéticas podem explorar. Essas vulnerabilidades abrangem aspectos 
técnicos, processuais e organizacionais, com um impacto direto na capacidade da empresa 
de proteger seus dados. 
4.7.1. Vulnerabilidades técnicas 
 Sistemas operacionais desatualizados: sistemas operacionais desatualizados 
em algumas máquinas de diagnóstico legadas representam uma 
vulnerabilidade crítica. Softwares antigos frequentemente contêm falhas de 
segurança conhecidas que não são corrigidas, tornando-os alvos fáceis para 
exploração. Em um ambiente de saúde, isso é ainda mais preocupante, pois 
pode afetar a precisão dos diagnósticos e a integridade dos dados do 
paciente. 
 Credenciais padrão: a presença de credenciais padrão encontradas em vários 
dispositivos de rede é uma falha de segurança básica, mas extremamente 
perigosa. Atacantes podem facilmente usar listas de credenciais padrão para 
obter acesso não autorizado a roteadores, switches, firewalls e outros 
dispositivos de infraestrutura, comprometendo a rede inteira. 
 Ausência de autenticação multifator (MFA): A ausência de autenticação 
multifator (MFA) para acesso remoto a sistemas críticos é uma vulnerabilidade 
grave. A MFA adiciona uma camada essencial de segurança, exigindo mais 
de uma forma de verificação de identidade. Sem ela, uma senha 
comprometida é suficiente para que um atacante obtenha acesso total. 
 Monitoramento e log insuficientes: o monitoramento e logs insuficientes 
impede a detecção precoce de atividades suspeitas ou ataques. Sem logs 
detalhados, é quase impossível investigar incidentes de segurança, identificar 
a causa raiz de uma violação ou determinar a extensão do dano. 
 Ausência de varredura de vulnerabilidades e testes de penetração: a falta de 
varredura regular de vulnerabilidades ou testes de penetração significa que a 
Health Labs não está proativamente identificando e corrigindo suas próprias 
fraquezas. Isso deixa a empresa cega para as brechas que podem ser 
exploradas por atacantes. 
 Políticas de senha fracas: políticas de senha fracas (por exemplo, sem 
requisitos de complexidade, sem rotação forçada) tornam as contas de 
usuário suscetíveis a ataques de força bruta ou adivinhação. Senhas fáceis 
de quebrar são um convite para o acesso não autorizado. 
 Dados não criptografados em repouso: a menção de dados não 
criptografados em repouso em alguns armazenamentos não críticos, mas 
potencialmente acessíveis é preocupante. Embora classificados como "não 
críticos", esses dados ainda podem conter informações sensíveis que, se 
expostas, poderiam levar a violações de privacidade. A criptografia de dados 
em repouso é uma prática fundamental para proteger informações contra 
acesso não autorizado, mesmo que o sistema de armazenamento seja 
comprometido. Ausência de soluções DLP: a ausência de soluções de prevenção de perda 
de dados (DLP) significa que a Health Labs não possui mecanismos 
automatizados para impedir a exfiltração de dados sensíveis, seja por 
intenção maliciosa ou por erro. 
4.7.2. Vulnerabilidades processuais e organizacionais 
 Ausência de classificação abrangente de dados: a falta de uma política 
abrangente de classificação de dados implica que sem classificação os dados 
por sensibilidade e criticidade, a Health Labs não pode aplicar os controles de 
segurança apropriados, tratando todos os dados da mesma forma, o que leva 
a uma proteção inadequada para os dados mais sensíveis e um uso 
ineficiente de recursos. 
 Treinamento de conscientização de segurança insuficiente: embora seja 
mencionada a existência de treinamento anual de conscientização de 
segurança para funcionários, a persistência de ameaças de phishing e a 
vulnerabilidade a funcionários negligentes sugerem que o treinamento pode 
não ser suficientemente eficaz ou frequente. A conscientização contínua é 
vital para mitigar o risco humano. 
 Controles de acesso fracos: a falta de MFA e as políticas de senha fracas são 
sintomas de controles de acesso inadequados. Isso se estende à gestão de 
privilégios, onde pode haver excesso de permissões ou falta de revisão 
regular dos acessos. 
 Plano de resposta a incidentes em andamento: a ausência de um plano de 
resposta a incidentes totalmente desenvolvido e testado significa que a Health 
Labs pode não ser capaz de reagir de forma eficaz e rápida a uma violação, 
minimizando danos e restaurando operações. 
 Baixa frequência de teste de backup e recuperação: embora exista uma 
política para backup e recuperação de dados, a frequência de teste é baixa. 
Backups não testados são backups não confiáveis. Em caso de um ataque de 
ransomware ou falha de sistema, a capacidade de recuperação da Health 
Labs seria comprometida. 
 Políticas de retenção de dados vagas: as políticas de retenção de dados são 
vagas. Isso pode levar ao armazenamento desnecessário de dados sensíveis 
por períodos prolongados, aumentando o risco de exposição em caso de 
violação, além de dificultar a conformidade com regulamentações de 
privacidade que exigem a exclusão de dados após um determinado período. 
5. Controles implementados e seus resultados 
Apesar das vulnerabilidades destacadas, é possível verificar que a Health Labs já 
implementou uma série de controles importantes, com status de implementação variando, 
o que é um ponto de partida positivo. A seguir é possível conferir os controles com alto 
percentual de implementação ou que são cruciais: 
5.1. Controle de acesso (Access Control - 100%) 
 Permissões de procedimentos armazenados concedidas apenas a funções, 
não a usuários. 
 Contas de usuário protegidas por senhas. 
 Resultado: isso é fundamental para a LGPD, garantindo que o acesso aos 
dados de pacientes seja concedido apenas a entidades autorizadas, mas a 
falta de "menor privilégio" na política (PR.AA-05, Detail Report) ainda é um 
gap. 
5.2. Gerenciamento de contas (Account Management - 100%) 
 Mecanismos para gerenciamento e monitoramento de contas. 
 Contas, grupos e bancos de dados não utilizados removidos. 
 Contas bloqueadas após um número definido de tentativas de login falhas. 
 Resultado: ajuda a prevenir acesso não autorizado e reduz a superfície de 
ataque. 
5.3. Proteção de limites (Boundary Protection - 100%) 
 Componentes do sistema protegidos por firewall de redes externas. 
 Resultado: primeira linha de defesa essencial contra intrusões. 
5.4. Proteção de comunicação (Communication Protection - 87.5% a 100%) 
 Bloqueio e registro de roteamento de origem solto e estrito. 
 Servidores públicos em DMZ (NA, indicando que a configuração é apropriada 
ou não aplicável). 
 Regras de firewall de egresso revisadas e implementadas. 
 Regras e tabelas de estado revisadas. 
 Tráfego ICMP de entrada e saída negado, exceto se permitido. 
 Tráfego externo direto para servidores críticos bloqueado por padrão. 
 Tráfego para servidor de e-mail restrito a protocolo e porta específicos. 
 Uso de VLANs privadas para comunicação sensível. 
 Protocolos de rede não utilizados desativados. 
 Resultado: fortalece a segurança da rede e do tráfego de dados, protegendo 
a confidencialidade e integridade dos dados durante a transmissão. 
5.5. Criptografia (Encryption - 100%) 
 Comunicações de impressoras de rede criptografadas. 
 Chaves criptográficas alteradas periodicamente e geradas por padrões 
reconhecidos. 
 Comunicações de dados para e do nó criptografadas. 
 Backups de dispositivos criptografados. 
 Resultado: a criptografia de dados em trânsito e em repouso é um pilar 
fundamental da segurança da informação e da proteção de dados pessoais, 
mitigando significativamente o risco de acesso não autorizado e vazamento 
de informações de pacientes. 
5.6. Registro (Logging - 80%) 
 Eventos como tentativas de login falhas e ações de sistema de arquivos falhas 
são registrados. 
 Administradores de sistema notificados de potenciais ameaças. 
 Registro inclui alterações críticas em arquivos de host, atividade de conexão 
não autorizada/autorizada, criação de rede ad-hoc. 
 Eventos de autenticação e administrativos registrados. 
 Resultado: a geração de logs é crucial para detecção e auditoria. No entanto, 
a falha em arquivar logs de forma segura para análise offline e a falta de 
disponibilidade para monitoramento contínuo (PR.PS-04, Site Detail Report) 
são vulnerabilidades que limitam a eficácia desses logs. 
5.7. Práticas de gerenciamento (Management Practices - 92.86%) 
 Tela de login exibe banner de segurança. 
 Firewalls pessoais administrados centralmente. 
 Usuários são obrigados a fazer treinamento de segurança antes de acessar o 
sistema. 
 Banco de dados hospedado em servidor dedicado (não compartilhado com 
servidores de arquivo/impressão/web). 
 Auditorias regulares de segurança e violações de permissão. 
 SO, banco de dados e logs em partições lógicas/físicas separadas. 
 Servidores de teste/desenvolvimento em segmento de rede diferente da 
produção. 
 Permissões de conta de usuário/administrador baseadas em princípios de 
menor privilégio. 
 Testes de segurança frequentes e regulares (manual/automatizado). 
 Contas administrativas padrão renomeadas. 
 Contas/grupos não utilizados removidos. 
 Resultado: muitos controles operacionais são robustos. A existência de menor 
privilégio contradiz a inexistência de definição de política e revisão (PR.AA-
05, Site Detail Report), indicando que a prática pode existir, mas não é 
formalizada ou consistentemente aplicada via política. A exigência de 
treinamento inicial é positiva, mas não aborda a necessidade de treinamento 
contínuo e especializado (PR.AT-01/02, Site Detail Report). 
5.8. Senha (Password - 100% em todas as categorias) 
 Reutilização de senhas não permitida. 
 Política de senhas fortes para administradores e usuários. 
 Senhas padrão alteradas. 
 Política para alteração periódica de senhas. 
 Nomes de usuário e senhas padrão para componentes do sistema alterados. 
 Resultado: a política de senhas fortes e sua aplicação são um dos controles 
de segurança mais básicos e eficazes para proteger o acesso a sistemas e 
dados. 
5.9. Acesso físico (Physical Access - 100%) 
 Servidores críticos fisicamente seguros (em sala trancada). 
 Resultado: protege a infraestrutura central de dados de acessos não 
autorizados. 
5.10. Políticas e procedimentos gerais (Policies & Procedures General - 88.89%) 
 Políticas para aplicação periódica de patches de segurança, backup de 
software/dados críticos, anti-malware, remoção de compartilhamentos de 
arquivo/pasta não necessários, bloqueio de sessões inativas, descarte de 
dispositivos (limpeza de armazenamento permanente), backup de 
configuraçõesde firewall, aplicação de patches de firmware. 
 Resultado: a existência de políticas operacionais é positiva, mas a ausência 
de governança geral de políticas (GV.PO-02, Site Detail Report) sugere que, 
embora políticas existam, a governança sobre a revisão, atualização, 
comunicação e aplicação dessas políticas para refletir mudanças em 
requisitos, ameaças e missão organizacional é deficiente. 
5.11. Proteção do roteador (Securing the Router - 100%) 
 Pacotes de entrada com endereços inválidos negados. 
 Acesso remoto a roteadores restrito a SSH. 
 Resultado: reduz a superfície de ataque na borda da rede. 
5.12. Proteção do sistema (Securing the System - Monitoring & Malware - 100%) 
 Sincronização de tempo do sistema. 
 Eventos registrados e alertas emitidos para assinaturas de ataque, perfis de 
ataque comuns, anomalias de protocolo, varreduras de porta TCP/UDP. 
 Administração, transferências de log e atualizações de sistema via protocolos 
seguros (HTTPS, SSH, SFTP, SNMPv3). 
 Capacidades de IDS (detecção baseada em anomalia, HIDS, NIDS, detecção 
de root kit, detecção baseada em assinatura, detecção baseada em pilha, 
capacidade de parar/mitigar ataques conhecidos, alertas oportunos, 
monitoramento de saúde). 
 Capacidades WIDS. 
 Resultado: indica uma forte capacidade de detecção de intrusões e proteção 
contra malware. No entanto, como apontado no Site Detail Report, a falta de 
integração da inteligência de ameaças (DE.AE-07) e correlação de 
informações (DE.AE-03) pode limitar a eficácia dessas ferramentas 
avançadas. 
5.13. Proteção de sistema e comunicações (System and Communications 
Protection - 100%) 
 Tráfego de câmeras de segurança devidamente seguro em rede não segura. 
 Resultado: sistemas de vigilância robustos. 
5.14. Autenticação de usuário (User Authentication - 100%) 
 Utilização de mecanismos de autenticação (Active Directory, LDAP, Kerberos). 
 Autenticação via meios seguros (SSL, SSH apenas), evitando protocolos de 
texto claro. 
 Resultado: fortalece a identidade e o acesso, mas a governança em torno das 
permissões ainda é um ponto fraco (PR.AA-05). 
6. Governança de dados e seus desafios 
A governança de dados é o conjunto de processos, políticas, padrões e métricas que 
garantem o uso eficaz e seguro das informações em uma organização. Na Health Labs, a 
análise dos documentos revela que a governança de dados é uma área que necessita de 
atenção e fortalecimento urgentes. 
6.1. Políticas e procedimentos existentes (ou a ausência deles) 
 Ausência de estrutura dedicada: não há menção explícita a uma estrutura 
dedicada de governança de dados ou a um papel de Encarregado de Dados 
(DPO), o que sugere que a responsabilidade pela governança de dados pode 
estar fragmentada ou não ser uma prioridade estratégica clara. Uma estrutura 
formal é essencial para garantir a responsabilidade e a coordenação das 
iniciativas de dados. 
 Ausência de classificação de dados: como mencionado anteriormente, a falta 
de uma política abrangente de classificação de dados é um obstáculo 
fundamental para a governança eficaz. Sem saber quais dados são mais 
sensíveis ou críticos, é impossível aplicar controles de segurança e 
privacidade de forma otimizada. 
 Políticas de retenção vagas: as políticas de retenção de dados vagas criam 
riscos de conformidade e aumentam a superfície de ataque. A retenção 
excessiva de dados pode violar regulamentações de privacidade como a 
LGPD e, em caso de violação, expor mais informações do que o necessário. 
 Controles de acesso inadequados: a fraqueza nos controles de acesso, como 
a falta de MFA e políticas de senha fracas, impacta diretamente a governança 
de dados, pois não há garantia de que apenas usuários autorizados acessem 
informações sensíveis. 
6.2. Conformidade regulatória 
Embora não haja menção explícita a regulamentações como a LGPD ou HIPAA, a 
natureza dos dados de saúde manipulados pela Health Labs implica que a conformidade 
com tais leis é mandatório. As vulnerabilidades e a falta de governança de dados 
identificadas colocam a Health Labs em risco significativo de não conformidade, o que pode 
resultar em multas pesadas, danos à reputação e perda de confiança dos pacientes. 
6.3. Gestão do ciclo de vida dos dados 
A gestão do ciclo de vida dos dados (coleta, armazenamento, uso, compartilhamento, 
descarte) parece ter lacunas: 
 Coleta e uso: não há detalhes explícitos sobre políticas de consentimento ou 
minimização de dados na coleta, mas a manipulação de dados de saúde exige 
rigor. 
 Armazenamento: a presença de dados não criptografados em repouso e a 
falta de classificação de dados indicam falhas no armazenamento seguro. 
 Compartilhamento: a ausência de soluções DLP e a falta de políticas claras 
de acesso podem levar ao compartilhamento inadequado de dados. 
 Descarte: as políticas de retenção vagas sugerem que o descarte seguro e 
oportuno de dados pode não ser adequadamente gerenciado. 
6.4. Desafios específicos relacionados à governança de dados 
 Cultura organizacional: a falta de priorização de ferramentas específicas de 
governança de dados sugere que a cultura organizacional pode não estar 
totalmente alinhada com a importância da proteção de dados. 
 Visibilidade e controle: a ausência de monitoramento e log suficientes, 
juntamente com a falta de classificação de dados, impede que a Health Labs 
tenha uma visibilidade clara sobre onde seus dados sensíveis residem, quem 
os acessa e como são usados. Isso dificulta o controle efetivo sobre as 
informações. 
 Recursos e orçamento: embora haja orçamento alocado para atualizações de 
segurança, a não priorização de ferramentas de governança de dados pode 
indicar uma alocação inadequada de recursos para esta área crítica. 
7. Análise da governança de dados sob a LGPD 
A LGPD impõe rigorosas obrigações de segurança, accountability e direitos dos 
titulares de dados. Com base na análise dos documentos, a Health Labs apresenta um risco 
considerável em várias frentes de governança de dados: 
1. Inventário de dados (Art. 37, 38 da LGPD): a falha mais gritante é a falta de 
inventários de dados e metadados (ID.AM-07). Sem isso, a Health Labs não 
consegue: 
 Saber quais dados pessoais trata; 
 Demonstrar a finalidade e a base legal do tratamento; 
 Responder adequadamente às solicitações dos titulares de dados 
(acesso, correção, exclusão); 
 Realizar avaliações de impacto à proteção de dados (DPIA). 
Isso coloca a empresa em total não conformidade com os princípios da LGPD, 
como o da finalidade, necessidade e segurança. 
2. Gestão de riscos (Art. 6, 46 da LGPD): a falta de uma metodologia 
padronizada para avaliação e priorização de riscos (GV.RM-06), a não 
definição do apetite a risco (GV.RM-02) e a ausência de revisão da estratégia 
de segurança (GV.OV-01, GV.OV-02, GV.OV-03) são falhas críticas. A LGPD 
exige que as organizações demonstrem que a segurança é baseada em uma 
gestão de riscos robusta e que a empresa é "accountable". 
3. Resposta a incidentes e notificação (Art. 48 da LGPD): as deficiências nos 
planos de resposta a incidentes (ID.IM-04), na coleta de dados (RS.AN-07), 
na estimativa de magnitude (RS.AN-08) e na comunicação e notificação a 
partes interessadas (RS.CO-02, RS.CO-03) são de alto risco. A LGPD exige 
notificação rápida à ANPD e aos titulares em caso de incidentes de segurança 
que possam acarretar risco ou dano relevante. A ineficiência aqui pode levar 
a multas e graves danos reputacionais. 
4. Princípio do menor privilégio e segregação de funções (Art. 6, 46 da 
LGPD): embora existam controles técnicos de gerenciamento de contas, a 
falta de uma política clara para o menor privilégio (PR.AA-05) e segregação 
de funções aumenta o risco de acesso indevido a dados de saúde, violando o 
princípio da segurança e da minimização dos dados. 
5. Treinamento e conscientização (Art. 6 da LGPD): aausência de 
treinamento contínuo e especializado (PR.AT-01, PR.AT-02) para os 
funcionários é uma vulnerabilidade humana significativa. A LGPD exige que 
medidas de segurança sejam aplicadas por todos os envolvidos no tratamento 
de dados, e isso inclui a conscientização sobre as melhores práticas. 
6. Segurança da cadeia de suprimentos (Art. 6, 46 da LGPD): a Health Labs, 
por ser uma empresa de TI que integra sistemas, deve gerenciar 
rigorosamente os riscos com fornecedores. As falhas na inclusão de terceiros 
nos planos de incidentes (GV.SC-08) e na gestão de risco pós-contrato 
(GV.SC-10) são grandes vulnerabilidades, pois uma violação em um 
fornecedor pode ser atribuída à Health Labs, sob a ótica da LGPD. 
8. Conexões e interdependências 
É crucial entender como as ameaças e vulnerabilidades se interligam com a 
governança de dados na Health Labs: 
 Ameaças e vulnerabilidades exacerbadas pela governança de dados 
deficiente: 
o A falta de classificação de dados (governança) significa que dados 
altamente sensíveis podem ser armazenados em sistemas com 
sistemas operacionais desatualizados ou sem MFA, tornando-os alvos 
fáceis para ransomware ou APTs. 
o Políticas de retenção vagas (governança) aumentam a quantidade de 
dados disponíveis para exfiltração em caso de um ataque de phishing 
bem-sucedido ou um insider malicioso. 
o A ausência de soluções DLP (governança) torna a empresa vulnerável 
à exfiltração de dados por insiders maliciosos ou por malware que se 
infiltra na rede. 
o A falta de monitoramento e log (governança/segurança) impede a 
detecção de acessos não autorizados a dados, mesmo que as 
credenciais padrão ou senhas fracas sejam exploradas. 
 Impacto das ameaças e vulnerabilidades na governança de dados: 
o Uma violação de dados resultante de ransomware ou phishing 
compromete diretamente a confidencialidade e a integridade dos 
dados, minando os princípios da governança de dados. 
o Ataques bem-sucedidos podem levar à perda de controle sobre os 
dados, dificultando a conformidade com as regulamentações de 
privacidade e a manutenção da confiança dos pacientes. 
o A interrupção dos sistemas críticos devido a ataques (como 
ransomware) afeta a disponibilidade dos dados, impedindo o acesso e 
o uso legítimo das informações. 
Em essência, a governança de dados atua como a espinha dorsal para uma postura 
de segurança cibernética robusta. Sem uma governança de dados eficaz, as medidas de 
segurança implementadas podem ser ineficazes, pois não há uma compreensão clara do 
que precisa ser protegido, onde está e como deve ser tratado. 
9. Recomendações e próximos passos 
Para mitigar as ameaças e vulnerabilidades identificadas e fortalecer sua postura de 
segurança e conformidade com a LGPD, a Health Labs deve considerar as seguintes ações 
estratégicas e táticas: 
9.1. Estruturação de governança de dados (prioridade máxima) 
 Inventário de dados e ativos: iniciar imediatamente a criação e manutenção 
de inventários detalhados de todos os dados (pessoais, sensíveis, etc.) e seus 
metadados (ID.AM-07). Isso inclui onde os dados estão armazenados, seu 
ciclo de vida, quem tem acesso e para qual finalidade. Isso é a base da LGPD. 
 Inventário de hardware e software: consolidar e manter inventários completos 
de todos os ativos de hardware e software (ID.AM-01, ID.AM-02). 
 Classificação e priorização de ativos: classificar os ativos com base em sua 
criticidade e impacto na missão, especialmente os relacionados a dados de 
pacientes (ID.AM-05), para focar os esforços de proteção. 
9.2. Fortalecimento da gestão de riscos 
 Definir apetite a risco: formalizar e comunicar claramente o apetite e tolerância 
a risco da organização (GV.RM-02). 
 Metodologia de avaliação de risco: implementar uma metodologia 
padronizada para calcular, documentar, categorizar e priorizar riscos 
cibernéticos (GV.RM-06). 
 Revisão estratégica contínua: estabelecer um processo formal para revisar e 
ajustar a estratégia de gerenciamento de riscos cibernéticos regularmente 
(GV.OV-01, GV.OV-02, GV.OV-03), garantindo que ela se alinhe às ameaças 
em evolução e aos requisitos da LGPD. 
9.3. Otimização da resposta a incidentes 
 Desenvolver planos de resposta abrangentes: criar e testar rigorosamente 
planos de resposta a incidentes cibernéticos que afetem as operações e os 
dados de pacientes (ID.IM-04). Esses planos devem incluir procedimentos 
claros para coleta de evidências (RS.AN-07), estimativa de magnitude 
(RS.AN-08), comunicação interna e externa (RS.CO-02, RS.CO-03) e 
documentação pós-incidente (RC.RP-06). 
 Simulados e exercícios (Tabletop Exercises): realizar exercícios regulares 
para testar a eficácia dos planos de resposta a incidentes com equipes 
multifuncionais. 
9.4. Melhoria contínua da detecção e monitoramento 
 Monitoramento contínuo de logs: garantir que os registros de log gerados 
sejam efetivamente utilizados para monitoramento contínuo (PR.PS-04). Isso 
pode envolver a implementação de um sistema SIEM (Security Information 
and Event Management). 
 Arquivamento seguro de logs: implementar um sistema de arquivamento 
seguro de logs em um host diferente para análise offline, conforme identificado 
como "Não" no "Site Cybersecurity Plan". 
 Integração de inteligência de ameaças: integrar a inteligência de ameaças 
cibernéticas de fontes externas nos processos de análise e detecção (DE.AE-
07). 
 Correlação de eventos: desenvolver capacidades para correlacionar 
informações de múltiplas fontes para identificar padrões de ataque complexos 
(DE.AE-03). 
9.5. Reforço dos controles de proteção e acesso 
 Políticas de acesso baseadas em menor privilégio: formalizar e aplicar 
rigorosamente políticas de acesso baseadas no princípio do menor privilégio 
e segregação de funções, garantindo que as permissões de acesso aos dados 
de pacientes sejam estritamente limitadas ao necessário para a função 
(PR.AA-05). 
 Testes regulares de backup: além de criar e proteger backups, é imperativo 
testá-los regularmente para garantir que possam ser restaurados com 
sucesso em caso de necessidade (PR.DS-11). Isso garante a disponibilidade 
dos dados de saúde. 
 Gestão de configuração e patches: estabelecer e aplicar práticas robustas de 
gerenciamento de configuração e garantir que hardware e software sejam 
mantidos, substituídos e removidos de forma oportuna e segura (PR.PS-01, 
PR.PS-02, PR.PS-03). 
9.6. Programa de conscientização e treinamento em segurança 
 Treinamento abrangente e contínuo: desenvolver e implementar um programa 
de treinamento de conscientização em cibersegurança obrigatório e contínuo 
para todos os funcionários, abordando os riscos específicos do setor de saúde 
e as obrigações da LGPD. Incluir treinamento especializado para funções com 
acesso a dados sensíveis de pacientes (PR.AT-01, PR.AT-02). 
9.7. Gestão de risco de terceiros (Supply Chain Risk Management) 
 Cláusulas contratuais fundamentadas na LGPD: Incluir cláusulas claras e 
exigentes sobre segurança da informação e LGPD nos contratos com todos 
os fornecedores e parceiros que tratam dados pessoais. 
 Inclusão de fornecedores em planos de incidentes: assegurar que 
fornecedores relevantes sejam incluídos nos planos de resposta e 
recuperação de incidentes (GV.SC-08). 
 Planos de desligamento: desenvolver planos de gestão de risco na cadeia de 
suprimentos que incluam disposições para atividades pós-conclusão de 
parcerias, como a devolução ou exclusão segura de dados (GV.SC-10). 
10. Conclusão 
Embora a Health Labs tenha implementado controles técnicos importantes, 
especialmente em criptografia e autenticação, as vulnerabilidades sistêmicas na 
governança, gerenciamento de riscos, gestão do ciclo de vida de dados e resposta a 
incidentes representam um risco significativo e direto para a conformidade com a LGPD e 
a proteção dos dados de saúde de seus pacientes. 
O desafioreside não apenas na implementação de mais controles técnicos, mas na 
estruturação de um programa de cibersegurança maduro e holístico. É essencial 
transformar as lacunas identificadas em um roteiro de melhoria contínua, com foco 
estratégico na proteção dos dados pessoais. Ao fazer isso, a Health Labs não só mitigará 
as ameaças cibernéticas, mas também consolidará sua reputação como uma empresa 
confiável e em conformidade no vital setor de TI da saúde. 
Dessa forma, é essencial que a Health Labs defina estratégias robustas para 
priorizar seus investimentos em segurança, garantindo que os recursos sejam alocados 
onde são mais necessários para proteger as informações mais valiosas da empresa e seus 
pacientes. 
 
TESTE DE PERFORMANCE – TP3 
Projeto 
Desenvolver um plano integrado que assegure a resiliência operacional e a 
proteção de informações em situações de crise ou ataques de engenharia 
social. 
Desafio 
Você atuará como especialista em segurança da informação e deverá propor 
soluções para garantir a continuidade dos negócios, mitigar ameaças, proteger 
dados e responder de forma eficiente a possíveis desastres em uma empresa 
fictícia que lida com dados sensíveis e que está sob risco de ataques de 
engenharia social seguidos de ataques que comprometam a continuidade das 
operações e a segurança dos dados. Você deverá identificar possíveis 
cenários de ataque de engenharia social (como phishing, pretexting ou spear-
phishing) e táticas psicológicas usadas em ataques de engenharia social para 
manipular funcionários para inserção de malwares ou acessar informações 
confidenciais. 
Com base nos riscos identificados, você deve elaborar um plano de 
continuidade de negócios que garanta que as operações da empresa 
continuem em caso de ataque ou desastre, focado na rápida retomada de 
operações, levando em consideração a segurança dos dados e a mitigação de 
impactos. Além disso, implementar um processo de classificação de dados 
que permita a identificação e proteção de dados sensíveis, assegurando que 
apenas partes autorizadas possam acessá-los, reduzindo a liberação de 
acesso por funcionários vítimas de engenharia social. 
Entrega 
 Um plano de continuidade de negócios detalhado e um plano de 
recuperação de desastres, com foco na mitigação de riscos relacionados 
à engenharia social. 
 Um relatório de análise de riscos, descrevendo as principais ameaças 
cibernéticas e os impactos na continuidade operacional. 
 Um plano de classificação de dados sensíveis e políticas de governança 
de dados que garantam a conformidade com regulamentações e a 
proteção de informações críticas. 
Plano de Continuidade de Negócios 
1. Introdução 
Em um cenário cada vez mais dinâmico e interconectado, a continuidade das 
operações é um fator crítico para empresas que atuam com soluções tecnológicas na área 
da saúde. A Health Labs, como fornecedora de sistemas de prontuário eletrônico, 
plataformas de gestão hospitalar, ferramentas de telemedicina, análise de dados clínicos e 
segurança da informação, está inserida em um ambiente altamente sensível, onde a 
indisponibilidade de serviços pode impactar diretamente a qualidade da assistência 
prestada a pacientes, a conformidade com regulamentações legais e a confiança de 
clientes e parceiros. 
Diante desse contexto, a elaboração de um Plano de Continuidade de Negócio 
(PCN) se torna essencial para garantir a resiliência organizacional da Health Labs. Este 
plano tem como propósito preparar a empresa para responder de forma eficaz a incidentes 
que possam interromper suas atividades críticas, assegurando a rápida retomada de 
operações e a minimização de impactos financeiros, operacionais e reputacionais. 
2. Objetivo e benefícios 
Objetivo geral: 
Estabelecer diretrizes e procedimentos para a continuidade das operações da 
Health Labs diante de situações de crise ou interrupções significativas, visando a preservar 
os ativos críticos, assegurar o cumprimento de obrigações legais e regulatórias, manter a 
confiança dos stakeholders e garantir a entrega contínua dos serviços essenciais ao setor 
de saúde. 
Benefícios esperados: 
1. Redução de riscos operacionais: identificação de processos críticos e 
antecipação de falhas, com ações preventivas e reativas bem definidas. 
2. Agilidade na resposta a incidentes: capacidade de reação rápida e 
coordenada diante de eventos disruptivos, diminuindo o tempo de inatividade. 
3. Proteção à reputação institucional: manutenção da credibilidade junto a 
clientes, parceiros, órgãos reguladores e à sociedade. 
4. Conformidade com legislações e normas: atendimento a exigências legais, 
como a Lei Geral de Proteção de Dados (LGPD), e alinhamento com boas 
práticas internacionais. 
5. Melhoria contínua: fortalecimento da cultura organizacional de prevenção, 
preparação e recuperação frente a crises. 
6. Continuidade de serviços essenciais: garantia de que os sistemas de gestão 
hospitalar, prontuários eletrônicos e soluções de telemedicina permaneçam 
funcionais mesmo em situações adversas. 
3. Metodologia 
A metodologia adotada para a elaboração do Plano de Continuidade de Negócio da 
Health Labs está fundamentada nas normas internacionais ABNT NBR ISO 22301:2020 
(Segurança e Resiliência – Sistemas de Gestão de Continuidade de Negócios – 
Requisitos), ABNT NBR ISO 22313:2020 (Diretrizes para a implementação e manutenção 
de um Sistema de Gestão de Continuidade de Negócios (SGCN)) e ABNT NBR ISO 
22317:2023 (Segurança e Resiliência – Sistemas de Gestão de Continuidade de Negócios 
– Diretrizes para Análise de Impacto nos Negócios (BIA)). 
Essas normas oferecem uma abordagem sistemática e estruturada para identificar 
ameaças potenciais à organização e desenvolver estratégias eficazes de resposta, 
recuperação e restauração. O plano foi construído com base em etapas essenciais como: 
 Entendimento do contexto organizacional; 
 Identificação de processos críticos e avaliação de impactos (BIA – Business 
Impact Analysis); 
 Análise de riscos e definição de estratégias de continuidade; 
 Elaboração de planos de resposta e recuperação; 
 Treinamento, testes e melhoria contínua. 
Essa abordagem proporciona à Health Labs um modelo de gestão robusto, com 
foco na resiliência operacional e na capacidade de adaptação frente a eventos imprevistos. 
4. Contexto Organizacional 
4.1. Cenário operacional 
A Health Labs é uma empresa de médio porte especializada no desenvolvimento e 
fornecimento de soluções tecnológicas para o setor da saúde. Suas atividades abrangem 
o desenvolvimento de sistemas (como prontuários eletrônicos e plataformas de gestão 
hospitalar), suporte à telemedicina, análise de dados médicos, segurança da informação e 
integração entre sistemas diversos. A empresa atende hospitais, clínicas, consultórios, 
operadoras de saúde e profissionais da área médica, sendo responsável por garantir a 
integridade, a confidencialidade e a disponibilidade de informações sensíveis e críticas à 
operação de seus clientes. 
A organização opera em um ambiente regulamentado, sujeito a legislações 
específicas como a Lei Geral de Proteção de Dados Pessoais (LGPD) e normas técnicas 
voltadas à segurança e interoperabilidade em saúde. O contexto operacional também é 
caracterizado por alta dependência de tecnologias digitais, conectividade com terceiros 
(clientes, parceiros e fornecedores) e exposição a ameaças cibernéticas complexas. 
4.2. Riscos e ameaças 
Dentre os riscos mapeados, destaca-se a crescente sofisticação de ataques de 
engenharia social, que têm sido utilizados como vetor inicial para comprometimento da 
segurança cibernética e continuidade operacional. A Health Labs está particularmente 
exposta a esse tipo de ameaça devido à sua atuação intensiva com dados sensíveis e ao 
contato frequente com instituições médicas que também podem ser alvos secundários dos 
ataques. 
Cenários de ataque identificados: 
 Phishing: