What the SCS Evaluation Scheme Changes: Incident Readiness Is Judged by What Happens "After" an Incident, Not Just "Before"

Author: Takaaki Kanetsuki, Representative Director, President & CEO

Introduction

In March 2026, Japan's Ministry of Economy, Trade and Industry (METI) and the Cabinet Secretariat's National Cybersecurity Office published the "Policy for Establishing a Security Measures Evaluation Scheme to Strengthen Supply Chains." Based on this policy, details of the "SCS Evaluation Scheme" operated by IPA are now coming into focus. Many companies have likely started considering obtaining a ★3 or ★4 rating at the request of their business partners.

Reading through the published requirements and evaluation criteria, one clear message emerges from the scheme: from the baseline ★3 level onward, it squarely asks not only "Can you prevent attacks?" but also "Can you recover after being attacked?"

Drawing on the requirements of the SCS Evaluation Scheme, this article explains why "recovery" matters and what companies should prepare.

The Basic Structure of the SCS Evaluation Scheme

The SCS Evaluation Scheme rates the security posture of companies that make up a supply chain in tiers, expressed as a number of stars.

What stands out is how the major requirement categories are structured. The requirements are organized into the following seven major categories, which map to the six functions of the NIST CSF (Cybersecurity Framework): Govern, Identify, Protect, Detect, Respond, and Recover.

1. Establishing governance (Govern)
2. Business partner management (Govern)
3. Identifying risks (Identify)
4. Protecting against attacks (Protect)
5. Detecting attacks (Detect)
6. Responding to incidents (Respond)
7. Recovering from incidents (Recover)

In other words, by design, "protection" is just one of seven categories, while "response" and "recovery" each stand as independent major categories. A protection-only approach cannot meet the scheme's requirements.

Why "Before" Alone Isn't Enough

Behind this is a shift to a realistic premise: you cannot prevent 100% of intrusions.

The threats assumed at ★3 are "common cyberattacks exploiting widely known vulnerabilities." Attacks exploiting known vulnerabilities in VPN appliances or routers, or ransomware infections via email, can be made less likely through defenses such as patching and multi-factor authentication, but they can't be reduced to zero. From a business partner's perspective, what they want to know isn't "Will your company be attacked?" but "When you are attacked, can you stop the damage from spreading to us, and how quickly can you restore supply?"

In fact, the description of the target level for ★3 explicitly states that "the minimum procedures necessary to report and share information with relevant parties inside and outside the company, including business partners, when an incident occurs are defined and implemented," while ★4 sets as its target supply chain resilience measures that include "initiatives toward business continuity." From the perspective of the supply chain as a whole, one company's outage can trigger a chain of supply disruptions, so it is only natural that recovery capability (resilience) becomes the central concern of the evaluation.

Recovery Preparations Required Already at ★3

If you assume "recovery won't be required until the higher ★4 level," you'll be caught off guard. A close look at the ★3 requirements reveals concrete preparations for incident response and recovery.

(1) Establishing a five-stage incident response procedure (No. 6-1-1-1)

★3 requires developing incident response procedures that include the following five steps.

(1) Discovery and reporting → (2) Initial response → (3) Investigation and response → (4) Recovery → (5) Final report

Note that "(4) Recovery" is explicitly built into the procedure. "Incident response" isn't defined as ending at containment; it extends all the way to restoring business operations.

(2) Establishing reporting and communication structures (No. 6-1-1-2 to 6-1-1-6)

• Defining internal and external contacts—including relevant authorities and competent ministries—and routes for reporting and information sharing
• Clarifying the roles and responsibilities of the CISO and the security department when an incident occurs
• Reviewing the structure at least once a year
• Preparing a reporting format
• Sharing incident cases and countermeasures internally (at least once a year, and whenever a major incident occurs)

In addition, under the business partner management category, ★3 requires defining "the roles and responsibilities of the company and its business partners when an incident occurs" with partners that share confidential information (No. 2-1-4-1). Recovery doesn't happen within a single company; it must be designed on the assumption of coordination across the supply chain.

(3) Backups as the foundation for recovery (No. 4-3-4)

Although placed under the protection category, backup is effectively a requirement for recovery. ★3 requires the following three items.

• Taking backups with defined targets, frequency, and retention periods
• Off-site backups of important confidential information
• Restore procedure documents for each backup target

Simply "taking" backups isn't enough; documented procedures for restoring them are a mandatory ★3 requirement. The biggest problems in recovering from ransomware are cases where "there were backups, but no established way to restore them" or "the backups were encrypted too." Off-site storage and documented procedures are requirements that reflect exactly these lessons.

(4) Setting target recovery levels (No. 7-1-1-1)

Under Major Category 7, "Recovering from incidents," ★3 requires that, for systems critical to business continuity, companies define target recovery levels for operations with cyberattacks in mind, and put measures in place to restore operations to those levels. The evaluation criteria give the following two examples of such measures.

• System-based business continuity: Preparing standby systems using spare machines, cloud environments, and the like
• Manual business continuity: Maintaining business partners' contact information and multiple means of communication, in preparation for communicating and carrying out work by phone, fax, and so on

It's telling that "manual business continuity" is explicitly given as an example. Keeping supply and communication going, even by analog means, until systems are fully restored—that is what "recovery" really looks like in the context of the supply chain.

(5) Education and training for everyone (No. 4-2-2)

Education and training on incident response are also ★3 requirements. They must cover not only executives and employees but also temporary staff and seconded personnel, be conducted upon onboarding and at least once a year, with records retained and content reviewed annually. Writing a procedure document isn't the end of it; you need evidence that your organization can actually act.

What ★4 Asks For: Proof That You Can Recover

At ★4, the recovery requirements go one level deeper—from "planning" to "proof."

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

For systems critical to business continuity, the following are required.

• Storing backups so that recovery to the recovery point objective (RPO) is possible
• Verifying that backups can be restored according to the restore procedure documents and within the recovery time objective (RTO)

In other words, the requirement goes beyond a paper plan to confirming that you can "actually restore within the time limit." For companies that haven't conducted restore drills, this will likely be the practical hurdle to obtaining ★4.

Supporting requirements for response and recovery

At ★4, the prerequisites that support recovery also broaden.

• Collecting and retaining logs needed for investigation (No. 4-4-3-1): Retaining firewall, proxy server, and authentication server logs for six months. If you can't determine "what happened" when an incident occurs, you can't make safe recovery decisions.
• Defining incident levels (No. 5-2-1): Defining incident levels and the scope of each level, communicating them, and analyzing and determining which level applies when an alert is received. This is the prerequisite for prioritizing response and recovery according to severity.
• Cyberattack monitoring and analysis structure (No. 1-2-2): Establishing "a structure that can derive the response if an incident occurs," starting from the detection of warning signs.

"Recovery Preparedness" Is Also Checked in On-Site Audits

The evaluation process is not to be overlooked. The scheme's policy lists the following three as examples of items to be checked in ★4 on-site audits.

• Vulnerability management structure and processes
• Security incident response procedures
• Recovery preparations aligned with business continuity requirements

Two of the three examples concern what happens "after." It's natural to read this as auditors coming to see, on the basis of evidence, "Can this company bounce back from an incident?" before they look at how comprehensive its defensive settings are.

Practical Implications: Working Backward from "Recovery"

For companies preparing for the SCS Evaluation Scheme, rather than working down the requirements list from top to bottom, it's more effective to work backward from "If we went down, how many days and to what level would we need to recover so as not to cause problems for our business partners?" Specifically, we recommend thinking in the following order.

1. Identify systems and operations critical to business continuity—what would affect the supply chain if it stopped?
2. Set target recovery levels, RPO, and RTO—define acceptable downtime based on your relationships with business partners
3. Establish and prove backup and restore procedures—test whether you can really restore within your targets
4. Establish the five-stage response procedure and reporting routes—design them to include reporting to business partners and competent ministries
5. Embed it through education and training—can everyone say "who to report to if they discover something"?

This sequence directly covers the core of the ★3 to ★4 requirements. This by no means implies that protective measures (patch management, multi-factor authentication, network perimeter defense, and so on) are unnecessary. But repositioning protection as a means to "buy time until recovery and reduce frequency" clarifies your investment priorities.

Enter Incident Lake

As we've seen, the hardest parts of the incident response the SCS Evaluation Scheme asks about are the "speed" of smoothly running all five stages—from discovery and reporting through initial response, investigation, recovery, and final reporting—and the "accuracy of records and communication" needed to deliver consistent reports on time to stakeholders inside and outside the company, including business partners and competent ministries.

Mapping detected alerts to incident levels, identifying which systems and business partners are affected, rolling that out into initial and final reports that follow the reporting format, and preserving it all as evidence you can present in annual reviews, evaluations, and audits—frankly, there are limits to running this entire flow on manual effort and back-and-forth chat alone.

Incident Lake is an incident management platform that supports this flow. It automates everything from reporting at the onset of an incident through recovery, as well as creating and managing reports, so that responders can spend their time on what they should really be focused on: stopping the damage and restoring service. Because response records accumulate automatically, it also helps you build the evidence required for the expert review at ★3 and the on-site audit at ★4.

Now that business partners can see your "real capability to respond and recover" through the SCS Evaluation Scheme, we recommend transforming your incident reporting and record-keeping into a system that doesn't depend on individual heroics.

More specific implementation details of the SCS Evaluation Scheme are being considered and refined during fiscal year 2026. For the latest information, please refer to materials published by IPA and METI.

References

• IPA, "Detailed Information on the SCS Evaluation Scheme"
• METI, "Policy for Establishing a Security Measures Evaluation Scheme to Strengthen Supply Chains" (March 27, 2026)
• SCS Evaluation Scheme ★3 and ★4 Requirements and Evaluation Criteria

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

About the Author
Takaaki Kanetsuki, Representative Director, President & CEO

Representative Director, SIGQ Inc.
Holds a master's degree from the University of Tsukuba, specializing in databases and distributed systems.
An engineer working with operational data—the unstructured, real-time information that is essential in the AI era.
Joined Money Forward, Inc. as a new graduate, working in management and development across engineering teams in Japan and abroad, including a secondment to the company's Vietnam office.
Joined PLAID, Inc. in 2022, where he was responsible for platform engineering and worked on large-scale distributed data systems.
Founded SIGQ Inc. in 2024.