iso-27001-internal-audit

ISO 27001 内部审计

按照 ISO 27001:2022 开展结构化内部审计。本技能将引导你完成范围界定、控制措施评估、证据收集和审计发现整理，遵循认证审计员使用的相同工作流程。

安全模型

• 不执行脚本 — 本技能仅提供 Markdown 格式的流程指南
• 无需机密信息 — 使用公开参考数据即可运行
• 知识产权清晰 — 所有控制措施描述均为原创内容，参考了公有领域的 NIST SP 800-53。ISO 27001:2022 控制措施仅以章节 ID 引用（例如“A.5.15”），绝不使用受版权保护的标题或描述
• 证据保留在本地 — 所有证据收集命令均将输出写入本地文件系统

适用场景

在以下情况下启用此技能：

1. 准备监督审核或认证审核 — 在外部审核前 4–6 周开展
2. 开展季度内部审计 — ISO 27001 要求至少每年进行一次内部审计；季度审计是最佳实践
3. 事件后审查 — 评估控制措施是否失效，以及需要采取哪些纠正措施
4. 采用新框架 — 将现有控制措施映射到 ISO 27001 要求
5. 接入新的合规工具 — 验证自动化检查是否覆盖了正确的控制措施

请勿用于：

• 从头生成 ISO 27001 适用性声明（SoA）——请先使用 iso-27001-evidence-collection 收集证据
• 仅针对 SOC 2 的审计——请改用 soc2-readiness
• 阅读或解读特定合同条款——请使用法律协议相关技能

核心概念

控制措施领域（ISO 27001:2022 附录 A）

ISO 27001:2022 在附录 A 中包含 4 个领域的 93 项控制措施，另有 ISMS 第 4–10 条款（30 个子条款）。本技能涵盖其中 48 项优先附录 A 控制措施（共 93 项）——这些是各领域中对云原生初创公司最关键的控制措施。其余控制措施优先级较低，或通常不适用于云原生组织。

领域	控制措施数量	重点
A.5 组织	37	政策、角色、事件管理、供应商关系
A.6 人员	8	背景审查、培训、离职、保密
A.7 物理	14	设施安全、设备、介质——对云初创公司而言大多不适用
A.8 技术	34	访问控制、加密、日志记录、SDLC、网络安全
第 4–10 条款	30	ISMS 管理体系（环境、领导力、规划、支持、运行、绩效、改进）

决策树：初创公司范围界定

Is the organization cloud-native (no owned data centers)?
├── YES → Mark A.7.1-A.7.9, A.7.11-A.7.13 as "satisfied by cloud provider SOC 2"
│         Focus evidence on: laptops, home offices, mobile devices
├── NO  → Full A.7 assessment required
│
Does the organization develop software?
├── YES → A.8.25-A.8.34 (SDLC controls) are in scope
├── NO  → A.8.25-A.8.34 can be scoped out with justification
│
Does the organization handle PII?
├── YES → A.5.34 (privacy) is critical, cross-reference with GDPR/CCPA
├── NO  → A.5.34 is checkbox tier

控制措施分级

93 项控制措施的失效风险并不相同。请根据审计失败频率确定优先级：

级别	数量	处理方式
关键	~30	全面评估：证据、访谈、观察
相关	~30	常规检查：证据审查、抽查
清单项	~33	确认政策是否存在，或由云服务提供商负责

如需各控制措施的详细指南，请加载 rules/<domain>.md。

分步工作流程

步骤 1：范围与环境

1. 确定 ISMS 范围 — 哪些系统、流程、地点和人员在范围内？
2. 收集适用性声明（SoA） — 93 项附录 A 控制措施中，哪些适用？
3. 查看之前的审计发现 — 上次指出了哪些问题？纠正措施是否已关闭？
4. 检查数据时效性 — 如果使用监控仪表板或自动化测试系统，请确认数据未超过 7 天

# If Internal ISO Audit MCP server is available:
list_controls()                                    # Get all controls with tier classifications
get_control_guidance(control_id="Clause 9.2")      # Check specific ISMS clause requirements

# If reading local files:
# Check compliance/status/last_refresh.yaml for staleness

步骤 2：ISMS 条款评估（第 4 至 10 条）

大多数初创公司都会在这里失败——他们把 ISMS 当作文档，而不是一个正常运作的管理体系。

1. 第 5 条（领导作用）——是否有已签署的安全策略？谁是 ISMS 负责人？是否有管理评审的证据？
2. 第 6 条（策划）——是否进行了风险评估？评估是否为最新版本（< 12 个月）？是否引用了 SoA？
3. 第 7 条（支持）——是否有能力矩阵？培训记录是否为最新版本？
4. 第 8 条（运行）——风险处置计划是否正在执行？
5. 第 9 条（绩效评价）——是否有指标？是否进行了内部审核？是否有管理评审记录？
6. 第 10 条（改进）——是否跟踪不符合项？是否实施了纠正措施？

审核员提示：审核员会查找一条相互关联的链路——风险评估 → SoA → 风险处置计划 → 实施证据 → 监控 → 管理评审 → 改进。链路上的任何断点都是不符合项。

步骤 3：附录 A 控制措施评估

按领域检查控制措施，并优先评估关键级别：

1. 对于每项关键控制措施：

   • 检查：是否有书面策略/程序？
   • 检查：是否有实施证据？
   • 检查：是否有监控/评审证据？
   • 记录结果：符合 / 轻微不符合 / 严重不符合 / 观察项

2. 对于每项相关控制措施：

   • 检查：是否有实施证据？
   • 抽查一至两项
   • 记录结果

3. 对于每项复选框控制措施：

   • 验证策略是否存在，或云服务提供商的 SOC 2 是否涵盖此项
   • 记录为符合，或注明例外情况

# If Internal ISO Audit MCP server is available:
list_controls(domain="organizational")                      # List all controls in a domain with tiers
get_control_guidance(control_id="A.5.15")                   # Full guidance: auditor hints, pitfalls, evidence
search_guidance(query="access review", domain="organizational")  # Find related controls by keyword
get_nist_mapping(control_id="A.5.15")                       # Cross-reference to NIST SP 800-53

步骤 4：收集证据

针对每项发现，收集支持证据：

1. API 导出数据（优先）——从源系统导出的、带时间戳的 JSON/CSV
2. 屏幕截图（API 不可用时）——必须清晰显示系统时钟
3. 访谈记录——总结谁在何时说了什么
4. 文档审查——注明文档名称、版本和审查日期

证据命名约定：{control_id}_{evidence_type}_{date}.{ext} 示例：A.5.15_user-access-list_2026-02-28.json

如需详细的收集命令，请加载 rules/ 文件或使用 iso-27001-evidence-collection 技能。

步骤 5：生成发现项

对于每项不符合项：

## Finding: [Short title]

- **Control**: A.x.x
- **NIST Reference**: [NIST control ID]
- **Severity**: Major / Minor / Observation
- **Description**: [What was found]
- **Evidence**: [What evidence supports the finding]
- **Root Cause**: [Why the control failed]
- **Corrective Action**: [Specific remediation steps]
- **Due Date**: [Agreed timeline]
- **Owner**: [Person responsible]

严重程度定义：

• 严重不符合：控制措施缺失或完全无效。存在审核失败的风险。
• 轻微不符合：控制措施存在，但有缺口。必须在下一次监督审核前修复。
• 观察项：可改进之处。并非必须，但建议改进。

步骤 6：审核报告

生成结构化审核报告：

1. 执行摘要——ISMS 整体成熟度、关键发现项和建议
2. 范围——审核了哪些内容，排除了哪些内容
3. 方法——评估的控制措施、审查的证据、访谈的人员
4. 发现项——按领域分组，并注明严重程度和纠正措施
5. 正面观察——哪些方面运行良好（审核员也会记录这些内容）
6. 结论——是否已准备好接受外部审核，以及建议的时间安排

快速参考：最常失效的 10 项控制

#	控制	常见失效情况	修复方法
1	A.5.15	未定期审查访问权限	安排季度审查，导出用户列表
2	A.8.8	未进行漏洞扫描	部署 Dependabot/Snyk，安排基础设施扫描
3	A.5.24	未测试事件响应计划	开展桌面演练，记录结果
4	A.8.5	未在所有地方强制启用 MFA	为所有生产环境和管理员账户启用 MFA
5	A.5.30	未进行业务连续性测试	运行灾难恢复故障切换测试，记录 RTO/RPO 结果
6	A.8.15	未集中管理审计日志	将日志发送到 SIEM/CloudWatch/Stackdriver
7	A.8.9	未建立基线配置	记录服务器/容器基础映像
8	A.6.1	背景调查未完成	确认所有员工均已完成审查
9	A.8.32	未建立变更管理流程	要求审查 PR，记录部署流程
10	A.5.9	资产清单不完整	从云服务提供商和端点管理系统导出

应做 / 不应做

应做

• 通过 API 导出并收集带有 ISO 8601 时间戳的证据——这始终优于屏幕截图
• 测试控制措施，而不只是审查文档——审计员会检查实际执行情况，而不只是政策
• 访谈不同层级的人员——经理的说法可能与工程师不同
• 记录正面发现——这表明审计兼顾平衡且全面
• 使 SoA 与实际控制措施保持一致——SoA 与实施情况之间的差距属于重大审计发现
• 在 macOS 上有必要截图时，使用 screencapture -x ~/evidence/{filename}.png

不应做

• 截取没有显示系统时钟的门户网站——审计员会拒绝没有日期的证据
• 未核查实际执行情况就接受“我们有政策”——“给我看看”胜过“告诉我”
• 审计自己的工作——独立性要求（第 9.2 条）意味着审计员不能审计自己负责的领域
• 将勾选框控制视为零工作量——即使是不适用的控制，也需要在 SoA 中说明理由
• 跳过 ISMS 条款而只关注附件 A——首次审计失败多发生在第 4-10 条

故障排除

问题	解决方案
数据已过时（超过 7 天）	从监控仪表板刷新，或从源系统重新导出
无法确定哪些控制适用	从 SoA 入手；如果没有 SoA，请使用上方的决策树
审计前需要处理的发现太多	按优先级处理：先修复所有重大不符合项，再处理严重级别的轻微不符合项
证据时间戳与审计期间不符	在审计窗口期内（通常为 12 个月）重新收集证据
未记录云服务提供商的控制措施	向服务提供商索取 SOC 2 Type II 报告；将其控制措施映射到你的 SoA
从未开展过内部审计	这就是首次内部审计——在报告中记录这一点，并制定定期审计计划

规则

如需了解各项控制的详细指导，请加载相应的规则文件：

文件	覆盖范围
rules/access-control.md	A.5.15-A.5.18、A.8.2-A.8.5——身份、身份验证、授权
rules/incident-response.md	A.5.24-A.5.29、A.6.8——事件生命周期
rules/encryption.md	A.8.24、A.8.10-A.8.12——加密控制
rules/change-management.md	A.8.25-A.8.34、A.8.9、A.8.32——SDLC 和配置
rules/logging-monitoring.md	A.8.15-A.8.17——审计跟踪和监控
rules/business-continuity.md	A.5.30、A.8.13-A.8.14——备份、灾难恢复、业务连续性计划
rules/people-controls.md	A.6.1-A.6.8——人力资源安全生命周期
rules/supplier-management.md	A.5.19-A.5.23——第三方风险
rules/isms-management.md	第 4-10 条——管理体系运行

致谢

审计流程和控制指导由 Internal ISO Audit（Hazel Castro，ISO 27001 首席审计员，拥有 14 年以上经验，完成 100 多次审计）协助制定。

运行模式检测

此技能会自动检测并在以下三种模式下运行：

1. Internal ISO Audit MCP 服务可用（最佳）——实时查询控制项指南，并提供审核员提示、NIST 交叉引用和全文搜索

   • 检测方式：客户端中配置了 internalisoaudit MCP 服务
   • 工具：get_control_guidance、list_controls、get_nist_mapping、search_guidance
   • 服务：internalisoaudit.com/api/mcp

2. 本地合规数据可用（良好）——直接读取 compliance/ 目录

   • 检测方式：存在 compliance/status/last_refresh.yaml
   • 优点：历史测试数据、证据状态和控制项映射

3. 仅供参考（基准）——使用内嵌的 rules/ 文件，不含实时数据

   • 始终可用
   • 优点：流程指南、控制项说明和证据清单
   • 限制：不包含组织专属的状态数据

连接器

有关 Internal ISO Audit MCP 服务的设置，请参阅 CONNECTORS.md。