合规性控制与风险管理

更常规化的评估(例如，基于ISO27001的评估)，可以减少遗漏细节的范围。通过使用行业最佳实践框架来评估控制，至少可以放心地知道所评估的控制是保护某些安全域所广泛需要的控制。此外，对于经验不足的风险管理人员来说，这种方法也提供了一个安全的工作基础，并提供了一定程度的指导，至少在安全领域是这样。

我已经看到了这些类型的行业所公认的信息安全框架被用作技术风险框架的基础，但这又给我提出了一个问题：如何识别不属于安全领域的控制，更重要的是，如何识别相关的业务风险?根据我的经验，一个严格的以控制为重点的评估可能会错过企业的真正风险敞口。即使是一个非常明确的路径也不能提供一种能够识别新的和正在出现的风险的方法，因为这些风险是预先确定的。

在我工作过的每个组织中都存在着信息安全风险。但它们还不是企业所面临的唯一与技术相关的风险。

作为一种技术风险管理方法，我对控制合规性的主要关注点在于风险计算阶段，在此阶段，无效或缺失的控制都会被自动归类为风险。简单来说：没有或者无效控制=风险。在我看来，这是完全不准确的，给利益相关者提供了一个虚假的故事，而且是有问题的，因为资源被投入到了“风险”之中，而这些资源本可以更好地被用于其他地方，以降低公司的风险。

风险管理

如果一个技术部门的运营风险的计算方法与公司其他部门的没有什么不同，会有什么影响?在英国，金融机构通过使用风险和控制自我评估(RCSA)来计算操作风险，如新巴塞尔协议所概述的。RCSA授权主题专家(SME)可自行定义其领域内所存在的风险，考虑为减轻已定义风险而实施的控制措施的运行有效性，然后评估这些控制措施对总体剩余风险的影响。这与控制合规性方法的不同之处在于，在定义剩余风险之前，要首先考虑风险，然后再考虑相关控制的运营有效性。

控制合规阵营担心，RCSA方法中的自定义风险可能会造成风险知识方面的差距，因为风险不是预先定义的，而是源自行业控制框架。还有一个相反的论点：由中小企业定义并由高质量技术风险经理所支持的风险可能与公司和技术部门最相关。

根据我的经验，RCSA方法提供了一个坚实的框架来挑战风险以及相关的红/黄/绿状态。RCSA的灵活性为其他风险管理活动(如风险事件、问题管理和审计结果)提供了基础，并确保了能够实现稳健的风险管理。其结果是，基于这种鼓励的谈话类型，可以对技术部门内部的实际风险有更深入的了解。

对我来说，在IT中使用组织的运营风险管理框架的最大好处之一是它是用业务术语编写的。最重要的是，技术风险的表达方式与公司内的其他部门相同。这有助于董事会和其他主要利益相关方更好地理解他们面前的技术相关信息。这可以推动董事会对关键技术计划的支持和认可。

相比之下，向董事会提交一系列低水平、无效的控制措施并将其归类为风险，与潜在的负面业务影响相去甚远。打个比方：说X位置的10台机器没有打

（编辑：葫芦岛站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!