Changes in the SCS Evaluation System—Incident Response Is Evaluated Based on What Happens “After” an Incident Occurs, Rather Than “Before” It Happens

Introduction

In March 2026, the Ministry of Economy, Trade and Industry (METI) and the National Cyber Security Coordination Office of the Cabinet Secretariat published the “Policy for Establishing a Security Measures Evaluation System to Strengthen Supply Chains,” and details of the “SCS Evaluation System”—administered by the IPA based on this policy—are gradually coming to light. It is likely that many companies have begun considering obtaining ★3 or ★4 ratings in response to requests from their business partners.

When you read through the published requirements and evaluation criteria, one clear message emerges from this program. It is that, starting from the minimum ★3 level, the program directly assesses not only “whether an attack can be prevented” but also “whether the system can recover after an attack.”

In this article, based on the requirements of the SCS evaluation system, we will explain why “return to work” is important and what companies need to prepare for.

Basic Structure of the SCS Evaluation System

The SCS Evaluation System is a system that uses a star rating to assess the security measures of companies in the supply chain on a graded scale.

Of particular note is the structure of the major categories of requirements. The requirements are organized into the following seven major categories, which correspond to the six functions of the NIST CSF (Cybersecurity Framework): governance, identification, protection, detection, response, and recovery.

1. Establishing Governance

2. Business Partner Management (Governance)

3. Risk Identification

4. Defense Against Attacks, etc. (Defense)

5. Detection of Attacks, etc. (Detection)

6. Incident Response (Response)

7. Recovery from an Incident (Recovery)

In other words, as designed, “Prevention” is merely one of seven categories, while “Response” and “Recovery” are each established as separate major categories. Measures focused solely on prevention cannot meet the standards required by this system.

Why Is “Before It Happens” Alone Not Enough?

The underlying issue is that “ it is impossible to prevent intrusions 100% of the time ."

★3 defines the threat as “common cyberattacks that exploit widely known vulnerabilities.”While the probability of attacks exploiting known vulnerabilities in VPN devices and routers, or ransomware infections via email, can be reduced through defensive measures such as applying patches and using multi-factor authentication, it cannot be eliminated entirely. From a business partner’s perspective, the question is not “Will your company be attacked?” but rather, “If you are attacked, how quickly can you prevent the damage from spreading to us and restore supply?”

In fact, the criteria for the ★3 level explicitly state that “the minimum procedures necessary for reporting and sharing information with internal and external stakeholders, including business partners, in the event of an incident are defined and implemented,” while the ★4 level sets as a standard supply chain resilience measures that include “initiatives for business continuity.”From the perspective of the entire supply chain, the shutdown of a single company can lead to a domino effect of supply disruptions; therefore, it is inevitable that resilience becomes the central focus of the evaluation.

Preparations for a "Return" Required at the ★3 Stage

If you assume that “the requirements for recovery will likely start at the higher ★4 level,” you’ll be caught off guard. A closer look at the ★3 requirements reveals that specific preparations are required for incident response and recovery.

(1) Establishment of a 5-step incident response procedure (No. 6-1-1-1)

For Level 3, you are required to develop an incident response procedure that includes the following five steps.

① Incident Report → ② Initial Response → ③ Investigation and Response → ④ Recovery → ⑤ Final Report

It is worth noting that “④ Recovery” is explicitly included in the procedure. “Incident response” is defined not merely as containing the incident and ending there, but as extending all the way to restoring operations to normal.

(2) Establishment of a Reporting and Communication System (No. 6-1-1-2 through 6-1-1-6)

• Establishment of contact information and reporting and information-sharing channels for internal and external parties, including relevant authorities and competent ministries and agencies

• Clarifying the Roles and Responsibilities of the CISO and Other Security Departments in the Event of an Incident

• Annual or more frequent inspections of the system

• Standardization of Reporting Formats

• Internal Sharing of Incident Case Studies and Countermeasures (At least once a year, and whenever a serious incident occurs)

Furthermore, under the business partner management category, establishing “the roles and responsibilities of the company and its business partners in the event of an incident” with business partners with whom confidential information is shared (No. 2-1-4-1) is a ★3 requirement. Recovery cannot be completed by the company alone; it must be designed with collaboration across the supply chain in mind.

(3) Backups as the Foundation for Recovery (No. 4-3-4)

Although classified under "Defense," backups are essentially a requirement for recovery. The following three points are required for ★3:

• Backing up data in accordance with specified criteria, frequency, and retention period

• Remote Backups of Critical Confidential Information

• Development of Restore Procedures for Each Backup Target

Simply “taking backups” is not enough; having a procedure manual for restoring data is a ★3 mandatory requirement. The most common problems encountered when recovering from a ransomware attack are cases where “backups existed but there was no established procedure for restoring them” or “the backups themselves were encrypted.” The requirements for off-site storage and the preparation of procedure manuals are precisely the lessons learned from these incidents.

(4) Setting the Target Recovery Level (No. 7-1-1-1)

In Major Category 7, “Recovery from Incidents,” organizations are required (★3) to establish target recovery levels for business operations— with cyberattacks in mind—for systems critical to business continuity, and to implement measures to restore operations to those levels. The evaluation criteria list the following two examples of such measures:

• System-Based Business Continuity: Establishing Standby Systems Using Backup Equipment, Cloud Environments, and Other Means

• Maintaining Operations Through Manual Methods: Establishing a list of business partners’ contact information and multiple communication channels to facilitate communication and business operations via telephone, fax, and other means

It is telling that “manual business continuity” is explicitly cited as an example. Ensuring that supply and communication continue—even through analog means—until the system is fully restored: this is the true nature of “recovery” in the context of the supply chain.

(5) Education and Training for All Employees (No. 4-2-2)

Education and training on incident response are also a ★3 requirement. These must cover not only executives and employees but also temporary staff and seconded employees; they must be conducted upon new hires and at least once a year, with records retained and the content reviewed annually. It is not enough to simply create a procedure manual; evidence is required to demonstrate that the organization is “capable of taking action.”

★4: “Demonstration of the Ability to Return to Work”

In ★4, the requirements for returning to service go a step further, shifting from “planning” to “demonstration.”

RPO and RTO Validation (No. 7-1-1-2)

The following requirements apply to systems critical to business continuity.

• Store backups in a manner that ensures recovery to the target recovery point (RPO)

• Verify that backups can be restored in accordance with the restore procedure and within the Recovery Time Objective (RTO).

In other words, the requirement goes beyond a theoretical plan and extends to verifying that “a recovery can actually be completed within the allotted time.” For companies that have not conducted restore drills, this will likely be a practical hurdle to achieving a ★4 rating.

Peripheral Requirements Supporting Response and Recovery

In ★4, the prerequisites for returning are also expanding.

• Collection and Retention of Logs Required for Investigations (No. 4-4-3-1): Retain logs from firewalls, proxy servers, and authentication servers for six months. If you cannot determine “what happened” when an incident occurs, you cannot make a safe decision regarding recovery.

• Definition of Incident Levels (No. 5-2-1): Define and communicate the levels of incidents and the scope of each level, and analyze and determine which level an incident falls under when an alert is received. This serves as the basis for prioritizing response and recovery efforts according to severity.

• Cyberattack Monitoring and Analysis Framework (No. 1-2-2): Establishing a framework that enables the development of response measures in the event of an incident, based on the detection of early warning signs.

"Recovery Preparations" Also Included in the Scope of On-Site Inspections

One thing you can’t afford to miss is the evaluation process. As examples of items to verify during the ★4 on-site review, the policy for establishing the system lists the following three points:

• Vulnerability Management Framework and Processes

• Security Incident Response Procedures

• Recovery Preparations in Accordance with Business Continuity Requirements

Two of the three examples relate to the “aftermath” of an incident. It’s only natural to interpret this as meaning that auditors will look for evidence-based proof of whether “this company can recover from an incident” before assessing the comprehensiveness of its defensive measures.

Implications for Practice—Developing Countermeasures by Working Backward from “Return”

For companies considering how to address the SCS evaluation system, rather than simply working through the list of requirements from top to bottom, it is more effective to take a backward-planning approach, starting with the question: “If our operations were to come to a halt, how many days would it take to restore them to what level to avoid causing inconvenience to our business partners?” Specifically, we recommend following this sequence of steps.

1. Identifying Systems and Operations Critical to Business Continuity— What, If It Stops, Would Impact the Supply Chain?

2. Setting Target Recovery Levels, RPO, and RTO —Defining Acceptable Downtime Based on Customer Relationships

3. Establishing and Validating Backup and Restore Procedures —Testing Whether Data Can Actually Be Restored Within the Specified Targets

4. Establishing a 5-Step Response Procedure and Reporting Channels —Designing the Process to Include Reporting to Business Partners and the Relevant Government Agencies

5. Reinforcement Through Education and Training —Can Everyone Say, “Who Should I Report It To If I Discover It?”

This sequence directly addresses the core requirements for moving from ★3 to ★4. This is by no means to suggest that defensive measures (such as patch management, multi-factor authentication, and network perimeter protection) are unnecessary; however, if we reframe defense as a means to “buy time for recovery and reduce the frequency of incidents,” the investment priorities become clear.

And so, Incident Lake

As we have seen so far, the key challenges in incident response addressed by the SCS evaluation system are the “speed” required to smoothly progress through the five stages—from discovery and reporting to initial response, investigation, recovery, and final reporting—and the “accuracy of documentation and communication” needed to provide consistent reports to both internal and external parties, including business partners and the relevant government agencies, within the specified deadlines.

We link detected alerts to specific incident levels to assess them, identify which systems and business partners are affected, and compile them into preliminary and final reports in accordance with the reporting format, while maintaining a record that can be presented during annual inspections, evaluations, and audits. To be honest, there are limits to managing this entire process relying solely on manual effort and back-and-forth chat exchanges.

Incident Lake is an incident management platform that supports this workflow. It automates everything from reporting an incident to recovery, as well as report creation and management, allowing personnel to focus their time on what truly matters: “stopping the damage and restoring services.” Since response records are automatically accumulated, this also helps ensure that the necessary documentation is in place for ★3 expert verification and ★4 on-site audits.

Now that business partners can assess your “response and recovery capabilities” through the SCS evaluation system, we recommend that you transition your incident reporting and recording processes to a system that does not rely on individual effort.

Please note that the specific implementation details of the SCS evaluation system are currently being reviewed and refined in fiscal year 2026. Please refer to the documents published by the IPA and the Ministry of Economy, Trade and Industry for the latest information.

For Reference

• IPA " Detailed Information on the SCS Evaluation System "

• Ministry of Economy, Trade and Industry, “Policy for Establishing a System for Evaluating Security Measures Aimed at Strengthening Supply Chains” (March 27, 2026)

• SCS Evaluation System: ★3 and ★4 Requirements and Evaluation Criteria

*This article is based on publicly available information as of August 2026.