Entenda como estruturar um registro de riscos (risk register) em projetos de Engenharia, definir campos, owners, gatilhos, tratamentos, histórico e risco residual.
Confira!
Um registro de riscos, ou risk register, é o repositório estruturado que mantém a história de cada risco ao longo do projeto: descrição, causa, evento, consequência, classificação, controles existentes, responsável, estratégia de resposta, ações, prazos, gatilhos, status e exposição residual. Em Engenharia, ele transforma a gestão de riscos em um processo rastreável e auditável, em vez de uma discussão pontual feita apenas em workshops ou reuniões de planejamento.
A função do registro não é substituir a matriz de riscos. A matriz compara criticidade; o risk register preserva contexto, decisões e evolução. Um projeto pode ter uma matriz visual excelente e ainda assim gerir mal seus riscos se não houver um registro vivo, com responsáveis, evidências e histórico de revisão.
O registro também precisa acompanhar o ciclo real do empreendimento. Riscos mudam quando requisitos são definidos, projetos são aprovados, fornecedores são contratados, equipamentos entram em fabricação, obras avançam, testes começam e condições de operação se alteram. Um risk register congelado é apenas um retrato antigo da exposição.
O que é um registro de riscos e por que ele é diferente da matriz
O registro de riscos é uma base estruturada de informação sobre incertezas que podem afetar objetivos do projeto. Ele pode existir em planilha, sistema de gestão, ambiente de PMO ou plataforma integrada, mas seu valor não depende da ferramenta. Depende da qualidade dos campos, da disciplina de atualização e da capacidade de ligar cada risco a decisões, ações e evidências.
A matriz de riscos responde principalmente à pergunta: quais riscos são mais críticos? O registro de riscos responde a perguntas mais amplas: o que pode acontecer, por que, com qual consequência, quem é o responsável, que resposta foi definida, o que já foi feito, qual exposição permanece e quando o risco deve ser revisto?
Essa distinção evita um erro recorrente: tratar a matriz colorida como se ela fosse o sistema completo de gestão. Em projetos multidisciplinares, a matriz é uma visualização; o registro é a memória operacional.
| Elemento | Função | Informação principal |
| Matriz de riscos | priorizar | probabilidade, consequência e classe |
| Registro de riscos | manter rastreabilidade | causa, evento, consequência, owner, ações, status e histórico |
| Plano de resposta | executar tratamento | ação, responsável, prazo, recurso e evidência |
| Issue log | controlar problemas já ocorridos | problema, impacto, decisão e resolução |
O registro de riscos é a memória operacional da gestão de riscos. A matriz mostra prioridade; o risk register precisa preservar causa, decisão, owner, ações, evidências e histórico de revisão para que a exposição seja realmente governada.
Risco não é problema, pendência ou não conformidade
Um registro de riscos perde qualidade quando recebe qualquer assunto que preocupa a equipe. É necessário distinguir estados diferentes.
Risco é uma incerteza que pode produzir efeito sobre objetivos. Problema ou issue é algo que já ocorreu. Pendência é uma ação ou decisão ainda não concluída. Não conformidade é o não atendimento a um requisito. Achado técnico é uma constatação baseada em evidência. Esses elementos podem se relacionar, mas não devem ser tratados como equivalentes.
Considere um equipamento crítico com prazo de fabricação de 24 semanas. Antes da data contratual vencer, pode existir um risco de atraso decorrente de aprovação tardia de desenhos. Se a data de aprovação já foi perdida, o assunto deixou de ser somente risco e passou a ser um problema ativo. O registro de riscos ainda pode manter riscos secundários decorrentes do atraso, como perda da janela de instalação, compressão do comissionamento ou custos adicionais.
Essa diferenciação melhora a governança porque cada tipo de informação segue um fluxo apropriado. Misturar tudo em uma única lista tende a criar dezenas de itens sem critérios claros de prioridade.
Como escrever um risco de forma tecnicamente útil
Descrições genéricas como “risco de atraso”, “risco de fornecedor” ou “risco de incompatibilidade” são insuficientes. Elas não permitem analisar mecanismo causal nem definir uma resposta adequada.
Uma estrutura útil separa causa → evento → consequência.
Exemplo:
> Devido à possibilidade de aprovação tardia do projeto executivo pelo contratante, a liberação para fabricação pode ocorrer após a data-base, deslocando o fornecimento para além da janela de implantação e comprometendo o marco contratual de energização.
Essa redação permite buscar evidências: prazo de aprovação, maturidade dos documentos, lead time do fabricante, folga do cronograma, dependências e janela operacional.
Uma boa descrição também evita registrar a própria consequência como se fosse risco. “Atraso no projeto” é resultado. O registro deve esclarecer o evento incerto que pode provocar esse atraso e as condições que o tornam plausível.
Campos essenciais de um risk register
Não existe uma única estrutura universal. O registro deve ser proporcional ao porte, à complexidade e à maturidade do empreendimento. Ainda assim, alguns campos são recorrentes porque sustentam a decisão.
Identificação e contexto
- identificador único;
- título curto do risco;
- categoria ou disciplina;
- fase do projeto;
- data de identificação;
- origem da informação;
- objetivo potencialmente afetado.
Formulação técnica
- causa ou condição de origem;
- evento de risco;
- consequência ou efeito esperado;
- premissas relevantes;
- dependências e interfaces relacionadas.
Avaliação
- probabilidade ou verossimilhança;
- consequência por dimensão;
- criticidade;
- justificativa da avaliação;
- controles existentes;
- exposição atual.
Governança
- risk owner;
- action owner, quando diferente;
- alçada de decisão;
- estratégia de resposta;
- ações de tratamento;
- recursos necessários;
- data-alvo;
- gatilhos de escalonamento.
Acompanhamento
- status;
- tendência;
- última revisão;
- próxima revisão;
- evidências de implementação;
- risco residual;
- decisão de aceite, encerramento ou reabertura.
Um registro pode conter campos adicionais para custo de resposta, reserva de contingência, vínculo com cronograma, contrato, fornecedor, ativo, requisito ou documento técnico.
O que é risk owner e por que ele não deve ser confundido com action owner
O risk owner é o responsável por acompanhar a exposição, promover decisões e assegurar que a resposta definida avance. Ele não precisa executar todas as ações.
Em um risco de atraso de fornecimento, o gerente do projeto pode ser o risk owner. A ação de emitir a especificação antecipadamente pode pertencer à Engenharia; a negociação com o fabricante pode caber ao Procurement; a aprovação pode depender do contratante. Cada ação possui um responsável, mas alguém precisa permanecer responsável pelo risco como um todo.
Sem essa distinção, é comum que um risco fique “sem dono” assim que uma tarefa é delegada. A equipe assume que o assunto foi tratado porque existe uma ação aberta, mesmo quando a exposição continua elevada.
O registro deve permitir que a governança responda rapidamente: quem tem autoridade e responsabilidade para conduzir este risco até uma condição aceitável?
Como registrar probabilidade, consequência e criticidade
O risk register não precisa duplicar todos os detalhes da metodologia da matriz, mas deve registrar a classificação vigente e a evidência que a sustenta.
Uma avaliação útil não contém apenas “probabilidade 4, impacto 5”. Ela inclui uma justificativa curta: histórico do fornecedor, atraso atual de desenhos, quantidade de interfaces, tendência do cronograma, maturidade de requisitos ou qualquer outra evidência pertinente.
Essa prática permite revisar a pontuação sem depender da memória de quem participou do workshop anterior.
Também é recomendável registrar as dimensões de consequência separadamente quando elas forem relevantes. Um risco pode ter impacto moderado em custo e crítico em segurança ou operação. Reduzir tudo a um único número pode esconder a natureza real da decisão.
Risco inerente, atual e residual
Muitos registros ficam confusos porque usam uma única classificação durante todo o ciclo. Uma estrutura mais madura diferencia estados de exposição.
Risco inerente representa uma exposição de referência antes de determinados controles ou tratamentos. Risco atual representa a condição observada no momento da revisão, considerando controles efetivamente existentes. Risco residual representa a exposição esperada ou observada após a implementação do tratamento adicional.
Essa distinção evita considerar uma ação planejada como se ela já tivesse reduzido o risco. Um plano ainda não implementado não deve receber o mesmo crédito de um controle testado e eficaz.
O registro pode manter duas leituras de residual: residual esperado, usado para justificar a estratégia, e residual verificado, atualizado após a implementação e evidência de eficácia.
Uma ação planejada não reduz risco até ser implementada e verificada. O registro precisa distinguir exposição atual, residual esperada e residual efetivamente observada para evitar falsa sensação de controle.
Status: aberto, monitorado, tratado, aceito ou encerrado
Status mal definidos reduzem a utilidade do registro. “Fechado” pode significar que o risco não existe mais, que foi aceito, que a ação terminou ou simplesmente que alguém deixou de acompanhar o assunto.
Uma taxonomia mais clara pode incluir:
- identificado: risco registrado e ainda não avaliado completamente;
- ativo: exposição vigente e sob acompanhamento;
- em tratamento: resposta aprovada e ações em execução;
- monitorado: sem ação adicional imediata, mas sujeito a gatilho;
- aceito: exposição residual aceita por autoridade competente;
- materializado: evento ocorreu e o assunto migrou para gestão de issue;
- encerrado: risco não é mais aplicável ou foi eliminado;
- reaberto: condição voltou a ser relevante após mudança de contexto.
O número de status deve permanecer administrável. O objetivo é tornar o estado inteligível, não criar burocracia.
Tendência do risco: subir, estabilizar ou cair
A criticidade atual não conta toda a história. Dois riscos podem estar classificados como “alto”, mas um está sendo reduzido e o outro piorando rapidamente.
Por isso, muitos registros incorporam um campo de tendência. Uma seta de alta, estabilidade ou queda pode ser suficiente desde que exista critério.
A tendência deve refletir evidências: consumo de folga, atraso acumulado, avanço de fabricação, melhoria da definição técnica, aprovação de documentos, conclusão de testes ou deterioração de uma premissa.
Essa informação ajuda a direção do projeto a identificar riscos que exigem atenção antes de mudarem formalmente de faixa na matriz.
Gatilhos e sinais de alerta
Um risco pode permanecer em monitoramento até que determinada condição seja atingida. O gatilho define quando a equipe precisa agir ou escalar.
Exemplos:
- desenho não aprovado até determinada data;
- fornecedor sem confirmação de matéria-prima até o marco definido;
- consumo de mais de 70% da folga disponível;
- taxa de retrabalho acima de um limite;
- ocorrência de uma falha específica em FAT;
- indisponibilidade confirmada da janela operacional;
- mudança normativa ou regulatória relevante.
Gatilhos bem definidos evitam depender de interpretações subjetivas sobre “quando o risco ficou sério”.
Como ligar o registro de riscos ao cronograma
Riscos de prazo devem ser conectados aos marcos e atividades que podem ser afetados. Sem essa ligação, o registro permanece separado do planejamento real.
Um risco de fabricação, por exemplo, pode afetar entrega, instalação, energização, testes e aceite. O cronograma deve permitir identificar a cadeia de impacto, folgas disponíveis e atividades de recuperação.
Em projetos de maior complexidade, alguns riscos podem receber identificadores que também aparecem no cronograma ou no modelo de análise quantitativa. Isso facilita simulações, revisões e auditorias.
A integração não exige inserir toda a lógica do cronograma no registro. Basta preservar a rastreabilidade entre risco e objetivo temporal afetado.
Como ligar o registro ao orçamento e à contingência
Riscos com impacto financeiro precisam informar decisões sobre reservas e exposição econômica. O registro pode incluir faixas de impacto, custo esperado da resposta, estimativa de perda potencial ou vínculo com a reserva de contingência.
É importante não confundir custo do tratamento com impacto do risco. Gastar para reduzir uma exposição pode ser economicamente racional quando o custo da resposta é inferior à perda evitada ou quando a consequência não é aceitável por outros critérios.
Em análises quantitativas, o registro também pode alimentar distribuições de impacto e probabilidades usadas em simulações.
Como integrar riscos a contratos e fornecedores
Em Engenharia, muitos riscos nascem em interfaces contratuais. Escopo mal definido, dependências do contratante, critérios de aceite ambíguos, prazos de aprovação, fornecedor único, lead time, importação, homologação e garantia são exemplos.
O registro deve permitir identificar a parte responsável pela condição, mas não deve ser usado como mecanismo para transferir responsabilidade de forma artificial. Uma boa gestão distingue alocação contratual de risco de responsabilidade gerencial pelo acompanhamento.
Mesmo quando o contrato atribui uma obrigação ao fornecedor, o contratante ou Owner’s Engineering pode precisar acompanhar a exposição porque o impacto final continua afetando o empreendimento.
Riscos de interface em projetos multidisciplinares
Riscos de interface merecem tratamento específico porque atravessam disciplinas, empresas e pacotes de contratação.
Uma incompatibilidade entre arquitetura, elétrica e telecomunicações pode não pertencer claramente a uma única equipe. O risk owner precisa atuar sobre a fronteira, coordenando decisões, entregáveis e responsabilidades.
Campos como “interface afetada”, “disciplina origem”, “disciplina dependente” e “documento de interface” podem agregar valor em empreendimentos complexos.
A ligação com gestão de interfaces reduz o risco de cada equipe considerar que a exposição pertence a outra parte.
Risk Breakdown Structure e categorias
Categorias ajudam a verificar cobertura e identificar concentração de exposição. Uma Risk Breakdown Structure (RBS) organiza fontes de risco em grupos coerentes.
Em projetos de Engenharia, uma estrutura pode incluir:
- requisitos e escopo;
- projeto e compatibilização;
- tecnologia;
- suprimentos e fornecedores;
- contratos;
- construção e campo;
- segurança e meio ambiente;
- qualidade;
- comissionamento e aceite;
- operação e manutenção;
- stakeholders e aprovações;
- prazo e custo;
- regulatório e licenciamento.
A categorização não deve limitar a identificação. Se a equipe só procura riscos nas categorias existentes, pode deixar de perceber riscos emergentes ou sistêmicos.
Como registrar oportunidades
Risco não precisa ser tratado somente como ameaça. Incertezas também podem produzir efeitos positivos.
Uma oportunidade pode ser antecipação de compra, padronização técnica, solução alternativa que reduz CAPEX, disponibilidade de uma janela adicional, consolidação de fornecedores ou uso de tecnologia com melhor desempenho.
O registro pode incluir ameaças e oportunidades, desde que os critérios de avaliação sejam claros. Em algumas organizações, manter campos separados melhora a leitura porque “impacto alto” pode ter sentidos opostos em ameaça e oportunidade.
Histórico de alterações e rastreabilidade
Um registro de riscos é parte da memória decisória do projeto. Alterar a probabilidade de 4 para 2 sem registrar por que a mudança ocorreu destrói parte do valor da ferramenta.
A trilha de auditoria deve permitir responder:
- qual era a classificação anterior;
- quando mudou;
- quem aprovou;
- qual evidência justificou a alteração;
- qual tratamento foi concluído;
- qual exposição residual foi aceita.
Em sistemas digitais, esse histórico pode ser automático. Em planilhas, pode exigir uma aba de histórico ou campos de revisão.
Cadência de revisão: semanal, mensal ou por gatilho?
Não existe frequência universal. A cadência deve refletir a velocidade de mudança do projeto.
Um empreendimento em fase conceitual pode revisar riscos em marcos de decisão. Durante fabricação e implantação, revisões semanais podem ser necessárias. Em operação estável, a frequência pode ser menor.
Além da cadência, eventos devem provocar revisão extraordinária: mudança de escopo, troca de fornecedor, revisão de baseline, falha em teste, atraso de aprovação, alteração regulatória ou nova condição de campo.
A combinação de cadência + gatilho é mais robusta que depender somente de reuniões programadas.
Como conduzir uma reunião de revisão de riscos
Uma reunião eficiente não deve reler todo o registro linha por linha. O foco precisa estar em mudança de exposição e decisões necessárias.
Uma sequência útil é:
- revisar riscos críticos e altos;
- identificar riscos cuja tendência piorou;
- verificar ações vencidas;
- reavaliar riscos afetados por mudanças recentes;
- revisar novos riscos identificados;
- decidir escalonamentos e aceitações;
- verificar riscos que podem ser encerrados;
- atualizar próximos gatilhos e datas de revisão.
A reunião deve produzir decisões, não apenas atualização administrativa.
Indicadores do registro de riscos
Contar quantos riscos existem é pouco informativo. Indicadores mais úteis observam qualidade e dinâmica da carteira.
Exemplos:
- riscos críticos e altos por fase;
- riscos sem owner;
- ações vencidas;
- riscos sem atualização há mais de determinado período;
- exposição residual acima do critério de aceitação;
- quantidade de riscos materializados;
- concentração por categoria;
- tendência da exposição total;
- tempo médio para redução de criticidade;
- percentual de tratamentos com eficácia verificada.
Esses indicadores devem apoiar decisão e não estimular comportamento artificial, como encerrar riscos apenas para melhorar um KPI.
Erros que transformam o risk register em “cemitério de riscos”
Alguns padrões indicam que o registro perdeu função gerencial:
- dezenas de riscos sem owner definido;
- descrições genéricas;
- datas de revisão antigas;
- ações sem prazo;
- classificações sem justificativa;
- risco residual nunca atualizado;
- assuntos já materializados permanecendo como risco;
- itens encerrados sem evidência;
- registro usado apenas antes de auditorias;
- ausência de vínculo com cronograma, contrato ou decisões do projeto.
O problema não é a planilha ou o software. É a desconexão entre o registro e a governança real.
Quando o risk register vira apenas uma planilha preenchida para reunião, a gestão de riscos já se desconectou do projeto. O registro precisa alimentar decisões, cronograma, contratos, respostas e escalonamentos — não apenas produzir status.
Planilha ou sistema: o que muda de verdade
Planilhas podem funcionar bem em projetos menores, desde que exista controle de versão, disciplina de atualização e responsabilidade clara. Sistemas agregam valor quando o volume, a quantidade de usuários ou a necessidade de integração tornam a planilha frágil.
Um ambiente digital pode fornecer histórico automático, alertas, permissões, dashboards, vínculo com documentos, cronograma, contratos, requisitos, ações e evidências.
Ainda assim, automatizar um processo ruim apenas acelera a produção de informação de baixa qualidade. A sequência correta é definir método, campos, responsabilidades e governança; depois escolher a ferramenta.
Registro de riscos em Owner’s Engineering e PMO
Em Owner’s Engineering, o registro pode funcionar como instrumento de governança entre contratante, projetistas, fornecedores, construtoras e operação.
O Owner’s Engineer não precisa assumir a propriedade de todos os riscos. Seu papel pode incluir consolidar exposições, desafiar avaliações, verificar consistência, acompanhar respostas, facilitar escalonamento e assegurar que riscos críticos sejam visíveis à autoridade competente.
No PMO, o registro pode ser consolidado em nível de programa ou portfólio para identificar riscos comuns, dependências entre projetos e exposições sistêmicas.
Critérios para um registro de riscos tecnicamente defensável
Um risk register robusto deve permitir que outro profissional qualificado compreenda a lógica da decisão sem depender da memória da equipe.
Verifique se:
- cada risco possui descrição causal clara;
- a avaliação tem justificativa;
- controles existentes são registrados;
- risk owner e action owners são distinguíveis;
- ações possuem prazo e evidência;
- gatilhos estão definidos quando aplicável;
- risco residual é reavaliado;
- mudanças de classificação têm histórico;
- aceitações possuem alçada registrada;
- o registro é revisado quando o contexto muda.
Considerações finais
O registro de riscos é uma peça central da governança de projetos porque transforma incerteza em informação rastreável. Seu valor não está na quantidade de colunas nem na sofisticação do software, mas na capacidade de conectar causa, exposição, responsabilidade, resposta, evidência e decisão.
Em Engenharia, um risk register vivo precisa acompanhar requisitos, interfaces, fornecedores, cronograma, custo, contrato, qualidade, segurança, comissionamento e operação. Quando esses vínculos são preservados, o registro deixa de ser uma lista administrativa e passa a funcionar como memória operacional da gestão de riscos.
O objetivo final não é manter todos os riscos abertos indefinidamente. É permitir que a equipe saiba quais exposições exigem ação, quais podem ser monitoradas, quais foram reduzidas, quais se materializaram e quais foram aceitas de forma consciente e documentada.
Referências técnicas
[1] INTERNATIONAL ORGANIZATION FOR STANDARDIZATION. ISO 31000:2018 — Risk management — Guidelines. Geneva: ISO, 2018. Disponível em: https://www.iso.org/standard/65694.html
[2] PROJECT MANAGEMENT INSTITUTE. Risk Management in Portfolios, Programs, and Projects: A Practice Guide. Newtown Square: PMI, 2024. Disponível em: https://www.pmi.org/standards/risk-management-in-portfolios
[3] HM TREASURY. The Orange Book: Management of Risk — Principles and Concepts. London: HM Treasury, atualização 2026. Disponível em: https://www.gov.uk/government/publications/orange-book/the-orange-book-management-of-risk-principles-and-concepts
Perguntas frequentes
É o repositório estruturado que mantém descrição, avaliação, responsáveis, respostas, ações, status, evidências e histórico de cada risco ao longo do projeto.
A matriz compara criticidade entre riscos. O risk register preserva o contexto completo de cada exposição, incluindo causa, consequência, owner, tratamento, prazos, status e histórico.
No mínimo: identificador, descrição do risco, causa, evento, consequência, probabilidade, impacto, criticidade, controles, risk owner, resposta, ações, prazos, status, última revisão e risco residual.
A governança precisa definir responsáveis. O risk owner deve assegurar que seu risco seja atualizado, enquanto PMO, gerente de projeto ou função de riscos pode consolidar e controlar a qualidade do registro.
A frequência depende da dinâmica do projeto. Além de uma cadência definida, mudanças de escopo, fornecedor, cronograma, requisito, contrato ou resultados de testes devem funcionar como gatilhos de revisão.
O histórico pode permanecer, mas o evento ocorrido deve migrar para o fluxo de issue ou problema. Novos riscos decorrentes da materialização devem ser avaliados separadamente.
Não. Planilhas podem funcionar em projetos menores. Sistemas agregam valor quando há necessidade de colaboração, histórico, alertas, integração e maior volume de informação.
É a exposição que permanece depois dos controles e tratamentos. Ela deve ser reavaliada com base em medidas efetivamente implementadas, não apenas em ações planejadas.
Materiais técnicos complementares
Soluções relacionadas
- Governança de Projetos, Programas e Portfólios
- Gestão de Contratos, Escopo e Entregáveis
- Gestão de Requisitos, Evidências e Critérios de Aceite
Serviços relacionados
- Gerenciamento de Riscos de Engenharia
- Consultoria Técnica de Engenharia
- Planejamento Técnico de Contratações de Engenharia
Conteúdos principais sobre o tema
- Gestão de riscos em projetos de engenharia
- Matriz de Riscos em Projetos de Engenharia
- Análise de Riscos em Projetos de Engenharia
- Mitigação de Riscos em Projetos de Engenharia
