7.2 内部控制（Module A）
7.2.1 程序
根据 CRA Annex VIII Module A 的内部控制 (Internal Control) 是最简单的合规评估 (Conformity Assessment) 程序。制造商自行评估其产品是否满足基本要求。
适用范围
Module A 适用于：
- 标准产品（其核心功能不对应 Annex III 或 IV 中任何类别）—— 始终适用
- Class I —— 仅在满足 7.2.2 中的条件时
- 符合自由与开源软件条件并投放市场的 Class I 与 Class II 产品 —— 依 Art. 32(5) 可采用标准类别的程序
对于非 FOSS 的 Class II 与关键产品，Module A 不足够：必须有第三方参与，无论是通过 Module B+C、Module H，还是保证等级至少为substantial 的欧洲网络安全认证方案。
始终可以选择更严格的路径
制造商始终可以选择比所要求者更严格的合规评估程序（Art. 32(1)）。
7.2.2 Class I 产品何时可以使用内部控制
只有在制造商未适用、或仅部分适用相关协调标准（其索引已在《欧盟官方公报》公布）、通用规范或保证等级至少为 substantial 的欧洲网络安全认证方案时，Class I 重要产品才需要第三方合规评估。
标准与产品之间的差距
产品的范围往往宽于相关协调标准的适用范围，而这些额外功能可能带来不同或额外的网络安全风险。
制造商始终须依 Art. 13(2) 进行风险评估，并据此检查适用该协调标准是否覆盖了产品的全部风险。若未覆盖，制造商必须以其他方式确保产品满足基本要求，并作为合规评估活动的一部分记录采取了哪些额外措施来处理这些剩余风险。
这不会让你失去 Module A
若协调标准覆盖了核心功能相关的风险，制造商可对整个产品（含额外功能）使用内部控制程序——前提是额外风险已被处理并记录。
示例： 某杀毒软件的核心功能是搜索、清除或隔离恶意软件（实施法规 (EU) 2025/2392 附件 I 第 4 项）。它还包含磁盘清理功能与反跟踪功能。制造商对整个产品进行风险评估，适用覆盖核心功能风险的协调标准，并为额外功能补充措施。整个产品可使用 Module A。
被集成的重要或关键组件
产品集成了本身属于另一重要或关键产品的功能时，规则相同。决定类别及适用机制的是产品整体的核心功能，而非孤立看待的被集成组件的功能。
示例： 某硬件产品的核心功能是路由器（实施法规 (EU) 2025/2392 附件 I 第 12 项），并额外集成了防火墙组件。该产品整体适用 Class I 机制。制造商适用覆盖路由器核心功能风险的协调标准，并可适用防火墙的协调标准来覆盖防火墙相关风险。Module A 仍然可用。
Module A 资格 ≠ 完整的合规推定
获准使用内部控制，与享有合规推定并非一回事。推定仅覆盖标准实际涵盖的风险；上述示例中的额外功能可能不在其内。参见 1.12 协调标准。
7.2.3 内部控制流程
1. 编制技术文档
根据 CRA Annex VII，必须具备完整的技术文档：
2. 要求审查（Annex I）
审查 Annex I 的每项要求并记录合规性：
第I部分 — 安全要求：
| 编号 | 要求 | 合规 | 证据 |
|---|---|---|---|
| 1 | 适当的网络安全水平 | ☐ | [参考文档] |
| 2 | 无已知可利用漏洞 | ☐ | CVE 监控 + Trivy 扫描 |
| 3.1 | 机密性保护 | ☐ | [加密、访问控制] |
| 3.2 | 完整性保护 | ☐ | [Cosign、校验和] |
| 3.3 | 可用性保护 | ☐ | [弹性措施] |
| 4 | 安全默认配置 | ☐ | [默认安全] |
| 5 | 未授权访问防护 | ☐ | [认证、授权] |
| 6 | 攻击面最小化 | ☐ | [最小服务、端口] |
| 7 | 存储数据的机密性 | ☐ | [加密] |
| 8 | 存储数据的完整性 | ☐ | [完整性检查] |
| 9 | 数据最小化 | ☐ | [仅必要数据] |
| 10 | 基本功能的可用性 | ☐ | [弹性] |
| 11 | 不利影响最小化 | ☐ | [日志、监控] |
| 12 | 安全相关信息 | ☐ | [日志、审计跟踪] |
| 13 | 安全更新能力 | ☐ | [更新机制] |
第II部分 — 漏洞处理：
| 编号 | 要求 | 合规 | 证据 |
|---|---|---|---|
| 1 | 识别和记录漏洞（SBOM） | ☐ | SBOM 生命周期 |
| 2 | 及时修复漏洞 | ☐ | 补丁管理 |
| 3 | 定期测试和审查 | ☐ | CI/CD 安全扫描 |
| 4 | 公开披露已修复的漏洞 | ☐ | Security Advisories |
| 5 | 协调漏洞披露 (Coordinated Vulnerability Disclosure) | ☐ | CVD 策略 |
| 6 | 提供安全更新 | ☐ | 更新机制 |
| 7 | 及时提供更新 | ☐ | 补丁管理 SLA |
| 8 | 漏洞报告联系点 | ☐ | SECURITY.md |
3. 签发 EU 符合性声明
审查成功完成后：
- 根据 Annex V 编制 EU 符合性声明（模板）
- 由授权人员签署
- 在仓库中归档
4. CE 标志
- 在产品或其包装上加贴 CE 标志
- 对于软件：在文档中以及（如适用）在用户界面中显示
- 必须可见、清晰、不可磨灭
5. 保留文档
- 技术文档：产品投放市场后10年
- EU 符合性声明：产品投放市场后10年
- 存储位置：本仓库（Git 版本控制）
7.2.4 检查清单：Module A — 内部控制
- [ ] 核心功能已确定并记录（→ 7.1.2）
- [ ] 产品分类已完成（标准，或满足 7.2.2 两个条件的 Class I，或依 Art. 32(5) 的 FOSS）
- [ ] 已评估协调标准与产品范围之间的覆盖差距，并记录了额外措施
- [ ] 技术文档完整（Annex VII）
- [ ] 网络安全风险评估已执行
- [ ] Annex I 第I部分 — 所有要求已审查并记录
- [ ] Annex I 第II部分 — 所有要求已审查并记录
- [ ] SBOM 已生成并归档
- [ ] 漏洞处理流程已建立
- [ ] EU 符合性声明已编制并签署
- [ ] CE 标志已加贴
- [ ] 文档已归档（10年保留）
7.2.2 节解释的来源与法律地位：欧盟委员会 CRA 指南。