Key takeaways

  • On October 7, 2026, Japan's privacy regulator, the Personal Information Protection Commission (PPC), issued a warning to companies that hold large volumes of personal data, after a run of large breaches caused by unauthorized access. It named no companies.
  • It previews revised security guidance, to be finalized next April, including phishing-resistant multi-factor authentication for remote and administrator access, EDR and log monitoring, and steps to stop attackers moving through a network.
  • It reminds companies that the law expects them to delete personal data they no longer need, and says failure to do so has made some breaches worse.
  • Its list of common breach patterns now includes abuse of APIs, where a logged-in attacker can pull other users' data by changing a parameter.

Why now#

The past few weeks in Japan have brought an unusual series of large breaches through unauthorized access, many of which we have covered: Times Car (6.6 million accounts), Yakiniku King (10.8 million app members), Seicomart, Sagawa Express, infoQ and others.

The PPC's warning does not name any of them. It says only that it has recently dealt with breaches in which businesses that handle large volumes of personal information and are widely used by the public were accessed from outside, and large amounts of personal data leaked or may have leaked.

Who the warning is for#

The PPC addresses the warning to all businesses that handle personal data, but "especially" to:

  • Businesses holding large volumes of personal data through services with a high market share in sectors used by most people, or services whose customers find it hard to choose the provider
  • Businesses holding sensitive personal data, data that could lead to financial harm, or data that could be used for fraud
  • Others whose breach would be likely to harm people's rights and interests

The second category in the first bullet is worth noting. Many people whose data leaks never chose the company that held it: the recipient of a parcel, for example, does not choose the delivery company. The PPC is signalling that companies in that position carry a particular responsibility.

What the regulator expects#

Required measures versus examples#

Japan's privacy law (the APPI) requires companies to take security control measures (Article 23). The PPC's guidelines describe them in two layers:

What it means
Measures that must be taken Not following them may be judged a violation of the law
Examples of methods Illustrations of how to meet the required measures. Not every example has to be adopted, and other methods can also be appropriate, in proportion to the risk

The warning is about the second layer. The PPC decided at a meeting on September 16 to revise the examples, which, according to its own meeting materials, have not changed much since 2016 and were written with perimeter security in mind. The revision is due to be finalized next April. Because of recent events, the PPC has published the planned technical examples now.

The new technical examples#

The preview covers five required technical measures. Highlights:

Required measure Examples now proposed
Access control Limit access to systems holding personal data, for example to pre-approved IP addresses. Minimize privileged accounts and where they can be used. Review access rights regularly. Evaluate each access request using context such as location, time and the security state of the device
Identification and authentication Multi-factor authentication, including phishing-resistant methods, for access from outside the organization's network, administrator access and access to important personal data. The same for non-employees who log in. Device authentication, such as certificates
Preventing unauthorized access Firewalls, security software and prompt patching of operating systems, middleware and applications. Block unapproved software. Allow access only from approved devices that meet security standards
Preventing leaks through system use Build security in at the design stage and keep reviewing it, including against attacks on vulnerabilities. Minimize real personal data in test data. Encrypt data in transit. Delete data from cloud services in ways that cannot be reversed, such as crypto-erasure
Detecting unauthorized access Keep authentication, access, operation and network logs, and protect them from tampering and deletion. Analyze them regularly. Use IDS/IPS or EDR for continuous monitoring. Isolate compromised systems and disable accounts to stop attacks spreading

The PPC's meeting materials say the revision aims to bring in zero trust thinking and measures against lateral movement after an intrusion, the pattern seen in ransomware attacks that reach deep into a network.

Delete what you no longer need#

The warning also restates Article 22 of the APPI: companies must make an effort to delete personal data without delay once it is no longer needed for its purpose, unless a law requires them to keep it. The PPC says it has seen cases where failing to do so made a breach more serious, and asks companies to check whether they still need the data they hold, and on what legal basis.

That is a recurring theme in our coverage. Times Car held data on former members and people who never completed sign-up. Dai-ichi Life held records on former staff going back to 1967. Osaka Metropolitan University held data on students back to 1995. Citizen's data sat on a system it was about to stop using.

The updated list of breach patterns#

Alongside the warning, the PPC revised its "WARNING" document, first published in December 2024, which sorts the breaches reported to it into common patterns. It now lists nine:

  1. Vulnerabilities left unpatched
  2. Vulnerabilities patched too late
  3. Unauthorized logins
  4. Attacks through group companies or overseas subsidiaries
  5. Weak access control between group companies
  6. Leaks of data saved in personal storage areas
  7. Inadequate supervision of group companies
  8. Leaks from a cloud service the company used
  9. API abuse (new)

The new ninth pattern describes a smartphone app or web service whose API let an attacker who had logged in change a parameter, such as a member ID in a URL, and retrieve other users' data. The causes listed: an API that was not being managed, sequential member IDs and unnecessary data in responses that made the API easy to work out, and no rate limit on requests. The suggested measures: keep an inventory of APIs, check authorization on every request as well as authentication, return only necessary data, use random IDs such as UUIDs, and limit request rates.

The cloud pattern describes a provider whose systems were breached, with many customers' personal data encrypted. The customers had not supervised the provider because they did not think using a cloud service counted as outsourcing the handling of personal data. The PPC says customers should check a service's terms and security assessment materials when choosing it, and that providers should publish security information. The IDCF Cloud ransomware attack this week is a similar situation on a much larger scale, though the PPC does not refer to it.

The PPC notes that if the measures behind these patterns are insufficient, a company may be judged to have breached its duties on security measures (Article 23), supervision of employees (Article 24) and supervision of contractors (Article 25).

Our analysis#

The regulator is catching up with the attacks#

The core of the guidance has been largely unchanged since 2016, and written for a world of office networks behind a firewall. The new examples, phishing-resistant MFA, EDR, protected logs, zero trust and containment of lateral movement, describe what security teams have been doing for years. That the PPC is putting them in writing now, and previewing them six months early, says as much about the pace of recent breaches as about the guidance itself.

Examples, not rules, but they will matter#

Formally, the new items are examples, not requirements. A company that does not adopt them is not automatically in breach. In our view, though, examples in PPC guidance tend to become the benchmark the regulator uses when it investigates a breach and decides whether a company's measures were adequate. A company that suffers a breach through an admin account without MFA, after this warning, will find it hard to argue that its measures were appropriate to the risk.

Many of the gaps sit with contractors#

Several patterns on the list, group companies and cloud services, and the WARNING document's references to contractors, point to the same problem we have seen repeatedly this month: data held or processed by someone else. In the i-ask breach, the gaps the vendor itself promised to fix were MFA for administrators and separation between clients. In the IDCF Cloud attack, 495 customers depended on one provider. The guidance places responsibility for supervising those arrangements on the company that holds the data.

What this means for readers#

  • If your company holds personal data of people in Japan, compare your current controls with the new examples now, rather than waiting for April. Priorities: phishing-resistant MFA for remote and admin access, protected logs and EDR, and an inventory of APIs.
  • Review what personal data you still need. Data on former customers, old members or past employees kept "just in case" is exactly what the PPC is now flagging.
  • If you use cloud services or contractors to handle personal data, treat them as part of your own security: check their controls and how your data is separated from other customers'.
  • If you have a breach, the APPI requires a preliminary report to the PPC promptly, and a final report within 30 days, or 60 days where the breach may have been caused with an improper purpose, such as unauthorized access.

Japanese terms at a glance#

Japanese Reading Meaning
個人情報保護委員会 Kojin Jōhō Hogo Iinkai Personal Information Protection Commission (PPC)
注意喚起 chūi kanki Warning, advisory
安全管理措置 anzen kanri sochi Security control measures (APPI Article 23)
講じなければならない措置 kōjinakereba naranai sochi Measures that must be taken
手法の例示 shuhō no reiji Examples of methods
フィッシングに耐性のある多要素認証 fisshingu ni taisei no aru tayōso ninshō Phishing-resistant multi-factor authentication
漏えい等報告 rōei-tō hōkoku Breach report to the PPC