¿Cómo hacer un perfil de riesgo?

TL;DR

La evaluación de riesgos es un tema amplio que puede (y ha) llenado muchos libros. No hay una respuesta simple a su pregunta. Sin embargo, ciertamente hay puntos de partida.

Préstamo de seguridad/auditoría

Los campos de seguridad y auditoría tienen algunos modelos de evaluación de amenazas (riesgos) bien definidos. Por ejemplo, OWASP detalla el proceso de modelado de amenazas de Microsoft . Si bien este modelo realmente se enfoca más en la seguridad de la información que en el riesgo del proyecto en general, sigue siendo un enfoque sólido para examinar el riesgo.

Estándares de evaluación de riesgos comerciales

También hay una serie de marcos y estándares de evaluación de riesgos disponibles comercialmente. Éstos incluyen:

• AS/NZS ISO 31000:2009 Gestión de riesgos: principios y directrices
• Guía NIST 800-30 para realizar evaluaciones de riesgos
• Marco OCTAVE de Carnegie Mellon

La ISO 31000 parecería ser la más independiente del dominio y dice que "puede ser utilizada por cualquier organización, independientemente de su tamaño, actividad o sector". Su kilometraje puede variar en este sentido.

Debería poder encontrar otros marcos dedicados a proyectos que no sean de TI, pero tendrá que usar algunos conocimientos específicos del dominio para investigar los problemas si desea algo más que un enfoque genérico. Por otro lado, si todo lo que desea es un enfoque genérico, cualquiera de los modelos de evaluación de riesgos debería ser suficiente; simplemente modifíquelos para adaptarlos al dominio comercial particular de su proyecto.

Además del consejo de @CodeGnome, también puede consultar a la Sociedad de Analistas de Riesgos de la Información .

podcast de riskscience que actualmente analiza conceptos de tolerancia al riesgo que pueden estar relacionados con la "perfil de riesgo". En un episodio reciente, discutieron una serie de marcos de riesgo más allá de los que citó @CodeGnome. Se centran en el análisis de riesgos de la información, no en el análisis de riesgos de proyectos, pero recomiendo mucho su trabajo, particularmente el trabajo de Tony Cox sobre la limitación de PIG (Probability Impact Graphs)

PMI publica el Estándar de práctica para la gestión de riesgos de proyectos , que tiene autoridad pero es costoso.

@CodeGnome menciona la guía NIST 800-30 sobre la que soy escéptico; es adecuado para iniciar la gestión de riesgos, pero los valores tienden a no estar calibrados y no son útiles para tomar decisiones - El estándar de PMI es mejor, pero creo que todavía está por debajo de la meta real. No creo que quiera basar un análisis de monte carlo en evaluaciones de riesgo hechas con cualquiera de los dos sistemas.

FAIR es un sistema costoso en el otro extremo del espectro; es muy probable que sea más de lo que necesita (más caro, más completo y más complicado). Pero si te tomas en serio la gestión de riesgos, te recomiendo que aprendas FAIR. (No puedo pagarlo en este momento, pero me he quedado en los bordes el tiempo suficiente para entender la metodología, incluso si me faltan los detalles).

Antes de comenzar la evaluación, piense en cómo la presentará

@CodeGnome y @Mark C. Wallace le brindaron excelentes referencias para la evaluación de riesgos. Sin embargo, es bueno pensar en cómo va a presentar sus hallazgos antes de comenzar.

Recomiendo presentarlo en una Cuadrícula de Impacto de Probabilidad superpuesta con el Apetito de Riesgo del negocio:

"Cada riesgo debe calificarse en términos de su probabilidad de ocurrencia e impacto en el proyecto. Estas cifras deben multiplicarse para determinar una calificación individual para cada riesgo como un porcentaje. Probabilidad x Impacto x 100 = Porcentaje de riesgo. En la tabla anterior , los puntos de corte fueron <5% (verde), >5% a <15% (amarillo) o >15% (rojo)"

Por ejemplo, si estima que la probabilidad es muy baja y el impacto es medio, ese riesgo se asignará al cuadro del 2 %.