ISO27001：2013业务连续性管理制度

1、业务连续性管理制度1.目的和范围目录.3.2.引用文件3.3.职责和权限.3.4.业务连续性管理流程.4.4.1.1识别组织关键业务.4.4.1.2 识别关键信息系统.5.4.2连续性架构规划5.4.2.1确定团队与人员.5.4.2.2确定利益相关方.6.4.2.3确定技术设施 6.4.3 制定应急预案6.4.3.1 确定团队职责与分工.6.4.3.2确定突发事件通告机制.6.4.3.3确定损害评估机制.6.4.3.4确定灾难启动机制.7.4.3.5确定系统恢复过程.7.4.3.6形成计划文档7.4.4演练与维护7.XXXXXX软件有限公司人性化科技提升业绩第1页共9页内部公开【业务连续性管理

2、制度】F4-B-研发服务体系-008-V1.14.4.1设计演练方案4.4.2演练4.4.3评审和改进.7.错误!未定义书签5 相关记录第9页共9页内部公开1. 目的和范围为确保公司的业务能够持续稳定的进行，最低限度的降低信息安全事件对业务的影响， 特制订本管理制度。业务连续性管理为关键业务过程提供支持。2. 引用文件1）下列文件中的条款通过本规定的引用而成为本规定的条款。凡是注日期的引用文件， 其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓 励各部门研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新 版本适用于本标准。2）GB/T 22080-2016

3、/ISO/IEC 27001:2013信息技术-安全技术-信息安全管理体系要求3）GB/T 22081-2016/ISO/IEC 27002:2013信息技术-安全技术-信息安全管理实施细则4）信息安全事件管理制度3. 职责和权限1）信息安全管理领导小组：审批业务连续性计划，分配相关资源，确保业务持续性活动 顺利进行；在发生重大信息安全事件或灾难时担任公司业务中断的恢复的总指挥与 总协调。2）信息安全工作小组：负责组织进行相关业务连续性计划（ BCP）编写，审核BCP，组 织BCP演练，监督修改完善；在发生重大信息安全事件或灾难时，负责协调进行信 息和资产保护，及时恢复中断的业务。3）各相关部

4、门：配合信息安全工作小组执行 BCP的编写与演练；在发生重大信息安全 事件或灾难时，负责保护本部门的信息和资产，及时恢复中断的业务。4.业务连续性管理流程为方便理解业务连续性管理过程，将采用分级的方式进行表述。业务连续性管理概要过程主要从整体上描述，不会体现具体的细节和涵盖所有的人员。1）制定业务连续性框架通过对一系列应对方式（包括资源获取方式）的策略评估，确定业务连续性框架， 为每一服务选择了合适的响应方式，使得组织可以在中断发生中或发生后能够按预定 的条件持续提供服务。2）制定应急预案开发具体的服务连续性应对措施，建立事故管理和业务连续性、业务恢复计划的 管理框架，以详细描述在事故发生中或

5、发生后维持和恢复运行的步骤。3）演练与维护通过业务连续性的演练、维护和评审使得组织保证服务连续性策略和计划完成、更新和准确的程度。4.1.1识别组织关键业务在开发业务应急预案之前，应对以下方面对组织进行分析：1）识别组织的目标、利益相关方的义务、法定责任和组织运行的环境；2）识别活动、资产和资源，包括组织以外支持组织产品和服务交付的活动、资产和资源;3）活动、资产和资源的失效随时间推移的影响和后果。4.1.2识别关键信息系统那些信息系统的崩溃将在最短的时间内带来重大影响，并需要快速恢复的系统，可被视 为“关键信息系统”。 组织应识别为关键业务提供支持的关键信息系统和（或）支持服务 4.2连续性

6、架构规划组织应该对信息系统的连续性的架构进行规划和设计，在进行规划和设计时需要考虑的 方面包括，1）人员；2）基础设施；3）技术设施；4）信息和数据；5）其他供给；6）利益相关方。4.2.1确定团队与人员组织应确定识别管理参与服务连续性管理和恢复所需的核心技能和知识的合适方式，以及相关参与的人员。能力和知识是指各种技术资源，包括技术人员、文档等，使得参与的团队和人员能够透 彻地了解组织的业务情况和信息系统情况，深刻地把握单位灾难恢复系统的状态，并具有各 种相关的技术能力，经历了多次灾难恢复演练，能在灾难发生时，迅速解决各种问题以确保 单位关键业务系统的持续运行。组织应根据灾难恢复目标，确定灾难

7、备份中心在软件、硬件 和网络等方面的技术支持要求，包括技术支持的组织架构、各类技术支持人员的数量和素质4.2.2确定利益相关方组织应确定参与服务连续性管理和恢复的相关利益方、业务或服务合作伙伴及承包方的 关系，以及联络方式和所分担的职责。4.2.3确定技术设施备用技术设施是指当灾难发生时，确保业务持续运行所需的技术设施（包括网络、应用 系统等）。对可能影响网络可用性的线路及设备有冗余；对于恢复所需的软、硬件设备以及 与外部的通讯方式和线路等，应提前确定获取的标的和相应的处理脚本。4.3制定应急预案组织应将灾难一旦发生，所应执行的活动，形成文件，制定应急预案。4.3.1确定团队职责与分工描述灾难

8、恢复的组织结构，各个岗位的职责和人员名单，灾难恢复组织应包括应急响应 组，灾难恢复组等。并列出灾难恢复相关人员和组织的联络表，包括灾难恢复团队，运营商、 厂商、经理部门、媒体、员工、家属等，联络方式包括固定电话、移动电话、对讲机、电子 邮件和住址等。4.3.2确定突发事件通告机制任何人员在发现信息系统相关突发灾难发生或即将发生时，应按预定的过程报告相关人员，并由相关人员进行初步判断，通知和处理。4.3.3确定损害评估机制在突发事件发生后，由灾难恢复责任人召集相应的专业人员对突发事件进行慎重评估，确认突发事件对信息系统造成的影响， 确定下一步将要采取的行动，一旦系统的影响被确定, 应将最新信息按

9、照预定的通告过程通知给相应的团队。4.3.4确定灾难启动机制应预先制定灾难恢复预案启动的条件，当损害评估的结果达到一项或多项启动条件时， 组织将正式发出灾难启动，宣布启动灾难恢复预案，并根据宣告过程通知各有关部门。4.3.5确定系统恢复过程各系统的应急预案中描述时间、地点、人员、设备和系统恢复每一步的详细操作步骤， 同时还包括特定情况发生时各团队之间进行协调的指令，以及异常处理过程。4.3.6形成计划文档将上述计划中的内容形成服务应急预案，并提交信息安全管理委员会及相关各方人员进 行评审。4.4演练与维护4.4.1设计演练方案演练应该是实际的、经过周密的计划，并获得利益相关方的认可，以使演练过

10、程中业务 中断的风险最小。演练应经过计划，以使得因演练直接导致事故的风险最小。每次演练都应 清晰定义目的和目标。演练的方式可能包括：桌面演练、模拟演练和真实演练。4.4.2演练除非经过演练并实施维持，否则组织的业务连续性和事故管理安排不能认为是可靠的。 演练核心是开发团队合作、能力、信心和知识，这在发生事故时是非常重要的。演练的计划 可以在项目计划时进行确定。4.4.3评审和改进演练后的简报和分析应考虑目的和目标的达成。在演练结束以后以及在系统本身或外界 环境发生重大变化时，应对服务连续性方案进行评审和维护。当公司的业务环境发生重大变化时，也应重新评估应急预案的有效性。5. 相关记录无本制度相关修改及解释权属于研发服务体系文档编号（由总经办填写）F4-B-研发服务体系-008-V1.1密级内部公开文档发布级别公司