How the Cyber Response Capability Enhancement Act Will Transform Incident Response: What Should System Operations Teams Prepare? [CTC System Management Seminar Report]

On September 15, 2026, SIGQ CEO Takaaki Kanetsuki spoke at an internal seminar hosted by CTC System Management Corporation. The topic was Japan's "Cyber Response Capability Enhancement Act," whose main provisions take effect on October 1, 2026.

The law is expected to have a major practical impact not only on the specified social infrastructure providers it directly covers, but also on the IT companies that support their system development and operations. Based on the talk, this article covers how incident response will change once the law takes effect, which preparations system companies should prioritize, and the role "Incident Lake" plays in addressing the challenges teams face on the ground.

System Companies Can't Afford to Look Away: The Impact of the Cyber Response Capability Enhancement Act

Media coverage of the Act has focused on "active cyber defense"—collecting communications data and neutralizing attackers' servers. But Kanetsuki points out that what will most affect day-to-day work at private companies is actually the "public-private collaboration" part of the law.

There are two concrete changes. The first is mandatory registration of information assets. Companies must report to the government what information assets they hold and which of them are critical. Whenever the registered details change, they must file again.

The second is a reporting obligation triggered by recognition. Until now, reporting on incidents such as DDoS attacks and ransomware has generally happened after damage was confirmed. Going forward, the obligation arises "at the moment you recognize that an incident may have occurred." In addition, incident report formats and reporting criteria have so far been left up to each company or team. Once the Act takes effect, covered providers will be obligated to report from the moment they recognize a DDoS attack or ransomware. The reporting format is also prescribed, and reports must be submitted in the designated format within a few days of recognizing the incident.

The "specified social infrastructure providers" directly covered by the Act are limited to 258 companies nationwide that support daily life and economic activity—electricity, water, gas, telecommunications, finance, railways, and so on. But these providers' systems are not built by a single company. When critical infrastructure providers become subject to legal registration and reporting obligations, the system companies they outsource IT work to will naturally be expected to operate to equivalent standards and provide information quickly. On top of that, in supply chain attacks, business partners with relatively weak defenses risk being used as a stepping stone for intrusion. In this way, the Act has a major impact on IT companies responsible for system development and operations. Kanetsuki also notes that the scope of the Act may expand in the future. A review of the system is planned roughly three years after enforcement, and judging by precedent from past legal amendments, it is quite conceivable that coverage will be extended to private companies above a certain size. That's why, Kanetsuki argues, even companies not currently covered need to start understanding the system and preparing early.

Criminal Penalties for Violators: What Should System Companies Prioritize in Practice?

Following the incident response lifecycle, the talk walked through the changes in each phase: "Preparation," "Detection and Response," "Containment and Recovery," and "Post-Incident Activity."

‍

1. Preparation

The first obligation is asset registration. Covered providers must report to the competent minister the product names and model numbers of equipment used in their server configurations and databases. Registration is required not only at deployment but also whenever changes are made. As a transitional measure, equipment already deployed at the time of enforcement must be registered by March 31, 2027, while new deployments and changes must, in principle, be registered within four months. Violations are subject to corrective orders, and failing to comply carries a fine of up to 2 million yen. The key point is that this is a legal obligation backed by criminal penalties, and a violation could create reputational risk for the company.

Registration isn't limited to core systems. Firewalls, VPN appliances, authentication servers, physical keys, and more are broadly covered. You need an operation that catalogs all of these information assets in a register without omission and keeps it continuously up to date.

When multiple companies share responsibility for managing a system, getting the full picture becomes another challenge. For example, if Company A handles the customer management database and Company B handles the inventory management database, each may understand its own configuration while dependencies between systems fall through the cracks. To register assets accurately, both the provider and the contractors need to understand and manage the system as a whole, including these dependencies.

2. Detection and Analysis

The biggest change in the detection and analysis phase is when the reporting obligation begins. Under the Act, the obligation arises not when damage is confirmed or an investigation is complete, but at the moment an incident is recognized. This means an event may become reportable even before any actual damage has been confirmed.

Incident response starts with an alert. Next comes triage to determine whether it is an incident or simply a false positive. If at this point you recognize that an incident has likely occurred, full-scale incident response begins—and at the same time, the legal reporting obligation kicks in. However, with threats like ransomware, there may be no clear alert, and an intrusion may only be discovered months later through system slowdowns or suspicious traces. In that case, the reporting deadline starts counting from the moment the anomaly is recognized.

Until now, many organizations have defined procedures mainly around post-triage response and left the initial judgment to specific individuals. Going forward, it will be important to have a system that performs triage quickly and against consistent criteria, and records those decisions.

Special care is needed when the criteria for "recognition" differ between the provider and outsourced partners such as a SOC (Security Operation Center) or MDR (Managed Detection and Response) service. Even if the partner decides to wait and see, it is the provider that bears the reporting obligation, and delays in information sharing can lead to missed or late reports. This risk grows especially in large projects involving multiple companies. Contractors handling operations therefore need to align their recognition criteria with their customers, and to put in place—both contractually and operationally—mechanisms for quickly sharing important signs even before an investigation is complete.

3. Containment and Recovery

In the containment and recovery phase, you need to plan not only for your own company but also for cases where a business partner becomes a stepping stone for an attack. Even companies not directly regulated may, in the future, be required to report or otherwise respond if they could affect critical infrastructure providers through the supply chain.

4. Post-Incident Activity

How work gets done changes in post-incident activity, too. Reports must organize the incident overview, how it unfolded, affected equipment, system operating status, and technical information about the attack. Among these, the most labor-intensive to produce are the scope of impact and the timeline.

If information is scattered across Slack or Teams threads, personal notes, and tickets, you have to re-gather material for the report while still handling the incident. On the other hand, if you compile detection time, recognition time, decisions, actions, and scope of impact as you respond, you can produce the report simply by organizing those records.

These records aren't just for regulatory compliance. If you can search past decisions and procedures when a similar failure occurs, you can also speed up containment and recovery. In other words, a report isn't something you produce as a ritual after the response is over. It should be built from records kept during the response and turned into an asset you can use for the next response and for preventing recurrence.

‍

Top Priority: Take Inventory of Incident Records and Document Triage Criteria‍

All of these compliance measures are necessary, but putting everything in place at once isn't easy. Kanetsuki therefore narrows down the preparations companies should tackle first to the following two.

(1) Connect your asset register with your incident records
If past incident records survive only in fragments, start by taking inventory and organizing which incidents occurred on which information assets.

(2) Document the definition of "recognition" and the triage criteria
Build a system in which anyone can make judgments against consistent criteria, without relying on specific individuals.

After addressing these first, Kanetsuki recommends working on the following points over roughly the next year.

(3) Capture the response timeline naturally
When people try to keep records in the middle of a response, details such as when something was detected, when it was recognized, and what decisions were made tend to slip through the cracks, so automating as much as possible is important.

(4) Build regulatory reporting into your incident command structure and drills

(5) Design reporting flows with contractors and group companies, both contractually and operationally

Why Does Automating Incident Records Matter? Today, incident reports are often written in each company's or department's own format, with no clear standards for which items to include, the level of detail, or response speed. Going forward, however, reports must follow a government-prescribed format. Especially important are the "scope of impact" and the "timeline."

For scope of impact, you describe which of your registered critical assets are affected. For the timeline, you need to record who detected what and when, and what actions were taken. The time to report must also be calculated from the point of detection. For ransomware, reports are required within 3 to 5 days of detection; for DDoS attacks, as promptly as possible. And after submitting the initial report, a detailed report must be submitted within 30 days.

One thing to watch out for is response during weekends and extended holidays. For example, if an incident occurs late at night right before a long weekend and the response drags on or reporting is delayed, that alone could push you past the deadline. You need a setup where record-keeping never stops, even at night or during long holidays.

That said, knowing that you need to keep records and deal with regulators is one thing; actually doing it is another. Look at the front lines and you'll find a deep-rooted problem in incident response: dependence on specific individuals.

A survey conducted by SIGQ in 2026 found that 72% of incident response depends on specific individuals, and that 89% of organizations see the departure of key people as a business risk. Under these conditions, if records are left scattered across chats and personal notes, it's only natural that the record of who decided what and which actions were taken tends to get lost.‍

‍

Incident Lake: Making "Record While You Respond" Systematic

To solve these challenges, SIGQ offers the incident response platform "Incident Lake." Rather than replacing the monitoring tools teams already know, Incident Lake adds an "AI layer" on top of them, supporting incident response while making the most of existing workflows.

Specifically, AI agents integrate directly with chat tools such as Teams and Slack and automatically aggregate conversations related to incident response. They record detection and recognition times, subsequent decisions, and actions taken in chronological order, while AI organizes information scattered across chat and internal tools and summarizes the current situation. Integration with the configuration management database also helps identify the scope of impact. Dependencies between instances and systems are visualized as diagrams, so when a failure occurs you can quickly see how far the impact extends across your registered critical assets. AI also supports triage and responder assignment, which tend to depend on specific individuals. In addition to helping with severity assessments—where judgments often vary from person to person—it can analyze historical data accumulated in other monitoring tools to recommend responders with relevant experience, and surface similar incidents along with their resolutions.

For report creation, Incident Lake provides templates covering the mandatory items specified by the Cyber Response Capability Enhancement Act. AI agents organize the situation and draft the response plan and report, and humans review and approve the content—so teams can respond quickly even when the person in charge is on vacation or unavailable.

Verifiable Records Underpin Business Continuity and Trust

Kanetsuki concluded that responding to the Cyber Response Capability Enhancement Act shouldn't end at mere regulatory compliance; it should be an opportunity to eliminate dependence on individuals in incident response and strengthen the response capabilities of the organization as a whole.

Building a setup that naturally captures the process as verifiable records while you respond to incidents not only supports regulatory compliance, but also protects your business continuity and public trust, and raises security across the entire supply chain.

‍