除了监控上述因素之外，项目管理者还应该监控风险缓解步骤的效力。例如：上例中，风险缓解步骤要求定义"文档的标准，并建立相应的机制，以确保文档能被及时建立"。如果有关键的人物离开了项目组，这是保证工作连续性的机制。项目管理者应该仔细地监控这些文档，以保证文档内容正确，当新员工加入该项目时，能为他们提供必要的信息。
 
风险管理及意外事件计划假设缓解工作已经失败，风险变成了现实。继续前面的例子，假定项目正在进行中，有一些人宣布将要离开。如果按照缓解策略行事，则有后备人员可用，因为信息已经文档化，有关知识已经在项目组中广泛进行了交流。此外，项目管理者还可以暂时重新将资源调整到那些需要人的地方去，并调整项目进度，从而使新加入的成员能够"赶上进度"。同时，要求那些要离开的人员停止工作，进入"知识交接模式"。
 
RMMM步骤将导致额外的项目开销。因此，风险管理的部分任务是评估何时由RMMM步骤所产生的效益低于实现它们所花费的成本。本质上是讲，项目计划者执行一个典型的成本－效益分析来估算项目开销变化情况。
 
对于一个大型项目，可能会标识出30－40种风险。如果为每种风险定义三至七个风险管理步骤，则风险管理本身可能变成一个"项目"。经验表明：整个软件风险的80％（即可能导致项目失败的80％潜在的因素）能够由仅仅20％的已知风险来说明。早期风险分析步骤中所实现的工作能够帮助计划者确定哪些风险在所说的20％中。
 
1、安全性风险和危险
 
风险不于软件项目本身。在软件已经能够交付客户之后，仍有可能发生风险。这些风险一般与领域中的软件失败相关。
 
虽然一个良好的系统发生错误的概率很小，但是基于计算机的控制及监督系统中未被发现的错误可能会导致巨大的经济损失，或者更加严重
 
当软件被用作控制系统的一部分时，复杂性会以数量级增加。由于人的错误所引起的微小的设计缺陷，在使用软件时会变得难以发现。
 
软件安全和危险分析是属于软件质量保证活动，它主要是用来标识和评估可能对软件产生负面影响并使整个系统失败的潜在危险。如果能够在软件工程的早期阶段标出危险，则可以指定软件设计特征来消除或控制潜在地危险。