职责分离（SoD）是维护高效、安全的内部控制环境的基石。这一概念指的是在员工之间划分职责，以防止利益冲突、不当访问和欺诈。然而，当职责分离应用于复杂的系统领域时，则需要更加细致入微的考量。

尽管职责分离在企业环境中普遍存在，但它并非总能有效地应用于支持业务流程的系统的开发和维护。许多组织在构建和有意识地应用职责分离时面临诸多障碍，原因在于IT部门、用户需求以及风险/控制专业人员之间存在沟通不畅。

幸运的是，整合开发团队和运营团队的工作有助于创建符合业务需求的功能性控制措施。通过营造与信息完整性和安全性相一致的控制环境，可以实现更好的风险治理。

系统背景下的职责分离

职责分离旨在降低因关键活动集中于一人之手而产生的风险。具体而言，这意味着不应由一人负责涉及授权、执行、注册和控制等流程的所有阶段。遵循职责分离原则能够加强控制环境，从而降低欺诈、错误和运营故障的发生率。

然而，随着组织流程逐渐自动化，职责分离的应用需要重新评估。执行任务的不再仅仅是员工，系统扮演着越来越重要的角色，系统功能决定着流程在实践中的运作方式。

因此，职责分离需要置于系统逻辑的框架下进行考量。这包括理解谁拥有哪些资源的访问权限、他们持有哪些权限以及授予这些访问权限的背景。

职责分离最相关的挑战之一在于识别关键的系统功能，这些功能如果由一人负责，就会造成不可接受的风险。一个组织发生了典型的控制失效（职责分离缺失）案例，一名负责协调和管理外包人员的员工发现，招聘和解雇流程完全由他一人掌控，无需其他部门的验证。此外，工资支付也不受定期审计。他利用这些漏洞，创建虚假员工信息，并将其与他有权访问的银行账户关联。这名员工在长达八年的时间里，每月存取工资，中饱私囊，却无人察觉。这个案例说明了职责分离的缺失会如何严重损害流程的完整性，并助长长期欺诈行为。报告发布后，该企业开始核对考勤记录与财务报表。

在系统功能开发或修改过程中，风险往往容易被忽视，尤其是在技术团队与组织风险文化融合度较低的情况下。为了避免出现类似上述案例中的情况，开发人员不仅要扮演技术执行者的角色，更要扮演关键角色。他们必须能够就运营和完整性风险向需求方提出质疑，尤其是在建议的功能允许单个用户执行本应按角色或部门划分的操作时。缺乏此类前期分析可能导致实施的解决方案虽然在功能上有效，但却削弱了内部控制，使组织面临系统性漏洞的风险。

ISACA的COBIT框架也支持这一点，该框架强调必须从技术解决方案的设计之初就融入控制措施，并由业务和治理部门直接参与。ISO/IEC 27002:2022 标准同样强调了应用职责分离作为预防措施的必要性，以防止不当访问、欺诈和信息完整性遭到破坏。

企业环境中的实际障碍

尽管职责分离作为内部控制支柱的概念已被广泛接受，但在实践中，组织面临着诸多障碍，这些障碍往往更多地源于文化和结构性因素，而非技术层面。这些障碍与企业系统（曾经）的设计、开发、修改和维护方式密切相关。

主要障碍之一是系统开发团队缺乏对内部控制原则和运营风险逻辑的理解。在许多情况下，这些专业人员只关注实现企业要求的技术功能，而忽略了与负责治理和控制的部门进行沟通。这导致最终的解决方案虽然技术上可行，却给系统环境带来了不可接受的风险。

即使系统运行完全正常，风险和合规团队缺乏验证也可能导致采用缺乏足够控制措施的解决方案，从而无法防止安全漏洞或滥用。⁴这些因素可能导致造成重大经济损失的事件，包括监管罚款和机构信任的丧失。

资产管理不善是治理薄弱的另一个典型表现。过时的设备和软件，以及未列入库存清单或缺乏适当支持的物品，都容易受到威胁。如果没有成熟的控制流程，风险就会悄然累积，最终演变成重大事件。

另一个关键缺口是缺乏系统功能的结构化清单。创建包含链接及其对企业重要性级别的详细存储库被认为是最佳实践，并已被纳入COBIT等公认的框架中。然而，这种做法仍未得到广泛应用。如果没有这些文档，风险和控制专业人员将很难（甚至无法）有效地监控系统环境，从而导致频繁的返工，尤其是在风险映射和重要性归因方面。

此外，在功能开发或修改过程中，缺乏标准化且广泛采用的职责分离风险评估流程，会显著削弱内部控制。在这种情况下，根据系统架构，新功能可能将多个关键权限（例如创建、编辑和查看）集中在一个访问点中，而未区分风险等级。缺乏批判性视角，这种将访问权限集中于单一功能的做法会造成漏洞，容易引发利益冲突，并为错误和欺诈行为留下可乘之机。

例如在SAP环境中，可以对功能进行权限对象级别的风险分析，这反映了事务的结构方式。这种细致程度不仅可以识别跨访问配置文件的风险，还可以识别分配给单个功能的特定权限组合中的风险。

职责分离作为控制机制面临的另一个相关障碍是业务领域和技术领域之间缺乏整合。当组织的运营部门专注于解决瓶颈和自动化流程时，开发人员则致力于技术交付，而风险和控制专业人员则疲于应对已实施的变更。这种缺乏协同性阻碍了风险综合视图的构建，也妨碍了预防性控制措施的主动实施。

最后，由于系统访问管理中缺乏关于角色和职责的明确治理，导致难以在风险矩阵的构建中界定角色。根据 ISO/IEC 27001:2022 标准，职责分配对于确保控制措施得到有效实施、监控和审查至关重要。

尽管这些挑战错综复杂，但通过集体努力、高层领导的积极支持以及不断增强以风险管理为中心的文化韧性是可以克服的。构建成熟稳健的系统治理架构，需要将这些障碍视为战略重点并加以应对。而这可以通过制定和完善功能清单来实现。

构建功能清单

构建功能清单不仅是文档编写的最佳实践，也是一种战略性的治理和控制工具。它涉及记录支撑企业系统的所有功能，包括它们的描述、用途、责任范围以及创建或最后修改日期。该清单有助于：

• 风险映射与识别——通过了解特定功能的作用及其使用者，可以分析其滥用、操作失误甚至欺诈行为所带来的影响。这种方法与特雷德韦委员会发起组织委员会 (COSO) 的《企业风险管理——与战略和绩效的整合》相一致，该指南倡导识别运营活动中的风险并了解其系统性背景。基于此分析，可以根据交易的重要程度对其进行分类，这是定义职责分离、强化认证和双重审批等控制措施的基础步骤。COBIT强调了维护服务和技术资产目录的重要性，这一概念可以扩展到功能清单，以支持与安全性、合规性和运营连续性相关的决策。

• 应对审计和检查——根据ISO/IEC 27001标准，对信息资产进行文件化控制并明确责任归属是确保其得到保护。管理团队经常面临以下问题：谁可以更改银行账户信息？是否存在允许用户在同一笔交易中注册和授权付款的功能？此功能的创建目的是什么？如果没有完善的信息资产清单，这些问题会导致不必要的安全隐患、返工和风险。

• 保障系统维护——在动态的企业环境中，系统不断更新，新功能不断开发，流程不断优化。如果没有现有功能的技术和功能历史记录，任何修改都可能在无意中削弱内部控制。

• 面向开发人员的资源指南——该清单可作为开发人员的指南，帮助他们在提出或应用变更之前理解每个功能的背景。这一前提符合“安全设计”的理念，即从任何系统、软件或数字基础设施的构思阶段到其实施和持续维护，都应将安全性融入其中。ISO/IEC 27001标准也考虑到了这一点。

• 信息库的存在促进了企业技术、业务和治理部门之间的整合，增进了各方对风险和控制措施的相互理解，从而指导每一项系统性决策。此时，信息库不再仅仅是记录工具，而是成为组织风险文化的重要组成部分。

构建系统性风险矩阵

编制系统性风险矩阵对于确保技术环境以结构化的方式反映组织活动的固有风险至关重要。必须强调的是，根据COSO的指导原则，风险管理必须是综合性的、持续性的，既要考虑流程带来的风险，也要考虑自动化和系统权限带来的风险。为了使该矩阵有效，必须明确不同业务领域的参与情况，包括他们的观点、技术知识和职责。

01 内部控制与风险

内部控制与风险部门负责构建和维护风险矩阵，并协调与其他业务部门的工作。该团队的职责包括：

• 分析运营流程和访问权限，以识别潜在的利益冲突风险

• 建立功能性的关键标准

• 根据最佳实践（COSO、COBIT、ISO/IEC 27001）支持职责分离规则的制定

• 定期审查与员工访问权限相关的风险，并参与测试以验证已实施控制措施的有效性

02 信息安全

信息安全在风险管理中发挥着辅助作用，与企业、IT以及风险和控制部门协同工作，以确保访问治理，并使组织符合保密性、完整性和可用性 (CIA) 原则。此外，信息安全还：

• 支持制定基于风险的职责分离政策

• 根据风险和业务领域定义的矩阵，配置系统中的访问权限配置文件。

• 根据安全策略管理访问权限的配置、更改和禁用。

• 确保用户仅拥有其角色所需的最小访问权限

• 采用工具持续监控违反矩阵隔离和特权访问规则的行为。

03 IT与系统开发

IT/系统开发职能部门负责将控制和风险准则转化为技术解决方案。这可能涉及：

• 维护一份最新的功能清单，清晰地识别各项例程、它们可用的配置文件及其对流程的影响

• 协助风险管理团队识别关键功能

• 启用操作可追溯性（例如通过审计日志）

04 运营

运营部门及其各自的管理者通常是流程的所有者，因此也承担着相关风险。例如，如果物流团队负责管理产品交付，那么他们最熟悉从运输到交货期限的整个流程。这使他们能够通过实施风险缓解措施来管理过程中的成功和问题（例如延误、失败）。该领域的参与至关重要，原因在于：

• 描述流程的实际流转情况以及分配给每个角色的活动。

• 理解为系统流程开发的功能。

• 指出日常感知到的脆弱点和风险点。

• 验证风险矩阵并批准所提出的职责分离标准。

未能将这些领域有效整合，可能导致风险矩阵与实际操作脱节，从而降低其有效性。此外，协调一致的行动可以将风险矩阵从静态文件转变为与管理相融合的动态工具。协调一致的行动是制定功能开发和加强控制环境等决策的出发点。

克服障碍：通往协同之路

在系统性环境中构建稳健的风险文化是一个持续的过程，需要机构的承诺和参与。克服障碍不仅取决于员工对识别和降低风险的控制措施的认识，还取决于技术、运营和治理团队之间的有效整合。

01 IT团队的教育与文化融合

若干基础策略可以促进强大的风险文化建设。然而，开发团队与职责分离及系统访问原则之间可能存在知识差距。为了弥合这一差距，建议企业采取以下措施：

• 推广有关访问治理、信息安全和内部控制框架的专项培训。

• 鼓励IT代表参加风险委员会或控制论坛，以加深他们对自身工作成果影响的理解。

• 将风险验证作为开发流程中的必要步骤，包括简单的预防控制清单。

02 建立明确的治理结构和角色分工

创建风险导向型文化需要明确各个相关领域的职责。构建这种文化将涉及以下方面：

• 在风险和控制领域的参与下，规范访问审批流程和系统性变更。

• 在IT和运营部门内指定内部控制联络人，以便向其他团队成员推广和解释相关概念。

• 建立系统性的安全委员会或多学科论坛，定期召开会议分析相关风险。

03 持续沟通

职责分离冲突的产生往往是由于缺乏对积累关键权限所带来的风险的认识，尤其是在员工无法全面了解其在受监控的控制环境中的职责所带来的影响时。

确保各运营部门了解其运营需求中蕴含的系统性风险至关重要。许多风险因素源于关键权限的积累或绕过既定控制措施的例行操作。通过主动告知利益相关者，控制团队有助于培养共同责任和风险意识的文化。

与其采取限制性立场，不如提出既能满足业务需求又能保持治理标准的安全替代方案，这样更为有效。基于对话与协作的咨询方法，能够构建兼顾敏捷性和管控力的解决方案，从而增强信任并确保长期合规。

来自高层领导的支持

任何文化建设举措都离不开领导层的支持。当高管们强调控制的重要性并倡导韧性文化时，这清晰地表明了他们对机构优先事项的重视。领导层可以通过将风险管理纳入战略讨论和机构沟通，积极为构建强大的风险文化做出贡献。例如，执行董事可以在季度会议伊始强调风险管理的重要性，分享从以往事件中吸取的经验教训，并公开表彰那些采取了有效控制措施的团队。这种做法既展现了对风险管理的重视，又使风险管理在内部获得认可，还能激励其他部门效仿。

此外：

• 与系统环境相关的指标和风险指标必须定期向高级管理层报告。

• 改善访问治理和职责分离的项目必须纳入 IT 战略规划、风险缓解和控制措施中。

通过采取协商式方法提高风险意识并提供安全的替代方案，该组织加强了治理，并显著降低了运营失败和违规的风险。这些举措还有助于提升组织成熟度，促进业务和控制领域的协调一致，并倡导共同责任的文化。因此，流程变得更加敏捷和安全，决策也更加明智，更具长期可持续性。

克服构建系统风险文化的挑战，并非意味着限制或约束创新，而是确保创新以结构化、安全和可持续的方式进行。从系统设计之初就考虑控制措施，整个组织都将从中受益。

结论

组织面临诸多挑战，例如开发团队文化适应性不足，以及缺乏记录功能用途和重要性的清单。因此，风险、内部控制、IT、运营和信息系统等领域在构建稳健的风险矩阵方面开展协调行动的重要性怎么强调都不为过。这种协作，再加上高层领导作为战略支柱的参与，对于建立有效的治理和职责分离至关重要。

在系统层面推广稳健的风险文化，不仅仅是一项技术性举措，更是一项战略举措。它涉及转变思维模式，重新定位IT在控制结构中的角色，并确保每一项新实施的功能都具备与人工策略、标准或流程同等的严谨性。

在当今数字化世界中，系统不再仅仅提供运营支持，它们本身已成为流程的一部分。这就要求组织采取一种新的姿态：在风险萌芽阶段就识别并应对它。

作者Guimarães Nascimento是巴西一家保险公司的风险管理分析师。自2016年以来，她一直从事内部控制和运营风险领域的工作。此前，她曾在安永巴西分公司从事外部审计工作，积累了丰富的经验，工作时间为2008年至2012年。