Incident Response Undergoing Dramatic Changes Due to the Cyber Response Capability Enhancement Act—What Preparations Are Required on the Front Lines of System Operations? [Report on the CTC System Management Study Session]

On September 15, 2026, our CEO, Takaaki Kanetsuki, spoke at an in-house seminar hosted by CTC System Management Co., Ltd. The topic was the “Cyber Response Capability Enhancement Act,” the key provisions of which will take effect on October 1, 2026.

It is anticipated that this law will have significant practical implications not only for the specific social infrastructure operators directly subject to its provisions but also for the IT companies that support the development and operation of their systems. Therefore, based on the content of the presentation, this article will discuss how incident response will change with the law’s enforcement, the preparations that system companies should prioritize, and the role of “Incident Lake” in addressing challenges on the ground.

This Isn't Just Someone Else's Problem for IT Companies—The Impact of the Cyber Response Capabilities Enhancement Act

In media coverage of the Cyber Response Capabilities Enhancement Act, attention has been focused on “proactive cyber defense” measures, such as the collection of communications data and the neutralization of servers used to launch attacks. However, Kanetsuki points out that it is actually the “public-private partnership” aspect of the law that will have the greatest impact on the day-to-day operations of private companies.

There are two specific changes. First, the reporting of information assets will become mandatory. Companies must report to the government what types of information assets they hold and which of those are critical. Additionally, if there are any changes to the reported information, a new report must be submitted.

Next is the reporting obligation based on awareness. Previously, reporting of incidents such as DDoS attacks and ransomware was primarily conducted after the extent of the damage had been determined.However, going forward, the reporting obligation will arise “at the time an organization becomes aware of the possibility that an incident has occurred.” Furthermore, while the format and standards for incident reports were previously left to the discretion of individual companies and teams, after the Act takes effect, covered entities will be required to report DDoS attacks and ransomware as soon as they become aware of them. A specific reporting format has also been established, and entities are required to submit reports in the prescribed format within a few days of becoming aware of the incident.

The “specified social infrastructure operators” directly subject to this law are limited to 258 companies nationwide—including those in the electricity, water, gas, telecommunications, finance, and rail sectors—that support the daily lives of citizens and economic activity. However, the systems of these operators do not function in isolation.If legal notification and reporting obligations are imposed on critical infrastructure operators, it naturally follows that the contracted IT service providers responsible for their IT operations will also be required to operate in accordance with equivalent standards and provide information promptly. Furthermore, in supply chain attacks, business partners with relatively weak defenses risk being used as a springboard for intrusion. In this way, the Act has a significant impact on IT companies responsible for system development and operation. In addition, Kanetsuki points out the possibility that the scope of the Act may be expanded in the future.A review of the system is scheduled approximately three years after its enactment, and based on past precedents for legislative amendments, it is entirely plausible that the scope of application will be expanded to include private-sector businesses above a certain size. Therefore, Kanetsuki urges that even companies currently not directly subject to the law must begin understanding the system and preparing for it as soon as possible.

Criminal Penalties for Violating Companies! What Practical Measures Should IT Companies Prioritize?

From this point on, we will explain the changes that occur in each phase—"Preparation," "Detection and Response," "Containment and Recovery," and "Post-Incident Activities"—in accordance with the incident response lifecycle.

1. Preparation

The first obligation is to file a report on assets. Affected businesses must report to the minister with jurisdiction over their operations the product names, model numbers, and other details of the equipment used in their server configurations and databases. Reports are required not only at the time of installation but also whenever changes are made.As a transitional measure, equipment already in use at the time of enforcement must be reported by March 31, 2027, while new installations or modifications must, in principle, be reported within four months. Violations are subject to corrective orders, and failure to comply may result in a fine of up to 2 million yen. It is important to note that this is a legal obligation subject to criminal penalties, and violations could potentially result in reputational risk for the company.

The reporting requirements are not limited to core systems. They also broadly cover firewalls, VPN devices, authentication servers, physical keys, and other items. It is essential to maintain an inventory of these information assets without omission and ensure that the inventory is always up to date.

When multiple companies share responsibility for managing a system, gaining a comprehensive overview can be a challenge. For example, if Company A is in charge of the customer management database and Company B is in charge of the inventory management database, even if each company understands its own specific configuration, they may overlook the interdependencies between the systems. To accurately report assets, both the business operator and the contractor are required to understand and manage the entire system, including these interdependencies.

2. Detection and Analysis

The most significant change in the detection and analysis phase concerns the trigger for the reporting obligation. Under the Act on Strengthening Cyber Response Capabilities, the reporting obligation arises not when damage is confirmed or an investigation is completed, but rather from the moment an incident is detected. Consequently, incidents may be subject to reporting even before actual damage has been confirmed.

Incident response begins when an alert is triggered.Next, triage is performed to determine whether it is an actual incident or merely a false positive. If it is determined at this point that an incident is highly likely to have occurred, full-scale incident response begins—and at the same time, a legal reporting obligation arises. However, there are also cases—such as with ransomware—where no clear alerts are issued, and the intrusion is discovered months later due to system slowdowns or suspicious traces. In such cases, the reporting deadline begins to run from the moment the anomaly is detected.

In the past, many organizations established procedures focused primarily on the response following triage, entrusting the initial assessment to specific personnel. Going forward, it will be important to have a system in place that allows for rapid triage based on consistent criteria and enables those decisions to be documented.

Particular caution is required when there are differences in “detection” criteria between service providers—such as SOCs (Security Operations Centers) and MDRs (Managed Detection and Response)—and the client. Even if the service provider determines that a situation warrants a “wait-and-see” approach, the client remains responsible for reporting; delays in information sharing can lead to missed or delayed reports. This risk is particularly high in large-scale projects involving multiple companies. Therefore, service providers must align their detection criteria with those of the client.Furthermore, they must establish mechanisms—both contractually and operationally—that allow for the prompt sharing of critical indicators even before an investigation is complete.

3. Containment and Recovery

During the containment and recovery phases, it is necessary to anticipate scenarios in which not only your own company but also your business partners could be used as a springboard for attacks. Even companies that are not directly subject to regulation may be required to take actions such as reporting in the future if there is a possibility that they could impact critical infrastructure operators through the supply chain.

4. Follow-up Activities

The approach to handling matters also changes during post-incident activities. In the report, it is necessary to organize information such as an overview of the incident, the circumstances leading to its occurrence, the affected devices, the operational status of the systems, and technical details regarding the attack. Among these, the scope of the impact and the timeline require the most effort to document.

If information is scattered across Slack and Teams threads, personal notes, and tickets, you’ll have to gather the material for the report all over again while continuing to handle the incident. On the other hand, if you document details such as the time of detection, time of awareness, decision, actions taken, and scope of impact as you respond, you can compile the report simply by organizing those records.

These records are not intended solely for regulatory compliance. If past decisions and procedures can be retrieved when a similar incident occurs, it can help speed up containment and recovery efforts. In other words, reports are not something to be prepared as a mere formality after the response is complete. It is essential to keep records during the response itself and turn them into assets that can be used for future responses and to prevent recurrence.

The top priority is to conduct an inventory of incident records and document triage criteria.

While all of these legal compliance measures are necessary, it is not easy to implement them all at once. Therefore, Kanetsuki has narrowed down the preparations that companies should prioritize to the following two points.

(1) Linking the Asset Register and Incident Records
If past incident records are only available in fragments, start by conducting an inventory to organize which information assets were affected by what types of incidents.

(2) Document the definition of “recognition” and the triage criteria
Establish a system that allows anyone to make judgments based on consistent criteria, without relying on specific individuals.

Kanetsuki recommends addressing these issues first as a priority, and then spending the next year or so addressing the following points.

(3) Automatically log the response timeline
Even if someone tries to keep a record during the response process, it’s easy to overlook details such as when an issue was detected, when it was acknowledged, and what decisions were made; therefore, it’s important to automate this process as much as possible.

(4) Incorporate regulatory reports into the incident command structure and training

(5) Design reporting procedures with contractors and group companies, taking into account both contractual and operational aspects

Why Is Automating Incident Logging Important?

Currently, incident reports often use unique formats specific to each company or department, and there are many cases where there are no clear standards regarding the items to be included, the level of detail, or the response time. However, going forward, reports must follow the format established by the government. Of particular importance are “scope of impact” and “timeline.”

Regarding the scope of the impact, describe which of the reported critical assets have been affected. For the timeline, you must record who detected the incident, when it was detected, and what actions were taken. The time until reporting must also be calculated based on the time of detection. In the case of ransomware, reporting is required within 3 to 5 days of detection; for DDoS attacks, reporting must be made as promptly as possible. Furthermore, after submitting the initial report, a detailed report must be submitted within 30 days.

One point to note here is how to handle incidents during holidays and extended breaks. For example, if an incident occurs late at night just before a long weekend and the response takes a long time or the report is delayed, this alone could cause the deadline to be missed. Therefore, it is essential to have a system in place that ensures record-keeping continues even at night and during extended breaks.

That said, even though we understand the importance of keeping records and responding to authorities, how to actually handle these situations is another matter entirely. When we look at the situation on the ground, there is a deep-rooted problem with incident response: it relies too heavily on individual expertise.

A survey conducted by SIGQ in 2026 revealed that 72% of incident responses rely on specific individuals, and 89% of organizations recognize the departure of key personnel as a business risk. Given this situation, it is only natural that if records are left scattered across chat logs and personal notes, the history of who made which decisions and what actions were taken will likely be lost.

Incident Lake: Systematizing the Process of “Responding While Keeping Records”

To address these challenges, SIGQ offers “Incident Lake,” an incident response platform. Rather than replacing the operational monitoring tools that field staff are accustomed to using, Incident Lake overlays an “AI layer” on top of them, thereby supporting incident response while leveraging existing workflows.

Specifically, AI agents integrate directly with chat platforms such as Teams and Slack to automatically aggregate communications related to incident response. They record the time of detection and recognition, subsequent decisions, and actions taken in chronological order. Additionally, the AI cross-references and organizes information scattered across chat platforms and internal tools to summarize the current situation. Furthermore, by integrating with configuration management databases, the system helps identify the scope of impact.It visualizes dependencies between instances and systems in diagrams, allowing you to quickly determine the extent of the impact on reported critical assets when a failure occurs. Furthermore, the AI assists with triage and the selection of personnel—tasks that are often left to individual judgment during incident response.In addition to assisting with severity assessments—which can vary depending on the person making the judgment—the system analyzes historical data accumulated in other operational monitoring tools to recommend staff members with relevant experience and suggest similar incidents along with their solutions.

We also provide templates for report preparation that address the mandatory requirements set forth in the Cyber Response Capabilities Enhancement Act. This system enables a rapid response even when the person in charge is on vacation or absent: an AI agent analyzes the situation, develops a response strategy, and drafts a report, which a human then reviews and approves.

Verifiable records support a company's business continuity and trustworthiness.

In conclusion, Kanetsuki stated that the response to the Cyber Response Capability Enhancement Act should not be limited to mere compliance with the law, but should instead serve as an opportunity to eliminate the reliance on individual expertise in incident response and enhance the organization’s overall response capabilities.

While responding to incidents, establish a system that naturally generates verifiable records of the process. This not only ensures legal compliance but also safeguards your company’s business continuity and public trust, and helps enhance security across the entire supply chain.