ISO27001系统变更管理程序
- 格式:doc
- 大小:80.00 KB
- 文档页数:9
XXXXXXXXX有限责任公司可移动介质管理程序[XXXX-B-14]V1.0变更履历1 目的为了对可移动介质进行控制和物理上的保护,以防止信息遭受未授权泄露、修改、移动或销毁以及业务活动遭受干扰,特制定本程序。
2 范围本程序适用于信息可移动介质的管理。
3 职责3.1 技术部可移动介质的归口管理部门,负责所辖可移动介质管理,为其他部门的信息可移动介质处置提供技术支持。
3.2 可移动介质使用部门可移动介质处置由本部门负责管理。
4 相关文件《信息安全管理手册》5 程序5.1 总则可移动介质需要转移或销毁时,如果处理不当,很容易造成信息泄漏。
因此,必须按规定执行处置。
可移动介质是指U盘、移动硬盘、数码相机、光盘、磁带、软盘和打印的媒体等。
可移动介质使用部门应建立《可移动介质使用登记表》,对本部门使用的可移动介质进行登记管理。
可移动介质处置原则:按照正式的程序可靠、安全的处置,使敏感信息泄露给未经授权的人员的风险最小化。
5.2 可移动介质处置可移动介质的处置应该与信息的敏感程度相一致,可移动介质的敏感程度应考虑风险评估的结果。
可移动介质处置应考虑下列原则:a)所有的可移动介质都应由部门经理负责保管;b)可移动介质的处置前应该识别需要安全处置的项目;c)销毁方式一般分为一般格式化、低级格式化、专业软件重写、粉碎;d)对无敏感信息的可移动介质作一般格式化即可,在保证质量的基础上重新分配和使用;e)保存有敏感信息的可移动介质应当得到安全的存放和处置;对于含有敏感信息的可移动介质应采用低级格式化或专业软件重写,反复次数为三次,再进行粉碎;f)应对含有敏感信息的存储可移动介质的处置做出记录,以备审查;g)销毁的可移动介质在处理后保存三个月后再作处理。
处置措施可以是:a)移动硬盘:文件先做删除,高级格式化后,低级格式化。
报废的硬盘,需要粉碎报废。
循环使用的硬盘,低级格式化后,拷入大量数据,覆盖无用信息后,高级格式化,再使用。
文件制修订记录1、文档介绍1.1 编写目的采取有效的改进、纠正和预防措施,确保信息安全管理体系的持续改进。
1.2 适用范围适用于改进、纠正和预防措施的制定、实施和验证。
1.3 引用文件ISO/IEC 27001:20222、角色和职责·管理者代表负责监督、协调改进、纠正和预防措施的实施。
·管理运营部负责组织相关部门对体系出现的不合格采取纠正措施并验证实施的结果。
·管理运营部负责对持续改进的策划,对出现存在的或潜在不合格,采取相应的纠正和预防措施并验证实施的结果。
·各部门负责实施相应的改进、纠正和预防措施。
3、内容3.1 持续改进的策划公司通过内审、管理评审及相应的纠正和预防措施,建立自我完善的机制;纠正/预防措施信息来源有:A. 公司内外安全事件记录、事故报告、薄弱点报告;B. 日常管理检查及技术检查中指出的不符合;C. 网络运维的监控记录;D. 内、外部审核报告及管理评审报告中的不符合项;E. 相关方的建议或抱怨;F. 风险评估报告;G. 其他有价值的信息等。
3.2 纠正措施1) 对于存在的不合格应采取纠正措施,以消除不合格原因,防止不合格再发生,纠正措施应与问题的影响程度相适应;2) 不合格识别、原因分析、措施制订及实施验证:·对内审及管理评审发现的不合格,由责任部门根据《内审不符合项报告》的不合格事实分析原因,制订纠正措施并实施,管理运营部组织内审员跟踪验证实施结果。
·对管理过程出现的重大问题或不合格由管代组织责任部门填写《纠正和预防措施处理单》,分析原因、制订措施、实施改进并跟踪实施结果。
·对顾客投诉的不合格,填写《信息反馈单》转管理运营部确认,分析原因、制订纠正预防措施并将结果转给客服人员,由客服及时转告顾客,确保顾客满意。
3) 每项纠正措施完成后,监督部门进行跟踪验证,该部门负责人对实施效果的有效性进行评审,评审其能否防止类似不合格的继续发生。
ISO27001变更管理控制程序1 目的为减少由变更所造成的问题对核心系统及其它基础环境的影响,将由变更所可能导致的服务中断对业务的影响降至最低,特制订本程序。
2 范围本程序适用于IT基础架构、环境、系统、应用、人员等变更的管理。
3 相关文件4 职责4.1 变更需求部门人员负责提出变更请求,需求部门主管审批变更请求;4.2网管人员(服务台负责人)及接到用户变更请求的系统管理员负责变更过程的策划,并提交相关领导审批;4.3 信息科技部总经理负责重大变更的审批。
4.4 各系统负责人负责具体变更活动的实施。
5 程序5.1 变更的范围在本程序中对变更的定义为:可能影响到银行IT基础环境的一种物理或流程的改变,一般情况下,变更仅仅在必须的情况下才进行实施。
a)解决IT环境现有或未来存在的问题b)为满足业务需求提供新的或修改的功能本流程仅仅包括IT基础环境或与基础环境相连的系统,本变更管理流程也由此些内容组成:a)针对物理设备的变更(e.g. 服务器,客户端,网络布线,网络设备,硬盘,路由器等)b)针对通讯和协议方面的变更(e.g. IP地址,相关变量设置等)c)针对操作系统的变更,包括网络操作系统 (e.g. 安装,版本控制,系统设置等)d) 应用开发上线前的变更e) 任何由外部单位(如IBM )实施的可能会影响到银行IT 基础环境的变更必须严格按照变更管理流程来执行。
5.2 变更分类根据变更的重要性及变更的类别对变更进行分类。
a) 变更的重要性:与变更的紧急程度有关b) 变更的类别:与变更对成品环境带来的影响和风险有关5.2.1 变更的严重等级 严重等级说 明 普通变更根据需求日期和资源配置情况进行划分 重要变更从业务角度有较高的优先级,不通过普通变更的窗口来执行 紧急变更 多个流程或单一业务受到影响或部分核心系统受到影响5.2.2 变更类别变更的类别是由如下两个方面来判断:a) 影响: 变更对业务的影响 ,如服务的可用性b) 风险: 变更的技术复杂性下表显示了与这些参数相关的变更的分类: 影响 > 低 中 高风险 低 低 低 中中 低 中 高高 中 高高 影响评估IT 变更影响被划分成高,中,低3个类别,变更失败对业务产生的影响是衡量影响的关键因素:。
文件制修订记录1、概述1.1目的为确保公司信息安全管理体系持续的适宜性、充分性和有效性,评估公司信息安全管理体系改进和变更的需要,包括信息安全方针、目标,特制定本程序。
1.2.范围适用于对公司信息安全管理体系运行的现状和适应性进行管理评审的活动。
2、职责A、最高管理者主持管理评审活动;批准《管理评审计划》;批准《管理评审报告》。
B、管理者代表负责组织召开管理评审会议;负责管理评审计划的落实和组织协调工作;跟踪验证管理评审问题的处理;审查《管理评审计划》和《管理评审报告》。
C、体系策划、贯彻团队负责制定《管理评审计划》,收集管理评审所需文件和记录;评审过程的组织工作、作好评审会议记录并编写《管理评审报告》;负责组织完成管理评审输入资料准备;保存管理评审相关记录;D、评审团队依据评审计划对管理体系进行评审;E、各相关部门负责准备、提供与本部门工作有关的评审所需材料,并负责实施管理评审中提出的相关纠正、预防措施。
3、内容3.1审核频率公司每年进行一次年度管理评审(管理评审时间间隔不超过12个月),此外,在下列情况下,管理者代表可临时决定进行管理评审。
➢产品、流程、系统、组织机构、人员和资源等有重大调整;信息安全方针、目标等发生变化;➢当业务过程发生重大事故造成重大损失时;发生重大顾客抱怨或投诉;➢管理体系审核发现严重不符合项;➢国家法令、法规、规章制度、标准等有所要求;其他不可预见情况。
3.2管理评审程序3.2.1管理评审策划管理评审计划制定管理评审小组应于每次管理评审前编制《管理评审计划》,上报管理者代表审核并由最高管理者批准,下发各相关人员。
管理评审计划的主要内容包括:➢评审时间及地点;评审目的;➢评审范围及评审重点;参加评审人员;➢评审依据;评审内容。
3.2.2管理评审实施1)管理评审准备管理评审小组应提前一周下发管理评审计划,通知参加评审的有关人员,参加评审人员负责准备与本部门有关的评审资料,并提交给管理评审小组。
文件制修订记录1、适用适用于本公司的各种应用系统涉及到的逻辑访问的控制。
2、目的为对本公司各种应用系统的用户访问权限(包括特权用户及第三方用户)实施有效控制,杜绝非法访问,确保系统和信息的安全,特制定本程序。
3、职责3.1各系统的访问授权管理由管理运营部设置安全框架,由各部门主管视权限和业务情况进行分配、审批。
3.2各系统的访问授权实施部门负责访问控制的技术管理以及访问权限控制和实施。
3.3管理运营部负责向各部门通知人事变动情况。
4、程序4.1访问控制策略4.1.1公司内部可公开的信息不作特别限定,允许所有用户访问。
4.1.2公司内部部分不公开信息,经访问授权管理运营部认可,访问授权实施部门实施后用户方可访问。
4.1.3本公司限制使用无线网络,对连接到互联网和局域网的设备采用粘贴标签的方法清晰的标明设备的连接属性(根据敏感程度,可查表获得权限,如IP列表)4.1.4用户不得访问或尝试访问未经授权的网络、系统、文件和服务。
4.1.5相关部门主管填写《用户权限登记表》,确定访问规则后,由网络管理员开设访问帐号和设置访问权限。
4.1.6为确保含有敏感信息的系统不发生泄密事故,采取措施对敏感系统予以隔离。
采用最小权限、最少用户原则。
4.2用户访问管理4.2.1权限申请4.2.1.1授权流程部门申请——授权管理运营部审批——访问授权部门实施所有用户,包括第三方人员均需要履行访问授权手续。
申请部门根据日常管理工作的需要,确定需要访问的系统和访问权限,经过本部门经理同意后,向访问授权管理运营部提交《用户权限申请表》,经访问授权管理运营部审核批准后,将《用户权限申请表》交访问授权实施部门实施。
第三方人员的访问申请由负责接待的部门按照上述要求予以办理。
第三方人员一般不允许成为特权用户。
必要时,第三方人员需与访问接待部门签订《第三方保密协议》。
4.2.1.2《用户权限申请表》应对以下内容予以明确:A)权限申请人员;B)访问权限的级别和范围;C)申请理由;D)有效期。
修订日期:2019.12.18修订日期:2019.12.18信息安全风险评估管理程序1 适用本程序适用于本公司信息安全管理体系(ISMS)范围内信息安全风险评估活动。
2 目的本程序规定了本公司所采用的信息安全风险评估方法。
通过识别信息资产、风险等级评估,认知本公司的信息安全风险,在考虑控制成本与风险平衡的前提下选择合适控制目标和控制方式将信息安全风险控制在可接受的水平,保持本公司业务持续性发展,以满足本公司信息安全管理方针的要求。
3 范围本程序适用于第一次完整的风险评估和定期的再评估。
在辨识资产时,本着尽量细化的原则进行,但在评估时我司又会把资产按照系统进行规划。
辨识与评估的重点是信息资产,不区分物理资产、软件和硬件。
4 职责4.1 成立风险评估小组办公室负责牵头成立风险评估小组。
4.2 策划与实施风险评估小组每年至少一次,或当体系、组织、业务、技术、环境等影响企业的重大事项发生变更、重大事故事件发生后,负责编制信息安全风险评估计划,确认评估结果,形成《信息安全风险评估报告》。
4.3 信息资产识别与风险评估活动各部门负责本部门使用或管理的信息资产的识别,并负责本部门所涉及的信息资产的具体安全控制工作。
4.3.1 各部门负责人负责本部门的信息资产识别。
4.3.2 办公室经理负责汇总、校对全公司的信息资产。
修订日期:2019.12.184.3.3 办公室负责风险评估的策划。
4.3.4 信息安全小组负责进行第一次评估与定期的再评估。
5 程序5.1 风险评估前准备5.1.1 办公室牵头成立风险评估小组,小组成员至少应该包含:信息安全管理体系负责部门的成员、信息安全重要责任部门的成员。
5.1.2风险评估小组制定信息安全风险评估计划,下发各部门内审员。
5.1.3必要时应对各部门内审员进行风险评估相关知识和表格填写的培训。
5.2 信息资产的识别5.2.1 本公司的资产范围包括:5.2.1.1信息资产1)数据文档资产:客户和公司数据,各种介质的信息文件包括纸质文件。
文件制修订记录1、目的规范公司的供应商管理,通过对供应商提供服务的监督,提高供应商服务的质量和安全控制的要求。
2、适用范围本公司相关供应商。
3、定义3.1供应商:服务提供者之外的组织或组织的一部分,其与服务提供者签署协议,共同参与到服务或服务流程的设计、转换、交付和改进中。
注:供应商包括指定的总包商,但不包括他们的分包商。
3.2供应商回顾:就供应商提供的服务与合同进行比较,审查包括服务的要求、范围和等级以及沟通过程与相关方达成的一致,对不符合内容进行审查并要求其限期整改。
4、职责55.1管理策略5.1.1管理运营部指定人员代表作为与商务、采购部门的接口人,在与供应商签订合同的过程中提供支持,向采购和商务部门提供对供应商相关要求。
服务合同应尽可能细致,明确供应商交付服务的范围、供应商资质、服务目标、工作量、双方权利与职责、纠纷处理、收费依据、付款周期等信息;5.1.2与供应商签订服务合同后,供应商人员必须签订保密承诺书,确保公司的商业机密、贸易机密、操作信息、技术信息等不被泄露;5.1.3在供应商提供的服务涉及我方重要设备时,应在我们的监控区域进行服务,如在视频监控的区域或在我方人员陪同下进行。
服务商工作需记录并归档,作为服务商服务回顾时的依据;5.1.4每年按计划的时间间隔对供应商提供的服务进行回顾;供应商服务绩效依据签订的服务合同和服务目标进行测量;5.1.5与服务商的合同发生的变更,需要通过变更控制程序进行控制和管理。
5.2控制指标5.2.1关键绩效指标(KPI)5.2.2管理运营部经理负责供应商管理的改进,应按照PDCA持续改进方法,定期对供应商管理流程及其实际情况进行回顾。
将识别的改进事项记录到「改进计划表」并定期跟踪执行进度。
6、相关记录《供应商列表》《供应商评分表》《供应商评价报告》《供应商管理报告》。
第三方服务管理工作指南
目录
1 范围 (2)
2 规范性引用文件 (2)
3 职责 (2)
4 管理内容和要求 (3)
4.1 第三方服务的确定 (3)
4.2 对第三方服务的监督和评审 (3)
4.3 第三方服务的变更管理 (4)
4.4第三方人员及外包商安全管理 (4)
4.5供应商协议中的安全 (5)
4.6 信息和通信技术供应链 (6)
第三方服务管理工作指南
1 范围
适用于公司信息安全第三方服务管理活动,包括第三方确定过程、第三方的服务安全控制措施、第三方的服务监督和评审方法、第三方的变更管理。
为加强对第三方服务提供商(合作商)的控制,减少安全风险,防范公司信息资产损失,特制定本程序。
2 规范性引用文件
下列文件中的条款通过本标准的引用而成为本标准的条款。
凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准,然而,鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。
凡是不注日期的引用文件,其最新版本适用于本标准。
《信息技术安全技术信息安全管理体系要求》(GB/T 22080-2016/ISO/IEC 27001:2013)
3 职责
3.1 商务采购部
负责统一管理第三方服务的控制活动,负责确定合格的第三方服务商。
3.2 各相关部门
a) 与第三方服务商签订服务合同和保密协议;
b) 负责对第三方服务商的服务进行安全控制;
c) 负责定期对第三方服务商进行监督和评审。
XXXXXXXXX有限责任公司安全区域管理程序[XXXX-B-19]V1.0变更履历1 目的为明确组织安全区域及控制要求,防止非授权人员对组织业务场所的物理访问、损坏和干扰,有效保障组织的工作稳定,特制订本程序。
2 范围本程序适用于组织安全区域的管理。
3 职责3.1 综合部a)负责组织安全区域的控制监管工作。
b)负责对进入组织的员工及外来访客进行确认和控制。
c)负责对非正常进入安全区域的人员、发生的突发事件进行调查和处理。
3.2 技术部负责重要安全区域的访问控制。
3.3 其他部门负责本部门安全区域管理工作。
4 相关文件《信息安全管理手册》《安全区域管理程序》《物理与环境安全管理办法》5 程序5.1 安全区域组织的安全区域分为重要安全区域和普通区域。
综合部应识别重要安全区域,建立和保持《物理与环境安全管理办法》,经各部门经理批准后实施。
重要安全区域以外的办公开发区域,统称为普通区域。
重要安全区域包括以下:a)机柜b)综合管理部文件柜技术部IT专职人员持有机柜的钥匙,每日负责检查机柜。
一般情况下,只有技术部IT 专职人员可打开机柜,如非技术部IT专职人员因工作关系需打开机柜,须通过批准后方可打开。
每日下班后综合管理部文件柜必须上锁。
重要安全区域的控制按《物理与环境安全管理办法》进行。
5.2 普通区域的物理访问外来联系工作和办理业务的人员进入办公、生产区域,须在前台申请,经相关部门负责人通过批准后,外来人员登记来访信息,方可进入普通区域。
前台人员负责外来人员的登记;当外来人员离开时,前台负责登记离开时间。
5.3 重要安全区域的出入控制管理重要安全区域只有技术部IT专职人员能够访问;当服务器需要由其他部门人员安装或更新软件时,开发部门填写《重要安全区域访问审批表》,待技术部批准后方可进入。
完成工作后,登记离开时间,反馈给技术部IT专职人员。
5.4 安全区域的检查管理各部门根据普通区域和重要安全区域不同的要求,严格执行组织相关的规定,防止对安全区域内场所的非授权物理访问、损坏和干扰,有效保障组织信息的安全,保证组织业务正常进行。
ISO27001系统变更管理程序
第一节总则
第一条为规范软件变更与维护管理,提高软件管理水平,优化软件变更与维护管理流程,特制定本制度。
第二条本制度适用于应用系统已开发或采购完毕并正式上线、且由软件开发组织移交给应用管理组织之后,所发生的生产应用系统(以下简
称应用系统)运行支持及系统变更工作。
第二节变更流程
第三条系统变更工作可分为下面三类类型:功能完善维护、系统缺陷修改、统计报表生成。
功能完善维护指根据业务部门的需求,对系统进行
的功能完善性或适应性维护;系统缺陷修改指对一些系统功能或使
用上的问题所进行的修复,这些问题是由于系统设计和实现上的缺
陷而引发的;统计报表生成指为了满足业务部门统计报表数据生成
的需要,而进行的不包含在应用系统功能之内的数据处理工作。
第四条系统变更工作以任务形式由需求方(一般为业务部门)和维护方(一般为信息部门的应用维护组织和软件开发组织,还包括合作厂商)
协作完成。
系统变更过程类似软件开发,大致可分为四个阶段:任
务提交和接受、任务实现、任务验收和程序下发上线。
第五条因问题处理引发的系统变更处理,具体流程参见《问题处理管理制度》。
第六条需求部门提出系统变更需求,并将变更需求整理成《系统变更申请表》(附件一),由部门负责人审批后提交给系统管理员。
第七条系统管理员负责接受需求并上报给IT主管。
IT主管分析需求,并提出系统变更建议。
IT经理根据变更建议审批《系统变更申请表》。
第八条系统管理员根据自行开发、合作开发和外包开发的不同要求组织实现系统变更需求,将需求提交至内部开发人员、合作开发商或外包
开发商,产生供发布的程序。
第九条实现过程应按照软件开发过程规定进行。
系统变更过程应遵循软件开发过程相同的正式、统一的编码标准,并经过测试和正式验收才
能下发和上线。
第十条系统管理员组织业务部门的系统最终用户对系统程序变更进行测试,并撰写《用户测试报告》(附件二),提交业务部门负责人和IT
主管领导签字确认通过。
第十一条在系统变更完成后,系统管理员和业务部门的最终用户共同撰写《程序变更验收报告》(附件三),经业务部门负责人签字验收后,报送
IT经理审批。
第十二条培训管理员负责对系统变更过程的文档进行归档管理,变更过程中涉及的所有文档应至少保存两年。
第三节紧急变更流程。