- Um roadmap de cibersegurança protege processos de negócio, não apenas ativos. Comece pelo que paralisaria a operação e trabalhe de volta aos sistemas, dados e controles que protegem isso.
- A sequência correta: contexto do negócio → inventário de ativos → ameaças e risco → maturidade atual → estado-alvo → análise de lacunas → priorização → plano faseado → responsabilidade e orçamento → testes → governança.
- Pontuação de maturidade em pessoas, processos e tecnologia fornece um ponto de partida mais honesto do que uma análise binária de "presente ou ausente".
- Resposta a incidentes pertence aos primeiros 90 dias. Você precisa de capacidade de resposta antes de ter um programa maduro.
- Três horizontes de roadmap funcionam na prática: Estabilizar (0 a 90 dias), Construir base (3 a 12 meses), Amadurecer (12 a 24+ meses). Não assuma compromissos de 36 meses: ameaças, tecnologia e prioridades do negócio mudam rápido demais.
- O resultado do roadmap é uma tabela, não um deck estratégico: prioridade, risco, iniciativa, responsável, dependência, prazo, esforço e métrica de sucesso para cada item.
O que um roadmap de cibersegurança realmente é
A maioria das empresas brasileiras trata a cibersegurança como uma coleção de produtos: antivírus aqui, firewall ali, uma política de senhas porque o fornecedor de TI pediu. Cada controle existe de forma isolada. Quando um incidente ocorre, não há lista priorizada, nenhum responsável claro e nenhum plano.
Um roadmap de cibersegurança registra sua postura de segurança atual, define o estado-alvo que seu perfil de risco e obrigações legais exigem e mapeia quais controles fecham a lacuna, em ordem, com responsáveis nomeados e datas. Ele se vincula ao registro de riscos, tem uma dimensão de orçamento e é atualizado em cadencia regular. Isso o torna um plano de investimento, não uma lista de compras.
Etapa 1: Entenda o negócio
Programas de segurança que começam pelo inventário de ativos ou pela seleção de framework pulam a pergunta mais importante: o que realmente prejudicaria esta organização? Uma vulnerabilidade em um servidor público pode ser tecnicamente grave. Um comprometimento da plataforma de identidade pode paralisar todos os serviços do negócio simultaneamente. Esses não são riscos equivalentes, e um roadmap que os trata como tal desperdiça orçamento nos problemas errados.
Estabeleça o contexto do negócio antes de catalogar ativos:
- Serviços e processos críticos: quais atividades, se interrompidas, causariam danos materiais a clientes, receita ou posição regulatória
- Joias da coroa - sistemas e dados: os sistemas e conjuntos de dados cujo comprometimento representaria o pior cenário: dados financeiros, PII de clientes, propriedade intelectual, tecnologia operacional
- Tempo máximo de inatividade tolerável: para cada serviço crítico, quanto tempo a organização consegue operar sem ele antes que as consequências se tornem graves
- Obrigações legais e apetite a risco: requisitos setoriais (LGPD, Resolução Bacen 4.658, regulamentos ANS, ANATEL, ANPD) e a tolerância articulada da organização ao risco de segurança
- Dependências críticas de terceiros: MSPs, provedores SaaS, plataformas em nuvem e fornecedores com acesso privilegiado ou relações de compartilhamento de dados
- Prioridades do negócio nos próximos 12 a 24 meses: aquisições planejadas, expansão geográfica, novos produtos, migrações para nuvem ou terceirização que mudarão materialmente a superfície de ataque
Com esse contexto, cada controle tem uma ancoração concreta no negócio e o roadmap passa a ser algo que um conselho pode avaliar e financiar.
Etapa 2: Construa o inventário de ativos e dependências
Você não consegue avaliar, priorizar ou proteger ativos que não catalogou. Um inventário útil abrange quatro categorias: hardware (cada dispositivo que se conecta à rede ou acessa dados corporativos, incluindo dispositivos pessoais usados no trabalho híbrido); software e serviços (cada aplicativo, plataforma em nuvem e ferramenta SaaS em uso ativo, incluindo TI sombra e integrações de terceiros); dados (onde dados sensíveis estão armazenados, quem pode acessá-los e como circulam entre sistemas); e pessoas e terceiros (usuários, contratados, fornecedores com acesso a sistemas e provedores de serviços gerenciados).
A maioria das organizações encontra dados sensíveis em mais lugares do que esperava: arquivo de e-mail, pastas no OneDrive sem controle, drives compartilhados sem revisão de acesso, planilhas usadas como bancos de dados improvisados. Comece pelo que você consegue catalogar agora. Priorize precisão sobre completude e vincule tudo de volta aos serviços críticos da etapa 1.
Etapa 3: Identifique ameaças e avalie riscos
Os ataques que afetam empresas brasileiras em 2025 e 2026 seguem padrões conhecidos: ransomware criptografando sistemas e exigindo resgate; fraude em e-mail corporativo redirecionando pagamentos ou extraindo dados; roubo de credenciais via phishing e ataques de password spray em contas na nuvem; e comprometimento via cadeia de fornecimento por meio de um fornecedor de software ou MSP confiável. Sua análise de risco foca nesses padrões, aplicados aos seus ativos e contexto de negócio específicos.
Joias da coroa e impacto no negócio
Para cada serviço crítico da etapa 1, mapeie os ativos específicos dos quais ele depende. Então pergunte: quais são as consequências para o negócio se esse ativo for comprometido ou ficar indisponível? A resposta orienta a priorização de forma mais confiável do que uma pontuação genérica de severidade.
Pontuação de risco
Para cada ativo ou serviço, pontue a probabilidade de um ataque bem-sucedido (1 a 5) e o impacto no negócio caso ele ocorra (1 a 5). Multiplique as pontuações. Os controles que reduzem pontuações de alta probabilidade e alto impacto geram o maior retorno por real investido.
Etapa 4: Avalie sua maturidade atual
Uma análise de lacunas binária ("presente" ou "ausente") dá uma imagem distorcida da postura de segurança real da maioria das organizações. Um controle que existe mas é aplicado de forma inconsistente, nunca testado ou não documentado não equivale a um controle que funciona de forma confiável. A pontuação de maturidade expe a diferença.
Pontue cada domínio de segurança em uma escala de cinco pontos: 0 = não implementado, 1 = ad hoc (existe informalmente), 2 = definido (documentado e aplicado de forma consistente), 3 = gerenciado (monitorado com métricas), 4 = medido (compreendido quantitativamente), 5 = otimizado (melhorado continuamente com base em evidências).
Avalie em três dimensões: pessoas, processos e tecnologia:
Pontue esses domínios honestamente; o resultado é sua linha de base. A lacuna entre essa linha de base e seu estado-alvo (etapa 5) gera a lista de iniciativas. Trate qualquer domínio com pontuação 0 ou 1 como prioridade, independentemente da posição na análise de risco. Controles ad hoc não são controles.
Etapa 5: Defina seu estado-alvo
Escolha um framework reconhecido como ponto de ancoragem para o estado-alvo. Três são mais relevantes para empresas brasileiras:
Construa o roadmap com base no risco do negócio. Use frameworks e regulamentações para definir requisitos de controle e validar que o programa cobre as áreas necessárias.
Etapa 6: Execute a análise de lacunas
Com uma linha de base de maturidade (etapa 4) e um framework-alvo (etapa 5), compare a maturidade atual com o estado-alvo por domínio de controle. Registre: pontuação atual, pontuação-alvo e as iniciativas que fecham a lacuna. Uma análise de lacunas só é útil se for específica o suficiente para agir: "MFA não está sendo aplicado em contas de serviço compartilhadas" é acionável; "gestão de acesso precisa melhorar" não é.
Etapa 7: Priorize
Priorização baseada em risco supera conformidade em primeiro lugar. Conformidade em primeiro lugar pergunta o que o auditor sinalizou. Baseada em risco pergunta o que reduz o risco real mais efetivo pelo menor esforço.
Classifique iniciativas em dois eixos: a redução de risco que entregam e o esforço necessário. Alta redução, baixo esforço vai primeiro. Baixa redução, alto esforço vai por último ou é postergado. Prazos regulatórios adicionam uma terceira restrição: uma obrigação da LGPD com prazo definido pode justificar a antecipação frente a uma iniciativa de maior risco sem data externa.
Etapa 8: Construa o roadmap faseado
Três horizontes de tempo funcionam para a maioria das organizações. Defina um limite máximo de 24 meses com revisão anual.
Exemplo prático de roadmap
O roadmap é uma tabela. Cada iniciativa tem um responsável nomeado, uma dependência, um prazo-alvo, uma estimativa de esforço e um critério de sucesso mensurável. Sem critérios de sucesso específicos, o acompanhamento do progresso não tem nada para comparar.
| Prioridade | Risco | Iniciativa | Responsável | Dependência | Prazo | Esforço | Métrica de sucesso |
|---|---|---|---|---|---|---|---|
| Fase 1: Estabilizar (0–90 dias) | |||||||
| Crítico | Contas na nuvem comprometidas | Aplicar MFA; bloquear autenticação legada | TI / Segurança | Inventário de identidades | 30 dias | M | 100% de cobertura de contas, legado bloqueado |
| Crítico | Ransomware / perda de dados | Backup imutável com teste trimestral de recuperação | TI | Análise de backup | 60 dias | M | Teste de recuperação aprovado, RTO validado trimestralmente |
| Alto | Vulnerabilidades sem patch | Gestão automatizada de vulnerabilidades | TI | Inventário de ativos | 90 dias | M | ≥95% dos sistemas dentro do SLA de patch |
| Alto | Sem capacidade de resposta | Plano mínimo de IR + exercício de tabletop | CISO / TI | Nenhuma | 60 dias | P | Plano documentado, exercício concluído, papéis atribuídos |
| Alto | Contas inativas (ex-colaboradores) | Procedimento de desliga de acesso no mesmo dia | TI / RH | Alinhamento com processo de RH | 30 dias | P | Nenhuma conta ativa de ex-colaborador em 48 horas |
| Fase 2: Construir base (3–12 meses) | |||||||
| Alto | Endpoints não gerenciados | Gestão de dispositivos com aplicação de conformidade | TI | Aquisição de MDM, MFA implantado | 6 meses | G | 100% de dispositivos corporativos registrados e conformes |
| Alto | Comprometimento via cadeia de fornecimento | Programa de avaliação de risco de terceiros | Segurança / Compras | Inventário de fornecedores | 6 meses | M | Todos os fornecedores críticos avaliados; requisitos contratuais existentes |
| Médio | Suscetibilidade a phishing | Conscientização de segurança + simulações trimestrais | RH / Segurança | Nenhuma | 6 meses | M | Taxa de clique <5% por dois trimestres consecutivos |
| Médio | Abuso de acesso privilegiado | Gestão de acesso privilegiado (JIT / PIM) | TI | MFA implantado | 9 meses | G | Todas as funções administrativas com ativação temporária; nenhum privilégio permanente |
| Fase 3: Amadurecer (12–24+ meses) | |||||||
| Médio | Lacunas holísticas de segurança | Programa de certificação ISO 27001 | CISO / Alta gestão | Controles maduros, sistema de gestão | 18+ meses | XG | Auditoria estágio 2 aprovada; certificado emitido |
Etapa 9: Atribua responsabilidade e orçamento
Nomeie um responsável e um orçamento financiado para cada iniciativa. Cada iniciativa também precisa de: um responsável com autoridade para entregá-la; uma estimativa de custo incluindo gastos externos e horas internas de capacidade; habilidades ou suporte externo que precisam ser contratados; e uma referência ao risco ou requisito de conformidade que aborda.
Para relatórios ao conselho, formule o orçamento como uma decisão de investimento. Cada iniciativa reduz um risco nomeado por um valor quantificável. Se um risco crítico ficar descoberto, isso precisa ser uma decisão explícita do conselho, não algo que eles descobrem depois de um incidente.
Seguradoras estabelecem controles específicos como condição de cobertura: MFA, backup imutável e procedimentos de notificação de incidentes são os requisitos mínimos mais comuns. Antes de finalizar o roadmap, revise as condições e exclusões da sua apólice. Controles exigidos pela seguradora pertencem à fase 1, independentemente de sua classificação de risco. Uma reivindicação negada porque um controle obrigatório estava ausente é custosa; isso também elimina o argumento orçamentário contra implementá-lo.
Etapa 10: Testes e mensuração
Controles não testados são suposições. Recuperação não exercitada é suposição.
Comece testando a recuperação do backup. Um backup que nunca foi restaurado não é capacidade de recuperação. Teste frente ao tempo máximo de inatividade tolerável da etapa 1. Se a recuperação levar mais tempo do que a organização consegue absorver, a arquitetura de backup precisa de ajuste.
Exercícios de resposta a incidentes (tabletop no mínimo, simulação completa conforme o programa amadurece) testam as dimensões de processo e pessoas que a tecnologia não cobre. Quem toma a decisão de isolar um sistema? Quem aprova a comunicação externa? Quem notifica a ANPD? Pratique antes que essas perguntas surjam em um incidente real.
Testes de penetração revelam se seus controles técnicos resistem à abordagem de um adversário. Direcione o escopo primeiro para os sistemas de joias da coroa.
Métricas para rastrear: cobertura de MFA (percentual de contas registradas), pontuação de conformidade de patch (percentual dentro do SLA), taxa de clique em simulações de phishing por trimestre, tempo médio para detectar e conter incidentes de segurança, e vulnerabilidades críticas abertas que ultrapassaram o SLA.
Etapa 11: Governança e atualização
Dois mecanismos mantêm o roadmap vivo. Revisões trimestrais acompanham o progresso, identificam iniciativas em atraso e atualizam o contexto de ameaças. Atualização anual revisa a análise de risco, incorpora novas ameaças, alterações regulatórias e mudanças no negócio como aquisições ou entrada em novos mercados, e reprioriza para o próximo ano.
Relatórios ao conselho traduzem o progresso de segurança em termos sobre os quais um conselho pode agir: tendência na postura de risco, incidentes no período, status de controles críticos e o que está ou não financiado. Conselhos precisam saber se o risco está subindo ou caindo e qual decisão está sendo solicitada a eles.
Alinhamento regulatório
Construa o roadmap com base no risco do negócio e os principais frameworks se tornam camadas de validação, não projetos separados.
LGPD Arts. 46-50 exigem medidas técnicas e administrativas de segurança proporcionais ao risco do tratamento de dados pessoais. O Art. 48 determina a notificação à ANPD em até 2 dias úteis após a ciência de um incidente com potencial de dano a titulares. Um plano de IR testado com um procedimento documentado de notificação é um requisito direto da LGPD, não uma adição opcional.
ISO 27001 Cláusula 6.1.2 exige um plano de tratamento de risco que vincule cada risco identificado a uma decisão de tratamento e a um controle. Esse plano é estruturalmente idêntico ao seu roadmap. Construa o roadmap corretamente e você produz o plano de tratamento de risco da ISO 27001 como resultado direto.
Resolução Bacen 4.658/2018 e normativos ANATEL e ANS exigem frameworks documentados de gestão de risco de TI, testes de resiliência e gestão de risco de terceiros para entidades reguladas nos seus setores. A estrutura do roadmap se alinha a cada uma dessas obrigações. Para entidades em escopo, testes de resiliência e avaliação de risco de terceiros pertencem à fase de construção de base.
PCI DSS se aplica a qualquer organização que processe, armazene ou transmita dados de cartão de pagamento. Os 12 requisitos do PCI DSS mapeiam diretamente para domínios do roadmap: firewalls de rede, gestão de senhas, proteção de dados armazenados, criptografia na transmissão, antivirus, desenvolvimento seguro, controle de acesso e logging. O compliance com PCI DSS não substitui um programa de segurança mais amplo, mas os seus controles técnicos pertencem à fase 1 e 2 para qualquer organização em escopo.
Um roadmap construído em torno de requisitos de conformidade aborda o que os auditores verificam, não o que mais prejudicaria a organização. Priorização baseada em risco produz uma ordem diferente.
