Lista de compras ou tese de risco?

Todo ano é a mesma coisa: inicia-se o ciclo orçamentário e, com ele, repete-se uma cena bizarramente comum. É como se fosse uma época encantada em que as áreas de negócio chegam com promessas sedutoras de crescimento, eficiência, automação, redução de custo, experiência do cliente, inteligência artificial, novos canais, novos mercados, entre muitas outras. Poucas delas são substancialmente boas de fato. Algumas não passam de histórias bem contadas por alguém que quer ficar bem na foto com a diretoria e que as traz embaladas em um encantador PowerPoint carregado de promessas, ou fundamentadas em planilhas recheadas de números e previsões exageradamente otimistas, coloridas e repletas de buzzwords da moda. É como o ano novo organizacional.

É óbvio que, nesse movimento em busca do tão desejado orçamento anual, a segurança não poderia ficar de fora. A questão é que ela chega em outra sintonia, falando em: vulnerabilidades críticas, EDR, SIEM, PAM, DLP, SAST, SCA, CSPM, pentest, compliance, hardening, classificação de dados, revisão de acessos, resposta a incidentes. Embora boa parte disso seja realmente importante, o problema é que, para quem decide capital, tudo isso soa como a estática de uma lista de compras solta, não como decisão estratégica.

E aí renasce a distorção nossa de cada ano: projetos ruins ganham orçamento porque prometem futuro, enquanto bons programas de segurança perdem o orçamento necessário porque parecem despesa. Sem falar dos projetos vitais de SI que estão em andamento e sofrem cortes ou interrupções para dar espaço aos tais reluzentes e idílicos projetos de futuro organizacional.

Isso acontece não porque o board seja ignorante, nem porque executivos não se importem com risco, e nem apenas porque "segurança precisa falar a língua do negócio". Aliás, essa frase já está tão batida que seu sentido até desbotou.

Esse problema anual é mais profundo do que parece, pois revela um problema de postura e posicionamento da área de segurança: ela ainda perde orçamento porque, com frequência, não consegue demonstrar com clareza que está gerando valor e protegendo aquilo que realmente mantém a empresa de pé: receita, continuidade, reputação e vantagem competitiva.

A crítica precisa começar dentro de casa

A verdade precisa ser dita: o orçamento de segurança nem sempre é pequeno. Frequentemente, ele é mal alocado.

Existe uma narrativa confortável na nossa área: se algo não vai bem, a desculpa é a falta de orçamento, falta de gente, falta de ferramenta, falta de apoio executivo ou a falta de alguma outra coisa. Em alguns poucos casos, isso é verdade. Mas, na verdade, está longe de ser uma regra.

Já estive à frente de uma área de SI em que o orçamento da área era de menos de 3% do orçamento de TI. A empresa também era uma incubadora com seis startups em estágios diferentes de maturação e SI era uma área cross para todas elas. Lembro de que em certo momento, a organização estava em crise porque uma delas estava puxando as demais para o olho do furacão e, neste momento nebuloso, tive que pedir orçamento para uma iniciativa legítima de contratação de um recurso, devido à sobrecarga e ao excesso de horas extras. Negaram na hora e sequer tiveram a urbanidade de me esperar terminar a fala. Ainda por cima aproveitaram que eu estava ali e fizeram a gentileza de "avisar" do corte de verba de um projeto importante. Diante de tal finesse, fui forçado a buscar alternativas: cortei uma ferramenta importante e contratei uma substituta fazendo um pacote com um antigo fornecedor de uma outra solução que usávamos e que, embora fosse menos eficiente, apresentava níveis ainda aceitáveis para dar lugar à contratação e ao andamento do projeto. Deu um trabalho hercúleo para a já sobrecarregada área, mas deu certo. Coisas assim fazem parte do jogo, e deve-se aprender a jogá-lo, em vez de resistir a ele.

O pior é que, depois de anos trabalhando com segurança, desenvolvimento seguro, arquitetura, operação, risco e governança, uma coisa ficou clara: há empresas que reclamam de falta de orçamento enquanto carregam um cemitério de ferramentas sobrepostas, módulos nunca ativados, funcionalidades subutilizadas, contratos renovados por inércia e soluções compradas mais pelo susto do último incidente do que por uma tese consistente de risco, sem contar os caros e infames contratos de cobertor emocional: se algo der errado, pelo menos há alguém para culpar.

Em AppSec, por exemplo, cansei de ver empresas irem às compras em busca de um scanner antes de terem, sequer, um processo estabelecido que definisse quem analisaria os achados e os falsos positivos, quem corrigiria, em que prazo, com qual critério de aceite, com qual integração no ciclo de desenvolvimento e, o mais importante, que resultados esperariam dele. O resultado parecia uma comédia triste em um picadeiro: a ferramenta encontrava problemas, o backlog crescia, o risco continuava lá, a segurança cobrava o desenvolvimento e de brinde ganhava a má fama de produzir atrito.

E não é só com scanners que essas coisas acontecem, e é mais comum do que parece. Duvida? Olhe para o pentest: a empresa paga caro por um, recebe um relatório robusto e corrige os achados um a um e para por aí batendo as palmas das mãos, orgulhosa de mais um trabalho bem feito. Quase ninguém pergunta por que aqueles achados existem. Trata-se o sintoma e ignora-se a doença: o processo, a arquitetura ou o padrão de configuração que gerou aquela lista continua intacto, prontinho para devolver os mesmos achados em outros pontos dos sistemas no pentest do ano que vem. Corrigir achado sem corrigir a causa é dar escala à cara arte de enxugar gelo.

Os números do mercado confirmam o meu incômodo. Um estudo da IBM com a Palo Alto Networks (2025) encontrou organizações fazendo malabarismo com, em média, 83 ferramentas de segurança de 29 fornecedores diferentes; o Panaseer já vinha apontando a tendência, com a média saltando de 64 para 76 ferramentas em apenas dois anos. E o uso é pífio: o Mandiant Security Effectiveness Report (2020) mostrou que cerca de 80% das ferramentas estão subutilizadas e 35% têm capacidades sobrepostas, enquanto o levantamento da ReliaQuest (2021) indica que apenas ~22% delas são consideradas vitais para os objetivos primários de segurança. Para completar, estima-se que entre 25% e 40% das licenças corporativas nunca chegam a ser usadas. Em outras palavras: compramos o arsenal, ligamos um quinto dele, pagamos várias vezes pela mesma capacidade e achamos que estamos salvando a organização e até o mundo.

Não é raro encontrar ambientes em que a empresa tem ferramenta para quase tudo, mas pouca capacidade de transformar essa parafernália tecnológica em redução real de exposição e, pior, em eficiência orçamentária. Tem EDR, mas não tem sequer capacidade de resposta. Tem SIEM, mas não tem caso de uso decente, nem um plano de resposta bem desenhado. Tem SAST, mas não consegue fazer o desenvolvimento aprender e corrigir o que importa melhorando a cada ciclo. Tem DLP, mas, mal configurado, ele é verborrágico (fala muito e diz pouco) e ninguém sabe quais dados são realmente críticos. Tem PAM, mas ainda existem contas privilegiadas fora do cofre. Tem política, mas ela é sumariamente ignorada, e a exceção virou a regra e o processo real.

A grande questão nunca foram as ferramentas. E não: trocar de ferramenta, na maioria dos casos, não vai resolver o problema. Em geral, ela faz razoavelmente o que promete dentro do seu escopo. O problema acontece sempre que a ferramenta vira substituta da estratégia, ou da falta dela.

Na minha experiência constatei que, em geral, a segurança não precisa começar pedindo mais orçamento, mas é imperativo que primeiro ela prove que já faz bom uso do que tem ou que pode enxugar aquilo que não é estritamente necessário. E o elefante na sala é que, se a área quer disputar capital em pé de igualdade com produto, tecnologia, operações, comercial e finanças, precisa aceitar a regra básica dessas áreas: toda alocação de capital exige tese, prioridade, disciplina e revisão de valor. Segurança não deveria estar fora dessa lógica.

A lista de compras tomou o lugar da tese de risco

Há uma diferença enorme entre pedir uma ferramenta e defender uma tese de investimento.

Pedir é dizer: "Precisamos de uma solução de DLP." Defender uma tese é dizer: "Temos dados sensíveis espalhados em canais não controlados, sem rastreabilidade adequada, em processos ligados a clientes estratégicos e obrigações regulatórias. Hoje a exposição se concentra em três fluxos. A proposta é reduzi-la em fases, começando pelos dados de maior impacto." A primeira frase vende tecnologia; a segunda vende redução de risco sobre algo que importa para o negócio.

Pedir é dizer: "Precisamos contratar SAST e SCA." Defender uma tese é dizer: "Nosso canal digital depende de aplicações que mudam toda semana, e parte relevante do risco entra pelo ciclo de desenvolvimento antes de chegar à produção. Sem deslocar os controles para mais cedo no ciclo de desenvolvimento, continuaremos pagando caro por correções tardias, exceções emergenciais e exposição acumulada." A primeira parece custo; a segunda mostra preservação de valor e controle de risco em um ponto estrutural da cadeia.

A diferença não é semântica. É governança. Quando a segurança pede ferramentas sem conectar o pedido à exposição, ao ativo crítico, ao processo de negócio e à perda possível, ela entra na conversa orçamentária como centro de custo. E centro de custo disputa as sobras da mesa.

Certa vez, geri a área de segurança de uma organização e, após um assessment feito por um potencial cliente enorme, eles questionaram a falta de uma caríssima ferramenta de segurança. O cliente se mostrava hesitante em fechar o contrato por conta desse e de outros motivos alheios à SI. Pedi uma reunião, entendi o problema e mostrei que, embora não tivéssemos a ferramenta em questão, o papel de controle que ela exercia era coberto por outros processos e ferramentas, com resultados consistentes. Depois dessa reunião, o cliente fechou o negócio.

Projetos ruins sabem contar boas histórias

Enquanto isso, projetos ruins vindos de outras áreas passam, e passam bem. Isso acontece porque prometem crescimento, eficiência, produtividade, automação, inteligência artificial, melhor experiência do cliente, não raras vezes apoiados em premissas frágeis, números otimisticamente exagerados, riscos subestimados e a promessa de um novo paraíso terrestre. Mas chegam com a conversa do futuro sussurrada com voz angelical. Segurança, muitas vezes, chega falando de problemas que soam como uma cacofônica fonte de ruído e atrito. E, na aguerrida disputa por orçamento, futuro costuma vencer problema e atrito facilmente.

Um projeto ruim, bem narrado, parece um investimento. Um programa de segurança bom, mal comunicado, parece uma despesa. Esse é um dos maiores dramas da área: não basta o risco existir, ser tecnicamente relevante, ter CVSS alto. O que decide o orçamento não é a existência do risco, mas a capacidade de demonstrar por que aquele risco deveria competir com todas as outras prioridades da empresa.

E é aqui que muita gente de segurança erra. Confunde severidade técnica com relevância executiva. Confunde volume de achados com exposição real. Confunde controle implementado com risco reduzido. Confunde cobertura com efetividade. Confunde compliance com segurança real. Confunde atividade com valor.

Proteger tudo é uma forma cara de não priorizar nada

Há uma tentação antiga na área: proteger tudo. Tudo precisa de controle, scan, revisão, bloqueio, política, evidência, aprovação, exceção formal, lugar no dashboard. É sempre bonito no papel e parece maturidade, mas, na prática, costuma ser ausência de priorização.

E este é um ponto que separa os aspirantes dos veteranos com cicatrizes: segurança madura não é a que protege tudo com a mesma intensidade. É a que sabe precisamente onde a empresa não pode ser atingida pelo fogo do inimigo. Sabe: quais sistemas sustentam receita? Quais processos não podem parar? Quais dados, se vazarem ou forem sequestrados, mudam o patamar de impacto? Quais fornecedores são pontos de falha do negócio? Quais identidades têm poder de causar dano sistêmico? Quais riscos, se materializados, deixam de ser problema técnico e viram problema de continuidade, liquidez, confiança ou regulação?

Sem essas respostas, segurança vira uma metralhadora operada por um estabanado: atira para todos os lados, desperdiça munição, faz muito barulho, gera muito calor por atrito, produz relatório, mas pouco acerta o que importa. É aqui que entram conceitos ainda pouco explorados na prática: BIA, criticidade de processo, dependência operacional, apetite a risco, exposição acumulada, caminho de ataque, impacto em receita, impacto regulatório e capacidade de recuperação.

Nenhum CISO precisa transformar cada discussão em aula de finanças. Mas precisa saber responder a uma pergunta simples: "Por que este risco merece dinheiro antes daquele outro projeto?" Se a resposta for apenas "porque é crítico", perdeu seu quinhão. Crítico para quem? Em qual ativo? Com qual exposição? Que perda evita? Que decisão executiva está sendo tomada?

A síndrome do centro do universo

Há ainda uma mazela mais sutil, mas igualmente cara: a segurança que se enxerga como o centro do universo corporativo. Sai uma vulnerabilidade grave (um CVSS 9.8 estampado em vermelho no boletim do dia) e a área quase grita "parem as rotativas!", exigindo atenção imediata e como se a empresa inteira devesse congelar o roadmap, suspender lançamentos e despejar capital até que tudo aquilo que a segurança exige esteja no devido lugar.

É prima da velha venda pelo medo, mas com outra fantasia medonha: aqui não se trata de assustar o board para arrancar orçamento, e sim de exigir que o mundo pare para ouvir e acompanhar o passo da segurança. O detalhe é que a empresa tem mais de um front. Receita, caixa, clientes, prazo regulatório, concorrência e gente disputam a mesma atenção e o mesmo dinheiro, ao mesmo tempo. Uma falha "crítica" num sistema de baixa criticidade, sem exposição e sem caminho de ataque plausível, não justifica parar a companhia, e nem toda "vulnerabilidade do ano" que vira manchete é, de fato, o seu maior risco naquela semana.

Tratar cada susto como emergência existencial tem um custo que quase ninguém contabiliza: corrói o capital político e a credibilidade que você vai precisar justamente no dia em que a casa estiver pegando fogo de verdade. Quem grita lobo para tudo o que acontece perde credibilidade. Maturidade, aqui, é proporcionalidade: separar o incêndio da fogueirinha de papel daquela canção do Gilberto Gil, calibrar a resposta ao impacto real no negócio e pedir mobilização total só quando o risco de fato exige, porque é aí que ela precisa ser levada a sério.

Operacionalmente ocupada, estrategicamente ausente

Outro mal comum é a segurança ocupada demais para ser estratégica. A área passa o dia respondendo a ticket, evidência de auditoria, exceção, revisão de acesso, questionário de fornecedor, alerta, falso positivo, aprovação emergencial e cobrança de patch. Tudo parece urgente, e pouca coisa vira decisão. Quando percebe, a área está exausta, mas ainda assim pouco relevante.

Por outro lado, esse também é um dos pontos mais cruéis da profissão: dá para trabalhar muito, entregar muito, apagar muito incêndio e ainda assim ser percebido como função operacional. Porque esforço não é estratégia, atividade não é valor, controle não é necessariamente redução de risco e relatório não é decisão. A área pode estar tecnicamente certa e politicamente irrelevante ao mesmo tempo. Com ferramentas caras e pouca legitimidade. Um dashboard cheio de indicadores, mas uma cadeira vazia na conversa em que a estratégia é definida.

E existe um outro agravante que pouca gente admite: a segurança que vive isolada, longe da realidade das áreas de negócio. Não sabe como cada BU ganha dinheiro, que pressões enfrenta nem como é a rotina de quem está na ponta. Do alto de sua torre de marfim, prescreve controles genéricos que não cabem em como o negócio de fato opera, e o resultado é previsível: a área concorda com tudo na reunião, sorri e acena educadamente e continua fazendo do seu jeito. Controle que ignora a realidade da operação não vira segurança; vira encenação educada e, no fim, vira contorno.

Os dados mostram o tamanho do abismo de comunicação: em pesquisa com mais de 200 CISOs, apenas 25% reportavam algo além de métricas de vulnerabilidade, e um benchmark recente revela que só 47% dos conselheiros acham que o CISO articula bem o impacto real das ameaças sobre o negócio. Não é que o board não escute. É que, com frequência, não recebe nada de muito útil que o ajude a decidir.

Isso é especialmente grave em produtos digitais. Quando a segurança só entra depois que o produto foi vendido, desenhado, desenvolvido ou colocado em produção, qualquer recomendação vira atraso, qualquer controle vira burocracia e qualquer vulnerabilidade vira problema de "quem não entendeu o negócio". Mas o erro começou antes: quando segurança não estava na conversa de produto, quando threat modeling era tratado como luxo e arquitetura segura, como filigrana técnica. O risco foi criado por uma decisão de negócio e só foi descoberto como problema de segurança. Quando a área entra no fim, vira obstáculo caro; quando entra no início, vira um desenho útil e mais em conta.

Influência sem accountability

Há também um problema de governança raramente discutido com franqueza: muitas áreas interferem em decisões de segurança, mas se esquivam e a culpam quando seus "palpites" dão errado.

Compras escolhe pelo preço. Jurídico transforma segurança em cláusula. Auditoria, em checklist. TI transforma exceção em conveniência operacional. Produto transforma prazo em argumento absoluto. O negócio aceita risco sem entender exatamente o que está aceitando. Finanças corta orçamento sem recalcular a exposição residual. E segurança fica no meio, tentando se virar como pode e ainda entregar os resultados de que a organização precisa.

Não entenda mal: o problema não é outras áreas influenciarem segurança. Aliás, elas devem influenciar, pois é uma área de apoio ao negócio e não pode ser uma ilha nem um tribunal técnico isolado. O problema é influenciar sem accountability. Se alguém pressiona por uma exceção, alguém precisa justificar e assumir formalmente o risco e a decisão. Se um produto vai ao ar sem controles mínimos, alguém precisa explicar o motivo e aceitar a exposição. Se um fornecedor crítico não atende requisitos essenciais, alguém precisa decidir se a empresa quer comprar aquele risco.

Risco aceito sem dono é apenas risco abandonado. E risco abandonado costuma reaparecer na forma de incidente, auditoria, indisponibilidade, vazamento, manchete ou reunião emergencial. E tudo isso vai parar, rapidamente, na conta da segurança. É a materialização da velha história do papagaio que come o milho e o periquito que leva a fama.

A exceção temporária como arquitetura permanente

Poucas coisas explicam tão bem a fragilidade organizacional quanto a exceção esquecida. Ela nasce pequena, razoável, quase sempre justificada: "É só por enquanto", "depois corrigimos", "precisamos colocar em produção", "o fornecedor ainda não suporta", "esse sistema é legado", "na próxima fase a gente resolve".

A próxima fase não vem. O gestor muda, o projeto muda, o time muda, a prioridade muda, a ata desaparece, a planilha fica desatualizada. O risco permanece. Depois de alguns anos, ninguém sabe quem aprovou, por quê, por quanto tempo nem com qual compensação. A exceção virou arquitetura, e, quando se investiga o fato, ouve-se que "sempre foi assim".

Quase todo profissional de segurança com alguns anos de janela já viu passar uma exceção "temporária" mais velha que "A Banda", do Chico Buarque, só que, diferente da canção, essa passa interrompendo a rotina dos sistemas críticos da empresa e não deixa nenhum efeito feliz e poético no caminho.

Uma parte significativa do risco real das empresas vive exatamente nesses lugares: nas decisões temporárias que ganharam cidadania permanente. A conta sem MFA, a VPN antiga, a regra aberta no firewall, o servidor fora do inventário, o usuário privilegiado sem recertificação, o bucket esquecido, a biblioteca vulnerável que ninguém atualiza porque ninguém sabe quem mantém. Isso raramente aparece nos promissores discursos sobre transformação digital e IA, mas aparece nos incidentes. O risco raramente mora no desconhecido; quase sempre mora no conhecido tolerado e acalentado por alguém no seio da organização.

Segurança mendicante

Existe uma expressão que costumo usar. Ela é dura, mas útil: segurança mendicante. É quando a área deixa de disputar decisão e passa a pedir favor. Pede orçamento, ferramenta, headcount, prioridade. Pede que o negócio corrija, que o desenvolvimento escute, que a infraestrutura aplique patch, que compras a envolva antes, que o board dê atenção, que alguém assuma o risco. Pede, pede, pede. E quem vive pedindo raramente é percebido como parte da estratégia. É visto como dependência, obstáculo, custo inevitável ou, pior, mal necessário.

Nem sempre a culpa é da área. Em muitas empresas a estrutura empurra o CISO para essa posição degradante: responsabilidade sem autoridade, cobrança sem orçamento, urgência sem patrocínio, exposição sem governança. Mas também é verdade que a própria área reforça esse lugar quando não consegue traduzir sua contribuição para o sistema de decisões da empresa.

Segurança não pode ser apenas a área que diz "não". Sim, eu sei: é outra parte riscada do mesmo disco velho. Mas convém lembrar que ela também não é obrigada a sempre dizer "sim" para ser vista como "parceira". Deve negociar cada "não", transformando-o num possível "sim": uma decisão conjunta de risco, prazo, condições e responsabilidades. Precisa ser a área que qualifica a decisão: pode fazer? Pode, mas com qual risco? Pode aceitar? Pode, mas quem é o dono? Pode lançar? Pode, mas qual exposição residual? A maturidade da segurança não está em bloquear tudo. Está em tornar o risco visível antes que a decisão seja tomada.

O board não deveria perguntar apenas "quanto custa?"

Quando o board pergunta "quanto custa?", talvez o CISO precise ensiná-lo a fazer uma pergunta melhor: "Quanto risco estamos comprando?"

Sim, é uma mudança cultural gradual e difícil, mas cabe ao CISO gastar a sola do sapato e o latim nessa tarefa inglória.

Porque toda decisão compra algum tipo de risco. Comprar uma ferramenta compra risco de implementação e adoção; não comprar compra risco de exposição. Adiar uma contratação compra risco de capacidade. Acelerar um produto compra risco de desenho. Ignorar um legado compra risco acumulado.

A pergunta nunca é se haverá risco, pois sempre haverá. É se a empresa sabe qual risco está comprando, por qual preço, por quanto tempo e em troca de qual benefício. Essa é a conversa que segurança precisa provocar. Não uma conversa sobre medo, nem sobre ferramenta, nem sobre "melhores práticas" ou frameworks como argumento final. Uma conversa, de par para par, sobre alocação de risco.

Segurança como tese de investimento

O ponto de virada talvez seja tratar segurança como tese de investimento, não como lista de controles. Uma boa tese consegue responder: que valor estamos preservando? Que exposição estamos reduzindo? Que capacidade estamos criando? Que perda plausível estamos evitando? Que decisão de negócio fica melhor depois desse investimento?

Isso muda o tom da conversa. Um programa de AppSec não é uma esteira com SAST, SCA e DAST; é uma forma de reduzir risco no ciclo de criação de produtos, diminuir retrabalho e dar confiança para acelerar mudanças. Um programa de IAM não é recertificação, MFA e PAM; é a redução de um risco sistêmico concentrado em identidades, limitando o impacto de um comprometimento. Um SOC não é monitoramento 24x7; é a capacidade de detectar e conter antes que um evento técnico vire crise operacional.

O mesmo investimento, mal narrado, parece custo. Bem estruturado, vira capacidade organizacional.

O problema não é gastar menos ou mais. É gastar melhor.

Da próxima vez que você abrir o seu PowerPoint para apresentar ao board em busca de orçamento, não comece o discurso com "precisamos de mais dinheiro". Faça um exercício mental e responda a perguntas comuns e ordinárias, como: onde estamos expostos? O que é realmente crítico? O que estamos protegendo demais, e o que de menos? Quais controles não entregam mais valor? Quais ferramentas se sobrepõem? Quais capacidades existem no contrato, mas não na prática? Quais riscos estão órfãos? Quais exceções já venceram? Quais decisões de negócio estão criando risco sem governança?

Só depois disso pense em orçamento. Afinal, orçamento sem prioridade vira dinheiro queimado, ferramenta sem processo vira bibelô caro, processo sem dono vira uma casa da mãe Joana burocratizada, métrica sem decisão vira teatrinho e segurança sem conexão com valor vira o tal custo que o board corta primeiro.

No fim, segurança perde para projetos ruins quando aceita jogar o jogo errado

Projetos ruins não deveriam vencer bons programas de segurança. Mas vencem quando chegam com narrativa de valor e encontram uma segurança presa em narrativa de ferramenta. Vencem quando falam de futuro e a segurança responde com checklist. Vencem quando o risco do projeto é invisível e o custo da segurança é explícito. Vencem, principalmente, quando a empresa ainda trata o risco cibernético como assunto técnico e, pior, quando a própria segurança aceita esse enquadramento.

A provocação final é esta: a segurança da informação não perde orçamento apenas porque o board não entende de segurança. Ela perde quando não consegue entrar na conversa como decisão de capital, alocação de risco e preservação de valor. Enquanto for apresentada como lista de compras, vai disputar as migalhas. Quando for apresentada como tese de proteção do que sustenta o negócio, a conversa muda.

E talvez, na próxima vez que alguém perguntar "quanto custa?", o CISO possa responder com outra pergunta: "Quanto risco estamos comprando se não fizermos isso direito?"

Referências

André Gaio escreve sobre segurança da informação, gestão de riscos, desenvolvimento seguro e liderança de SI como decisão de negócio. Depois de mais de 25 anos entre operação, arquitetura, produto e board, virou obstinado por uma ideia simples: segurança não precisa de mais orçamento, precisa saber defender uma tese de risco. Escreve aqui sobre como sair da "lista de compras" e chegar à mesa onde o capital é decidido.

Contents