APRENDER. PRATICAR. EVOLUIR.O que precisa de uma decisão
Um projeto de migração de fundos pode terminar dentro do orçamento e deixar uma exposição sem responsável. Para impedir esta separação, escreve a decisão de segurança como uma escolha concreta: qual serviço pode operar, em que condições, durante quanto tempo e com que consequência se as condições falharem. Distingue a recomendação do responsável de segurança da aceitação por quem tem autoridade sobre o risco de negócio. No exemplo desta aula, a delegação interna permite ao responsável do serviço aceitar apenas exposições dentro da tolerância aprovada. Esta regra é um pressuposto didático, não uma descrição de governance de um banco específico.
Uma ficha que pode ser executada
A ficha deve identificar serviço e dados abrangidos, motivo da exceção, alternativas consideradas, controlos temporários, evidência de funcionamento, responsável de risco, responsável de execução, prazo e gatilhos de reavaliação. Um campo «aprovado» não responde a estas perguntas. Imagina uma exceção de 30 dias para uma interface antiga, condicionada a revisão diária de acessos. A equipa APS precisa de saber quem faz essa revisão ao sábado, onde fica a evidência e quem é chamado se faltar. A ausência do titular exige um suplente com autoridade adequada, não uma conta partilhada nem uma assinatura copiada.
A soma não descreve a dependência
Três projetos apresentam exceções diferentes para a mesma plataforma de identidades. Contar três aprovações separadas oculta que a falha dessa plataforma pode afetar os três serviços simultaneamente. Liga os registos à dependência comum e constrói um cenário transversal, com consequências e responsáveis identificados. Não somes probabilidades como se fossem perdas independentes, nem elimines os registos locais: cada equipa continua responsável pelas suas condições. O comité pode descobrir que uma correção central reduz exposição em vários projetos, enquanto três soluções locais duplicam custos e deixam o mesmo ponto de falha.
Mudança de âmbito e fim do prazo
Antes do fim do prazo, pede evidência de correção ou uma nova decisão fundamentada. Uma renovação automática transforma uma solução temporária numa aceitação permanente que pode nunca ter sido autorizada. A revisão também deve ocorrer quando muda uma condição relevante: nova conectividade, dados mais sensíveis, falha de monitorização ou atraso da desativação. No exercício, o risco ultrapassa a delegação quando entra uma nova aplicação de liquidação. O gestor prepara opções e escala para a autoridade prevista, mantendo as ações de contenção já autorizadas. Escalar não significa suspender todas as medidas úteis enquanto se espera pela reunião.
Exercício de comité e resumo
Prepara uma nota de cinco linhas para um comité: serviço afetado; condição que deixou de ser cumprida; exposição e incerteza; opções viáveis com custos e prazos; decisão pedida e responsável. Usa este caso: o controlo diário não foi executado durante dois dias, a exceção ainda tem dez dias de validade e a migração pode ser adiada uma semana. A conclusão deve separar validade temporal de cumprimento das condições. Uma boa resposta propõe verificar acessos do período em falta, restabelecer cobertura e pedir decisão sobre operação ou adiamento segundo os limites de autoridade. Não declara que ocorreu um ataque sem evidência.
Três exceções dependem do mesmo diretório. O comité recebe uma vista conjunta da exposição e mantém responsáveis distintos para cada serviço.
Armadilhas comuns
Tratar prazo válido como controlo eficaz; renovar por silêncio; confundir sponsor de projeto com autoridade de risco; somar cenários dependentes como se fossem independentes.
Tópicos relacionados: Aceitação de risco · Dependências partilhadas
A exceção é uma decisão condicionada e monitorizada. O seu âmbito, autoridade e evidência devem continuar válidos durante toda a operação.
Referência: The NIST Cybersecurity Framework 2.0 · CISM current outline before November 3, 2026