← CISM: gerir segurança, risco e incidentes
22 / 25 · 135 MIN

Políticas, requisitos e integração empresarial

Liga requisitos fictícios a âmbito, versões, responsabilidades e evidência, analisando uma integração empresarial.

Construir um registo de obrigações utilizável

Começa por uma referência estável ao requisito e à interpretação aprovada por quem tem competência. Acrescenta entidade, serviço, conjunto de dados, finalidade, versão, datas e estado de aplicabilidade. A mesma plataforma pode servir duas entidades com obrigações diferentes; o hostname não resolve esse âmbito. Regista também a pessoa responsável por manter a interpretação e o evento que a faz regressar a revisão. Um campo desconhecido deve gerar trabalho, não ser convertido em não aplicável. No exercício, todas as obrigações são inventadas e a aplicabilidade é fornecida como entrada. O programa consegue conferir ligações e datas, mas não determina a lei que uma empresa real deve cumprir.

Quando duas condições não cabem na mesma configuração

O requisito fictício R1 impõe pelo menos 90 dias para o conjunto orders da entidade A; R2 impõe no máximo 30 dias. Se ambos forem confirmados para o mesmo conjunto e período, nenhum valor satisfaz as duas condições. Escolher 90 por parecer mais prudente viola o máximo; escolher 30 viola o mínimo. Antes de alterar dados, confirma se os objetos, cópias, finalidades e períodos são realmente iguais. Pode existir uma separação válida entre registo obrigatório e cópia de trabalho, mas essa interpretação precisa de fundamento e aprovação. O gestor coordena análise jurídica, privacidade, negócio e implementação, mantendo a incompatibilidade visível até existir decisão aplicável.

Rastrear do requisito até à observação

A cadeia do laboratório é requisito → política → responsável → evidência. Uma ligação presente não significa ligação correta. O requisito pode ser da entidade A e a política da B; a evidência pode referir a versão anterior do requisito. Verifica estas chaves antes de contar cobertura. Para cada observação guarda a data, o âmbito e a referência ao resultado. Se a equipa testou recuperação de reports, não usa esse resultado como prova sobre orders apenas porque ambos usam o mesmo armazenamento. O registo ajuda a encontrar a lacuna e a atribuir a próxima ação. A evidência continua a precisar de apreciação sobre qualidade, relevância e integridade fora desta simples reconciliação.

Preparar e executar o laboratório local

Usa Python 3 e uma pasta de saída nova: python3 content/labs/cism-governance-contracts/run.py --output /tmp/cism-governance-run-a. A execução cria entradas limpas e inconsistentes, relatórios e execution.json com resultados das verificações e hashes. O caso limpo tem dois requisitos aplicáveis e nenhuma flag; o caso inconsistente tem cinco flags distintas. Lê as razões em vez de usar apenas a contagem. Para experimentar outra data ou entrada, copia uma fixture e executa --input caminho.json --as-of 2026-10-07 --output /tmp/cism-analysis.json. Neste modo, o ficheiro de saída indicado é escrito diretamente: escolhe um caminho de trabalho que possas substituir. Nenhum serviço remoto é contactado.

Exercício: corrigir a ligação sem esconder a origem

No inconsistent-input.json, r1 continua ligado a p-orders, mas p-orders-v2 substitui essa política a partir do dia 8. Compara os relatórios de dia 7 e de dia 8 e explica a diferença. Depois liga r1 à versão atual e conserva o histórico da alteração na tua nota de decisão. A flag de substituição deve desaparecer, enquanto self-review e evidence-missing permanecem. Não preenchas a evidência com uma frase genérica só para obter zero flags: identifica o teste necessário e quem pode avaliar o resultado. Entrega o relatório antes/depois e três linhas sobre a decisão humana ainda pendente. O hash demonstra identidade dos bytes usados como referência, não a verdade da observação descrita.

Exercício: distinguir conflito de diferença de âmbito

Cria dois requisitos vigentes: um mínimo de 90 dias e um máximo de 30 dias. Primeiro coloca-os em conjuntos de dados diferentes; depois no mesmo conjunto e entidade. Prevê a alteração nas flags antes de executar. A rotina só identifica a interseção numérica impossível quando entidade e conjunto coincidem. Se um dos estados for unknown, não o trata como obrigação confirmada: devolve applicability-unresolved. Na tua resposta, separa erro de configuração, dúvida de aplicabilidade e potencial conflito entre requisitos. Justifica a informação adicional que pedirias a cada responsável. Não alteres o campo dataset apenas para eliminar a flag se os dados reais continuariam a ser os mesmos.

Caso prático: integrar duas políticas no serviço Maré

A entidade A adquire B. Ambas usam o arquivo Maré, mas A conserva orders e B conserva reports. A equipa importa uma política antiga de A para todas as linhas porque é a única versão no repositório do projeto. O registo assinala substituição e diferenças de âmbito; o revisor indicado também operou a configuração. Prepara uma proposta com quatro entregáveis: mapa de aplicabilidade confirmado, ligações de política corretas por entidade/conjunto, responsáveis aceites e plano de avaliação com o grau de independência exigido. Podes propor integração por etapas se os âmbitos forem separáveis e a decisão for autorizada. Adicionar uma aprovação genérica do sponsor não corrige os vínculos nem prova eficácia operacional.

Interpretar o resultado e fechar a aprendizagem

Duas execuções do laboratório observaram 30 verificações cada. Isso mostra o comportamento destas fixtures e do código executado, não cobertura de todas as obrigações possíveis. Mesmo sem flags, pode existir um requisito omitido da entrada, evidência falsa, um conflito não numérico ou um revisor com dependência não representada pelo nome. Para fechar o exercício, apresenta uma limitação concreta e uma forma de obter evidência adicional. Resume a sequência: confirmar âmbito, ligar versões, atribuir responsabilidades, obter observações e reavaliar quando mudam os pressupostos. Relaciona esta aula com governance empresarial, gestão de fornecedores, mudança e assurance. Uma boa decisão mantém visível o que se sabe, o que falta e quem deve agir.

Aplicabilidade antes de procurar uma contradição

Converte uma obrigação em condições verificáveis: entidade, população, evento, data de criação, estado atual e prazo. Só existe conflito direto quando requisitos incompatíveis abrangem o mesmo objeto e período. Num exercício, guardar ordens de A pelo menos 90 dias e apagar relatórios de B até 30 dias pode ser compatível se as populações forem realmente distintas e a classificação for mantida. Uma plataforma comum não torna os âmbitos iguais. As regras de transição também podem diferir. Uma assinatura adicional pode aplicar-se apenas a documentos criados a partir do dia 10, enquanto um catálogo de acesso se aplica a todos os documentos ativos a partir desse dia. Um documento criado no dia 8 e ativo no dia 12 necessita do catálogo, mas não satisfaz a condição de criação da primeira regra. Não deduzas retroatividade apenas da data em que uma política entra em vigor. No plano contratual, marca, país e tecnologia não substituem uma condição explícita sobre a entidade jurídica. Se a cláusula exige consentimento antes de mudar essa entidade, uma subsidiária distinta aciona o processo mesmo quando o grupo mantém a marca. Exercício: cria uma tabela de predicados para as três situações e indica a evidência de classificação ou interpretação necessária. Estes exemplos têm regras fictícias fornecidas, não constituem interpretação de legislação real.

Medir exatamente o compromisso e preservar o âmbito da prova

Antes de calcular um SLA, escreve o denominador e as exclusões autorizadas. Com 1 000 minutos programados, 10 de manutenção previamente aprovada e 7 de outra indisponibilidade, uma definição que exclui apenas a manutenção tem 990 minutos elegíveis e 983 de serviço. A disponibilidade é 983/990, cerca de 99,293%, abaixo de 99,5%. Excluir todos os minutos sem serviço porque a causa é conhecida altera o compromisso. Contar a manutenção como serviço também altera a definição, mesmo que o número pareça próximo. Frequência de revisão e população revista são igualmente distintas. Duas revisões após alterações de privilégios podem cumprir o requisito de analisar cada alteração antes de uso. Não demonstram que todas as permissões foram incluídas na revisão mensal. Usa um registo que associe cada prova à população, ao período e ao requisito correspondente; não descartes evidência válida só por ela não resolver outra obrigação. Exercício: reproduz a fração do SLA sem arredondar antes da comparação e constrói duas linhas de evidência para a revisão mensal e por alteração. A conclusão deve distinguir incumprimento demonstrado de requisito ainda sem prova. A aritmética confirma apenas a definição fictícia do exercício.

Resultados de política, perfis e equivalência linguística

Uma política pode exigir que o acesso deixe efetivamente de funcionar em dez minutos, enquanto um procedimento permite encerrar administrativamente o ticket em quatro horas. Verifica o comportamento exigido antes de declarar conflito: revogar aos oito minutos e documentar o fecho mais tarde pode cumprir ambos. O gestor que aprova o procedimento não ganha automaticamente autoridade para dispensar a política. No CSF, o perfil atual descreve o estado que existe e os resultados ainda em execução; o perfil pretendido descreve o que se procura alcançar. Orçamento aprovado para cobrir contas técnicas não demonstra que a revisão dessas contas já acontece. Liga a lacuna ao plano financiado e atualiza a realização quando houver evidência. De igual modo, quando o referencial permite escolha técnica, uma implementação local que demonstra os resultados e a exportação de evidência não precisa de uma exceção apenas por usar outro produto. A tradução também é uma implementação da política: trocar E por OU altera os requisitos. Se o documento define qual versão resolve divergências, usa essa regra, corrige a tradução com o responsável e mantém as condições obrigatórias. Exercício: revê uma instrução bilingue e identifica os verbos, conjunções, prazos e intervenientes cujo significado tem de ser preservado. Não assumas que um idioma é sempre superior; a autoridade resulta do processo documental definido.

Transição governada por resultados

Uma estratégia de identidade única pode permitir coexistência temporária para preservar o fecho diário. A instalação do novo serviço é um marco de entrega; a passagem dos consumidores e a prontidão de operações são evidência de transição. Define o âmbito, quem decide desligar, o que demonstra prontidão e como tratar condições não cumpridas antes de terminar a janela. Uma preferência local não transforma coexistência temporária em arquitetura permanente. Quando dois resultados são obrigatórios, procura uma sequência que preserve ambos. Se desligar uma conta partilhada hoje deixa metade dos operadores sem acesso, mas é possível criar e ensaiar identidades individuais hoje e desligar amanhã dentro da transição autorizada, a sequência ensaiada é uma proposta concreta. Não atribuas à segurança poder implícito para interromper um serviço cuja continuidade continua exigida. Mede ainda o resultado estratégico, não apenas atividade. Uma percentagem maior de aprovações automáticas pode coexistir com mais acessos incorretos corrigidos depois da ativação. Relaciona a meta com a duração dessa exposição e a qualidade da decisão; conserva a automação como indicador complementar. Exercício: escreve um gate de saída e duas medidas, uma de execução e outra do resultado. Explica que evidência faria adiar a saída sem declarar a estratégia abandonada.

python3 content/labs/cism-governance-contracts/run.py --output /tmp/cism-governance-run-a
NA PRÁTICA

Dois requisitos só geram conflito numérico no modelo se estiverem vigentes e abrangerem a mesma entidade e conjunto de dados.

Armadilhas comuns

Escolher automaticamente o prazo maior; mudar o âmbito para limpar flags; confundir nomes distintos com independência; usar hashes como prova de veracidade.

Tópicos relacionados: Governance e autoridade · Gestão de mudança · Evidência e assurance · Gestão de fornecedores

Leva esta ideia contigo

Um registo consistente ajuda a pedir a decisão certa; não determina conformidade nem substitui análise competente.

Criar conta

Referência: The NIST Cybersecurity Framework 2.0 · CISM current outline before November 3, 2026

CISM® é uma marca registada de ISACA. A dr.pt é uma plataforma de preparação independente e não está afiliada, associada, patrocinada, autorizada nem aprovada por ISACA. Os conteúdos e as perguntas são originais, não são perguntas oficiais de exame, e concluir os nossos testes não atribui nem garante qualquer certificação. Os nomes são usados apenas para identificar o tema. Todas as outras marcas pertencem aos respetivos titulares.