【企业安全】安全架构(四)

news/2024/12/22 2:26:56/文章来源:https://www.cnblogs.com/o-O-oO/p/18621612

第一部分 安全架构第四章 内控合规管理4.1 概述4.1.1 合规、内控、风险管理的关系4.1.2 目标及领域4.1.3 落地方法4.2 信息科技风险管理4.2.1 原则4.2.2 组织架构和职责4.2.3 管理内容4.2.4 管理手段和流程4.2.5 报告机制4.2.6 信息科技风险监控指标4.3 监督检查4.4 制度管理4.5 业务连续性管理4.5.1 定义和标准4.5.2 监管要求4.5.3 BCM实施过程4.5.4 业务影响分析和风险评估4.5.5 BCP、演练和改进4.5.6 DRI组织及认证4.6 信息科技外包管理4.7 分支机构管理4.8 信息科技风险库示例4.9 小结

《企业安全建设指南金融行业安全架构与技术实践》——聂君李燕何扬军编著，资深信安专家十余年实战经验的结晶，安全领域多位专家联袂推荐。
本书系统化介绍金融行业中企业信息安全的架构与技术实践，总结了作者在金融行业多年的信息安全实践经验，致力于解决金融企业信息安全“最后一公里”问题，内容丰富，实践性强。

第一部分安全架构

第四章内控合规管理

金融行业的典型特征是，各项业务开展以及IT发展，必须遵守各项管理规定，合规是金融企业的底线和最低要求。为落实监管规定以及企业内部管理制度，金融业内部控制（简称“内控”）的要求相对其他行业高出不少。对于金融机构来说，IT内控合规是广义信息安全的一部分，而且是科技管理体系中很重要的一环。

4.1 概述

4.1.1 合规、内控、风险管理的关系

合规、内控、风险管理，是金融企业经常提到的三个关于合规建设的概念，这三者之间既有区别，又有关联。

合规管理是最基础的层面，合规管理的目标是避免违反内外部法律法规、规章制度、流程规范，避免因不合规导致的风险。
内控比合规管理更进一层，内控不但要求合规，还要审视“规”是不是完善，“规”有没有配备相应的执行点，执行“规”的过程是不是有效。
风险管理，特别是全面风险管理，是风险管控的最高形式。风险按标准划分为市场风险、信用风险、流动性风险、操作风险、法律风险。而合规、内控只是操作风险管理的手段。大部分金融企业会设置首席风险官，属于公司高级管理层。

虽然从一般意义上说，风险管理>内控>合规，但由于企业习惯将风险管理及其所包含的内控、合规活动统称为内控合规管理，而且本书探讨的是企业信息安全管理，故本书所称的内控合规，特指IT内控合规，即围绕信息科技风险管理的一系列管理活动。

4.1.2 目标及领域

金融企业IT内控合规管理的目标是，通过建立有效的机制，实现对金融企业IT风险的识别、计量、监测和控制，对外保障IT活动符合监管机构各项管理要求，对内确保各项管理要求的落地和控制措施有效，最终实现IT风险可控。

在具体实践中，IT内控合规管理的领域包括：信息科技风险管理、监督检查、制度和公文管理、业务连续性管理、信息科技外包管理、分支机构管理，以及其他一些工作。根据不同企业对IT内控合规的理解不同，管理的领域可能会有一些不同。

在很多金融企业中，IT内控合规管理的岗位给人的印象就是“写报告”，这种说法比较通俗易懂，但失之偏颇。

其一，写报告只是展现方式，报告中的内容，需要各种学习、对标、检查、督促等大量的积淀。所谓“巧妇难为无米之炊”，可以说，先要有对风险的深度掌控这个“米”，才能做出一份好报告的“炊”。

其二，要写好一份报告，不是简单的文字堆砌，而是需要能力、知识、技能和逻辑架构的功底，需要很多年持之以恒的积累和丰富的技巧。针对不同的对象要有不同的报告，针对不同的要求要有不同的报告，针对不同的时期也要有不同的报告。所谓“运用之妙，存乎一心”，要写得非常熟练、自然、流畅，要合乎阅读对象、形势、场景、时间的需要，需要多年的积累，方可挥洒自如。

4.1.3 落地方法

笔者从IT内控合规管理工作的经历中，总结出一套落地方法，可以用一个简单的口诀表示——外规对内规，内规对检查，检查对整改，整改对考核。

外规对内规。将外部规范要求分解成元要求，去重合并，和内部规范一一对应，每条元要求对应的结果为三者其一：1）满足要求；2）冲突；3）缺失。如果是2）、3）两种情况，要么修订内部规范，要么增加内部规范，以满足外规要求。通过识别，外部规范（指中国人民银行、银监会、公安部等监管机构发布的规章）分解成9大类、52个小类、1249条元要求，去重合并后形成外规内规对应关系。在外规对内规的梳理过程中发现了部分外规元要求没有内规承接和冲突的情况。
内规对检查。依据监管要求和外部标准梳理出内部规范后，建立一套适用的检查标准，并进行全面覆盖的检查，包括常规检查、专项检查和事件驱动检查。具体内容见4.3节“监督检查”。
检查对整改。建立一套电子化系统，实现检查计划制订、检查实施、报告管理、问题跟踪等全过程的电子化管理。检查发现和整改情况纳入问题管理流程。
整改对考核。将检查发现和整改情况纳入团队和个人当月和年度考核，实实在在地与个人收入挂钩，才可能引起重视，提高整改达成率。

较多的大型金融机构（如银行）均建立了外规条款数据库，并可以根据关键字进行快速检索查询，供内部使用，取得了不错的效果。

下文分别介绍IT内控合规管理的各个领域。

4.2 信息科技风险管理

银监会发布了《商业银行信息科技风险管理指引》，证监会（包括协会）发布了《证券期货经营机构信息技术治理工作指引（试行）》《证券期货经营机构信息技术治理工作指引（试行）》等，对信息科技风险管理提出了明确的管理要求。

注意

银行业“信息科技”的提法较多，证券基金期货“信息技术”的提法较多，本文未做严格区分。

4.2.1 原则

信息科技风险是指在运用信息科技过程中，由于自然因素、人为因素、技术漏洞或管理缺陷产生的操作、法律和声誉等风险。
信息科技管理的原则如下：

事前预防为主原则。在风险发生以前建立有效的风险管理措施，降低风险发生的可能性或减少风险可能造成的损失。
全面性原则。信息科技风险管理应覆盖到全行各部门、岗位、人员及操作环节中，使信息科技风险能够被识别、评估、计量、监测和控制。
成本效益原则。对风险管理措施的实施成本与风险可能造成的损失进行分析比较，选取成本效益最佳的风险控制方案。

对信息科技风险的管理需要根据董事会设定的风险偏好，在成本效益原则下，最大限度地完善信息科技风险管理体系，保障IT长期、稳定、健康的发展。

4.2.2 组织架构和职责

典型的信息科技风险管理组织架构示例如图4-1所示。

下面简单介绍金融机构信息科技风险防范三道防线。在一般商业银行中三道防线的概念比较多，其他证券保险基金期货用此概念较少，但实际部门组织架构和岗位职责的设置是类似的。

第一道防线：信息科技部门

主要关注日常的风险管理。

识别、分析与评估、控制、监测及报告风险管理情况。

信息技术部门各团队严格执行各项风险管理政策和要求，定期评估。·通常向首席信息官、信息科技管理委员会报告。

第二道防线：风险管理部门

侧重制定风险管理政策、制度、流程，在第一道防线的基础上对风险进行集中管理。
在总部层面设立风险职能部门，监督和协调整个风险管理框架的有效性和完整性，与前台部门保持相对独立。

对IT条线提供精细化的风险管理策略和支持。

与第一道防线保持一定的独立性，通常向首席风险官、风险管理委员会报告。

第三道防线：稽核审计部门

按期进行全面的或专项的审计或稽核。

与IT部门和风险管理部门保持独立，对风险管理框架、内控体系的完整性和有效性提供独立的审计和管理意见。

通常向董事会下设的审计管理委员会直接报告。

注意

一道防线和二道防线向经营管理层汇报和负责，而稽核审计部可以直接向董事会汇报和负责，保持独立性。

4.2.3 管理内容

信息科技风险管理可以从8个领域开展：

IT治理。IT治理的目标是，形成分工合理、职责明确、相互制衡、报告关系清晰的信息科技治理组织结构，为企业信息科技的发展提供战略方向和资源保障，并保证信息科技的战略与全行业务战略目标相一致。
信息安全。信息安全的目标是建立信息安全管理策略和技术措施，确保所有计算机操作系统和系统软件的安全，并进行必要的员工培训。这里所讲的信息安全，是指狭义的信息安全。
信息系统开发、测试和维护。信息科技部门应针对信息系统需求分析、规划、采购、开发、测试、部署、维护、升级和报废等各环节，建立管理制度和流程，管理信息科技项目的排序、立项、审批和控制，并持续监控重大信息科技项目的进展情况。
信息科技运行。信息科技部门应对人员职责分配、数据保存、操作方法、服务水平、变更、故障、性能及容量管理，建立制度和流程，并对信息科技突发事件建立应急处置预案，严格执行突发事件报告制度，落实突发事件的处置职责。安全保卫部门负责信息系统机房的物理环境安全管理。
业务连续性管理。金融企业和各相关机构应建立恢复服务和保证业务连续运行的管理机制和备用方案，并定期对其进行检查和测试，保证在业务运行中断时可以快速启动备用方案，降低业务中断带来的影响。信息科技部门负责信息系统灾难恢复方案的制订、实施和维护。
外包管理。信息科技部门负责管理信息科技相关的外包业务，制定与信息科技外包业务有关的管理政策，保证信息科技外包服务有协议、服务合同和监督机制的约束。
内部审计。审计部门应根据信息科技风险所涉及活动的性质、规模和复杂程度，信息科技应用情况，以及信息科技风险评估结果，决定信息科技审计范围和频率，对信息科技风险管理的适当性和有效性进行审计和评价，向董事会提供独立的信息科技风险审计意见。审计部应至少每三年进行一次全面的信息科技风险审计；在进行重大系统开发时，审计部门应参与其中，保证系统开发符合金融企业的信息科技风险管理要求。
外部审计。在符合法律、法规和监管要求的情况下，根据需要可以委托具备相应资质的外部审计机

构进行信息科技外部审计。在委托外部审计机构进行外部审计时，应与其签订保密协议，并督促其严格遵守法律法规，保守公司的商业秘密和信息科技风险信息。

4.2.4 管理手段和流程

信息科技风险管理，需要遵循一定的“套路”—有流程、有方法、有工具。

管理手段

信息科技风险隶属于操作风险，管理手段一般遵从第二道防线风险管理部门的管理手段。实际中，无论是银行还是证券，都会按照第二道防线下发的操作风险管理三大工具和要求开展工作。这里简单介绍一下操作风险管理的三大工具。

操作风险管理的三大工具，包括风险与控制自我评估（RiskControlSelf-Assessment，RCSA）、损失数据收集（LossDataCollection，LDC）和关键风险指标（keyriskindicators，KRI）。三大工具贯穿操作风险管理始终，为高效率、系统化的操作风险管理提供帮助。通常采取信息科技风险与控制自我评估、

设置信息科技关键风险指标、信息科技风险监控报表三种手段对信息科技风险进行管理。

RCSA，是识别和评估信息科技风险及风险控制措施有效性的管理手段。各相关部门应按照预先设定的工作方法，对其职责范围内的信息科技风险管理现状进行评估。信息科技风险与控制自我评估是信息科技风险管理持续改进的基础工作和关键环节。
LDC，是指依据监管规定、内部操作风险偏好与管理需求所定义的收集范围，针对操作风险事件的相关信息进行数据收集、内容分析、整改方案设计与执行、损失分配和内外部报告等程序。通过持续开展损失数据收集，一方面，可以动态反映企业操作风险损失的分布情况及发生诱因，为有效识别评估操作风险和强化管理提供线索和方向；另一方面，可以逐步建立操作风险损失数据库，为今后进行风险建模和计量积累数据，最终达到提高操作风险管理水平、降低风险损失的目的。
KRI，是反映信息科技风险水平的一系列统计指标，具有可量化的特点。关键风险指标用于监测可能造成重大信息科技风险事件的各项风险及控制措施，并作为反映风险变化情况的早期预警指标。通过对主要风险类型的早期预警并及时采取应对措施，避免重大信息科技风险事件的发生。

同时，通过信息科技风险监控报表，定期汇总分析，能够获取信息科技风险情况，并能掌握总体风险变化趋势。

管理流程

金融企业的信息科技风险管理流程包括信息科技风险识别、风险分析与评估、风险控制、风险监测及风险报告等五个环节。

风险识别。信息科技风险识别是指对企业具有脆弱性，可能受到威胁侵害，需要保护的信息资源或资产进行识别和分类，并对相关的威胁和脆弱性进行确认的过程。风险识别是风险管理的第一步，也是风险管理的基础。信息科技风险具有一定的可变性，风险识别是一项持续性和系统性的工作，应密切注意原有风险的变化，并随时发现新的风险。
风险分析与评估。信息科技风险分析是指对风险的可能性及其发生以后所造成的影响进行综合度量。信息科技风险评估单位应通过定性或定量的评估方法，判断风险的影响程度和发生可能性，确定风险的等级。
风险控制。信息科技风险控制指根据企业的风险偏好及风险评估的结果建立相应的风险管理措施。通过建立事前预防、事中监控及事后复核的风险管控手段，降低风险发生的可能性及其造成的影响，并根据公司的信息科技风险容忍程度采取规避、降低和转移风险的措施，将风险控制到公司可接受的水平之内。
风险监测。信息科技风险监测是指对信息科技风险进行定期或持续的检查，及时发现新出现的信息科技风险以及风险管理措施出现的问题，并采取相应的补救措施，以保证公司的信息科技风险在不断变化的内外部环境中，始终处于公司的风险容忍水平之内。应定期通过风险评估和审计等方式对风险的发展与变化情况进行持续监测，并根据需要对风险应对策略进行调整。
风险报告。信息科技风险报告指信息科技部门、风险管理部门和稽核审计部门，依据特定的格式和程序对信息科技风险状况进行描述、分析和评价，形成信息科技风险报告后，按照规定的报告路线进行汇报。报告的内容应完整、客观、清晰。

4.2.5 报告机制

为了使董事会、高级管理层和各级领导充分、及时地了解金融企业的风险状况，需要建立信息科技风险报告机制。
报告遵循以下原则：

逐级上报。
IT业务条线、风险管理条线、审计条线各自汇报。

各部门的汇报路径、汇报形式和汇报频率，如图4-2所示。

按照报告部门划分

信息科技部门、风险管理部门和审计部门分别按照以下汇报路径，向高级管理层和董事会报告全行信息科技风险状况和重大信息科技风险事件：

信息科技部门负责定期向高级管理层下设的信息科技管理委员会报告信息科技风险管理工作情况。
风险管理部门负责定期向高管层下设的风险管理委员会报告信息科技风险状况；同时，根据要求向董事会及下设的风险控制委员会报告。
审计部门负责定期向董事会下设的审计委员会报告信息科技审计情况。

按照报告频率划分

第一类是定期报告，三道防线部门按照不同频率和报告路线开展：

信息科技部门向主管IT的高级管理层成员汇报信息科技风险管理月报，向第二道防线、第三道防线汇报IT风险管理和IT内外部审计情况。其中信息科技风险管理月报主要是向主管科技的高级管理层成员（例如首席信息官）汇报周期内IT运行情况（事件、容量、交易量、业务连续性等）、研发情况（开发质量、）、信息安全（数据安全、人员管理、审计问题），以及其他事项。
风险管理部定期完成操作风险监测并向高级管理层报告，至少每季度向董事会及下设的风险控制委员会报告全面风险管理情况（包括信息科技风险）。
审计部每年向董事会下设的审计委员会报告信息科技审计情况。

第二类是触发式报告，由信息科技部在发生以下情况时主动报告：

发生重大信息科技风险事件。
信息科技环境发生重大变化。
监管机构要求时向高级管理层汇报。

此外，除了向高级管理层进行内部汇报外，还要按照监管要求向监管机构报送与信息科技风险有关的报告，也包括定期报告或触发式报告两种形式。

4.2.6 信息科技风险监控指标

信息科技风险管理在IT管理中日益重要。对于高级管理层来说，需要全面了解公司信息科技风险及风险管控情况，并能够在一定程度上对可能发生的风险事件进行预警。对于人民银行、银监会、保监会、证监会等监管机构来说，针对银行信息科技提出了一系列监管要求，需要及时发现合规问题和潜在风险，确保整体合规。为此我们设定了一系列监控指标，并进行持续地整合和完善，力求建立一套内容全面、标准统一、结构系统的信息科技风险监控指标体系。

在实际工作中，经常发现以下问题：

监管要求来源渠道多，容易遗漏。
不同渠道的部分监管要求重复。

针对这些问题，可以采取以下措施解决：

建立信息科技风险库。
建立信息科技风险监控指标体系。
运用监控指标体系。

建立信息科技风险库

为了全面、体系化地识别日常管理中需要的信息科技风险监控指标，首先需要建立一套完整的信息科技风险库。风险库来源应该全面覆盖行业监管合规要求、行业风险事件、行业标准、公司风险现状和相关专家知识库，保障风险库的完备性，如图4-3和图4-4所示。

基于“威胁×脆弱性=风险”的理论基础，可以从监管要求、行业和公司历史风险事件、业界最佳实践标准等着手，从自然环境因素、人员因素、技术因素和业务因素等方面的威胁，分析出在人员、流程和技术等领域的脆弱性，进而识别出信息科技风险点，形成信息科技风险库。

通过对人民银行、银监会等监管机构发布的监管要求和标准进行详细解读，逐条提炼出相对应的信息科技风险描述，同时将业界和企业内部历史上曾经发生的信息科技风险事件案例作为风险识别的一个重要输入，通过对监管机构发布的风险提示、披露的银行业信息科技风险事件和内部过往信息科技风险

事件的分析，提炼出各个风险案例中的风险点，并结合信息系统和技术控制目标(ControlObjectivesforInformationandrelatedTechnology,COBIT)、信息技术基础架构库(InformationTechnology InfrastructureLibrary,ITIL)、ISO27001(信息安全管理体系)、软件能力成熟度集成模型(Capability MaturityModelIntegration,CMMI)等国际标准和内部多年积累的风险知识库的内容，构建成信息科技风险库。

【图4-3】信息科技风险指标库来源

【图4-4】信息科技风险识别框架

建立信息科技风险监控指标体系

识别关键风险指标是指，基于前期建立的信息科技风险库中各个风险点，进行全面梳理和分析，在对所有风险点进行评估的基础上，分析确定各个风险点的驱动因素，并进行关键信息科技风险指标的识别。然后，根据重要性、系统性、合规性、代表性和可操作性等原则，对风险监控指标进行筛选。最后，在指标确定后，明确指标的含义和计算方法等关键属性，如图4-5所示。

【图4-5】信息科技风险关键指标识别方法

关键信息科技风险指标可以是客观的量化指标，如信息系统可用率，也可以是偏重定性的指标，如信息科技组织架构合理性等；可以是客观的，如灾备系统覆盖率，也可以是主观评价型的，如信息科技组织架构成熟度等。

监控指标体系的运用

监控指标体系主要运用在以下几个方面：

有效评估信息科技风险管理水平。
动态监测信息科技风险状况。
合理配置信息科技风险管理资源。
及时采取管理措施。

必要时通过专业数学建模方法论，可以构建信息科技风险预警模型和管理流程，预警风险并进行风险处置。

指标监测和报告

日常进行风险指标监测，并按月向二道防线和公司主管领导汇报监测情况，对于监测到的异常需要进行及时处置。

4.3 监督检查

首先，依据监管要求、外部标准和内部规范梳理出一套适用的检查标准，并进行全面覆盖的检查。通过识别，外部规范分解成9大类、52小类、1249条元要求，去重合并后形成外规内规对应关系，也就是信息科技风险检查标准库，如图4-6所示。

然后，制订全年检查计划，采用常规检查、专项检查、事件驱动检查相结合的方式，100%覆盖信息科技风险检查标准库。一个典型的监督检查运行图，如图4-7所示。

专项检查围绕信息科技风险领域，如外包管理、可用性管理、数据安全、业务连续性管理等。例如，某年共开展××项专项检查工作，提出改进完善建议×x×余个。

常规检查注重变更、发布、值班等日常运维重点模块，按周开展监督检查。例如，追踪变更发布近万个，追踪发现违规问题××个，同时提出风险规避建议×条。

【图4-6】信息科技风险检查标准库

【图4-7】监督检查运行图示例

事件驱动检查一般在可用性事件、信息安全事件或重大违规违纪事件发生后进行，对于检查中发现的问题全部纳入问题管理流程进行跟踪管理。而且，通过问题跟踪机制，可以同时归口管理第二、三道防线的检查发现，充分确保问题统一归口、管理追踪无遗漏，并使整改方案可实施、进度有跟踪、实施有成效，监督检查闭环流程如图4-8所示。

【图4-8】监督检查闭环管理流程

监督检查是确保风险管理政策、措施、流程落地的有效保障，检查方式、投入资源、结果运用根据实际情况灵活决定。

4.4 制度管理

无论企业属于什么行业、规模大小、发展快慢、战略方向如何，都需要一套科学合理的制度体系，保证制度的合规性、有效性、可操作性及规范性，才能更好地管理和约束员工，形成有序、良性发展。金融企业的IT部门也一样。

制度一般以条文形式展示，名称通常冠以政策、规定、办法、规程、细则、指引等；制度可以通过制度补丁的方式进行调整、补充和完善，制度补丁可以采取条文或非条文的形式展示，一般以修订通知、补充通知或加强管理通知等标题体现。

制度体系

制度体系应遵循架构合理、层级清晰、覆盖全面的原则，制度体系一般包括三级：

政策级制度，是指用于规范业务条线行使经营管理职责基本事项的制度，名称一般使用制度、规定、政策、章程等。
办法级制度，是指用于规范业务条线的工作方法和具体内容的制度，名称一般使用管理办法、管理规程等。
规程级制度，用于规范具体的作业内容，名称一般使用操作规程、操作细则、实施细则、指引等。

制度的起草

在起草制度过程中，应开展调查研究，广泛征求制度执行部门和人员、部门内部相关人员的意见，以论证制度的必要性、有效性、合理性和可操作性。紧密涉及其他部门职责或与其他部门关系的制度，主办部门应充分征求其意见。征求意见可采取发送征求意见函、召开制度会审会、签报以及发文会签等方式进行，其中发文会签为此类制度在发文阶段的必经程序。

制度内容一般应包括：总则（含目的依据、适用范围、管理原则、职责分工、定义等）、管理流程、监督检查及罚则（如有）、附则（含制定细则要求、解释部门、施行日期、作废声明等）。

制度的评审

制度评审主要包含以下内容：

是否符合法律、规则、准则和监管要求。
是否与本公司有关制度协调一致、接口清晰。
是否影响本公司制度整体架构的合理性和清晰性。·制度描述的流程是否清晰并具有可操作性。
是否符合本公司制度的规范性要求。
评审人员可以对其认为的其他制度问题（如制度实用性和适宜性等）提出评审意见。

制度的发布

经评审、审核或审议通过的制度以公文形式印发。为便于制度维护和管理，印发的制度原则上应一文号对应一项制度。主办部门应根据制度的印发时间，合理确定制度的施行日期，并在制度中明确。实际中，很多情况是“本文自发布之日起施行”，但不如确定日期更合适。

制度的维护

制度的维护包括制度的后续评估和制度改进。制度后续评估是指主办部门对制度实际管理效果进行的自我评估，旨在发现制度存在的问题，评估是否需要对制度进行改进。后续评估包括以下内容：

是否存在合规性、有效性、可操作性和规范性等制度问题。·制度间是否存在重复、冲突。
是否存在制度缺失和管理盲点。
对制度进行梳理，摸清制度补丁情况，评估实施整合的可行性和必要性。

对执行层面反映意见较多的制度，主办部门应及时进行后续评估。对于施行超过5年的制度，主办部门必须进行制度后续评估，并将评估结果报同级制度主管部门。

在日常工作中，总分支机构各部门应多方收集和整理制度信息，提高制度后续评估的效率和质量。制度信息包括：外部政策变化，总部制度的变化，制度解释解答，基层操作人员反馈的制度问题，业务检查发现的管理漏洞，外部或同业案件反映的管理漏洞和新风险，内部组织架构、管理和业务流程调整等。

制度改进是指根据制度后续评估结果和业务管理需要，主办部门实施的制度新增、换版、修订、补充以及整合工作。在实施制度改进工作前，主办部门要评估制度改进的成本，兼顾制度的稳定性和执行的方便性，选择印发制度补丁、增加新制度或换版等方式对制度实施改进。对于制度存在较多补丁的，相关部门要结合部门制度架构的安排，对制度实施整合。一般情况下，一项制度的补丁不应超过3个。

制度补丁主要有以下几种方式：

修订通知，是指针对具体制度条款实施调整的制度补丁，发文中应写明作废条款的内容以及对应替换条款的内容，一般情况下其发文标题拟为“关于修订《××公司×××》有关条款的通知”，并在文中注明解释部门和施行日期。如同时补充了相关内容，应对补充内容进行独立描述，并将发文标题拟为“关于《××公司×××》的修订补充通知”。
补充通知，是指针对具体制度进行整体补充的制度补丁，不对原制度条款实施改变，发文中主要描述补充的内容，一般情况下其发文标题拟为“关于《××公司×××》的补充通知”，并在文中注明解释部门和施行日期。如属对新增业务功能或管理内容的补充，也可采取条文的形式，一般情况下其发文标题拟为“关于印发《〈××公司×××〉新增×××的补充规定》的通知”。
加强管理通知，是指从某一类业务或管理出发提出的改进要求，对原有的一系列相关制度规定均实施改变的制度补丁，一般情况下其发文标题拟为“关于加强××管理的通知”，并在文中注明解释部门和施行日期。

为加强制度补丁的关联性和针对性，以便于制度查阅和学习的系统性，各部门在选择制度补丁方式时，应尽可能采用“修订通知”或“补充通知”的方式。如以“电邮部通”方式下发的通知涉及制度管理的，一般仅限于对制度进行强调或解释，不得用于对制度进行补充和修订。

制度的日常管理

制度应明确解释部门，原则上由制度主办部门负责解释，特殊情况下应明确各部门解释的范围。低层级制度与高层级制度规定相抵触时，以高层级制度规定为准，但制度解释部门另有正式批复或回复的除外。

4.5 业务连续性管理

4.5.1 定义和标准

业务连续性管理定义

英国标准协会（BritishStandardsInstitution，BSI）：业务连续性管理（BusinessContinuity Management，BCM）是一个整体性的管理流程，它主要识别威胁组织的潜在影响，并且提供构建组织弹性和有效响应的框架，以保护组织关键利益相关方的利益、声誉、品牌以及价值创造的活动。（BSI，BS25999，ISO22301的前身。）

中国银监会：商业银行为有效应对重要业务运营中断事件，建设应急响应、恢复机制和管理能力框架，保障重要业务持续运营的一整套管理过程，包括策略、组织架构、方法、标准和程序。（《商业银行业务连续性监管指引》银监发[2011]104号）

ISO22301

ISO22301为第一份直接以业务连续性管理（BusinessContinuityManagement，BCM）为主题的国际标准。该标准的性质为要求（Requirements），因此可用于审核与认证。除了ISO22301外，另有属于指引（Guidance）的ISO22313，ISO22313与ISO22301合为具有完整架构的业务连续性管理国际标准。

4.5.2 监管要求

银监会有关业务连续性管理要求

2007年《商业银行操作风险管理指引》中，业务连续性要求的重点为实现从系统到业务的提升。

2008年《银行业重要信息系统突发事件应急管理规范》中，明确了银行突发事件应对原则；日常管理以及应急管理组织架构；细化了危机事件预测预警和内外部上报流程。

2009年《商业银行信息科技风险管理指引》中，商业银行应制订全面的信息科技风险管理策略，包括业务连续性计划和应急处置。

2010年《商业银行数据中心监管指引》中，明确了数据中心的建设以及灾备中心的系统、数据建设目标，以满足业务连续性的需求。

2011年《商业银行业务连续性监管指引》中，从全行层面明确规定了业务连续性管理建设各阶段的要求，具有较强的规范性与可操作性。

2013年《商业银行资本管理办法》中，明确要求业务连续性管理实施是标准法计提操作风险资本的前提条件之一。

中国人民银行有关业务连续性管理要求

2002年《关于加强银行数据集中安全工作的指导意见》中，规范了银行网络可靠率、UPS供电时间、数据全备份频率、灾备中心建设、业务连续性计划和演练要求。

2006年《关于进一步加强银行业金融机构信息安全保障工作的指导意见》中，强调了银行需建立灾备中心，并定期进行灾备演练。

2007年《银行业信息系统灾备恢复管理流程》中，规范了信息系统应急响应和灾备恢复的具体要求，规范了灾备恢复组织架构，明确了各等级系统的恢复时间目标（Recovery-TimeObjective，RTO）和恢复时间点目标（RecoveryPointObjective，RPO）。

世界部分地区金融业监管机构发布的相关指引

部分国家及地区金融监管相关指引如表4-1所示。

【表4-1】部分地区金融监管相关指引

4.5.3 BCM实施过程

根据国际良好实践以及BCM的实施经验，将BCM的实施过程总结为以下几个关键步骤：

1）制度和组织建设。建立BCM管理制度，组建总分支机构BCM管理组织架构，明确各部门职责。

2）业务影响分析（BusinessImpactAnalysis，BIA）和风险评估（RiskAssessment，RA）。确定BCM的需求和管理策略，识别、分析、评价风险，确定防止、降低损失的控制措施。

3）资源建设、预案制订。为满足业务持续运营目标而开展的资源建设，根据RA的成果制订和完善预案。

4）演练、维护和评估。通过演练提高组织应急处置能力，验证资源可用性，评估BCM体系并持续改进。

5）BCM企业文化建设。贯穿BCM整个过程，提高全员意识，将BCM融入企业文化中。

4.5.4 业务影响分析和风险评估

1、术语定义

（1）重要业务

《商业银行业务连续性监管指引》（银监发〔2011〕104号）第三条规定重要业务是指面向客户、涉及账务处理、时效性要求较高的银行业务，其运营服务中断会对商业银行产生较大经济损失或声誉影响，或对公民、法人和其他组织的权益、社会秩序和公共利益、国家安全造成严重影响的业务。

支持重要业务运行的系统，相应地就称为重要系统。

（2）RTO和RPO

恢复时间目标（RecoveryTimeObjective，RTO）分业务RTO和系统RTO，指业务或系统从中断到恢复所需要的时间，是业务或系统恢复及时性的指标。恢复时间点目标（RecoveryPointObjective，RPO）分业务RPO和系统RPO，指业务或系统数据恢复到的时间点，是业务或系统恢复数据完整性的指标。

（3）BIA

业务影响分析（BusinessImpactAnalysis，BIA）是整个BCM流程建立的基础工作，在这一过程中，通常会利用定量和定性分析相结合的方法对业务中断可能导致的经济与运营损失进行科学的分析，从而制订重要业务的恢复优先级、恢复目标（RTO与RPO）以及重要信息系统的恢复优先级和恢复目标等，通过BIA确定业务连续性管理的策略。

BCM就是解决运营中断事件发生时需要用多少资源、多长时间、什么方式、恢复什么业务的问题，其中资源、时间、业务都是BIA的成果。

《商业银行业务连续性监管指引》（银监发〔2011〕104号）第二十三条规定，商业银行应当通过业务影响分析识别和评估业务运营中断所造成的影响和损失，明确业务连续性管理重点，根据业务重要程度实现差异化管理，确定各业务恢复优先顺序和恢复指标。商业银行应当至少每三年开展一次全面业务影响分析，并形成业务影响分析报告。

（4）风险评估

风险评估（RA）是进行风险识别、风险分析和风险评价的整个过程，基于BCM的风险评估，关注于可能对BIA所识别的重要业务造成中断的各类威胁发生的可能性和影响程度，并针对潜在的威胁和影响制订进一步的风险管控措施。RA是BCM开展的基础和主要需求来源之一。

《商业银行业务连续性监管指引》（银监发〔2011〕104号）第二十八条规定，“商业银行应当开展业务连续性风险评估，识别业务连续运营所需的关键资源，分析资源所面临的各类威胁以及资源自身的脆弱性，确定资源的风险敞口。关键资源应当包括关键信息系统及其运行环境，以及关键的人员、业务场地、业务办公设备、业务单据以及供应商等”。第二十九条规定，“商业银行应当根据风险敞口制订降低、缓释、转移等应对策略。依据防范或控制风险的可行性和残余风险的可接受程度，确定风险防范和控制的原则与措施”。

2、业务影响分析实施过程

业务影响分析实施过程包括重要业务和重要系统的识别，重要业务的影响分析过程及结果，重要系统的影响分析过程及结果，从而得出整个BIA成果，具体流程如图4-9所示。

恢复时间目标和恢复时间点目标（RTO和RPO）：

业务RTO，是指业务恢复所需要的必需时间，是业务恢复及时性的指标。对于公司来说，就是允许我们用多长时间恢复中断的重要业务。
业务RPO，是指业务恢复到的时间点，是业务恢复数据完整性的指标。对于公司来说，就是允许我们重要业务丢失多长时间的数据。

【图4-9】业务影响分析实施流程

国家标准《信息安全技术信息系统灾难恢复规范》(GB/T20988—2007)附录CRTO/RPO与灾难恢复能力等级的关系，如表4-2所示。

【表4-2】RTO/RPO与灾难恢复能力等级的关系

同时，通过收集和分析人民银行、银监会等监管机构发布的监管要求，得出银行业重要系统RTO和RPO的最低要求，其他金融企业可以参照执行，如表4-3所示。

【表4-3】RTO和RPO监管要求

3、风险评估

1)实施前内部方案讨论，确定RA的范围和实施方式。

参与范围：重要业务归属部门、数据中心、各一级分支机构(业务和IT)。
评估对象：重要业务、总部IT运营、分支机构业务运营整体、分支机构IT运营等。
实施方式：现场、非现场沟通和培训/问卷调研分析等。

2)RA调研问卷设计。根据业务和IT特点，结合评估对象差异性，有针对性地设计调研问卷和调研方式。

3)RA试点反馈，优化问卷。选择几家总部部门、分支机构作为RA工作的试点，根据试点情况反馈调整整体实施方案和优化调研问卷。

4)全面启动RA工作。确定方案和问卷后统一组织总部各部门、各分支机构开展RA工作。

5)分析整理，撰写报告。各分支机构根据各自RA结果，撰写分支机构RA报告；总部根据各部门反

馈撰写总部评估报告。再综合总部和分支机构RA报告完成企业RA报告。

RA注意事项如下：

BCM风险评估关注点。各类风险对于业务或IT系统运营的中断威胁，而非经济损失。
BCM评估问卷。问卷只是工具，问卷上评估对象、可能性和影响打分规则、影响类别、威胁、高中低风险划分，都可以根据机构实际情况、风险偏好等进行客户化调整。
BCM评估核心。核心在于针对评估的中、高级风险制订管控措施，不需大而全的措施，但要保障措施的可实施性，改进周期可自定，但不建议超一年，在下次RA时可分析措施的有效性。

4.5.5 BCP、演练和改进

1、术语定义

业务连续性计划（BusinessContinuityPlan，BCP），是一种策略规划，当灾难发生致使组织关键业务或服务中断时，BCP可以指导迅速恢复关键业务的正常与持续运作。BCP是组织在实施BCM过程中的产出物，并在BCM过程中不断更新和完善。银监会监管指引要求BCP主要内容应包括：重要业务及关联关系、业务恢复优先次序；重要业务运营所需关键资源；应急指挥和危机通讯程序；各类预案以及预案维护、管理要求；残余风险。

总体应急预案，是商业银行应对运营中断事件的总体方案，包括总体组织架构、各层级预案的定位和衔接关系，及对运营中断事件的预警、报告、分析、决策、处理、恢复等处置程序。总体预案通常用于处置导致大范围业务运营中断的事件。

重要业务专项应急预案，应当注重灾难场景的设计，明确在不同场景下的应急流程和措施。业务条线的专项应急预案，应当注重调动内部资源、采取业务应急手段尽快恢复业务，并和信息科技部门、保障部门的应急预案有效衔接。

2、内容

业务连续性计划的主要内容应当包括：

重要业务及关联关系、业务恢复优先次序。
重要业务运营所需关键资源。
应急指挥和危机通信程序。
各类预案以及预案维护、管理要求。
残余风险。

专项应急预案的主要内容应当包括：

应急组织架构及各部门、人员在预案中的角色、权限、职责分工。
信息传递路径和方式。
运营中断事件处置程序，包括预警、报告、决策、指挥、响应、回退等。·运营中断事件处置过程中的风险控制措施。
运营中断事件的危机处理机制。
运营中断事件的内部沟通机制和联系方式。·运营中断事件的外部沟通机制和联系方式。·应急完成后的还原机制。

3、演练

演练的目的如下：

检验应急预案的完整性、可操作性和有效性。
验证业务连续性资源的可用性。资源包括人员、IT系统、IT灾备中心、办公和业务场地、基础公共资源、指挥中心、办公及业务开展所需的其他资源等。
提高运营中断事件综合处置能力。
提高应急参与人员处置能力、熟悉处置流程、提高全员应急意识、提高应对信心。

监管要求包括：《商业银行业务连续性监管指引》（银监发〔2011〕104号）第五章规定，业务连续性计划演练中，对演练计划的制订、重要业务演练周期、演练时间点、演练重点（业务和IT配合、IT系统接管能力）、演练参与者（外部供应商要求）、外部机构演练、演练的记录、总结、评估、改进等都提出要求。

演练方式如下。

桌面演练（说）：

熟悉处置流程。
检查角色分工。
检查计划内容。
为实战演练准备。
场景简单。

实战演练（做）：

真实资源调配。
真实系统切换。
真实场地转移。
全方位检验应急处置的有效性。
场景复杂。

4、持续改进

持续改进包括以下工作内容：

每年需要针对业务连续性管理体系的完整性、合理性、有效性组织一次自评估，或者委托第三方机构进行评估，并向高管层提交评估报告。
每年需要针对业务连续性管理文档进行修订，修订内容包括重要业务调整、制度调整、岗位职责与人员调整等，确保文档的真实性、有效性。
开发新产品时，应同步考虑是否将其纳入业务连续性管理范畴。对纳入业务连续性管理的，应当在上线前制订业务连续性计划并实施演练。
在业务功能或关键资源发生重大变更时，应当及时对业务连续性相关文档进行修订。
每三年进行一次业务连续性管理的专项审计，在发生大范围业务运营中断事件后也要及时开展专项审计。

有部分企业采用了业务连续性管理系统（BCMS），进行业务连续性日常管理，也取得了不错的效果。

4.5.6 DRI组织及认证

国际灾难恢复协会（DRIInternational）

DRIInternational（DRII）成立于1988年。其使命是通过提供教育和帮助，以及发布标准的基础资源，来推广业务连续性规划和灾难恢复行业的通用知识体系；协助建立公共和私营机构之间的合作，来推广相关行业标准；通过对业务持续领域的专业人员进行认证，来提高获认证人员的可信度和专业技能。

有关DRIInternational的更多信息见：

http://www.drii.org

DRI中国技术委员会

DRI中国技术委员会（DRIChinaTechnicalCommittee，DRICTC）是DRIChina的核心机构，其宗旨是为DRIChina的发展提供组织建设、战略规划等方面的建议和决策支持，帮助DRIChina推进BCM、突发公共事件应急管理（EmergencyManagement，EM）以及IT信息系统灾难恢复（DisasterRecovery，DR）在中国的发展，建立和完善相关行业标准，解决应用实践中的问题，跟踪国内外BCM的发展趋势，促进BCM向科学化、专业化、规范化和国际化方向发展；协助DRIChina在中国培养更多符合国际标准的BCM人才；为国内外BCM专业人士、管理人员、政府主管部门、学术机构及厂商，搭建行业内外信息沟通与交流平台，促进相互合作，共同推进中国各行业BCM的应用和发展；提高中国政府和企业高层管理者对于防范及应对风险的认识和管理水平，增强其抵御灾难并持续发展的能力。

DRI中国技术委员会的性质是以政府、金融、保险、证券、电信、交通、能源等DR，EM，BCM的主管，以及该领域的专家、学者等自愿组成的学术性、公益性、非营利性组织。

有关DRI中国技术委员会的更多信息见：

http://www.drichina.org/

有关业务连续性管理的国际认证

有关业务连续性管理的国际认证，认可度较高的是DRIInternational组织维护的国际认证体系，一共有以下四种。

MBCP（MasterBusinessContinuityProfessional）—DRI国际认证的最高级别，专门用于在业务连续性/灾难恢复行业具有高级知识和技能的个人。该认证是针对具有至少五年行业经验的个人。
CBCP（CertifiedBusinessContinuityProfessional）—CBCP认证要求：1）在业务连续性/灾难恢复行业拥有丰富知识和工作经验的人员；2）该级别需要超过两年的经验；3）申请人必须能够在专业实践的五个主题领域中展示具体和实际的经验。
CFCP（CertifiedFunctionalContinuityProfessional）—CFCP认证级别，适用于在业务连续性/灾难恢复行业具有知识和工作经验的个人。该级别需要超过两年的经验。申请人必须能够在专业实践的三个主题领域中展示具体的实践经验。
ABCP（AssociateBusinessContinuityProfessional）—ABCP级别，适用于行业经验少于两年的个人，对业务连续性管理知识最少且已成功通过资格考试的人员。

中国申请较多的BCM国际认证证书是CBCP由DRII为需要获得DRII国际标准资格认证的人员而设计的课程。

4.6 信息科技外包管理

近年来，各金融机构处于业务快速发展时期，产品不断丰富，开发需求持续增长，对研发产能需求很大，合理利用外包可以一定程度上减小自身队伍快速膨胀带来的人力资源波动风险，有效利用市场资源。同时通过引入外部公司资源，获取IT服务提供商的先进经验，提升自身科技队伍的管理及创新水平。但与此同时带来了一系列外包管理风险。“工作可以外包，责任不能外包”，已成为监管层的明确要求。

有关外包管理详细内容见第7章外包安全管理。

4.7 分支机构管理

各金融机构基本都在全国各地分布着一些分支机构，比如银行和证券公司。分支机构的规模都比较大，有的分支机构还有一定规模的信息技术部门。分支机构的IT风险管理也是重要内容。

分支机构的管理内容包括：

合规管理。明确分支机构需遵守的IT制度，并进行全覆盖的检查，检查可以是远程与现场相结合的方式进行。合规检查情况纳入当年度分支机构考核。
事件管理和问题管理。分支机构发生可用性事件和安全事件时，进行事件调查和处理。相关改进措施纳入问题管理跟踪督促。
项目推广。每年总部会有一些重点工作，需要分支机构落实，放入项目推广工作中。
人才培养。建立分支机构IT人才的认证模型，进行专业培训和认证考试，科学评价各分支机构岗位人才胜任情况。

有效措施包括：

建立定期会议机制。比如季度分支机构IT工作例会，全体分支机构IT负责人和骨干参加。年度分支机构IT工作会议，通报各分支机构IT工作全年情况，表彰先进，督促后进。
建立分支机构评级机制。分支机构根据规模大小分成ABC三类，同一类之间进行科技评级，通过评级机制，将改进优化的一些非合规类要求给到分支机构，相比检查更有利于分支机构主动开展IT建设工作，评级注重的是未来持续发展能力。
开展分支机构检查并全覆盖，确保分支机构管理要求落地。检查可以采用现场检查和非现场检查相结合；计划内检查和飞行检查相结合；对标类检查和技术类检查相结合等方式。