企业官网建设流程全解析

或许很少人去思考过这样一个问题，在数据安全中为什么分类在分级前面？这二者有何区别，又有何联系？先说判断：分类是为分级服务的，它的终点是完成数据识别。

GB/T 43697-2024《数据安全技术 数据分类分级规则》这份行业标准在24年发布，金融行业的各主管部门需要照着它制定本行业的规范，数据处理者需要照着它建自己的清单，一段时间下来，多数单位的动作已经从"要不要做"变成了"怎么把这轮做完，做好"。

金融行业在进行分类分级工作时，有一个常见的场景：分类分级工具装进业务库、扫出上千张表和几十万甚至上百万字段，可清单到手之后反而更不知道下一步往哪走：注释残缺，字段名是一串英文缩写，一张表里什么都有，找不出切第一刀的位置。

卡住分类分级工作的，往往是规则本身还不够清楚。一是规则覆盖不到：现有的分类分级规则是按业务条线、按数据大类写出来的，落到具体业务系统里那些字段名各异、口径混杂的表上，常常找不到能直接套用的条目。二是规则定得不够细：以往的标准规范偏粗，一个类目下面吊着几十上百个字段，边界画在哪里没有明说，遇到跨类别的字段就只能靠个人理解去猜。模棱两可的地方一多，不同的人对同一张表同一个字段就会给出不同的分类分级结果，返工也就从这里开始。

要找到下手的位置，得先回答一个看起来很小的问题：这份标准为什么叫"分类分级"，不叫"分级分类"？顺序不是随手写的，它对应着两件事的因果关系。

🗂️一、为什么把"分类"放在"分级"前面

数据分类动的是业务条线、关键业务、业务属性三层，一路往下切；数据分级要识别的是重要性和影响程度这些要素。两套语汇看起来各说各话，实际上是相关联的，两者之间存在"输入－转换－输出"的逻辑关系。分类给出的是输入：这份数据服务哪个业务领域、落在哪个流程环节、描述的是什么内容；经过中间一步转换，输出的就是分级要识别的那几类要素。

中间这一步转换，它指的是：把分类时已经梳理清楚的业务属性，换一个安全的视角重新看一遍。 业务属性回答的是"这份数据在业务里是干什么用的"，转换要回答的是"从保密性、完整性、可用性以及一旦泄露、篡改、损毁会波及谁的角度看，这些属性意味着多大的风险"。比如分类里"交易基本信息"这一项说的是"这批数据描述的是交易"，换到安全视角就变成"涉及的是特定场景中的哪一类交易数据、这类数据一旦被泄露会造成什么后果"。换个视角看同一批属性，出来的就是分级要素。

举个例子，如分类里的"描述对象"和"数据主体"，正是分级要素里"群体"这一项的输入；分级要素里的"领域"，也要靠分类中的业务领域、流程环节、内容主题这些业务属性才识别得出来。输入给得越准，输出才判得越稳。

中间的转换，是按安全因素把业务属性重新看一遍。

反过来说，分类切得越粗，分级就越没有依据。把一整个业务系统的数据笼统归成"业务数据"一个大类，到分级那一步只能凭感觉判，判完也没有可复核的理由。这也是为什么国标要花力气去定义那些看起来有点琐碎的业务属性，它们是分级脚底下那块地。

🧭二、两笔账分开算：有没有行业标准，路径不一样

动手之前要先看清一件事：本行业有没有主管部门认可的数据分类分级标准规范。有，就照着本行业的规则细化执行，国标在这里是方法参考；没有，或者本行业规范覆盖不到某些数据类型，才按国标执行。业务横跨多个行业领域的单位，可以分别按各自行业的标准规范细化。

这两条线是两笔账，产出的东西不一样。行业主管（监管）部门那一侧，负责制定本行业的分类分级标准规范、明确本行业重要数据的识别细则、提出哪些数据建议确定为核心数据，并组织本行业的数据处理者开展分类分级、指导他们报送目录。数据处理者这一侧，最终要拿出来的是分类分级清单，以及重要数据和核心数据的目录。

有没有行业标准，是两条路径：

业务领域横跨多个行业时，可分别按各自的行业规范细化执行。

没有行业标准不等于不能开工，只是分类的自主权落到了自己手上，规则得自己拟，细则得自己写。这对有能力沉淀标准的单位是好事，对没有经验的单位则意味着一轮更长的试错。

路径看清了，接下来就是动手。而无论走哪条路径，第一件要做的事都一样：把数据资产的家底盘清楚。规则再清楚，也要先知道自己手上到底有哪些表、哪些字段，才谈得上往里套。下一步就从这个最费人力、也最容易做浅的环节说起

🧾三、资产梳理：工具扫得出字段，扫不出业务含义

资产梳理是国标流程里最费人力的一步。把分类分级工具部署到业务环境里，扫描库表资产，拿到的是表名、表注释、字段名、字段注释，这些是坐标，不是答案。字段的业务含义要靠另外几路取证去补。

这里讲的主要是结构化数据的分类分级，也就是业务和信息系统里的那些库表。一个字段一格值，能扫、能数、能按行按列去切，这也是多数单位第一轮要啃下来的部分，做完它，家底的大头就清楚了。（非结构化数据（文档、影像、音视频、日志等）的分类分级是另一套做法，难点在怎么切内容单元、怎么从非结构内容里识别出敏感项）

先说困境。扫出来的初步清单，注释往往残缺得厉害，一份三十个字段的表，注释有时能写全一半已经算不错。这时候没人说得清某个字段到底存的是谁的数据、用来做什么，分类分级也就无从下手。

补信息有几条路，通常要一起走：①查阅业务和信息系统的相关文档，包括建设方案、用户手册、技术方案、汇报材料，以及数据字典、元数据字典、数据标准、数据库设计文档这类解释表结构的材料；②带着文档里没讲清的问题，有针对性地找业务人员做访谈；③请业务人员做系统演示，看业务流程和功能怎么走；④借一个演示账号自己登录进去，看不同角色分别能做什么操作、数据在环节之间怎么流。四路走完，对这套系统的理解才算够用。

近两年多了一条路：用AI结合表名、字段名和数据内容来推断字段的业务含义，补注释的效率确实高。但它在一类场景会失效，字段里存的不是真实内容，而是一串代码。以卫生健康行业为例，身份证件类型这样的字段，库里存的可能是 01、02 这样的编号，编号与含义的对应关系写在另一张字典表里；找不到那张字典表，AI识别到的数据内容就只是一串数字，推断出来的注释不可信。

还有一类场景更棘手：表名和字段名本身命名得极不规范，而字段里存的又不是真实内容。两边同时不成立的时候，AI 能抓的线索全都断了。前一种情况里字段名虽然看不出业务含义，至少还留了 tbl_patient_info 这样的英文全拼，能猜个七八分；后一种情况里至少还有值域特征可以反推，比如一个字段里全是 18 位数字、校验位还对得上，那大概率是身份证号。可要是表叫 T_001、字段叫 C_003，值又是一堆 0/1 和编码，那么表名给不出语义、字段名给不出语义、值域也给不出语义，三条线索同时归零。这种表往往还不是少数，老系统、外购系统、多轮外包迭代过的系统里成片出现。

这时候没有捷径，只能回到人工。一是实地调研：到业务现场看这套流程实际怎么跑、这些数据由谁在什么环节产生和录入、哪些字段是必填、哪些字段实际几乎不用。二是访谈：找最熟悉这张表的岗位聊，把每个字段的业务含义、取值口径、与其他系统的对应关系逐个问清楚，边问边在清单上标注，问完一轮再回填一版，看不清的继续追。这一轮花的时间比用工具扫一遍多得多，但它是唯一能把这类表讲明白的办法。工具负责把面铺开，人工负责把最难的少数表啃下来，两者缺一不可。

梳理的时候还要把数据的几组属性一并问清楚：描述对象是哪一类，数据主体属于谁，用途是什么，经过哪些处理环节，存放在哪里，业务功能对应哪条流程。这几组属性问全了，后面制定内部规则才有素材。

📋四、分类怎么切：先切业务条线，再切关键业务，最后切业务属性

再说一个容易被跳过的判断：分类的第一刀不落在技术上。国标给的顺序是先按行业领域分、再按业务属性细化。一个单位如果同时经营医疗和教育两块业务，业务条线至少能切出两条；每条业务线再按业务范围、运营模式、业务流程细化出关键业务；到了关键业务这一层，才轮到选业务属性。

选属性这一步很讲究。可选的业务属性有九个方向：业务领域、责任部门、描述对象、流程环节、数据主体、内容主题、数据用途、数据处理、数据来源。选哪一个取决于你的数据管理和使用需求，不需要全用，但也不能随手挑。想按部门落实责任就选责任部门，想按数据流向管就选流程环节，想按加工形态管就选数据处理。

落到实际操作里，还有一个常见做法值得说一句：当一个单位的业务范围比较广、条线拉得比较开时，一级分类往往从"业务领域－责任部门"这一对组合开始切。这么做的好处是每一步都有人对得上：业务领域让清单能反映业务全貌，责任部门让每一类数据当场就有归属，后面推分类分级、做数据治理，责任落地不需要再重新找人。对业务单一的小单位，这一层可以省掉，直接从业务对象切；但业务横跨几块、部门之间数据又有交叉的单位，先把这一层立住，后面很多争执会少很多。

切完之后，把结果整理成规则有两种做法：一种是把三级串成一条可读的标识，让人一眼看出数据的来路；另一种是把主题相似的数据子类归并到一起，减少类别数量。两种做法不冲突，规模大的单位常常先用前一种理清来路，再用后一种收敛类别。

🧩五、分类的最后一层，要同时带上业务属性和安全属性

这里有个坑，很多第一轮做分类的团队都踩过：只按业务切下去，会漏掉相当一部分敏感项。从业务角度分完，最终还是要落到具体的表上，而一张表通常不止一类数据。

同一张表里，可能既有用户数据，又有业务数据，还有系统运维数据，上报时间、数据更新时间这类字段就属于运维痕迹。按描述对象继续往下切，往往需要把一张表拆开，字段分别归属。举个常见的例子：一张三十来个字段的业务表，里面通常有一批是填报人、联系方式这类用户信息，一批是业务单据本身的业务数据，剩下的属于上报时间、创建人、状态位这类运维痕迹，三类数据混在一张表里。到这一步，表就不再是分类的最小单位了。

接着上面，用户数据这一支还能继续往下分：个人用户与组织用户两类。个人用户这一边，再分个人基本信息与敏感个人信息(两类的数据级别不一样)；组织用户那一边，对应的是组织基本信息与商业秘密信息一类(两类的数据级别不一样)。所以数据分类的最后一个层级，往往是业务属性和安全属性同时作用的结果，走到最末一级数据子类，级别的高低其实已经“写”在类别的名字里了。如下：

📊六、分级怎么定：四步走、八类要素、六个影响对象

分级这一步有固定的动作顺序，跳步就定不准。国标给的是四步：确定分级对象，识别分级要素，做数据影响分析，综合确定级别。这四步的次序不能调换，因为后一步的输入正是前一步的输出。

第一步要先把对象定清楚。数据项、数据集、衍生数据、跨行业领域数据，这四类要分别考虑。数据项通常表现为表里的某一列字段；数据集是多个数据记录组成的集合，一张表或一批记录都算；跨行业领域数据指从一个行业领域流转到另一个行业领域的数据，以及两个以上行业领域的数据融合加工产生的数据。

第二步识别八类分级要素，它们分三组。领域、群体、区域、重要性属于定性描述；精度、规模、覆盖度属于定量描述；还有一类只服务于衍生数据：深度，它刻画的是一份数据经过统计、关联、挖掘或融合之后，对描述对象隐含信息与多维度细节的刻画程度，比如能不能还原出经济运行情况、行踪轨迹、对象关系、产业供应链。定性要素靠判断，定量要素靠数数，深度要看加工到了哪一层。（关于定性与定量的分级要素后续也会单独展开一篇描述）

这八类要素在国标里是名称和定义，落到具体数据上怎么理解，看几个示例最直观。下表用卫生健康行业的几类数据做对照，左边是要素，右边是判断这个要素时要看的东西。

把这张表横过来读，能看出一个规律：定性要素回答"这份数据是什么、涉及谁、在哪儿、有多重要"，定量要素回答"这份数据有多准、有多大、覆盖多广"，深度则只对加工过的数据生效。判断顺序上，一般先看定性再看定量，定性定的是这份数据值不值得关注，定量定的才是最终级别能到哪一档。规模这一项尤其容易被忽略：同一类数据，覆盖几百人还是覆盖几千万人，级别可能差出好几档，这也是后面讲动态更新时反复出现的那条线索。注：一般在行业领域的数据分类分级标准规范中会有定义。如卫生健康、教育等各行业会对重要数据和核心数据的数据规模作出明确说明。

第三步影响分析看两个东西。影响对象六个，各个行业一般都是通的：国家安全、经济运行、社会秩序、公共利益、组织权益、个人权益。影响程度各行业的命名可能并统一：国标分特别严重危害、严重危害、一般危害三档，部分行业标准可能命为"轻微危害"。碰到对影响程度名称不同的情形，要判断它实际落在国标三档里的哪一档，做一次映射（影响对象与影响程度对应的参考说明），不能各说各话。

判断的基准也有讲究。影响对象落到国家安全、经济运行、社会秩序或公共利益时，以国家、社会或行业领域的整体利益为基准；只落到组织权益或个人权益时，才以组织或公民个人的权益为基准。这里还有一处需要留神：当影响对象是大规模的组织权益或个人权益时，要同时研判它会不会进一步波及国家安全、经济运行、社会秩序或公共利益，量变会引起质变。

最后一步按级别确定规则落定。国家安全、经济运行、社会秩序、公共利益这四个对象造成的危害越高，级别越高；组织权益与个人权益无论危害多重（不考虑规模影响），一般对应的是一般数据。多个要素、多个影响对象或影响程度同时成立时，按就高从严取最高的那一档。

⚠️七、重要数据不是"重要的数据"

有个高频误读值得单独说：重要数据不是形容词，是类别名。它指的是特定领域、特定群体、特定区域或达到一定精度和规模的数据，一旦被泄露或篡改、损毁，可能直接危害国家安全、经济运行、社会稳定、公共健康和安全。

判定的关键落在"直接"两个字上，看的也是危害有没有外溢到公共利益以上。仅影响组织自身或公民个体的数据，一般不作为重要数据。这句话常被读反：一份数据对一家企业再要紧，只要它的危害不外溢，就不会因为"对企业很重要"而升级。反过来说，一份看起来零散的数据，如果它关系到特定区域或特定群体的公共利益，反而可能落在重要数据的范围内。

这里可以说是整篇最需要掰开的一处：经常有企业把"对企业自身很重要的数据"直接理解成重要数据，然后照着重要数据的口径去管。客户名单、核心配方、成本底价、未公开的经营数据，这些对一家企业确实要紧，丢掉任何一份都可能伤筋动骨，但它们影响的是企业自己的权益，不外溢到公共利益，在分级里对应的是组织权益这一侧，落在一般数据的范围里。此"重要"非彼"重要"：一个是企业内部的轻重排序，一个是标准里的类别名称，两者讨论的根本不是同一件事。分不清的后果是双重的：把自家重要数据抬成"重要数据"，会凭空多出一大堆本该按更高要求做的动作，报告也报不到点子上；反过来，真正够得上重要数据的那几类，反而可能因为名单里挤满了自家数据而被稀释掉。一句话记住：重要数据看的是外溢，不看单位自身的珍惜程度。

核心数据的口径更窄。它指向对领域、群体、区域有较高覆盖度，或者达到较高精度、较大规模、一定深度的数据，一旦被非法使用或共享可能直接影响政治安全。两个级别的门槛差在危害的对象上，不在数据的体量上。

上图里"仅影响组织自身或公民个体"这一格，还有一处需要补充说明：它的"一般不作为重要数据"是有条件的，规模上去之后是可能升级的。一份只涉及个人的数据，单看影响对象确实落在个人权益这一侧；但当它的覆盖面扩大到一定规模，量变就会引起质变：几百万、上千万人的信息汇聚到一起，一旦泄露影响的就是特定区域、特定群体的公共利益，甚至触及社会秩序，这时候它就不再是"仅影响个人"的数据了。前面反复提到的"规模"这一项分级要素，起作用的地方正在这里。所以判断一份数据是不是重要数据，不能只问它涉及谁，还要同时问它涉及多大规模。

📈八、落到一般数据：级别怎么细分，最低参考级别怎么用

中间一层定完之后，工作量最大的是底部。一般数据涵盖面最广，不细分就落不了具体的保护措施。国标给了三套细分框架，分 2 级、分 3 级、分 4 级，各行业可以不一样，实践中以细分 3 级和 4 级居多。

细分之后马上会遇到一个具体问题：某类数据该从哪一级起步？国标给出的是"最低参考级别"，可以直接当清单的初始值用。在 4 级框架下，敏感个人信息不低于 4 级，一般个人信息不低于 2 级；组织内部员工个人信息、去标识化的个人信息、个人标签信息都不低于 2 级；公共数据这一侧，有条件开放或共享的不低于 2 级，禁止开放或共享的不低于 4 级。换成 3 级框架，敏感个人信息不低于 3 级，一般个人信息不低于 2 级，有条件开放或共享的公共数据不低于 2 级，禁止开放或共享的不低于 3 级。

"最低"两个字要读准：它是下限，不是建议值。实际定级可以更高，不能更低。这一条在评审里最容易被问到，把敏感个人信息定在 2 级，无论理由写得多充分，都会被直接退回。

🔄九、衍生数据与动态更新：级别会降，也会升

最后一个容易被想当然的地方：加工过的数据不等于更安全的数据。按加工程度，数据分原始数据、脱敏数据、标签数据、统计数据、融合数据五类，后四类都属于衍生数据。衍生数据的级别要参照原始数据级别，再结合加工后的深度等要素重新判断，方向并不唯一。

脱敏数据的级别可以比原始数据低，这符合直觉；标签数据和统计数据的级别则可能降，也可能升。一个反直觉的例子是：反映国民经济运行总体情况、反映行业领域产业发展态势、影响国家宏观调控能力的未公开统计数据，级别要设得比原始数据更高。原因不难理解：原本分散在各处的明细数据不敏感，汇总之后反而成了能够影响宏观判断的信息。融合数据同样如此：把大量多维数据关联、挖掘、汇聚之后，如果出现了更敏感、更深层的内容，级别要升高；如果结果降低了标识化程度，级别可以降低。——融合数据一般有特定的应用场景，判断它的数据级别高低，首先要发问“这融合数据是做什么用的？基于融合数据的应用场景分析其影响程度”，即从融合数据用途（业务属性之一，也是数据分级要素的“重要性”）去分析。

级别定完不等于一劳永逸。数据的业务属性、重要程度和可能造成的危害程度一变，级别就要跟着动。触发动态更新的情形有八类，每一类的触发逻辑和处置动作都不太一样，下面逐类说清楚。

一是数据规模变化让原级别不再合适。比如某地市的医保参保人信息，原先只覆盖本地几万人，定在一般数据；随着区域统筹推进，数据汇聚到省级、覆盖几千万人，量级上去了，一旦泄露的影响面就从局部扩大到区域公共利益，级别要重新研判。处置上不只是把某张表的级别调高，还要同步更新它所在的类别、目录条目和访问控制策略。

二是内容没变，但时效性、规模、应用场景或加工方式明显变化。典型的是统计数据从"内部参考"转为"对外发布"：字段一个字没改，但用途变了、可访问范围变了，敏感程度随之变化。反过来，一份三年前还有敏感性的经营数据，在业务终止、时效过去之后，危害程度也会下降。这一类最容易被漏掉，因为数据本身看起来没动。

三是多个原始数据直接合并。比如把分散在几个部门的企业注册信息、纳税信息、社保缴纳信息不加加工地拼到一张宽表里，单个部门的数据都只影响组织权益，合并之后就能完整刻画一家企业的经营状况，可能触及经济运行，级别要按合并后的整体重新判。

四是从不同数据里各取一部分合并成新数据。这跟上一类合并的区别在于取了子集：把用户表里的身份标识和订单表里的消费记录抽出来拼成一份新清单，字段都来自原有数据，但组合之后形成的是一个人完整的消费画像，敏感度高于任何一份来源数据。

五是不同数据类型汇聚融合形成新的类别。这类数据在分类上就已经是新东西了，可能落进一个新的数据类别，而不只是级别变化。地理轨迹叠加通信记录形成的关系网络、消费数据叠加健康数据形成的个人画像，都属于这一类。分类变了，级别自然要跟着重新定。

六是做了脱敏、删除关键字段或去标识化。这一条方向通常是往下降的：把身份号做了掩码、把姓名和联系方式整列删掉之后，直接识别到个人的能力下降，级别可以相应降低。但要留神去标识化的强度，如果保留的字段组合仍然能复原到个人，就不能按降级处理。

七是发生数据安全事件导致敏感性变化。数据遭到泄露、篡改之后，即使内容没变，它的风险状态已经变了。比如一份内部通讯录被泄露，短期内它会成为被精准利用的目标，处置期间级别应当从紧；同时在事件复盘后，也要反过来检查原定级是不是本身偏低。

八是主管部门有新要求。行业主管部门发布新的识别细则、新增或调整重要数据目录口径，或者在监管通报中明确某类数据要提级管理，都要照办。这一类的特点是外部驱动，不取决于本单位的判断，接收后要建立一条从监管要求到清单更新的响应链路。

这八类情形出现时，要更新的是规则、清单、目录和标识，而不只是某一条记录。只改单条记录会留下口径不一致的隐患：同一个类别的数据在不同表里挂着两个级别，下次评审就会对不上账。

回到开头那个场面：一张表之所以难切，一半是因为规则本身还不够细、不够贴业务，另一半是因为我们把所有数据当成了一类东西。这两件事要一起解：往上看，把本行业的识别细则结合自身数据特点越出越细；往下做，先把自己那套内部规则写具体，把模棱两可的地方一条条钉死。分类分级的价值，正在于把它拆成能分别对待的几摞：分对类，是给分级找到依据；定准级，是给保护找到标准。规则清楚了，那张清单就不再是一堵墙。