Un registro de riesgos ayuda a decidir cuando los riesgos prioritarios, sus responsables y las siguientes mitigaciones se entienden de un vistazo. Para ordenar la historia, usa una historia de datos para presentaciones (en inglés): primero el método y la fecha, después la exposición y por último la decisión necesaria.
Cuando las descripciones de los riesgos estén revisadas, puedes usar la creación de presentaciones a partir de texto para preparar un borrador de diapositivas. Conserva el registro original y los enlaces a las evidencias: generar las diapositivas no autoriza una respuesta al riesgo.
Documenta método y fecha de corte
Indica escala, periodo y fecha de los datos. Explica si multiplicas probabilidad e impacto o aplicas otra regla. Una puntuación antigua no debe presentarse como estado actual.
Un impacto alto con probabilidad baja pide una decisión distinta a un evento frecuente que se puede contener. No inventes probabilidades exactas cuando los datos solo permiten una estimación cualitativa.
Incluye también la fuente del dato y la persona que lo comprobó para que el siguiente equipo pueda repetir la evaluación.
Haz legibles los riesgos prioritarios
Describe cada riesgo con causa, evento posible e impacto. Separa el valor inherente del riesgo residual después de la mitigación. Muestra la incertidumbre en lugar de inventar probabilidades exactas.
Un obstáculo técnico no es lo mismo que el daño que podría provocar. Esta separación evita contar dos veces la misma consecuencia.
Veamos una migración del sistema de identidades. R-01 es un ejemplo ficticio de planificación, no el informe de una migración completada.
| Campo de R-01 | Entrada para la migración de identidades |
|---|---|
| Objetivo y periodo | Completar las pruebas de extremo a extremo antes del lanzamiento previsto; evaluar el periodo hasta la decisión de cambio de sistema. |
| Causa | La correspondencia de roles entre el sistema de identidades anterior y el nuevo aún está pendiente de confirmación. |
| Posible evento | El nuevo flujo de identidad no está listo para las pruebas de extremo a extremo cuando debe decidirse el cambio. |
| Impacto | No pueden completarse las pruebas necesarias del flujo; quizá haya que aplazar el lanzamiento. Aún no se ha estimado la duración del retraso. |
| Responsabilidad | La persona responsable de la migración comunica los cambios; el patrocinador del proyecto autoriza un cambio del lanzamiento. |
| Prevención y evidencia | Confirmar los roles y probar recorridos representativos de administrador, usuario estándar y cuenta de servicio. Conservar la revisión de roles y los resultados, incluidos los fallos. |
Si ya se incumplió el plazo de las pruebas, el hito fallido es un problema ocurrido, no una probabilidad futura. Vincula su registro de incidencias con R-01 y conserva el historial. Evalúa por separado la incertidumbre posterior, como su efecto sobre una nueva fecha de lanzamiento, sin volver a puntuar el evento que ya ocurrió.
Revisa responsables y mitigaciones
Cada mitigación necesita responsable, estado, fecha objetivo y evidencia esperada. «En curso» no es un siguiente paso comprobable. Sin responsable o fecha, el punto sigue siendo una decisión abierta.
Para R-01, define una señal concreta: si la confirmación de roles sigue bloqueada durante dos ciclos semanales consecutivos de seguimiento, la persona responsable de la migración eleva el asunto al patrocinador. No esperes al segundo ciclo si la decisión de cambio o una condición de seguridad exige actuar antes. Los dos ciclos son una regla del proyecto del ejemplo, no un umbral universal.
La contingencia consiste en aplazar el cambio y mantener disponible el servicio de identidades actual mientras se completan las pruebas pendientes. Indica quién puede aprobar la opción, si puede mantenerse el soporte del servicio anterior y qué condiciones de seguridad y operación se aplican. La persona responsable de la migración la propone; el patrocinador debe aprobar expresamente el cambio del lanzamiento antes de considerarlo autorizado.
Una evaluación menor del riesgo residual requiere la confirmación de roles y los resultados de repetir las pruebas. Cerrar una tarea o conseguir un único inicio de sesión no demuestra que funcionen los tres recorridos. Hasta que los fallos se resuelvan o sean aceptados conscientemente por quien tiene autoridad, muestra la exposición restante y la próxima revisión.
El Orange Book de HM Treasury relaciona el tratamiento del riesgo con las responsabilidades de aprobación, el seguimiento y los planes de contingencia. Las acciones de R-01 son un ejemplo de proyecto, no un procedimiento obligatorio de la guía.
El siguiente paso puede ser una revisión técnica, una cláusula o una prueba.
No muestres estos puntos de decisión o escalado como si estuvieran resueltos, marcándolos en verde.
Estructura breve del soporte
- Pregunta de decisión y fecha de datos
- Método y escala
- Matriz o lista priorizada
- Riesgos principales, causas e impactos
- Mitigaciones, responsables y riesgo residual
- Decisiones y próxima comprobación
Deja las filas detalladas y fuentes en el anexo. En la diapositiva principal conserva solo lo que cambia recursos, escalado o supuestos.
Termina con la próxima comprobación
Cierra con decisiones y fecha del próximo control.
Una puntuación describe un método, no el futuro. Separa hechos confirmados, supuestos y señales por seguir. Así se pueden asignar recursos o escalar sin atribuir al registro una precisión que no tiene.
