在管理和降低技术风险方面，IT团队传统上总是依赖侧重于信息安全的运营、控制和合规性方法。与此同时，该业务的其余部分可能已经采用了更广泛的、以业务为中心的风险管理框架。这种脱节有时会抑制IT领导者向业务利益相关者有效表达技术风险的能力，从而影响投资决策。
为了有效地管理IT风险，这两种方法都有其应用空间，因为每种方法都有其好处。
控制合规性
控制合规性方法的一个主要好处是增加了对技术产业中存在的低水平控制缺陷的理解和认识。正如我们从各行各业的各种成功的后门进入所看到的，它往往是一个未修补的系统或是一个小的配置错误，使得黑客能够进入。因此，对当前控制缺陷的深入了解可以提高检测到可导致后门攻击的小型可利用漏洞的概率。
此外，通过对控制措施进行更常规化的评估(例如，基于ISO27001的评估)，可以减少遗漏细节的范围。通过使用行业最佳实践框架来评估控制，至少可以放心地知道所评估的控制是保护某些安全域所广泛需要的控制。此外，对于经验不足的风险管理人员来说，这种方法也提供了一个安全的工作基础，并提供了一定程度的指导，至少在安全领域是这样。
我已经看到了这些类型的行业所公认的信息安全框架被用作技术风险框架的基础，但这又给我提出了一个问题：如何识别不属于安全领域的控制，更重要的是，如何识别相关的业务风险?根据我的经验，一个严格的以控制为重点的评估可能会错过企业的真正风险敞口。即使是一个非常明确的路径也不能提供一种能够识别新的和正在出现的风险的方法，因为这些风险是预先确定的。
在我工作过的每个组织中都存在着信息安全风险。但它们还不是企业所面临的唯一与技术相关的风险。
作为一种技术风险管理方法，我对控制合规性的主要关注点在于风险计算阶段，在此阶段，无效或缺失的控制都会被自动归类为风险。简单来说：没有或者无效控制=风险。在我看来，这是完全不准确的，给利益相关者提供了一个虚假的故事，而且是有问题的，因为资源被投入到了“风险”之中，而这些资源本可以更好地被用于其他地方，以降低公司的风险。
风险管理
如果一个技术部门的运营风险的计算方法与公司其他部门的没有什么不同，会有什么影响?在英国，金融机构通过使用风险和控制自我评估(RCSA)来计算操作风险，如新巴塞尔协议所概述的。RCSA授权主题专家(SME)可自行定义其领域内所存在的风险，考虑为减轻已定义风险而实施的控制措施的运行有效性，然后评估这些控制措施对总体剩余风险的影响。这与控制合规性方法的不同之处在于，在定义剩余风险之前，要首先考虑风险，然后再考虑相关控制的运营有效性。
控制合规阵营担心，RCSA方法中的自定义风险可能会造成风险知识方面的差距，因为风险不是预先定义的，而是源自行业控制框架。还有一个相反的论点：由中小企业定义并由高质量技术风险经理所支持的风险可能与公司和技术部门最相关。
根据我的经验，RCSA方法提供了一个坚实的框架来挑战风险以及相关的红/黄/绿状态。RCSA的灵活性为其他风险管理活动(如风险事件、问题管理和审计结果)提供了基础，并确保了能够实现稳健的风险管理。其结果是，基于这种鼓励的谈话类型，可以对技术部门内部的实际风险有更深入的了解。
对我来说，在IT中使用组织的运营风险管理框架的最大好处之一是它是用业务术语编写的。最重要的是，技术风险的表达方式与公司内的其他部门相同。这有助于董事会和其他主要利益相关方更好地理解他们面前的技术相关信息。这可以推动董事会对关键技术计划的支持和认可。
相比之下，向董事会提交一系列低水平、无效的控制措施并将其归类为风险，与潜在的负面业务影响相去甚远。打个比方：说X位置的10台机器没有打补丁，与说恶意软件风险的增加可能导致业务中断是两码事。后者对关心公司福利的人来说更有意义。
混合方法：使用两种方法来加强整体结果
与大多数论点一样，双方都有自己的正确观点。这就是为什么我认为技术风险经理应该坚持风险管理，信息安全治理经理应该坚持信息安全控制的应用和治理的原因所在。
确保遵守业界所认可的信息安全框架对任何组织来说都有很大的价值。而信息安全团队对此负有责任。安全团队的控制合规工作应确定风险领域，并将其纳入RCSA的总体文件中，以告知信息安全的相关风险和现有控制的运行有效性。当在这种情况下概述信息安全风险时，任何所需的补救工作都是在程序级别上完成的，而不是以逐个控制的方式零碎完成的。未经授权的访问风险超出了容忍范围?那就让我们启动一个身份和访问管理程序来有效地解决风险。
信息安全只是IT中可能面临风险的一个领域。与管理IT部门相关的财务风险如何?无效变革的风险又如何?
当信息安全治理经理正在运行一个强大的计划来确保在信息安全中能够适当地应用控制时，技术风险经理却坐在整个技术部门，然后问这样一个问题：“这对业务来说意味着什么?”RCSA有助于使用与公司其他人相同的语言来表达IT风险，确保所有高层都能够理解。
