
SCS评估制度的变化——安全事件应对措施的评估更侧重于“发生后”而非“发生前”
本文的作者
董事长兼首席执行官
金筑 敬晃
前言
2026年3月,经济产业省与内阁官房国家网络安全统筹室公布了《关于构建“旨在强化供应链的安全对策评估制度”的制度构建方针》,基于该方针,由IPA运营的“SCS评估制度”的具体细节正逐渐明朗。想必已有不少企业应交易伙伴的要求,开始考虑获取★3和★4评级了吧。
仔细研读已公布的各项要求和评估标准,便能看出该制度传递的一个明确信息。那就是,从最低等级的★3阶段开始,评估就不仅关注“能否防御攻击”,还直接考察“遭受攻击后能否恢复正常运行”。
本文将基于SCS评估制度的要求,梳理“复工”为何重要,以及企业应做好哪些准备。
SCS评估制度的基本结构
SCS评估制度是一种通过★的数量,分级评估构成供应链的企业安全措施水平的制度。
★3 | ★4 | |
|---|---|---|
预期的威胁 | 利用广为人知的漏洞进行的一般性网络攻击 | 对供应链及第三方造成重大影响的攻击 |
要求项数 | 26件 | 43件 |
评估方案 | 经安全专家核实的自我评估 | 第三方评估(包括实地审查和技术验证) |
有效期 | 1年 | 3年 |
值得注意的是,要求事项的大类构成。要求事项由以下7个大类组成,这些大类分别对应NIST CSF(网络安全框架)的6项功能(治理、识别、防御、检测、响应、恢复)。
完善治理机制(治理)
客户管理(治理)
风险的识别
防御攻击等(防御)
攻击等的检测(检测)
事件应对(处理)
从事件中恢复(恢复)
也就是说,在制度设计阶段,“防御”仅是7个分类中的一个,“应对”和“恢复”则分别被设为独立的大类。如果仅采取一味侧重“防御”的措施,将无法达到该制度的要求标准。
为什么仅靠“发生之前”还不够呢?
其背景是,“无法100%防止入侵”这一现实前提的转变。
★3所设想的威胁是“利用广为人知的漏洞进行的一般性网络攻击”。针对VPN设备和路由器已知漏洞的攻击、通过电子邮件传播的勒索软件感染等,虽然可以通过打补丁或多因素认证等防御措施降低发生概率,但无法完全杜绝。从客户的角度来看,他们想了解的并非“贵公司是否会遭到攻击”,而是“一旦遭到攻击,能否防止对我们造成的损害扩大,以及能多快恢复供应”。
实际上,★3级标准明确指出:“在发生事件时,已明确定义并实施了向包括交易伙伴在内的公司内外相关各方进行报告和信息共享所需的最低限度流程”;而★4级则将包括“业务连续性措施”在内的供应链韧性提升策略作为评估标准。从整个供应链的角度来看,一家企业的停摆会导致连锁性的供应中断,因此恢复能力(韧性)成为评估的核心关注点,这可谓是必然的。
★3阶段所需的“回归”准备工作
如果认为“恢复运营的要求大概从较高的★4级开始”,那就会被出其不意地打个措手不及。仔细分析★3级的要求,会发现其中明确要求在事件应对和恢复方面做好具体准备。
(1) 制定5级事件响应流程(No.6-1-1-1)
在★3中,要求制定包含以下5个步骤的事件响应流程。
①发现报告 → ②初步应对 → ③调查与处理 → ④恢复 → ⑤最终报告
值得注意的是,该流程中明确包含了“④恢复”这一环节。所谓“事件响应”,并非仅止于控制事件,而是将业务恢复至正常状态这一环节也纳入了其定义范围。
(2) 完善报告与联络机制(第6-1-1-2至6-1-1-6条)
制定包括相关主管部门及主管部委在内的公司内外联系方式以及报告和信息共享渠道
明确安全事件发生时CISO等及安全负责部门的职责与责任
每年至少一次的系统检查
完善报告格式
在公司内部共享事件案例及应对措施(每年至少一次,以及发生重大事件时)
此外,在业务伙伴管理的分类中,与共享机密信息的业务伙伴之间明确“发生安全事件时本公司与业务伙伴的角色及责任”(No.2-1-4-1)也是一项★3级要求。恢复工作不能仅由本公司独立完成,而需以供应链上的协作作为前提进行设计。
(3) 作为恢复基础的备份(第4-3-4条)
虽然归类于“防御”项下,但备份实际上可视为恢复所需的一项要求。★3级的要求包括以下三点:
执行了规定备份对象、备份频率及保存期限的备份操作
重要机密信息的异地备份
制定针对各备份对象的恢复操作指南
仅“进行备份”是不够的,连恢复操作手册都属于★3级必备条件。在从勒索软件攻击中恢复的过程中,最棘手的问题往往是“虽然有备份,但没有确立恢复方法”或“连备份文件也被加密了”这类情况,因此,异地存储和完善操作手册的要求,正是吸取了这些教训而提出的。
(4) 目标恢复级别的设定(第7-1-1-1条)
在大分类7“从安全事件中恢复”中,针对对业务连续性至关重要的系统,在以网络攻击为前提设定业务目标恢复水平的基础上,要求以★3为标准制定相关措施,以确保业务恢复至该水平。评估标准中列举了以下两项措施作为示例:
基于系统的业务连续性:通过备用设备及云环境等构建备用系统
人工业务连续性:为通过电话、传真等方式进行联络和开展业务,应完善交易方的联系方式及多种联络渠道
“依靠人力维持业务连续性”这一做法被直接列举出来,颇具深意。在系统完全恢复之前,即使通过传统方式,也要确保供应和联络不中断——这正是供应链语境下“恢复”的真实写照。
(5) 全员参与的教育与培训(第4-2-2条)
关于事件发生时的应对措施,教育与培训也是★3级要求。不仅针对高管和员工,还包括派遣员工及借调人员,要求在新员工入职时及每年至少一次开展培训,妥善保管记录,并对内容进行年度审查。不能仅止于制定操作规程,还必须提供证明该组织具备“行动能力”的证据。
★4中要求的“能够恢复的证明”
在★4阶段,复出要求从“计划”进一步深化为“验证”。
RPO·RTO的验证(No.7-1-1-2)
对于对业务连续性至关重要的系统,需满足以下要求。
妥善保管备份,以确保能够恢复到目标恢复时间点(RPO)
应确认能够按照恢复操作指南,并在目标恢复时间(RTO)内完成备份的恢复
也就是说,要求不仅要制定纸面计划,还要确认“能否在规定时间内实际恢复”。对于未开展恢复演练的企业而言,这将成为获得★4评级在实务上的障碍。
支持应对与恢复工作的相关要求
在★4中,支持回归的前提条件也将进一步扩大。
获取和保存调查所需的日志(No.4-4-3-1):将防火墙、代理服务器和认证服务器的日志保存6个月。如果发生安全事件时无法查明“发生了什么”,就无法做出安全的恢复决策。
事件级别的定义(No.5-2-1):明确规定事件级别及各级别的适用范围并予以通告,以便在收到警报时分析并判断其属于哪个级别。这是根据严重程度确定响应和恢复优先级的前提。
网络攻击的监测与分析机制(No.1-2-2):从检测征兆出发,建立“能够制定出发生安全事件时应对措施的机制”。
“恢复准备”也被列入实地审查的确认范围
绝对不能忽视的是评估流程。作为★4级实地审查中应确认事项的示例,制度构建方针列举了以下三点。
漏洞管理体制与管理流程
安全事件应对流程
符合业务连续性要求的恢复准备
在三个示例中,有两个涉及“事件发生后”的相关内容。自然可以理解为,评审方在考察防御设置的全面性之前,会首先基于证据来评估“该公司能否从安全事件中恢复”。
对实务的启示——从“恢复”倒推制定对策
对于正在考虑如何应对SCS评估制度的企业而言,与其从要求事项清单的开头依次逐项落实,不如从“当公司运营中断时,需要多少天、恢复到什么程度才不会给客户带来麻烦”这一问题倒推,这种方法更为有效。具体而言,建议按照以下顺序进行思考。
确定对业务连续性至关重要的系统和业务——哪些环节一旦中断会影响供应链
目标恢复级别、RPO 和 RTO 的设定——根据与客户的关系定义可接受的停机时间
完善并验证备份与恢复流程——测试是否能在既定目标范围内真正恢复数据
完善5个阶段的应对流程和报告渠道——在设计时应涵盖向交易方及主管部委的报告
通过教育与培训确保落实——所有人都能说出“发现问题后该向谁报告”吗
这一顺序直接涵盖了★3→★4要求的核心内容。这绝不意味着无需采取防御措施(如补丁管理、多因素认证、网络边界防护等),但如果将防御重新定位为“争取恢复时间并降低发生频率”的手段,投资的优先级便会变得清晰。
于是便来到了Incident Lake

正如前文所述,SCS评估制度所关注的事件响应难点在于:能否顺畅地完成从发现报告到初步应对、调查、恢复及最终报告这五个阶段的“速度”,以及能否在规定期限内向包括客户和主管部门在内的公司内外各方提供一致且准确的“记录与传达”。
将检测到的警报与事件级别关联起来进行判断,确定哪些系统和哪些客户会受到影响,同时按照报告格式编制速报和最终报告,并将其作为可在年度检查、评估和审查中出示的证据留存下来。坦率地说,仅靠人工和聊天工具的往来来完成这一系列流程,确实存在局限性。
Incident Lake 是一款支撑这一工作流程的事件管理平台。它将事件发生时的报告、恢复处理以及报告的生成与管理等环节实现自动化,使负责人能够将时间用于本应重点关注的“遏制损失、恢复服务”上。由于处理记录会直接积累,这也有助于完善★3专家确认和★4现场审查所要求的证据链。
正因为如今通过SCS评估制度,客户能够直观地看到企业的“应对与恢复能力”,因此我们建议将事件报告和记录机制调整为不依赖于个人努力的形式。
此外,关于SCS评估制度的具体实施内容,目前正在2026年度进行探讨和细化。最新信息请参阅IPA及经济产业省公布的资料。
参考
IPA《SCS评估制度的详细信息》
经济产业省《关于构建“旨在加强供应链的安全对策评估制度”的制度方针》(2026年3月27日)
※本文基于截至2026年8月的公开信息。
本文的作者
董事长兼首席执行官
金筑 敬晃
SIGQ股份有限公司 代表董事
毕业于筑波大学研究生院,专业为数据库与分布式系统。
在AI时代不可或缺的、负责处理运营数据(即非结构化、实时信息)的工程师。
应届毕业后加入Money Forward股份有限公司。曾外派至越南分部,在包括海外在内的开发一线从事管理和开发工作。
2022年加入Plaid股份有限公司,负责平台工程(Platform Engineering)工作,参与大规模分布式数据系统的开发。
2024年创立SIGQ株式会社。
实用文章一览


