《变更管理规定.docx》由会员分享，可在线阅读，更多相关《变更管理规定.docx（4页珍藏版）》请在第壹文秘上搜索。
1、变更管理规定文件编号：1目的对信息处理设施和系统的变更缺乏控制是系统故障或安全失误的常见原因，为规范本公司信息系统的变更，降低因信息系统变更带来的风险，特制定本制度。2引用文件1）下列文件中的条款通过本规定的引用而成为本规定的条款。凡是注日期的引用文件，其随后所有的修改单（不包括勘误的内容）或修订版均不适用于本标准，然而，鼓励各部门研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于本标准。2） GB/T22080-2016/IS0/IEC27001:2013信息技术-安全技术信息安全管理体系要求3） GB/T22081-2016/ISO/IEC27002:2013信息技
2、术-安全技术-信息安全管理实施细则1.2 和权限系统服务部：负责各产品线的变更管理。各研发部：负责对变更进行策划。4变更步骤管理4.1 变更分类以下情况属于变更范畴,需按此变更管理规定处理。当信息系统需要产生变更时,应先分析其变更原因，信息类变更主要有以下几个方面：a）IT设备的维修、升级或更换。b）操作系统的补丁升级或更换。c）应用系统的升级或更换（包括紧急更新）。d）数据库变更。e）配置信息变更（包括组织角色）。f）架构更新。4.2 提交变更申请1）业务部门提交各产品线的变更申请表。XXX信息安全有限公司2）在明确变更原因和必要的变更影响评价后，各研发或业务部负责对变更进行策划,提出变更意
3、见，以及变更的具体实施方案计划，交由各研发或业务部负责人审核。3）变更不成功的恢复措施，所有的变更，包括IT系统的变更、操作系统软件、应用程序软件和程序库的升级、补丁或更新等，在制订变更计划时，就需要将失败恢复措施作为必要措施写入计划，并经各研发或业务部领导与各应用部门论证通过。4.3 变更的测试1）变更测试是对回退计划、变更实施计划和变更预期进行测试。变更测试应在独立的测试系统上进行。不可再正式环境中进行测试2）对于重要设备和重要信息系统的重大变更要首先进行测试，避免变更带来的风险。4.4 变更的批准1）各研发或业务部负责人对提交的变更计划进行审核，如涉及到其他部门，则转发相关部门共同审议，
4、达成共同意见后，批准变更计划。2）如需要召开变更协调会议，各研发或业务部要保留相关会议记录。3）系统服务人员经各研发或业务部负责人授权后实施变更具体操作。4.5 变更的实施1）变更实施前，各研发或业务部负责将变更的信息传达到所有相关用户。变更应按批准的计划和程序进行。2）要由经过培训的系统服务人员，根据授权来执行操作系统软件、应用程序软件和程序库的升级、补丁或更新。3）操作系统软件、应用程序软件和程序库的升级、补丁或更新前，应进行数据备份，包括数据、程序和具体配置。4）在变更实施时，需要时刻注意对应用系统造成的影响，如影响超出可控范围，需停止变更，并将系统恢复到变更前的状态。4.6 变更验收1
5、）变更实施后，由各研发或业务部和各应用部门及用户对变更的影响作出测试或评估，确保对业务连续性和安全没有不利影响。2）系统服务人员对变更进行评估，评估内容包括： 变更是否达到预期的目标 用户是否满意变更的结果 变更是否带来未预期的副作用 变更的费用和工作量是否超过预期 ）如果变更成功，则变更结束。如果变更失败，则重新开始。系统服务人员可根据情况，建议执行回退计划然后重新申请变更。因为继续在失败的系统中变更常常会引起更多的问题。 ）变更不成功的恢复措施： 根据同退计划，取消所做更改，如从备份资料中获得原始软件资料，重新运行，恢复原始状态； 根据更改操作记录，查找更改失败原因，以便再次做更改操作时避
6、免同样的错误发生。5）变更后备份要求： 当更改完成后，需将此次所运行的系统、软件和数据进行备份，包括其相关资料，以便下次的再一次更改以及资料查询；如果此次更改涉及到一些资料文件，则这些资料文件也必须做相应的更改并存档。4.7软件包的变更1） 一般不更改软件包。如果确有必要进行更改，应取得供应商的许可和支持，提出更改的部门应在实施前进行风险评估，确定必须的控制措施，经各研发或业务部负责人及总负责人批准。2）软件包更改时，应保留原始软件，并在完全一样的复制软件上进行更改，更改实施前应得到各研发或业务部及总负责人的授权。5关于补丁变更的参考文件补丁管理规定6相关记录序号记录名称保管场所保存期限保存形式备注1变更申请表系统服务部三年纸质/电子也可通过工单系统提交变更申请本制度相关修改及解释权属于研发服务体系文档编号（由总裁办填写）密级内部公开文档发布级别公司级文档发布及实行范围全员制度试行日期（可选）制度执行日期文档起草人签字：文档修订人：签字：修订说明：备注：文档负责人：签字：文档审批研发服务体系签字：文档审批人签字：
