老周是被一个电话叫进会议室的。

九月的第二个周一，上午十点，合规部的小林把投影切到一张空白表格上，抬头问了一句：「今年的数据安全风险评估报告，放在哪个目录了？」

会议室安静了大概三秒。

老周不慌。他在信息技术部干了十年，从机房值班做到安全岗，自认为材料是齐的。回到工位，他打开共享盘，拖出三份 PDF：三月份刚做完的等级保护三级测评报告、去年底的商用密码应用安全性评估报告、还有一份渗透测试报告。链接发进群里，附了两个字：「都在。」

小林回得很快：「周老师，这三份都不是。」

他后来承认，那一刻有点不服气。

中午两人站在茶水间，小林把差别讲得很慢。

等保看的是系统底线，问的是「这套系统安全措施到位了吗」；密评只看密码用得对不对，算法、密钥、证书那一摊；渗透测试是找漏洞，能不能打进来？数据安全风险评估问的是另一件事——我们手里究竟有哪些数据，它们从哪儿来、往哪儿去、谁碰过、什么时候被谁导出过，万一出事会波及谁。

问的对象都不一样，答案当然不能互相套用。共用一部分证据没问题，比如权限配置、审计日志、网络拓扑，这些底稿可以拿来复用；但数据安全风险评估报告必须是一份独立的、以数据资产和数据处理活动为主线的安全报告。

老周把那三份 PDF 收进一个新建的文件夹，命名「可复用资料」。这个动作，后来省了项目组不少事。

那天下午，他把文件按四层摊在桌上，从厚到薄。

最上面是几部法：网络安全法、数据安全法、个人信息保护法、证券法。它们只说「必须做」，没给流程，也不给实施表格。

第二层是刚施行没多久的《网络数据安全风险评估办法》，国家网信办、工业和信息化部、公安部联合公布的第 24 号令，2026 年 6 月 18 日发布，8 月 20 日施行。第五条写得直白：处理重要数据的，每年度开展一次风险评估；重要数据安全状态发生重大变化、可能对数据安全造成不利影响的，应当及时就发生变化及其影响的部分开展评估；只处理一般数据的，鼓励至少每三年一次。往后翻还有几条容易被跳过的——自行评估要指定专人负责，委托第三方要订合同把权责写清；报告要按主管部门的要求编制报送，省级以上部门可以检查核验，必要时还可以要求你委托通过认证的评估机构来做。

第三层是证监会第 218 号令《证券期货业网络和信息安全管理办法》，2023 年 5 月 1 日就施行了，比 24 号令早三年。这一层管的是证券行业自己：等保定级备案、投资者个人信息保护、重要信息系统的日志和备份、外包与应急处置、安全事件上报。追责的时候，翻的是它。

最底下是几本标准，做检查表的时候才用得着：JR/T 0158-2018《证券期货业数据分类分级指引》，GB/T 45577-2025《数据安全技术 数据安全风险评估方法》（2025 年 11 月 1 日实施），JR/T 0250-2022《证券期货业数据安全管理与保护指引》，再垫上等保 2.0 三级和密码应用的要求。

老周在便签上记了一句，后来贴在了项目看板右上角：24 号令第六条留了口子——有关主管部门对本行业、本领域另有规定的，从其规定。所以券商不是把国家那一套照抄一遍就完事，行业标准要压在上面看。还有一处措辞也值得留意：正式稿写的是「参照有关国家标准开展」，标准给的是方法论和报告框架，不是逐条打勾的强制清单。

四层文件摆完，他大概明白小林为什么不收那三份 PDF 了。

小林要的第一份东西，不是报告，是一张表：重要数据清单。

老周第一版交得挺快。他按 JR/T 0158 把公司数据打了 1 到 4 级——公开披露的经营信息 1 级，内部办公 2 级，客户身份、资产余额、成交明细 3 级，跨机构汇总的清算类 4 级。定级的依据是指引里那三个要素：影响对象是行业、机构还是客户，影响范围是本机构还是跨行业，影响程度是严重、中等还是轻微。他在备注里顺手写了一句「3 级以上即重要数据」。

第二天被退了回来。小林在那个备注旁边画了个圈：「周老师，这是两把尺子。」

JR/T 0158 的 1 到 4 级，是证券行业内部的管理标尺，用来决定谁可以看、要不要脱敏、留存多久、走哪条审批。而「重要数据」是数据安全法体系里的法定身份，得对照国家重要数据目录和行业目录去认，认上了才触发 24 号令的年度评估和报送义务。3 级、4 级不等于重要数据；反过来，某些单看只到 2 级的数据，一旦在数仓里聚合到足够规模，也可能被认进去。指引里专门提醒过：机构内的数据仓库、大数据分析用的数据宜单独划类，考虑升级。

老周返了两轮工。这一轮最耗人，也最有价值。后面所有的范围、频次、报不报送，全在这张清单上。

最后交出去的是两份东西：《数据资产清单》，写清数据来源、存储位置、使用部门、传输链路；以及《重要数据识别清单》，把法定身份单独标出来。检查组进场，第一份要的通常就是这两张表。

第一次报评估范围，老周填了六个系统：集中交易、账户管理、资金清算、适当性管理、投资者信息库、风控。都是硬骨头，也都填在了点上。

小林拿着笔一路往下加：测试环境、运维堡垒机、客服工单、开户小程序、OA 里那些带附件的审批流、外包驻场开发用的代码仓库。

走到测试环境那台机器，两个人都停了一下。开发库的客户表里，身份证号、手机号、资产余额全是真的，字段完整，一次都没脱敏。开发同事说得也实在：「造不出像样的测试数据，脱敏的数据会失真，用真的跑起来最省事。」

这件事 218 号令第十六条写得清清楚楚：除必须使用敏感数据的情形外，测试环境涉及的敏感数据应当脱敏；未脱敏的，要采取与生产环境同等的安全控制措施。老周把截图贴进底稿，没写「管理不规范」这种话，写的是哪台机器、哪张表、哪个字段、哪天导出的、谁导的、现在还有几份副本。

后来他跟人说，评估范围这东西，按系统报最容易漏，按「数据在哪儿出现过」去报，才报得全。投资者数据不会只在核心系统里存着。

真正让这套东西活起来的，是十月那次港股通的业务评审。

业务部门准备把一批投资者资料提供给境外合作方，流程已经走到用印，合同连数据字段附件都定稿了。小林在会上问：评估做了吗？业务那边有点急：「数据还没出去，评估不是走个备案吗？」

老周这回没接话，回去把 24 号令第五条又看了一遍。原文并没有「对外提供必须专项评估」这几个字，写的是「重要数据安全状态发生重大变化可能对数据安全造成不利影响的，应当及时对发生变化及其影响的部分开展风险评估」。共享给第三方、委托外包处理、系统重大改造、数据出境，是行业把这些场景落到这句话底下的；真到了出境，还要再接数据出境安全评估那条线，涉及个人信息的另有个人信息保护影响评估。这几套制度各有各的触发条件和报送口径，如果只做「做个专项评估」容易在汇报时被追问住。

他在项目底稿边上写了一行给后来人看的话：这些不是年报里补一笔的事，是前置条件。数据一旦出去就收不回来，事后补的那份评估，证明不了当时做过判断。

后来他们做了一张触发台账，只有四列：什么事、什么时候提的、谁负责启动、评估结论挂在哪份报告里。业务立项会过一遍这张表，比年底翻邮件找记录靠谱得多。系统重大版本上线、架构改造、外包驻场、发生安全事件后的复盘，陆陆续续都进了这张表。

只有处理公开行情、公开资讯，既不碰投资者信息、也不涉及重要数据的那类系统，才轮得上「三年一次」的宽松节奏。

项目是九月底立的，跨了三个多月。回头看，其实就是一段一段把问题问完。

先组队。IT、安全、合规、业务部门各出人，另外请了一家第三方机构。24 号令要求自行评估指定专人负责，老周被点了名；选机构时小林坚持看机构能力认证和合同里的权责条款，理由很朴素——将来监管来问，得说得出谁做的、按什么做的、出问题谁担着。

接着摸家底。每张表都要追到来源、存储、使用部门、传输链路。这一步没有捷径，靠的是把业务、开发、运维三方拉到一个屋里，一条链路一条链路对。对不上的地方当场标红，第二天补。

然后是核查。采集、传输、存储、使用、共享、销毁，一段一段走；翻权限矩阵、看脱敏规则、查审计记录、看备份和加密、核对水印、把外包合同里的数据条款逐条挑出来。在这里翻出第二个问题：某套重要信息系统的业务日志只留了三个月。小林提醒，218 号令第十八条要的是业务日志保存五年以上、系统日志六个月以上，不是笼统一句「六个月」。这一条差点被他们自己写进「符合要求」里。

再往下是定级。可能性乘影响程度，划高、中、低。老周第一次给「客服坐席可批量导出客户手机号」打了中，被小林翻了回去：能一次性导全量、导出无审批、无水印、事后无审计，可能性就不低。定级不能凭印象，判断依据必须写进底稿，写清楚为什么是这个分。证券行业常见的高风险，大多长这个样子——投资者身份与资产信息越权访问或整表导出、测试环境留着生产真实交易数据、外包厂商管控不足把数据带出去、弱口令和日志留存不达标、共享没审批也没脱敏。

处置方案最费笔头。高风险立即整改、限期闭环，必要时先暂停相关数据处理活动；中风险定措施、定责任人、定时间；低风险纳入日常运营盯着。每一条下面都得回答同一个问题：改完之后剩下的风险，能不能接受，谁签字同意接受。老周说这一栏最难写，因为「加强管理」四个字在这里过不去。

正式报告出来，合规复核、分管领导审批，属于要报送的按主管部门渠道提交。24 号令给监管留了检查核验这一手，报告交上去不等于结案。年底前他们又做了一轮整改复测，没销号的风险项挂进日常巡检，台账最后一列添了「复测人」和「复测日期」。

归档是十二月底。老周把目录截图发进项目群，没人回复，但后来检查时救了场：

实施方案；数据资产清单、重要数据清单和分级定级表；现场调研记录与控制措施核查底稿；风险清单（风险描述、等级、根因、整改措施、责任人、时限）；正式评估报告；整改台账与整改验证材料；最后是全程留痕的归档包——会议纪要、访谈记录、版本变更、审批签字、报送回执。

前六份是成果，第七份是证明你真的做过。迎检的时候，前者说明结论，后者说明过程，缺哪一头都不好答。

年底一次同业交流，三四家券商的安全岗凑一桌，聊下来老周听着听着就笑了——上半年他们基本踩了个遍，别人也没躲开。

有人只盘系统不盘数据，重要数据清单拿不出来，第一轮材料就被打回；有人风险等级全凭拍脑袋，检查组问一句「这个高是怎么算出来的」，翻遍底稿找不到矩阵；有人整改计划写得漂亮，通篇没有责任人、没有时间节点；有人把等保报告改个封面就当数据风险评估报上去——就是老周九月那个动作；有人等数据共享完、合同都执行半年了才想起来补评估，补出来的东西怎么解释都别扭。

还有两家，一家测试环境里躺着完整的生产客户表，一家业务日志只留三个月。这两条在证券行业几乎成了固定扣分项，偏偏都不难改，只是没人专门去看一眼。

科技部陈总只给了十分钟。老周没讲法条，也没放那张四层文件的照片，只说了四句。

第一，先把数据分类分级做完。摸清家底是所有数据安全工作的底座，分级没做完，后面范围、频次、控制措施全是猜的。

第二，年度评估和触发式评估分开管。年度的排进日历，触发的挂进台账，别指望谁记得住。

第三，交报告不算结束。整改销号、复测、纳入日常运营，这一段才是真正降低风险的部分。

第四，评估、等保、密评、渗透和安全审计协同排期、复用证据，别让同一批业务一年迎四拨人、填四遍同样的表。

陈总问了一句「那张重要数据清单在哪？」，老周说已经在共享盘里了。会就散了。

检查通知下来那天，老周没再手忙脚乱地翻共享盘。小林把去年的底稿按目录打包发过去，触发台账上又多了一行，是开户系统的一次改版，日期、责任人、评估结论都填好了。

他后来跟新来的同事说，这活其实不复杂：搞清楚手里有什么数据，搞清楚谁在动它，把每次动它之前的那次判断留下来。

别的都是固定格式。