简介《员工个人信息保护合规清单》面向企业人力资源、法务与合规岗位人员围绕员工个人信息从制度构建到离职处理的全流程梳理出一份可直接对照自查的合规条目清单。资源包内含1个docx文档约17KB以勾选式问句形式逐项排查制度是否落地例如是否建立分类分级保护机制、处理敏感信息是否取得单独同意、监控设备与生物识别考勤是否事先告知并提供替代方案、招聘与背景调查中的信息来源与同意范围是否核实、离职员工信息是否及时删除或匿名化、对外提供与跨境传输是否完成影响评估等。清单覆盖制度构建、日常管理、招聘环节、离职管理、对外委托处理五大模块并延伸至自动化决策的算法歧视防范、合规审计与应急机制建设。读者可将其作为内部合规体检表逐条核对现状、定位缺口快速形成整改优先级。目前已有450人学习下载。1. 员工个人信息保护合规清单.docx一份文档背后的字段、权限与责任HR 交来一份花名册IT 手里有一份账号台账门禁系统里还躺着几千条人脸模板。法务问一句「员工个人信息保护合规清单在哪」多数团队递上来的是一份 Word条目写得都对但没人能立刻答出这条要求对应哪个字段、存在哪个系统、谁能看、留多久。这份清单真正的价值不在文档本身而在于它把「合规要求」翻译成可核对的五元组字段、系统、角色、处理目的、留存期。有了这五列同一份内容既能发给部门签字也能被脚本读走做自动化核查季度复检时才不用靠人肉翻 Excel。适合两类人看一类是从零开始搭基线的中小团队 IT 与 HR需要一份能直接生成、能落库比对的模板另一类是制度早已写好但卡在落地环节的团队需要把 Word 里的条目变成 SQL 和权限矩阵能验证的检查项。2. 员工个人信息保护合规清单的字段盘点从四类系统抽出可核查的数据字典清单写不实九成问题出在盘点阶段。字段没盘全后面所有「已勾选」都是自我安慰。盘点的目标不是写一篇制度说明而是产出一张表每个字段都能回指到一个系统、一句话的处理目的、一条明确的留存策略。2.1 员工个人信息通常散落在四类系统里第一类是 HR 主数据包括花名册、入职登记表、身份证、学历、家庭住址、紧急联系人。第二类是薪酬与财务银行卡号、社保公积金基数、个税专项附加扣除信息往往在独立系统里和 HR 库各存一份。第三类是出入与考勤门禁刷卡记录、指纹模板、人脸底图、定位打卡轨迹这类数据常被当成「设备数据」而漏出清单。第四类是 IT 与办公协作账号目录、设备序列号、工单附件里的身份证照片、聊天记录里随手发来的银行卡号最容易失控。盘点顺序建议按「系统 → 表 → 字段」而不是按「部门 → 流程」走因为合规核查最终落在库表上按系统盘能直接和information_schema对上。来源系统典型字段常被忽略的点HR 主数据身份证、住址、紧急联系人紧急联系人属于第三方个人信息薪酬财务银行卡号、个税信息与 HR 库字段重复且不同步考勤门禁人脸模板、指纹、打卡坐标模板数据是否可逆、何时删IT 办公账号、设备号、工单附件附件里的图片无人清点2.2 用 Python 把散落字段汇总成一张清单字段来源多、格式杂先统一成一份带结构的 CSV后续生成文档、做 SQL 比对、跑权限核查都靠它。# field_inventory.py # 把四个来源系统的字段汇总成一张可核查的清单 from dataclasses import dataclass, asdict import csv dataclass class FieldItem: field: str # 字段名如 id_card system: str # 来源系统如 hr_master category: str # 分类身份标识/联系方式/生物识别/薪酬金融 sensitive: bool # 是否高敏感 purpose: str # 处理目的必须一句话说清 retention: str # 留存策略如 离职后180天 roles: str # 可见角色逗号分隔 rows [ FieldItem(id_card, hr_master, 身份标识, True, 入职身份核验, 离职后180天, hr_admin,legal), FieldItem(bank_account, payroll, 薪酬金融, True, 工资代发, 离职后5年, payroll_admin), FieldItem(face_template, access_control, 生物识别, True, 门禁通行, 离职当日删除, security_admin), FieldItem(emergency_contact, hr_master, 第三方联系, True, 紧急情况联络, 在职期间, hr_admin), ] with open(field_inventory.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnameslist(asdict(rows[0]).keys())) writer.writeheader() writer.writerows(asdict(r) for r in rows)dataclass的作用是把字段结构固定下来谁少填一列在导入阶段就会报错。purpose是这份清单的灵魂如果一个字段填不出处理目的基本可以判断它不该收。roles这一列不是给人看的备注第 4 章会用它和真实的授权配置做差集比对。写出utf-8-sig是为了 Excel 双击打开不乱码很多团队卡在这一步以为脚本写错了。2.3 分级分类把字段绑到处理目的与留存期分类维度按「身份标识 / 联系方式 / 生物识别 / 薪酬金融 / 行为轨迹」五档就够用不必追求学术化的分级。与分级配套的是三件事谁能看、留多久、到期怎么删。字段分类敏感留存策略到期动作id_card身份标识是离职后 180 天逻辑删除 备份清理face_template生物识别是离职当日物理删除模板文件bank_account薪酬金融是离职后按财务凭证期加密归档emergency_contact第三方联系是在职期间随主记录删除提示留存期写成「离职后 N 天」这类可计算表达式才能在 SQL 里直接算差值写「长期保存」的条目在自动核查中只能永远标红。2.4 盘点阶段最容易翻车的三个地方只盘 HR 系统。人脸模板、指纹、工单附件这三类往往不在 HR 手里但它们恰恰是高敏感数据漏掉一项整份清单的可信度就没了。把第三方个人信息当成自己的数据。紧急联系人、家属信息、背调联系人处理目的、告知方式、留存期都不同于员工本人的数据需要单独成条。不标在职状态。留存期计算的起点通常是离职时间如果员工主表没有清晰的状态字段和离职日期第 4 章的 SQL 核查根本跑不起来。3. 用 python-docx 生成《员工个人信息保护合规清单.docx》模板结构、样式与参数清单要发给部门签字最终形态仍是一份 docx。与其手工拼表格、每次改版都调格式不如用脚本生成条目定义在代码里格式由样式统一改一版重新跑一次就行还能顺手把版本号和复核人写进文档元数据。3.1 环境与依赖准备python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install python-docx # 生成与解析 docx 都靠它 python -c import docx; print(docx.__version__)用虚拟环境是为了避免和办公机上已有的包互相覆盖。装完先打印一次版本号后面用到的iter_inner_content()只有较新的版本才有版本偏旧时第 4 章的解析代码要换成手动遍历doc.element.body。3.2 清单条目的数据结构与分组条目按「收集 / 存储与访问 / 使用与传输 / 删除与留存」四段分组与清单的五元组对齐。每段下面是一组检查项每项带责任人和当前状态。状态只用三个值是、否、待补。「部分满足」这种模糊状态一旦出现复检时就没人说得清到底算不算通过。分组键直接作为 docx 的一级标题文本例如「一、收集环节」。这个约定很重要脚本解析时靠标题识别章节标题格式变了解析就断了。3.3 生成带表格与勾选列的 docx# build_checklist_docx.py from docx import Document from docx.shared import Pt from docx.enum.text import WD_ALIGN_PARAGRAPH from docx.oxml.ns import qn SECTIONS { 一、收集环节: [ (收集前是否告知处理目的与范围, HRBP, 是), (身份证、银行卡字段是否逐项说明用途, HR 系统管理员, 是), (紧急联系人信息是否留存告知记录, HRBP, 待补), ], 二、存储与访问: [ (高敏感字段是否加密存储, IT 安全, 是), (是否按角色最小化授权, IT 安全, 是), (批量导出是否留痕, IT 安全, 待补), ], } doc Document() style doc.styles[Normal] style.font.name 微软雅黑 # 作用于西文 style.font.size Pt(10.5) style.element.rPr.rFonts.set(qn(w:eastAsia), 微软雅黑) # 作用于中文缺这行会回落宋体 title doc.add_heading(员工个人信息保护合规清单, level0) title.alignment WD_ALIGN_PARAGRAPH.CENTER for section, items in SECTIONS.items(): doc.add_heading(section, level1) # 解析时按 Heading 1 识别章节 table doc.add_table(rows1, cols4) table.style Table Grid # 带边框WPS 同样识别该内置样式名 header table.rows[0].cells for i, text in enumerate([检查项, 责任人, 当前状态, 复核记录]): header[i].text text header[i].paragraphs[0].runs[0].bold True for item in items: row table.add_row().cells row[0].text, row[1].text, row[2].text item doc.core_properties.title 员工个人信息保护合规清单 doc.core_properties.comments v1.0复核人待定 doc.save(员工个人信息保护合规清单.docx)代码的逻辑是「先定样式再填内容」Normal样式一改全文中文字体统一生效不用逐段设置。add_heading(level0)生成文档标题level1生成章节标题第 4 章解析时会用Heading 1判断章节边界所以这里的 level 不能随意改。表格每行先填前三列第四列留给人工签字或复检时手填程序不去覆盖。3.4 参数说明与三个常见坑参数/写法作用建议取值style.font.name西文字体与中文字体保持一致qn(w:eastAsia)中文字体必须设置否则中文回落宋体table.style表格边框用Table Grid等内置名add_heading(level1)章节标记解析的锚点不要改core_properties文档元数据写版本号、复核人注意中文字体只设style.font.name在 Word 里往往看不出问题导出 PDF 或换台机器打开才会暴露w:eastAsia这一行不能省。第二个坑是样式名。自定义样式名在解析时匹配不到用内置的Title、Heading 1、Table Grid最省事。第三个坑是合并单元格如果表头做了跨列合并用 python-docx 读回来会出现重复单元格文本解析时需要去重或按索引取列。4. 把合规清单变成自动化核查docx 回读、SQL 比对与权限矩阵核对清单签完字只是起点。真正省人力的是反向路径从 docx 里把条目读出来变成结构化数据再和数据库、权限配置做比对只把差异项推到人面前。4.1 把 docx 回读成 JSON让清单可被程序消费# parse_checklist.py import json from docx import Document from docx.table import Table from docx.text.paragraph import Paragraph doc Document(员工个人信息保护合规清单.docx) checklist, current {}, None for block in doc.iter_inner_content(): # 按文档顺序返回段落和表格 if isinstance(block, Paragraph): if block.style.name.startswith(Heading 1): current block.text.strip() checklist[current] [] elif isinstance(block, Table) and current: for row in block.rows[1:]: # 第一行是表头跳过 cells [c.text.strip() for c in row.cells] checklist[current].append({ item: cells[0], owner: cells[1], status: cells[2], }) with open(checklist.json, w, encodingutf-8) as f: json.dump(checklist, f, ensure_asciiFalse, indent2)iter_inner_content()按文档真实顺序返回段落与表格避免了「先读全部段落再读全部表格」导致章节与表格错位的问题。判断条件用block.style.name.startswith(Heading 1)而不是匹配中文里的「一、二、三」这样改章节文字不会打断解析。输出 JSON 时用ensure_asciiFalse中文保持可读方便在 Git 里看 diff。4.2 用 SQL 核查留存期与字段最小化-- 找出已超出清单约定留存期、仍在库的员工个人信息 SELECT e.employee_id, e.left_date, DATEDIFF(CURRENT_DATE, e.left_date) AS days_since_left, p.id_card IS NOT NULL AS has_id_card, b.bank_account IS NOT NULL AS has_bank_account FROM hr_employee e LEFT JOIN hr_employee_profile p ON p.employee_id e.employee_id LEFT JOIN hr_payroll_account b ON b.employee_id e.employee_id WHERE e.status left AND DATEDIFF(CURRENT_DATE, e.left_date) :retention_days ORDER BY days_since_left DESC;retention_days不要写死在 SQL 里从清单的留存策略列解析出来传入这样清单改了核查逻辑跟着变不会出现两份口径。第二个参数是时区CURRENT_DATE取的是数据库服务器本地日期跨时区团队部署时先确认这一点否则会在离职当天产生边界误报。字段最小化可以用另一条查询做反向核对把库表里存在但清单里没有的列找出来SELECT column_name FROM information_schema.columns WHERE table_schema hr AND table_name hr_employee_profile AND column_name NOT IN (SELECT field FROM compliance_field_inventory);返回的是「收了但没说清用途」的字段这类字段要么补进清单要么从表里下线。4.3 权限矩阵核对清单里的角色和真实授权做差集# authz_check.py import csv, json inventory {r[field]: r for r in csv.DictReader(open(field_inventory.csv, encodingutf-8-sig))} grants json.load(open(role_grants.json, encodingutf-8)) # {hr_admin: [id_card], ...} for field, meta in inventory.items(): allowed set(meta[roles].split(,)) actual {role for role, fields in grants.items() if field in fields} extra actual - allowed if extra: print(f[越权] {field} 被 {sorted(extra)} 读取清单允许 {sorted(allowed)})授权配置从实际系统导出为标准 JSON字段名与清单保持一致。差集只打印「多出来的角色」因为漏授权通常不会带来风险越权才会。跑出来的清单直接进整改工单附上字段、角色、责任人三列。核查项数据来源通过标准失败常见原因留存期到期业务库 清单留存列到期记录数为 0离职状态未更新字段最小化库表结构 字段清单差集为空历史遗留列未清权限最小化授权导出 角色列无越权角色临时授权未回收4.4 核查不通过时先看什么先看时间字段。留存期误报里超过一半是离职日期、状态字段没及时更新数据本身其实已经清理干净。再看字段命名一致性清单写id_card、库里叫idcard或cert_no差集会被误判成新增字段。最后才怀疑真的没清这时候把记录抽样出来人工确认一次再决定是改流程还是改清理脚本。5. 清单的版本化、签署留痕与季度复检技巧清单最容易烂尾的地方是「改了一版没人知道」。文件名带版本和生效日期例如员工个人信息保护合规清单_v1.3_20240601.docx比在正文里写「第 3 版」可靠得多检索和归档都省事。5.1 用文档元数据承载版本信息doc.core_properties.title 员工个人信息保护合规清单 doc.core_properties.revision 3 doc.core_properties.comments v1.3复核人张三下次复核下一季度元数据不占正文版面但能被脚本读出来做校验。复检脚本可以顺手断言revision是否递增防止有人覆盖旧文件当新版发布。5.2 签署留痕的两种做法轻量做法是把生成的 docx 算一次 SHA-256连同版本号、复核人、日期记进工单或邮件正文日后任何一方手里的文件是否被改动重算一次哈希就能判断。重一点的做法是把 docx 和生成的checklist.json一起提交进 Git 仓库人看 docx、机看 JSON两份同步更新。提示docx 是二进制git diff看不出内容变化。把同一版的checklist.json一并提交diff 就落在 JSON 上改了哪条一目了然。5.3 季度复检只处理差异项复检的输入是上一版的checklist.json和这一版的同一文件。把两份规范化后对比导出新增项、状态由「是」变「否」的项、责任人变更项三类其余勾选保持不变的条目直接归档不进会议议程。jq -S . old/checklist.json /tmp/old.json jq -S . new/checklist.json /tmp/new.json diff -u /tmp/old.json /tmp/new.json | grep ^[-] | grep -v ^[-][-]jq -S先按 key 排序避免键顺序不同造成的假差异。复检会上只讨论 diff 出来的新增项和责任人变更项一次会议三十分钟能收尾剩下的时间用来抽查两条高风险字段的实际存储位置比逐条念清单有用得多。本文还有配套的精品资源点击获取
简介《员工个人信息保护合规清单》面向企业人力资源、法务与合规岗位人员围绕员工个人信息从制度构建到离职处理的全流程梳理出一份可直接对照自查的合规条目清单。资源包内含1个docx文档约17KB以勾选式问句形式逐项排查制度是否落地例如是否建立分类分级保护机制、处理敏感信息是否取得单独同意、监控设备与生物识别考勤是否事先告知并提供替代方案、招聘与背景调查中的信息来源与同意范围是否核实、离职员工信息是否及时删除或匿名化、对外提供与跨境传输是否完成影响评估等。清单覆盖制度构建、日常管理、招聘环节、离职管理、对外委托处理五大模块并延伸至自动化决策的算法歧视防范、合规审计与应急机制建设。读者可将其作为内部合规体检表逐条核对现状、定位缺口快速形成整改优先级。目前已有450人学习下载。1. 员工个人信息保护合规清单.docx一份文档背后的字段、权限与责任HR 交来一份花名册IT 手里有一份账号台账门禁系统里还躺着几千条人脸模板。法务问一句「员工个人信息保护合规清单在哪」多数团队递上来的是一份 Word条目写得都对但没人能立刻答出这条要求对应哪个字段、存在哪个系统、谁能看、留多久。这份清单真正的价值不在文档本身而在于它把「合规要求」翻译成可核对的五元组字段、系统、角色、处理目的、留存期。有了这五列同一份内容既能发给部门签字也能被脚本读走做自动化核查季度复检时才不用靠人肉翻 Excel。适合两类人看一类是从零开始搭基线的中小团队 IT 与 HR需要一份能直接生成、能落库比对的模板另一类是制度早已写好但卡在落地环节的团队需要把 Word 里的条目变成 SQL 和权限矩阵能验证的检查项。2. 员工个人信息保护合规清单的字段盘点从四类系统抽出可核查的数据字典清单写不实九成问题出在盘点阶段。字段没盘全后面所有「已勾选」都是自我安慰。盘点的目标不是写一篇制度说明而是产出一张表每个字段都能回指到一个系统、一句话的处理目的、一条明确的留存策略。2.1 员工个人信息通常散落在四类系统里第一类是 HR 主数据包括花名册、入职登记表、身份证、学历、家庭住址、紧急联系人。第二类是薪酬与财务银行卡号、社保公积金基数、个税专项附加扣除信息往往在独立系统里和 HR 库各存一份。第三类是出入与考勤门禁刷卡记录、指纹模板、人脸底图、定位打卡轨迹这类数据常被当成「设备数据」而漏出清单。第四类是 IT 与办公协作账号目录、设备序列号、工单附件里的身份证照片、聊天记录里随手发来的银行卡号最容易失控。盘点顺序建议按「系统 → 表 → 字段」而不是按「部门 → 流程」走因为合规核查最终落在库表上按系统盘能直接和information_schema对上。来源系统典型字段常被忽略的点HR 主数据身份证、住址、紧急联系人紧急联系人属于第三方个人信息薪酬财务银行卡号、个税信息与 HR 库字段重复且不同步考勤门禁人脸模板、指纹、打卡坐标模板数据是否可逆、何时删IT 办公账号、设备号、工单附件附件里的图片无人清点2.2 用 Python 把散落字段汇总成一张清单字段来源多、格式杂先统一成一份带结构的 CSV后续生成文档、做 SQL 比对、跑权限核查都靠它。# field_inventory.py # 把四个来源系统的字段汇总成一张可核查的清单 from dataclasses import dataclass, asdict import csv dataclass class FieldItem: field: str # 字段名如 id_card system: str # 来源系统如 hr_master category: str # 分类身份标识/联系方式/生物识别/薪酬金融 sensitive: bool # 是否高敏感 purpose: str # 处理目的必须一句话说清 retention: str # 留存策略如 离职后180天 roles: str # 可见角色逗号分隔 rows [ FieldItem(id_card, hr_master, 身份标识, True, 入职身份核验, 离职后180天, hr_admin,legal), FieldItem(bank_account, payroll, 薪酬金融, True, 工资代发, 离职后5年, payroll_admin), FieldItem(face_template, access_control, 生物识别, True, 门禁通行, 离职当日删除, security_admin), FieldItem(emergency_contact, hr_master, 第三方联系, True, 紧急情况联络, 在职期间, hr_admin), ] with open(field_inventory.csv, w, newline, encodingutf-8-sig) as f: writer csv.DictWriter(f, fieldnameslist(asdict(rows[0]).keys())) writer.writeheader() writer.writerows(asdict(r) for r in rows)dataclass的作用是把字段结构固定下来谁少填一列在导入阶段就会报错。purpose是这份清单的灵魂如果一个字段填不出处理目的基本可以判断它不该收。roles这一列不是给人看的备注第 4 章会用它和真实的授权配置做差集比对。写出utf-8-sig是为了 Excel 双击打开不乱码很多团队卡在这一步以为脚本写错了。2.3 分级分类把字段绑到处理目的与留存期分类维度按「身份标识 / 联系方式 / 生物识别 / 薪酬金融 / 行为轨迹」五档就够用不必追求学术化的分级。与分级配套的是三件事谁能看、留多久、到期怎么删。字段分类敏感留存策略到期动作id_card身份标识是离职后 180 天逻辑删除 备份清理face_template生物识别是离职当日物理删除模板文件bank_account薪酬金融是离职后按财务凭证期加密归档emergency_contact第三方联系是在职期间随主记录删除提示留存期写成「离职后 N 天」这类可计算表达式才能在 SQL 里直接算差值写「长期保存」的条目在自动核查中只能永远标红。2.4 盘点阶段最容易翻车的三个地方只盘 HR 系统。人脸模板、指纹、工单附件这三类往往不在 HR 手里但它们恰恰是高敏感数据漏掉一项整份清单的可信度就没了。把第三方个人信息当成自己的数据。紧急联系人、家属信息、背调联系人处理目的、告知方式、留存期都不同于员工本人的数据需要单独成条。不标在职状态。留存期计算的起点通常是离职时间如果员工主表没有清晰的状态字段和离职日期第 4 章的 SQL 核查根本跑不起来。3. 用 python-docx 生成《员工个人信息保护合规清单.docx》模板结构、样式与参数清单要发给部门签字最终形态仍是一份 docx。与其手工拼表格、每次改版都调格式不如用脚本生成条目定义在代码里格式由样式统一改一版重新跑一次就行还能顺手把版本号和复核人写进文档元数据。3.1 环境与依赖准备python -m venv .venv source .venv/bin/activate # Windows 用 .venv\Scripts\activate pip install python-docx # 生成与解析 docx 都靠它 python -c import docx; print(docx.__version__)用虚拟环境是为了避免和办公机上已有的包互相覆盖。装完先打印一次版本号后面用到的iter_inner_content()只有较新的版本才有版本偏旧时第 4 章的解析代码要换成手动遍历doc.element.body。3.2 清单条目的数据结构与分组条目按「收集 / 存储与访问 / 使用与传输 / 删除与留存」四段分组与清单的五元组对齐。每段下面是一组检查项每项带责任人和当前状态。状态只用三个值是、否、待补。「部分满足」这种模糊状态一旦出现复检时就没人说得清到底算不算通过。分组键直接作为 docx 的一级标题文本例如「一、收集环节」。这个约定很重要脚本解析时靠标题识别章节标题格式变了解析就断了。3.3 生成带表格与勾选列的 docx# build_checklist_docx.py from docx import Document from docx.shared import Pt from docx.enum.text import WD_ALIGN_PARAGRAPH from docx.oxml.ns import qn SECTIONS { 一、收集环节: [ (收集前是否告知处理目的与范围, HRBP, 是), (身份证、银行卡字段是否逐项说明用途, HR 系统管理员, 是), (紧急联系人信息是否留存告知记录, HRBP, 待补), ], 二、存储与访问: [ (高敏感字段是否加密存储, IT 安全, 是), (是否按角色最小化授权, IT 安全, 是), (批量导出是否留痕, IT 安全, 待补), ], } doc Document() style doc.styles[Normal] style.font.name 微软雅黑 # 作用于西文 style.font.size Pt(10.5) style.element.rPr.rFonts.set(qn(w:eastAsia), 微软雅黑) # 作用于中文缺这行会回落宋体 title doc.add_heading(员工个人信息保护合规清单, level0) title.alignment WD_ALIGN_PARAGRAPH.CENTER for section, items in SECTIONS.items(): doc.add_heading(section, level1) # 解析时按 Heading 1 识别章节 table doc.add_table(rows1, cols4) table.style Table Grid # 带边框WPS 同样识别该内置样式名 header table.rows[0].cells for i, text in enumerate([检查项, 责任人, 当前状态, 复核记录]): header[i].text text header[i].paragraphs[0].runs[0].bold True for item in items: row table.add_row().cells row[0].text, row[1].text, row[2].text item doc.core_properties.title 员工个人信息保护合规清单 doc.core_properties.comments v1.0复核人待定 doc.save(员工个人信息保护合规清单.docx)代码的逻辑是「先定样式再填内容」Normal样式一改全文中文字体统一生效不用逐段设置。add_heading(level0)生成文档标题level1生成章节标题第 4 章解析时会用Heading 1判断章节边界所以这里的 level 不能随意改。表格每行先填前三列第四列留给人工签字或复检时手填程序不去覆盖。3.4 参数说明与三个常见坑参数/写法作用建议取值style.font.name西文字体与中文字体保持一致qn(w:eastAsia)中文字体必须设置否则中文回落宋体table.style表格边框用Table Grid等内置名add_heading(level1)章节标记解析的锚点不要改core_properties文档元数据写版本号、复核人注意中文字体只设style.font.name在 Word 里往往看不出问题导出 PDF 或换台机器打开才会暴露w:eastAsia这一行不能省。第二个坑是样式名。自定义样式名在解析时匹配不到用内置的Title、Heading 1、Table Grid最省事。第三个坑是合并单元格如果表头做了跨列合并用 python-docx 读回来会出现重复单元格文本解析时需要去重或按索引取列。4. 把合规清单变成自动化核查docx 回读、SQL 比对与权限矩阵核对清单签完字只是起点。真正省人力的是反向路径从 docx 里把条目读出来变成结构化数据再和数据库、权限配置做比对只把差异项推到人面前。4.1 把 docx 回读成 JSON让清单可被程序消费# parse_checklist.py import json from docx import Document from docx.table import Table from docx.text.paragraph import Paragraph doc Document(员工个人信息保护合规清单.docx) checklist, current {}, None for block in doc.iter_inner_content(): # 按文档顺序返回段落和表格 if isinstance(block, Paragraph): if block.style.name.startswith(Heading 1): current block.text.strip() checklist[current] [] elif isinstance(block, Table) and current: for row in block.rows[1:]: # 第一行是表头跳过 cells [c.text.strip() for c in row.cells] checklist[current].append({ item: cells[0], owner: cells[1], status: cells[2], }) with open(checklist.json, w, encodingutf-8) as f: json.dump(checklist, f, ensure_asciiFalse, indent2)iter_inner_content()按文档真实顺序返回段落与表格避免了「先读全部段落再读全部表格」导致章节与表格错位的问题。判断条件用block.style.name.startswith(Heading 1)而不是匹配中文里的「一、二、三」这样改章节文字不会打断解析。输出 JSON 时用ensure_asciiFalse中文保持可读方便在 Git 里看 diff。4.2 用 SQL 核查留存期与字段最小化-- 找出已超出清单约定留存期、仍在库的员工个人信息 SELECT e.employee_id, e.left_date, DATEDIFF(CURRENT_DATE, e.left_date) AS days_since_left, p.id_card IS NOT NULL AS has_id_card, b.bank_account IS NOT NULL AS has_bank_account FROM hr_employee e LEFT JOIN hr_employee_profile p ON p.employee_id e.employee_id LEFT JOIN hr_payroll_account b ON b.employee_id e.employee_id WHERE e.status left AND DATEDIFF(CURRENT_DATE, e.left_date) :retention_days ORDER BY days_since_left DESC;retention_days不要写死在 SQL 里从清单的留存策略列解析出来传入这样清单改了核查逻辑跟着变不会出现两份口径。第二个参数是时区CURRENT_DATE取的是数据库服务器本地日期跨时区团队部署时先确认这一点否则会在离职当天产生边界误报。字段最小化可以用另一条查询做反向核对把库表里存在但清单里没有的列找出来SELECT column_name FROM information_schema.columns WHERE table_schema hr AND table_name hr_employee_profile AND column_name NOT IN (SELECT field FROM compliance_field_inventory);返回的是「收了但没说清用途」的字段这类字段要么补进清单要么从表里下线。4.3 权限矩阵核对清单里的角色和真实授权做差集# authz_check.py import csv, json inventory {r[field]: r for r in csv.DictReader(open(field_inventory.csv, encodingutf-8-sig))} grants json.load(open(role_grants.json, encodingutf-8)) # {hr_admin: [id_card], ...} for field, meta in inventory.items(): allowed set(meta[roles].split(,)) actual {role for role, fields in grants.items() if field in fields} extra actual - allowed if extra: print(f[越权] {field} 被 {sorted(extra)} 读取清单允许 {sorted(allowed)})授权配置从实际系统导出为标准 JSON字段名与清单保持一致。差集只打印「多出来的角色」因为漏授权通常不会带来风险越权才会。跑出来的清单直接进整改工单附上字段、角色、责任人三列。核查项数据来源通过标准失败常见原因留存期到期业务库 清单留存列到期记录数为 0离职状态未更新字段最小化库表结构 字段清单差集为空历史遗留列未清权限最小化授权导出 角色列无越权角色临时授权未回收4.4 核查不通过时先看什么先看时间字段。留存期误报里超过一半是离职日期、状态字段没及时更新数据本身其实已经清理干净。再看字段命名一致性清单写id_card、库里叫idcard或cert_no差集会被误判成新增字段。最后才怀疑真的没清这时候把记录抽样出来人工确认一次再决定是改流程还是改清理脚本。5. 清单的版本化、签署留痕与季度复检技巧清单最容易烂尾的地方是「改了一版没人知道」。文件名带版本和生效日期例如员工个人信息保护合规清单_v1.3_20240601.docx比在正文里写「第 3 版」可靠得多检索和归档都省事。5.1 用文档元数据承载版本信息doc.core_properties.title 员工个人信息保护合规清单 doc.core_properties.revision 3 doc.core_properties.comments v1.3复核人张三下次复核下一季度元数据不占正文版面但能被脚本读出来做校验。复检脚本可以顺手断言revision是否递增防止有人覆盖旧文件当新版发布。5.2 签署留痕的两种做法轻量做法是把生成的 docx 算一次 SHA-256连同版本号、复核人、日期记进工单或邮件正文日后任何一方手里的文件是否被改动重算一次哈希就能判断。重一点的做法是把 docx 和生成的checklist.json一起提交进 Git 仓库人看 docx、机看 JSON两份同步更新。提示docx 是二进制git diff看不出内容变化。把同一版的checklist.json一并提交diff 就落在 JSON 上改了哪条一目了然。5.3 季度复检只处理差异项复检的输入是上一版的checklist.json和这一版的同一文件。把两份规范化后对比导出新增项、状态由「是」变「否」的项、责任人变更项三类其余勾选保持不变的条目直接归档不进会议议程。jq -S . old/checklist.json /tmp/old.json jq -S . new/checklist.json /tmp/new.json diff -u /tmp/old.json /tmp/new.json | grep ^[-] | grep -v ^[-][-]jq -S先按 key 排序避免键顺序不同造成的假差异。复检会上只讨论 diff 出来的新增项和责任人变更项一次会议三十分钟能收尾剩下的时间用来抽查两条高风险字段的实际存储位置比逐条念清单有用得多。本文还有配套的精品资源点击获取
