[Offshore Development] "It's Overseas, So It Doesn't Apply to Us" Has It Backwards: The Cyber Response Capability Enhancement Act Reaches Across Borders

Author: Takaaki Kanetsuki, Representative Director, President & CEO

The public-private collaboration provisions of Japan's so-called "Cyber Response Capability Enhancement Act" (formally, the Act on the Prevention of Damage Caused by Unauthorized Acts Against Critical Computers), enacted in May 2025, take effect in October 2026. The parties directly bound by the law are the 257 "specified social infrastructure providers" across 15 critical infrastructure sectors designated under the Economic Security Promotion Act. Judging by the name alone, it might seem like a law with little relevance to offshore development teams running in Vietnam or the Philippines.

But trace how the law actually works and you'll find its impact flows toward the far end of the outsourcing chain. Designated providers are required to "register and report on their own systems"—but who actually builds and operates those systems?

It's not unusual for development of systems surrounding critical infrastructure in finance, telecommunications, and power to flow through domestic system integrators (SIers) to offshore delivery centers. In this article, we look at the law from the perspectives of both the client and the vendor in offshore development, and explain why it is "more your problem than you think."

A Refresher on the Law: Registration and Incident Reporting Become Mandatory

The Act imposes two major obligations on designated specified social infrastructure providers. The first is to register with the government their system assets—vendor names, product information, and so on—for those information systems involved in core operations that qualify as "specified critical computers."

The second is incident reporting when they suffer a cyberattack. Failing to comply with a supervising authority's corrective order after violating the registration obligation carries a fine of up to 2 million yen, and failing to respond to requests such as submitting documents carries a fine of up to 300,000 yen.

Reporting happens in two stages. Once an incident is recognized, an "initial report" must be filed promptly, followed by a "detailed report" within 30 days. Reportable events include not only traces of "specified unauthorized acts" such as unauthorized access, but also events that could lead to them—in other words, the warning-sign stage as well.

In addition, for SaaS and PaaS (covering middleware and operating systems), the law is designed so that "recognition" is deemed to occur at the moment the cloud provider sends notification.

What deserves attention here is the scope of registration. It covers not only the specified critical equipment that supports social systems, but also peripheral equipment whose compromise by a cyberattack could lead to equipment shutdown or degraded functionality. Experts have pointed out that, depending on the system architecture, equipment owned by contractors that operate the covered equipment may also qualify, and that the law could indirectly affect companies doing business with critical infrastructure providers.

Why It Spills Over to Offshore Development: Three Pathways

Pathway 1: "Your Company" Appears in the Registration Documents

Registration includes the vendor names and product information for specified critical computers. When a domestic SIer wins a designated provider's system development contract and the actual development work is carried out by an offshore center or an overseas partner, the outsourcing structure itself may become something that has to be explained to the government.

This is a direct continuation of the pre-screening system under the Economic Security Promotion Act. Under that framework, it has long been expected that cases like outsourcing a financial institution's core system development to an overseas offshore center would face rigorous scrutiny in pre-deployment review. The enforcement of the new Act should be seen as extending this "visibility into outsourcing structures" beyond deployment and into the operational phase.

Pathway 2: The Starting Point of "Recognition" Becomes the Contractor

The incident reporting clock starts ticking at "recognition." And in setups where the operation or maintenance of core systems is outsourced, the first to notice an anomaly is often the contractor—that is, the offshore operations team.

An alert detected in the middle of the night in Vietnam gets put on "wait and see" at the local team's discretion, and the report to Japan is held over until the next business day's regular meeting. This kind of practice, tolerated in normal times, will directly threaten the client's statutory reporting deadline once the law takes effect. Time differences, language, and mismatched criteria for "is this something we should report?"—the communication friction inherent in offshore development converts directly into compliance risk.

Pathway 3: The Risk of Being Dropped from Vendor Selection

In recent years, "supply chain attacks"—which target large enterprises by using business partners with relatively weak cyber defenses as a stepping stone—have been increasing, and small and mid-sized vendors and service providers are increasingly being targeted.

Given this, it is a natural consequence that designated providers and their prime contractors will start dropping offshore vendors that cannot explain their incident notification processes. This is exactly the dynamic Nikkei xTECH described when it reported on the "risk of being excluded by business partners."

The Offshore-Specific Weak Spots: The "Notification Intake" and the Depth of Subcontracting

Just as the weak spot for financial institutions and card companies is the depth of their outsourcing structure, the weak spot in offshore development is that this structure crosses national borders and languages. Here are the specific points to check.

• Notification clauses in contracts
  Do your outsourcing contracts and SLAs specify the obligation to notify upon detecting a security incident or its warning signs, the notification deadline (in hours, not "promptly"), the recipient, and the language of notification? Under lab-style (dedicated team) contracts with test environments or operational terminals located on-site, are events on that equipment also covered by the notification requirement? Where there is subcontracting, do equivalent clauses flow all the way down to the subcontractors?
• Escalation design that accounts for time differences
  The clock from "recognition to initial report" runs on Japanese rules. For events detected during local nights or holidays, who delivers them, within how many hours, to which contact point in Japan? Is the notification address still set to a former employee's email or a shared inbox nobody replies from? It may be unglamorous, but this is effectively where your ability to meet reporting obligations is decided.
• The language gap in reporting formats
  Since October 2025, a unified reporting format for DDoS attacks and ransomware has been in use ahead of full enforcement, and consolidation of the report intake system is also planned.
  
  Naturally, the format is in Japanese. You need to decide, in normal times, who is responsible for accurately converting the local team's English incident reports into the Japanese format within the deadline. Security practitioners have long noted that perception gaps arise between Japan and other countries over even basic definitions like "confidential information" or "incident."

Another Weak Spot: "Responsibility Boundaries" and "Blast Radius" in Multi-Client Structures

Let's take one more step into the reality of offshore development firms. Many of them run projects for multiple clients in parallel.

Even when dedicated lab-style teams are separated, many layers—offices, networks, authentication infrastructure, CI/CD environments, internal IT systems—are often shared across projects. This structure has two weaknesses that come to the surface in the era of the new Act.

The first is whether you can immediately state the scope of your responsibility when something happens on the client side. When an incident is detected in a client's system, the first questions the client will fire at you are "What exactly is your scope of work and access?" and "Could your environment be the cause?"

If the contractual scope of work, the access rights actually granted, and the list of environments local members can touch aren't organized per project, it will take days to get from "we'll look into it" to an answer. But as noted above, the client's initial-report clock is already running. The longer responsibility boundaries remain unclear, the more suspicion shifts toward the contractor—and even if you weren't the cause, the fact that you "couldn't explain" is what people remember.

The second runs in the opposite direction: whether you can immediately identify which projects are affected when an incident originates on your side. If an internal development machine is infected with malware, a shared authentication system is compromised, or a former employee's account was left active, and you can't answer "which systems of which clients could be reached from that machine, account, or environment?", then the blast radius is logically "all clients."

Even if the incident was actually contained to a single project, without a per-project map of assets and access paths you can't prove it—and you may end up notifying every client while simultaneously running the statutory reporting flows of multiple clients.

In both cases, the work to do in normal times is the same: for each project, maintain a register of assigned members, loaned and personally brought devices, access rights, and shared infrastructure, and update it with every change. Think of it as the vendor keeping, per project, a miniature version of the "inventory and registration of specified critical computers" that the Act requires of designated providers. When a client asks you for information for their registration, this register becomes your answer as-is.

Pre-Enforcement Checklists for Clients and Vendors

For clients (domestic SIers and operating companies), the first step is a project inventory. When you trace the clients behind the projects you've taken on, which ones lead back to a specified social infrastructure provider? And within those projects, how much of the scope has been sent offshore?

For the relevant projects, compare the contractual notification clauses with the actual escalation paths and close the gaps. Then run a drill—even just once—in which a failure or breach notification from the local team triggers the reporting decision process on the Japan side. Drills always surface concrete gaps: there's no notification template, translation takes three hours, the decision-maker in Japan can't be reached late at night.

For vendors (offshore development firms), this law is both a threat and an opportunity to differentiate. A documented flow from incident detection to notification of the Japan side, backed by a contractual commitment to a notification SLA, will be a clear sales asset in the Japanese market after enforcement. Conversely, vendors that can't explain this will be dropped from consideration before price or skills even come into play. Security-conscious contractors are already investing in countermeasures and training to win projects from Japan, Europe, and the US, and the Act will institutionally accelerate this sorting process.

What matters for both sides is centralized record-keeping. In addition to the Act's initial and detailed reports, there are reports to the Personal Information Protection Commission, reports to supervisory authorities via the client, and contractual customer notifications—the list of recipients keeps growing. Whether you have a system that captures the local team's chat logs, detection times, and response timeline in a form where "you record it once and reuse it for every report" makes an order-of-magnitude difference in the burden during a crisis.

Enter Incident Lake

As we've seen, the hardest parts of incident response involving offshore development are the speed of getting "from recognition to report" across borders and languages, and the ability to quickly separate "scope of responsibility and blast radius" within a structure serving multiple clients.

Taking an anomaly detected on-site, carrying it across time zones into the Japan side's reporting decision, identifying which projects and clients are affected, and rolling it out consistently into deadline-bound initial and detailed reports—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 team members both on-site and in Japan can spend their time on what they should really be focused on: stopping the damage and restoring service.

Now, as a deadline-bound reporting regime of initial and detailed reports gets underway, we recommend transforming your cross-border reporting and record-keeping into a system that doesn't depend on individual heroics.

Note that some details of the law are still being worked out through cabinet orders, ministerial ordinances, and operational rules ahead of enforcement. For the latest information, please refer to materials published by the Cabinet Office (Cyber Security and Economic Security divisions) and the relevant supervisory authorities.

References

• Cabinet Office, "System for Ensuring the Stable Provision of Critical Infrastructure Services" https://www.cao.go.jp/keizai_anzen_hosho/suishinhou/infra/infra.html
• Cabinet Office, Director-General for Policy Planning (Cyber Security), "Draft Approach Toward Enforcement of the Cyber Response Capability Enhancement Act (Public-Private Collaboration)" (December 2025) https://www.cao.go.jp/cybersecurity/kaigi/pdf/04shiryo05.pdf
• Nikkei xTECH, "Cyber Response Capability Enhancement Act Takes Effect in October, With a Risk of Exclusion by Business Partners" (2026) https://xtech.nikkei.com/atcl/nxt/column/18/00989/042300207/
• Nikkei, "Cyber Response Capability Enhancement Act Takes Effect in October, Imposing New Obligations on Social Infrastructure Companies" (May 2026) https://www.nikkei.com/article/DGXZQOUC071KC0X00C26A5000000/
• PwC Japan Group, "Reconsidering Offshore Bases in Light of Economic Security and Geopolitical Risk, 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? Its Four Pillars and the Measures Companies Should Prepare" https://group.gmo/security/security-all/information-security/blog/cyber-response-capability-enhancement-act/

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.