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 15 critical infrastructure sectors include "finance" and "credit cards" as separate sectors, and designated providers will be legally required to register their system assets and report cyber incidents to the government.
That said, the way this law "bites" differs between megabanks and major card companies on the one hand, and regional banks and shinkin banks (cooperative regional banks) on the other. Because only providers that meet size thresholds are designated, many regional financial institutions are not expected to be directly designated.
Does that mean regional banks and shinkin banks are unaffected? Not at all. The "Guidelines for Cybersecurity in the Financial Sector," issued by the Financial Services Agency (FSA) in October 2024, cover a wide range of financial institutions, including regional ones, and the substance of the incident response they require points in the same direction regardless of designation. In this article, we sort out what is mandatory and what should be prepared from the respective standpoints of credit card companies and regional financial institutions.
What the Law Makes Mandatory: Registration and Incident Reporting
The Act directly covers specified social infrastructure providers (critical infrastructure providers) designated under the Economic Security Promotion Act; as of April 1, 2026, a total of 257 providers across all sectors had been designated. Finance and credit cards have both been covered sectors since the system's launch. The FSA published its designation of specified social infrastructure providers in the financial sector on November 17, 2023, and has continued to add designations since. Whether your institution is designated can be confirmed in FSA and METI public notices.
The Act imposes the following obligations on designated providers: registering with the government vendor names, product information, and other details for those information systems involved in core operations that qualify as "specified critical computers"; and filing incident reports when they suffer a cyberattack.
As for the reporting framework, the draft approach to enforcement presented to the Cabinet Office's expert panel sets out two stages. Once an incident is recognized, an "initial report" is filed promptly, followed by a "detailed report" within 30 days. In both cases, you only need to report what is known at that point; a perfect root-cause analysis is not required at the initial stage. Reportable events include not only traces of "specified unauthorized acts" such as unauthorized access, but also events that could lead to them. The design means the reporting obligation kicks in from the warning-sign stage.
The treatment of cloud usage has also been clarified. For SaaS and PaaS (covering middleware and operating systems), "recognition" is deemed to occur at the moment the cloud provider sends notification. As for penalties, 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.
Particularly important for the financial industry is the spillover to non-designated businesses and entities. It has been pointed out that IT vendors and group companies contracted to operate specified critical computers—and, depending on system architecture, equipment owned by contractors—may also be covered. Among regional financial institutions, where the dominant model is to entrust core banking systems to shared data centers and rely on external vendors' services for internet banking and payment processing, and in the card industry, where processing work is outsourced and subcontracted through many layers, relationships such as "we're not designated, but we run on the same system as a designated provider" or "we're a contractor to a designated provider" are actually the norm.
Regional Financial Institutions: The FSA Guidelines Are the De Facto Standard
For regional banks and shinkin banks, the practical centerpiece is, first and foremost, not the Act but the FSA's "Guidelines for Cybersecurity in the Financial Sector," issued on October 4, 2024. Their scope is broad—from major banks to small and regional financial institutions, insurers, funds transfer service providers, and crypto-asset exchanges—and they make concrete the cybersecurity management points that the supervisory guidelines had previously described only in principle.
The guidelines are written in two tiers: "basic measures" that all financial institutions should implement, and "desirable measures" recommended in light of size, characteristics, and so on. This allows regional financial institutions to design their level of response according to their own size. From an incident response perspective, the key points are as follows.
- Management responsibility is explicitly stated
Addressing cybersecurity risk is positioned as management's job. The guidelines call for resource allocation such as assigning specialized personnel and budget, and for establishing cross-organizational reporting, communication, and consultation routes and chains of command—including for risks arising from third parties. They also build in mechanisms for continuous management, such as reviewing policies and rules at least once a year and tracking status through KPIs and KRIs. - Establishing a crisis management structure
Institutions are required to establish reporting and public relations structures for when they suffer a cyberattack, and to set up emergency response teams such as an internal CSIRT. Contingency plans are recommended to include recovery plans and to be developed for each attack type, such as website defacement and malware infection, with the FISC (The Center for Financial Industry Information Systems) handbook cited as a reference. - Continuity with existing regulatory reporting
Financial institutions already have practices for reporting system failures and similar events to regulators under the supervisory guidelines. The FSA also conducts a Cyber Security Self-Assessment (CSSA) for regional financial institutions, so the materials for benchmarking your own measures against industry standards are already in place. For designated providers, the Act's initial and detailed reports are a new layer on top of these reporting practices. Even for non-designated institutions, it is best to assume that the same yardstick—"speed from recognition to report"—will become the industry standard.
Between late 2024 and early 2025, a series of DDoS attacks targeted domestic financial institutions and airlines, with temporary internet banking outages reported. Even attacks that don't involve intrusion can bring down customer-facing services and trigger regulatory reporting and customer communications. Rather than "acting once evidence of a breach appears," you need a structure in which reporting and PR workflows start running the moment service impact occurs.
Credit Cards: Incident Response That Overlaps with Fraud Prevention
The card industry has accumulated its own body of regulation well before the Act. Article 35-16 of the Installment Sales Act requires businesses handling credit card numbers and related data to take the measures necessary to properly manage card numbers (appropriate number management measures), and the 2021 amendment expanded coverage to seven types of businesses, including QR code payment providers. The practical guidance for this obligation is the "Credit Card Security Guidelines" from the Credit Transaction Security Council, revised to version 6.0 in March 2025.
Behind this is the growing severity of losses. Credit card fraud losses hit a record 55.5 billion yen in 2024, and more than 90% of that came from "number theft"—the use of card data stolen through leaks or phishing. The guidelines promote vulnerability countermeasures for e-commerce merchants and adoption of EMV 3-D Secure, and card companies and PSPs are expected to advise and share information with merchants.
Reference: https://www.j-credit.or.jp/customer/5countermeasures-creditcard_fraud/
What sets card companies' incident response apart from other industries is that it becomes a two-front battle: "restoring systems" and "containing fraudulent use." If card data leaks at a merchant or PSP, even with your own systems unscathed, a whole set of responses kicks off at once: stepped-up fraud monitoring, notifying affected cardholders, reissuing cards, and coordinating with merchants and card brands. Reports under the Act are expected to center on attacks against core systems handling authorization and payment processing, but for frontline incident response, you need to design workflows on the assumption that statutory reporting, Installment Sales Act obligations, reporting under card brand rules, and cardholder communications will all run in parallel.
Finance-Specific Issues: Outsourcing Structures and Designing "Recognition"
A weak spot shared by finance and credit cards is the depth of system outsourcing structures. Shared data centers, core banking vendors, payment networks, cloud SaaS—incidents that happen outside your own walls lead directly to your own service outages or data leaks.
The fact that the Act's draft approach deems the moment of notification from a cloud provider to be "recognition" carries real weight. Designing the "notification intake"—who receives failure or breach notifications from vendors and shared data centers, through which contact point, and within how many hours they are put onto the reporting decision line—effectively determines whether you can meet your reporting obligations. Do your outsourcing contracts and SLAs include notification clauses? Is the notification address still set to a former employee's email? It may be unglamorous, but this is the first thing to check.
For information sharing, industry mechanisms such as the Financials ISAC Japan and CEPTOAR have long been in place. After the Act takes effect, statutory reporting to the government and information sharing within the industry will run side by side, so sorting out in normal times which information goes where and on whose judgment will reduce confusion during a crisis.
What to Do Before Enforcement
First, check public notices to confirm whether your institution is designated as a specified social infrastructure provider. If it is, your immediate priorities are taking inventory of specified critical computers that may be subject to registration, and establishing reporting workflows so you can file initial and detailed reports on time. If you have an equipment list prepared for pre-screening under the Economic Security Promotion Act, you can use it as a starting point.
Even if you're not designated, what needs to be done hardly changes. Identify gaps between the FSA guidelines' "basic measures" and your organization's current state, and put in place a CSIRT, contingency plans, and reporting and PR structures. Run a drill, at least once, in which you act on a notification from a shared data center or vendor. If you're a card issuer, map multiple reporting destinations—the Installment Sales Act, the Act on the Protection of Personal Information, card brand rules, and (if applicable) the Cyber Response Capability Enhancement Act—onto a single response flow for a scenario in which leak response and fraud response run simultaneously. The more reporting regimes there are, the more value you get from centralized records where "you record once and reuse it for every regime's report."
Finally, there's management involvement. As the FSA guidelines explicitly make cybersecurity a management responsibility, approving the incident response plan and participating in drills are the job of senior management, not the IT department. Before a deadline-bound reporting regime of initial and detailed reports gets underway, it's worth confirming that positioning as an organization.
Some details of the law are still being worked out through cabinet orders, ministerial ordinances, and operational rules ahead of enforcement, and items described as "draft" in this article may change. For the latest information, please refer to materials published by the Cabinet Office (Cyber Security and Economic Security divisions), the FSA, and METI.
Enter Incident Lake

As we've seen, incident response in finance and credit cards is a world defined by the sheer number of reporting destinations: reports to supervisory authorities, the Act's initial and detailed reports, reports to the Personal Information Protection Commission, communications with card brands and industry bodies, and notices to customers and cardholders. Continuing to issue all of these on time and consistently—while stopping fraud and restoring service on the front lines—has its limits when done by hand alone.
Incident Lake is an incident management platform that supports this entire 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 protecting customers. Now, as deadline-bound reporting such as initial and detailed reports becomes institutionalized, we recommend transforming your reporting and record-keeping into a system that doesn't depend on individual heroics.
References
- Financial Services Agency, "Guidelines for Cybersecurity in the Financial Sector" (October 4, 2024) https://www.fsa.go.jp/news/r6/sonota/20241004/18.pdf
- Financial Services Agency, "Cybersecurity Measures in the Financial Sector" https://www.fsa.go.jp/policy/cybersecurity/index.html
- Financial Services Agency, "Economic Security Measures in the Financial Sector" (public notice of designation of specified social infrastructure providers) https://www.fsa.go.jp/news/r5/economicsecurity/231117infrastructure.html
- METI, "The 'Credit Card Security Guidelines' Have Been Revised" (version 6.0, March 2025) https://www.meti.go.jp/press/2024/03/20250305002/20250305002.html
- METI, "The State of Credit Card Fraud Losses" (materials from the 1st meeting of the Study Group on Fraud Countermeasures at Merchants, April 2025) https://www.meti.go.jp/shingikai/mono_info_service/measures_against_fraud/pdf/001_01_04.pdf
- 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/
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.
![[Credit Card Companies and Regional Financial Institutions] How Incident Response Changes Under the Cyber Response Capability Enhancement Act](https://cdn.prod.website-files.com/6ab8637ce5d9f171240fb21c/6ab8f9e03e941cb4dd568fd2_s-2816x1536_v-frms_webp_220e947e-218b-4728-a2f8-5b353d745c35_small.webp)