四家银行罚没近5000万：数据安全这笔账，必须算清

Yu
Yu

TJXFire

2026年10月13日 17:58
江西

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

全文约 4800 字，预计阅读 14 分钟。

近5000万元是多项违规的合计罚没，数据安全责任已落到具体岗位。本文按数据全生命周期，拆解管控措施、设备服务和验收方法。

一、先把近5000万元这笔账算清楚

2026年9月24日，央行公示邮储、广发、江苏、渤海四家银行的处罚信息，机构罚没合计约4937.51万元。分项如下：[1—4]

这些金额包含罚款和没收违法所得。四家银行均涉及数据安全管理违规，同时还涉及金融统计、账户管理、反洗钱等多个领域；江苏、渤海的公示还列有网络安全管理违规。[1—4]

因此，不能把新闻写成“四家银行因数据安全问题被罚近5000万元”。公示没有把机构罚款按每一项违法行为拆分。

32名相关人员合计被罚125.5万元，这是另外一笔个人罚款，也不能全部归到数据安全头上。各项处罚决定作出于9月8日，9月24日是公示日期。[1—4]

还有一个边界：这些公示列出了违法行为类型，但没有披露足以还原具体技术问题的细节。不能据此断言某家银行发生了数据泄露，或者把原因写成“未脱敏”“未加密”“外包失控”。

把边界说清楚，后面的解读才有依据。

二、系统没有被攻破，数据仍然可能走出保护范围

先看一个假设场景。

业务部门要做客户分析，从系统导出一张名单。为了方便核对，名单保留了完整姓名、手机号、证件号码和账户信息。文件先存在经办人的电脑，再发给合作机构。任务结束后，双方都没有确认副本是否清理。

整个过程可能没有木马，没有漏洞利用，也没有异常登录。

但数据已经离开原来的权限控制和审计环境。系统里谁能看哪些字段，原本有规则；变成文件以后，谁拿到了副本、又转发给谁，就未必查得清楚。

网络防护仍然要做：补丁、分区隔离、强认证、接口防护和异常访问检测，都在保护承载数据的系统。与此同时，还要追踪数据在正常业务操作中怎样被使用。

《银行保险机构数据安全管理办法》第五条明确，利用互联网等信息网络开展数据处理活动，应在网络安全等级保护制度基础上履行数据安全保护义务。[5]

做过等保测评，无法替每一笔数据导出回答“为什么要给、给多少、给谁、用到什么时候”。

三、先看“导出”按钮，往往比先买设备更接近问题

在现行规则里，数据导出已经有具体要求。

《中国人民银行业务领域数据安全管理办法》自2025年6月30日起施行，适用于央行业务领域相关数据处理活动。第十七条规定，使用高敏感性数据项原则上不采取导出方式；确需导出的，应统一规范管理相关需求场景。[6]

这里有两个词需要一起看：高敏感性、确需。

不能把它理解为所有数据都禁止导出，也不能认为经理签个字，就可以无限量导出。机构需要把允许的业务场景、字段范围和处理方式具体化。

回到那张客户名单，可以先做三个动作。

第一，把“要数据”改成“要完成什么任务”。 如果只是统计客户数量，就在受控环境内形成汇总结果；如果只是核实身份，优先考虑返回核验结果。用不到的明细字段，不因为取数方便就一并提供。

第二，把批准的范围变成系统限制。 审批通过100条，接口不能实际返回全量；批准查询，也不应默认附带批量下载权限。对批量导出设置独立授权、必要的复核和使用期限。

第三，让文件离开数据库后仍然有人管。 确有必要生成文件的，明确存放位置、访问人员、发送渠道和清理时间；结合敏感程度采用加密、访问限制、水印或外发控制。加密密钥与文件分开管理，避免文件和密码一起转发。

这些措施要通过一次真实流程的抽查来验证。找出审批单，再核对实际导出的字段、条数和接收方。三者对不上，制度就还没有落实到操作上。

四、把全生命周期拆开：每个环节怎么管，设备和服务怎么配

分类分级做完，下一步应该发生什么？

最直接的检验，是跟着一批客户数据走一遍：从采集入库，到查询分析、传输共享，再到归档和退出使用，看看每一步有没有实际控制。

分类分级是这些控制的依据。敏感个人信息、重要数据和机构内部的高敏感字段，需要按适用规则分别识别，不能直接互换标签。

下面是一套落地建议。设备名称指能力类别，也可以由软件或现有平台实现，并非监管要求逐项采购。控制设计可参考访问控制、审计、通信保护、备份和介质保护等安全控制体系，再结合本行规则验证。[8]

1. 采集：先说清为什么收，再决定收哪些字段。

例如客户申请某项服务，页面只需核验身份，却把完整影像、通讯录等一并收进来。真正该查的是，每个字段有没有相应业务用途和合法处理依据，是否完成适用的告知、同意或其他必要程序。

可以利用接口网关、采集规则校验和敏感数据发现能力，检查实际请求与批准的字段是否一致；对第三方数据源核实来源、范围和接入授权。技术工具能发现“收了什么”，合法性和必要性仍需要业务、合规人员判断。

配套服务与验收： 做数据资产梳理、采集合规评估和分类分级，交付“字段—用途—来源—依据—责任人”清单。抽查一个实际业务请求，确认没有把清单之外的数据顺手收进来。

2. 存储：主库加密了，副本也要找齐。

数据入库以后，保护对象包括正式数据库，也包括共享目录、缓存、日志、对象存储和临时导出文件。正式系统管得严，某个临时目录却允许所有人读取，同样留下了缺口。

数据库或文件加密可与密钥管理系统配合，按需要使用密码机保护密钥；同时配置最小访问权限、网络隔离和数据库审计。密钥的生成、授权、轮换和恢复要有人负责。存储加密不能阻止一个已获解密权限的账号滥用明文。

配套服务与验收： 开展存储基线检查、权限复核及加密配置核验，形成存储位置清单、权限矩阵和整改记录。分别使用普通账号、运维账号验证访问边界，并检查副本是否遵守相应保护要求。

3. 使用与加工：看得见、导得出、能运维，要分开授权。

业务人员需要查询，不代表需要全量下载；开发人员需要测试，也不代表需要真实客户明文。建立岗位、场景和数据范围的对应关系，对临时权限设置有效期，人员转岗后同步回收。

可由身份权限管理、特权账号管理或堡垒机配合业务系统授权，使用动态脱敏控制页面展示，使用静态脱敏生成测试副本，再用数据库审计记录关键操作。堡垒机主要约束经过它的运维通道，应用接口和绕行直连还要另查。脱敏不等于匿名化，仍需评估重识别风险。

配套服务与验收： 做权限治理、脱敏规则设计、应用越权测试和数据加工风险评估。让普通业务角色尝试访问超范围记录，让测试角色检查样本中是否残留可识别信息；加工形成的新标签、画像也应重新评估保护等级。

4. 传输：通道加密之外，还要核对两端。

行内系统调用、文件交换、移动介质传递，都要明确发送者、接收者和允许的数据范围。传输成功，只说明文件到了；送错对象、超范围返回或重复调用，仍可能造成风险。

按场景采用适用的加密通道、安全文件交换、接口认证及数据防泄漏能力。接口校验身份、字段和调用频率，证书与密钥定期维护。加密流量在旁路设备上未必可见，敏感内容检查应部署在经过授权、能够识别内容的应用端、网关或终端位置。

配套服务与验收： 梳理数据流向，检查接口和传输策略。用受控测试验证错误身份、过期凭证、超范围字段是否被拒绝，并保留测试记录。不能只凭“已启用HTTPS”通过整个传输环节的验收。

5. 共享、对外提供与公开：权限跟着用途走，责任不能随文件转走。

先区分行内共享、委托处理、对外提供和公开发布。分别明确接收方、用途、字段、期限及必要评估；涉及出境的，按实际场景识别适用义务。公开发布也要检查附件、批注、隐藏工作表等是否夹带不应公开的数据。

数据交换平台、API安全能力、终端及网络数据防泄漏系统（DLP），可辅助实施审批、限量、内容检查和告警；文档权限与水印可以补充使用控制及追溯。水印不等于阻断，外发成功也不等于银行仍能控制接收方的全部副本。

配套服务与验收： 开展共享场景评估、供应商安全检查和外发策略验证。选一笔实际交换任务，将合同、审批、实际字段、接收记录对照；外包履约的检查，下一章继续展开。

6. 备份与归档：恢复得回来，也要防止旧数据重新失控。

根据业务恢复目标设计备份频率、可接受的数据损失范围和恢复时间，明确备份保存期限。备份账号与生产管理账号适当隔离，避免同一组高权限凭证同时控制生产和全部备份。

可结合加密备份、离线或隔离副本、不可变存储和灾备能力。保护方式应与风险和系统条件匹配；备份中的密钥恢复依赖也要验证，不能只备数据、不备恢复所需条件。

配套服务与验收： 开展备份架构检查和恢复演练，交付恢复记录、耗时、数据完整性验证及问题清单。备份任务显示“成功”之后，还要实际恢复一次，并确认恢复环境重新施加了正确权限。

7. 删除与销毁：从台账退出，还要从副本和介质退出。

先核对法定留存、业务保存和争议处理要求，再决定删除或销毁，不能为清理而提前删除必须保留的数据。删除任务要关联主库、缓存、共享文件、测试副本和受托方副本；不可变备份按保留策略到期处置，恢复时防止已删除数据重新投入使用。

可由数据生命周期管理规则触发到期处理，结合适合介质类型的安全擦除、密码擦除或物理销毁。格式化、删文件不自动等于不可恢复；密码擦除也依赖加密覆盖和所有相关密钥副本的可靠处置。介质清理方法与验证可参考NIST SP 800-88 Rev.2，国内法定与行业要求仍按适用规定执行。[9]

配套服务与验收： 做留存策略核查、介质处置与销毁验证，留存对象编号、审批、方法、时间、执行人和验证结果。设备交给回收方前完成交接核验，不能只拿一张笼统的“已销毁证明”。

走完这七步，再看数据安全设备的作用，就容易判断了。

发现工具帮助找数据，权限和加密控制访问，脱敏降低暴露，审计记录行为，DLP约束外发，备份保障恢复；评估、整改、验证和持续运营把这些能力接进业务。

它们存在覆盖边界。旁路审计通常不能代替实时阻断；DLP能否识别特定文件和通道，要靠测试确认；数据安全平台即便展示了全景，也不代表所有控制点已接入。

所以采购或验收时，可以要求服务方拿一个脱敏测试场景跑完整流程：违规操作在哪里被阻止，谁收到了告警，工单交给谁，整改后怎么复验。优先复用已有能力，针对覆盖缺口补充建设。

每个环节至少留下四样东西：保护对象、控制规则、负责岗位、验证记录。设备是否上线，只是其中一个起点。

五、外包签了保密协议，检查还没有结束

那张客户名单如果交给合作方，行内的审批只是第一步。

银行需要知道，对方用哪套系统处理、哪些人员可以访问、是否允许转委托、任务结束后如何返还或删除，以及发现异常时怎样通知银行。

《银行保险机构数据安全管理办法》第三十条，对委托处理的合同约定、记录审计，以及未经同意转委托等行为提出要求。[5]

落到检查上，建议抽一个已经结束的外包项目：

看合同约定的数据范围，核对实际传输记录；看人员名单，检查离场人员账号是否撤销；看删除确认，核实临时目录、共享文件夹和备份的处置安排。

一份保密协议证明双方约定过义务；履约记录才能说明义务实际执行到了哪里。

同样的检查思路也适用于AI工具。员工把客户明细贴进外部模型、插件读取业务文件、助手自动调用查询接口，都可能形成新的数据处理路径。

建议把这些工具纳入应用与数据流向清单，明确允许输入的数据、调用账号权限、服务方是否留存或用于训练，以及输出和操作如何审查。没有完成必要评估与授权前，不应把客户敏感明细当作普通办公素材提交给外部服务。

六、问责落到人，日常工作就要留下能对应人的证据

公示中还有两笔值得注意的个人处罚：邮储银行运营数据中心、江苏银行信息科技部及大数据部各有一名人员，因对数据安全违规负有责任被罚1万元。公示没有披露具体失职动作，不能继续演绎。[1][3]

对其他机构，更有用的是回头检查自己的责任安排。

谁能解释这批数据为什么需要使用？谁审批范围？谁配置权限？谁检查异常导出？谁决定风险升级？如果这些问题都只指向“科技部”，业务责任很可能没有分清。

《银行保险机构数据安全管理办法》第十至十四条，分别涉及主要负责人、归口管理部门、业务部门、风险合规审计和信息科技部门的职责。[5]

建议每个重点场景明确四类责任：业务负责人说明用途和必要范围，数据安全归口部门组织评估，技术团队落实控制，独立检查人员核验执行结果。

日志也要能支持这个分工。除了“某账号登录成功”，还应按场景记录谁在何时访问了什么对象、执行了哪类操作、是否关联审批，以及异常如何处置。日志本身也要避免无必要地记录敏感明文。

保留多久，不能全行统一套用一句“六个月”。例如央行上述办法第三十条，对普通业务数据处理日志、涉及重要或核心数据系统的日志，以及部分对外提供和委托处理记录，规定了不同的最低留存期限。[6]

应急方面，则要提前演练“发现异常后谁接手”。模拟一次批量异常导出：能否定位账号、暂停访问、保存证据、查清接收方，并启动报告流程。

《中国人民银行业务领域网络安全事件报告管理办法》自2025年8月1日起施行，规定了适用领域事件的分级和报告要求。机构应按事件性质、等级及其他适用监管要求执行，不能把内部工单关闭当作报告义务已完成。[7]

七、下一次自查，可以先勾完这六项

下面是工作建议，不是新增的监管时限或统一抽样标准。可以从一条高风险数据使用流程入手，再根据发现扩大检查范围。

再留一张可以直接放进工单的便签：

数据使用核验单

业务用途／业务负责人：\\\\

数据范围／分类分级依据：\\\\

使用人员／接收方／处理环境：\\\\

审批记录／实际操作记录：\\\\

保护措施／保存或使用期限：\\\\

待整改问题／责任人／完成日期：\\\\

复核证据／复核人／结论：\\\\

近5000万元足以让人停下来读新闻。但对银行和其他适用机构而言，真正值得带回去的，是一项能够马上执行的检查。

选一张含敏感信息的业务报表，从生成追到使用结束。查清谁需要它、谁拿到它、它去了哪里，以及什么时候该停止使用。

如果这条路径说不清，下一步该补的工作，就已经在眼前。

资料来源与核验说明

处罚事实依据央行原始公示，机构合计金额由罚款和没收违法所得相加，个人罚款另计。文中制度用于说明当前防护要求，不据此倒推上述处罚的具体适用条款。核验日期：2026年10月13日。

[1] 中国人民银行：银罚决字〔2026〕88—96号（邮储银行）。https://www.pbc.gov.cn/zhengwugongkai/4081330/4081344/4081407/4081705/2026092418100954390/index.html

[2] 中国人民银行：银罚决字〔2026〕104—116号（广发银行）。https://www.pbc.gov.cn/zhengwugongkai/4081330/4081344/4081407/4081705/2026092418294123383/index.html

[3] 中国人民银行：银罚决字〔2026〕97—103号（江苏银行）。https://www.pbc.gov.cn/zhengwugongkai/4081330/4081344/4081407/4081705/2026092418173395804/index.html

[4] 中国人民银行：银罚决字〔2026〕81—87号（渤海银行）。https://www.pbc.gov.cn/zhengwugongkai/4081330/4081344/4081407/4081705/2026092417524340666/index.html

[5] 国家金融监督管理总局：《银行保险机构数据安全管理办法》，重点参见第五条、第十至十四条、第三十条。https://app.www.gov.cn/govdata/gov/202412/29/523120/article.html

[6] 中国人民银行：《中国人民银行业务领域数据安全管理办法》，重点参见第二条、第十七条、第三十条。https://www.pbc.gov.cn/zhengwugongkai/attachDir/2025/11/2025111915275027791.pdf

[7] 中国人民银行：发布《中国人民银行业务领域网络安全事件报告管理办法》。https://www.pbc.gov.cn/goutongjiaoliu/113456/113469/2025092212554764345/index.html

[8] NIST SP 800-53 Rev.5：安全与隐私控制目录，作为技术控制设计参考，不作为国内监管强制采购依据。https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final

[9] NIST SP 800-88 Rev.2：介质清理指南，2025年9月发布。https://csrc.nist.gov/pubs/sp/800/88/r2/final