跳到主要内容

中国人民银行业务领域网络安全事件报告管理办法

本文用于组织落实和检查央行4号令：明确安全要求，选择实施方式，确定完成标准，用真实证据验证执行结果。

法规概览 · 安全要求与实施 · 法规原文

法规概览​

项目内容
法规《中国人民银行业务领域网络安全事件报告管理办法》，中国人民银行令〔2025〕第4号
生效日期2025年8月1日
适用对象金融机构以及经中国人民银行批准设立或者认定的其他机构，在中国境内发生的中国人民银行业务领域网络安全事件
主要内容事件分级、监测与应急职责、报告对象、时限、内容、渠道、调查总结和台账
核对依据人民银行公布文本、司法部收录文本；本页最近条文核对日期为2026年9月16日

本办法聚焦事件分级与报告，不能替代数据安全、关基保护、个人信息保护等其他合规要求。非央行业务领域事件不按本办法报告，仍须判断其他适用义务；涉及国家秘密的，按有关规定执行。依据：第2—4条、第31条。

下文按 “法规要求 → 落实与验收” 展开：每项要求同时说明实施动作与可验证证据。法规原文要求与实施建议明确区分；法定要求不得通过替代实现降低标准。存在适用、起算或解释争议时，应结合具体事实由法务合规核实，必要时向主管机关确认。

安全要求与实施​

按四个工作主题组织实施。每项要求在本节完成闭环：先明确法规要求，再说明落实动作和可验证的验收标准。

核心主题达成状态
范围与职责知道哪些业务适用、需要向谁报告、由谁负责
事件识别与分级事件不漏、等级判得准、关键指标随时取得到
报告与持续更新该报的事件能够按对象、时限、内容和渠道持续完成报告
调查与留存每起事件能够完整还原、整改闭环、证据可追溯

各主题应在内部明确负责人、完成日期、证据位置和复核人；公开文档不记录真实事件材料、监管联系方式和内部架构。

范围与职责​

确定适用范围和并行报告义务​

法规要求｜第2—4条。 根据机构身份、业务领域以及受影响的网络和数据判断本办法是否适用。国家有关部门和其他金融管理部门另有报告规定的，还应从其规定；涉及危害计算机信息系统等违法犯罪的网络安全事件，还应及时向公安机关报案。

落实与验收。

  • 从机构完整的业务和系统清单出发，映射央行业务领域、相关数据、责任部门及报告链路。
  • 对排除的业务和系统记录理由。
  • 为其他适用法规单独登记触发条件、分级规则、起算依据、对象、时限和渠道，避免把央行口径直接套给所有接报机关。

验收标准。

  • 请拿出完整业务和系统清单：哪些属于央行业务领域，哪些不属于？每一个排除项的依据是什么？
  • 如果今天发生一场同时涉及网络攻击、个人信息泄露和重要数据风险的事件，除了人民银行，还需要向谁报告或报案？每条链路的触发条件、时限和依据是什么？
  • 有没有只因为“系统归某团队”“过去一直没报过”“不是核心系统”就被排除在适用范围之外的系统？
  • 新业务、新系统、新数据类型上线后，谁负责判断是否进入4号令适用范围？最近一次变更是什么时候？

明确处置职责、报送授权和报告对象​

法规要求｜第13—14条。 明确应急处置与报告的职责分工；发生网络安全事件立即启动应急预案、采取补救措施，报告工作不得迟滞业务恢复、存证溯源、用户解释和舆情应对。按机构类型向正确的人民银行机构报告。

机构或场景人民银行报告路径
国家开发银行、政策性银行、国有商业银行、中国邮政储蓄银行、股份制商业银行、属于系统重要性金融机构的城市商业银行、系统重要性非银行支付机构、经营个人征信业务的征信机构向中国人民银行报告
上一行所列机构的分支机构向住所地中国人民银行分支机构报告
人民银行所属单位及其管理的金融基础设施运营机构向中国人民银行报告
其他金融从业机构或其分支机构向住所地中国人民银行分支机构报告
证券、期货、基金机构在保障报告时效性前提下，经中国证监会派出机构转通报同级中国人民银行分支机构

落实与验收。

  • 在预案中落实判级、技术处置、报送、授权、隐私和舆情职责，维护可用联系人与渠道。
  • 建议设置主备人员和紧急授权，使主负责人不可达时仍可按合法授权推进，避免等待逐级审批。
  • 人民银行系统内部的逐级上报职责，不应混作企业自身的报送任务。

验收标准。

  • 现在随机问一个夜班值班人员：发生较大事件后，他第一通电话打给谁，谁负责判级，谁负责报送，谁负责技术处置？能否不翻几十页制度就回答出来？
  • 如果主负责人、审批人同时联系不上，报告流程会停在哪里？现有授权是否允许继续推进？
  • 总部、分支机构、不同类型机构的报告对象是否真的区分清楚？有没有沿用旧联系人、旧组织架构或旧监管路径？
  • 报告、恢复、取证、用户解释和舆情处置是否由不同角色并行开展，还是所有动作都在等待同一个负责人拍板？
  • 最近一次验证监管联系人和备用渠道是什么时候？如果主渠道现在不可用，团队实际会怎么做？

事件识别与分级​

覆盖事件来源，验证监测与研判联动​

法规要求｜第3条、第10条、第13条。 健全网络安全风险监测预警体系，提升第一时间发现和报告事件的技术能力。事件原因包括人为原因、网络攻击、漏洞隐患、软硬件缺陷或故障、不可抗力等；发生或者可能发生个人信息泄露、篡改、丢失，属于第十条规定的分级情形。

落实与验收。

  • 联通安全告警、生产故障、业务异常、数据异常、用户投诉和外部通报。
  • 收到线索后核实影响并进入适用的分级程序。
  • 安全、稳定性、数据和隐私团队可以使用不同平台，但须能关联事实、判级和报告任务。

验收标准。

  • 从最近一段时间的安全告警、生产故障、投诉和数据异常中各随机抽几条：为什么进入或没有进入网络安全事件研判？依据能否被复核？
  • 一次纯发布故障导致支付业务大面积中断，没有任何攻击行为，会不会被稳定性团队直接关闭而从未进入4号令判级？
  • 数据库有效凭证暴露，已经能够访问个人信息，但尚不能确认是否被下载，团队会立即研判还是等“确认泄露”以后再处理？
  • 用户投诉、业务监控或监管通报是否可能比安全平台更早发现事件？如果会，这些来源如何进入统一研判流程？
  • 有没有出现过多个团队分别处理同一件事，但没有任何一个团队负责最终判级和报告判断？

建立完整分级规则并持续维护​

法规要求｜第6—12条、第31条。 在制度或操作规程中明确特别重大、重大、较大、一般四级标准，每年组织评估、视情更新；更新须报主管网络安全的领导班子成员批准。针对指定业务考虑高峰和非高峰的差异，结合业务领域数据安全规定制定数据事件标准。涉及与央行管理的金融基础设施业务交互功能异常的标准，还须征求运营机构意见并协商一致。

下列条件按适用前提分别判断，任一命中即达到至少相应等级，同时命中取最高等级。“以上”含本数。各表为同一套规则的不同维度，不是综合打分表。

用户影响条件。 前提为提供金融服务的央行业务领域网络，主要功能中断、超时报错等导致业务无法正常开展，经合理测算或估算达到实际影响规模。不得直接用注册用户数代替实际影响人数。

最低等级实际影响自然人实际影响法人和其他组织
一般1万个以上1000个以上
较大10万个以上5000个以上
重大100万个以上10万个以上
特别重大1000万个以上100万个以上

数据及攻击条件。 数量门槛对应“泄露”，不能不加区分地套用于所有篡改、丢失情形。数据类型须与本机构经核实的分类分级结果一致。

条件最低等级
发生或者可能发生个人信息泄露、篡改、丢失一般；仍须判断其他更高等级条件
央行业务领域数据遭篡改、破坏、泄露，导致社会危害一般；仍须判断其他更高等级条件
泄露500条以上征信信息、财产信息，或者5万条以上个人信息较大
泄露100万条以上敏感个人信息，或者1000万条以上个人信息重大
泄露1000万条以上敏感个人信息，或者1亿条以上个人信息特别重大
央行业务领域重要数据遭篡改、破坏、泄露重大
央行业务领域核心数据遭篡改、破坏、泄露特别重大
勒索恶意程序攻击已对央行业务领域网络或数据造成危害后果较大

业务中断条件。 下表适用于金融基础设施、直接服务5000万个以上自然人，或者与货币存取款、支付交易、税款缴库、银行间市场交易密切相关的央行业务领域网络，且其主要功能在业务高峰时段发生相应范围的整体中断。

最低等级两个以上省级行政区范围单个省级行政区范围
较大整体中断15分钟以上整体中断30分钟以上
重大整体中断1.5小时以上整体中断3小时以上
特别重大整体中断3小时以上整体中断6小时以上

一般事件还有独立条件：提供金融服务的央行业务领域网络主要功能单省整体中断30分钟以上；或者央行业务领域网络主要功能中断、超时报错等导致业务无法正常开展持续1小时以上。不得因不满足上表的特定网络或高峰前提而跳过这些条件；还应核对本机构其他适用分级标准。

网信部门、公安机关已明确的等级，以及人民银行或其上海总部、省级分行、计划单列市分行研判并书面告知的重大、特别重大等级，也须按第七至十条纳入判断。更高等级依据不能被另一维度较轻的结果抵消。

落实与验收。

  • 将适用前提、数据来源、计算公式、阈值、等级、条款和版本编成规则。
  • 规则可放在现有制度或工具中，无须另造一份文件。
  • 每年形成评估结论；未修改时仍记录评估，不强行产生新版本。
  • 涉及金融基础设施交互的，标识适用场景和协商状态。

验收标准。

  • 随机给出刚好落在阈值边界上的场景，规则能否稳定给出正确等级，还是必须找某个“熟悉法规的人”临时解释？
  • 高峰与非高峰、自然人与法人、普通个人信息与敏感个人信息、重要数据与核心数据是否分别建模，还是被简化成一张粗略分级表？
  • 同时命中多个条件时，系统或人员是否真的会取最高等级？有没有被“主要看业务影响”之类经验判断降级？
  • 对照规则仍无法准确确定等级时，是否真的会至少按较大处理，还是会倾向于先定一般、等证据更多再说？
  • 最近一个年度的分级标准评估结论在哪里？如果有更新，谁批准的？如果没有更新，是否有“评估后无需更新”的记录？
  • 涉及央行管理金融基础设施交互异常的规则，是否真的征求过运营机构意见并协商一致，还是企业单方面制定？

取得判级数据并执行动态调整​

法规要求｜第6—12条、第31条。 对照标准综合判级；同时符合多个条件取最高等级，对照标准无法准确确定等级时至少分级为较大。灾害或信息基础设施故障使多个央行业务领域网络同时发生事件的，先分别判级，再取最高等级作为整体等级；事态达到更高级别标准时立即调整。

落实与验收。

  • 为各类网络明确指标负责人、时间窗口、地域划分、正常业务量基线、用户统计、数据类型及规模来源。

  • 允许有依据的合理测算或估算，记录方法、已知限制和后续更新；不必等所有数据精确到最终值才判级。

  • 计算口径应遵守第31条：

指标应采用的口径
主要功能与用户身份认证或者业务交互相关的功能
业务高峰时段按年度统计的分时平均业务量超过日平均业务量3%的时段，或者依据本机构制度列明的其他合理计算方式确定的时段
整体中断运行某时段未处理和处理失败业务量之和，与正常情况下全部业务量的比例，经合理测算或估算超过70%
  • 整体中断的分母不是实际进入系统的请求量，也不能直接以某个接口的错误率替代。
  • 假设正常应处理10000笔，成功2000笔、未处理8000笔、失败0笔，则该比例为80%，不能因失败笔数为0得出“没有整体中断”。
  • 这是计算示例，实际还需满足相应网络、时段和地域前提。

验收标准。

  • 现在随机指定一个核心系统和一个故障时间窗口，团队能否立即说清判级需要哪些数据、分别从哪里取、谁有权限取？
  • “实际影响用户数”到底怎么计算？能否从原始数据重算，而不是只引用事故群里一个口头数字？
  • 正常业务量、高峰时段、未处理量和失败量的基线从哪里来？业务量异常时，分母是否仍然可解释？
  • 数据安全团队确认的重要数据或个人信息影响，是否会自动进入事件判级，还是停留在另一个工单系统里？
  • 多个网络同时受影响时，是否逐个判级后取最高等级？事件升级以后，旧等级、升级时间和触发的新增报告义务是否都能追溯？
  • 缺关键数据时，系统会显示“未知”并触发保守处理，还是默认成0，从而把事件等级算低？

报告与持续更新​

明确报告触发条件和时限​

法规要求｜第13条、第15—17条。 报告及时、准确、完整，不得迟报、漏报或瞒报。不同义务按各自条件触发，持续报告与初次报告、技术处置并行。

触发条件必须执行的报告义务
较大及以上网络安全事件发生后1小时内报送事发简要报告，24小时内报送事发报告
尚未达到较大，但相关舆情出现进入社交媒体、搜索引擎或新闻网站热点榜等情形并引发较大舆情按第15条同样执行1小时简报、24小时事发报告；该报告触发不等于事件等级自动变为较大
重大及以上事件处置期间至少每隔2小时报送进展，直至处置结束；调高等级、取得阶段性进展、发现新问题等重要情况立即报告
一般事件，且未触发上述舆情情形第15条第一款未统一规定其1小时、24小时首报要求；仍应履行适用的处置、事后总结、台账及其他报告义务

落实与验收。

  • 建立事件及报告义务清单，为每条义务记录适用依据、到期点、执行人和提交结果。

  • 建议自动提醒、预先授权并预留内部缓冲；不得为等最终根因或层层审批而推迟依法报送。

  • 应形成报告触发规则、时限管理机制、授权与提醒机制。

  • 每项适用时限均能独立验证；重大以上的进展报告覆盖整个适用期间，不能等24小时事发报告完成后才开始。

  • 检查首份进展、连续各次进展和处置结束前的尾段，不只计算两份中间报告的间隔。

  • 起算判断须依据客观事件事实和适用监管口径。

  • 第15条没有规定可从内部审批或最终判级完成后重新计时。

  • 建议保留实际发生、客观达到相应条件、首次发现、初步判级、内部升级、各次报送及收悉的时间和依据。

  • 起点迟发现或不明确时，如实记录未知项并立即采取保守报送措施，不等待起点争议解决后再报告；由法务合规核实具体起算口径，不以发现时间当然替代发生时间。

验收标准。

  • 找出检查期间所有达到较大及以上条件的事件：是否每一起都能证明在适用起算点后1小时内完成简报，而不是“1小时内启动内部流程”？
  • 有没有事件在技术团队看来已经很严重，但因为内部还没完成正式判级、领导审批或根因分析而推迟报送？
  • 24小时事发报告是否逐起按时提交？迟报时是否如实记录，而不是通过修改事件发生时间或判级时间让时间线看起来合规？
  • 对重大及以上事件，从进入该等级到处置结束，是否始终满足至少每2小时报告一次？第一份和最后一段时间是否也覆盖？
  • 调高等级、取得阶段性进展、发现新问题时，是否立即报告，还是统一等到下一个2小时时点？
  • 有哪些技术等级未达到较大、但舆情已经进入热点榜并引发较大舆情的事件？这些事件是否触发了同样的1小时、24小时报告？

准备报告内容，落实渠道和收悉要求​

法规要求｜第18—21条。 不同报告包含不同内容。下表列示字段依据，机构可以调整排版，但不能省略适用信息。

报告类型应覆盖的内容
事发简要报告初次确定的等级、事发时间、依据相关国家标准确定的事件分类、影响的央行业务领域网络及其保护等级、涉及的数据中心、报告机构和时间、报告人和联系方式
事发报告简报内容，加影响范围和程度、已采取措施和效果；网络攻击事件增加分析研判情况
事中进展报告简报内容，加最新等级、影响变化、处置进展、下一步措施；存在需要央行协调支持的事项时一并说明
事后调查总结最终等级、处置历程、影响损失评估、技术或管理根因、经验教训、后续改进、报告机构和时间、报告人和联系方式、签发人；涉及个人信息或较大以上事件时，分别补入个人信息事项和责任认定

简报、事发报告和进展报告，可以使用电话、即时通信工具、电子邮件、传真或者人民银行指定系统。采用邮件、传真时，应通过电话或即时通信确认已收悉。 涉及工作秘密，不得通过互联网渠道报告。事后调查总结须书面报送并加盖本机构或承担报告职责内设部门公章；有电子化报送规定的，还应按规定电子化报送。

落实与验收。

  • 将字段清单与各类报告准备流程绑定，准备允许使用的渠道及故障替代路径。
  • 电话报送建议同步记录接报对象、时间和实际内容；邮件和传真后保留电话或即时通信确认。
  • 未知信息如实标识、持续补充，不得编造完整性，也不能以填满最终信息为前提拖延报告。

验收标准。

  • 随机抽一份真实简报，不看模板：法规要求的字段是否真的全部存在？哪些字段当时未知，是否明确标注并后续补充？
  • 邮件或传真报送后，能否拿出电话或即时通信确认监管已收悉的证据，并明确关联到这一份报告？
  • 如果报告涉及工作秘密，现有流程会不会仍然默认发互联网邮箱或互联网即时通信？
  • 电话报送时，除了通话记录，是否能证明向谁、在什么时间、报告了哪些关键内容？
  • 事后调查总结是否真的书面报送并盖章？有电子化报送要求时是否同时完成？
  • 主报送渠道故障时，备用渠道是否真正可用，还是只在预案里写了一行？

联动个人信息补救和通知义务​

法规要求｜第4条、第20条；并行适用《个人信息保护法》第57条。 涉及个人信息泄露、篡改、丢失的，总结报告还应说明补救措施、依法通知个人的情况，以及告知个人可采取减轻危害措施的情况。重大以上事件应在进展报告中提前说明，不能一律等到事后总结。

并行适用个人信息保护法第57条时，发生或者可能发生个人信息泄露、篡改、丢失，应立即采取补救措施并通知履行个人信息保护职责的部门和个人。采取措施能够有效避免危害时，可以不通知个人，但主管部门认为可能造成危害的，有权要求通知。该例外不当然免除主管部门通知义务。

落实与验收。

  • 将安全调查、隐私影响评估、部门通知和个人通知分别建立任务。
  • 通知内容覆盖信息种类、原因和可能危害、补救及个人减损措施、处理者联系方式。
  • 不通知个人时，形成事实和适用依据，不能仅以影响较小或担忧舆情作为理由。

验收标准。

  • 随机抽一件涉及个人信息的事件：谁作出了“通知个人/不通知个人”的决定？依据是什么？有没有事实和法律判断记录？
  • 如果决定不通知个人，是否真的满足有效避免危害的条件，还是只是因为影响人数少、担心舆情或认为“问题已经修了”？
  • 实际通知内容是否包含信息种类、原因和可能危害、补救措施、个人可采取的减损措施以及联系方式？
  • 重大以上事件中，这些个人信息补救和通知情况是否已经在事中进展报告中体现，而不是事后才补进总结？
  • 安全、隐私、监管报告三条流程是否能关联到同一事件，还是彼此各自关闭工单？

调查与留存​

完成调查总结、延期承诺和退回修订​

法规要求｜第17—19条、第23条。 事件处置结束后10个工作日内报送调查总结。无法按时完成时，先按时报送初步报告，说明最终报告承诺日期并按时履行；承诺日期原则上在处置结束之日起40个工作日内。收到正式退回修改意见后，应在收到反馈之日起10个工作日内完善并重新报送。

第17条未将事后调查总结限定为较大以上事件。一般事件也不能仅因不适用第15条第一款首报时限就跳过总结。报告内容和形式见报告内容及渠道。

落实与验收。

  • 分别记录业务恢复、事件处置结束、整改完成等状态，避免用任意关闭工单日期代替处置结束。
  • 建立工作日截止日期、初步报告、承诺及退回反馈台账；复杂事项的起止依据由责任人和法务合规核实。

验收标准。

  • 检查期间所有已经处置结束的事件，是否都能找到对应的事后调查总结？一般事件有没有因为“没到较大”而被漏掉？
  • “处置结束时间”是谁定义的？是否存在通过晚关工单、晚定义处置结束来延后10个工作日起算点的情况？
  • 无法10个工作日内完成时，是否先按时报送初步报告并明确承诺日期？最终是否真的按承诺提交？
  • 有哪些总结被监管退回过？收到正式反馈后是否在10个工作日内完成修改重报，还是只在内部完成了修订？
  • 总结报告是否真正完成提交、盖章和适用的电子化要求，还是只停留在“文档已经写完”？

形成责任认定和差异化处理依据​

法规要求｜第21—22条。 较大以上事件总结还应包括直接负责的主管人员和其他直接责任人员的责任认定及处理情况。制度应综合动机态度、客观条件、程序方法、后果影响和挽回损失等因素，明确差异化处理情形。适用第22条减轻或免除责任处理时，须能提供证明并在总结中说明。

落实与验收。

  • 预先建立责任处理规则，由调查事实支持责任结论。
  • 对主动报告并立即处置、符合条件的创新试错、已履行制度规程等情形分别核实，不预设“发生事件必定处罚某个人”。
  • 机构按第22条作出的责任处理减免，不等于行政法律责任自动免除。

验收标准。

  • 每一起较大以上事件，是否都明确识别了直接负责的主管人员和其他直接责任人员，并形成责任判断？
  • 责任处理结果能否逐项对应到既有制度和调查事实，还是事故发生后再临时决定“谁背锅”？
  • 对减轻或免除责任处理的人员，能否拿出符合第22条条件的证明材料？相关理由是否写进总结报告？
  • 有没有“技术根因分析得很完整，但完全没有责任认定”的事件？反过来，有没有只有处分结果却没有事实链和制度依据的事件？

核查监管风险提示并反馈​

法规要求｜第24条。 收到人民银行通报的运行异常、疑似泄露、安全缺陷、漏洞等风险提示后，立即组织核查并采取必要补救。风险属实且构成事件的，依本办法报告；风险不属实或尚不构成事件的，仍按通报要求及时反馈核查处置情况。

落实与验收。

  • 对接收、分派、核查开始、结果、补救和反馈建立记录。
  • 将“开始核查”“完成处置”“到期反馈”分别管理，不能把立即核查误写成所有调查和整改都须瞬间完成。
  • 构成事件时关联分级与报告任务。

验收标准。

  • 随机抽一条监管通报：收到后多久开始核查，谁接手，采取了什么补救，什么时候向监管反馈？
  • 风险核查后认定“不属实”或“尚不构成事件”的事项，是否仍按通报要求反馈，还是内部关单后就结束？
  • 尚未完成核查的事项是否持续跟踪并按要求说明进展，还是一旦分派出去就脱离监管报告视野？
  • 风险属实并构成网络安全事件时，是否自动进入事件分级和报告流程，还是监管通报与事件系统彼此割裂？

建立可追溯的事件台账和证据索引​

法规要求｜第25条。 建立事件台账，完整准确记录事发时间、事发报告时间、人民银行接报联系人及对应报告内容；台账至少留存三年。

落实与验收。

  • 用事件编号或稳定关联关系串联原始线索、影响数据、判级、报告和事后处理。
  • 台账可以使用适当的系统或受控表格，重点是记录完整、访问受控、能够检索和迁移。
  • 建议保存可核验的报告内容及关联证据；其他原始日志的保存期限还须按其适用规定确定，不能把“台账三年”机械等同于所有日志三年。

验收标准。

  • 不从事件台账里选样本，而是从生产故障、告警、投诉或监管通报中随机挑一个事件：能否在台账里找到它？如果找不到，为什么？
  • 随机选一件已登记事件，能否一路追到原始事实、判级依据、报送内容、收悉记录、调查总结和整改结果？
  • 台账里的“事发时间”和“报告时间”能否与原始系统记录对应，还是事后人工补填且无法验证？
  • 至少三年的保存策略是否真正生效？系统迁移、人员离职或归档后，历史记录还能否恢复和检索？
  • 未触发某项报告或责任认定的事件，是否记录了不适用依据，还是简单留空，让后来检查人员无法判断是“不适用”还是“遗漏”？

法规原文​

查看法规原文

来源与条款索引​

本页依据人民银行公布文本整理，可用司法部收录文本交叉核对。下方保留原有33条法规正文，只调整章节层级并添加条款锚点；解读、示例和验收建议均在原文之前。

条款本页落实位置
第1—4条、第31条中的主体定义法规概览、适用范围
第5条举报权利和监管保密规定，保留原文，不转写成企业新增技术义务
第6—11条、第31条中的分级术语分级规则、指标与动态判级
第12条指标与动态判级，包括多网络事件和升级
第13—14条监测研判、职责与报告对象
第15—16条报告触发与时限
第17—19条报告内容和渠道、调查总结
第20条个人信息义务
第21—22条责任认定
第23—25条退回修订、监管风险提示、台账
第26条第二十六条原文
第27—29条法律责任及相应处罚情形，原文保留；不以本页建议替代实际责任认定
第30、32条监管内部责任、解释权及分支机构自身事件安排，区分于金融从业机构实施项
第33条生效与旧制度废止；检查期间和制度依据应使用适用版本

原文中的上位法名称和条号按收录版本保留；实际法律责任还须核对现行有效规定及事件发生时适用规则，不擅自改写已公布条文。企业专项通知、正式解释和其他适用义务应另行维护并定期核对。

第一章 总 则​

第一条​

为规范中国人民银行业务领域网络安全事件报告管理，根据《中华人民共和国网络安全法》、《中华人民共和国数据安全法》、《中华人民共和国个人信息保护法》、《中华人民共和国中国人民银行法》等法律、行政法规，制定本办法。

第二条​

金融从业机构在中华人民共和国境内发生中国人民银行业务领域网络安全事件时，应当按照本办法规定向中国人民银行或者住所地中国人民银行分支机构报告。非中国人民银行业务领域网络安全事件无须按照本办法规定报告。涉及国家秘密的，按照有关规定执行。

第三条​

本办法所称中国人民银行业务领域，指依据法律、行政法规，党中央、国务院决定，由中国人民银行承担监督和管理职责的业务领域。

  • 本办法所称中国人民银行业务领域网络安全事件（以下简称网络安全事件），指由于人为原因、遭受网络攻击、存在漏洞隐患、软硬件缺陷或故障、不可抗力等因素，对本机构建设、运营、维护、管理的中国人民银行业务领域网络或者处理的中国人民银行业务领域数据造成危害的事件。

第四条​

国家有关部门和其他金融管理部门等对网络安全事件报告有规定的，金融从业机构还应当从其规定报告。涉及危害计算机信息系统等违法犯罪的网络安全事件，金融从业机构还应当及时向公安机关报案。

  • 中国人民银行加强与国家有关部门和其他金融管理部门间的网络安全事件报告内容共享，按照国家有关部门规定向其通报网络安全事件，并根据其他金融管理部门需要向其通报网络安全事件。

第五条​

任何个人和组织有权向中国人民银行或其分支机构举报金融从业机构未按照本办法规定报告网络安全事件的行为。中国人民银行或其分支机构对举报人的相关信息予以保密。

第二章 网络安全事件分级​

第六条​

金融从业机构应当在本机构网络安全管理制度或者操作规程中明确网络安全事件分级标准（以下简称分级标准），将网络安全事件分为特别重大、重大、较大和一般四个等级。金融从业机构应当每年组织评估并视情更新分级标准。分级标准如有更新，应当报本机构主管网络安全的领导班子成员批准。

  • 金融从业机构制定分级标准时，应当综合考虑网络安全事件对业务、用户等的影响程度。金融从业机构针对与货币存取款、支付交易、税款缴库、银行间市场交易密切相关的中国人民银行业务领域网络制定分级标准时，应当差异化考虑业务高峰时段和非业务高峰时段网络安全事件对业务处理的影响程度。
  • 金融从业机构还应当结合中国人民银行业务领域数据安全管理相关规定，制定与中国人民银行业务领域数据遭到篡改、破坏、泄露相关的分级标准。
  • 金融从业机构可以针对网络安全等级保护三级以上的中国人民银行业务领域网络，逐一细化制定专门适用的分级标准。

第七条​

符合下列情形之一的，应当分级为特别重大网络安全事件：

  • （一）属于金融基础设施、直接服务5000万个以上自然人或者与货币存取款、支付交易、税款缴库、银行间市场交易密切相关的中国人民银行业务领域网络，主要功能在业务高峰时段出现两个以上省级行政区范围整体中断运行3小时以上或者单个省级行政区范围整体中断运行6小时以上的；
  • （二）提供金融服务的中国人民银行业务领域网络，主要功能出现中断、超时报错等情形，导致业务无法正常开展，经合理测算或者估算，已实际影响1000万个以上自然人或者100万个以上法人和其他组织的；
  • （三）中国人民银行业务领域核心数据遭到篡改、破坏、泄露的；
  • （四）致使泄露1000万条以上敏感个人信息或者1亿条以上个人信息的；
  • （五）网信部门、公安机关已明确应当分级为特别重大网络安全事件的；
  • （六）中国人民银行或其上海总部、省级分行、计划单列市分行研判并书面告知金融从业机构，应当分级为特别重大网络安全事件的。

第八条​

符合下列情形之一的，应当至少分级为重大网络安全事件：

  • （一）属于金融基础设施、直接服务5000万个以上自然人或者与货币存取款、支付交易、税款缴库、银行间市场交易密切相关的中国人民银行业务领域网络，主要功能在业务高峰时段出现两个以上省级行政区范围整体中断运行1.5小时以上或者单个省级行政区范围整体中断运行3小时以上的；
  • （二）提供金融服务的中国人民银行业务领域网络，主要功能出现中断、超时报错等情形，导致业务无法正常开展，经合理测算或者估算，已实际影响100万个以上自然人或者10万个以上法人和其他组织的；
  • （三）中国人民银行业务领域重要数据遭到篡改、破坏、泄露的；
  • （四）致使泄露100万条以上敏感个人信息或者1000万条以上个人信息的；
  • （五）网信部门、公安机关已明确应当分级为重大网络安全事件的；
  • （六）中国人民银行或其上海总部、省级分行、计划单列市分行研判并书面告知金融从业机构，应当分级为重大网络安全事件的。

第九条​

符合下列情形之一的，应当至少分级为较大网络安全事件：

  • （一）属于金融基础设施、直接服务5000万个以上自然人或者与货币存取款、支付交易、税款缴库、银行间市场交易密切相关的中国人民银行业务领域网络，主要功能在业务高峰时段出现两个以上省级行政区范围整体中断运行15分钟以上或者单个省级行政区范围整体中断运行30分钟以上的；
  • （二）提供金融服务的中国人民银行业务领域网络，主要功能出现中断、超时报错等情形，导致业务无法正常开展，经合理测算或者估算，已实际影响10万个以上自然人或者5000个以上法人和其他组织的；
  • （三）致使泄露500条以上征信信息、财产信息，或者致使泄露5万条以上个人信息的；
  • （四）遭受勒索恶意程序攻击，已对中国人民银行业务领域网络或者中国人民银行业务领域数据造成危害后果的；
  • （五）网信部门、公安机关已明确应当分级为较大网络安全事件的。

第十条​

符合下列情形之一的，应当至少分级为一般网络安全事件：

  • （一）提供金融服务的中国人民银行业务领域网络，主要功能出现单个省级行政区范围整体中断运行30分钟以上的；
  • （二）提供金融服务的中国人民银行业务领域网络，主要功能出现中断、超时报错等情形，导致业务无法正常开展，经合理测算或者估算，已实际影响1万个以上自然人或者1000个以上法人和其他组织的；
  • （三）中国人民银行业务领域网络主要功能出现中断、超时报错等情形，导致业务无法正常开展，已持续1小时以上的；
  • （四）中国人民银行业务领域数据遭到篡改、破坏、泄露，导致社会危害的；
  • （五）发生或者可能发生个人信息泄露、篡改、丢失的；
  • （六）网信部门、公安机关已明确应当分级为一般网络安全事件的。

第十一条​

金融从业机构制定与中国人民银行管理的金融基础设施业务交互功能异常相关的分级标准时，应当征求金融基础设施运营机构意见并协商一致。

第十二条​

金融从业机构发生网络安全事件时，应当对照分级标准，综合确定网络安全事件等级。同时符合多个分级标准的，应当按照最高级别确定网络安全事件等级。对照分级标准无法准确确定网络安全事件等级的，应当至少分级为较大网络安全事件。

  • 因灾害或者信息基础设施故障，导致金融从业机构多个中国人民银行业务领域网络同时发生网络安全事件时，应当先分别确定网络安全事件等级，再按照各网络安全事件等级中的最高级别，确定整体的网络安全事件等级。
  • 网络安全事件事态发展情况已达到更高级别分级标准时，金融从业机构应当立即调整网络安全事件等级。

第三章 网络安全事件报告​

第十三条​

金融从业机构应当明确应急处置与报告的职责分工，确保网络安全事件报告及时、准确、完整，不得迟报、漏报或者瞒报。

  • 金融从业机构应当健全网络安全风险监测预警体系，提升第一时间发现和报告网络安全事件的技术能力。
  • 金融从业机构发生网络安全事件时，应当立即启动应急预案，采取相应的补救措施。按照本办法规定报告网络安全事件时，不应迟滞业务恢复、存证溯源、用户解释、舆情应对等处置工作。

第十四条​

国家开发银行、政策性银行、国有商业银行、中国邮政储蓄银行、股份制商业银行、属于系统重要性金融机构的城市商业银行、系统重要性非银行支付机构、经营个人征信业务的征信机构发生网络安全事件时，应当向中国人民银行报告；其分支机构发生网络安全事件时，应当向住所地中国人民银行分支机构报告。中国人民银行所属单位及其管理的金融基础设施运营机构发生网络安全事件时，应当向中国人民银行报告。其他金融从业机构或其分支机构发生网络安全事件时，应当向住所地中国人民银行分支机构报告；在保障报告时效性前提下，证券、期货、基金机构发生网络安全事件时，经中国证监会派出机构转通报同级中国人民银行分支机构。

  • 中国人民银行计划单列市分行（不含深圳市分行）、地市分行接报辖区发生较大等级以上网络安全事件时，应当及时上报至中国人民银行省级分行。中国人民银行省级分行、深圳市分行接报辖区发生重大等级以上网络安全事件时，应当及时上报至中国人民银行。

第十五条​

金融从业机构发生较大等级以上网络安全事件后，应当于1小时内报送网络安全事件事发简要报告，并在24小时内报送网络安全事件事发报告。

  • 金融从业机构发生网络安全事件，尚未达到较大等级，但出现相关舆情信息进入社交媒体、搜索引擎或者新闻网站热点榜等情形，引发较大舆情的，应当按照前款规定报告。

第十六条​

对于重大等级以上网络安全事件，金融从业机构应当至少每隔2小时进行事中进展报告，直至处置结束。处置过程中如出现调高网络安全事件等级、处置取得阶段性进展、发现新的问题等重要情况时，应当立即报告。

第十七条​

网络安全事件处置结束后，金融从业机构应当于10个工作日内报送事后调查总结报告。无法按时报送事后调查总结报告的，金融从业机构应当先按时报送初步报告，说明承诺报送事后调查总结报告的日期并按时报送。承诺日期原则上应当在处置结束之日起40个工作日内。

第十八条​

金融从业机构可以通过电话、即时通信工具、电子邮件、传真或者中国人民银行指定的信息系统报送网络安全事件事发简要报告、事发报告和事中进展报告；采用电子邮件、传真方式报告的，应当通过电话或者即时通信工具确认中国人民银行或其分支机构已收悉。涉及工作秘密的，不得通过互联网渠道报告。

  • 金融从业机构应当书面报送网络安全事件事后调查总结报告，并加盖本机构或者承担报告职责内设部门公章。中国人民银行对网络安全事件事后调查总结报告另有电子化报送规定的，金融从业机构还应当按照规定电子化报送。

第十九条​

网络安全事件事发简要报告内容包括初次确定的网络安全事件等级、事发时间、依据网络安全事件分类分级相关国家标准确定的网络安全事件分类、影响的中国人民银行业务领域网络及其对应的网络安全保护等级、涉及的数据中心、报告机构和报告时间、报告人和联系方式。网络安全事件事发报告应当在事发简要报告内容基础上，增补影响范围和程度、已采取的措施和效果，网络攻击事件还应当增补分析研判情况。

  • 网络安全事件事中进展报告应当在事发简要报告基础上，增补说明最新确定的网络安全事件等级、影响的变化、处置进展和下一步拟采取的措施。如存在需中国人民银行或其分支机构协调支持处置的事项，应当一并说明。
  • 网络安全事件事后调查总结报告内容应当包括最终确定的网络安全事件等级、处置历程回顾、影响损失评估、技术或者管理问题根源分析、处置经验教训、后续改进措施、报告机构和报告时间、报告人和联系方式、签发人。

第二十条​

金融从业机构发生网络安全事件涉及个人信息泄露、篡改、丢失的，事后调查总结报告还应当说明本机构为有效避免网络安全事件危害所采取的补救措施、依法通知个人的情况和告知个人可以采取减轻危害措施的情况。

  • 对于重大等级以上网络安全事件，前款所列内容应当在事中进展报告中提前予以说明。

第二十一条​

较大等级以上网络安全事件事后调查总结报告内容，还应当包括直接负责的主管人员和其他直接责任人员的责任认定和对应责任处理情况。

  • 金融从业机构应当综合考虑动机态度、客观条件、程序方法、后果影响、挽回损失等因素，在本机构网络安全管理制度中明确责任处理的差异化适用情形。事后调查总结报告中对直接负责的主管人员和其他直接责任人员的处理措施，应当符合本机构网络安全管理制度规定。

第二十二条​

满足下列条件之一并且能提供相关证明材料的，金融从业机构可以根据直接负责的主管人员和其他直接责任人员具体承担职责，视情针对性减轻或者免除责任处理，但应当在网络安全事件事后调查总结报告中予以说明：

  • （一）已按本办法规定主动报告，同时按照本机构网络安全事件应急预案有关程序立即进行处置，尽最大努力降低影响的；
  • （二）网络技术创新和应用过程中因缺乏经验、先行先试造成网络安全事件，且没有主观过错的；
  • （三）已切实落实中国人民银行和本机构网络安全、数据安全相关管理制度要求，并严格执行本机构相关操作规程的。

第二十三条​

中国人民银行或其分支机构认为金融从业机构网络安全事件事后调查总结报告存在内容缺失、原因分析不清、影响损失评估失实、责任认定或者处理不当等情形，退回事后调查总结报告并正式反馈修改意见的，金融从业机构应当在收到反馈之日起10个工作日内完善事后调查总结报告并重新报送。

第二十四条​

金融从业机构收到中国人民银行或其分支机构通报的其网络产品、服务存在运行异常、疑似数据泄露、安全缺陷、漏洞等风险提示时，应当立即组织核查，采取必要补救措施。经核查风险属实并构成网络安全事件的，金融从业机构应当按照本办法规定进行报告；风险不属实或者尚不构成网络安全事件的，应当根据通报要求按时反馈风险核查处置情况。

第二十五条​

金融从业机构应当建立网络安全事件台账，完整准确记录网络安全事件事发时间、事发报告时间、中国人民银行或其分支机构接报联系人和对应的网络安全事件报告内容。中国人民银行分支机构应当相应建立辖区网络安全事件台账。台账应当至少留存三年。

第四章 法律责任​

第二十六条​

中国人民银行或其分支机构根据金融从业机构报告处置网络安全事件的情况，可以按照中国人民银行执法检查有关规定明确的程序，对金融从业机构依法实施检查，金融从业机构应当予以配合。

第二十七条​

金融从业机构未按照本办法规定报告网络安全事件的，中国人民银行或其分支机构依照《中华人民共和国网络安全法》第五十九条予以处罚。

第二十八条​

金融从业机构收到中国人民银行或其分支机构通报的风险，如果风险属实，但未立即采取补救措施或者未按照本办法规定按时反馈核查处置情况的，中国人民银行或其分支机构依照《中华人民共和国网络安全法》第六十条予以处罚。

第二十九条​

金融从业机构在接受中国人民银行或其分支机构检查时，主动供述检查人员尚未掌握的未按照本办法规定报告网络安全事件行为的，应当从轻或者减轻处罚。

第三十条​

中国人民银行分支机构未按照本办法规定报告网络安全事件，存在失职失责行为，造成重大损失、严重后果或者恶劣影响的，对直接负责的主管人员和其他直接责任人员依规依纪依法予以严肃追责问责。

第五章 附 则​

第三十一条​

本办法下列用语的含义：

  • （一）金融从业机构，是指金融机构以及经中国人民银行批准设立或者认定的其他机构。
  • （二）网络，是指由计算机或者其他信息终端及相关设备组成的按照一定的规则和程序对信息进行收集、存储、传输、交换、处理的系统。
  • （三）业务高峰时段，是指按年度统计的分时平均业务量超过日平均业务量百分之三的时段，或者依据本机构制度列明的其他合理计算方式确定的时段。
  • （四）整体中断运行，是指因网络安全事件，某一时段内未处理和处理失败业务量与正常情况全部业务量的比例，经合理测算或者估算，已经超过百分之七十。
  • （五）主要功能，是指与用户身份认证或者业务交互相关的功能。
  • （六）本办法所称“以上”均含本数。

第三十二条​

本办法由中国人民银行负责解释。

  • 中国人民银行分支机构自身发生的网络安全事件应当向其上级行报告，报告时效、途径和内容等要求按照本办法对金融从业机构的规定执行。

第三十三条​

本办法自2025年8月1日起施行。《银行计算机安全事件报告管理制度》（银发〔2002〕280号文印发）、《中国人民银行计算机系统信息安全报告制度》（银发〔2010〕366号文印发）同时废止。