NSPM-12 合规简报：国安系统网络安全将压到云、密码与事件报告链条

这份备忘录没有新设 AI 牌照，也没有直接写罚款上限。它改变的是国安系统（NSS）的网络安全治理链条：CNSS 被重新激活，NSA 局长作为 National Manager 可以对已知或合理怀疑的风险发出应急指令，云、加密、跨域解决方案和事件报告会进入更硬的政府侧审查口径。对 AI 云、数据中心、模型训练基础设施和安全服务供应商来说，风险不在「明天被罚」，而在未来 30 至 120 天内，政府客户会把新基线写进技术审查、授权、续约和分包管理。

白宫在 2026 年 6 月 12 日发布 National Security Presidential Memorandum/NSPM-12，主题是 National Policy for the Cybersecurity of National Security Systems。文件明确适用于 Department of War、Intelligence Community 以及联邦文职行政机构拥有或运行的 National Security Systems（NSS），并撤销 1990 年的 NSD-42 和 2022 年的 NSM-8。1

官方事实表把这份备忘录描述为「bolster the cybersecurity of America’s National Security Systems」和「modernize NSS governance」，并说明 NSS 包括处理机密信息或支持军事、情报任务的敏感计算机系统。2

它与 6 月 5 日的 NSPM-11 有直接衔接：NSPM-12 要求 CNSS 在 90 天内出具关于 FCEB 机构在 Secret、Top Secret、TS/SCI 等级别上配置云能力的报告，并注明该报告要与 NSPM-11 要求的 advanced computing resources roadmap 协调起草。1 这意味着，AI 国安采购的算力、云和系统安全接口不会只停留在采购策略层面，还会落到 NSS 网络安全基线和云配置基线。

NSPM-12 的第一层变化，是重新设立 Committee on National Security Systems（CNSS）。CNSS 成员包括 Department of War CIO、Intelligence Community CIO、Federal CIO，以及 NSA Director 作为 National Manager 的代表；司法部、商务部、CISA、NIST 所在的政策链条则可以作为顾问进入。1

第二层变化，是 CNSS 的要求不再只是协调意见。备忘录写明，CNSS 可以发布适用于所有 NSS 的 directives 和 complementary standards；拥有或运行 NSS 的机构必须遵守这些指令和补充标准。1

第三层变化，是 NIST 标准被设为默认底线。NSPM-12 规定，除非 CNSS 另有规定，NSS 应达到或超过 NIST 发布的网络安全标准保护水平；CNSS 可以针对 NSS 调整 NIST 基线，CNSSP 15 或其后续政策、National Manager 的临时指导将构成 NSS 的商业密码标准。1

第四层变化，是 NSA 局长作为 National Manager 获得更明确的技术权责。文件授权 National Manager 为 NSS 提供技术建议，针对影响 NSS 的安全事件提出事件响应建议，并在存在已知或合理怀疑的信息安全威胁、漏洞或风险时，向机构负责人发出应急指令。该指令可以覆盖由其他实体代表机构使用或运行的系统。1

固定日期可以先按 2026 年 6 月 12 日发布日折算。30 天节点是 7 月 12 日前，CNSS 要修订 2013 年的 CNSS Directive 900 及其认为必要的其他政策。1

60 天节点是 8 月 11 日前，CNSS 要发布下一年度 NSS roadmap 和 policy priority areas；National Manager 也要向 CNSS 建议新的或修改后的 NSS 事件报告标准，并包括必须报告事件的阈值。1

90 天节点是 9 月 10 日前，CNSS 要确定哪些 National Manager Binding Operational Directives 和 NSM-8 相关政策需要保留或纳入 CNSS Directives，并审查既有 CNSS 政策、指令和说明是否应废止或协调。1 同一 90 天内，CNSS 还要出具 FCEB 机构云能力配置报告，并审查 CNSSP-32 云安全政策需要怎样修改。1

120 天节点是 10 月 10 日前，CNSS 要向获准托管 NSS 的云服务商索取配置基线、规格和建议，用于保护联邦数据。1

第一，先判断自己是否进入 NSS 供应链。NSPM-12 的直接义务对象是拥有或运行 NSS 的政府机构，但它多次覆盖「由其他实体代表机构使用或运行」的系统，并要求 National Manager 可向这类系统相关机构发出应急指令。1 如果企业为国防、情报或联邦文职机构提供 AI 云、隔离区训练环境、模型安全评测、日志分析、跨域传输、身份与密钥管理，应该把相关项目标为「可能涉及 NSS」，不要等客户正式改合同后才排查。

第二，整理四类证据：系统边界、NIST 控制项映射、密码/密钥材料、事件报告流程。NSPM-12 要求各机构每年维护并更新 NSS inventory，至少包括该机构拥有或运行的信息系统、NSS 和非 NSS 的数量。1 供应商如果不能快速说明哪些组件、数据流和人员权限属于客户 NSS 环境，后续很难配合客户完成 inventory、指标收集和安全态势评估。

第三，把 incident response 从普通 SaaS 口径改成政府任务口径。NSPM-12 没有写出固定小时数，但它明确要求 National Manager 提出 NSS 事件报告阈值，并要求机构把新标准纳入自身 incident response policies。1 对承包商来说，准备重点是把「何为影响 NSS 的事件」「谁判断是否达到阈值」「何时通知政府客户」「日志和取证材料保留多久」写成内部流程。

第四，提前准备云配置基线回应。NSPM-12 的 120 天节点直接点名 cloud service providers accredited to host NSS。1 如果企业提供 AI 训练、推理或安全分析所需的云基础设施，应在 10 月前完成高等级环境配置基线、客户隔离、密钥控制、日志留存、管理员访问、跨域数据移动和应急变更机制的材料包。

NSPM-12 没有设置新的民事罚款、刑事责任或行政处罚金额。它更像是政府内部治理和技术基线命令。企业的直接风险来自三条链：政府客户把 CNSS/National Manager 要求写入合同，授权机构把新基线写入系统认证，或者客户在重大事件后依据应急指令要求供应商停用、隔离、补丁、迁移或提供取证材料。

合规团队本周可以先做三件事：列出所有国防、情报和联邦文职客户项目；标记可能处理机密信息或支持军事、情报任务的系统；为这些项目建立 30/60/90/120 天跟踪表。NSPM-12 的细则还没全部公开，但它已经给出了下一批问题的方向：NSS 环境在哪里，谁负责安全基线，事件什么时候上报，云和密码方案能不能经得起政府技术审查。