TCL Portal

Ransomware and Data Breach Reporting Under Japan's APPI

By: Sekiko Jo (pen name, TCL Security Editorial Desk) Published:
  • #Ransomware
  • #APPI
  • #Data Breach
  • #Japan
  • #Compliance

Part of our guide to Japan’s cybersecurity laws. For a full side-by-side of the two frameworks, see APPI vs GDPR: Comparing Japan’s and the EU’s Data Protection Laws.

A ransomware attack lands on your network, and the incident response playbook that kicks in probably has a line item for “regulatory notification.” In the EU, that line item has a number attached to it: 72 hours. In Japan, teams running an APPI compliance program often assume something similar exists, and get the shape of the obligation wrong in both directions — either assuming ransomware always means a mandatory report, or assuming that without confirmed data exfiltration there is nothing to report at all. Neither assumption is safe.

This piece walks through what actually triggers a mandatory report under Japan’s Act on the Protection of Personal Information (APPI), why encryption-only ransomware is not automatically exempt, what the reporting timeline looks like, and how it lines up against GDPR’s more familiar 72-hour rule.

Does a Ransomware Attack Always Trigger an APPI Breach Report?

No. APPI’s breach notification duty is not triggered by the word “ransomware” appearing in an incident timeline. It is triggered by specific thresholds under Article 26 and its accompanying Personal Information Protection Commission (PPC / 個人情報保護委員会) rules. A report to the PPC and to affected individuals is mandatory when any of the following applies:

These four triggers were made legally mandatory by the amended APPI, which took effect in April 2022; before that, PPC reporting and individual notification were only recommended best practice (RadarFirst, What You Need to Know About Japan’s Amended APPI Law).

In practice, that fourth bullet and the cyberattack bullet mean most ransomware incidents that touch any meaningful volume of personal data end up in reporting territory — but the mechanism is these enumerated triggers, not the presence of ransomware as such. A ransomware incident confined to a system holding no personal information, or affecting a handful of records with no sensitive categories and no attacker-driven intent established, may fall outside the mandatory thresholds. Incident response teams should map the affected systems to these four triggers explicitly, rather than treating “we had a ransomware event” as self-evidently reportable or self-evidently not.

The PPC’s Reporting Thresholds: What Counts as ‘Leaked’ Personal Data

The PPC’s thresholds turn on the nature and scale of what was exposed, not on public visibility of the data. “Leaked” in this context covers unauthorized acquisition, loss, or disclosure of personal information — it does not require proof that the data has surfaced on a forum or been used against a data subject. This matters for ransomware specifically, because a business can meet a reporting trigger even if there is no external evidence yet that the stolen or exposed data has been misused.

The sensitive-information and property-damage thresholds are the more mechanical of the four to evaluate: does the affected data set include health records, criminal history, or other 要配慮個人情報 categories, and could exposure plausibly lead to financial or physical harm. The 1,000-subject threshold is a straightforward count. The improper-purpose trigger is the one that requires the most judgment in a ransomware case, and it is the one addressed directly in the next section.

Ransomware Encryption vs. Exfiltration: Why the Distinction Changes Your Obligation

This is the distinction that trips up teams building their incident response runbook from a GDPR-first mental model. Under GDPR, the core question is usually framed around whether personal data was accessed or disclosed to an unauthorized party — encryption-only ransomware, where an attacker locks files but does not exfiltrate them, has sometimes been treated by EU practitioners as a lower-severity event because confidentiality wasn’t necessarily breached, even though availability was.

Under APPI, the improper-purpose trigger is oriented around the nature of the attack — a ransomware incident is treated as reportable because it reflects a likely improper act, largely independent of whether the business can affirmatively confirm data was copied out. Modern ransomware operations compound this: double-extortion tactics, where an attacker exfiltrates data before encrypting it and threatens publication as separate leverage from the encryption itself, have become standard tradecraft rather than an edge case. That means a forensic finding of “no confirmed exfiltration” describes what the evidence shows, not what happened. Logging gaps, short retention windows, and encrypted or tunneled exfiltration channels are common reasons investigators cannot rule out data access even when they cannot prove it.

The practical consequence for a compliance team: do not treat “encryption only, no confirmed exfiltration” as a basis for skipping the APPI report. Treat it as the starting hypothesis for your forensic investigation, and let the improper-purpose trigger — the cyberattack itself — drive the reporting decision unless the investigation affirmatively establishes that no personal information was accessed.

Timeline: What You Must Report and By When Under APPI

APPI’s reporting timeline runs in two stages rather than GDPR’s single fixed window:

  1. Preliminary report — PPC guidelines interpret this as due promptly after the business becomes aware of the breach, which is generally read in practice as roughly three to five business days. This report can be filed with incomplete facts; it establishes that the business is aware of and responding to the incident.
  2. Full report — due within 30 days of recognizing the breach in the general case, extended to 60 days when the cause is a likely improper act, such as a cyberattack — the category that covers most ransomware incidents (Mori Hamada & Matsumoto, Cyber Incident Response and Data Breach Notification).

Both the PPC and the affected data subjects must be notified; individual notification can, in defined circumstances, be substituted with public disclosure where individual notice would be difficult and substitute measures are taken to protect the affected individuals’ interests. Recognition of the breach — the date the notification clocks start from — is generally read as the point the business’s incident response process confirms the incident meets a reporting trigger, not the date of initial detection of anomalous activity, so timestamp that determination carefully in your incident log.

How This Differs From GDPR’s 72-Hour Rule (for Multinational Compliance Teams)

GDPR Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to individuals’ rights and freedoms; a late notification must be accompanied by reasons for the delay (gdpr-info.eu, Art. 33 GDPR — Notification of a personal data breach to the supervisory authority). For a team running both programs, the practical comparison looks like this:

GDPR (Article 33)APPI
Authority notification deadline72 hours from awareness (unless unlikely to result in risk)Preliminary: ~3–5 business days; Full: 30 days (60 days for cyberattack-caused breaches)
Late notificationMust be accompanied by reasons for delayNo equivalent fixed-clock lateness provision; PPC expects good-faith promptness
Individual notificationRequired when high risk to rights and freedomsRequired, with a defined substitute-disclosure route in specific circumstances
Trigger orientationRisk-to-individual assessment across all breach typesEnumerated thresholds (sensitive data / property risk / improper purpose / >1,000 subjects)

The single-hours GDPR clock is easy to build a runbook around: 72 hours, full stop, with a documented-reasons escape hatch for delay. APPI’s two-stage structure is more forgiving on the initial clock — there is no equivalent “hours, not days” deadline — but it compresses the standard for what counts as a trigger, particularly for cyberattack-caused incidents, which is exactly the category most ransomware falls into. A multinational team’s incident response plan should treat the two regimes as running in parallel, not sequentially: the 72-hour GDPR clock and the several-business-day APPI preliminary-report expectation both start from the same “became aware” moment, and a playbook that only tracks one of them risks missing the other.

Sources: Cyber Incident Response and Data Breach Notification, Mori Hamada & Matsumoto; What You Need to Know About Japan’s Amended APPI Law, RadarFirst; Art. 33 GDPR – Notification of a personal data breach to the supervisory authority, gdpr-info.eu.

FAQ

Does every ransomware attack trigger an APPI breach report?

No. APPI's mandatory reporting duty is triggered by specific thresholds — sensitive personal information involved, risk of property damage, a likely improper purpose such as a cyberattack, or more than 1,000 affected data subjects — not by the mere fact that ransomware touched a system. A ransomware incident that never reached personal information, or that hit a system with no personal data, does not by itself create an APPI reporting obligation.

Do I need to report to Japan's PPC if the ransomware only encrypted data and didn't exfiltrate it?

It depends on what the attacker actually did, not on what your logs can prove. Because ransomware groups increasingly exfiltrate data before encrypting it, and the PPC treats a cyberattack as a likely-improper-purpose trigger largely regardless of confirmed exfiltration, most incident response teams report unless they can affirmatively rule out both encryption-only containment and any data access. Treat the absence of proof of exfiltration as inconclusive, not as proof of no leak.

How much faster does GDPR require notification than APPI?

GDPR requires notification to the supervisory authority within 72 hours of becoming aware of a breach, unless the breach is unlikely to result in a risk to individuals' rights and freedoms. APPI does not use a fixed-hours clock for its initial report: PPC guidelines interpret the preliminary report as due promptly, generally read as three to five business days, followed by a full report within 30 days (60 days if the cause is a likely improper act such as a cyberattack).

About the authors