信息科技风险自评估表
一、信息科技治理
序号 风险类别 风险点 控制目标 风险分析 参考依据
1
对信息科技战略
的审查
批准并审查信息科技战略；保
证信息科技战略与银行总体业
务战略和重大策略相一致；定
期评估信息科技及其风险管理
工作的总体效力和效率。
信 息 风 险 管 理 缺
乏长期规划，无法
指 导 信 息 安 全 工
作开展。
ISO27001：2005 管理层职责：
建立信息安全方针，确保信息安全目标和计划的建立，进
行信息安全管理体系的评审；
ISO27001：2005 信息安全方针文档：
信息安全方针文档应经过管理层的批准，并向所有员工和
外部相关方公布和沟通；
ISO27001：2005 信息安全方针评审：
应按策划的时间间隔或当发生重大变化时，对信息安全方
针文档进行评审，以确保其持续的适宜性、充分性和有效
性。
2
董事会或
高级管理
层职责
对本行信息科技
风险管理现状的
掌握情况
定期听取信息科技风险管理部
门报告；组织进行独立有效的
信息科技风险审计；对审计报
告和监管意见的整改情况进行
监督。
无 法 掌 握 现 有 风
险，对存在的信息
安 全 风 险 针 对 性
的 改 进 无 法 得 到
有力的推进。
Corbit 信息技术审计指南-决定技术方向：
IT管理层理解并使用技术基础设施计划；
技术基础设施计划上的变化，以确定相关的成本和风险，
这些变化要反映在IT长短期计划的变化中；
IT管理层要理解监控和评估正在出现技术的过程，并要将
适当的技术合并到当前的IT基础设施之中；
IT 管理层要理解系统评估技术计划意外的过程。
序号 风险类别 风险点 控制目标 风险分析 参考依据
3
对信息科技建设
的支持
建立合理的人才激励体制；确
保为信息科技风险管理工作拨
付所需资金；建立规范的职业
道德行为和廉政标准。
对 信 息 安 全 风 险
的 改 进 缺 乏 有 效
资源
Corbit信息技术审计指南-管理信息技术投资：
高级管理层应执行预算编制过程，按照机构的长期和短期
计划以及 IT 的长期和短期计划，保证年度 IT 运作预算的
建立和批准。应调查资金的选择。
4
组织信息科技管
理委员会的建立
由来自高级管理层、信息科技
部分和主要业务部分的代表组
成；定期向董事会和高级管理
层汇报信息科技战略规划的效
力、信息科技预算和实际支出、
信息科技的整体性能；对信息
科技建设及管理情况进行有效
的协调。
信 息 安 全 工 作 缺
乏 统 一 组 织 进 行
协调。
等级保护-安全管理机构-岗位设置
c) 应成立指导和管理信息安全工作的委员会或领导小组。
5
首席信息官的设
置
直接参与本银行与信息科技运
用有关的业务发展决策；建立
切实有效的信息科技部分；确
保信息科技风险管理的有效性。
信 息 安 全 工 作 缺
乏 统 一 有 效 的 领
导和责任人。
等级保护-安全管理机构-岗位设置
c)信息安全工作的委员会或领导小组最高领导应由单位主
管领导委任或授权。
6
信息科技部门的
职责
岗位设置完整合理；人员具有
相应的技能和专业知识，制定
有合理的培训计划；重要岗位
制定详细完整的工作说明。
7
组织架构
信息科技风险管
理部分的职责
可直接向 CIO 或 CRO 汇报；实
施持续的信息科技风险评估；
协调有关信息科技风险管理策
略的制定。
缺 乏 具 有 专 业 知
识 和 技 能 的 专 职
人员；信息安全工
作 无 法 有 效 的 协
调。
等级保护-安全管理机构-岗位设置
a) 应设立信息安全管理工作的职能部门，设立安全主管、
安全管理各个方面的负责人岗位，并定义各负责人的
职责；
b) 应配备专职安全管理员，不可兼任；
d) 应制定文件明确安全管理机构各个部门和岗位的职责、
分工和技能要求。
序号 风险类别 风险点 控制目标 风险分析 参考依据
8
信息科技内部审
计岗位
在内审部门内部设立；配备足
够的专业人员；制定完整的信
息科技审计策略和流程；制定
信息科技内审计划并落实。
信 息 安 全 工 作 缺
乏 有 效 的 监 督 和
评价，信息安全风
险 管 理 无 法 有 效
的落实和改进。
等级保护-安全管理机构-审核和检查
a) 安全管理员应负责定期进行安全检查，检查内容包括系
统日常运行、系统漏洞和数据备份等情况；
b) 应由内部人员或上级单位定期进行全面安全检查，检查
内容包括现有安全技术措施的有效性、安全配置与安全策
略的一致性、安全管理制度的执行情况等；
c) 应制定安全检查表格实施安全检查，汇总安全检查数据，
形成安全检查报告，并对安全检查结果进行通报；
d) 应制定安全审核和安全检查制度规范安全审核和安全检
查工作，定期按照程序进行安全审核和安全检查活动。
9
制度建设流程
完善的规章制度和管理办法的
制定、审批和修订流程。
信 息 安 全 管 理 制
度混乱，无法形成
完整体系，缺乏可
操 作 性 且 得 不 到
有效改进。
ISO27001：2005 总要求
组织应根据整体业务活动和风险，建立、实施、运行、监
视、评审、保持并改进文件化的信息安全管理体系。
10
制度建设
制度体系
涵盖运行、安全、开发等各重
要部分；对关键部分应有详细
的管理规定和操作细则。
关 键 工 作 缺 乏 规
范性，工作流程混
乱，直接导致信息
安全事件。
ISO27001：2005-控制目标：
1、信息安全方针；2、信息安全组织；3、资产管理；4、
人力资源安全；5、物理与环境安全；6、通讯及操作管理；
7、访问控制；8、信息系统的获取、开发和维护；9、信息
安全事故管理；10、业务连续性管理；11、符合性。
二、信息科技风险管理
序号 风险类别 风险点 控制目标 风险分析 参考依据
序号 风险类别 风险点 控制目标 风险分析 参考依据
11
信息科技风险管
理策略
策略内容应包括：1、信息分级
与保护；2、应用系统开发、测
试和维护；3、信息科技运行和
维护；4、访问控制；5、物理
安全；6、人员安全；7、业务
连续性与应急处置
安 全 策 略 考 虑 不
完善，没有完整包
含 信 息 安 全 各 方
面，制定的安全策
略内容存在疏漏。
等级保护-控制项：
1、物理安全；2、网络安全；3、主机安全；4、应用安全；
5、数据安全；6、安全管理制度；7、安全管理机构；8、
人员安全管理；9、系统运维管理；10、系统建设管理。
ISO27001：2005-控制目标：
1、信息安全方针；2、信息安全组织；3、资产管理；4、
人力资源安全；5、物理与环境安全；6、通讯及操作管理；
7、访问控制；8、信息系统的获取、开发和维护；9、信息
安全事故管理；10、业务连续性管理；11、符合性。
12
风险识别和评估
流程
准确定位存在隐患的区域；评
价风险对其业务的潜在影响；
对风险进行分类排序；确定风
险防范活动及必备资源的优先
级。
13
风险防范措施
1、明确的信息科技风险管理策
略、技术标准和操作规程等，
并定期公示；2、识别潜在风险
区域，对这些区域进行详细的
独立监控，并建立适当的控制
结构。
14
信息科技
风险管理
风险计量和监测
机制
范围涵盖所有的重要部分，包
含项目实施、系统性能、事故
与投诉、问题整改、外包服务
水平、运行操作、外包项目等。
无 法 了 解 现 有 系
统存在的风险，无
法 有 效 的 指 导 信
息安全的改进，提
高 信 息 系 统 安 全
性。
计算机等级保护制度；
ISO27001：2005 信息安全管理体系要求。
三、信息安全
序号 风险类别 风险点 控制目标 风险分析 参考依据
15
授权机制
完整的审批流程；以“必需知道”
和“最小授权”为原则；权限收回
流程。
用 户 获 得 不 当 权
限，有意或者无意
的 造 成 系 统 破 坏
或信息泄露。
ISO27001 访问控制-控制策略：
应建立文件化的访问控制策略，并根据对访问的业务和安
全要求进行评审；
ISO27001 访问控制-用户注册：
应建立正式的用户注册和解除注册程序，以允许和撤销对
于所有信息系统和服务的访问；
ISO27001 访问控制-特权管理：
应限制和控制特权的使用和分配。
16
用户审查
定期对系统所有用户进行审查；
每个系统的所有用户使用唯一
ID；用户变化时应及时检查和
更新。
用 户 获 得 不 当 权
限，有意或者无意
的 造 成 系 统 破 坏
或信息泄露。
ISO27001 访问控制-用户访问权限的评审：
管理者应按照策划的时间间隔通过正式的流程对用户的访
问权限进行评审。
17
用户认证
和访问控
制
认证机制
与信息访问级别相匹配的用户
认证机制；高风险交易和活动
使用增强的认证方法。
用 户 获 得 不 当 权
限，有意或者无意
的 造 成 系 统 破 坏
或信息泄露。
等级保护-应用安全-身份鉴别：
a) 应提供专用的登录控制模块对登录用户进行身份标识和
鉴别
b) 应对同一用户采用两种或两种以上组合的鉴别技术实现
用户身份鉴别
c) 应提供用户身份标识唯一性和鉴别信息复杂度检查功能，
保证应用系统中不存在重复用户身份标识，身份鉴别信息
不易被冒用
d) 应提供登录失败处理功能，可采取结束会话、限制非法
登录次数和自动退出等措施
e) 应启用身份鉴别、用户身份标识唯一性检查、用户身份
鉴别信息复杂度检查以及登录失败处理功能，并根据安全
策略配置相关参数
序号 风险类别 风险点 控制目标 风险分析 参考依据
18
信息安全管理
完善的信息安全管理流程、组
织架构和职责分配。
管 理 混 乱 信 息 安
全 策 略 无 法 正 确
及时的实施；信息
安 全 责 任 无 法 明
确。
等级保护-安全管理机构-岗位设置
a) 应设立信息安全管理工作的职能部门，设立安全主管、
安全管理各个方面的负责人岗位，并定义各负责人的职责
b) 应设立系统管理员、网络管理员、安全管理员岗位，并
定义各个工作岗位的职责
c) 应成立指导和管理信息安全工作的委员会或领导小组，
其最高领导应由单位主管领导委任或授权
d) 应制定文件明确安全管理机构各个部门和岗位的职责、
分工和技能要求
19
信息安全策略
信息安全策略包含完整的内容：
1、组织信息安全；2、资产管
理；3、人员安全；4、物理和
环境安全；5、通信和操作安全；
6、访问控制；7、身份认证；
8、信息系统的获取、开发和维
护；9、信息安全事故管理；
10、业务连续性管理；11、合
规性。
安 全 策 略 考 虑 不
完善，没有完整包
含 信 息 安 全 各 方
面，制定的安全策
略内容存在疏漏。
ISO27001：2005-控制目标：
1、信息安全方针；2、信息安全组织；3、资产管理；4、
人力资源安全；5、物理与环境安全；6、通讯及操作管理；
7、访问控制；8、信息系统的获取、开发和维护；9、信息
安全事故管理；10、业务连续性管理；11、符合性。
20
信息安全
管理
安全培训
提供必要的培训，使所有员工
都了解信息安全的重要性，并
让员工充分了解其职责范围内
的信息保护流程。
普 通 员 工 缺 乏 信
息安全意识，造成
有 意 或 无 意 的 信
息泄露或者破坏。
等级保护-人员安全管理-安全意识教育和培训：
a) 应对各类人员进行安全意识教育、岗位技能培训和相关
安全技术培训；
b) 应对安全责任和惩戒措施进行书面规定并告知相关人员，
对违反违背安全策略和规定的人员进行惩戒；
c) 应对定期安全教育和培训进行书面规定，针对不同岗位
制定不同的培训计划，对信息安全基础知识、岗位操作规
序号 风险类别 风险点 控制目标 风险分析 参考依据
程等进行培训；
d) 应对安全教育和培训的情况和结果进行记录并归档保存。
21
数据中心的地理
位置
远离自然灾害地区、危险或有
害设施、或繁忙/主要公路；采
取有效的物理或环境控制措施，
监控对信息处理设备运行构成
威胁的环境
物 理 设 施 受 到 台
风、地震、火灾、
震动、灰尘等威胁。
ISO27001：2005-物理与环境安全：
应设计并实施针对火灾、水灾、地震、爆炸、骚乱和其他
形式的自然或人为灾难的物理保护措施。
等级保护-物理安全-物理位置的选择：
a) 机房和办公场地应选择在具有防震、防风和防雨等能力
的建筑内；
b) 机房场地应避免设在建筑物的高层或地下室，以及用水
设备的下层或隔壁。
22
物理安全
数据中心的安全
保卫
出口数量应严格控制；出入通
道的锁具安全可靠；配备有录
像监控和报警系统；关键位置
配备警卫人员；敏感设施及场
所的标识隐匿
非 法 访 问 者 对 物
理 设 施 进 行 有 意
或者无意的破坏。
等级保护-物理安全-物理访问控制：
a) 机房出入口应安排专人值守，控制、鉴别和记录进入的
人员；
b) 需进入机房的来访人员应经过申请和审批流程，并限制
和监控其活动范围；
c) 应对机房划分区域进行管理，区域和区域之间设置物理
隔离装置，在重要区域前设置交付或安装等过渡区域；
d) 重要区域应配置电子门禁系统，控制、鉴别和记录进入
的人员。
等级保护-物理安全-防盗窃和防破坏：
a) 应将主要设备放置在机房内
b) 应对设备或主要部件进行固定，并设置明显的不易除去
的标记
c) 应将通信线缆铺设在隐蔽处，可铺设在地下或管道中
d)应对介质分类标识，存储在介质库或档案室中
序号 风险类别 风险点 控制目标 风险分析 参考依据
e) 应利用光、电等技术设置机房防盗报警系统
f) 应对机房设置监控报警系统
23
数据中心的运行
环境
使用全面的环境控制措施保障
系统安全运行，如：不间断电
源保护、温湿度控制、防水防
火设施等。
物 理 设 施 受 到 潮
湿、断电、火灾等
威胁。
等级保护-物理安全-防雷击：
a) 机房建筑应设置避雷装置
b) 应设置防雷保安器，防止感应雷
c) 机房应设置交流电源地线
等级保护-物理安全-防火：
a)机房应设置火灾自动消防系统，能够自动检测火情、自
动报警，并自动灭火；
b) 机房及相关的工作房间和辅助房应采用具有耐火等级的
建筑材料；
c) 机房应采取区域隔离防火措施，将重要设备与其他设备
隔离开。
等级保护-物理安全-防水和防潮：
a) 水管安装，不得穿过屋顶和活动地板下；
b) 应采取措施防止雨水通过机房窗户、屋顶和墙壁渗透；
c) 应采取措施防止机房内水蒸气结露和地下积水的转移与
渗透；
d) 应安装对水敏感的检测仪表或元件，对机房进行防水检
测和报警；
等级保护-物理安全-防静电：
a) 主要设备应采用必要的接地等防静电措施；
b) 机房应采用防静电地板；
等级保护-物理安全-温湿度控制：
a) 机房应设置温、湿度自动调节设施，使机房温、湿度的
序号 风险类别 风险点 控制目标 风险分析 参考依据
变化在设备运行所允许的范围之内
a) 应在机房供电线路上配置稳压器和过电压防护设备
b) 应提供短期的备用电力供应，至少满足关键设备在断电
情况下的正常运行要求
c) 应设置冗余或并行的电力电缆线路为计算机系统供电
d) 应建立备用供电系统
等级保护-物理安全-电磁防护：
a) 应采用接地方式防止外界电磁干扰和设备寄生耦合干扰；
b) 电源线和通信线缆应隔离，避免互相干扰
c) 应对关键设备和磁介质实施电磁屏蔽
24
门禁管理制度
第三方人员进入安全区域应得
到适当的批准，并受到密切监
控；对外聘人员和承包商有严
格的审查程序，包括身份验证
和背景调查，并签署安全、保
密协议。
非 法 访 问 者 对 物
理 设 施 进 行 有 意
或者无意的破坏。
等级保护-物理安全-物理访问控制：
a) 机房出入口应安排专人值守，控制、鉴别和记录进入的
人员；
b) 需进入机房的来访人员应经过申请和审批流程，并限制
和监控其活动范围。
ISO27001：2005 信息安全组织-外部组织：
应识别来自涉及外部组织的业务过程的信息和信息处理设
施的风险，并在允许访问前实施适当的控制；与第三方签
订的协议中应覆盖所有相关的安全要求。这些协议可能涉
及对组织的喜讯你或信息处理设施的访问、处理、沟通或
管理，或增加信息处理设施的产品和服务。
25
网络安全 逻辑分区
按照不同的安全级别，将网络
划分为不同的逻辑安全域。
重 要 系 统 得 不 到
应有的安全保护，
非 法 用 户 对 系 统
进行非法访问，造
等级保护-网络安全-结构安全：
e) 应根据各部门的工作职能、重要性和所涉及信息的重要
程度等因素，划分不同的子网或网段，并按照方便管理和
控制的原则为各子网、网段分配地址段。
序号 风险类别 风险点 控制目标 风险分析 参考依据
成 系 统 破 坏 或 数
据中断。
26
网络边界防护
不同的网络域之间应采取有效
的分隔和访问控制措施，如部
署防火墙和入侵检测设备；对
网络的特殊敏感域，应采用物
理隔离方式。
扁 平 化 的 网 络 使
网 络 管 理 更 加 困
难，非法访问者更
加 容 易 针 对 重 要
设备并进行攻击。
等级保护-网络安全-结构安全：
f) 应避免将重要网段部署在网络边界处且直接连接外部信
息系统，重要网段与其他网段之间采取可靠的技术隔离手
段。
等级保护-网络安全-访问控制：
a) 应在网络边界部署访问控制设备，启用访问控制功能；
b) 应能根据会话状态信息为数据流提供明确的允许/拒绝
访问的能力，控制粒度为端口级；
c) 应对进出网络的信息内容进行过滤，实现对应用层
HTTP、FTP、TELNET、SMTP、POP3 等协议命令级的控
制；
d) 应在会话处于非活跃一定时间或会话结束后终止网络连
接；
e) 应限制网络最大流量数及网络连接数；
f) 重要网段应采取技术手段防止地址欺骗
g) 应按用户和系统之间的允许访问规则，决定允许或拒绝
用户对受控系统进行资源访问，控制粒度为单个用户；
h) 应限制具有拨号访问权限的用户数量。
等级保护-网络安全-边界完整性检查：
a) 应能够对非授权设备私自联到内部网络的行为进行检查，
准确定出位置，并对其进行有效阻断；
b) 应能够对内部网络用户私自联到外部网络的行为进行检
测，准确定出位置，并对其进行有效阻断。
序号 风险类别 风险点 控制目标 风险分析 参考依据
等级保护-网络安全-入侵防范：
a) 应在网络边界处监视以下攻击行为：端口扫描、强力攻
击、木马后门攻击、拒绝服务攻击、缓冲区溢出攻击、IP
碎片攻击和网络蠕虫攻击等
b) 当检测到攻击行为时，记录攻击源 IP、攻击类型、攻击
目的、攻击时间，在发生严重入侵事件时应提供报警
27
传输加密
敏感数据在网络传输过程中应
加密。
数据被非法窃听，
导 致 重 要 数 据 泄
露。
等级保护-数据安全-数据保密性
a) 应采用加密或其他有效措施实现系统管理数据、鉴别信
息和重要业务数据传输保密性。
28
网络监控
依据事先定义的性能目标对网
络进行持续地监测，以确认任
何潜在的瓶颈制约或超负荷运
行等任何异常的活动；高强度
网络分析工具的使用应有适当
的授权或审批流程。
无 法 及 时 发 现 网
络异常，导致网络
故障或系统宕机。
等级保护-系统运维管理-监控管理：
a) 应对通信线路、主机、网络设备和应用软件的运行状况、
网络流量、用户行为等进行监测和报警，形成记录并妥善
保存；
b) 应组织相关人员定期对监测和报警记录进行分析、评审，
发现可疑行为，形成分析报告，并采取必要的应对措施；
a) 应指定专人对网络进行管理，负责运行日志、网络监控
记录的日常维护和报警信息分析和处理工作。
29
网络配置更改
定期审查网络配置；配置更改
或设备调整应作为网络变更流
程进行操作。
网 络 配 置 不 当 导
致出现安全弱点；
错 误 的 配 置 操 作
导 致 网 络 安 全 弱
点 或 网 络 故 障 出
现。
等级保护-系统运维管理-网络安全管理：
a) 应指定专人对网络进行管理，负责运行日志、网络监控
记录的日常维护和报警信息分析和处理工作；
b) 应建立网络安全管理制度，对网络安全配置、日志保存
时间、安全策略、升级与打补丁、口令更新周期等方面作
出规定；
c) 应根据厂家提供的软件升级版本对网络设备进行更新，
并在更新前对现有的重要文件进行备份；
序号 风险类别 风险点 控制目标 风险分析 参考依据
d) 应定期对网络系统进行漏洞扫描，对发现的网络系统安
全漏洞进行及时的修补；
e) 应实现设备的最小服务配置，并对配置文件进行定期离
线备份；
f) 应保证所有与外部系统的连接均得到授权和批准；
g) 应依据安全策略允许或拒绝便携式和移动式设备的网络
接入；
h) 应定期检查违反规定拨号上网或其他违反网络安全策略
的行为。
30
安全标准
制定每种类型操作系统的基本
安全要求，确保所有系统满足
基本安全要求。
操 作 系 统 配 置 不
当 导 致 出 现 安 全
弱点。
等级保护-系统运维管理-系统安全管理：
a) 应根据业务需求和系统安全分析确定系统的访问控制策
略；
b) 应定期进行漏洞扫描，对发现的系统安全漏洞及时进行
修补；
c) 应安装系统的最新补丁程序，在安装系统补丁前，首先
在测试环境中测试通过，并对重要文件进行备份后，方可
实施系统补丁程序的安装；
d) 应建立系统安全管理制度，对系统安全策略、安全配置、
日志管理和日常操作流程等方面作出具体规定。
31
访问权限
明确定义不同用户组的访问权
限，包括终端用户、系统开发
人员、系统测试人员、计算机
操作人员、系统管理员和用户
管理员等。
管 理 员 获 得 不 当
权限，系统关键配
置被非法修改。
等级保护-系统运维管理-系统安全管理：
e) 应指定专人对系统进行管理，划分系统管理员角色，明
确各个角色的权限、责任和风险，权限设定应当遵循最小
授权原则。
32
操作系统
安全
最高权限账户管 制定针对使用最高权限系统帐 高 权 限 帐 号 的 错 等级保护-安全管理机构-授权和审批：
序号 风险类别 风险点 控制目标 风险分析 参考依据
理 户的审批、验证和监控流程，
并确保最高权限用户的操作日
志被记录和监察。
误 或 非 法 操 作 造
成 严 重 的 故 障 或
损失；无法对故障
或 损 失 的 原 因 进
行追溯。
a) 应根据各个部门和岗位的职责明确授权审批事项、审批
部门和批准人等
b) 应针对系统变更、重要操作、物理访问和系统接入等事
项建立审批程序，按照审批程序执行审批过程，对重要活
动建立逐级审批制度
c) 应定期审查审批事项，及时更新需授权和审批的项目、
审批部门和审批人等信息
d) 应记录审批过程并保存审批文档
等级保护-主机安全-安全审计：
a) 审计范围应覆盖到服务器和重要客户端上的每个操作系
统用户和数据库用户；
e) 应保护审计进程，避免受到未预期的中断；
f) 应保护审计记录，避免受到未预期的删除、修改或覆盖
等。
33
安全补丁
定期监察可用的安全补丁，经
评估和测试后进行安装。
对 已 发 现 系 统 漏
洞无法及时修补，
导致黑客入侵，木
马、病毒植入；不
当 的 安 全 补 丁 安
装 影 响 系 统 稳 定
性或者系统宕机。
等级保护-系统运维管理-系统安全管理：
c) 应安装系统的最新补丁程序，在安装系统补丁前，首先
在测试环境中测试通过，并对重要文件进行备份后，方可
实施系统补丁程序的安装；
34
重要事项审核
操作人员应对操作系统运行的
重要事项进行检查和说明，如
系统日志中记录的未成功登录，
重要系统文件的访问，对用户
对 操 作 系 统 的 非
法 或 错 误 操 作 无
法记录，对信息安
全 事 件 或 系 统 故
等级保护-主机安全-安全审计：
a) 审计范围应覆盖到服务器和重要客户端上的每个操作系
统用户和数据库用户
b) 审计内容应包括重要用户行为、系统资源的异常使用和
序号 风险类别 风险点 控制目标 风险分析 参考依据
帐号进行修改等信息，以及系
统出现的任何异常事件。
障 无 法 进 行 追 溯
和分析。
重要系统命令的使用等系统内重要的安全相关事件
c) 审计记录应包括事件的日期、时间、类型、主体标识、
客体标识和结果等
d) 应能够根据记录数据进行分析，并生成审计报表
e) 应保护审计进程，避免受到未预期的中断
f) 应保护审计记录，避免受到未预期的删除、修改或覆盖
等
35
岗位职责
明确定义终端用户和信息科技
技术人员在应用安全中的岗位
和职责；对关键或敏感职能进
行双重控制。
知识、技能不够造
成误操作；重要岗
位 缺 乏 监 管 造 成
有意的非法操作。
ISO27001：2005 人力资源安全-角色和职责：
应根据组织的信息安全方针，规定员工、合同方和第三方
用户的安全角色和职责并形成文件。
ISO27001：2005 访问控制-特权管理：
应限制和控制特权的使用和分配
36
应用系统
安全
身份验证
针对应用系统的重要程序和敏
感程度，采取有效的身份验证
方法。
非 法 用 户 获 得 访
问权限。
等级保护-应用安全-身份鉴别：
a) 应提供专用的登录控制模块对登录用户进行身份标识和
鉴别；
b) 应对同一用户采用两种或两种以上组合的鉴别技术实现
用户身份鉴别；
c) 应提供用户身份标识唯一性和鉴别信息复杂度检查功能，
保证应用系统中不存在重复用户身份标识，身份鉴别信息
不易被冒用；
d) 应提供登录失败处理功能，可采取结束会话、限制非法
登录次数和自动退出等措施；
e) 应启用身份鉴别、用户身份标识唯一性检查、用户身份
鉴别信息复杂度检查以及登录失败处理功能，并根据安全
策略配置相关参数。
序号 风险类别 风险点 控制目标 风险分析 参考依据
37
信息输入和输出
在关键的接合点进行输入验证
或输出核对；采取安全的方式
处理保密信息的输入和输出，
防止信息被盗、篡改、故意或
无意泄露。
关键数据被盗、篡
改、故意或无意泄
露。
ISO27001：2005 电子商务服务-电子商务：
应保护电子商务中通过公共网络传输的信息，以防止欺诈、
合同争议、未授权的泄漏和修改；
ISO27001：2005 电子商务服务-在线交易：
应保护在线交易中的信息，以防止不完整的传输、路由错
误、未授权的消息修改、未经授权的泄漏、未经授权的消
息复制或回复。
38
运行情况审核
系统能以书面或电子格式保存
审计痕迹；能够以预先定义的
方式处理例外情况，并向用户
提供有意义的信息；管理人员
对系统重要事项进行管理和审
核。
对 应 用 系 统 的 非
法 或 错 误 操 作 无
法记录，对信息安
全 事 件 或 系 统 故
障 无 法 进 行 追 溯
和分析。
等级保护-应用安全-安全审计：
a) 应覆盖到每个用户的安全审计功能，对应用系统重要安
全事件进行审计；
b) 应保证无法单独中断审计进程，无法删除、修改或覆盖
审计记录；
c) 审计记录的内容至少应包括日期、时间、发起者信息、
类型、描述和结果等；
d) 应提供对审计记录数据进行统计、查询、分析及生成审
计报表的功能。
39
策略和流程
制定了相关策略和流程，控制
所有生产系统的活动日志，以
支持有效的审核、安全论证分
析和预防欺诈；设置了日志监
控和管理岗位；制定了日志资
料的安全保护和调阅管理制度。
无 法 及 时 发 现 信
息安全事件，无法
对 信 息 安 全 事 件
进行分析和预防；
日 志 被 篡 改 或 者
无意丢失，无法对
历 史 事 件 进 行 追
溯。
等级保护-系统运维-监控管理：
a) 应对通信线路、主机、网络设备和应用软件的运行状况、
网络流量、用户行为等进行监测和报警，形成记录并妥善
保存；
b) 应组织相关人员定期对监测和报警记录进行分析、评审，
发现可疑行为，形成分析报告，并采取必要的应对措施；
c) 应建立安全管理中心，对设备状态、恶意代码、补丁升
级、安全审计等安全相关事项进行集中管理。
40
日志安全
交易日志 交易日志由应用软件和数据库 对系统问题，非法 等级保护-主机安全-安全审计；
序号 风险类别 风险点 控制目标 风险分析 参考依据
管理系统产生，包括身份尝试、
数据修改、错误信息等；交易
日志按照国家会计政策要求予
以保存。
操 作 无 法 进 行 记
录，对出现问题的
原 因 无 法 进 行 追
溯。
41
系统日志
系统日志由操作系统、数据库
管理系统、防火墙、入侵检测
系统和路由器等生成，包括身
份认证尝试、系统事件、网络
事件、错误信息等；系统和网
络日志保存期限按事先的风险
定级确定，但不能少。
不 完 整 的 日 志 无
法 对 现 有 的 系 统
运 行 情 况 进 行 监
控，无法对出现的
各 类 事 件 的 原 因
进行追溯；历史记
录 不 进 行 合 理 的
保 留 导 致 在 出 现
问 题 后 对 以 前 的
操 作 或 者 问 题 进
行查找分析。
42
保存和复查
银行应保证在日志中包含足够
的项目，以便有效地完成内部
控制、系统故障解决和审计，
同时应采取适当措施保证所有
日志的计时同步，并确保其完
整性，有任何的例外情况发生
都应当复查系统日志。交易日
志或数据库日志的复查频率和
保留周期应由信息科技部门和
有关业务部分共同决定，并报
不 完 善 的 日 志 记
录 无 法 对 审 计 提
供足够的参考；缺
乏 日 志 审 核 对 隐
藏 的 操 作 问 题 无
法及时发现。
等级保护-应用安全-安全审计；
等级保护-网络安全-安全审计；
等级保护-系统运维管理-网络安全管理；
a) 应指定专人对网络进行管理，负责运行日志、网络监控
记录的日常维护和报警信息分析和处理工作
b) 应建立网络安全管理制度，对网络安全配置、日志保存
时间、安全策略、升级与打补丁、口令更新周期等方面作
出规定
等级保护-系统运维管理-系统安全管理：
d) 应建立系统安全管理制度，对系统安全策略、安全配置、
日志管理和日常操作流程等方面作出具体规定；
g) 应定期对运行日志和审计数据进行分析，以便及时发现
异常行为。
序号 风险类别 风险点 控制目标 风险分析 参考依据
信息科技管理委员会批准。
43
信息分类
制定信息分类操作指南和信息
保护工作流程；信息依据敏感
程度进行分类，并指定所有人。
对 重 要 信 息 无 法
提 供 足 够 有 效 的
保护，造成重要信
息被破坏、篡改、
泄露。
ISO27001：2005 资产管理-分类指南：
应按照信息的价值、法律要求及对组织的敏感程度和关键
程度进行分类；
ISO27001：2005 资产管理-信息标识和处置：
应制定一套与组织所采用的分类方案一致的信息标识和处
置的程序，并实施。
44
信息加密
对不同类别信息采用相应的加
密技术或密码设备；建立密码
设备管理规范制度；管理使用
密码系统设备的员工经过专业
培训和严格审核。
没 有 加 密 的 信 息
容易被泄露、破坏、
篡改。
等级保护-数据安全-数据完整性：
a) 应能够检测到系统管理数据、鉴别信息和用户数据在传
输过程中完整性受到破坏，并在检测到完整性错误时采取
必要的恢复措施
b) 应能够监测到系统管理数据、鉴别信息和重要业务数据
在存储过程中完整性受到破坏，并在监测到完整性错误时
采取必要的恢复措施
等级保护-数据安全-数据保密性：
a) 应采用加密或其他有效措施实现系统管理数据、鉴别信
息和重要业务数据传输保密性
b) 应采用加密或其他保护措施实现系统管理数据、鉴别信
息和重要业务数据存储保密性
等级保护-系统运维管理-密码管理：
a) 应建立密码使用管理制度，使用符合国家密码管理规定
的密码技术和产品。
45
信息安全
密钥管理
实施有效的密钥管理流程，尤
其是密钥生命周期管理和证书
周期管理。
密钥泄露，造成严
重信息安全事件。
等级保护-系统运维管理-密码管理：
a) 应建立密码使用管理制度，使用符合国家密码管理规定
的密码技术和产品。
序号 风险类别 风险点 控制目标 风险分析 参考依据
46
机密信息安全
机密信息的加密使用符合国家
密码管理局要求的加密技术和
加密设备，加密强度和加密效
率满足信息机密性和可用性要
求。
机密信息泄露，造
成 严 重 信 息 安 全
事件。
等级保护-数据安全-数据完整性；
等级保护-数据安全-数据保密性；
等级保护-系统运维管理-密码管理：
a) 应建立密码使用管理制度，使用符合国家密码管理规定
的密码技术和产品。
47
客户敏感信息安
全
制定相关策略和程序，管理客
户信息的采集、处理、存贮、
传输、传播、备份、恢复、清
理和销毁。
客户数据被泄露，
破坏和篡改，直接
造成经济损失。
ISO27001：2005 电子商务服务-电子商务：
应保护电子商务中通过公共网络传输的信息，以防止欺诈、
合同争议、未授权的泄漏和修改；
ISO27001：2005 电子商务服务-在线交易：
应保护在线交易中的信息，以防止不完整的传输、路由错
误、未授权的消息修改、未经授权的泄漏、未经授权的消
息复制或回复。
四、应用系统开发、测试和维护
序号 风险类别 风险点 控制目标 风险分析 参考依据
48
项目管理 制度建设
应制定策略和流程，治理信息
科技项目的立项、优先排序、
审批和控制；重大项目必须建
立项目管理框架和工作方案，
包括：职责的划分、时间进度、
财务预算管理、质量检测、风
险评估等。
项目管理混乱，项
目成本无法控制，
进度无法掌握，项
目质量无法度量，
导致项目失败。
等级保护-安全管理制度-管理制度：
b) 应对安全管理活动中的各类管理内容建立安全管理制度；
d) 应形成由安全策略、管理制度、操作规程等构成的全面
的信息安全管理制度体系。
序号 风险类别 风险点 控制目标 风险分析 参考依据
49
进度报告
定期向信息科技管理委员会提
交重大信息科技项目的进度报
告；进度报告包括更改时间计
划、关键人员或供应商的决策
以及主要费用
项 目 缺 乏 统 一 的
计划和安排
等级保护-系统建设管理-工程实施：
b) 应制定详细的工程实施方案控制实施过程，并要求工程
实施单位能正式地执行安全工程过程；
c) 应制定工程实施方面的管理制度，明确说明实施过程的
控制方法和人员行为准则。
50
系统开发方法
根据信息科技项目的规模、性
质和复杂性采用适当的系统开
发方法，控制信息系统的生命
周期；典型的系统生命周期包
括系统分析、设计、开发或采
购、测试、试运行、部署、维
护或报废。
信 息 科 技 项 目 缺
乏 有 效 的 过 程 管
理和控制
等级保护-系统建设管理-自行软件开发：
b) 应制定软件开发管理制度，明确说明开发过程的控制方
法和人员行为准则。
ISO27001-通讯及操作管理-操作程序及职责-开发、测试和
运营设施的分离：
应分离开发、测试和运营设施，以降低未授权访问或对操
作系统变更的风险；
ISO27001-通讯及操作管理-系统规划与验收-系统验收：
应建立新的信息系统、 系统升级和新版本的验收准则，
并在开发过程中及接收前进行适当的系统测试。
序号 风险类别 风险点 控制目标 风险分析 参考依据
51
风险管理或者内
部审计的参与
商业银行在进行大规模和大范
围的系统开发时，应要求内部
审计部门或信息科技风险管理
部分的参与，保证系统开发符
合商业银行信息科技风险标准。
不 严 格 的 开 发 过
程 使 应 用 系 统 存
在安全弱点，应用
系 统 问 题 无 法 在
项 目 建 设 过 程 中
及时发现，直接导
致系统运行失败、
系 统 中 重 要 数 据
被破坏、丢失。
等级保护-系统建设管理-自行软件开发：
a) 应确保开发环境与实际运行环境物理分开，开发人员和
测试人员分离，测试数据和测试结果受到控制
b) 应制定软件开发管理制度，明确说明开发过程的控制方
法和人员行为准则
c) 应制定代码编写安全规范，要求开发人员参照规范编写
代码
d) 应确保提供软件设计的相关文档和使用指南，并由专人
负责保管
e) 应确保对程序资源库的修改、更新、发布进行授权和批
准
等级保护-系统建设管理-测试验收：
b) 在测试验收前根据设计方案或合同要求等制定测试验收
方案，在测试验收过程中应详细记录测试验收结果，并形
成测试验收报告；
c) 应对系统测试验收的控制方法和人员行为准则进行书面
规定。
52
文档管理 格式标准
规范并明确项目资料文档的管
理职责、资料文档的起草和审
批职责、资料文档格式标准化
规范。
软 件 质 量 无 法 保
证，对软件质量的
改 进 等 无 法 有 效
实施。
等级保护-系统建设管理-自行软件开发：
b) 应制定软件开发管理制度，明确说明开发过程的控制方
法和人员行为准则
d) 应确保提供软件设计的相关文档和使用指南，并由专人
负责保管。
序号 风险类别 风险点 控制目标 风险分析 参考依据
53
程序文档完整性
程序文档内容包括：程序设计
和代码标准、程序描述、程序
设计资料、代码清单、源代码
命名规则、系统操作指南等。
项 目 程 序 文 档 的
缺失，可能会致使
整 个 项 目 维 护 困
难、升级困难等问
题
等级保护-系统建设管理-自行软件开发：
d) 应确保提供软件设计的相关文档和使用指南，并由专人
负责保管。
等级保护-系统建设管理-外包软件开发：
c) 应要求开发单位提供软件设计的相关文档和使用指南。
等级保护-系统建设管理-系统交付：
a) 应制定详细的系统交付清单，并根据交付清单对所交接
的设备、软件和文档等进行清点；
c) 应确保提供系统建设过程中的文档和指导用户进行系统
运行维护的文档。
54
项目文档完整性
项目文档内容包括：项目需求、
可行性分析、阶段实施记录（启
动、计划、设计、开发、测试、
实施、后评价等）。
项 目 文 档 的 不 完
善，增加了项目失
败的可能性
等级保护-系统建设管理-工程实施：
b) 应制定详细的工程实施方案控制实施过程，并要求工程
实施单位能正式地执行安全工程过程。
等级保护-系统建设管理-外包软件开发：
a) 应根据开发需求检测软件质量；
c) 应要求开发单位提供软件设计的相关文档和使用指南。
55
系统测试
开发环境与测试
环境的分离
保证生产系统与开发系统、测
试系统相分离；生产系统与开
发系统、测试系统的管理职能
相分离。
影 响 生 产 系 统 的
稳定性，导致数据
泄 漏 等 安 全 事 件
的发生。
等级保护-系统建设管理-自行软件开发：
a) 应确保开发环境与实际运行环境物理分开，开发人员和
测试人员分离，测试数据和测试结果受到控制。
ISO27001-通讯及操作管理-操作程序及职责-开发、测试和
运营设施的分离：
应分离开发、测试和运营设施，以降低未授权访问或对操
作系统变更的风险。
序号 风险类别 风险点 控制目标 风险分析 参考依据
56
测试数据
敏感的生产数据应该降低或消
除敏感性，在运用到测试环境
前必须得到预先的批准。
生 产 数 据 丢 失 或
泄漏
等级保护-系统建设管理-测试验收：
b) 在测试验收前根据设计方案或合同要求等制定测试验收
方案，在测试验收过程中应详细记录测试验收结果，并形
成测试验收报告。
ISO27001-信息系统的获取、开发和维护-系统文档安全-系
统测试数据的保护：
应谨慎选择测试数据，并加以保护和控制。
57
系统验收 独立方验收
较大的与技术相关项目应该由
独立的一方实施质量品质审查。
系 统 的 质 量 无 法
得 到 有 效 的 验 证
和度量
等级保护-系统建设管理-测试验收：
a) 应委托公正的第三方测试单位对系统进行安全性测试，
并出具安全性测试报告。
ISO27001-通讯及操作管理-系统规划与验收-系统验收：
应建立新的信息系统、 系统升级和新版本的验收准则，
并在开发过程中及接收前进行适当的系统测试。
58
系统维护 系统变更
应用程序开发和维护人员经管
理层授权才能进入生产系统；
所有的紧急修复活动立即进行
记录和审核。
关 键 操 作 缺 乏 监
管和控制，导致出
现 有 意 或 无 意 的
非法操作。
等级保护-系统运维管理-变更管理：
b) 应建立变更管理制度，系统变更前，向主管领导申请，
变更方案经过评审、审批后方可实施变更，并在实施后将
变更情况向相关人员通告；
c) 应建立变更控制的申报和审批文件化程序，变更影响分
析应文档化，记录变更实施过程，并妥善保存所有文档和
记录。
ISO27001-通讯及操作管理-操作程序及职责-变更管理：
应控制信息处理设施及系统的变更；
ISO27001-信息系统的获取、开发和维护-开发和支持过程
的安全-变更控制程序：
应通过正式的变更控制程序，控制变更的实施。
序号 风险类别 风险点 控制目标 风险分析 参考依据
59
系统升级
制定相关策略和流程，控制系
统升级过程；系统升级应被视
为项目对待，接受所有相关项
目管理控制，包括用户验收测
试。
升 级 过 程 中 错 误
操 作 导 致 系 统 错
误或者崩溃。
等级保护-系统运维管理-网络安全管理：
c) 应根据厂家提供的软件升级版本对网络设备进行更新，
并在更新前对现有的重要文件进行备份。
等级保护-系统运维管理-系统安全管理：
c) 应安装系统的最新补丁程序，在安装系统补丁前，首先
在测试环境中测试通过，并对重要文件进行备份后，方可
实施系统补丁程序的安装。
ISO27001-信息系统的获取、开发和维护-信息系统安全要
求-安全要求分析和规范：
新的信息系统或对现有信息系统的更新的业务要求声明中
应规定安全控制的要求。
60
问题管理
建立并完善有效的问题管理流
程；建立问题知识库，进行记
录、分类和编制索引；重要责
任和指令集，应进行清楚地描
述说明，并通知所有相关人员。
对 发 现 的 问 题 无
法 快 速 有 效 进 行
判断和处理，导致
问 题 影 响 时 间 延
长，问题范围扩大。
等级保护-系统运维管理-安全事件处置：
b) 应制定安全事件报告和处置管理制度，明确安全事件的
类型，规定安全事件的现场处理、事件报告和后期恢复的
管理职责。
等级保护-人员安全管理-安全意识教育和培训：
b) 应对安全责任和惩戒措施进行书面规定并告知相关人员，
对违反违背安全策略和规定的人员进行惩戒。
ISO27001-信息安全事故管理-信息安全事故的管理和改进
-从信息安全事故中学习：
应建立能够量化和监控信息安全事故的类型、数量、成本
的机制。
五、信息科技运行
序号 风险类别 风险点 控制目标 风险分析 参考依据
序号 风险类别 风险点 控制目标 风险分析 参考依据
61
岗位设置
合理的岗位设置；明确的岗位
职责；不相容岗位的分离设置，
如系统运行与系统开发维护分
离；岗位职权的中止。
岗位设置不合理，
权限缺乏制约，容
易引起越权操作。
等级保护-主机安全-访问控制：
b) 应根据管理用户的角色分配权限，实现管理用户的权限
分离，仅授予管理用户所需的最小权限。
等级保护-应用安全-访问控制：
d) 应授予不同帐户为完成各自承担任务所需的最小权限，
并在它们之间形成相互制约的关系。
ISO27001-信息安全组织-内部组织-信息安全管理委员会：
管理者应通过清晰的方向、可见的承诺、明确的任务分配、
信息安全职责沟通在组织内积极支持安全。
62
管理制度
信息系统运行体系的总体规划、
管理办法、技术标准和信息系
统运行体系各组成部分的管理
细则。
管理制度不完善，
操 作 缺 乏 有 效 的
指导和约束，易导
致非法操作。
等级保护-安全管理制度-管理制度：
a) 应制定信息安全工作的总体方针和安全策略，说明机构
安全工作的总体目标、范围、原则和安全框架等；
d) 应形成由安全策略、管理制度、操作规程等构成的全面
的信息安全管理制度体系。
63
运行体系
建设
交易记录
按照有关法律法规要求的年限
保存交易记录；采取必要的程
序和技术确保存档数据的完整
性，满足安全保存和恢复要求。
重 要 生 产 数 据 丢
失或泄漏，破坏数
据 的 完 整 性 和 可
用性。
等级保护-系统运维管理-备份与恢复管理：
c) 应根据数据的重要性和数据对系统运行的影响，制定数
据的备份策略和恢复策略，备份策略须指明备份数据的放
置场所、文件命名规则、介质替换频率和将数据离站运输
的方法；
d) 应建立控制数据备份和恢复过程的程序，对备份过程进
行记录，所有文件和记录应妥善保存；
e) 应定期执行恢复程序，检查和测试备份介质的有效性，
确保可以在恢复程序规定的时间内完成备份的恢复。
ISO27001-通讯及操作管理-备份-信息备份：
应根据既定的备份策略对信息和软件进行备份并定期测试。
序号 风险类别 风险点 控制目标 风险分析 参考依据
64
操作规程
运行管理各部分制定有详细的
操作规程，包括操作人员的任
务、工作日程安排和执行过程；
信息科技运行手册包括生产和
开发环境中数据和软件的现场
及非现场备份（即备份的频率、
范围和保留周期）的程序和要
求。
操作失误，维护错
误，造成业务中断。
等级保护-系统运维管理-备份与恢复管理：
b) 应建立备份与恢复管理相关的安全管理制度，对备份信
息的备份方式、备份频度、存储介质和保存期等进行规范；
c) 应根据数据的重要性和数据对系统运行的影响，制定数
据的备份策略和恢复策略，备份策略须指明备份数据的放
置场所、文件命名规则、介质替换频率和将数据离站运输
的方法。
ISO27001-访问控制-访问控制的业务要求-访问控制策略：
应建立文件化的访问控制策略， 并根据对访问的业务和
安全要求进行评审。
序号 风险类别 风险点 控制目标 风险分析 参考依据
65
事件管理 事件管理系统
建立事件管理系统及处理机制，
及时响应信息系统运行事故，
逐级向相关的信息科技管理人
员汇报事故的发生，记录、分
析和跟踪所有事件，直到对事
件进行彻底的改正并完成根本
原因的分析。
无 法 及 时 有 效 解
决安全事件；对安
全隐患无法根除。
等级保护-系统运维管理-安全事件处置：
b) 应制定安全事件报告和处置管理制度，明确安全事件的
类型，规定安全事件的现场处理、事件报告和后期恢复的
管理职责；
e) 应在安全事件报告和响应处理过程中，分析和鉴定事件
产生的原因，收集证据，记录处理过程，总结经验教训，
制定防止再次发生的补救措施，过程形成的所有文件和记
录均应妥善保存。
ISO27001-信息安全事故管理-报告信息安全事件和弱点：
报告信息安全事件，应通过适当的管理途径尽快报告信息
安全事件；报告信息安全弱点，应要求所有的员工、合同
方和第三方用户注意并报告系统或服务中已发现或疑似的
安全弱点。
ISO27001-信息安全事故管理-信息安全事故的管理和改进：
职责和程序，应建立管理职责和程序，以快速、有效和有
序的响应信息安全事故；
从信息安全事故中学习，应建立能够量化和监控信息安全
事故的类型、数量、成本的机制；收集证据，事故发生后，
应根据相关法律的规定（无论是民法还是刑法）跟踪个人
或组织的行动，应收集、保留证据，并以符合法律规定的
形式提交。
序号 风险类别 风险点 控制目标 风险分析 参考依据
66
服务支持系统
为用户提供所有技术相关事件
的前线支持，并将事件提交给
相关信息科技职能部分进行调
查和解决。
故 障 后 无 法 及 时
响 应 各 类 安 全 事
件，造成业务中断。
等级保护-系统运维管理-安全事件处置：
d) 应制定安全事件报告和响应处理程序，确定事件的报告
流程，响应和处置的范围、程度，以及处理方法等。
ISO27001-信息系统的获取、开发和维护-开发和支持过程
的安全：
变更控制程序，应通过正式的变更控制程序，控制变更的
实施；
操作系统变更后的技术评审，当操作系统变更后， 应评审
并测试关键的业务应用系统， 以确保变更不会对组织的
运营或安全产生负面影响；
软件包变更限制，不鼓励对软件包进行变更， 对必要的更
改严格控制；
信息泄漏，防止信息泄漏的机会；软件委外开发，组织应
对软件委外开发进行监控。
67
系统监控
核心业务系统监
控
对核心业务系统的持续性或阶
段性监测，包括响应时间和处
理量、系统承载能力、任务处
理失败的次数、比例、类型和
原因、系统使用的峰值和均值，
系统使用趋向和容量等。
对 安 全 事 件 无 法
事前预防，系统可
用性得不到保障。
等级保护-主机安全-资源控制：
c) 应对重要服务器进行监视，包括监视服务器的 CPU、硬
盘、内存、网络等资源的使用情况。
ISO27001-通讯及操作管理-监督-监视系统的使用：
应建立监视信息处理系统使用的程序， 并定期评审监视
活动的结果。
序号 风险类别 风险点 控制目标 风险分析 参考依据
68
监控程序
落实监控程序，确保应用系统
的性能受到连续监控，及时完
整地报告例外情况；性能监控
程序提供预警功能，在问题对
系统性能造成影响前对其进行
识别和修正。
安 全 事 件 无 法 及
时遏制，造成系统
可用性下降，甚至
中断。
等级保护-主机安全-资源控制：
e) 应能够对系统的服务水平降低到预先规定的最小值进行
检测和报警。
ISO27001-通讯及操作管理-监督-监视系统的使用：
应建立监视信息处理系统使用的程序， 并定期评审监视
活动的结果。
ISO27001-通讯及操作管理-监督-审计日志：
应产生记录用户活动、以外和信息安全事件的日志，并按
照约定的期限进行保留，以支持将来的调查和访问控制监
视。
69
容量规划 覆盖范围
建立容量规划以适应由于经济
金融环境变化产生的业务发展
和交易量非计划性增加；容量
规划应涵盖与生产环境有关的
备份系统。
系 统 性 能 无 法 满
足业务需求。
ISO27001-通讯及操作管理-系统规划与验收-容量管理：
应监督、调整资源的使用情况，并反应将来容量的要求，
以确保系统的性能。
70
变更管理 管理规程
已制定并实施了书面的变更管
理规程，包括过程记录、变更
优先级的确定、程序的版本控
制和审计跟踪、计划和实施变
更、在必要时变更的恢复和实
施的后评价。
错 误 的 变 更 直 接
导 致 业 务 系 统 中
断，重要数据被篡
改、泄露和破坏。
等级保护-系统运维管理-变更管理：
b) 应建立变更管理制度，系统变更前，向主管领导申请，
变更方案经过评审、审批后方可实施变更，并在实施后将
变更情况向相关人员通告；
c) 应建立变更控制的申报和审批文件化程序，变更影响分
析应文档化，记录变更实施过程，并妥善保存所有文档和
记录。
ISO27001-信息系统的获取、开发和维护-开发和支持过程
的安全-变更控制程序：
应通过正式的变更控制程序，控制变更的实施。
序号 风险类别 风险点 控制目标 风险分析 参考依据
71
授权机制
系统变更应建立合理的审批流
程；涉及业务系统或数据的变
更应由科技部门和业务部门共
同签准。
未 经 审 批 的 操 作
导致越权，直接对
系 统 安 全 造 成 威
胁。
等级保护-系统运维管理-变更管理：
c) 应建立变更控制的申报和审批文件化程序，变更影响分
析应文档化，记录变更实施过程，并妥善保存所有文档和
记录。
ISO27001-信息系统的获取、开发和维护-开发和支持过程
的安全-操作系统变更后的技术评审：
当操作系统变更后， 应评审并测试关键的业务应用系统，
以确保变更不会对组织的运营或安全产生负面影响。
72
实施过程
变更前对变更程序进行测试；
变更前对系统进行备份；变更
实施后进行验收测试。
没 有 经 过 测 试 的
变 更 可 能 导 致 系
统中断；缺乏验证
的 变 更 无 法 准 确
的 评 估 其 有 效 性
和安全性。
ISO27001-信息系统的获取、开发和维护-开发和支持过程
的安全-变更控制程序：
应通过正式的变更控制程序，控制变更的实施。
73
回滚计划
所有变更都应建立失败后的恢
复计划。
变 更 前 的 系 统 状
态无法及时恢复。
等级保护-系统运维管理-变更管理：
d) 应建立中止变更并从失败变更中恢复的文件化程序，明
确过程控制方法和人员职责，必要时对恢复过程进行演练。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面-开发并实施包括信息安全的连续性计划：
应开发并实施计划， 以确保在关键业务流程中断或失效
后能够在要求的时间内和要求的等级上保持和恢复运营并
确保信息的可用性。
序号 风险类别 风险点 控制目标 风险分析 参考依据
74
紧急变更
所有的应急变更都应该记录和
备份，包括变更前后的程序版
本与数据。应急变更应该由独
立的人员立即审核，以确保所
有的变更都是适当的。且不会
对生产环境产生不良影响。
应 急 需 求 得 不 到
及时响应；变更造
成 系 统 故 障 和 业
务中断问题，且无
法及时恢复。
等级保护-系统运维管理-变更管理：
c) 应建立变更控制的申报和审批文件化程序，变更影响分
析应文档化，记录变更实施过程，并妥善保存所有文档和
记录。
ISO27001-信息安全组织-内部组织-信息安全的独立评审：
应按计划的时间间隔或当发生重大的信息安全变化时，对
组织的信息安全管理方法及其实施情况（如，信息安全控
制目标、控制措施、策略、过程和程序）进行独立评审。
六、业务连续性管理
序号 风险类别 风险点 控制目标 风险分析 参考依据
75
业务连续性策略
经董事会或高管层批准的业务
连续性策略、标准和流程。
对 重 大 灾 害 缺 乏
足够的准备，导致
业务因火灾、台风、
地 震 等 不 可 抗 因
素 造 成 毁 灭 性 的
损失，直接威胁企
业的生存。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面 -在业务连续性管理过程中包含信息安全：
应在组织内开发并保持业务连续性管理过程， 该过程阐
明了组织的业务连续性对信息安全的要求。
76
高管层的
管理
管理组织
明确设立部门负责业务连续性
规划的整体流程管理。
缺 乏 有 效 的 组 织
者和领导者，在业
务 中 断 后 无 法 及
时 的 组 织 业 务 恢
复工作。
ISO27001-信息安全组织-内部组织-信息安全职责分配：
应明确规定所有的信息安全职责。
序号 风险类别 风险点 控制目标 风险分析 参考依据
77
独立的评估机制
独立部门对定期对业务连续性
计划进行评估；评估内容包含
业务连续性规划的有效性，以
及是否与本机构的策略和标准
相一致。
不 当 的 业 务 连 续
性 计 划 无 法 对 业
务 中 断 情 况 下 的
恢 复 进 行 有 效 指
导。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面-业务连续性和风险评估：
应识别可能导致业务过程中断的事故， 以及这类中断发
射给您的可能性和影响、 中断的信息安全后果。应定期测
试并更新 BCP，以确保 BCP 的更新和有效
78
业务影响分析
意外事件发生的场景和几率；
准确评估业务运行中断的可能
性及其影响。
对 风 险 的 估 计 错
误，导致投入与保
障失衡。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面-业务连续性和风险评估：
应识别可能导致业务过程中断的事故， 以及这类中断发
射给您的可能性和影响、 中断的信息安全后果。
79
业务恢复最低要
求
重要的业务和后台部门已制定
业务连续性规划最低要求，以
保证基本的业务和技术服务能
力。
业务中断后，无法
快 速 的 构 铸 业 务
运行环境，无法快
速 恢 复 业 务 系 统
运行。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面-开发并实施包括信息安全的连续性计划：
应开发并实施计划， 以确保在关键业务流程中断或失效
后能够在要求的时间内和要求的等级上保持和恢复运营并
确保信息的可用性。
80
规划分析
业务恢复的优先
级
启动业务连续性计划时不同业
务有明确的恢复顺序。
重 要 业 务 的 恢 复
的 延 迟 导 致 更 大
的损失。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面-业务连续性计划框架：
应保持一个单一的业务连续性计划框架， 以确保所有计
划的一致性， 以维护信息安全要求的一致性并识别测试
和保持的优先级。
ISO27002-业务连续性管理：
1）了解机构所面临的风险、风险发生的概率及影响，包括
定出哪些是重要的业务进程，并分出先后；
序号 风险类别 风险点 控制目标 风险分析 参考依据
81
处理措施分类
针对不同类型风险以及影响的
期限分别制定不同的处理措施。
对 风 险 的 估 计 错
误，导致投入与保
障失衡。
等级保护-系统运维管理-应急预案管理
a) 应在统一的应急预案框架下制定不同事件的应急预案，
应急预案框架应包括启动应急预案的条件、应急处理流程、
系统恢复流程和事后教育和培训等内容。
82
资源保障
人员、系统、财务和后勤等资
源的充分保障；有明确的获取
资源的渠道和方式，并评估灾
难对资源获取环节的影响。
业 务 恢 复 计 划 无
法实施。
GBT 20988-2007 信息系统灾难恢复规范-资源的获取方式：
数据备份系统；
备用数据处理系统；
备用网络系统；
备用基础设施等。
83
内容完整
性
联系沟通机制
与重要外部机构建立了正式的
联络沟通机制（如：监管部门、
投资者、客户、交易对手、商
业合作伙伴、服务提供商、新
闻媒体和其他股东等），对内部
机构的沟通联系机制（如：内
部员工、母公司、总部、分支
结构等）。业务连续性规划应明
确指定灾害期间的对外新闻发
言人，重要外部机构的电话号
码和电子邮件地址应被妥善管
理。
沟 通 不 畅 导 致 安
全 事 件 无 法 及 时
协调及处理，无法
得 到 内 部 和 外 部
的有效支持。
等级保护-安全管理机构-沟通和合作：
a) 应加强各类管理人员之间、组织内部机构之间以及信息
安全职能部门的合作与沟通，定期或不定期召开协调会议，
共同协助处理信息安全问题
b) 应加强与兄弟单位、公安机关、电信公司的合作与沟通
c) 应加强与供应商、业界专家、专业的安全公司、安全组
织的合作与沟通
d) 应建立外联单位联系列表，包括外联单位名称、合作内
容、联系人和联系方式等信息
ISO27001-信息安全组织-内部组织-与监管机构的联系：
应保持与相关监管机构的适当联系。
ISO27001-信息安全组织-内部组织-与特殊利益团体的联
系：
应保持与特殊利益团体或其他专业安全协会和行业协会的
适当联系。
序号 风险类别 风险点 控制目标 风险分析 参考依据
84
发布流程
业务连续性计划应得到高管层
认可并正式发布；重要岗位人
员应明确了解自身职责和需配
合人员的联络方式。
连 续 性 计 划 无 法
满业务需要。
ISO27001-管理职责-管理承诺：
管理层应通过以下措施对其建立、实施、运行、监视、评
审、保持和改进ISMS的承诺提供证据：
a) 建立信息安全方针；
b) 确保信息安全目标和计划的建立；
c) 为信息安全分配角色和职责。
85
业务连续性计划
的定期演练
建立有效的演练计划，并保障
实施。
计 划 的 有 效 性 得
不到验证和保障。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面- BCP 的测试、保持和再评估：
应定期测试并更新 BCP，以确保 BCP 的更新和有效。
86 演练与更
新
业务连续性计划
的更新
有明确的制度要求依据演练和
评估结果对业务连续性计划进
行更新，并确保内部人员、交
易对手、客户和服务提供商及
时得到更新。
计 划 的 适 用 性 不
能 及 时 有 效 的 完
善。
ISO27001-业务连续性管理-业务连续性管理的信息安全方
面-BCP 的测试、保持和再评估：
应定期测试并更新 BCP，以确保 BCP 的更新和有效。
七、外包
序号 风险类别 风险点 控制目标 风险分析 参考依据
87
外包管理 外包商的资质
考查服务商的设施和能力；财
务稳定性和专业经验；有能力
满足其履行监管、审计义务；
遵守内部规章制度。
外 包 程 序 和 数 据
的 安 全 性 得 不 到
有效的保障。
ISO27001-通讯及操作管理-第三方服务交付管理：
确保第三方实施、运行并保持第三方服务交付协议中包含
的安全控制、服务定义和交付等级。
序号 风险类别 风险点 控制目标 风险分析 参考依据
88
外包协议的完整
性
完整的技术传送、安全保密规
定；质量控制标准；整改升级
策略；重要部分分包控制。
重 要 生 产 数 据 有
泄漏的风险。
等级保护-应用安全-通信完整性：
a) 应采用校验码技术保证通信过程中数据的完整性；
等级保护-应用安全-通信保密性：
a) 在通信双方建立连接之前，应用系统利用密码技术进行
会话初始化验证；
b) 应对通信过程中的整个报文或会话过程进行加密。
89
对外包商的检测
评估
实施前对外包商的独立评估，
重要部分向监管部门报告；定
期对外包商进行检测评估。
不 能 及 早 发 现 并
避 免 潜 在 不 合 规
事件的发生。
ISO27001-信息系统的获取、开发和维护-开发和支持过程
的安全-软件委外开发：
组织应对软件委外开发进行监控；
ISO27001-通讯及操作管理-第三方服务交付管理：
应对服务和第三方提交的报告定期进行监视和评审，并定
期进行审核。
90
应急管理
制定正式的应急措施和退出管
理措施，防范外包商不能提供
服务的风险。
导 致 项 目 的 成 本
的增加，直接影响
工程进度。
ISO27001-通讯及操作管理-第三方服务交付管理-管理第
三方服务的变更：
应管理服务提供的变更（包括包括保持和改进现有信息安
全方针、程序和控制措施），考虑对业务系统的关键程度、
涉及的过程和风险的再评估。
八、内部审计和外部审计
序号 风险类别 风险点 控制目标 风险分析 参考依据
91
内部审计 内部审计的责任
制定、实施和维护审计计划，
执行信息科技的专项审计，提
出整改建议并检查是否得到落
实。
操 作 失 误 无 法 追
查责任，操作无法
严格执行。
ISO27001-信息系统审核的考虑因素-信息系统审核控制：
应谨慎策划对操作系统检查所涉及的审核要求和活动并获
得许可，以最小化对业务过程的影响或风险
序号 风险类别 风险点 控制目标 风险分析 参考依据
92
内部审计频率
依据风险高低决定内部审计频
率；至少每三年进行一次全面
审计。
风 险 不 能 及 时 发
现 并 采 取 适 当 措
施控制。
等级保护-安全管理机构-审核和检查：
b) 应由内部人员或上级单位定期进行全面安全检查，检查
内容包括现有安全技术措施的有效性、安全配置与安全策
略的一致性、安全管理制度的执行情况等
93
工作配合
提供必要的数据和材料，保证
信息科技审计服务商能够充分、
及时而准确地揭示信息科技存
在的风险。
不 能 保 证 审 计 的
客观性和全面性，
导 致 风 险 不 能 被
准确的评估，影响
业务的正常运作。
Corbit 信息技术审计指南-质量保证的责任：
管理层应为IT职能部门的成员分配质量保证职能履行的责
任，并确保适当的质量保证、系统、控制和
存在于IT职能质量保证小组中的专家们的交流。IT职能内
机构的布置以及质量保证小组的职责和规模应
满足机构的需求。
94
外部审计
保密协议
与信息科技审计服务商签订保
密协议，并督促其严格遵守法
律法规，保守本银行的商业秘
密和信息科技风险信息，防止
其擅自对本银行提供的任何文
件进行修改、复制或带离现场。
重 要 数 据 或 安 全
弱点泄漏，直接导
致 安 全 事 件 的 发
生。
ISO27001-符合性-信息系统审核的考虑因素：
应谨慎策划对操作系统检查所涉及的审核要求和活动并获
得许可， 以最小化对业务过程的影响或风险。
填报说明：
1、 风险评估等级：I：已完善，完全符合风险控制目标要求。
II：基本完善，某些方面存在遗漏，但风险基本可控。
III：已采取相关措施，但存在较大漏洞，存在风险较大或未进行评估。
IV：未采取风险控制措施。
V：经评估，该风险控制要求不适用于银行实际情况。
2、 具体做法应简要填写风险控制方法、实施步骤，或填写相关文件名称及发布日期。
