ISMS（ISO27001）所需文件清单｜标准要求的文件化信息与记录梳理

用「必备」与「实务上几乎必需」两层来理解ISMS文件

ISO/IEC 27001:2022正文（第4至10章）在若干处明确写明须「保持为文件化信息」或「保留文件化信息」。这构成第一层，即标准明确要求的文件化信息。缺少这一层本身就可能在审核中被提出。

第二层是为说明附录A控制措施如何运行而编制的制度与程序。标准并未规定必须叫什么名字，但如果访问权限的授予与复核完全没有约定，就很难说明控制措施确实在运行。整体取证流程可参见ISO27001认证取得流程。

标准正文明确要求的文件化信息一览

按条款号整理，可以机械地核对本组织缺什么。下表名称沿用标准用语，实际文件名可用自己的叫法。把多项合并为一个文件，或把一项拆成多个文件，通常都不影响符合性。

其中风险评估的过程与结果通常最费时间，具体做法另见ISMS风险评估。

围绕附录A控制措施常见的制度与程序

下表是100人规模以内IT企业常见的编制单位。不必都做成独立文件，不少组织把它们作为章节收进一份「信息安全管理制度」。判断标准是：修订频率不同的内容不要放进同一份文件。

「文件」与「记录」的区别

旧版把文件与记录分开要求，而ISO/IEC 27001:2022将两者统一称为文件化信息。不过在实务中，区分两者的性质仍然更便于管理。

• 文件（方针、制度、程序、表单）规定「今后要做什么」，管理重点是版本与审批
• 记录（申请、会议纪要、复核结果、审核报告）是「实际发生了什么」的证据，管理重点是防止事后改写
• 按标准的措辞，前者大致对应「保持」，后者对应「保留」
• 空白表单是文件，填写后的表单是记录，这样区分有助于台账清晰

文件体系的层级与控制数量的做法

通常按方针 → 制度 → 程序 → 表单／记录四层搭建。层级越高修订越少、审批者职位越高；层级越低越贴近现场、变化越频繁。这一关系一旦被打乱，细小的运行调整也要最高管理者审批，更新就会停滞。

• 方针只保留一份；仅当读者对象或审批者确实不同，才另设专题方针
• 制度写到「谁、做什么、多久一次」为止，界面操作与工具专属步骤下沉到程序文件
• 工具或界面名称一变就要改的内容，不要嵌进制度正文
• 与既有内部规定（如员工手册、个人信息保护方针）重复的内容，引用而不是抄写
• 不要把无法维持的频率（例如每月全量盘点）写进制度

对文件管理本身的要求（7.5.2 / 7.5.3）

文件的管理方式本身也是要求。7.5.2针对创建与更新，要求标识（标题、日期、编制人、编号等）、格式与载体、以及适当的评审与批准。7.5.3要求文件在需要的时间与地点可获得，并得到充分保护。

使用模板的注意点与审核中常被查看的记录

模板作为起点是有效的，但直接沿用会残留与本组织实际不符之处。并不存在的职位名称、并未召开的会议、并未采用的技术要素若原样留在文件中，就容易与记录相互矛盾而被提出。一般而言，引入模板后立即逐句核对其中写明的频率与角色名称是否与实际一致，可以减少返工。

此外，审核更关注「是否按文件执行」的证据。以下记录尤其容易出现期间缺漏或审批栏空白。

• 教育与能力记录（实施日期、对象、内容、理解程度确认）
• 访问权限复核记录（涉及系统、实施人、纠正内容）
• 内部审核的计划与报告（含可体现审核员独立性的记载）
• 管理评审纪要（对各项输入的处理与决定事项）
• 安全事件记录（包含轻微事件；长期为零往往会被追问检测机制）
• 供应方评估与复核记录

把版本管理与审批流程交给工具的选择

文件清单本身用文字处理软件或表格也能做。负担集中在靠人力持续追踪版本、审批、复核期限以及文件与记录之间的对应关系。当文件、记录、风险、控制措施与适用性声明分散在不同文件里时，一次修订是否波及其他部分只能靠人工逐一确认。

把这部分工作交给工具，审批履历与版本会自动留存，复核期限的遗漏也更容易发现。若想先确认本组织缺少哪些文件，可以从ISMS现状自查开始梳理容易缺失的项目。

本文仅供一般信息参考，不保证任何审核结果或认证获取。制度与费用可能变化，请向认证机构确认最新信息。