简介：围绕医疗健康信息安全管理需求整理的ISO 27799-2016标准翻译版，面向医院、诊所、健康信息平台、保险及研究机构的安全合规人员，也适合以ISO/IEC 27002为框架落地隐私保护的技术与管理人员参考。内容在ISO/IEC 27002:2013基础上延伸，聚焦个人健康信息的机密性、完整性与可用性，并讨论信息治理、公司治理和临床治理的关系、健康信息面临的威胁与脆弱性、适用范围与术语定义，以及信息安全策略、访问控制、系统运维等控制主题。压缩包共1个PDF文件，约2.29MB，为中文翻译并作格式修订，目录层级较完整，便于按章节检索和对照原文阅读。已有1113人学习，读者可借此梳理健康信息安全管理框架、理解医疗场景下的控制措施与实施指南，并用于制度编写、培训备课或合规自查时快速定位关键条款。

1. 一份被反复翻译、反复改格式的标准，到底卡在哪

手里这份 ISO 27799-2016 中文翻译稿，最魔幻的地方在于：正文技术内容早就定稿了，真正消耗时间的却是目录页码错位、控制措施小节标题层级不统一、中英对照串行。它对应的是健康信息安全管理这一摊具体活儿——以 ISO/IEC 27002:2013 的控制域为骨架，针对医疗场景逐条补“健康特定控制措施”和“健康特定实施指南”。适用对象很明确：医院信息科、区域健康平台、医保与健康险机构里做制度落地和合规对标的人，以及需要把英文标准转成内部可执行条款的安全岗。这份稿子的价值不在“又一份翻译”，而在于它保留了完整的控制项标注体系，能直接拆成检查表。

2. 先看懂这份翻译稿的结构：控制项、健康特定控制、实施指南三层怎么拆

拿到一份 100 多页的标准译文，多数人的第一反应是从第一页读起，这在标准类文档上是低效的。ISO 27799 的组织方式跟 27002 高度同构：每个控制项固定按“Control（控制措施）→ Implementation guidance（实施指南）→ Health-specific control（医疗健康特定控制措施）→ Health-specific implementation guidance（医疗健康特定实施指南）→ Other information（其他信息）”五段展开，但并非每一项都有五段，很多条目只有三段或四段。这份翻译稿在格式修订时把这几段的中英标题并排保留，正好给了你一个判断依据：哪个控制项被医疗场景真正“加重”了。

2.1 五段式条目的含义与取舍逻辑

把一条控制项拆开看，五段的分工是这样的：

关键判断在第三段。以“5.1.1 信息安全策略”为例，通用控制只要求“形成文件化策略并发布”，而健康特定控制会进一步要求策略中必须覆盖个人健康信息的可识别性处理、护理对象知情范围等。凡是有“Health-specific control”的条目，说明标准认为通用控制在医疗环境下不够用，这类条目在内部审计中几乎必然被问到。反过来，像“8.1.3 资产的可接受使用”“8.2.3 资产处理”这几项，译文里明确写着“No additional guidance for information security management in health（没有健康信息安全管理的附加指南）”，这类条目直接套用 27002 的做法即可，不必再为医疗场景额外造要求。

2.2 目录层级与控制项编号的对应规则

这份稿子最容易出错的地方是编号映射。ISO 27799 沿用了 27002:2013 的章节号（5 到 18 章），每个控制项的编号是“章.节.条”三级，比如 6.1.5 表示第 6 章“信息安全的组织”、6.1 节“内部组织”下的第 5 个控制项。而在控制项内部，五段式小标题又各自独立，不参与编号。格式修订时如果把这些小标题也加上编号，就会出现“6.1.5.2”这种标准里根本不存在的地址，后续做条款引用时会全部对不上。

我一般的处理办法是先建一张编号主表，把“章号 / 节号 / 控制项号 / 是否有健康特定控制 / 页码”五列固定下来，所有正文和目录都从这张表生成，而不是手工敲。用 Python 从纯文本目录行里提一遍，比肉眼核对靠谱得多：

import re # 目录行形如：6.1.5 Information security in project management 项目管理中的信息安全 35 LINE = re.compile(r'^(?P<num>\d+(?:\.\d+){0,2})\s+(?P<en>.*?)\s+(?P<zh>[\u4e00-\u9fa5，、（）]+)\s+(?P<page>\d+)$') rows = [] with open('toc.txt', encoding='utf-8') as f: for raw in f: line = raw.strip() if not line: continue m = LINE.match(line) if not m: continue # 目录里的 Foreword、Introduction 等无编号行单独处理 num = m.group('num') rows.append({ 'num': num, 'level': num.count('.') + 1, # 1=章, 2=节, 3=控制项 'en': m.group('en').strip(), 'zh': m.group('zh').strip(), 'page': int(m.group('page')), }) # 校验：控制项必须挂在一个存在的节下面 secs = {r['num'] for r in rows if r['level'] == 2} for r in rows: if r['level'] == 3: parent = r['num'].rsplit('.', 1)[0] assert parent in secs, f'孤立控制项: {r["num"]}'

这段脚本干三件事：用正则把“编号 + 英文名 + 中文名 + 页码”四段切开，用点号数量判定层级（1 个点是章，2 个点是节，3 个点是控制项），最后校验每个三级编号都能找到二级父节点。level字段后面直接决定目录缩进，page字段用于生成页码对齐的制表位。这里有个细节：中文名正则里我把顿号、括号都放进字符集，是因为“意识、教育和培训”这类标题会被空格规则误切，如果你的译文里出现英文括号或数字混排，把字符集扩到[\u4e00-\u9fa5A-Za-z0-9，、（）()]更稳。

2.3 翻译稿里“中英并排”带来的排版约束

这份稿子的一个显式特征是双语标题同行，比如“6.2 Mobile devices and teleworking 移动设备和远程工作”。这在阅读时友好，在排版时是灾难：英文词长差异大，同一级标题的中文起始位置会左右跳动；一旦某行英文超长触发折行，中文部分就掉到下一行，视觉上跟子标题混在一起。

常见做法是不要试图在正文里靠空格对齐，而是把中英文拆成两个段落样式，英文用固定宽度制表位，中文从制表位之后开始。若最终交付物是 Word，用“段落 → 制表位”设一个左制表位在 8 字符处，标题写成“英文 中文”；导出 PDF 时制表位会保持对齐。若交付物是纯 Markdown，就别强求并排，中文标题在前、英文放括号内，可读性反而更高。这一点在格式修订阶段定下来，后面 100 多页的标题就不用逐条手调。

3. 把标准条款转成可执行检查表：从控制域到院内制度条目

翻译稿真正的使用场景不是“读”，而是“拆”。一份健康信息安全管理体系落地，通常要产出一份控制措施适用性声明（SoA），里面每一行都要能溯源到标准条款。这份译文保留了完整的控制域划分，从第 5 章信息安全策略一直到后面的访问控制、密码控制、物理与环境安全等，正好可以按域批量抽取。

3.1 按控制域抽取条款并生成适用性清单

先明确控制域的抽取边界。ISO 27799 的章节结构继承 27002:2013，共 14 个控制域（第 5 章至第 18 章），每个域下若干节，节下是控制项。抽取时以控制项为最小粒度，一个控制项一行，字段建议固定为：条款号、控制项名称、是否有健康特定控制、适用性（适用/不适用）、不适用理由、责任部门、现有控制措施、差距说明。

用脚本从结构化后的目录表批量生成骨架，比手工建表快一个量级：

import csv # rows 来自 2.2 的解析结果 with open('soa_skeleton.csv', 'w', newline='', encoding='utf-8-sig') as f: w = csv.writer(f) w.writerow(['条款号', '控制项名称', '层级', '是否有健康特定控制', '适用性', '不适用理由', '责任部门', '现有措施', '差距说明']) for r in rows: if r['level'] != 3: # 只保留控制项，章和节作为分组依据不进表 continue w.writerow([ r['num'], f"{r['zh']} / {r['en']}", r['level'], '', # 待人工或按正文关键词回填 '', '', '', '', '', ])

encoding='utf-8-sig'是为了 Excel 直接双击打开不乱码，这是血泪经验——用 utf-8 导出的 CSV 在部分 Windows 环境下中文会变方块。只保留level == 3是刻意的：章和节在 SoA 里通常作为分组标题而非适用性对象，混进去会让后续统计口径变乱。

“是否有健康特定控制”这一列不必全靠人工。译文里该段标题是固定串，可以在正文全文里按条款号定位后做存在性判断：

import re body = open('iso27799_zh.txt', encoding='utf-8').read() def has_health_control(clause: str) -> bool: # 从该条款号出现处截到下一个同级或更高级条款号之前 start = body.find(clause) if start == -1: return False nxt = re.search(r'\n\d+(?:\.\d+){0,2}\s', body[start + len(clause):]) seg = body[start: start + len(clause) + (nxt.start() if nxt else 4000)] return '医疗健康特定控制措施' in seg for r in rows: if r['level'] == 3: r['health'] = has_health_control(r['num'])

这里的关键不是正则本身，而是“切段”的思路：标准正文里条款号是天然分隔符，用下一个条款号的位置截断当前段落，比按行号硬编码稳健得多。4000这个兜底长度是给最后几个条款用的，避免找不到下一个编号时把整篇都算进来。判断用的关键词必须跟译文里的实际标题完全一致，“医疗健康特定控制措施”和“健康特定控制”不要混用，否则漏判。

3.2 用条款号做双向溯源，避免审核时对不上

审核场景下最尴尬的是被问“这条制度依据标准哪一条”，答不上来或者答错号。解决办法是双向索引：制度文件里每条都标注条款号，同时维护一份“条款号 → 制度文件条目”的反查表。这份译文的编号体系完整，做这件事成本很低。

具体做法是在制度文档的每个条目末尾加方括号标注，格式统一为[ISO 27799:2016 8.2.1]，然后用脚本扫一遍所有制度文件，抽出标注做一致性检查：

import re, pathlib TAG = re.compile(r'\[ISO 27799:2016 (\d+(?:\.\d+){0,2})\]') valid = {r['num'] for r in rows} index = {} for p in pathlib.Path('policies').glob('*.md'): text = p.read_text(encoding='utf-8') for num in TAG.findall(text): index.setdefault(num, []).append(p.name) if num not in valid: print(f'[无效条款号] {p.name} -> {num}') # 找出标准里有、但制度里完全没提的控制项（覆盖缺口） missing = sorted(valid - set(index), key=lambda s: [int(x) for x in s.split('.')]) print('未覆盖控制项数量:', len(missing))

这段脚本输出两类信息：无效条款号（写错号、引用了不存在的条目）和覆盖缺口（标准有要求但制度没落）。sorted里用[int(x) for x in s.split('.')]是为了让 6.10 排在 6.9 之后而不是字典序的 6.1 前面——标准编号是数字语义，字符串排序会给出误导性的顺序。

提示：覆盖缺口不等于必须补齐。SoA 的逻辑是“不适用的要写明理由”，脚本只负责把空白暴露出来，判断仍要人做。

3.3 医疗场景下需要额外加严的几类控制项

不是所有控制项在医疗环境下都要加码，盲目加严会让制度臃肿到没人执行。从这份译文的“健康特定实施指南”分布看，被反复加重的主要集中在四类：

第一类是访问控制。护理对象的健康信息一旦被非授权读取，损害不可逆，所以译文在访问控制域的医疗特定指南里强调“基于角色 + 基于治疗关系”的双重判定，而不是单纯的角色授权。落到制度上，就是要在权限申请流程里增加“是否存在现行治疗关系”这一确认环节。

第二类是审计与日志。译文在日志相关条款中明确要求覆盖信息全生命周期的可审核性，这与通用控制在保留时长和留存范围上有差别。实操上常见做法是把健康信息的读取、导出、打印三类操作单独设日志策略，保留期按行业要求延长。

第三类是传输与介质。可移动介质管理这一条在译文里有独立的健康特定控制，原因是影像、检验结果常通过介质在机构间流转。制度里要把介质登记、加密、销毁三件事写死。

第四类是可用性。译文在引言和多个控制项里都提到健康信息系统面对自然灾害、系统故障时的持续运行需求，这条在通用标准里权重不高，在医疗场景必须单列应急与恢复指标。

4. 格式修订实操：从乱版译文到可发布文档的四步流水线

这份稿子的标题里就写着“格式修订”，说明原始译文的结构已经乱了。乱版的标准译文有三个典型症状：目录页码与正文不符、标题层级深浅不一、五段式小标题时有时无。手工改 100 多页不现实，得走流水线。

4.1 第一步：清洗原文，统一五段式小标题

清洗的目标是把所有变体收敛到五个标准串。译文里常见的变体包括“Control 控制”“控制措施 Control”“实施指南 Implementation guidance”缺空格、全角括号混用等。用一张映射表批量替换，比逐个查找替换安全：

import re CANON = { 'control': 'Control 控制措施', 'implementation guidance': 'Implementation guidance 实施指南', 'health-specific control': 'Health-specific control 医疗健康特定控制措施', 'health-specific implementation guidance': 'Health-specific implementation guidance 医疗健康特定实施指南', 'other information': 'Other information 其他信息', 'other health-specific information': 'Other health-specific information 其他医疗健康特定信息', } def normalize_heading(line: str) -> str: s = line.strip().replace('：', ':').replace('（', '(').replace('）', ')') s = re.sub(r'\s+', ' ', s) low = s.lower() for k, v in CANON.items(): # 允许英文在前或中文在前两种写法 if low.startswith(k) or low.endswith(k): return v return line out = [normalize_heading(l) for l in open('raw.txt', encoding='utf-8')] open('clean.txt', 'w', encoding='utf-8').write('\n'.join(out))

先做全角转半角再匹配，是因为译文中冒号和括号的中英文混用极多，不归一化就会出现“Control：控制措施”匹配不上。startswith / endswith双向判断覆盖了“英文在前”和“中文在前”两种排版习惯。注意CANON里把 health-specific 两个变体分开，health-specific control必须排在health-specific implementation guidance之前判断是不必要的——因为用的是精确前后缀匹配而非包含匹配，顺序不影响结果，但如果改成in判断就必须按长度降序，这是容易翻车的点。

4.2 第二步：重建目录，用制表位做页码对齐

目录重建的难点是页码对齐。用空格凑对齐在等宽字体下勉强能看，换字体立刻崩。正确做法是用制表位加右对齐前导符。若输出为 Word，可在目录段落样式里设一个右制表位在版心右边界，前导符选点线；若输出为 HTML/PDF，用 CSS 的leader()或简单的 flex 布局。

如果最终产物是 Markdown 转 PDF，我一般放弃精确页码，改成不带页码的两级目录，把页码交给 PDF 书签。这样做的好处是译文后续再修订时目录不需要跟着重排，代价是纸质打印时不好翻。两种方案取舍看交付形态：

选 Word 自动目录的前提是标题样式必须干净，也就是 4.1 那步的清洗必须做完，否则自动目录会把“Control 控制措施”也收进去，生成一份几十页的假目录。

4.3 第三步：控制项编号校验与交叉引用修复

正文里大量出现“见 8.2.1”“参见第 6 章”这类交叉引用，格式修订时条款号一旦变动，这些引用全部失效。校验逻辑很简单：把所有引用抽出来，比对编号主表。

import re REF = re.compile(r'(?:见|参见|依据)\s*(\d+(?:\.\d+){0,2})') valid = {r['num'] for r in rows} text = open('clean.txt', encoding='utf-8').read() for m in REF.finditer(text): num = m.group(1) if num not in valid: line_no = text[:m.start()].count('\n') + 1 print(f'第 {line_no} 行引用失效: {num}')

只匹配“见 / 参见 / 依据”三个引导词是有意的，因为标准正文里还有大量数字本身不是引用（比如“保留 6 个月”“27002:2013”），不加引导词会误报一片。实际跑下来误报仍会有，比如“见 3.1 定义”这类跨到术语章的引用，如果主表只收了 5 到 18 章就会报失效，所以主表要把第 1 到 4 章的编号也补进去，或者在校验时白名单排除 1 到 4 章。

4.4 第四步：导出前的完整性自检清单

导出前跑一遍机械检查，能挡掉大部分返工。我固定查这几项：

• 每个三级编号都有对应的二级父节点（2.2 的断言已覆盖）
• 五段式小标题只出现在控制项之下，不出现在章、节之下
• 目录条目数等于正文标题数，差值应为 0
• 所有“没有健康信息安全管理的附加指南”条目，其下不应再出现健康特定实施指南段落
• 页码单调递增，允许章首页重复但不允许倒退

最后一项最容易被忽略。目录页码倒退通常意味着某章正文被误删或分页符错位，这种错误在缩略视图下完全看不出来，但打印出来就是装订事故。

5. 避坑与排查：这类标准译文修订里最常见的五个翻车点

5.1 目录页码全错，正文却是对的

现象：PDF 里目录标 35 页，翻过去是 33 页。原因不是目录生成错了，而是正文在修订过程中插入了分节符或调整了页边距，分页位置整体前移，而目录域没有更新。解决：定稿流程里把“更新整个目录域”作为固定动作，且必须在最后一次改页面设置之后执行；若用脚本生成目录，页码要在排版完成后回填，不能提前算。

5.2 五段式标题被自动编号，生成不存在的条款

现象：正文出现“6.1.5.1 Control 控制措施”，引用时被当成有效条款。原因是把五段式小标题套用了标题 4 级样式并开启了自动编号。解决：五段式小标题一律用加粗正文段落而非标题样式，或使用不参与编号的独立样式；同时在编号主表校验里加一条规则，四级编号直接报错。

5.3 中文标题被空格规则切断，正则匹配漏项

现象：解析目录时“7.2.2 意识、教育和培训”整行匹配失败，导致该控制项在 SoA 骨架里缺失。原因是原译文标题为“Information security awareness, 意识、教育和培训”，英文逗号后紧跟中文，中间只有半角空格，而正则把中文名限定为连续汉字。解决：把中文名字符集扩展到包含标点，或在清洗阶段先把“英文, 中文”统一成“英文 中文”再解析。漏项是静默失败，不会报错，所以解析后必须比对条目总数。

5.4 健康特定控制判断误判，把通用条款标成加严条款

现象：某些控制项被标了“有健康特定控制”，实际译文里写的是“No additional guidance”。原因是关键词匹配用了“健康”二字做包含判断，把“没有健康信息安全管理的附加指南”这句话也命中了。解决：判断关键词必须是完整标题串“医疗健康特定控制措施”，且要做“该段落内是否出现否定表述”的二次校验。这个坑很典型，属于关键词选得太宽的翻车。

5.5 交叉引用批量替换后指向错位

现象：把旧编号 8.2 统一替换成 8.2.1 之后，原本正确的“见 8.2.1”变成了“见 8.2.1.1”。原因是替换没有做边界限定，短编号是长编号的前缀。解决：替换时用词边界和负向断言，Python 里写成re.sub(r'(?<![\d.])8\.2(?![\d.])', '8.2.1', text)，前后都排除数字和点号；更稳的做法是不做文本替换，而是保留旧号、在映射表里做一层别名，导出时再统一渲染。

6. 进阶用法：把这份译文做成可检索的条款知识库

译文定稿之后，它的最佳归宿不是躺在共享盘里，而是变成一个能按条款号、按控制域、按关键词三路检索的知识库。我一般用最笨但最耐用的方案：一个 SQLite 表加一段导入脚本，不需要任何服务端。

建表时把控制项作为主键，五段式内容各占一列，再补一个全文检索用的合并列：

import sqlite3, re conn = sqlite3.connect('iso27799.db') conn.execute('''CREATE TABLE IF NOT EXISTS clause ( num TEXT PRIMARY KEY, domain TEXT, -- 所属控制域（章名） title_zh TEXT, title_en TEXT, control TEXT, -- 控制措施段 guidance TEXT, -- 实施指南段 health_control TEXT, -- 医疗健康特定控制段 health_guide TEXT, -- 医疗健康特定实施指南段 has_health INTEGER, -- 1/0，便于筛加重条款 fulltext TEXT )''') SEG = { 'control': 'Control 控制措施', 'guidance': 'Implementation guidance 实施指南', 'health_control': 'Health-specific control 医疗健康特定控制措施', 'health_guide': 'Health-specific implementation guidance 医疗健康特定实施指南', } def split_clause(block: str) -> dict: pos = [(k, block.find(v)) for k, v in SEG.items()] pos = [(k, p) for k, p in pos if p != -1] pos.sort(key=lambda x: x[1]) res = {} for i, (k, p) in enumerate(pos): end = pos[i + 1][1] if i + 1 < len(pos) else len(block) res[k] = block[p:end].strip() return res

split_clause的思路是按五段标题在文本中的出现位置排序后顺序切分，而不是用正则去“匹配每一段的内容”——后者在段落里出现嵌套引用时会截断错位。has_health字段直接从health_control是否为空推导，比再做一次文本判断可靠。

导入完成后，三个高频查询基本覆盖日常需求：按域看某章有多少加严条款、按关键词找“介质”“审计”相关要求、按条款号取原文用于制度引用。第二条尤其有用，写制度卡壳时用关键词反查标准原话，比通读快得多。

-- 哪些控制域的健康特定要求最密集 SELECT domain, COUNT(*) AS total, SUM(has_health) AS health_items, ROUND(1.0 * SUM(has_health) / COUNT(*), 2) AS ratio FROM clause GROUP BY domain ORDER BY ratio DESC; -- 关键词反查：涉及介质处理与销毁的条款 SELECT num, title_zh, health_guide FROM clause WHERE fulltext LIKE '%介质%' AND fulltext LIKE '%销毁%';

第一条查询会直接把“加严密度”排出来，做差距分析时按这个顺序排优先级，比按章节顺序推进合理。第二条的LIKE双条件是为了降噪，单关键词命中太多，两个词同时出现的基本就是你要找的那几条。

一个具体技巧收尾：全文检索列不要只存中文，把英文标题也拼进去。原因是很多专有表述（如 teleworking、segregation of duties）在译文里翻法不统一，用英文字面反查反而更快命中。我吃过一次亏——为了找“职责分离”相关要求，中文搜了三遍没找全，最后用英文原词一搜就出来了，因为那几条分别被译成了“职务分离”和“职责分隔”。从那以后我每次建这类标准知识库，fulltext列都强制中英双语拼接，导入脚本里固化这一步，不再靠事后补。希望帮到你。

本文还有配套的精品资源，点击获取