入侵电话在周日晚上 11:47 打来。首席信息安全官（CISO）正与事件响应负责人通话，你的外部法律顾问正在接入，而作战室（war room）里已经有人在问那个决定接下来九十六小时的关键问题：这具有重要性（materiality）吗？
对于美国上市公司而言，这个问题不再是法律顾问和审计委员会之间悠闲的谈话。自 2023 年 12 月以来，美国证券交易委员会（SEC）要求注册人在确定网络安全事件具有重要性后的四个工作日内提交 Item 1.05 Form 8-K。错过截止日期、错误描述事件或在错误的条目下过度披露，都可能让你收到反馈信、Wells 通知，或者是一场比泄露事件本身持续更久的证券集体诉讼。
本指南探讨了该规则在 2026 年的实际运作方式——什么会触发四个工作日的倒计时、如何在不无故拖延的情况下做出重要性判断、美国总检察长何时可以为你争取时间、Regulation S-K Item 106 对年度 10-K 报告的要求，以及 SEC 前两年执法中显而易见的代价高昂的错误。
规则的实际要求
SEC 的最终规则于 2023 年 7 月通过，包含两个重要部分。第一部分是关于 Form 8-K 的事件报告。第二部分是关于 Form 10-K（或外国私人发行人的 Form 20-F）中网络安全风险管理、战略和治理的年度披露。
Form 8-K 的 Item 1.05 要求注册人披露其确定的任何具有重要性的网络安全事件。披露必须描述事件的性质、范围和时间节点的重大方面，以及对注册人的重大影响或合理可能产生的重大影响——包括对注册人财务状况和经营成果的影响。8-K 通常在做出重要性判定后的四个工作日内提交。
Regulation S-K 的 Item 106 要求注册人在年度报告中描述：
- 其评估、识别和管理网络安全威胁带来的重大风险的过程
- 网络安全威胁产生的任何风险（包括过往事件产生的风险）是否已经或合理可能对其产生重大影响
- 董事会对网络安全风险的监督（包括任何负责的董事会委员会）
- 管理层在评估和管理重大网络安全风险中的作用，包括相关负责人员的专业知识
所有注册人（包括小型报告公司）必须在 2024 年 12 月 15 日或之后结束的财政年度，在 Inline XBRL 中标记其网络安全披露内容。
这两部分协同工作。10-K 描述方案；8-K 报告方案未能防止的事件。
四个工作日的倒计时并非从发现事件时开始
这是该规则最容易被误解的一点。倒计时并不是从你的 SOC 警报出现可疑活动、发现恶意软件、攻击者窃取数据，甚至当你致电取证公司时开始的。倒计时是从公司确定该事件具有重要性时开始的。
该判定必须在发现后“不得无故拖延”的情况下做出。SEC 明确拒绝为重要性判定设定固定时间表，承认事件的范围和影响通常需要几天或几周才能明确。但“不得无故拖延”也不意味着可以无限期暂停判定以让律师进行谈判。
由此产生三个实际意义：
- 你必须有一套记录在案的流程，用于对事件进行分流并将其上报至重要性判定环节。 如果 SEC 询问你是如何达成判定的，你应该能够出示一份书面的事件响应手册、一个定义明确的判定委员会以及会议记录。
- 聘请取证人员、致电 FBI 或支付赎金并不会暂停判定倒计时。 事件的终止或表面终止（包括因支付勒索软件赎金而导致的终止）并不能免除注册人进行重要性判定的义务。
- 你可以在判定之前与执法部门沟通。 上市公司可以在事件响应的任何阶段提醒政府部门，包括在确定重要性之前，只要这不会无故拖延其内部的重要性判定流程。
“重要性”对网络安全事件意味着什么
联邦证券法下的重要性与最高法院几十年前在 TSC Industries 和 Basic v. Levinson 案中阐述的标准相同：如果存在实质性可能性，使理性投资者在做出投资决策时认为该信息是重要的，或者如果该信息会显著改变可用信息的总体组合，则该信息具有重要性。
SEC 拒绝编写专门针对网络安全的重要性测试。相反，注册人必须应用其已应用于运营、财务和法律风险的相同框架。往往会使网络安全事件趋向于具有重要性的因素包括：
- 定量财务影响： 预计损失的收入、补救成本、赎金支出、监管罚款、客户补偿、扣除自留额后的保险赔付净额，以及减值资产的冲销
- 定性影响： 声誉受损、客户信任丧失、对业务线的损害、商业秘密被盗、受监管的个人信息泄露、关键运营中断、违反合同的风险以及诉讼风险
- 范围： 受影响的客户、员工或账户数量；涉及的地域和监管体系；中断持续的时间
- 数据敏感性： 支付卡数据、受保护的健康信息、源代码、并购团队的收件箱
- 运营中断： 工厂停工、ERP 系统宕机、供应链中断、零售零售端失效、理赔处理延迟
至关重要的是，该规则要求评估实际影响和“合理可能”的影响。如果一次泄露事件的直接财务损失看起来不大，但监管或诉讼风险很严重，它仍然可能具有重要性。相反，一次触发了警报但未导致数据外泄且无运营影响的入侵可能不具有重要性——即使它在内部事件报告中看起来很吓人。
公司财务部（Division of Corporation Finance）曾公开强调一点：不要为了规避阈值而将无关的网络安全事件汇总到单一的重要性评估中。但你应该汇总相关的事件——例如，由同一威胁主体发起的重复入侵，或一系列共同产生重大影响的相关事件。
8-K 表格中应包含及不应包含的内容
项目 1.05 要求注册人描述：
- 事件性质、范围和时间的重要方面
- 对注册人产生的重要影响或合理可能产生的重要影响，包括对财务状况和经营业绩的影响
另外两项规定也至关重要。首先，注册人无需披露有关公司计划响应、网络安全系统、相关网络和设备或潜在系统漏洞的具体或技术信息——即任何会阻碍事件响应或修复的内容。其次，如果初始备案时无法获得重要信息，随后该信息变得可用，注册人必须修订原始 8-K 表格（再次使用项目 1.05）。在目前已提交项目 1.05 披露的公司中，约有三分之一随后进行了至少一次修订。
其中的艺术在于平衡透明度与运营安全及诉讼风险。2026 年的最佳实践包括：
- 陈述已知事实和正在调查的内容。 避免推测，但不要为了让披露看起来影响较小而低估其影响。
- 具体描述运营影响。 “使某些系统离线”比“迅速做出反应”更有用。“订单处理中断约五个工作日”比“产生暂时影响”更有用。
- 尽可能量化财务影响。 即使是范围估值和“合理可能具有重要性”的估计，也比保持沉默要好。SEC 在 2024 年年中的审查中专门发布了意见函，要求公司扩大对潜在重要影响的披露，而不仅仅局限于财务状况和经营业绩。
- 避免提供与重要性无关的技术细节。 投资者不需要知道 CVE 编号或未能检测到恶意软件的具体终端检测产品。
- 如果你尚未完成评估，请勿声明“尚未发现重要影响”。 这种表述本身可能会演变为证券欺诈指控。
项目 1.05 与项目 8.01 的陷阱
在该规则实施后的前十八个月里，最常见且最可避免的错误是，对于每一次网络安全事件都条件反射般地根据项目 1.05 进行备案，包括那些公司尚未确定是否具有重要性，或已明确认定不具重要性的事件。
2024 年 5 月，SEC 公司金融部主任发表公开声明，澄清项目 1.05 仅适用于具有重要性的事件。如果公司选择自愿披露（例如，因为媒体已有报道、客户正在询问，或公司希望掌握话语权），且尚未做出重要性判定或判定结果为非重要，则披露应列在 8-K 表格的另一个项目下，通常是项目 8.01（其他事项）。
原因显而易见：如果每起事件都归入项目 1.05，投资者将无法区分重大违规与常规事件。标签会被稀释，重要披露也会失去其信号作用。
由此产生三条实用规则：
- 对于尚未确定是否具有重要性的事件，使用项目 8.01 进行自愿披露。
- 在随后做出任何重要性判定后的四个工作日内，迁移至项目 1.05。 新的项目 1.05 8-K 表格可以交叉引用之前的项目 8.01 备案。
- 同步记录重要性判定过程。 内部备忘录、委员会会议纪要和时间戳可以证明你是经过深思熟虑后做出的决定，而非草率行事。
一项反映这一转变的数据是：在 2024 年 5 月的声明发布后的一年里，根据项目 8.01 而非项目 1.05 提交的与网络安全相关的 8-K 比例大幅增长。以前对所有事件都使用项目 1.05 的公司意识到，SEC 正在关注项目的选择，而不仅仅是披露的内容。
司法部长何时可以暂停计时
该规则包含一项狭窄的国家安全和公共安全延迟例外。如果美国司法部长认定立即披露将对国家安全或公共安全构成重大风险，并以书面形式通知 SEC，注册人可以延迟提交项目 1.05 8-K：
- 初始期限最长可达 30 天，外加
- 如果司法部长再次确认该认定，可延长最多 30 天，外加
- 在仅与国家安全相关的特殊情况下，最后可再延长最多 60 天
司法部和 FBI 已发布申请这些延迟的程序。在依赖此例外情况之前，需要明确几个现实情况：
- 司法部已发出信号，延迟申请将极少获得批准。默认预期是在确定重要性后的四个工作日内提交备案。
- 相关的测试标准是该事件的公开披露是否会威胁公共安全或国家安全，而不是事件本身是否具有危险性。
- 申请应在做出重要性判定后尽快通过 FBI 提交，而不是在四个工作日的窗口期结束时。司法部评估申请需要实际的前置时间。
- 无论是否申请延迟，都鼓励在事件响应期间与 FBI 协调，但这本身并不能成为暂停重要性判定的理由。
对于大多数公司而言，正确的运营假设是不会获得任何延迟。该例外是为真正的国家安全案例准备的，而不是作为一种诉讼管理工具。
公平披露规则 (Reg FD) 与项目 1.05 并存
一个细微但至关重要的观点是：8-K 备案是一种满足公平披露规则 (Regulation FD) 的公开且同步的披露。但在事件响应过程中进行的许多对话——与客户、供应商、监管机构、执法部门、保险公司、大型企业客户团队，甚至员工的对话——则不然。
如果一家公司告知主要客户其数据受到泄露影响，且该信息具有重要性 (Material) 但尚未公开，那么这种披露即使在泄露事件本身尚未公开宣布的情况下，也可能违反 Reg FD。一旦你做出重要性认定，安全的预设假设是：你只有几个小时（而不是几天）的时间来使内部沟通与计划中的 8-K 备案保持一致。
法律顾问和投资者关系 (IR) 部门应编写以下脚本：
- 针对一旦泄露事件公开即刻开始的媒体询访的预留声明 (Holding statements)
- 与计划中的 8-K 备案措辞一致的客户沟通函
- 不会在公开备案前泄露重大非公开信息的员工沟通
- 与保险公司和再保险公司的协调，他们通常会较早获悉，但不应被透露重大非公开信息
项目 106：奠定基调的年度披露
一份严谨的项目 1.05 披露始于一个可信的项目 106 计划。年度披露为投资者——以及原告律师——提供了一个衡量你事件响应表现的基准。
一个辩护性强的项目 106 披露通常描述：
- 正式的网络安全风险管理框架（通常锚定在 NIST CSF 2.0、ISO 27001 或类似标准）
- 定义明确的威胁识别流程，包括第三方和供应链风险
- 与更广泛的企业风险管理计划的集成——而非孤立的 IT 功能
- 合资格第三方的参与（评估机构、渗透测试人员、托管检测和响应提供商、内部审计）
- 由指定委员会（通常是审计委员会、风险委员会，在某些情况下是董事会全体成员）进行的董事会层面监督，并记录会议频率
- 挂钩到具体职位的管理责任（通常是 CISO），并披露相关专业背景（多年经验、认证、以往职位）
- 对过去已产生重大影响或合理可能产生重大影响的任何事件的诚实描述
一些细微之处：
- 披露必须诚实。 关于“世界级网络安全计划”的愿景式描述，如果与公司的实际操作不符，正是原告律师在泄露发生后会仔细审查的那类陈述。
- CISO 的履历很重要。 关于“丰富经验”的模糊表述不如具体的凭证、以往的 CISO 职位和安全认证更有力。
- 董事会监督应当具体。 “董事会监督网络安全”太模糊了。应指明具体的委员会，描述其会议频率，并说明其审查的材料类型。
- 当时不具有重要性的过去事件，现在可能已经累积成了具有重要性的事件。 不要遗漏相关的历史记录。
前两年的启示
在强制报告实施的前十八个月里，SEC 企业融资部运行了观察家所称的“扫描” (Sweep)——发布关注两个特定问题的反馈信：
- 在事件尚未被认定为具有重要性，或已被认定为不具有重要性的情况下，选择根据项目 1.05 进行披露。
- 需要将潜在重大影响的讨论扩展到财务状况和经营业绩之外，包括声誉、运营、客户、监管和诉讼维度。
第二点值得强调。许多最初的 8-K 备案读起来很局限：“该事件预计不会对我们的财务结果产生重大影响。”如果公司正面临监管审查、客户流失和集体诉讼，这种语言在技术上可能是正确的，但在实质上具有误导性。投资者关心大局；SEC 的评论明确表示披露也应如此。
第二个模式：修正案。在提交了项目 1.05 8-K 备案的公司中，约有三分之一提交了至少一份修正案，相当一部分公司提交了两份或更多。这是正常且符合预期的。调查会产生新的事实；新的事实会产生更新的披露。不可接受的是“如果具有重要性我们将进行更新”的承诺，却从未有后续行动。
构建运营手册
如果你的公司正在准备——或更新——其项目 1.05 就绪状态，该手册应涵盖：
从检测到认定的工作流。 定义安全运营中心 (SOC) 的升级路径、法律评估步骤、重要性委员会的构成，以及委员会在活动事件期间的会议频率。大多数公司从发现事件到解决事件期间，会设立每日一次或每日两次的例会。
重要性委员会章程。 一个由少数指定人员组成的小组——通常包括首席财务官 (CFO)、总法律顾问、首席信息安全官 (CISO)、投资者关系负责人和一名高级业务主管——被授权做出认定。章程应规定法定人数、决策权、文档标准以及向审计委员会的汇报机制。
披露模板。 预先起草的项目 1.05 和项目 8.01 的 8-K 壳文件，加上客户通知用语、预留声明和常见问题解答 (FAQ) 文档。在时间压力下从零开始起草会导致披露质量下降。
跨功能桌面演练。 年度或半年度演练，带领所有利益相关者走过一个假设的泄露场景：法律、安全、投资者关系 (IR)、财务、传播、业务部门领导和董事会委员会。演练应明确涵盖四个工作日的时限。
供应商和合同依赖关系。 外部顾问、取证公司、勒索软件谈判专家和 IR 咨询公司应已签署主服务协议 (MSA) 并处于待命状态。在活动事件期间谈判这些合同会耗费你本不拥有的时间。
网络保险协调。 许多保单要求在紧迫的时间线内发出通知。将通知与重要性认定工作流协调起来，使证券披露和保险通知不会发生冲突。
做对与做错的代价
会计和合规成本是实实在在的。到 2026 年，一家中型上市公司预计将承担：
- 50,000 至 200,000 美元的初始项目构建及外部法律顾问工作
- 每年 50,000 至 150,000 美元的持续性 GRC 工具、第三方评估以及桌面演练支持费用
- 对于任何可报告事件，需支付 150,000 至 500,000 美元的特定事故成本（数字取证、法律顾问、沟通联络）
- 如果披露不力，可能面临高达七位数的监管罚款和集体诉讼风险
这些成本分布在多个总账科目中——专业服务、保险、软件订阅、内部薪资——且往往记账编码不一致，这导致年度同比分析和审计委员会报告变得异常困难。建立清晰的会计科目表，将网络风险管理支出从其他 IT 和法律成本中分离出来，能为审计委员会提供监督该项目所需的数据。这同时也能为下一轮投资者尽职调查和网络安全保险的续保周期提供更准确的数据。
让你的披露记录像安全控制一样可审计
网络安全事故响应涉及安全、法律、沟通、财务和会计职能——而你在那四个工作日内建立的披露记录将受到 SEC、审计委员会、保险公司以及极有可能出现的对方律师的审查。适用于安全控制的同一标准同样适用于你的财务记录：它们应当是透明的、带有时间戳的、受版本控制的且可复现的。Beancount.io 为财务团队提供了一个完全可审计、在 Git 中进行版本控制的纯文本会计平台，并为未来审计委员会预期的 AI 辅助审查做好了准备。免费开始使用，了解为什么财务专业人士正在转向纯文本会计，以实现现代合规所要求的审计轨迹。