非科技部门和人员的科技风险管理

Q: 学习这门课可以获得什么收益？

听得懂： 将枯燥的技术术语转化为业务场景语言，让业务人员不再“云里雾里”。了解科技风险，了解科技分线管理的对业务的要求；理得清： 明确非科技部门在风险管理中的责任边界，知道哪些归我管，哪些归科技管 ，哪些需要协同，如何协同

课程大纲

观念重塑——为什么业务人员必须关注科技风险？

（对应核心领域：科技风险治理）核心目标：讲清业务部门在“治理架构”中的法定地位，解决“心态”问题
从“修电脑”到“保饭碗”
全行性风险认知：为什么监管认为科技风险是“董事会责任”？解析科技风险如何直接导致客户投诉、资金损失和监管处罚，对银行战略、运营和声誉的毁灭性打击
治理架构通识：简述银行科技风险治理顶层设计，让业务明白这不是科技部的“自留地”
找准你的位置：三道防线中的“前锋”
第一道防线（业务部门）：明确业务是风险的源头（谁产生数据、谁使用系统、谁就是防线）
协同机制：介绍“3道防线，乃至1.5道防线”概念，厘清业务与科技、风控部门的职责边界，如何做到“守土有责”

业务视角的风险识别——我们的工作哪里有雷？

（对应核心领域：网络安全 + 信息安全）核心目标：将网络与信息安全知识融入日常办公场景，识别身边的隐患
看不见的敌人：网络安全（Cyber Security）常识
网络钓鱼与社会工程学：黑客如何利用业务人员的同情心或疏忽突破防线（非技术性攻击的防范）。深入解析钓鱼邮件、社会工程学攻击（利用人性弱点）
账号与权限管理：为什么“共享账号”和“弱口令”是业务操作的红线？
影子IT（Shadow IT）：业务部门自行购买或使用的未经审批的工具/APP带来的巨大隐患
攻击面管理：为什么私自乱接设备、乱装软件（包括影子IT）会给黑客开“后门”？
AI带来的安全风险：投喂内部或商密数据造成数据外泄、数据错误误导机器学习、算法缺陷的风险
实战警示：复盘勒索攻击（Ransomware）案例，展示一次点击如何导致全行交易瘫痪，强调业务终端安全的重要性
守护核心资产：信息安全（Information Security）底线
CIA三要素的业务解读
保密性：防泄露（客户名单不是想发就能发）
完整性：防篡改（交易金额不能错）
可用性：防瘫痪（系统必须随时能用）
数据合规红线：结合《个人信息保护法》，讲解业务采集信息的“最小必要原则”、数据分级分类标准，以及数据跨境的法律风险
客户隐私保护：业务办理中如何避免违规收集或泄露个人信息（不仅是IT的事，更是合规的事）
敏感数据传输：严禁通过微信、私人邮箱传输客户明细数据，DLP系统防数据泄露
欧洲GDPR，中国及香港的个人信息保护法例，个人隐私保护条例等法规介绍

外部合作风险——谁引进，谁负责

（对应核心领域：供应链安全/外包风险）核心目标：强调工作外包，但责任不能外包，强化业务部门作为“发包方”的主体管理责任
拒绝做“甩手掌柜”
权责对等：明确“业务部门引进、业务部门负责”的原则。科技负责技术把关，业务必须承担供应商管理主责
关注数据风险
数据交换：关注与供应商（如打印印刷商，活动组织方）的数据交换和数据接口，防止数据泄露
全生命周期的供应链管控
准入与合同：准入安全评估。为什么必须在合同中约定“服务中断赔偿”（索赔与补救）和“数据保密条款”？如何在合同中约束供应商？
过程监督：断供应对，教授业务人员如何识别供应商的异常信号
现场检查：定期现场检查供应商的科技风险管理
案例分析：第三方ERP系统留后门案例 —— 业务部门为了增加客户黏性引入系统，却带来隐患

当系统崩了——业务连续性与应急协同

（对应核心领域：安全生产 & 业务连续性）核心目标：讲透“安全生产”，训练业务部门在系统宕机时的“生存技能”
安全生产与业务韧性（Resilience）
系统稳定性：理解“变更”是风险之源，为什么业务需求变更频繁会炸雷？
业务影响分析（BIA）：假如系统停机1小时、4小时、24小时，业务损失是多少？（这是业务必须告诉科技的关键指标，决定了灾备等级，关键系统定义，实时单系统热切，MTO， RTO RPO等）
从业务连续性（BCM，包括业务连续性BCP和灾备DRP）到运营韧性（OR）
应急预案中的“业务动作”
演练不是演戏：真正的演练是系统挂了，业务人员能否熟练切换到手工记账、线下办理或安抚客户？
应急预案制订及演练
案例复盘：结合星展银行（DBS）或支付系统宕机案例，分析高可用失效后，业务侧应急预案缺失带来的混乱
协同作战
事故发生时的沟通机制：如何准确向科技部门描述故障现象，而不是只喊“坏了”？

业技融合——如何与科技部门高效协同

（对应核心领域：全流程管理）核心目标：传授具体的方法论，建立高效的“业务-科技”工作流
需求与测试阶段的协同：风险前移
提需求（BRD）：如何把非功能“安全需求”（如并发量、数据脱敏要求、熔断及应急限流、监控机制等）写进业务需求书？
做测试（UAT）：业务验收不能走过场，如何发现逻辑漏洞（如优惠券被无限领取）？覆盖正常情况和异常情况
日常沟通与新技术应用
新技术边界：业务人员使用AI工具（如ChatGPT）时的合规边界（严禁投喂敏感数据）
建立机制：如何建立定期的“业务-科技”沟通机制，主动通报业务变化带来的风险
应急协同
电子渠道及网络安全应急响应小组ERT以及关键业务如支付系统应急协同小组

前瞻与总结——拥抱技术，守住底线

核心目标：总结知识点，布置行动作业
知识图谱回顾：串讲治理、网络、信息、生产四大领域的业务记忆点
对照检查工作清单：将业务部门需要关注的科技风险管理事项列为清单跟进
行动计划（Next Steps）
带回岗位的作业：自查身边的三个风险死角（如：弱口令、过期外包合同、未更新的应急手册）

适合对象

非科技部门（业务、职能、分支行）中高级管理者及骨干、产品经理与项目经理（业务侧）

课程定位与主要问题

随着银行数字化转型的深入，科技风险已不再局限于机房和代码，而是渗透到了产品设计、客户服务、第三方合作等业务全流程

核心收益

听得懂：将枯燥的技术术语转化为业务场景语言，让业务人员不再“云里雾里”。了解科技风险，了解科技分线管理的对业务的要求
理得清：明确非科技部门在风险管理中的责任边界，知道哪些归我管，哪些归科技管，哪些需要协同，如何协同
用得上：掌握供应商管理、应急预案制定、数据合规操作的具体方法，直接应用于日常工作

课程背景与交付信息

1天（6小时）

课程时间

1天

授课方式

去技术化讲解：主要采用比喻、类比的方式解释技术风险

课程内容重点

01观念重塑——为什么业务人员必须关注科技风险？

02业务视角的风险识别——我们的工作哪里有雷？

03外部合作风险——谁引进，谁负责

04当系统崩了——业务连续性与应急协同

05业技融合——如何与科技部门高效协同

06前瞻与总结——拥抱技术，守住底线

讲师介绍

尹熔

银行数字化与科技风险管理实战专家

35年银行数字化与科技风险管理实战专家，曾任大行软件中心副总经理及CISO。擅长全面科技风险管理与数字化转型，拥有人民银行科技发展一等奖及CISM国际认证，致力于赋能金融机构安全高效发展。本课程与其科技风险管理方向相关

银行业金融科技金融监管

查看讲师主页

课程差异说明

本课程页面围绕《非科技部门和人员的科技风险管理》重点呈现课程定位、适合对象、核心收益和 6 个主要模块，便于快速判断培训匹配度

课程常见问题

这门课适合哪些学员参加？

非科技部门（业务、职能、分支行）中高级管理者及骨干、产品经理与项目经理（业务侧）。

学习这门课可以获得什么收益？

听得懂：将枯燥的技术术语转化为业务场景语言，让业务人员不再“云里雾里”。了解科技风险，了解科技分线管理的对业务的要求；理得清：明确非科技部门在风险管理中的责任边界，知道哪些归我管，哪些归科技管，哪些需要协同，如何协同。

课程通常安排多长时间？

课程通常可按1天安排，具体节奏会结合企业培训目标、学员基础和现场安排确认

课程采用什么授课方式？