PDSI na prática: priorização, orçamento e resultado em Segurança da Informação

Um PDSI serve para responder a uma pergunta incômoda: com orçamento e equipe limitados, o que deve ser corrigido primeiro e como provar que o investimento reduziu risco? O plano organiza prioridades, responsáveis, dependências, custos e métricas sem transformar Segurança da Informação em uma lista de compras.

Segurança da Informação costuma perder força na mesa executiva quando chega traduzida apenas em vulnerabilidades, controles, ferramentas, siglas e requisitos técnicos. Um conselho de administração, um CEO ou um CFO dificilmente precisa saber quantas regras existem em um firewall ou quantos agentes de EDR foram instalados. Eles precisam entender quais riscos ameaçam receita, operação, clientes, propriedade intelectual, conformidade e estratégia, quanto custa reduzir esses riscos e como saber se o investimento está funcionando.

O Planejamento de Segurança da Informação (PDSI) organiza essa conversa. Ele registra o estado atual, os riscos que merecem prioridade, o estado-alvo, as iniciativas necessárias, o investimento previsto e as evidências que mostrarão se houve melhora. Não tenta prever todos os ataques; cria uma sequência de decisões que pode ser revisada quando o ambiente ou o orçamento mudam.

O que é um PDSI

O PDSI pode ser entendido como um plano diretor aplicado à Segurança da Informação: um documento vivo que organiza objetivos, prioridades, responsabilidades, investimentos, cronograma e métricas para um horizonte definido. Dependendo da organização, esse horizonte pode ser anual, bienal ou de três anos, com revisões periódicas.

Seu ponto de partida não deve ser a tecnologia. Deve ser o contexto do negócio. Isso significa compreender quais processos sustentam receita, quais operações não podem parar, quais informações são sensíveis, quais obrigações regulatórias e contratuais existem, quais transformações tecnológicas estão previstas e qual nível de risco a liderança está disposta a aceitar.

Essa lógica está alinhada ao NIST Cybersecurity Framework 2.0, que elevou Govern ao mesmo nível das funções Identify, Protect, Detect, Respond e Recover. A mudança reforça que estratégia, expectativas, políticas e gestão de risco precisam orientar as demais atividades de cibersegurança, e não aparecer como um complemento posterior.

Também se conecta à ISO/IEC 27001, que estrutura a Segurança da Informação como um sistema de gestão baseado em contexto, avaliação de riscos, controles, responsabilidades, monitoramento e melhoria contínua. O PDSI não substitui um SGSI, mas pode funcionar como o mecanismo executivo que transforma essas necessidades em programa, orçamento e agenda de implementação.

O erro clássico: começar pelo catálogo de controles

Um PDSI fraco normalmente começa com frases como “implantar DLP”, “adquirir SIEM”, “criar SOC”, “implementar PAM” ou “contratar pentest”. Todas essas iniciativas podem ser válidas, mas ainda não explicam por que devem receber prioridade.

Considere uma empresa industrial que depende de um ERP para produção, faturamento e logística. Se a organização identificar que contas administrativas compartilhadas e ausência de MFA podem permitir comprometimento do ambiente central, o problema executivo não é “falta de PAM” ou “falta de MFA”. O problema é que uma identidade comprometida pode interromper produção e faturamento. PAM, MFA, segregação de privilégios e monitoramento passam a ser respostas possíveis a um risco de negócio claramente definido.

Essa inversão muda a qualidade da discussão. Em vez de perguntar “quanto custa a ferramenta?”, a organização passa a perguntar “qual exposição reduzimos com esse investimento, em quanto tempo e com quais evidências?”.

O que precisa aparecer no plano para ele ser útil

Embora cada empresa exija adaptações, um PDSI consistente normalmente contém algumas camadas essenciais.

1. Contexto estratégico e escopo

O plano deve registrar quais unidades, processos, ativos e geografias estão cobertos, quais objetivos corporativos influenciam o planejamento e quais restrições precisam ser consideradas. Uma empresa em processo de aquisição, por exemplo, pode precisar priorizar integração de identidades e segregação de ambientes. Uma organização migrando aplicações para cloud pode concentrar esforços em arquitetura, IAM, segurança de workloads, dados e configuração.

2. Diagnóstico da situação atual

Essa etapa combina evidências técnicas e gerenciais. Políticas, arquitetura, inventário de ativos, identidades, vulnerabilidades, testes de intrusão, incidentes anteriores, auditorias, maturidade de processos, contratos de terceiros, requisitos regulatórios, continuidade, segurança de aplicações e capacidade de resposta devem ser avaliados de forma integrada.

O diagnóstico não precisa transformar o plano em uma auditoria infinita. O objetivo é estabelecer uma linha de base confiável. Sem baseline, qualquer indicador futuro corre o risco de medir atividade, e não evolução.

3. Avaliação e priorização de riscos

A análise precisa conectar ameaça, vulnerabilidade, ativo, probabilidade e impacto. Quanto mais crítica a decisão, mais importante evitar a priorização baseada apenas em pontuação técnica.

Uma vulnerabilidade CVSS 9,8 em um sistema isolado pode representar risco menor do que uma falha de identidade aparentemente menos grave em uma plataforma que controla toda a operação. O PDSI deve capturar essa diferença.

O Blog abordou esse problema recentemente ao discutir a CVE-2026-93616 no Check Point Management Server: o papel do servidor administrativo aumenta o impacto potencial porque ele controla componentes de segurança. A mesma lógica vale para Active Directory, serviços de identidade, backup, hypervisors, plataformas de cloud e outros ativos que concentram confiança.

4. Estado-alvo e objetivos de segurança

Depois de compreender os riscos, a liderança precisa definir onde pretende chegar. O objetivo não deve ser “ter segurança máxima”, porque isso não é mensurável nem economicamente realista.

Objetivos executivos melhores seriam: reduzir acessos privilegiados sem controle; aumentar a capacidade de detecção de movimentos laterais; reduzir tempo de correção de vulnerabilidades críticas em ativos expostos; garantir recuperação de serviços essenciais dentro de RTO e RPO definidos; ou elevar o nível de proteção de dados pessoais e propriedade intelectual.

5. Roadmap de iniciativas

É aqui que o plano transforma risco em execução. Cada iniciativa precisa ter justificativa, responsável, dependências, prazo, investimento estimado e resultado esperado.

Um roadmap de 24 meses, por exemplo, pode dividir ações em ondas: primeiro identidades críticas, exposição externa e recuperação; depois visibilidade, segmentação, segurança de aplicações e terceiros; em seguida automação, analytics, maturidade de SOC e controles avançados.

Essa abordagem evita dois extremos comuns: tentar corrigir tudo simultaneamente ou investir apenas no que produz maior visibilidade interna, mas pouco impacto real.

6. Orçamento e critérios de decisão

O orçamento do PDSI deve separar investimentos de implantação, custos recorrentes, serviços especializados, pessoas, treinamento e operação. Também precisa considerar custo de oportunidade e dependências.

Por exemplo, adquirir uma plataforma SIEM sem capacidade de engenharia, casos de uso, operação, tuning e resposta pode criar um custo recorrente sem entregar o benefício esperado. O investimento real não é apenas a licença: é o conjunto necessário para produzir o resultado.

7. Indicadores e governança

O NIST SP 800-55 orienta a criação e seleção de medidas de Segurança da Informação capazes de avaliar a adequação de políticas, procedimentos e controles. Essa disciplina é fundamental para o PDSI porque evita o uso de métricas de vaidade.

“Quantidade de eventos analisados” ou “número de ferramentas instaladas” pode mostrar esforço. Não necessariamente demonstra redução de risco. Indicadores mais úteis conectam capacidade técnica a resultado: percentual de ativos críticos com MFA, tempo de remediação de vulnerabilidades exploráveis, cobertura de backup imutável, percentual de contas privilegiadas monitoradas, tempo médio de detecção, tempo médio de contenção, percentual de aplicações críticas submetidas a testes de segurança e evolução de riscos residuais.

A CISA segue raciocínio semelhante em seus Cybersecurity Performance Goals ao priorizar práticas com valor conhecido de redução de risco e resultados de alto impacto, em vez de simplesmente recomendar a maior quantidade possível de controles.

Como traduzir requisitos técnicos para a linguagem executiva

O executivo de segurança precisa abandonar a expectativa de que a alta direção aprenda a linguagem do SOC. O trabalho é justamente fazer a tradução.

“Precisamos de microsegmentação” é uma demanda técnica. “Hoje, o comprometimento de uma estação de trabalho pode alcançar servidores que sustentam faturamento e produção” é uma declaração executiva de risco. “A implantação de segmentação reduzirá os caminhos de propagação e limitará o impacto de um incidente” conecta o controle ao resultado.

Outro exemplo: “temos 4.000 vulnerabilidades abertas” comunica volume. “Trinta e duas vulnerabilidades exploráveis estão em ativos expostos à Internet que processam dados de clientes, e onze delas não possuem controle compensatório” comunica prioridade.

A diferença parece semântica, mas muda o processo de decisão. A alta gestão precisa saber qual cenário pode ocorrer, qual seria o impacto, qual investimento reduz a exposição e qual risco permanecerá depois da intervenção.

ROI em segurança: retorno não é apenas receita

Uma das partes mais difíceis do planejamento é demonstrar retorno. Segurança raramente produz receita de forma direta, e isso torna inadequado aplicar mecanicamente o ROI tradicional a qualquer iniciativa.

Em muitos casos, o conceito mais útil é o ROSI — Return on Security Investment, baseado na redução de perda esperada. A lógica é estimar o risco antes do controle, estimar o risco residual depois da implementação e comparar a redução econômica com o custo do investimento.

Considere um exemplo simplificado. Uma organização estima que determinado cenário de ransomware tenha 20% de probabilidade anual e impacto potencial médio de R$ 5 milhões. A perda anual esperada seria, nesse modelo, de R$ 1 milhão. Após investir em segmentação, identidade privilegiada, EDR, backup imutável e testes de recuperação, a probabilidade estimada cai para 8%, mantendo-se o mesmo impacto de referência. A perda anual esperada cairia para R$ 400 mil.

Se o programa custar R$ 300 mil por ano, a redução de risco estimada seria de R$ 600 mil. Um cálculo simplificado de ROSI seria:

Esse número não deve ser interpretado como promessa financeira. Probabilidade e impacto são estimativas e precisam ser tratados como cenários, com premissas registradas. Ainda assim, o método é muito mais útil para a direção do que justificar um investimento com frases genéricas como “a segurança é importante”.

Além da perda evitada, um PDSI pode capturar outras formas de valor: redução de indisponibilidade, aceleração de auditorias, diminuição do esforço manual, menor custo de resposta a incidentes, redução de prêmios ou exigências de seguro, melhora na homologação como fornecedor e habilitação de iniciativas digitais que dependeriam de controles adequados.

ROI também pode ser medido em velocidade e capacidade

Nem todo retorno precisa ser convertido imediatamente em reais. Uma empresa que reduz o tempo médio para revogar acessos de ex-funcionários de três dias para duas horas reduziu uma janela de exposição. Uma organização que passa de 40% para 95% de cobertura de MFA em aplicações críticas reduziu uma condição concreta de risco. Um programa que diminui o tempo de recuperação de 48 para oito horas aumenta resiliência operacional.

O desafio é construir uma cadeia lógica: investimento → capacidade → indicador → redução de risco → impacto no negócio. Quando essa cadeia existe, a discussão deixa de ser “quanto a segurança gastou” e passa a ser “o que a organização passou a ser capaz de prevenir, detectar, conter ou recuperar”.

Por que uma consultoria especializada pode aumentar a qualidade do PDSI

O PDSI pode ser desenvolvido internamente, especialmente em organizações maduras, com equipe experiente e boa integração entre segurança, TI, riscos, jurídico, privacidade e negócio. Ainda assim, uma consultoria especializada pode gerar vantagens importantes quando o ambiente é complexo ou quando a empresa precisa acelerar o planejamento.

A primeira vantagem é a independência de diagnóstico. Equipes internas convivem diariamente com restrições, ferramentas legadas, decisões históricas e prioridades políticas. Um olhar externo pode questionar premissas que deixaram de fazer sentido e comparar a organização com padrões, práticas e cenários observados em outros ambientes.

A segunda é a amplitude técnica. Um PDSI consistente pode envolver arquitetura, cloud, identidade, segurança de aplicações, redes, SOC, resposta a incidentes, privacidade, continuidade, fornecedores, compliance e segurança física. Raramente uma única equipe interna possui profundidade equivalente em todas essas disciplinas.

A terceira é a capacidade de traduzir diagnóstico em programa executivo. Uma consultoria madura não deve entregar apenas um relatório com dezenas de gaps. Ela precisa priorizar, criar dependências, estimar esforço, construir roadmap, definir quick wins e conectar cada iniciativa ao risco que pretende reduzir.

Por fim, existe a vantagem da validação externa. Um board pode questionar se a avaliação feita pela própria área de segurança está superestimando necessidades para justificar orçamento ou, no extremo oposto, subestimando fragilidades. Uma avaliação independente cria um ponto adicional de confiança para decisões de investimento.

O que exigir de uma consultoria que vai construir o PDSI

A contratação, porém, não deve ser baseada apenas em metodologia de apresentação. O resultado esperado precisa ser explícito.

A consultoria deve demonstrar capacidade de avaliar riscos técnicos e de negócio, trabalhar com evidências, entrevistar executivos e equipes técnicas, compreender obrigações regulatórias, definir arquitetura-alvo, priorizar iniciativas e produzir indicadores. Também precisa deixar claro quais premissas foram utilizadas para estimativas de risco e retorno.

Um bom projeto não termina com um PDF. Deve entregar instrumentos utilizáveis: registro de riscos, matriz de prioridades, roadmap, plano de investimentos, responsáveis, indicadores, critérios de acompanhamento e governança de revisão.

É recomendável ainda prever ciclos de atualização. Fusões, novas aplicações, adoção de IA, mudança de provedor de cloud, incidentes relevantes, novas regulações ou alterações estratégicas podem tornar partes do plano obsoletas muito antes de seu prazo original.

Exemplo de evolução executiva

Imagine uma empresa de serviços com três prioridades corporativas para os próximos dois anos: expandir canais digitais, utilizar IA generativa internamente e entrar em um mercado que exige controles mais robustos de segurança.

O PDSI poderia identificar quatro riscos prioritários: identidades privilegiadas excessivas, ausência de inventário consistente de dados, recuperação não testada e baixa visibilidade de aplicações SaaS. Em vez de criar projetos isolados, o plano poderia organizar um programa em três ondas.

Na primeira, identidade, backup e exposição externa. Na segunda, classificação de dados, segurança de SaaS e aplicações. Na terceira, governança de IA, automação de resposta e evolução do SOC. Cada onda teria metas, orçamento e indicadores associados.

Ao final do primeiro ano, o board não receberia um relatório dizendo que “12 ferramentas foram implantadas”. Receberia evidências como: 98% das contas privilegiadas sob controle; redução de 60% nas vulnerabilidades críticas vencidas; testes de restauração concluídos para 100% dos serviços de prioridade 1; redução do MTTD; e queda mensurada do risco residual em cenários específicos.

Esse tipo de evidência permite discutir segurança pelo resultado obtido, e não pelo número de produtos implantados.

O PDSI precisa sobreviver ao orçamento anual

Outro ponto importante é evitar que o PDSI seja reinventado a cada ciclo orçamentário. O plano deve criar continuidade. Projetos podem ser antecipados, adiados ou redimensionados, mas a lógica de risco que sustentou a priorização precisa permanecer rastreável.

Quando uma iniciativa é cortada do orçamento, o risco correspondente não desaparece. Ele precisa ser formalmente aceito, transferido, mitigado por outro caminho ou reprogramado. Essa disciplina evita que decisões financeiras sejam interpretadas equivocadamente como decisões de segurança.

É nesse ponto que o PDSI se torna também instrumento de governança. Ele registra não apenas o que será feito, mas o que não será feito agora, quem aceitou essa decisão e quais consequências podem permanecer.

Conclusão: o plano precisa continuar útil depois da aprovação do orçamento

Um PDSI só prova seu valor quando continua sendo usado depois da aprovação do orçamento. A cada corte, atraso ou mudança de prioridade, o risco associado precisa continuar visível e ter um responsável pela decisão.

O documento pode ser simples, desde que responda de forma rastreável cinco perguntas: o que precisa ser protegido, contra quais riscos, em que ordem, com qual investimento e por quais evidências será possível saber se o risco diminuiu.

Quando essas respostas permanecem atualizadas, o plano deixa de ser uma fotografia anual e passa a orientar decisões reais de Segurança da Informação.

Referências

NIST — Cybersecurity Framework 2.0
NIST — Measurements for Information Security / SP 800-55
ISO — ISO/IEC 27001:2022 Information Security Management Systems
CISA — Cross-Sector Cybersecurity Performance Goals

Transforme risco técnico em um plano executivo de Segurança da Informação.

A Mindsec apoia organizações na avaliação de riscos, definição de prioridades, roadmap, governança e planejamento de investimentos em cibersegurança.