Copyright by CHENYL
信息科技风险监管知识讲座
2010 年 8 月
主要内容
一、信息科技风险监管概况
二、信息科技风险监管目标和手段
三、主要监管制度介绍
四、信息科技风险监管体系简介
五、基层银行机构科技风险监管的思考
一、信息科技风险监管概况
信息科风险监管背景
某银行核心系统
故障全国中断营
业4小时
某行海南分
行供电中断
导致停业
小时
2006年银联
跨行交易全
面中断8小时
屡次发生的网络安
全事件：
2010年 初多家银行
网银系统遭受攻击
2009年底我省某行
网银系统遭受DDos
攻击
2009年底某行成都
分行发生网银客户
资金被盗事件
2008年奥运开幕式
某国有银行网络遭
攻击
….
….
2006 2008 2010
•近年来，随着银行机构系统网络化、数据集中化，科技风险问题日益突出
•科技风险的特点是风险变化快、蔓延快、影响范围大
银监会信息科技监管历程
2006 2007 2008 2009 2010
•发布信息科技风险管理指引
•开展信息科技风险内部和外
部评价审计
•开展信息科技风险奥运专项自查
•发布新的《商业银行信息科技风险管理指引》
•《银行业重要信息系统投产与变更管理办法》
• 部署信息科技风险非现场系统
•《商业银行数据中心监管指引》
自2006年8月发布《银行业金融机构信息系统风险管理指引》开始，
银监会正式对银行科技风险进行监管，近年来推出一系列制度和措施，
监管工作逐步走向规范化。
银监会开展的主要工作
制定一系列制度和标准
持续开展信息科技风险监管培训
组织开展信息科技风险现场检查
推动实施信息科技非现场监管
组织开展重要时点信息科技自查整改
及时发布各类信息科技风险提示
银行机构信息科技风险状况
科技风险管控意识提高
科技治理架构初步建立
科技基础设施不断完善
运行维护能力不断加强
重视加强灾备建设及开展应急演练
银行机构信息科技风险状况
个别银行科技治理认识不到位
重眼前建设轻长远规划
科技治理架构未有效运行
应急演练开展实战性不足
基层银行机构科技力量薄弱
二、信息科技风险监管目标与手段
信息科技风险监管目标
降低信息系统连续性和
安全性风险程度到可接受范围
保障信息系统连续性和安全性
保护银行信息资产（信息系统、数据）
保护存款人利益
维护社会稳定
信息科技风险监管目标
连续性：
即业务连续性，保证信息系统稳定、持续地提供服务，
通俗地说就是系统“不能断”。
安全性：
保证数据的保密性、完整性、可用性，通俗地说就是
数据“不能丢”。
所有科技风险事件都可以归于信息系统连续性
或安全性出问题的事件。
信息科技风险监管目标
连续性事件案例
案例1：2008年11月上旬，某大型银行某省分行在供电部门预先通
知停电的情况下，因发电机故障、主机存储控制卡损坏等原因，
造成全省业务无法正常运营达7小时15分钟。
案例2：2009年12月21日，某行网上银行系统发生一起因DDOS攻击
引发的系统故障，经内外部专家诊断为外部分布式攻击。攻击来
自互联网多个地方和多台机器，持续时间500分钟。故障刚发生阶
段的现象表现为网银客户登录网银主页面缓慢或超时无法访问。
监控系统显示网上银行主页服务器系统资源压力迅速增大，进程
达到系统最大进程数，超过日常监控进程数四倍。
案例3：2010年2月3日某全国性银行核心业务系统数据库故障导致
全国柜面等各项业务中断近四小时。
案例4：2007年12月16日11：05至13：57，某分行综合前置机系统
出现故障，造成全辖15个网点对外营业中断近三个小时。
信息科技风险监管目标
安全性事件案例
案例1：2008年12月31日至2009年1月4日，某银行成都分行发生一
起网上银行客户资金被盗案件，涉及被盗帐号12个，总金额12万
元。犯罪嫌疑人通过本人及雇用他人在银行办理借记卡并开通个
人网银业务，以合法身份进入该银行大众版网银系统，然后利用
网络下载的黑客软件对该银行大众版网银系统进行攻击和破译，
发现漏洞后作案。犯罪嫌疑人利用网银客户端交易数据包未对转
出卡号、转入帐号客户隶属关系进行校验，而且主机系统对网银
服务端上传的个别交易数据验证不充分的程序逻辑缺陷，通过模
拟浏览器与服务端通讯的方式，非法截取并篡改交易数据，盗取
他人资金。
信息科技风险监管目标
安全性事件案例
案例2：某行市分行发生一起内部员工违规利用网银动
用客户资金的案件。2008年10月份，支行客户部网银
操作员及复核员在为客户办理网银业务时发现操作IC
卡已经过期，遂联系市分行网银管理员黄某办理换卡
事宜，并告知其操作密码。黄某利用自己作为管理员
保管“管理证书”之便，进入系统，修改了某对公客
户的网银证书和密码，再通过集团理财帐户实行网银
转帐，动用客户帐户上万元用于炒权证。
案例3：某行柜员在为客户办理购买基金手续过程中,
利用电脑终端画面可以屏幕打印功能,没有进行实际交
易,套打基金交易凭证交予客户,将客户资金转入其控
制的账户.涉案金额85万元。电脑终端可随意进行屏幕
打印,存在明显缺陷,使作案人有机可乘
信息科技风险监管目标
安全性事件案例
案例4：近期，某银行机构发现不法分子根据互联网上下载的“特
征码识别程序”自行编写密码猜解软件，通过锁定某一固定密码
反复轮训帐号的方式，对多家银行网银系统发起暴力猜测攻击，
最终非法获取两家银行数百个客户的网银帐号、查询密码等信息。
案例5：近期，某银行机构发现不法分子根据互联网上下载的“特
征码识别程序”自行编写密码猜解软件，通过锁定某一固定密码
反复轮训帐号的方式，对多家银行网银系统发起暴力猜测攻击，
最终非法获取两家银行数百个客户的网银帐号。
案例6 ：某行借记卡被通过手机银行猜解密码，涉及1007张借记卡。
信息科技风险监管目标
如何判断是否达到目标？
信息科技风险（包括连续性和安全性风险）的计量
判断信息科技风险程度是否在可接受范围
基本概念
资产
对组织具有价值的信息或资源，是安全策略保护的对象。主要
包括：
——支持设施（例如建筑、供电、供水、空调等）
——硬件资产（例如计算机设备、路由交换机、交换机等）
——信息资产（例如数据库和数据文档、系统文件、用户
手册、培训资料、操作和支持程序等）
——软件资产（例如应用软件、系统软件、开发工具和使
用程序等）
——生产能力或服务能力
——人员
——无形资产（例如信誉、形象等）
——其他
（参照：1、信息安全风险评估规范P1；2、信息系统安全管理要求
P53）
基本概念
资产价值
资产的重要程度或敏感程度的表征。资产价值是资
产的属性，也是进行资产识别的主要内容。
（出处：1、信息安全风险评估规范P1）
基本概念
威胁
可能导致对系统或组织危害的不希望事故的潜在
起因。
威胁的分类可按照造成威胁的因素分为人为因素
威胁和环境因素威胁，按照威胁的表现形式可以
分为软硬件故障、物理环境影响、无作为或操作
失误、管理不倒位、恶意代码、越权或滥用、网
络攻击、物理攻击、泄密、篡改、抵赖等。
（出处：1、信息安全风险评估规范P2、P9）
基本概念
脆弱性
可能被威胁所利用的资产或若干资产的薄弱环节。
资产的脆弱性包括物理布局、组织、规程、人事、
管理 、行政、硬件、软件或信息等的弱点。
（出处：1、信息安全风险评估规范P3；2、信息系统安全管理
要求P54）
基本概念
安全措施
保护资产、抵御威胁、减少脆弱性、降低
安全事件的影响，以及打击信息犯罪而实
施的各种实践、规程和机制。
（出处：1、信息安全风险评估规范P2）
基本概念
剩余风险
采取了安全措施后，信息系统仍然可能存在的风
险。
（出处：1、信息安全风险评估规范3）
基本概念
风险的计量
人为或自然的威胁利用信息系统及其管理体系中存在的脆
弱性导致安全事件的发生及其对组织造成的影响。
风险值=R(A,T,V)=R(安全事件可能性,安全事件造成的损失
)
A——资产
T——威胁
V——脆弱性
安全事件的可能性 = L（T，V）= L（威胁出现频率，脆弱
性）
安全事件造成的损失 = F（Ia，Va）=（资产价值，脆弱性
严重程度）
风险计量原理图
威胁识别
脆弱性识别
资产识别
脆弱性的严重程度
威胁出现的频率
资产价值
安全事件造成的损失
安全事件的可能性
风险值
信息科技风险要素关系图
信息科技风险监管目标
如何判断信息科技风险程度是否在可接受范围
？
计量当前信息科技风险程度
计量最低信息科技风险程度
• 依据：
– 国家规范
– 银监会制度法规
– 行业标准
– 自身接受程度（投入成本<=损失成本）
比较当前信息科技风险程度和最低信息科技风险程度
基本概念
风险评估
资产识别 威胁识别 脆弱性识别 已有安全措施确认
人员 病毒 病情 预防措施
信息安全风险评估
人员健康查体检
风险管理实施流程图
风险评估准备
威胁识别资产识别 脆弱性识别
已有安全措施的确认
风险计算
风险是否接受
制定风险处理计划
并评估残余风险
是否接受残余风险
实施风险管理
保持已有的安全措施
评估过程文档
评估过程文档
评估过程文档是
否
风险评估文档记录
风险分析
否
…
…
信息科技风险管理/监管手段
银行机构
治理层面
• 明确董事会职责、成立信息科技风险管理委员会
• 建立科技风险三道防线（科技、风险、审计部门）
• 制定全行信息科技风险管理战略规划
管理层面
• 科技部门
• 风险部门
• 审计部门
具体手段
信息科技风险管理/监管手段
银行机构
保护系统连续性和安全性的具体手段：
• 基础设施建设（机房、网络、主机）
–灾备中心
–双机热备
–双运营上线路
• 信息安全防护体系
–防火墙、IPS
–桌面管理系统
• 日常系统运行监控
• 项目开发、外包过程管理
• 应急管理（应急预案、应急保障、应急演练）
信息科技风险管理/监管手段
监管部门
制度标准制定
非现场监管和现场检查
准入审核及机构评级
• 荷兰央行：银行执照、人员任免、计提资本、罚款
组织协调、促进资源共享
三、主要监管制度介绍
主要监管制度介绍
银监会拟发布制度
《银监会行政许可事项中信息科技核准条件的补
充规定》和《银行业金融机构重要信息系统投产
及变更管理办法》
《商业银行首席信息官管理办法》
1、《商业银行信息科技风险管理指引》
信息科技风险管理
信息科技治理
信息科技审计
业务持续性管理
信息安全管理 信息科技运行
项目开发、
测试
外包管理
主要概念：
信息科技风险
• 是指信息科技在商业银行运用过程中，由于自然因素、人为因素、技术漏洞
和管理缺陷产生的操作、法律和声誉风险。
——《商业银行信息科技风险管理指引》第四条
信息科技风险与操作风险的关系——莆田网银案件
信息科技风险管理的目标
• 是通过建立有效的机制，实现对商业银行信息科技风险的识别、计量、监测
和控制，促进银行安全、持续、稳健运行，推动业务创新，提高信息技术使
用水平，增强核心竞争力和可持续发展能力。
——《商业银行信息科技风险管理指引》第五条
三道防线
• 信息科技风险管理的关键是要建立三道防线，第一道防线是指信息科技管理，
需要全员参与，主要职责落在科技部门，第二道防线是风险管理，即从风险
的角度如何防范，职责落在风险部门，第三道防线是审计监督，即内审和外
审，职责落在审计部门，三道防线相互作用，形成立体防护网。
1、《商业银行信息科技风险管理指引》
要点：
信息科技治理
• 明确商业银行董事会职责
• 要求设立首席信息官，明确了首席信息官职责
• 明确三道防线要求：明确信息科技管理、信息科技风险管理、信息科
技审计的责任部门和职责内容
• 风险管理部门职责：
– 将科技风险纳入总体风险管理体系
– 负责制定信息科技风险管理策略
– 负责持续开展信息科技风险识别、监测、计量、评估
– 根据风险评估结果制定风险防范措施
• 审计部门职责：
– 组织开展内部和外部审计
– 要求配备具有专业能力的信息科技审计人员独立开展审计
– 至少每三年开展一次全面审计
1、《商业银行信息科技风险管理指引》
要点：
业务连续性管理
• 制定业务连续性规划，确保在出现无法预见的中断时，系统仍能持续
运行并提供服务。
• 业务影响分析：人员、系统或其他资产的故障或缺失，信息丢失、战
争、台风、地震
• 采取双机热备、制定应急计划、购买商业保险
1、《商业银行信息科技风险管理指引》
要点：
项目开发、测试管理
• 开发环境和生产环境物理隔离
• 禁止开发和维护人员随意进入生产系统
• 组织开展系统上线后评价
外包管理
• 重要外包报告
• 外包风险评估
• 服务水平协议
• 安全保密要求（包含敏感客户信息）
• 应急措施
1、《商业银行信息科技风险管理指引》
要点：
系统运行管理
• 制定详细的运行操作说明
• 系统运行监控
• 容量规划
• 变更管理
• 事件管理
信息安全管理
• 安全策略（物理安全、人员安全、访问控制、数据加密等）
• 活动日志保存（交易日志、系统日志）
1、《商业银行信息科技风险管理指引》
2、《银行业重要信息系统突发事件应急管理规范
（试行）》
作用：
规范并促进了银行业金融机构做好重要信息系统突发事件应急管理，提
高对突发事件的综合管理能力和应急处置能力。
主要概念
重要信息系统：指支撑银行业金融机构关键业务，其信息安全和系统服
务安全关系公民、法人和组织权益或社会秩序和公共利益，甚至影响国
家安全的信息系统
要点：
明确定义了董事会及高管层、风险管理部门、信息科技管理部门和业务
管理部门在突发事件中的职责要求，明确了应急领导小组、应急执行小
组、应急保障小组的职责分工
对突发事件进行分级定义，将突发事件按照影响范围和持续时间分为特
别重大突发事件（两个以上省业务中断超过3小时或一个省超过6小时）、
重大突发事件（两个以上省业务中断半小时或一个省超3小时）、交大突
发事件（一个省业务中断超半小时）三个级别
2、《银行业重要信息系统突发事件应急管理规范
（试行）》
要点：
要求银行机构建立信息科技风险防范体系，制定信息系统RTO（最短恢
复时间目标）、RPO（最近恢复点目标）指标
2、《银行业重要信息系统突发事件应急管理规范
（试行）》
正常处理 初始响应 激活 恢复流程 积压业务 正常处理
最
近
备
份
备份 备份
恢
复
结
束
目标恢复点
事件
在成功恢复之前，
数据可能会遗失、
损坏、或无法获取
目标恢复阶段
（RTO）
处理间隙：位于损
坏点与恢复正常处理
之间的滞后时间段
灾难声明
2、《银行业重要信息系统突发事件应急管理规范
（试行）》
要点：
对信息科技风险识别、评估、监测、预警的各个环节提出了具体要求
对银行机构制定应急预案、开展应急演练、应急响应及报告机制、日常
应急保障等应急管理内容提出了具体要求。 重要突发事件发生后60分钟
内将情况报监管部门、12小时内提交正式报告、一级事件每两小时报告
进展
3、《银行业重要信息系统投产与变更管理办法》
概念
重要信息系统：指支撑银行业金融机构关键业务，其信息安全和系统服
务安全关系公民、法人和组织权益或社会秩序和公共利益，甚至影响国
家安全的信息系统
投产和变更内容：支撑重要信息系统运行的机房、网络设施投产、机房
场地迁移、网络及核心业务系统应用架构变更、核心业务系统版本变更
等。
要点
加强和规范银行机构信息系统投产和变更管理，避免系统投产或
变更过程造成业务中断或数据丢失情况
重要信息系统投产前至少20个工作日、变更前至少10个工作日向
监管部门报告，实施后1个月内提交投产或变更情况报告
4、《商业银行数据中心监管指引》
概念
数据中心：生产中心和灾备中心
灾备中心：商业银行为保障业务连续性，在生产中心故障、听短或瘫痪
后，能够接替生产中心运行，具备专用场所、进行数据处理和支持重要
业务持续运行的组织。
同城灾备中心：同一地理区域，一般距离数十公里，可防火灾、建筑物
破坏、电力或通信中断
异地灾备中心：不同地理区域、距离数百公里以上，不会同是面临地震、
台风、洪水等同类灾难风险。
要求：
总资产1千亿元人民币且跨省经营的法人银行及省级农信社要建立异地灾
备中心，灾难恢复等级达到5级以上，其他法人银行应设立同城灾备中心
并实现数据异地备份，灾难恢复等级达到4级以上。
正式运营前至少20个工作日向监管部门报告，变更数据中心场所要提前2
月报告
对数据中心选址、基本配置提出明确要求
灾难恢复等级达到5级
灾难恢复等级达到5级：数据实施备份，4级：数据定期备份
4、《商业银行数据中心监管指引》
灾难恢复等级达到4级：电子传输及完整设备支持，数据
定期备份
灾难恢复等级达到5级：实时数据传输及完整设备支持，
数据实施备份
灾难恢复等级达到5级：数据零丢失和远程集群支持。
5、《银行业金融机构信息系统安全保障问责方案》
要点
要求法人银行机构签署信息系统安全保障责任书，明
确高管人员对信息系统安全保障的管理责任
对管理失职造成不良后果的，追究责任
6、《银行业金融机构信息科技非现场监管报表》
要点：
明确信息科技风险部门为报送责任部门
包括1份年度报告、14张年度报表、6张季度报表、7张实时报表
7、《商业银行信息科技风险现场检查指南》
要点
明确了商业银行目前主要的信息科技风险领域、主要风险点，阐
明了检查思路和主要方法，帮助检查人员明确检查目标，从而提
高信息科技风险现场检查的有效性和针对性，提升现场检查质量。
提供评价银行信息科技风险管理各领域状况的参考标准，并提出
了具体的检查要求和步骤，进一步规范了信息科技风险现场检查
的程序、手段和行为，是银监会及各级派出机构实施现场检查工
作的一个重要参考依据和检查指导工具。
指明商业银行信息科技风险防控的重点领域、方向和关键风险点，
提出了风险识别、预警和控制的具体手段，商业银行可以充分借
鉴《指南》内的信息科技风险防控原则和指导思想，应用到银行
信息科技建设和管理实践中，成为指导银行全面开展科技风险防
控、提升管理能力的有力武器。
四、信息科技风险监管架构
信息科技风险监管体系
信息科技风险
监管年度计划
数据采集
与审核
信息科技风险
分析与评估
信息科技风险
现场检查
信息科技
风险监测
风险提示、
预警
及应急处理
年度信息科技
监管评级
年度信息科技
监管报告
体系概述—总体框架
固有风险 - 控制有效性 = 剩余风险
固有风险指标 控制有效性指标
信息科技综合风险水平
信息科技风险评估指标
固有风险水平 控制有效性
风险评估流程方法
体系概述—剩余风险综合分析矩阵
剩余风险
控制有效性
强 中强 中弱 弱
固
有
风
险
高 三级 四级 五级 六级
中高 二级 三级 四级 五级
中低 一级 二级 三级 四级
低 一级 一级 二级 三级
体系概述—基础定义
《体系》基础定义：
【固有风险】是指在不考虑内部控制结构的前提下，由于内部因素和客观环境的影
响，经营运作可能发生重大错误的风险。
【信息科技固有风险】是固有风险的重要组成部分，特指机构在运用信息技术的运
用过程中所面对的固有风险。信息科技固有风险可以通过获取相关信息进行衡量和
评价，其识别与评估是一个全面信息收集与综合分析研判的过程。
【控制有效性】是指机构所采用的信息科技风险控制措施的设计与执行效果满足监
管机构和信息科技风险管理要求的程度。
【风险评估】是通过对信息科技风险种类、风险程度和风险发展趋势进行识别分析，
对信息科技的风险状况、风险管理的充分性以及外部风险因素的影响做出判断，并
在此基础上对机构的整体风险水平做出评估。
体系概述—数据关系
风险评估指标
非现场监管报表
其
他
监
管
干
预
现场检查结果
风险
评估
监管评级
现场检查
结
果
结
果
结果
指标体系—固有风险指标
重要信息系统
数据中心运行
与灾备
信息科技项目
信息科技
服务外包
系统恢复及
数据保护
监管关注度
信息科技信息科技
固有风险指标固有风险指标
固有风险 子领域
指标体系—固有风险指标
重要信息系统子领域 风险成因
重要信息系统
核心业务系统替换后影响未消除，导致业务
无法正常运行。
重要信息系统重大变动影响业务正常运行。
重要信息系统复杂程度高，存在安全性和完
整性问题。
关键信息系统缺乏稳定性以致影响业务正常
运行。
指标体系—固有风险指标
数据中心运行
与灾备子领域
风险成因
数据中心运行
与灾备
数据中心的重大变动对信息科技正常运行产
生不利影响。
数据中心与灾备中心（场所）地理位置分布
对机构应对灾难产生不利影响。
公共基础设施（电力、电信、交通、机房建
筑等）服务中断、异常，对机构业务持续运
行产生不利影响。
指标体系—固有风险指标
系统恢复及
数据保护子领域
风险成因
系统恢复及
数据保护
除负责本机构系统恢复外，机构还提供对外部
机构共享本机构系统恢复设施的服务。本机构
系统恢复设施的失效可能影响对方的系统恢复，
增加本机构在经济责任、法律及声誉等方面的
风险。
本机构系统恢复依赖于外部机构的恢复设施，
外部机构系统恢复设施的失效可能影响本机构
的系统恢复。
仍在使用已过时或缺乏厂商技术支持的系统恢
复设施或技术。
生产数据脱离生产环境进入办公环境或互联网
环境。例如，基于数据仓库技术的商业智能系
统的运用。其数据基础源自生产数据。
外部机构拥有或分享本机构生产数据的控制权，
例如：监管要求、审计需要、外包等。
指标体系—固有风险指标
信息科技项目子领域 风险成因
信息科技项目
项目变动不可避免，若变动频繁、随意性大，
可能导致项目目标无法按要求实现。
项目规模及复杂度难以驾驭。
项目资源不足使项目难以按时、按质完成，进
而影响业务目标的实现。
指标体系—固有风险指标
信息科技服务
外包子领域
风险成因
信息科技服务外包
外包人员变动导致外包服务持续性受影响，导
致服务质量下降、进度拖延等可能性。
过度依赖外包商，导致出现“太依赖而不能替
换的外包商”。
外包商完全位于境外或。外包商性质及提供服
务的形式对机构的可能影响。如：境外外包商，
外包商采用非授权工具提供服务，外包商常驻
机构与其内部员工共同进行现场作业等。
指标体系—固有风险指标
监管关注度子领域 风险成因
监管关注度
规模（资产规模、网点规模、电子银行用户）。
信息科技支持能力应与机构规模相适应，并在一
定时期内能够持续满足对网点规模增长的需求）
业务量。业务量是机构信息系统所承载交易压力
的直接体现。
信息科技风险历史记录。重点关注以往重大信息
系统突发事件情况、信息科技人员涉案情况等。
指标体系—控制有效性指标
信息科技治理
控制有效性控制有效性
指标指标
控制有效性 子领域
信息科技风险管理
信息系统开发、测试与维护
信息科技审计
灾难恢复与应急管理
信息科技外包
信息安全（一般控制）
信息科技运行
指标体系—控制有效性指标
信息科技治理子领域 关键要素
信息科技治理
是否具有信息科技治理领导力？（或信息科技在
高管层中的地位如何）？
信息科技战略能否有效支持业务目标？
信息科技未得到足够的财务支持？
信息科技治理职能与责任划分是否明确、合理？
信息科技治理执行力如何？
信息科技治理是否与企业治理兼容？
指标体系—控制有效性指标
信息科技风险管理
子领域
关键要素
信息科技风险管理
风险容忍度？
风险管理流程是否完整？（应包括：识别风险、
评估风险、控制风险、监测风险、预警风险）
风险管理是否有效运作？主要体现在风险根源分
析机制持续运作？
信息科技风险管理与业务风险管理的关系是否理
顺？
风险控制措施是否有效覆盖被识别的风险点？
是否有足够的专业人才开展风险管理工作？
风险意识持续培养？
指标体系—控制有效性指标
信息科技审计
子领域
关键要素
信息科技审计
信息科技审计部门及人员的独立性如何？
信息科技审计部门与人员是否合理授权？
信息科技审计人员的专业性如何？
审计发现整改率？
审计分支机构覆盖率？
是否建立信息系统的应用控制及审计方法？
指标体系—控制有效性指标
信息系统开发、测试与维护
子领域
关键要素
信息系统开发、
测试与维护
有无项目管理组织统一安排、协调各类项目？
如何保障项目质量？
有无项目财务管理和监督？
开发、测试环境的管理？
项目的设计阶段是否充分考虑了信息安全、保密、
灾难恢复等需求？
项目结束后是否进行业务价值评价和审计？
指标体系—控制有效性指标
信息科技运行子领域 关键要素
信息科技运行
运行操作岗位设置是否合理？
事件管理如何？
问题管理如何？
可用性管理如何？
容量管理如何？
变更与维护管理如何？
运行过程监控如何？
指标体系—控制有效性指标
灾难恢复与应急管理子领域 关键要素
灾难恢复与应急管理
灾难恢复计划或应急预案的演练与更新情况？
重要信息系统灾难恢复计划覆盖率？
重要信息系统应急预案覆盖率？
指标体系—控制有效性指标
外包子领域 关键要素
外包
有无外包商资质、服务水平的考核指标？
如何选择正确的外包服务商？
如何防止外包人员接触生产数据或敏感信息？
外包合同是否经法规或审计部门审核？
有无可迅速替换的外包商？
指标体系—控制有效性指标
信息安全管理子领域 关键要素
信息安全管理
信息资产普查与分级？
跨部门协调的信息安全执行组织 ？
物理安全？
物理访问控制？
逻辑访问控制？
版本管理？
配置管理？
日志管理？
网络管理？
数据安全？
评估指标
定量指标定量指标7474
个个
固有风险： 23个
监管关注度： 9个
控制有效性：42个
定性指标定性指标9090
个个
固有风险： 10个(手工2个)
控制有效性：80个(手工8个)
固有风险： 33
个
监管关注度： 9
个
控制有效性：122
个
指标合计指标合计164164个个
基本思想
自动化自动化 自动抽得指标结果、自动评分、自动汇总、自
动分级
灵活性灵活性
标准化标准化
审核标准规范化、评分规则标准化、参数标准
化
得分可调整、结果可调整、参数调节因子
评估流程
综合
风险
水平
非现场
监管报
表
监管
人员
评判
调整
指标
得分
系统
自动
生成
指标
得分
监管关注
度调节因
子
固有风险
分级结果
控制有效
性分级结
果
生
成
后续监管工作
参数值
监管关注
度调节因
子
固有风险
分级结果
控制有效
性分级结
果
抽
取
评估打分表示例
指标分值及意义
固有风险固有风险 5分制，分值越高，固有风险越高
控制有效性控制有效性
监管关注度监管关注度 5分制，分值越高，关注度越高
5分制，分值越高，控制有效性越强
参数表
参数值参数值
参数值=行业基准值×参数调节因子
行业基准值：行业平均值或手工设定的经验值
参数调节因子：用于调整行业基准值的因子，可根据评估结
果进行手动调节
行业平均值行业平均值
1.全行业
2.按资产规模分三类：大、中、小，划分标准可调整
3.按机构类型分七类：政策性银行、国有商业银行及邮政储蓄
银行、股份制商业银行、城市商业银行及城市信用社、省联社
及农村商业银行、农村合作银行及农村信用社、外资法人商业
银行
参数值参数值
行业平均值行业平均值
参数值参数值
行业平均值行业平均值
行业平均值行业平均值
使用行业固定值时，调节因子通常设为1；
固有风险指标的参数调节因子设为时，平均值相当于
得70分（中低上限）；
监管关注度指标的调节因子设为时，平均值相当于得
75分（监管关注度调节因子下限）；
控制有效的指标的调节因子为时，平均值得70分（中
弱上限）。
行业平均值行业平均值参数调节因子参数调节因子
统一维护，生效
后才能评分
固有风险评分流程
指标评
分
关键风险因素评分
子领域评分
• 关键风险因素得分=∑(指标得分/5*指标分
值)
• 子领域得分=∑关键风险因素得分
固有风险评分 • 固有风险得分=∑(子领域得分*子领域权值)
• 5分制，先系统自动评分，再人工调整
固有风险评分固有风险评分
固有风险评估示例
监管关注度评分流程
监管关注度指标评
分
监管关注度评
分
监管关注度调节因子
• 监管关注度得分<=60时， 调节因子
=；
60<监管关注度得分<=75时， 调节因子=
；
75<监管关注度得分<=90时， 调节因子=
；
90<监管关注度得分<=100时，调节因子
=;
• 5分制，先系统自动评分，再人工调整
• 监管关注度得分=∑(指标得分/5*指标分值)
固有风险调整后得分= 固有风险得分×监管关注度调节因
子
监管关注度评分监管关注度评分
固有风险调整固有风险调整
固有风险评估分级
固有风险分级
低： (0<固有风险调整后得分<=50)
中低：(50<固有风险调整后得分<=70)
中高：(70<固有风险调整后得分<=90)
高： (90<固有风险调整后得分<=100)
控制有效性评估分级
控制有效性分级
弱： (0<控制有效性得分<=50)
中弱：(50<控制有效性得分<=70)
中强：(70<控制有效性得分<=90)
强： (90<控制有效性得分<=100)
综合风险水平
综合风险
水平
1级
1 级
1级
2 级
1级
3 级
1级
4 级
1级
5 级
1级
6 级
固有风险
低
中低
中高
高
控制有效性
强
中强
中弱
弱
综合评估矩阵
综合风险
水平
控制有效性
强 中强 中弱 弱
固
有
风
险
高 三级 四级 五级 六级
中高 二级 三级 四级 五级
中低 一级 二级 三级 四级
低 一级 一级 二级 三级
综合风险水平
控制有效性
强 中强 中弱 弱
固
有
风
险
高 中高 中高 高 高
中高 中低 中低 中高 高
中低 低 中低 中高 中高
低 低 低 中低 中低
综合评估矩阵
综合评估卡
综合评估结论
综合评估结果调综合评估结果调
整整
•综合考虑固有风险水平、控制有效性、风险发展
趋势、极端评估指标和领域、监管经验及机构实
际情况
•遵循“风险多监管、低风险少监管”的原则
•对信息科技风险水平、监管意见进行描述
•对固有风险较高的领域和控制有效性较弱的领域
进行简要描述
综合评估结论综合评估结论
•对信息科技风险水平、监管意见进行描述
•对固有风险较高的领域和控制有效性较弱的领域
进行简要描述
综合评估结论综合评估结论
评估结果运用
掌握风险状况掌握风险状况
识别、判断机构的风险状况和严重程度
（生成报表）
实施分类监管实施分类监管
明确监管重点明确监管重点 明确非现场监管、现场检查的频率和范围
针对性地采取监管措施，提高监管有效性
五、基层银行机构科技风险监管的思考
基层银行机构科技风险监管的思考
基层银行机构科技管理的特点
• 分支机构为主
• 数据上收
• 科技人员少
• 操作风险事件多发
基层银行机构科技监管的目标
• 连续性
• 安全性
基层银行机构科技风险监管的思考
基层银行机构科技监管的内容
• 开展调查，摸清全辖银行机构科技风险管理情况
• 建立联系人制度
• 定期收集评估银行机构科技运行情况
• 开展信息科技风险现场检查
• 督促银行落实银监会各项监管要求（报告制度等）
• 组织开展银行机构信息科技管理横向交流
现场检查的方式内容
• 功能监管和机构监管结合
• 操作风险和科技风险兼顾
• 现场检查的重点：
总结
信息科技风险监管概貌了解
目标：连续性和安全性 手段：银行/监管部门
主要制度依据
信息科技风险监管体系
基层银行机构信息科技风险监管
基层银行机构科技风险监管的思考
现场检查的内容：
• 从常见问题、薄弱环节入手
– 高管意识
– 环境安全
– 内控管理
» 科技人员道德风险
» 操作风险（初始密码管理、代发工资卡）
– 应急管理
Copyright by CHENYL
