企业官网建设流程全解析

简介：围绕医疗健康信息安全与隐私合规需求，这份 ISO 27799-2016 标准中文翻译面向医疗保健组织、个人健康信息保管人及安全合规从业者，帮助理解如何基于 ISO/IEC 27002 开展健康信息安全管理。内容围绕个人健康信息的机密性、完整性与可用性展开，涉及信息治理、公司治理和临床治理的关系，健康信息安全中的威胁与脆弱性，需保护的健康信息范围，以及医疗健康特定控制措施和实施指南，适合用于制度对照、风险梳理与内部培训。资源包共 1 个 PDF 文件，约 2.29MB，为中文翻译修订版，目录层级较完整，便于按章节检索术语定义、策略要求与控制要点。已有 1112 人学习，读者可据此对照标准原文梳理控制项，理解健康信息系统在自然灾害、系统故障和拒绝服务攻击下的可用性要求，并用于合规自查和安全管理体系文件编制。

1. 评审现场被追问依据时，这份 ISO 27799:2016 中英对照译本能接住哪几句话

医疗信息化项目做到安全方案评审，最容易被问住的一句不是“你上了什么设备”，而是“这条控制措施的依据在哪、为什么这么定”。手上这份 ISO 27799-2016 标准翻译（格式修订）就是专门接这类问题的：它把健康信息学领域的信息安全管理要求，按 ISO/IEC 27002:2013 的控制域逐条重排成中英对照，每一条控制措施下面挂着医疗健康特定控制措施和对应的实施指南。做医疗健康标准的同行都有体会，隐私安全在别的行业是合规成本，在临床场景里直接连着患者安全，一份错译、漏条、编号错位的译本，拿去做差距分析会把整张台账带沟里。这份资源的价值不在“有中文”，而在条款编号、术语译法、增补段落三件事能不能被直接引用进制度和内审证据链。适合三类人：要过行业审查的安全负责人、写医院信息安全制度的合规岗、给医疗数据产品划范围的产品和研发。

2. 拆骨架：14 个控制域里，哪些条款被健康场景改写过

拿到一份标准译本，从第一页顺着读是最低效的读法。ISO 27799:2016 的正文主体是第 5 章到第 18 章这 14 个控制域，编号体系和 ISO/IEC 27002:2013 完全对齐，也就是说它没有另起一套框架，而是“寄生”在成熟框架上做加法。搞清楚加法加在哪一层，比通读一遍有用得多：做差距分析时你能一眼判断某条是该照抄通用要求，还是必须补健康增量。

2.1 五段式条目结构：Control 和 Health-specific control 不是一回事

翻到任意一条控制措施，比如 5.1.1 信息安全策略，你会看到固定顺序的几个小节：Control（控制措施）、Health-specific control（医疗健康特定控制措施）、Implementation guidance（实施指南）、Health-specific implementation guidance（医疗健康特定实施指南），有的条目后面还有 Other information 或 Other health-specific information。这个五段式是整份标准的阅读钥匙，顺序不能乱着看。

正确的读法是分层判断，而不是从头念到尾。第一层看 Control，这是 27002 的原文陈述，判断你的组织有没有做这件事；第二层看 Health-specific control，这是 27799 加的增量，判断健康场景下有没有额外的控制目标；第三层看两份 implementation guidance，前者给通用做法，后者给贴合临床流程的做法；最后看 Other information，那里通常放着边界说明和交叉引用。很多人栽在第二层和第三层混着看，把实施建议当成强制控制目标写进整改计划，工作量凭空翻倍。

提示：Health-specific control 里出现的要求，才需要在台账里单独占一行打分；Health-specific implementation guidance 里的内容属于“怎么做”，用来写方案，不用单独打分。

举个实际的操作差异。同一条控制措施，通用实施指南可能只说到“策略应传达至相关人员”，健康特定实施指南则会落到临床科室的交接班、第三方检验机构的接口人员、区域平台的数据交换方这些具体角色上。前者是要求，后者是路径。写制度时引前者，写操作规程时抄后者，两者的引用位置不一样，交付物也不一样。

2.2 增补密度分布：三类条款对应三种处理策略

把译本目录从头扫一遍，你会发现不同条款的增补程度差别很大，这个差别本身就是信息。有的条款带 Health-specific control，有的只带 Health-specific implementation guidance，还有的直接写一句“没有健康信息安全管理的附加指南”。这三种情况对应三种完全不同的落地策略，混为一谈是常见的返工源头。

这张表能直接指导裁剪。看到“有 Health-specific control”，说明标准认为健康场景存在额外控制目标，你的差距分析里必须单独列一行，缺了就是漏项；看到“只有 Health-specific implementation guidance”，说明控制目标没变，只是实施路径要按临床流程改，台账里不用新增行，但方案文档里要写清适配方式；看到“明确写无附加指南”，最省事的做法就是照抄 27002，评审时被问“健康场景有没有特殊要求”，直接翻到这一条给对方看，比临场解释有用。

我在一个模拟项目里见过反面案例：项目组把 8.1.3 和 8.2.3 这两条也按“健康特定”去设计，硬加了一套资产使用审批流，结果和已有的设备管理制度打架，内审时两套文件互相矛盾。标准自己都写了没有附加指南，说明通用要求已经覆盖，过度设计只会增加维护成本。

2.3 用条款号当主键，别用页码

这份译本是格式修订版，目录、页眉、条款编号都重排过，但目录里的页码仍然存在错位。最典型的是 7.2.3 纪律处分流程：标题挂在第 42 页附近，可它下面的 Control 却标着第 69 页。类似情况在目录里不止一处，按页码跳转很容易翻到隔壁章节，找半天找不到对应段落。

稳妥的定位方式是三级索引：条款号是主键，页码只做参考，制度文件编号做映射。建索引的时候，先把目录页复制成纯文本，用一条命令把每个控制域下挂了多少条统计出来，和 27002 的条目总数对一遍，对不上的地方就是译本合并条目或者漏排的地方，优先人工核对。

# 把译本目录页复制成 toc.txt 后执行 # -Eo 只输出匹配到的条款号，awk 取第一段（控制域号），sort -n 按数字排序，uniq -c 计数 grep -Eo '^[0-9]{1,2}(\.[0-9]{1,2}){1,2}' toc.txt \ | awk -F. '{print $1}' \ | sort -n \ | uniq -c

参数说明：-E启用扩展正则，-o只打印匹配部分避免带出整行标题，(\.[0-9]{1,2}){1,2}覆盖 x.y 和 x.y.z 两种层级，-F.按点切分取第一段。跑完会得到类似“5 域 2 条、6 域 12 条、7 域 11 条、8 域 13 条”的分布，拿这个分布和 27002:2013 的域内条目数对比，差异超过两条的域就值得逐条翻一遍。

这个动作看着笨，但省下来的时间很实在。我一般会在项目启动第一周就把这张索引表建好，后面每次评审被问到某条要求，直接按条款号查表，比在 PDF 里翻目录快得多，也不会因为页码错位引错条款。

3. 锁术语：第 3 章那 9 个定义，决定你的数据分类边界

标准第 3 章术语和定义只有短短几页，很多人直接跳过，这是最亏的读法。术语决定适用范围：什么算个人健康信息、谁算可识别个人、护理对象的边界画到哪，这三个问题答错，后面的数据分类分级、访问控制策略、脱敏规则全部跟着错。译本把英文原词和中文译法并排给出，正是为了让你能回头核对原文，而不是只记中文。

3.1 九个必须逐字锁死的术语

这张表不是让你背，是让你在做全文替换时有对照。制度文件里最怕同一个概念三种叫法：正文写“个人健康信息”，附件写“个人医疗数据”，表单又写“患者隐私数据”，内审时审核员会追问这三者是不是一回事、边界在哪，你答不上来就得回去改文件。

3.2 “可识别个人”和“护理对象”：两条边界线怎么画

identifiable person是判定门限。一条数据是否落入标准的保护范围，取决于它能不能关联到具体的可识别个人。直接标识好判断，姓名、病历号、身份证件号、生物特征都算；麻烦的是间接标识的组合，出生日期加性别加居住区域邮编这三项凑一起，很可能已经能唯一定位到人。做数据分类时，我一般会要求业务方把字段按“直接标识 / 准标识 / 非标识”三档标注，准标识字段单独列一张表，评估组合后的重识别风险，而不是只盯着姓名和证件号做脱敏。

subject of care是范围线。译本把它译成护理对象，这个范围比患者宽，包含接受健康管理、体检、随访、陪护登记的人群。很多机构的数据分类只覆盖住院和门诊患者，健康管理App的注册用户、体检中心的受检者、区域平台上的建档人群全在范围外，结果是标准覆盖了一半，剩下那一半在检查时变成盲区。范围线画完之后，再回头对一遍healthcare organization的定义，研究机构和保险方这些非诊疗主体也在适用范围内，制度里的适用范围章节要写清楚。

3.3 术语一致性核对的三个动作

第一个动作是建表。把第 3 章的九个术语抄成两列表格，一列英文原词、一列译本译法，再加一列“本机构习惯叫法”，三列并排放着，谁写文件都按这张表来。第二个动作是全文替换，把历史制度文件里不统一的叫法批量改掉，改的时候保留一份替换记录，方便内审时追溯。第三个动作是交叉校验，拿英文原词去译本里搜一遍，再拿中文译法搜一遍，两边命中数差得多的地方，往往就是排版粘连或者漏译的位置。

第三个动作在这份译本上尤其必要。排版修订过程中出现过单词粘连和空格错位，比如Implementationguidance少了中间的空格，personal health information在术语表里被排成persona l health information。直接搜“implementation guidance”会漏掉那几条，搜“personal health information”也会漏。校验的时候把搜索词放宽，或者用正则允许中间隔几个字符，能救回不少条目。

4. 落地五步：把条款翻成能过内审的台账、制度与指标

读懂了结构和术语，接下来是把纸面条款变成组织里跑得动的东西。这一段的差距最大：同样一份译本，有人能做出可执行的整改计划，有人做出来的台账内审一看就打回。区别不在读得细不细，而在有没有把“条款—现状—证据—责任人”这条链闭合。下面这套五步是我在几个模拟项目里反复用过的顺序，可以照着改。

4.1 第一步：建一张条款级差距台账

台账的粒度必须到控制措施这一层，也就是 x.y.z 三位编号，不能停在控制域。停在域级别的台账看起来清爽，实际没法派活：一个“访问控制”域下面十几条要求，分给谁、什么时候完成、证据是什么，全说不清。

填表有个技巧：先填“是否含健康增补”这一列，把带 Health-specific control 的条款单独标色。这些条款是健康场景的增量，通用安全体系里往往没有对应内容，是差距最集中的地方。标完色再打现状分，优先级自然浮出来。

4.2 第二步：裁剪要写理由，别写“不适用”

裁剪是必做的，标准里大量控制措施对大机构和小机构的意义完全不同。问题在于裁剪的写法：只写“不适用”三个字，内审一定追问。合格的裁剪记录要写清三件事——为什么不适用、替代措施是什么、残余风险谁接受。

判断能不能裁，我用三条线卡：涉及患者安全的不能裁，涉及法定义务的不能裁，涉及可审核性的不能裁。前两条好理解，第三条最容易被忽略。标准里多处强调健康信息全生命周期的可审核性，日志、变更记录、访问痕迹这些条款看着琐碎，一旦裁掉，出了事件连回溯都做不到，那时候补是补不回来的。反过来，和业务规模明显不匹配的可以裁，比如超大规模机房的某些物理控制要求，在小规模部署里按实际情况调整并留下风险评估记录就行。

4.3 第三步：制度文件和控制条款做多对多映射

一份制度覆盖多条控制措施，一条控制措施也可能被多份制度覆盖，这是常态。映射表要按多对多建，不要强行一对一。

映射做完，会发现有些条款没有任何制度覆盖，这就是真空区；也会发现有些制度找不到对应条款，那是历史遗留文件，该废就废。两个方向都要处理，只处理前一个，制度体系会越来越臃肿。

4.4 第四步：监控指标和数据来源要一起定

指标不落到数据来源，就是墙上标语。定指标时我会强制要求写出三样：怎么算、从哪个系统取、多久看一次。

最后一行是这份标准特有的。通用指标只能反映基线，健康增补条款的整改率才是这份译本带来的增量价值。把这个指标放进管理层汇报，讨论的焦点会从“有没有做安全”转到“临床场景的特殊要求覆盖了没有”，层次不一样。

5. 避坑排查：这份译本最容易翻车的五个地方

格式修订版的坑分两类：一类是排版层面的，翻页、检索、复制的时候踩；一类是理解层面的，把增补条款当强制项、把实施建议当控制目标。两类坑的表现不同，排查手法也不同，混着查容易越查越乱。

5.1 排版层面的三个坑

坑一：搜“specific”搜不全。现象是按关键词全文检索，只出来一半结果，另一半明明在页面上却搜不到。原因是排版时用了英文连字，Health-specific被排成了带连字的Health-specific，那个fi是两个字符合成的一个字形，检索工具按单字符匹配自然对不上。

解决办法是放宽搜索词，用Health-spe打头，或者用正则允许中间隔一到两个字符，比如Health-spe.{0,2}cific。我一般在建索引阶段就把所有形似词归一化，把连字统一替换成普通字母，后面所有检索都走归一化后的版本，省得每次都要记着放宽。

坑二：按目录页码跳转翻错页。现象是照目录页码翻过去，发现是隔壁章节，最典型的是 7.2.3 纪律处分流程，目录里 Control 标的页码和正文实际位置差了二十多页。原因是格式修订时页码域没有完全更新，目录保留了旧值。

解决方式是放弃页码定位，一律用条款号。临时救急可以看页眉的章节标题，但页眉也可能有残留错误，最终还是回到条款号检索。长期做法是把目录页单独抽出来做成索引表，条款号和页码并排，页码只做参考值。

坑三：单词粘连导致漏条。现象是搜“implementation guidance”漏掉几条，搜“personal health information”也漏。除了连字问题，还有纯空格丢失，比如Implementationguidance中间没有空格，术语表里persona l health information中间多了一个空格。

解决办法是建别名索引：把常见粘连写法和正常写法都登记进去，检索时同时命中。做这件事花不了半小时，但能避免后面反复怀疑“是不是译本漏译了”。漏译和排版问题是两回事，排查顺序应该是先排除排版，再怀疑内容。

5.2 理解层面的两个坑

坑四：把 Health-specific control 当成必须新增的控制措施。现象是项目组拿到译本，把每一条带健康特定控制的条款都当成新增要求，整改计划一下子多出几十项，工期撑不住，最后草草收场。

原因是没分清控制措施和实施指南的层级。Health-specific control 确实是增量要求，但它的落地方式可以是“在现有控制里补一句”，不必新建一套流程。比如某条增补要求是策略要覆盖特定协作方，那就在现有策略文件里加一段适用范围，不用另发一份文件。判断标准很简单：这条增补能不能被现有制度的一个章节吸收，能吸收就不新建。

坑五：对外交付直接引用译本条款号，对方对不上。现象是把 27799 的条款号写进方案交付，外部审核方拿着 27002 的编号体系来对，两边对不上，来回解释好几轮。

原因是 27799 沿用 27002 的编号，但增补段落是自成体系的，同一个编号在两份文件里的段落构成不一样。解决办法是双编号引用：主编号写 27799 条款号，后面括注对应的 27002 条款号，涉及健康增补的内容再标一句“健康特定控制”。这样既保留了健康场景的增量信息，又能和通用体系对接。

注意：这五个坑里，前三个属于文件本身的排版遗留，后两个属于使用方法问题。排查时先花十分钟排除排版，再讨论内容理解，顺序反了会浪费大量时间在“到底是我理解错了还是文件错了”上打转。

6. 进阶用法：把全译本做成可筛选的条款映射表

读到第三遍的时候，纸质翻阅的效率就到头了。真正高频的使用场景是这样的：评审会上有人问“哪些条款带健康特定控制又还没整改到位”，或者内审前要抽十条增补条款做样本。这时候需要的不是再读一遍，而是一张能筛能排序的表。

我的做法是先把条款清单整理成一张 CSV，至少四列：clause（三位条款号）、title_en、title_cn、has_health_control（Y/N）。整理过程本身就是一次通读，大概两三个小时能过完 14 个域。整理完之后用一小段脚本加工成索引表，把控制域号抽出来，把英文标题归一化成检索键，再按条款号做数字排序。

import csv SRC = "iso27799_clauses.csv" # 手工整理的条款清单 OUT = "iso27799_index.csv" # 输出的优先整改索引 def build_index(row): clause = row["clause"].strip() # 控制域号取条款号第一段，用于按域聚合统计 domain = clause.split(".")[0] # 检索键统一小写并压缩空白，规避 PDF 连字和粘连导致的关键词搜不到 key = f"{clause} {' '.join(row['title_en'].lower().split())}" return {**row, "domain": domain, "search_key": key} with open(SRC, newline="", encoding="utf-8") as f: rows = [build_index(r) for r in csv.DictReader(f)] # 只留带健康特定控制措施的条款，这些是通用体系里通常没有覆盖的增量 priority = [r for r in rows if r["has_health_control"].strip().upper() == "Y"] # 按条款号逐段转 int 排序，避免 "10" 排在 "9" 前面 priority.sort(key=lambda r: [int(x) for x in r["clause"].split(".")]) with open(OUT, "w", newline="", encoding="utf-8") as f: writer = csv.DictWriter(f, fieldnames=list(rows[0].keys())) writer.writeheader() writer.writerows(priority) print(f"总条款 {len(rows)} 条，含健康特定控制措施 {len(priority)} 条")

代码本身的逻辑很直白，值得说的是三个参数选择。domain单独抽出来，是为了后面按控制域做统计，看看哪个域的增补最密集，资源就往哪里倾斜；search_key做小写和空白压缩，专门对付前面提到的连字和粘连问题，有了这一列，后续检索不再依赖 PDF 原文的排版质量；排序键逐段转整数，是因为条款号是点分数字，按字符串排会把 10 排到 9 前面，台账顺序一乱，评审时翻页就乱。

这张表跑出来之后，用法可以很灵活。内审前筛has_health_control = Y且台账现状分小于等于 1 的条款，就是本轮优先整改项；做管理层汇报时按domain分组计数，能直观看出健康增补集中在哪几个控制域；新人接手时按条款号顺序过一遍这张表，比啃整本 PDF 快得多。

还可以再往前推一步：把台账里的现状分、责任人、证据位置作为额外列合并进同一张表，用clause做连接键。合并之后，一份文件同时承担索引、台账、汇报三种用途，不用在多个 Excel 之间来回对号。这一步做完，译本才算真正从“参考资料”变成“工作底稿”。

血泪经验是排版类问题一定要在项目最开始处理掉。我早期接手一个模拟项目，直接拿 PDF 全文检索做条款核对，搜“specific”只出一半结果，当时以为是译本漏译，花了整整两天逐页人工比对，最后发现是连字问题。从那以后我每次拿到标准译本，第一件事都是先做归一化和索引表，再开始读正文，宁可多花半天，也不在检索上反复翻车。希望帮到你。

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