[Offshore Development] “It doesn’t apply to us because it’s overseas” is actually the opposite. The impact of the Cyber Response Capabilities Enhancement Act extends beyond national borders.

The public-private partnership provisions of the so-called “Cyber Response Capability Enhancement Act” (official title: Act on the Prevention of Damage Caused by Unauthorized Acts Against Critical Computers), which was enacted in May 2025, will take effect in October 2026. The entities directly subject to these obligations are the “specified social infrastructure operators”—257 entities across 15 sectors of critical infrastructure designated under the Economic Security Promotion Act.Judging by the name alone, this law may seem far removed from the reality of offshore development sites that operate development teams in countries such as Vietnam and the Philippines.

However, if we carefully examine how this law works, we can see that its impact actually trickles down to the bottom of the outsourcing chain. While designated operators are required to “notify and report on their own systems,” who is actually developing and operating those systems?

It is not uncommon for the development of peripheral systems for critical infrastructure—such as finance, telecommunications, and power—to be outsourced to offshore locations through domestic system integrators. In this article, we will examine why this law is “surprisingly relevant to everyone” from the perspectives of both the clients and the contractors involved in offshore development.

Legal Update: Filing and Incident Reporting Will Become Mandatory

The Strengthening Act imposes two main obligations on designated specific social infrastructure operators. The first is to report system assets—such as vendor names and product information—to the government for those information systems related to core operations that qualify as “specified critical computers.”

Another requirement is the reporting of incidents involving cyberattacks. Failure to comply with the reporting obligation or to follow a corrective order issued by the regulatory authority is punishable by a fine of up to 2 million yen, while failure to comply with requests to submit documents or other materials is punishable by a fine of up to 300,000 yen.

Reporting is a two-step process. Upon becoming aware of an incident, a “Preliminary Report” must be issued promptly, followed by a “Detailed Report” within 30 days. The scope of reporting includes not only evidence of “specific unauthorized acts,” such as unauthorized access, but also related events—that is, the early warning stages.

Furthermore, in the case of SaaS and PaaS (related to middleware and operating systems), the system is designed such that “acknowledgment” is deemed to have occurred at the time the cloud service provider issues a notification.

What we would like to highlight here is the scope of the reporting requirements. The reporting requirements apply not only to specific critical facilities that support social systems but also to peripheral devices that, if subjected to a cyberattack, could lead to system shutdowns or performance degradation. Furthermore, experts have pointed out that, depending on the system configuration, equipment owned by third-party contractors responsible for operating the targeted devices may also fall under these requirements, and that the impact could indirectly extend to companies that do business with critical infrastructure operators.

Why Does It Spill Over into Offshore Development? Three Pathways

Path 1: "Your Company" is listed on the filing documents

The notification must include the vendor name and product information for the designated critical computer systems. In cases where a domestic system integrator (SIer) is contracted by a designated operator to develop a system, and the actual development work is carried out by offshore locations or overseas partner companies, the outsourcing structure itself may be subject to explanation to the government.

This is a natural extension of the prior review system under the Economic Security Promotion Act; within the framework of that Act, it had long been anticipated that cases involving the outsourcing of core system development by financial institutions to overseas offshore locations would be subject to strict scrutiny during the pre-implementation review. The enforcement of the Enhanced Act should be viewed as expanding this “transparency of outsourcing structures” not only to the implementation phase but also to the operational phase.

Path 2: The starting point of “Awareness” is the contractor

The incident reporting clock starts ticking from the moment an incident is “detected.” Furthermore, in a structure where the operation and maintenance of core systems are outsourced, it is often the case that the first to notice an anomaly is the contractor—that is, the offshore operations team.

An alert detected late at night in Vietnam may be classified as “wait and see” based on the local team’s judgment, and reporting to the Japanese side may be deferred until the next business day’s regular meeting. In other words, this operational practice—which would have been acceptable under normal circumstances—will directly jeopardize the client’s statutory reporting deadline once the new regulations take effect.Time differences, language barriers, and discrepancies in the criteria for determining whether an incident “should be reported”—the communication frictions inherent in offshore development are directly transformed into compliance risks.

Path 3: Risk of Being Excluded from Selection

In recent years, there has been an increase in “supply chain attacks” that use business partners with relatively weak cybersecurity defenses as a stepping stone to target large corporations, and it has been noted that small and medium-sized vendors and service providers are increasingly becoming targets.

Given this premise, it is a natural consequence that designated operators and their primary contractors would exclude offshore vendors that cannot explain their incident notification systems from the selection process. This is precisely the scenario that Nikkei CrossTech reported as the “risk of being excluded from business partnerships.”

Key Issues Unique to Offshore Operations: “Notification Channels” and the Extent of Subcontracting

Just as the depth of the outsourcing structure is a critical issue for financial institutions and credit card companies, the critical issue with offshore development is that this structure spans national borders and languages. Here are the specific points that should be examined.

• Contract Notification Provisions

  Do the outsourcing agreement and SLA specify the obligation to notify when a security incident or its precursors are detected, the notification deadline (specified in hours rather than as “promptly”), the recipients of the notification, and the language of the notification? In the case of a lab-based contract where a test environment or operational devices are located on-site, are incidents occurring on those devices also included in the notification requirements? If there is subcontracting, do equivalent provisions extend to the subcontractors?

• Escalation Design That Accounts for Time Zones

  The “timeline from detection to initial report” operates under Japan’s system. Who is responsible for reporting incidents detected locally at night or on holidays, and within how many hours must they be reported to which contact point in Japan? Are the notification recipients still listed as retired employees’ email addresses or shared addresses that never receive replies? It may seem like a minor detail, but this is effectively what determines whether reporting obligations can be fulfilled.

• Language Gaps in Reporting Formats

  Starting in October 2025, the use of a standardized reporting format for DDoS attacks and ransomware will begin on a pilot basis, and plans are in place to centralize the reporting system.

  Naturally, the form is in Japanese. It is necessary to designate, in advance and during normal operations, the person responsible for accurately converting the local team’s English incident reports into the Japanese form by the deadline. It has long been pointed out in security practice that even regarding definitions as basic as “confidential information” and “incident,” there can be differences in understanding between Japan and overseas.

Another Critical Point: “Point of Responsibility” and “Scope of Impact” in a Multi-Client Architecture

Let’s take a closer look at the reality of offshore development companies. Many offshore development companies handle projects for multiple clients simultaneously.

Even in a lab-style environment where dedicated teams are assigned to specific projects, it is not uncommon for resources—such as office infrastructure, networks, authentication infrastructure, CI/CD environments, and internal information systems—to be shared across projects. This structure has two weaknesses that become apparent in the era of the Enhanced Security Act.

The first issue is whether we can immediately identify our scope of responsibility when something happens on the client’s side. When an incident is detected in a client’s system, the first questions the client typically asks are, “What exactly is the scope of your work and access privileges?” and “Is it possible that the issue originated in your environment?”

Unless the scope of work specified in the contract, the access rights actually granted, and a list of the environments that local team members have access to are organized on a project-by-project basis, it will take several days just to “look into” the matter. However, as mentioned earlier, the clock is already ticking for the client’s urgent report. The longer time passes while the boundaries of responsibility remain unclear, the more suspicion will fall on the contractor; even if the contractor wasn’t at fault, the sole fact that they “couldn’t explain” the situation will remain.

The second issue is the reverse scenario: when an incident originating within the company occurs, can we immediately determine the full scope of its impact? If an in-house development device is infected with malware, a shared authentication infrastructure is compromised, or a former employee’s account remains active, and we cannot answer the question, “Which systems at which clients could be accessed from that device, account, or environment?” then the scope of impact will logically be “all clients.”

Even if a project was actually closed out as a single case, without a project-by-project mapping of assets and access paths, it would be impossible to prove this, potentially leading to a situation where notifications must be sent to all clients and the statutory reporting processes for each of the multiple clients must be initiated simultaneously.

In both cases, the routine procedures are the same. For each project, maintain a register listing the assigned team members, leased or brought-in equipment, access permissions, and shared infrastructure, and update it whenever changes occur. It’s easier to understand if you think of this as a scaled-down version of the “inventory and reporting of specified critical computers” required of designated operators under the Security Enhancement Act—one that the contractor also maintains on a project-by-project basis. When the client requests information for reporting purposes, this register serves as the direct response.

Pre-Implementation Checklists for the Client and Contractor

The first step for clients (domestic system integrators and operating companies) is to conduct a project inventory. When tracing the clients behind the projects their company is handling, which ones ultimately lead back to specific social infrastructure operators? Among those projects, to what extent are they being outsourced offshore?

For the case in question, we will compare the contract’s notification clauses with the actual escalation procedures and bridge any gaps. After that, we should conduct at least one drill in which the Japanese team’s decision-making process is triggered by an incident or infringement notification from the local team. When we conduct such a drill, we are sure to uncover specific shortcomings, such as the lack of a notification template, the fact that translation takes three hours, or the inability to reach the decision-maker in Japan late at night.

For service providers (offshore development companies), this law is both a threat and an opportunity for differentiation.A system that documents the workflow from incident detection to notification of the Japanese client and commits to a notification SLA in the contract will be a clear competitive asset in the Japanese market after the law takes effect. Conversely, vendors unable to demonstrate this capability will be eliminated from consideration before the competition even comes down to unit prices or skill levels. We are already seeing a trend where security-conscious outsourcing providers are focusing on countermeasures and training to secure projects in Japan, Europe, and the U.S., and the Enhanced Security Law is likely to accelerate this selection process from an institutional perspective.

One common challenge is the centralization of records. In addition to preliminary and detailed reports under the Strengthening Act, the number of reporting destinations continues to grow—including reports to the Personal Information Protection Commission, reports to regulatory authorities via the client, and contractual notifications to customers. Whether or not there is a system in place to retain on-site team chat logs, detection times, and the chronology of responses in a format that allows “a single entry to be used across all reports” can make an order-of-magnitude difference in the workload during an incident.

And so, Incident Lake

As we have seen so far, the key challenges in incident response involving offshore development lie in the speed of the process—from detection to reporting—across national borders and languages, as well as the ability to immediately distinguish between “scope of responsibility” and “scope of impact” within a structure that serves multiple clients.

We take anomalies detected on-site, incorporate them into the reporting and decision-making process in Japan despite the time difference, identify which projects and clients are affected, and compile them into timely preliminary and detailed reports without any inconsistencies. To be honest, there are limits to managing this entire process relying solely on manual labor and back-and-forth chat messages.

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 both on-site and in Japan to focus their time on what truly matters: “stopping the damage and restoring service.”

Now that the time-sensitive reporting system—comprising “flash reports” and “detailed reports”—is being implemented, I recommend shifting the mechanisms for cross-border reporting and record-keeping to a system that does not rely on individual effort.

Please note that some details of the law will be finalized through cabinet orders, ministerial ordinances, and operational guidelines prior to its enforcement. For the latest information, please refer to the materials published by the Cabinet Office (Cyber Security and Economic Security Divisions) and the relevant regulatory agencies.

Reference Materials

• Cabinet Office: “System for Ensuring the Stable Provision of Critical Infrastructure Services” https://www.cao.go.jp/keizai_anzen_hosho/suishinhou/infra/infra.html

• Director-General for Policy Coordination, Cabinet Office (in charge of Cybersecurity): “Draft Guidelines for the Enforcement of the Act on Strengthening Cyber Response Capabilities (Public-Private Partnership)” (December Reiwa 7) https://www.cao.go.jp/cybersecurity/kaigi/pdf/04shiryo05.pdf

• Nikkei CrossTech: “Cyber Response Capability Enhancement Act to Take Effect in October; Risk of Being Excluded by Business Partners” (2026) https://xtech.nikkei.com/atcl/nxt/column/18/00989/042300207/

• The Nikkei: “Cyber Response Capability Enhancement Act to Take Effect in October; New Obligations for Companies Involved in Social Infrastructure” (May 2026) https://www.nikkei.com/article/DGXZQOUC071KC0X00C26A5000000/

• PwC Japan Group: “Reviewing Offshore Operations in Light of Economic Security and Geopolitical Risks: Part 1” https://www.pwc.com/jp/ja/knowledge/column/offshore-base-reconsideration/01.html

• GMO Internet Group: “What Is the Cyber Response Capability Enhancement Act? An Explanation of Its Four Pillars and the Measures Companies Should Take” https://group.gmo/security/security-all/information-security/blog/cyber-response-capability-enhancement-act/