Analista de governança, risco e conformidade

Pelo que responde

• Política específica o bastante para ser seguida e geral o bastante para sobreviver a uma troca de produto.
• Um registro de riscos que reflita a organização, e não um modelo pronto.
• Evidência que exista antes de ser pedida.

Como é medido

• Apontamentos de auditoria, e se os do ano passado foram de fato encerrados.
• Certificação mantida sem crise no mês anterior à avaliação.
• Exceções com dono e data de expiração, em vez de uma lista sem limite.

Quem mais tem interesse

• Clientes, cujos contratos cada vez mais especificam controles que este papel precisa evidenciar.
• Seguradoras, que hoje fazem as mesmas perguntas com dinheiro anexado.
• Todo time que herda um requisito escrito aqui.

O que exige

• Alfabetização técnica suficiente para saber quando uma alegação de implementação não é verdadeira.
• Escrita que sobreviva à leitura de um advogado, de um engenheiro e de um auditor.
• Teimosia para seguir pedindo evidência depois de ouvir que ela existe.
• Senso de proporção, já que um programa de controles que ignora custo passa a ser ignorado.

As fontes publicadas

• ISACA - COBIT, the governance framework that separates governance from management and is the common reference for GRC work
• NIST SP 800-53 Rev. 5 - the control catalogue that security architecture and policy work is written against in practice
• ISO/IEC 27001:2022 - Information security, cybersecurity and privacy protection: information security management systems, requirements. Third edition, published October 2022 by ISO/IEC JTC 1/SC 27, and the certification most GRC programmes are audited against

Para onde leva

• IT auditorQuem defende
• Security leaderQuem defende
• Security architectQuem defende
• Security managerQuem defende

O trabalho em si

A Prática cobre como este trabalho é feito — triagem, escalação, evidência, passagem de bastão — em todo o corpus.

• Lendo um projeto que não foi você quem fezHerdar um sistema projetado por outra pessoa é uma das situações mais comuns deste trabalho, e o primeiro ato não é julgar o projeto: é recuperar as restrições a que ele respondia. Quase tudo que parece errado é uma decisão cuja razão já saiu do prédio, e as partes genuinamente erradas são indistinguíveis das que não são até você saber qual é qual.
• Para que serve, de fato, o teste de aceitaçãoTeste de aceitação não é uma demonstração de que o sistema funciona. A função real dele é registrar o que ficou acordado como "funcionando", enquanto as duas partes ainda querem concordar — para que a discussão que chega dezoito meses depois tenha um documento em vez de duas memórias.
• O runbook que ninguém consegue seguir, e por quêRunbooks falham quando são escritos pela pessoa que menos precisa deles, no momento em que ela mais entende o sistema, para um leitor que ela imagina ser ela mesma. A correção não é mais detalhe — é escrever para um leitor específico em um estado específico, e então deixar esse leitor quebrar o documento antes de você precisar dele.
• Passagem: o momento em que um projeto vira operaçãoA passagem é tratada como transferência de documentos e é, na verdade, transferência de julgamento — e julgamento é a única coisa que não se transfere numa reunião. O que dá para transferir é o raciocínio por trás das decisões, a lista do que ficou por fazer, e o nome de alguém que vai atender o telefone.
• Linha de base — saber como é o normal antes de precisarUma linha de base não é monitoração nem documentação. É a resposta à única pergunta que importa nos primeiros dez minutos de um incidente — isso sempre foi assim? — e é o único artefato que só pode ser feito quando nada está errado.
• O que uma linha de base não consegue dizerUma linha de base registra o que aconteceu durante o período em que foi tirada e promove, em silêncio, as condições daquele período ao status de normal. Ela responde se algo mudou, o que já vale muito — mas não consegue dizer se aquilo que registrou algum dia esteve certo, e a diferença entre essas duas perguntas é de onde saem as respostas erradas ditas com confiança.
• Janelas de mudança, e a aritmética do rollbackUma janela de mudança não é o tempo que a mudança leva. É o tempo da mudança mais o tempo para descobrir que deu errado mais o tempo para desfazer — e o terceiro número é o que ninguém mede, razão pela qual janelas estouram e rollbacks são abandonados pela metade.
• Nomenclatura, endereçamento e o custo de errar cedoNomenclatura e endereçamento são decididos numa tarde por quem estiver livre, e sobrevivem a todas as outras decisões do parque — não porque sejam tecnicamente difíceis de mudar, mas porque todo o resto passa, em silêncio, a depender deles. A conta é paga anos depois, por outra pessoa, numa moeda que ninguém orçou.

Ler A Prática