考虑一个有几率发生的情况：一个团队正在疯狂地工作，试图在截止日期前达成目标，他们却得知组织的外部审计人员正在对他们的团队进行审计。该团队领导被要求提供一份材料清单。其中有些很容易收集，但大部分项目需要几个小时才能完成。因此，团队面临的选择是加班或错过冲刺承诺。更令人沮丧的是，该团队在几周前接受了组织内部审计部门的审计。而在这更早的几周前，IT风险团队进行了控制评估，并要求提供相同的材料清单。该团队只想完成工作，却被这些要求牵着鼻子走。

  为了有效评估组织的控制环境，IT审计和风险在很大程度上依赖于人工输出的材料。这些材料的形式可能是配置截图或从系统中导出的用户列表。但很多时候，这些要求是重叠的，全年多次要求相同的东西会给企业业务造成不必要的负担。为减少重复工作，让业务做自己最擅长的事情，第三道防线（内部审计）和第二道防线（风险）必须通力合作，协同工作。

  有专门的书籍、课程甚至学位来探讨组织文化，但文化的重要性怎么强调都不为过。安全绝不应被视为（照着检查表）打勾，审计也不应成为人类恐惧的东西。整个企业的员工在开始职业生涯时就一定要了解安全和审计团队的重要性，而不是在风险评估或审计前一周才了解它们。风险有助于业务部门做出明智的决策，审计则能发现阻碍业务发展的组织流程和标准之间的差距。而支持性的组织架构则有助于影响对合作协同文化的接受。

  有无数种组织架构可以轻松又有效支持风险和审计工作。选择哪种组织架构取决于组织规模和成熟度等因素。规模较大、成熟度较高的组织有专门的风险和审计职能部门。规模较小的组织可能会将IT风险置于IT或安全等其他职能部门之下，以避免重复工作并简化安全实践。然而，无论风险置于何处，审计都一定要保持独立，不应在会影响审计结果的部门（如IT审计中的IT部门）之下进行报告。因此，在风险和审计属于同一职能领域的组织中，例如规模较小的组织，应制定报告制度，以防止任何可能会影响审计结果的利益冲突或偏见。

  为进一步加强风险与审计之间的伙伴关系，应尽可能多地采用工作见习和作业交换的方式。风险分析师应进行客串审计。审计人员应协助评估风险和控制措施。这对审计人员来说是提升技术知识的绝佳机会，对风险分析人员来说是学习更多控制评估知识的绝佳机会。这也是各部门发现这两个领域之间的差距和重叠的机会。

  审计和风险部门必须定期向组织的其他部门推销他们的服务。如果在做出重大决策时，审计和风险部门能够去参加了，那么组织就会发现从一开始就以安全思维实施解决方案会更容易。这能够尽可能的防止在现有解决方案上贴上安全创可贴，而这通常会导致采用效率极低的人工流程，仅仅是为满足法律和监督管理要求。营销不一定要大张旗鼓，只要用心就好。小规模、频繁的互动，如午餐学习或定期接触，可以让风险和审计话题成为人类的首要关注点，以此来降低人们的恐惧感。

  审计以遵循检查表和运行脚本而闻名，考虑到审计人员一定审查的技术范围之广，这是能够理解的。然而，尽管检查表和脚本是重要的工具，但如果审计人员过度依赖它们，再加上对所审计的控制措施缺乏了解，就会导致不必要的审计结果，甚至阻碍审计结果的产生。因此，一个T型团队对于成功和有一定的影响力的审计至关重要。

  T型审计团队拥有广泛的基础审计和技术知识，由各具专长的审计人员组成。有些人对分布式操作系统和数据库平台了如指掌。其他人则对云控制有很强的把握。每位审计师应具备的深厚知识取决于团队规模。团队规模越大，审计师就越有机会进一步探索少数特定技术。他们可能有一名亚马逊网络服务（AWS）审计师和另一名对Azure有深入了解的审计师。较小团队中的知识分布往往更广泛。例如，一名审计师可能熟悉传统技术，而另一名审计师则擅长审查云控制。

  为支持T型审计团队，审计管理层必须对团队每位成员的技能、认证和学位进行清点；定期审查该清单；并鼓励通过会议、网络研讨会和认证考试报销等方式来进行持续教育。这也有助于外部审计师和监督管理的机构了解审计师的资历。

  除正规教育外，审计师还需要实践技术经验，以应用他们在认证计划中学到的概念。这能够最终靠让审计师参与构建他们在执行审计时使用的工具和脚本来实现。这也是在企业内部建立关联的一个机会，因为这些工具在大多数情况下要主题专家的帮助。这些机会不仅有助于培养审计师的技能和关联，还能提高所执行测试的质量，防止错误的审计结果导致不正确的脚本输出。

  IT风险和IT审计有许多相似之处。然而，一个关键的区别是IT审计必须从始至终保持独立。其工具和脚本不应被用作第一道或第二道控制线，因为这可能会引起隐藏最终的原因，并导致审计负责审计自己的流程。因此，审计应尽可能依靠风险测试。不过，要使这一方法取得成功，风险必须知道怎么正确测试控制的有效性，并以可靠的方式记录下来。

  风险团队必熟悉主体生成信息（IPE：information provided by the entity）和公司使用信息（IUC：information used by the company，译者注：IUC此处或应为information used by a relevant control）概念，以确保其工作的可靠性。IPE可让审计人员确信材料是如何生成的。而IUC则向控制所有者保证材料是如何生成的。例如，数据所有者每月都要对其负责的数据所在系统的所有访问权限进行审核检查。系统管理员向数据所有者提供导出的全用户访问日志，以供审查。在执行审查之前，数据所有者必须准确了解列表是如何提取的。否则，有极大几率会出现被忽视的漏洞，例如系统管理员认为数据所有者并不关心系统ID，而过滤掉了所有这些ID。如果不提供这种IUC，数据所有者就永远都不可能发现控制中的这种巨大漏洞。

  在同样的情况下，IT审计要求系统管理员提供同样的内容--系统生成的全用户列表。如果系统管理员不提供IPE，审计人员就无法确信报告的完整性和准确性。无论谁将收到报告，系统管理员都必须要提供来源、数据、报告逻辑和报告参数，以确保报告的可靠性：

  源数据---指提取数据的来源，即记录系统。在示例中，这就是存放列表的服务器。如果数据来自数据库，则指数据库的名称

  报告逻辑---指如何提取数据并将其转换为所提供的材料中。在示例中，这可能是从活动目录导出到Excel。实质上，报告数据显示了数据如何从格式A转换到格式B。

  报告参数---指应用的任何筛选条件。同样，根据示例，这可能是按照每个用户类型USER过滤。这样做才能够确保数据的完整性。

  为了让审计团队依赖风险团队用于测试的材料，必须要提供IPE/IUC。否则，审计将不得已重新测试一切，以确保数据的准确性和完整性。

  为了促进跨团队合作，风险团队和审计团队必统一工具。使用一个共享平台做审计和风险评估，能让两个团队充分的利用彼此的工作成果，并为风险和审计领导层提供综合指标，以说明整体情况。例如，应用程序A在最近的控制评估中显示出很强的控制能力，但却未能通过审计。这些发现表明需要对风险和审计计划、评分方法和流程进行审查。

  共享工具还允许在共享记录中存储材料。例如，要查看最近对应用程序B进行的第三方审查中是否发布了系统和组织控制（SOC）报告，IT审计团队只需检查应用程序记录的文档库，并调出审查所需的任何材料即可。共享材料时，必须适当配置访问权限。诸如系统配置等可以在两个小组之间共享。但是，审计访谈记录等项目必须保密。选择平台时一定要考虑账户管理。

  虽然使用同一平台来存储风险评估、控制评估和审计工作底稿是理想的做法，但这并非是必须的。在不使用共享平台的情况下，团队之间还有别的合作方式。系统之间能够正常的使用应用程序接口（API），这可以从报告的角度提供帮助。审计可通过风险评估输出的数据，确定整个企业中风险最高的应用程序。这有助于审计范围规划。另一方面，IT风险能确定哪些控制系列已经过审计，并注意其相应的有效性水平。这表明企业存在安全漏洞，有必要进行风险评估。

  在使用不同工具时，一定要考虑交叉培训和访问问题。可以对审计人员进行IT风险系统的培训，并允许他们访问该系统，以调取作为控制评估的一部分已经请求和存储的材料。这样做可以有效的预防审计人员要求业务部门提供在控制评估期间已经提供的材料。同样，必须对访问管理进行安全配置。例如，审计人能在审计期间内访问风险的治理、风险与合规（GRC）平台，但只能访问特定记录（甚至可能是字段）。

  这种合作伙伴关系的一个实例可能是这样的：审计部门正在对人力资源部门进行IT审计。为帮助确定审计范围，团队使用了一个与存储风险评估的数据源直接相连的仪表板，并按最高重要性对系统和供应商进行分类。这一些数据为审计工作提供了一种客观的方法，可根据对组织最关键的第三方和系统来确定审计范围的优先次序。此外，审计团队还可以与业务部门核实这份清单，看看是否有遗漏，而不是要求业务部门从头开始编制一份清单。

  在对审计进行适当的规划和沟通后，团队就能开始执行审计了。审计工作的一部分包括审查托管了任何范围内的应用程序的第三方。IT风险部门已经对每个供应商进行了第三方风险和控制评估，而不是由审计人员要求业务部门联系其第三方联系人以获得SOC或类似报告的证明。所有材料都存储在正在使用的GRC平台中。审计人员被授予临时访问权限（或永久审计人员角色），以查看第三方审查的结果。审计人员只需查看风险团队已执行的评估，并记录其发现。

  每个应用程序中被审计的另一个部分是用户账户管理。被分配到应用程序A的审计人员登录风险团队存储其评估的GRC工具，并调出最近对应用程序A执行的控制评估。所审查的控制之一涉及用户权限。执行审查后，风险分析师将对该控制措施的分析详细记录在案，并包含业务用户更好的提供的每个材料的IPE。同样，审计人员对之前执行的评估进行审核并记录在案，无需因材料请求而打扰业务部门的用户。当然，及时性在这里也很重要。原始审核应与审计在同一财政年度内完成。如果这项工作将被外部审计人员利用，那么内部审计人员就必须与外部审计人员合作，明白他们的信任期望和要求。

  人力资源审计最终完成。今年晚些时候，IT风险对营销部门进行了风险评估。其中一个受审查的应用程序已由内部审计部门审查过，因此风险团队要求提供与范围内应用程序审计相关的审计报告。风险团队注意到，内部审计已根据审计报告评估了三个典型的控制措施，未曾发现任意的毛病。现在，风险团队可以将这些控制措施标记为有效，从而避免向应用程序所有者发送相同材料的重复请求。

  这些例子说明了共享输入、输出和处理的理想概念。审计小组将风险的输出（风险评估）作为范围内活动的输入。同样，风险小组将审计报告（输出）用于控制保证（处理）。

  当审计团队和风险团队步调一致时，他们就能更有效地评估组织的安全状况，而无需不断干扰业务。保持同步需要的不仅仅是每月与团队召开一次会议。这需要坚持不懈的努力。归根结底，IT审计和IT风险在保护组织方面负有不同的责任，但它们的总体目标都是确保组织的安全。

  编者注：本文出自ISACA Journal 2023年第5期。尾注略。文章的主要内容仅代表作者本人观点。