浅谈中小金融机构信息科技风险审计中常见的误区

更新时间:2023-11-05 19:15:01 阅读量: 综合文库 文档下载

说明:文章内容仅供预览,部分内容可能不全。下载后的文档,内容与下面显示的完全一致。下载之前请确认下面内容是否您想要的,是否完整无缺。

浅析中小金融机构信息科技 安全管理中常见的理念误区

随着银行信息化的高速发展,数据形成了高度集中的趋势,风险也随之高度集中,因此信息科技安全所形成的现代金融风险,使传统的金融风险内涵发生了根本性变化。从2006年起,银监会高度重视信息科技安全,先后出台了《银行业金融机构信息系统风险管理指引》、《商业银行信息科技风险管理指引》等相关制度,逐步引导中小金融机构加强对信息科技安全管理工作,并提出内、外部审计部门介入信息科技安全审计的理念和要求。如今,银监会《商业银行信息科技风险管理指引》(以下简称《指引》)成为国内商业银行IT治理的指导性文件,该文明确了监管机构对于信息科技治理的监管要求,详细阐明了商业银行各级管理部门对本机构信息科技管理的职责。中小金融机构在这些年的摸索中也逐步完善信息科技安全管理体系,但与国外银行、大型商业银行相比,由于人力、物力、财力等主、客观因素的影响,中小金融机构信息科技安全管理工作还任重道远。下面,本人结合几年来信息科技安全审计工作的实践与思考,谈谈中小金融机构信息科技安全管理中常见的理念误区并尝试作个剖析。

一、治理方面的误区

信息科技风险是高管及科技部门的事;信息科技风险审计必须是专业的技术人员才做得了;信息科技风险的第二、三道防线

1

根本是空谈。

现象:这种理念误区所形成的结果是高管虽然重视,但停留于文件、工作布置层面,并未深入工作的实施和落实,高管对于信息科技风险认识不到位,风险点并不知悉。而各职能部门对科技风险的认识更是在涉及到部门利益或关联到部门协调时才会去认真对待,平常则是视见非见、视闻非闻,将信息科技风险交由科技部门去把控,文件会签、成立IT治理委员会等都成为形式,而实质性的责任落实成为空谈。对于这些现象的形成,最终的借口和推托理由则是信息科技风险只有科技人员才清楚,其他人员并不懂得信息科技,自然无法发现风险。由此而形成的理念包括信息科技风险审计必须是专业的技术人员才做得了。于是,信息科技风险的第二道防线(风险管理部门)、第三道防线(内部审计部门)未能发挥作用或根本不作为,风险防控压力完全承载于第一道防线(信息科技部门)。

分析:《指引》关于信息科技治理方面,明确提出商业银行信息科技风险管理的第一责任人是法定代表人,并明确商业银行的董事会、首席信息官应履行信息科技管理的职责。同时要求商业银行应设立或指派一个特定部门负责信息科技风险管理工作,应在内部审计部门设立专门的信息科技风险审计岗位。要求在建立良好的公司治理的基础上进行信息科技治理,形成分工合理、职责明确、相互制衡、报告关系清晰的信息科技治理组织结构。并确保银行所有员工充分理解和遵守经其批准的信息科技风险

2

管理制度和流程,安排相关培训。

2009年,我们在信息科技风险审计过程中,曾向某金融机构处级以上干部及主要岗位员工发出问卷调查,其中:无法完整回答“哪些部门联手可构建科技风险管理三道防线”的占比46.43%;“信息科技安全领导小组是否已经成立”回复“不知道”的占比22.22%,未作答的占比7.4%。2010年向某金融机构的71家法人行社高管问卷调查发现,能够正确回答信息科技风险管理第一负责人的仅占比45.68%,而单个法人行社高管全部选择正确的占比仅15.49%;对于专职科技人员人数的回复中,同一法人行社的高管答复不一致的占比11.27%,有一家法人行社的4个高管对于这个问题回答出了3个答案。这些问卷在不同程度上反映出了科技治理方面的问题。通过这几年的努力,应该说中小金融机构信息科技治理情况有所好转,但首席信息官在大部分金融机构仍未设立或虚设,高管作为第一责任人及科技部门、内审岗位虽基本能按银监会要求设立,但发挥的作用却各不相同。

对于信息科技风险审计方面,我们通过几年的实践体会到,专业的技术人员参与是必须的,但信息科技风险审计并不是专业的技术人员就做得了的,信息科技风险审计离不开审计理念,,只有带着特有的审计理念对信息科技流程进行梳理,才能发现风险点。

建议:高管层要勇于担当信息科技风险安全管理的推动者和引领者,建立良好的IT治理机制。发挥风险部门的第二道防线

3

的作用,组织共同学习《指引》并深入领会。风险管理部门、内部审计部门要加强信息科技方面的学习,并主动介入信息科技安全管理工作,各职能部门也应通过学习和参与项目建设、风险自查等工作中逐步树立信息科技安全理念。

二、外包方面的误区

怕风险不敢外包,但因技术能力有限又不得不外包;对于外包风险认识不足,或技术已经外包却自欺欺人地认为是合作开发。

现象:一是认为IT外包风险较大,不敢外包;二是认为外包能解决人员不足问题且风险转移,可以集中精力于核心业务,故开发项目、机房管理尽量外包;三是不得不外包,如网络运营商的服务、IBM等主要设备的硬件维保,技术、服务受制于人。

分析:前两种现象实际上都有点极端,而第三种现象则又是有点无奈。实际上,外包不仅仅是一个成本决策,也是有效管理的战略决策,要充分考虑本金融机构的技术能力和需求、外包商的服务质量、服务可持续性、控制步骤、竞争优势、技术知识等。人可以说是整个软件项目的灵魂,软件项目最大的成本就是人力成本,外包服务可以在很大程度上解决这一问题,但外包服务不得将其信息科技管理责任外包,应合理谨慎监督外包职能的履行。

建议:IT外包目的因组织而异,但通常目标都是要实现信息系统持久有益的改善。外包服务必须坚持不得将信息科技管理

4

责任外包这一原则,并通过选择战略合作伙伴、合同约束、访问控制/安全管理、违规事件报告和跟踪、服务变化控制和检测以及绩效管理/评价等措施防范外包风险。

三、项目建设方面的误区

技术部门从参与者变为协调和组织者,项目建设是科技部门的事;项目建设采用技术外包,业务部门测试通过就可加载上线;项目加载上线能够顺利运行就好;科技引领业务,必须无条件满足业务发展需要,项目建设速度要快。

现象:一是项目开发更重要的是技术人员、软件工程师的技能和水平,忽略了业务需求的重要性;二是测试注重功能性测试,对于系统间的关联性测试往往被忽略,系统压力测试成为技术部门理论上应该实现的愿景,而不是项目建设应考虑的问题;三是项目验收上线关键是程序加载顺利与否,往往忽略了上线后的业务操作反馈和跟踪;四是项目建设时间在项目立项时以项目组预估的工作量来核定,往往忽略了商务谈判时间,一旦商务谈判时间超出原定计划,则往往压缩开发、测试时间来保进度,进而影响项目质量;五是由于业务创新的提速,各行社对金融产品创新的需求强烈,因此立项建设项目也越来越多,往往忽略了项目的后评价,即使用率、使用效果、成本核算、IT负载和运行压力。

分析:如果项目建设过程中,业务需求不能确定的话,就好比一个盲人走路一样,只能摸索着前进,开发过程中不断变更需求,在历经 “磨难”后才最终确立需求,甚至在项目完成后需

5

本文来源:https://www.bwwdw.com/article/uzr2.html

Top