银行信息科技风险管理办法模版.docx

《银行信息科技风险管理办法模版.docx》由会员分享，可在线阅读，更多相关《银行信息科技风险管理办法模版.docx（9页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、银行信息科技风险管理办法 第一章 总则第一条 为建立和健全银行股份有限公司（以下简称“本行”）信息科技风险管理框架，根据中华人民共和国银行业监督管理法、中华人民共和国商业银行法、商业银行信息科技风险管理指引银行全面风险管理办法银行操作风险管理办法，制订本办法。第二条 本办法所称信息科技是指计算机、通信、微电子和软件工程等现代信息技术，在本行业务交易处理、经营管理和内部控制等方面的应用，并包括进行信息科技治理，建立完整的管理组织架构，制订完善的管理制度和流程。第三条 本办法所称信息科技风险，是指信息科技在本行运用过程中，由于自然因素、人为因素、技术漏洞和管理缺陷产生的操作、法律和声誉等风险。第四

2、条 信息科技风险管理的目标是通过建立有效的机制，实现对本行信息科技风险的识别、计量、监测和控制，促进本行安全、持续、稳健运行，推动业务创新，提高信息技术使用水平，增强核心竞争力和可持续发展能力。第二章 信息科技风险管理组织架构第五条 董事会是本行信息科技风险管理的领导部门，负责组织本办法的贯彻落实。第六条 本行的董事会履行以下信息科技管理职责：（一） 遵守并贯彻执行国家有关信息科技管理的法律、法规和技术标准，落实中国银行业监督管理委员会（以下简称银监会）相关监管要求。（二） 审查批准信息科技战略，确保其与本行的总体业务战略和重大策略相一致。评估信息科技部门与风险管理部门信息科技风险管理工作的总

3、体效果和效率。（三） 掌握主要的信息科技风险，确定可接受的风险级别，确保相关风险能够被识别、计量、监测和控制。（四） 规范职业道德行为和廉洁标准，增强内部文化建设，提高全体人员对信息科技风险管理重要性的认识。（五） 设立专门信息科技管理委员会，负责监督各项职责的落实，定期向董事会和高级管理层汇报信息科技战略规划的执行、信息科技预算和实际支出、信息科技的整体状况。（六） 在建立良好的公司治理的基础上进行信息科技治理，形成分工合理、职责明确、相互制衡、报告关系清晰的信息科技治理组织结构。加强信息科技专业队伍的建设，建立人才激励机制。（七） 确保审计部门进行独立有效的信息科技风险管理审计，对审计报告

4、进行确认并落实整改。（八） 每年审阅并向银监会及其派出机构报送信息科技风险管理的年度报告。（九） 确保信息科技风险管理工作所需资金。（十） 确保银行所有员工充分理解和遵守经其批准的信息科技风险管理制度和流程，并安排相关培训。（十一） 确保本行涉及客户信息、账务信息以及产品信息等的核心系统在中国境内独立运行，并保持最高的管理权限，符合银监会监管和实施现场检查的要求，防范跨境风险。（十二） 及时向银监会及其派出机构报告本行发生的重大信息科技事故或突发事件，按相关预案快速响应。（十三） 配合银监会及其派出机构做好信息科技风险监督检查工作，并按照监管意见进行整改。（十四） 履行信息科技风险管理其他相关

5、工作。第七条 本行信息科技部负责人直接向行长汇报，并参与决策。其主要职责包括：（一） 直接参与本银行与信息科技运用有关的业务发展决策。 （二） 确保信息科技战略，尤其是信息系统开发战略，符合本行的总体业务战略和信息科技风险管理策略。（三） 信息科技部承担本行的信息科技职责。确保其履行：信息科技预算和支出、信息科技策略、标准和流程、信息科技内部控制、专业化研发、信息科技项目发起和管理、信息系统和信息科技基础设施的运行、维护和升级、信息安全管理、灾难恢复计划、信息科技外包和信息系统退出等职责。（四） 确保信息科技风险管理的有效性，并使有关管理措施落实到相关的每一个内设机构和分支机构。（五） 组织专

6、业培训，提高人才队伍的专业技能。（六） 履行信息科技风险管理其他相关工作。第八条 信息技术部门对本部门内部管理职责进行明确的界定；各岗位的人员应具有相应的专业知识和技能，重要岗位应制定详细完整的工作手册并适时更新。第九条 本行风险管理部门负责协调制定有关信息科技风险管理策略，尤其是在涉及信息安全、业务连续性计划和合规性风险等方面，为业务部门和信息科技部门提供建议及相关合规性信息，实施持续信息科技风险评估，跟踪整改意见的落实，监控信息安全威胁和不合规事件的发生。风险管理部设置专门岗位负责信息科技风险管理工作，定期按照本部门的信息科技风险管理工作开展要求，开展相关工作，向部门负责人汇报。第十条 本

7、行在审计部门设立专门的信息科技风险审计岗位，负责信息科技审计制度和流程的实施，制订和执行信息科技审计计划，对信息科技整个生命周期和重大事件等进行审计。第三章 信息科技风险管理第十一条 本行制定了全面的信息科技风险管理策略，包括但不限于下述领域：（一） 信息分级与保护。（二） 信息系统开发、测试和维护。（三） 信息科技运行和维护。（四） 访问控制。（五） 物理安全。（六） 人员安全。（七） 业务连续性计划与应急处置。第十二条 本行依据信息科技风险管理策略和风险评估结果，实施全面的风险防范措施。防范措施包括：（一） 制定明确的信息科技风险管理制度、技术标准和操作规程等，定期进行更新和公示。（二）

8、确定潜在风险区域，并对这些区域进行详细和独立的监控，实现风险最小化。建立适当的控制框架，以便于检查和平衡风险；定义每个业务级别的控制内容，包括：1. 最高权限用户的审查。2. 控制对数据和系统的物理和逻辑访问。3. 访问授权以“必需知道”和“最小授权”为原则。4. 审批和授权。5. 验证和调节。第十三条 本行建立了持续的信息科技风险计量和监测机制，其中包括：（一） 建立信息科技项目实施前及实施后的评价机制。（二） 建立定期检查系统性能的程序和标准。（三） 建立信息科技服务投诉和事故处理的报告机制。（四） 建立内部审计、外部审计和监管发现问题的整改处理机制。（五） 安排供应商和业务部门对服务水平

9、协议的完成情况进行定期审查。（六） 定期评估新技术发展可能造成的影响和已使用软件面临的新威胁。（七） 定期进行运行环境下操作风险和管理控制的检查。（八） 定期进行信息科技外包项目的风险状况评价。 第四章 信息科技风险评估流程与方法第十四条 信息科技风险评估由本行风险管理部按照实际工作需要开展，每年至少一次。信息科技管理以及风险状况内部审计由本行审计部按照实际工作需要开展，每两年至少一次。本行可聘请外部机构开展对信息科技风险状况的外部审计。第十五条 本行信息科技风险评估遵循以下流程：（1）成立评估组织自评估工作主要以银行内部人员为主，而风险评估对人员的能力要求相对较高，因此应根据评估工作所要达到

10、的目标，从系统、网络、开发维护、机房维护、安全管理等方面选择骨干人员参与，明确工作任务和相关职责。（2）确定评估范围在进行风险评估前，要先明确定义系统的边界范围，避免不必要的工作，并提高风险分析的质量。界限说明要明确指出在为某个信息系统进行风险分析时，应该包括哪些内容。这些内容可能包括：信息资产（如：硬件、软件、信息）、人员 （如：员工、分包商、其他外部人员）、环境 （如：建筑、设施）、活动 （如：对设备的操作） 等。（3）系统特性分析在确定评估范围之后，要分析所涉及的信息系统的系统边界和敏感性。信息系统是由处于一定边界之内的一系列处理过程、通信、人员及存储资源等元素构成，风险评估必须验证信息

11、系统边界控制的有效性，并确定被评估系统、信息和数据的价值。价值可由系统和信息的敏感性来表示。所谓敏感性是指信息拥有者分配给信息的一种重要程度的度量，以标出该信息的保护需求，例如机密性、完整性、可用性、可核查性、可靠性和抗抵赖性。（4）信息资产的识别和价值估算信息资产是一个完整信息系统的组成部分，它被银行直接赋予了某种价值，因此需要对它进行保护。在信息资产识别时要注意信息系统中的资产不只是软件和硬件，还包括很多其他内容，如信息或数据、服务、资金（如在ATM中的钱款）、银行的形象等。在所确定的评估范围内的所有信息资产都必须予以识别。在进行信息资产识别和价值评估时，评估小组可制定标准，组织银行内部相

12、关人员参与。信息资产清单编制完成之后，参与人员要从信息资产的购买价值、损毁对银行和业务的影响等方面进行价值估算，以确定发生信息安全事件后可能造成的影响。（5）威胁分析威胁是指某个特定威胁源利用某个特定系统的脆弱性对系统造成损失的潜在能力。这种利用可能是偶然的，也可能是有意的。如果系统没有脆弱性，威胁源就无法对系统造成威胁。同样，即使系统具有脆弱性，如果没有威胁源，也不足以对系统造成威胁。某个威胁发生的可能性与系统存在的脆弱性、威胁源的强度和系统采取的控制措施有关。可重点从威胁源及其动机和行为等方面进行分析。威胁源：威胁源按照其性质一般可分为自然威胁、人为威胁和环境威胁三种。信息系统根据自身应用

13、的特点和地理位置可能会面对不同的威胁源。动机和行为：由于人具有各种各样的动机，拥有难以计算的资源，因此人也成为信息系统安全的最大威胁源。另外，还要对曾经遭遇过的攻击历史和以往的事故报告进行回顾，以便更全面地识别信息和信息系统的人为威胁源。（6）脆弱性分析本步骤的目标是制定系统中可能会被威胁源利用的脆弱性（缺陷或薄弱环节）的列表。 脆弱性或漏洞存在于管理、运行和技术三个方面。系统脆弱性往往需要与对应的威胁源相结合时才会对系统的安全造成危害。在评估过程中，可以从以下几个方面获得系统脆弱性信息：信息系统在以前经过的风险评估的文档；信息系统审计报告、系统异常报告、安全检查报告、系统测试和评价报告等；厂

14、商公布的脆弱性列表；软件安全分析。（7）控制措施分析要确定信息系统潜在威胁源利用系统脆弱性造成损失的可能性，必须考虑银行信息系统实施的控制情况。本步骤的目的是对信息系统实施的或计划实施的控制进行核查，以了解本行信息系统安全控制的强度和完备情况。安全措施包括对技术和非技术措施的运用。技术类措施是计算机硬件、软件或固件中的保护措施，例如访问控制机制、标识和鉴别机制等；非技术类措施包括管理和运行类措施，例如安全策略、操作流程、人员、物理和环境安全。评估时评估小组可制定安全要求核对表，有助于以一种有效且系统化的方式对安全措施进行分析。安全要求核对表可以用来验证安全是否与既有的法规和政策相一致。因此，在

15、本行的控制环境发生变化（例如安全策略、方法和要求发生变化）后，有必要对安全核对表进行更新，以确保其有效性。（8）可能性分析信息系统安全事件发生的可能性与威胁源的动机和能力、系统脆弱性的性质及信息系统实施控制的有效性有关。因此，可能性分析必须对这三个方面进行综合考虑。（9）影响分析本步骤的目的是确定某个威胁源或脆弱性产生的特定安全事件对信息系统造成影响的等级。为确定影响的等级，应该了解以下的必要信息：系统使命 （例如信息系统的处理过程）；系统和数据的关键性 （系统对单位的价值和重要性）；系统和数据的敏感性。某个安全事件对信息系统产生的影响可通过完整性损失、可用性损失和机密性损失等来确定，也可通过

16、收入的损失数目、修复系统的财务费用及修复系统所必须付出的时间和努力来计算。按照影响或危害的定义，级别的大小可分为高、中、低三级。（10）确定风险这一步骤的目的是评估信息系统的风险级别，可由以下方面来确定：威胁源在现有的控制措施下利用系统脆弱性的可能性；系统被攻击后产生的危害程度（影响）。威胁发生的可能性与威胁源的能力和动机、信息系统的脆弱性和系统已实施的控制措施有关，使用风险等级矩阵，可得出风险的等级。（11）控制措施建议风险评估的最终目的是提高本行信息系统的安全防范能力和降低信息系统的安全风险。在本步骤，评估小组将对系统需要采取的控制措施提出建设性的建议。在提出信息系统应采取的控制措施时，应

17、考虑以下因素：控制措施的有效性；控制措施的合法性；本行的安全策略；对系统运行的影响；安全性和可信性。（12）记录评估结果一旦安全风险评估全部结束，最终必须产生风险评估结果文档。结果文档不仅可作为此次风险评估的资料保存，也可为以后的安全风险评估提供参考和比较。结果文档应包括威胁源清单、系统脆弱性清单、已实施的控制措施清单、系统的风险等级和建议控制措施清单。另外，还应形成一份详细的安全风险评估报告。本行主管领导可根据风险评估报告了解安全现状，进行决策。第十六条 本行信息科技风险评估可采取访谈、实地考察、实际操作检验三种方式。访谈主要由评估小组对系统开发人员、运行维护人员以及系统使用人员进行的面对面

18、的谈话方式。访谈过程中要做好访谈内容的设计、访谈策略的确定，以期得到最真实的信息。实地考察主要是针对重大系统开发以及系统运行维护、管理工作开展的一种评估方法。实地考察重点了解系统开发、运行、维护的实际状况。实际操作体验是运用各种系统监测工具，对系统运行进行检测，评价系统性能的主要方法。第五章 信息安全第十七条 信息技术部根据信息安全级别，将网络划分为不同的逻辑安全域（以下简称为域）。对下列安全因素进行评估，并根据安全级别定义和评估结果实施有效的安全控制，如对每个域和整个网络进行物理或逻辑分区、实现网络内容过滤、逻辑访问控制、传输加密、网络监控、记录活动日志等。（一） 域内应用程序和用户组的重要

19、程度。（二） 各种通讯渠道进入域的访问点。（三） 域内配置的网络设备和应用程序使用的网络协议和端口。 （四） 性能要求或标准。（五） 域的性质，如生产域或测试域、内部域或外部域。（六） 不同域之间的连通性。（七） 域的可信程度。第十八条 信息技术部通过以下措施，确保所有计算机操作系统和系统软件的安全：（一） 制定每种类型操作系统的基本安全要求，确保所有系统满足基本安全要求。（二） 明确定义包括终端用户、系统开发人员、系统测试人员、计算机操作人员、系统管理员和用户管理员等不同用户组的访问权限。（三） 制定最高权限系统账户的审批、验证和监控流程，并确保最高权限用户的操作日志被记录和监察。（四） 要

20、求技术人员定期检查可用的安全补丁，并报告补丁管理状态。（五） 在系统日志中记录不成功的登录、重要系统文件的访问、对用户账户的修改等有关重要事项，手动或自动监控系统出现的任何异常事件，定期汇报监控情况。第十九条 信息技术部通过以下措施，确保所有信息系统的安全：（一） 明确定义终端用户和信息科技技术人员在信息系统安全中的角色和职责。（二） 针对信息系统的重要性和敏感程度，采取有效的身份验证方法。（三） 加强职责划分，对关键或敏感岗位进行双重控制。（四） 在关键的接合点进行输入验证或输出核对。（五） 采取安全的方式处理保密信息的输入和输出，防止信息泄露或被盗取、篡改。（六） 确保系统按预先定义的方式

21、处理例外情况，当系统被迫终止时向用户提供必要信息。（七） 以书面或电子格式保存审计痕迹。（八） 要求用户管理员监控和审查未成功的登录和用户账户的修改。第二十条 信息技术部制定相关策略和流程，管理所有生产系统的活动日志，以支持有效的审核、安全取证分析和预防欺诈。日志可以在软件的不同层次、不同的计算机和网络设备上完成，日志划分为两大类：（一） 交易日志。交易日志由应用软件和数据库管理系统产生，内容包括用户登录尝试、数据修改、错误信息等。交易日志应按照国家会计准则要求予以保存。（二） 系统日志。系统日志由操作系统、数据库管理系统、防火墙、入侵检测系统和路由器等生成，内容包括管理登录尝试、系统事件、网

22、络事件、错误信息等。系统日志保存期限按系统的风险等级确定，但不能少于一年。信息科技部保证交易日志和系统日志中包含足够的内容，以便完成有效的内部控制、解决系统故障和满足审计需要；应采取适当措施保证所有日志同步计时，并确保其完整性。在例外情况发生后应及时复查系统日志。交易日志或系统日志的复查频率和保存周期应由信息科技部门和有关业务部门共同决定，并报信息科技管理委员会批准。第二十一条 信息技术部采取加密技术，防范涉密信息在传输、处理、存储过程中出现泄露或被篡改的风险，并建立密码设备管理制度。第二十二条 本行配备切实有效的系统，确保所有终端用户设备的安全，并定期对所有设备进行安全检查，包括台式个人计算

23、机（PC）、便携式计算机、柜员终端、自动柜员机（ATM）、存折打印机、读卡器、销售终端（POS）。第二十三条 本行对所有员工进行必要的培训，使其充分掌握信息科技风险管理制度和流程，了解违反规定的后果，并对违反安全规定的行为采取零容忍办法。 第六章 信息系统开发、测试和维护第二十四条 本行采取适当的系统开发方法，控制信息系统的生命周期。典型的系统生命周期包括系统分析、设计、开发或外购、测试、试运行、部署、维护和退出。所采用的系统开发方法应符合信息科技项目的规模、性质和复杂度。第二十五条 信息技术部制定相关控制信息系统变更的制度和流程，确保系统的可靠性、完整性和可维护性。第二十六条 信息技术部负责

24、制定并落实相关制度、标准和流程，确保信息系统开发、测试、维护过程中数据的完整性、保密性和可用性。第二十七条 信息技术部负责建立并完善有效的问题管理流程，以确保全面地追踪、分析和解决信息系统问题，并对问题进行记录、分类和索引；如需供应商提供支持服务或技术援助，应向相关人员提供所需的合同和相关信息，并将过程记录在案；对完成紧急恢复起至关重要作用的任务和指令集，应有清晰的描述和说明，并通知相关人员。第二十八条 信息技术部负责制定相关制度和流程，控制系统升级过程。当设备达到预期使用寿命或性能不能满足业务需求，基础软件（操作系统、数据库管理系统、中间件）或应用软件必须升级时，应及时进行系统升级，并将该类

25、升级活动纳入信息科技项目，接受相关的管理和控制，包括用户验收测试。 第七章 信息科技运行第二十九条 相关部门应严格控制第三方人员（如服务供应商）进入安全区域，如确需进入应得到适当的批准，其活动也应受到监控；针对长期或临时聘用的技术人员和承包商，尤其是从事敏感性技术相关工作的人员，应制定严格的审查程序，包括身份验证和背景调查。第三十条 信息技术部负责将信息科技运行与系统开发和维护分离，确保信息科技部门内部的岗位制约；对数据中心的岗位和职责做出明确规定。第三十一条 信息技术部按照有关法律法规要求保存交易记录，采取必要的程序和技术，确保存档数据的完整性，满足安全保存和可恢复要求。第三十二条 信息技术

26、部制定详尽的信息科技运行操作说明。如在信息科技运行手册中说明计算机操作人员的任务、工作日程、执行步骤，以及生产与开发环境中数据、软件的现场及非现场备份流程和要求（即备份的频率、范围和保留周期）。第三十三条 信息技术部负责建立连续监控信息系统性能的相关程序，及时、完整地报告例外情况；该程序应提供预警功能，在例外情况对系统性能造成影响前对其进行识别和修正。第三十四条 信息技术部应及时进行维护和适当的系统升级，以确保与技术相关服务的连续可用性，并完整保存记录（包括疑似和实际的故障、预防性和补救性维护记录），以确保有效维护设备和设施。第三十五条 信息技术部负责制定有效的变更管理流程，以确保生产环境的完

27、整性和可靠性。包括紧急变更在内的所有变更都应记入日志，由信息科技部门和业务部门共同审核签字，并事先进行备份,以便必要时可以恢复原来的系统版本和数据文件。紧急变更成功后,应通过正常的验收测试和变更管理流程,采用恰当的修正以取代紧急变更。 第八章 业务连续性管理第三十六条 本行根据自身业务的性质、规模和复杂程度制定适当的业务连续性规划，以确保在出现无法预见的中断时，系统仍能持续运行并提供服务；定期对规划进行更新和演练，以保证其有效性。第三十七条 信息技术部负责采取系统恢复和双机热备处理等措施降低业务中断的可能性，并通过应急安排和保险等方式降低影响。第三十八条 信息技术部负责建立维持其运营连续性策略

28、的文档，并制定对策略的充分性和有效性进行检查和沟通的计划。第三十九条 本行的业务连续性计划和年度应急演练结果应由风险管理部确认。第九章外包第四十条 本行在签署外包协议或对外包协议进行重大变更前，应做好相关准备，其中包括：（一）分析外包是否适合本行的组织结构和报告路线、业务战略、总体风险控制，是否满足商业银行履行对外包服务商的监督义务。（二）考虑外包协议是否允许本行监测和控制与外包相关的操作风险。（三）充分审查、评估外包服务商的财务稳定性和专业经验，对外包服务商进行风险评估，考查其设施和能力是否足以承担相应的责任。（四）考虑外包协议变更前后实施的平稳过渡（包括终止合同可能发生的情况）。（五）关注

29、可能存在的集中风险，如多家商业银行共用同一外包服务商带来的潜在业务连续性风险。第四十一条本行在与外包服务商合同谈判过程中，应考虑的因素包括但不限于：（一）对外包服务商的报告要求和谈判必要条件。（二）银行业监管机构和内部审计、外部审计能执行足够的监督。（三）通过界定信息所有权、签署保密协议和采取技术防护措施保护客户信息和其他信息。（四）担保和损失赔偿是否充足。（五）外包服务商遵守本行有关信息科技风险制度和流程的意愿及相关措施。（六）外包服务商提供的业务连续性保障水平，以及提供相关专属资源的承诺。（七）第三方供应商出现问题时，保证软件持续可用的相关措施。（八）变更外包协议的流程，以及本行或外包服务

30、商选择变更或终止外包协议的条件，例如：1.本行或外包服务商的所有权或控制权发生变化。2.本行或外包服务商的业务经营发生重大变化。3.外包服务商提供的服务不充分，造成本行不能履行监督义务。第四十二条本行在实施双方关系管理，以及起草服务水平协议时，应考虑的因素包括但不限于：（一）提出定性和定量的绩效指标，评估外包服务商为商业银行及其相关客户提供服务的充分性。（二）通过服务水平报告、定期自我评估、内部或外部独立审计进行绩效考核。（三）针对绩效不达标的情况调整流程，采取整改措施。第四十三条本行应加强信息科技相关外包管理工作，确保本行的客户资料等敏感信息的安全，包括但不限于采取以下措施：（一） 实现本银

31、行客户资料与外包服务商其他客户资料的有效隔离。（二） 按照“必需知道”和“最小授权”原则对外包服务商相关人员授权。（三） 要求外包服务商保证其相关人员遵守保密规定。（四） 应将涉及本银行客户资料的外包作为重要外包，并告知相关客户。（五） 严格控制外包服务商再次对外转包，采取足够措施确保商业银行相关信息的安全。（六） 确保在中止外包协议时收回或销毁外包服务商保存的所有客户资料。第四十四条本行应建立恰当的应急措施，应对外包服务商在服务中可能出现的重大缺失。尤其需要考虑外包服务商的重大资源损失，重大财务损失和重要人员的变动，以及外包协议的意外终止。第四十五条本行所有信息科技外包合同应由风险管理部门和

32、信息技术管理委员会审核通过。本应设立流程定期审阅和修订服务水平协议。第十章 审计第四十六条 本行审计部门应根据业务的性质、规模和复杂程度，对相关系统及其控制的适当性和有效性进行监测。内部审计部门应配备足够的资源和具有专业能力的信息科技审计人员，独立于本行的日常活动，具有适当的授权访问本行的记录。第四十七条 本行内部信息科技审计的责任包括：（一） 制定、实施和调整审计计划，检查和评估本行信息科技系统和内控机制的充分性和有效性。（二） 按照第（一）款规定完成审计工作，在此基础上提出整改意见。（三） 检查整改意见是否得到落实。（四） 执行信息科技专项审计。信息科技专项审计，是指对信息科技安全事故进行

33、的调查、分析和评估，或审计部门根据风险评估结果对认为必要的特殊事项进行的审计。第六十五条 审计部应根据业务性质、规模和复杂程度，信息科技应用情况，以及信息科技风险评估结果，决定信息科技内部审计范围和频率。但至少应每三年进行一次全面审计。第四十八条 本行在进行大规模系统开发时，应要求风险管理部门和审计部门参与，保证系统开发符合本行信息科技风险管理标准。第四十九条本行可以在符合法律、法规和监管要求的情况下，委托具备相应资质的外部审计机构进行信息科技外部审计。在委托审计过程中，本行应确保外部审计机构能够对本银行的硬件、软件、文档和数据进行检查，以发现信息科技存在的风险，国家法律、法规及监管部门规章、规范性文件规定的重要商业、技术保密信息除外。第十一章 附 则第五十条 本办法由银行股份有限公司负责解释和修订。第五十一条 本办法自发布之日起生效。