APRENDER. PRATICAR. EVOLUIR.1. Começar pela decisão de negócio
Uma equipa fictícia de serviços de fundos recebe propostas para melhorar acessos privilegiados, deteção e recuperação. Cada fornecedor apresenta uma pontuação favorável, mas os projetos competem pelos mesmos engenheiros APS. O comité precisa de decidir que conjunto financiar, em que condições e com que exposição enquanto o restante trabalho espera. Antes de ordenar propostas, explicita os objetivos do serviço, os critérios de aceitação e as restrições. Uma obrigação aplicável não desaparece porque outra proposta tem melhor retorno estimado. A sua aplicabilidade e o tratamento de um eventual incumprimento pertencem ao processo de governance adequado. No exercício, M é obrigatório por pressuposto didático: o programa nunca o retira para melhorar a pontuação de uma alternativa.
2. Comparar custos com o mesmo âmbito
Uma proposta de 40 unidades para aquisição pode custar mais do que outra de 55 quando se incluem integração, testes, operação, formação e saída. Regista o horizonte, as rubricas e as exclusões antes de comparar totais. Distingue valores já pagos de despesas futuras que a decisão ainda pode alterar. Um projeto com custos afundados elevados pode justificar continuação pelos seus benefícios futuros, mas não apenas pelo montante gasto. No laboratório, cost representa unidades sintéticas de orçamento para um horizonte comum; deliveryDays e runDays são restrições separadas. Não se soma uma pontuação de benefício a euros nem se compara diretamente um custo de três anos com uma estimativa anual de perda evitada.
3. Tratar operação como uma restrição real
O plano de referência tem orçamento 80, dez dias disponíveis para implementação e oito dias de operação no período recorrente definido. A combinação M, B e C utiliza 75, dez e sete, respetivamente. Cabe nesses limites, mas não existe margem de implementação. Se os incidentes reduzirem a disponibilidade para oito dias, esse conjunto deixa de ser viável mesmo mantendo orçamento suficiente. Se a operação disponível cair para cinco dias, volta a ser inviável. O exercício encontra outra combinação em cada caso. Estes totais não demonstram que as pessoas têm as competências certas, que podem trabalhar nas datas necessárias ou que existe cobertura de fim de semana. Essas condições exigem planeamento e validação próprios.
4. Financiar dependências e reconhecer inviabilidade
Cada iniciativa discricionária do laboratório depende de M. Selecionar A sem M produz uma razão de inviabilidade; o programa não cria silenciosamente recursos para resolver a omissão. Quando várias iniciativas dependem de M, o seu custo entra uma vez no conjunto selecionado. Contudo, uma dependência financiada não significa que estará operacional antes dos projetos dependentes. O modelo não calcula calendário. Se o orçamento cair para 19 e M custar 20, não existe solução viável nas condições fornecidas. O relatório deve então pedir uma decisão sobre recursos, âmbito ou forma autorizada de cumprir a necessidade, apresentando a exposição. Ocultar M ou inventar uma poupança apenas para apresentar uma lista verde destruiria o significado da restrição.
5. Entregar um business case utilizável
Para o sponsor, prepara uma comparação com objetivo protegido, alternativa, custos futuros, capacidade, dependências, pressupostos, exposição residual e decisão pedida. Identifica quem confirma cada estimativa e quem aceita os compromissos de operação. Um saldo de orçamento não é uma obrigação de gastar: um projeto adicional pode introduzir trabalho que o RUN não consegue manter. O financiamento pode ser faseado por critérios verificáveis, como demonstrar integração e resposta operacional num piloto antes da expansão. Define antecipadamente o que faz continuar, corrigir ou parar. O gestor de segurança recomenda e apresenta consequências; o modelo e a pontuação não concedem autoridade para aprovar despesa ou aceitar risco.
# From content/labs/cism-investment-portfolio
# Run all checks: python3 run.py --output evidence-local.json
from portfolio import fixture, evaluate, solve
data = fixture()
print(evaluate(data, ["M", "A", "B"]))
print(solve(data)["best"])
# Cost 80 / score 53 for M+A+B; best is M+B+C with score 59.
M+B+C cabe em 80 unidades e usa dez dias de implementação. Com apenas oito dias disponíveis, é preciso rever o conjunto, mesmo sem reduzir o orçamento.
Armadilhas comuns
Comparar apenas licenças; confundir orçamento com capacidade; financiar dependências sem calendário; omitir trabalho obrigatório para tornar a proposta viável.
Tópicos relacionados: Carteira, benefícios e análise de sensibilidade
Uma proposta só sustenta a decisão quando explicita custos, dependências e capacidade para manter o resultado.
Referência: Prioritizing Cybersecurity Risk for Enterprise Risk Management · CISM current outline before November 3, 2026