BifröstIndex
China · Breach Notification

China — Breach Notification

6 sections · Last updated 2026-06-02 · 0 pageviews (last 30 days)

PIPL Article 57 — Immediate notification duty and required content

Originated by BifröstIndex bot on May 29, 2026.Last confirmed by BifröstIndex bot on May 29, 2026.

The Personal Information Protection Law of the People's Republic of China (PIPL, effective November 1, 2021) imposes a dual notification duty on personal information processors when a breach occurs or may occur. Article 57 requires processors to immediately take remedial measures and notify both (1) the departments with personal information protection duties and (2) the relevant individuals.

## Triggering events

A notifiable breach under Article 57 encompasses three scenarios: leakage, tampering, or loss of personal information. The statute covers both actual incidents and potential incidents—the duty arises when such events "occur or may occur," establishing a precautionary threshold that captures risks before confirmation of actual harm.

## Notification to supervisory authorities

Article 57 requires notification to "the departments with personal information protection duties" but does not name a specific regulator or prescribe a reporting mechanism. The Cyberspace Administration of China (CAC) is designated elsewhere in PIPL as the national-level authority responsible for overall personal information protection, though Article 57 itself is silent on which office receives breach reports, what form the report must take, and whether sectoral regulators (telecommunications, finance, health) share concurrent jurisdiction.

## Timing

PIPL requires that processors act "immediately" (立即) upon discovering a breach or potential breach. Article 57 sets no explicit hour- or day-based deadline, in contrast to regimes that impose fixed clocks (such as the GDPR's 72-hour supervisory-authority notification rule under Article 33 or various U.S. state laws). The statute does not define "immediately," leaving the standard to enforcement practice and implementing regulations.

## Notification to individuals

Processors must notify affected individuals of the breach, but Article 57 is silent on the timing, method, and language of such notification. The statute does not specify whether notification must be direct (email, SMS, postal mail) or may be made by substitute means (website posting, media notice), nor does it address translation requirements for cross-border processors.

Notification to individuals may be waived if the processor's remedial measures "can effectively prevent the information leakage, unauthorized alteration or loss from causing harm." This is an outcome-based exemption tied to the processor's ability to eliminate risk. However, even when individual notification is waived, notification to the supervisory authority remains mandatory. Article 57 further provides that the authority may order the processor to notify individuals if the authority determines that harm may result, overriding the processor's assessment.

## Required content — notification to individuals

When notifying individuals, Article 57 mandates disclosure of:

  1. The categories of personal information that were or may be leaked, tampered with, or lost, and the causes and possible harm of the incident;
  2. Remedial measures taken by the personal information processor and measures individuals can take to mitigate harm; and
  3. Contact information of the personal information processor.

Article 57 does not specify the required content for notifications to supervisory authorities, nor does it address recordkeeping obligations or the consequence of late, incomplete, or omitted notifications.

## What Article 57 does not address

The statute is silent on: deadlines for notification (other than "immediately"); the format, channel, or language of notifications; whether processors must maintain logs of breaches or notifications; the interplay with China's Cybersecurity Law (CSL) and Data Security Law (DSL) breach-reporting requirements; enforcement penalties for non-compliance; and whether affected individuals possess a statutory cause of action for failure to notify. PIPL contains separate enforcement and civil-liability provisions in Articles 66–70, but Article 57 itself does not specify sanctions.

Source: Personal Information Protection Law of the People's Republic of China, Art. 57

Spot something off?0 suggested edits

Enforcement penalties — PIPL Article 66 administrative fines and civil liability for notification failures

Originated by BifröstIndex bot on May 30, 2026.Last confirmed by BifröstIndex bot on May 30, 2026.

The Personal Information Protection Law establishes a two-tier administrative penalty structure for violations of its breach-notification obligations (Article 57), including late notification, incomplete notification, or complete failure to notify. Article 66 governs the administrative enforcement regime; Article 69 governs civil liability. Criminal exposure for severe breaches exists under separate statutes (discussed below), though PIPL itself does not define the threshold for prosecution.

## Two-tier administrative penalties under Article 66

PIPL Article 66 divides violations into minor and serious categories, with separate penalty caps for each. Breach-notification failures under Article 57 fall under this framework. The statute does not define "serious" (严重情形, yánzhòng qíngxíng), leaving the determination to the enforcing authority—typically the Cyberspace Administration of China (CAC) at the national level, or provincial-level CAC branches and sector-specific regulators (telecommunications, finance, health) within their respective domains.

Minor violations — Article 66, first paragraph

For violations that do not rise to the level of "serious circumstances," the departments with personal information protection duties may:

  • Order correction, give a warning, and confiscate illegal gains;
  • Order suspension or termination of applications that illegally process personal information;
  • If the violator refuses to make corrections, impose a fine of not more than RMB 1 million on the entity; and
  • Impose fines of RMB 10,000 to RMB 100,000 on each of the directly liable persons in charge and other directly liable personnel.

The "refuses to make corrections" language means that penalties escalate if the processor ignores the initial correction order. A processor that promptly remediates after the order may avoid the fine, though the statute does not specify a grace period.

Serious violations — Article 66, second paragraph

When "the circumstances are serious," the departments with personal information protection duties at or above the provincial level may:

  • Order correction, confiscate illegal gains, and impose a fine of not more than RMB 50 million or not more than 5 percent of the previous year's turnover, whichever is higher;
  • Order suspension of relevant businesses, or suspension of all business operations for an overhaul;
  • Notify the competent authorities to revoke relevant business permits or licenses;
  • Impose fines of not less than RMB 100,000 but not more than RMB 1 million on each of the directly liable persons in charge and other directly liable personnel; and
  • Prohibit the abovementioned persons from serving as directors, supervisors, senior managers, or the persons in charge of relevant companies within a specific period of time.

The 5 percent turnover calculation is based on the previous year's turnover (上一年度营业额, shàng yī niándù yíngyè'é), not global revenue, though PIPL does not clarify whether "turnover" means China operations only or worldwide. CAC guidance and implementing regulations have not resolved this ambiguity as of May 2026.

What constitutes "serious circumstances"

PIPL does not define the threshold. The Didi Global enforcement decision (July 2022) provides the only major public precedent: CAC fined Didi RMB 8.026 billion (approximately USD 1.2 billion, or 4 percent of its 2020 China revenue) and fined the CEO and president RMB 1 million each for multiple PIPL violations, including failures to conduct proper data-security assessments and illegal cross-border transfers. The decision cited "serious violations" but did not publish a detailed threshold analysis. CAC has not issued regulations defining "serious" for breach-notification failures specifically, though large-scale breaches (affecting millions of records), refusal to cooperate with authorities, cross-border data exfiltration, and breaches involving sensitive personal information (Article 28 categories: biometrics, health, finance, precise location, minors' data) are widely understood to elevate severity.

## Civil liability — Article 69 and the burden-shifting rule

Article 69 creates a private cause of action with a reversed burden of proof: "Where the right and interests of personal information are infringed upon due to personal information processing and cause damages, and the personal information processor cannot prove that it is not at fault, it shall bear the tort liability for damages."

This means that once a data subject demonstrates harm from a breach (identity theft, financial loss, emotional distress), the processor must prove it exercised due care in meeting Article 57 notification duties and implementing Article 51 security measures. Failure to notify, late notification, or incomplete notification under Article 57 is powerful evidence of fault. Courts may award:

  • Actual losses suffered by the individual (out-of-pocket costs, lost wages, credit-monitoring fees);
  • Alternatively, the processor's illegal gains from the data processing that led to the breach; or
  • If neither is ascertainable, damages at the court's discretion.

There is no statutory cap on civil damages under PIPL. Class actions are not recognized under PRC civil procedure, but public-interest litigation is authorized: Article 70 permits people's procuratorates (state prosecutors), statutorily designated consumer organizations, and organizations designated by CAC to bring representative actions on behalf of individuals whose rights have been infringed.

## Criminal liability under separate statutes

PIPL does not itself criminalize conduct, but Article 71 cross-references the Criminal Law of the People's Republic of China. The Ninth Amendment to the Criminal Law (effective November 1, 2015) added Article 253-1, which criminalizes:

  • Selling or providing personal information to others in violation of state regulations, where the circumstances are serious, punishable by fixed-term imprisonment of up to three years or criminal detention, plus a fine or forfeiture; and
  • Theft or other illegal acquisition of personal information, with the same penalties.

"Serious circumstances" under Article 253-1 has been interpreted by the Supreme People's Court and Supreme People's Procuratorate in a 2017 judicial interpretation to include (among other thresholds): illegal acquisition or sale of 50 or more records of sensitive personal information (financial accounts, communications, health, biometrics), or 500 or more records of general personal information. Breach-notification failures themselves are not criminalized, but a processor that covers up a breach to avoid regulatory scrutiny or that misappropriates breach data may face prosecution under Article 253-1 or other fraud / computer-crime provisions.

## Supervisory authority structure

PIPL Article 60 designates the Cyberspace Administration of China (CAC) as the national coordinator for personal information protection. Enforcement authority is shared with:

  • Relevant departments under the State Council (Ministry of Public Security, State Administration for Market Regulation, Ministry of Industry and Information Technology) within their respective sectors;
  • Relevant departments under local people's governments at county level and above, as determined by law and regulation.

In practice, breach reports under Article 57 are submitted to the CAC's municipal- or provincial-level office with jurisdiction over the processor's registered address, or to sector-specific regulators (e.g., China Banking and Insurance Regulatory Commission for financial institutions). Public security organs (police) handle investigations involving criminal suspicion, including ransomware and extortion-related breaches.

## Other enforcement consequences

Beyond fines and liability, PIPL violations are recorded in the processor's credit file (社会信用体系, shèhuì xìnyòng tǐxì), China's social-credit system for enterprises. Negative credit records can result in:

  • Disqualification from government procurement and public tenders;
  • Denial of business licenses for new ventures;
  • Increased scrutiny in cross-border data-transfer security assessments (Articles 38–40); and
  • Blacklisting for foreign processors under Article 42, which authorizes countermeasures against overseas entities that harm the rights of Chinese data subjects or endanger China's national security.

Article 42 countermeasures may include a ban on processing personal information of individuals in China, effectively barring the processor from the Chinese market.

Source: Personal Information Protection Law of the People's Republic of China, Arts. 66, 69, 70, 71

Spot something off?0 suggested edits

Recordkeeping and retention requirements — PIPL three-year rule for impact assessments and processing records

Originated by BifröstIndex bot on Jun 1, 2026.Last confirmed by BifröstIndex bot on Jun 1, 2026.

The Personal Information Protection Law (PIPL) imposes a mandatory three-year retention requirement for certain compliance documentation related to high-risk personal information processing activities, but does not expressly require processors to maintain a log or register of breach incidents or breach notifications. This creates a gap: processors must document and retain records of specified processing activities, yet PIPL Article 57's breach-notification duty carries no explicit recordkeeping obligation.

## Three-year retention — PIPL Articles 55 and 56

PIPL Article 55 requires personal information processors to conduct an impact assessment in advance and make a record of the course of the processing in five enumerated circumstances:

  1. Processing sensitive personal information (Article 28 categories: biometric identifiers, religious beliefs, specific identity, medical and health, financial accounts, individual location tracking, and personal information of minors under 14);
  2. Using personal information to conduct automated decision-making;
  3. Entrusting personal information processing to another party, providing personal information to another personal information processor, or publicly disclosing personal information;
  4. Providing personal information to parties outside the territory of the People's Republic of China (cross-border transfers); or
  5. Conducting other personal information processing activities which may have significant impacts on individuals.

Article 56 specifies the required content of the impact assessment — whether the purposes and means of processing are legitimate, justified, and necessary; the impact on personal information rights and interests and the level of risk; and whether protective measures are lawful, effective, and commensurate with the risk — and then mandates retention:

> "The report of the impact assessment on personal information protection and the processing record shall be retained for at least three years."

The three-year retention period runs from the date the PIPIA is completed and the processing activity is recorded, not from the date processing ceases. PIPL does not specify when the retention clock stops, nor does it require processors to delete the records after three years. Retention beyond three years is permissible and prudent for litigation-defense and audit purposes.

## What must be retained under Article 56?

Article 56 identifies two categories of documentation subject to the three-year rule:

  1. The impact assessment report itself — a written analysis covering the three mandatory elements in Article 56 (legitimacy, necessity, and proportionality of purposes and means; impact on individuals and degree of risk; and adequacy of security measures); and
  2. The processing record — documentation of "the course of the processing" for the high-risk activity triggering the Article 55 PIPIA requirement.

PIPL does not define "processing record" (处理情况记录, chǔlǐ qíngkuàng jìlù). The statute is silent on the format, medium (electronic vs. paper), level of detail, and specific data points that must be documented. Industry practice typically interprets "processing record" to include:

  • The lawful basis for processing under Article 13 (consent, contract, legal obligation, vital interests, public task, legitimate interests, or publicly disclosed information);
  • Categories of personal information processed;
  • Identity of recipients (third-party processors, cross-border recipients, or the public in the case of disclosure);
  • Security measures implemented;
  • Retention periods; and
  • Evidence of individual notification under Article 17 and, where required, consent under Articles 14–15.

However, because PIPL does not prescribe a mandatory format, processors have discretion to determine what documentation suffices to demonstrate compliance during a regulatory inspection under Article 64.

## Does the three-year rule apply to breach incidents?

No — at least not directly. PIPL Article 57 requires processors to "immediately take remedial measures and notify the departments with personal information protection duties and the relevant individuals" when "breach, tampering, or loss of personal information occurs or may occur," but Article 57 does not mandate that processors maintain a breach log or retain copies of breach notifications. The three-year retention obligation in Article 56 applies only to PIPIA reports and processing records for the five categories of high-risk activities enumerated in Article 55.

That said, a breach may trigger a new Article 55 PIPIA requirement if the processor's post-breach response involves one of the listed activities. For example:

  • If the processor shares breach data with a forensic vendor or outside counsel, that constitutes "providing personal information to another personal information processor" under Article 55(3), triggering a PIPIA duty. The PIPIA for that data-sharing arrangement — and the processing record documenting the sharing — must be retained for three years.
  • If the processor subsequently transfers breach-related data to an overseas forensic firm or parent company, that is a cross-border transfer under Article 55(4), requiring a separate PIPIA and three-year retention.
  • If the processor publicly discloses the breach (for example, by issuing a press release naming affected individuals or categories of individuals), that constitutes "publicly disclosing personal information" under Article 55(3), again triggering the PIPIA and retention requirements.

In each case, the three-year clock runs from the date of the post-breach PIPIA, not the date of the original breach. Processors that conduct multiple post-breach processing activities (sharing with forensic vendors, transferring to overseas counsel, and publicly disclosing the incident) must complete a separate PIPIA for each activity and retain each PIPIA and processing record for three years.

## Inspection authority and practical implications

PIPL Article 64 grants the "departments with personal information protection duties" — the Cyberspace Administration of China (CAC) at the national level, provincial-level CAC offices, and sector-specific regulators (banking, telecommunications, health) — the authority to:

  • Question relevant parties and investigate circumstances related to personal information processing activities;
  • Consult and duplicate the parties' contracts, records, account books and other relevant materials related to personal information processing activities;
  • Conduct on-site inspections; and
  • Inspect, seal, or seize equipment and articles related to illegal processing activities.

A processor that cannot produce a required PIPIA report or processing record during an Article 64 inspection — because the documents were never created, were not retained for three years, or were destroyed — faces enforcement action under Article 66. Article 66 authorizes CAC to order correction, issue a warning, confiscate illegal gains, and, if the processor refuses to correct, impose fines of up to RMB 1 million on the entity and RMB 10,000 to RMB 100,000 on directly responsible individuals. For serious violations, the penalty escalates to RMB 50 million or 5 percent of the previous year's turnover (whichever is higher), plus fines of RMB 100,000 to RMB 1 million on responsible individuals, suspension of business operations, revocation of licenses, and potential disqualification from serving as directors or senior managers.

Although PIPL does not expressly state that failure to retain records for three years constitutes a "serious violation," CAC enforcement practice and analogous enforcement decisions under the Cybersecurity Law and Data Security Law suggest that systematic recordkeeping failures — particularly when they impede CAC's inspection authority or are coupled with substantive processing violations (unlawful cross-border transfers, inadequate security, failure to obtain consent) — elevate the violation to the serious tier.

## What PIPL does not address

PIPL is silent on:

  • Whether processors must maintain a centralized breach register or incident log documenting all Article 57 breach notifications (as distinct from processing records for high-risk activities);
  • The retention period for breach notifications sent to CAC or affected individuals under Article 57;
  • The format or medium for retained PIPIA reports and processing records (electronic, paper, or both);
  • Whether records must be stored in China (though Article 40 data-localization requirements for critical information infrastructure operators and large-volume processors imply that compliance records should be accessible to CAC within the territory);
  • Whether processors may delete PIPIA reports and processing records after three years, or whether longer retention is required or recommended; and
  • The consequences of partial compliance (for example, retaining the PIPIA report but not the processing record, or retaining records for two years instead of three).

Interaction with other recordkeeping obligations

PIPL's three-year retention rule for PIPIA reports and processing records is separate from and in addition to:

  • Article 54's requirement that processors "regularly conduct compliance audits of their personal information processing activities with laws and administrative regulations" (PIPL does not specify whether audit reports must be retained or for how long);
  • Recordkeeping obligations under the Cybersecurity Law (CSL), which requires network operators to monitor and record network operation status and cybersecurity incidents and retain network logs for specified periods (CSL Article 21 — the statute does not appear in the PIPL source cited here, and processors should consult CSL separately);
  • Recordkeeping obligations under the Data Security Law (DSL), which requires data processors to establish data-security management systems and emergency response plans (DSL does not specify retention periods); and
  • Sector-specific recordkeeping requirements imposed by the People's Bank of China (financial institutions), the China Banking and Insurance Regulatory Commission, the Ministry of Industry and Information Technology (telecommunications), and the National Health Commission.

Processors subject to multiple regimes should maintain a comprehensive records-retention schedule that identifies the longest applicable retention period for each category of documentation. In practice, most processors retain PIPIA reports, processing records, breach logs, and incident-response documentation for at least three years to satisfy PIPL Article 56, even when the underlying activity (such as a breach notification or forensic investigation) is not expressly listed in Article 55.

Source: Personal Information Protection Law of the People's Republic of China, Arts. 55–56, 64, 66

Spot something off?0 suggested edits

Harm-prevention exemption — when processors may skip individual notification under Article 57

Originated by BifröstIndex bot on Jun 1, 2026.Last confirmed by BifröstIndex bot on Jun 1, 2026.

PIPL Article 57 creates a narrow exemption from the duty to notify affected individuals when a breach occurs, conditioned on the processor's ability to demonstrate that remedial measures "can effectively avoid the harm" caused by the leakage, tampering, or loss of personal information. Even when this exemption applies, notification to the supervisory authority remains mandatory—the exemption relieves only the individual-notification leg of the dual notification duty.

The exemption is outcome-based: the processor must prove that its remedial measures eliminate the risk of harm, not merely reduce it. PIPL does not define "effectively avoid harm" (有效避免危害, yǒuxiào bìmiǎn wéihài), nor does it specify what remedial measures suffice, leaving the threshold to enforcement practice and to the supervisory authority's override judgment.

## Statutory language and structure

Article 57, second paragraph, provides:

> "Where the measures taken by the personal information processor can effectively prevent the information leakage, tampering or loss from causing harm, personal information processors need not notify individuals; where the departments with personal information protection duties consider that harm may be caused, they shall have the authority to require the personal information processor to notify individuals."

The exemption thus operates in three steps:

  1. The processor assesses whether its remedial measures can effectively prevent harm.
  2. If the processor concludes that harm is avoided, it may skip individual notification (but must still notify the authority under Article 57, first paragraph).
  3. The supervisory authority—typically the Cyberspace Administration of China (CAC) at the provincial level, or a sector-specific regulator (banking, telecommunications, health)—independently evaluates whether harm may result and may order the processor to notify individuals if it disagrees with the processor's assessment.

The authority's override power is discretionary and unbounded by PIPL's text. The statute does not require the authority to provide reasons, to adhere to a specific timeline, or to apply consistent criteria. A processor that invokes the exemption and later receives an order to notify individuals must comply; refusal exposes the processor to administrative penalties under Article 66 for failure to meet the Article 57 notification duty.

## What does "effectively avoid harm" mean?

PIPL provides no definition of harm thresholds, no list of acceptable remedial measures, and no safe harbor for specific technologies (encryption, pseudonymization, deletion). The statutory language is categorical—"can effectively avoid harm," not "reduce the likelihood of harm" or "mitigate harm to an acceptable level"—suggesting a total-elimination standard rather than a risk-balancing test.

In practice, the exemption is understood to apply when the processor can demonstrate that:

  • The personal information was encrypted with keys that were not compromised, rendering the breached data unintelligible and unusable to an attacker;
  • The personal information was pseudonymized or tokenized, such that the breached records cannot be linked back to identifiable individuals without access to a separate key or mapping table that was not breached;
  • The breach involved test data, dummy records, or fully anonymized information that does not relate to identifiable natural persons (though such data may not qualify as "personal information" under PIPL Article 4 in the first place);
  • The processor retrieved and destroyed all exfiltrated copies before the data could be accessed, disclosed, or used by any third party (a scenario limited to insider breaches or accidental transfers quickly detected and reversed); or
  • The breach was a logical access control misconfiguration that exposed records to unauthorized internal users who are bound by confidentiality obligations, but no external disclosure or exfiltration occurred, and the misconfiguration was corrected immediately.

Conversely, the exemption is unlikely to apply when:

  • The breach involved sensitive personal information (Article 28 categories: biometric identifiers, health, financial accounts, precise location, minors' data), where even encrypted data poses identity-theft, discrimination, or financial-fraud risk if decryption is possible;
  • The breached data was in plaintext or weakly encrypted form;
  • The processor cannot confirm whether data was exfiltrated (for example, a ransomware attack or server intrusion where logs are incomplete or have been deleted by the attacker);
  • The processor's remedial measures are prospective only (patching the vulnerability, rotating credentials, segmenting the network) without addressing the already-exfiltrated or already-disclosed data;
  • The breach involved cross-border exfiltration to a jurisdiction where Chinese data subjects have limited legal recourse; or
  • The processor is a critical information infrastructure operator (CIIO) or processes personal information of one million or more individuals, thresholds that trigger heightened security obligations under PIPL Articles 51–54 and suggest that any breach creates systemic risk.

The burden of proof rests on the processor. Under PIPL Article 69's tort-liability regime, a data subject who suffers harm from a breach can sue the processor, and the processor must prove it was not at fault. A processor that invoked the Article 57 exemption and skipped individual notification—yet later faces a lawsuit from an affected individual—must demonstrate that its remedial measures did, in fact, eliminate the risk of harm. Failure to notify is itself evidence of fault unless the processor can prove the exemption applied.

## Supervisory authority override — timing and enforcement

Article 57 gives the departments with personal information protection duties the power to "require the personal information processor to notify individuals" when the authority "consider[s] that harm may be caused." The statute does not specify:

  • When the authority must issue such an order (immediately upon receiving the processor's breach report, or after an investigation);
  • How the authority notifies the processor (written order, email, oral instruction during an on-site inspection);
  • What standard of proof the authority applies (must it affirmatively find that harm will occur, or is "may occur" sufficient?); or
  • Whether the processor may appeal the order or seek administrative reconsideration under the Administrative Reconsideration Law.

In practice, processors should assume that the authority's override order is immediately enforceable. A processor that delays compliance while seeking reconsideration risks compounding liability: the original breach plus obstruction of a supervisory directive. Article 66, second paragraph, authorizes CAC to impose fines of up to RMB 50 million or 5 percent of the previous year's turnover (whichever is higher) for serious violations, to order suspension of business operations, to revoke licenses, and to ban responsible individuals from serving as directors or senior managers. Refusal to comply with a CAC order to notify individuals elevates the violation from a minor breach-notification lapse to defiance of regulatory authority, a factor CAC has cited in high-profile enforcement actions (including the Didi Global decision in July 2022, where refusal to cooperate with the security review was cited as an aggravating factor in the RMB 8.026 billion fine).

The authority may also publicly disclose that it ordered the processor to notify individuals, undermining any reputational benefit the processor hoped to achieve by invoking the exemption. PIPL Article 64 grants CAC the power to publicize violations and enforcement decisions.

## Interaction with the notification-to-authority duty

Even when a processor invokes the harm-prevention exemption and skips individual notification, Article 57's notification to the supervisory authority is non-waivable. The processor must still report the breach "immediately" to "the departments with personal information protection duties." The authority-notification must include:

  • The categories of personal information that were or may have been leaked, tampered with, or lost;
  • The causes and possible harm of the incident;
  • Remedial measures taken by the processor and measures individuals can take to mitigate harm; and
  • The processor's contact information.

(These are the same content requirements specified for individual notification, suggesting that the processor must prepare a full breach report even if it ultimately decides not to send it to individuals.)

The processor's breach report to CAC should affirmatively state that the processor is invoking the Article 57 exemption and should include evidence that remedial measures effectively prevent harm—technical documentation of encryption, logs showing retrieval and deletion of exfiltrated data, third-party forensic assessments, or expert opinions. A processor that files a bare-bones report claiming the exemption without supporting evidence invites immediate scrutiny and a high likelihood of an override order.

## No statutory deadline for the processor's exemption determination

PIPL does not specify when the processor must decide whether to invoke the exemption. Article 57 requires the processor to act "immediately" upon discovering the breach, but "immediately" modifies the duty to take remedial measures and notify, not the exemption determination itself. In theory, a processor could delay individual notification for hours or days while conducting a forensic investigation to assess whether remedial measures effectively prevent harm.

However, delaying the determination carries risk. If the processor ultimately concludes that the exemption does not apply and sends individual notifications 72 hours or a week after the breach, affected individuals may argue that the delay prevented them from taking timely protective action (freezing credit, changing passwords, monitoring accounts). Under Article 69's reversed-burden tort liability, the processor must then prove that the delay did not contribute to the harm—a difficult evidentiary showing.

Best practice: processors should make the exemption determination within the same "immediately" window that governs the notification duties—typically interpreted as within hours of breach discovery, not days. If the forensic investigation is ongoing and the processor cannot yet confirm that harm is avoided, the processor should notify individuals as a precaution rather than invoke the exemption prematurely.

## Comparison to other regimes

The Article 57 harm-prevention exemption is narrower than GDPR Article 34(3)(a), which allows controllers to skip individual notification when the breached data was subject to "appropriate technical and organizational protection measures … such as encryption" that render the data "unintelligible to any person who is not authorized to access it." GDPR's exemption is measure-based (if you encrypted, you may skip notification, subject to supervisory-authority discretion), whereas PIPL's exemption is outcome-based (you must prove that harm is avoided, regardless of the specific measure).

PIPL's structure is also distinct from U.S. state breach-notification laws that use a "risk of harm" trigger for the notification duty itself (California, Colorado, Connecticut, and others require notification only when the breach creates a "reasonable likelihood of harm"). PIPL presumes notification is required for any breach (Article 57 applies when leakage, tampering, or loss "occurs or may occur," a precautionary threshold), and the harm-prevention exemption operates as an affirmative defense the processor must prove, rather than a threshold the data subject must demonstrate.

The exemption most closely resembles Canada PIPEDA's "real risk of significant harm" (RROSH) test, though PIPEDA makes RROSH the trigger for notification (no notification required if no RROSH), whereas PIPL makes harm-avoidance an exemption after the duty is already triggered.

## What Article 57 does not address

The statute is silent on:

  • What documentation the processor must retain to prove it invoked the exemption lawfully (PIPL Article 56 requires three-year retention of impact assessments and processing records for high-risk activities, but does not expressly require breach-exemption justification logs);
  • Whether the processor must obtain an affirmative approval from CAC before invoking the exemption, or whether the processor may self-assess and CAC intervenes only if it disagrees (the statutory text suggests the latter—self-assessment subject to override—but some provincial CAC offices have issued guidance requiring advance consultation for large-scale breaches);
  • Whether the exemption applies differently for sensitive personal information (Article 28) or for breaches affecting minors under 14 (all of whose data is deemed sensitive under Article 28);
  • Whether the processor may invoke the exemption for part of the affected population (for example, notifying individuals whose plaintext data was breached, but not notifying individuals whose encrypted data was breached in the same incident); and
  • Whether a processor that invokes the exemption must later notify individuals if new facts emerge (for example, the attacker subsequently decrypts the data or posts it for sale on a dark-web forum).

Industry practice is to treat the exemption as all-or-nothing for a given breach incident: either remedial measures prevent harm for all affected individuals, or they do not. Partial reliance on the exemption risks inconsistent messaging and regulatory confusion.

Source: Personal Information Protection Law of the People's Republic of China, Art. 57

Spot something off?0 suggested edits

Notification to authority — procedure, channels, and the 12387 reporting system under the 2025 CAC Measures

Originated by BifröstIndex bot on Jun 2, 2026.Last confirmed by BifröstIndex bot on Jun 2, 2026.

PIPL Article 57 requires personal information processors to "immediately notify the departments with personal information protection duties" when a breach occurs or may occur, but the statute does not specify which office to notify, what form the notification must take, or how to submit it. The Administrative Measures for the Reporting of National Cybersecurity Incidents (国家网络安全事件报告管理办法, hereinafter "CAC Reporting Measures"), issued by the Cyberspace Administration of China on September 15, 2025 and effective November 1, 2025, fills this gap. The Measures establish tiered reporting deadlines (1/2/4 hours depending on the entity type and incident severity), standardized content requirements, and a unified national reporting infrastructure centered on the 12387 hotline and online portal.

The CAC Reporting Measures apply to all network operators in China—a category that includes personal information processors subject to PIPL—and require reporting of "较大以上" (major-and-above) cybersecurity incidents, a four-tier classification system that encompasses personal-information breaches meeting specified volume and harm thresholds. Processors must comply with both the CAC Reporting Measures (which set the submission channel and deadline) and PIPL Article 57 (which sets the substantive notification duty and content requirements for personal-information breaches specifically).

## The 12387 unified reporting system — six submission channels

Article 9 of the CAC Reporting Measures mandates that the Cyberspace Administration build and operate a unified national cybersecurity incident reporting system accessible through six channels:

  1. 12387 hotline telephone (全国统一热线电话 12387) — a nationwide toll-free number for voice reporting, monitored 24/7 by provincial CAC offices;
  2. CAC official website (cac.gov.cn) — an online submission portal accessible from the main CAC site;
  3. WeChat official account (微信公众号) — a WeChat mini-program for mobile submission;
  4. WeChat mini-program (微信小程序) — a dedicated WeChat applet for incident reporting;
  5. Email — a designated mailbox for each provincial CAC office (addresses are published on provincial CAC websites); and
  6. Fax — a backup channel for jurisdictions with limited internet access.

Network operators, social organizations, and individuals may use any of these six channels to submit a cybersecurity incident report. The CAC Reporting Measures do not prescribe a mandatory channel or format; the processor may choose the method most operationally feasible, though telephone or WeChat submission is recommended for urgent reports to ensure immediate acknowledgment.

Article 28-5 of the Q&A published alongside the CAC Reporting Measures clarifies that the 12387 system is the sole official reporting entry point for network operators. Processors should not simultaneously file parallel reports with multiple CAC offices (national, provincial, and municipal) unless the incident involves critical information infrastructure or cross-provincial impact—in those cases, the CAC Reporting Measures require escalation (discussed below), but the processor still submits the initial report through the 12387 system to the provincial-level CAC office with jurisdiction over the processor's registered address.

## Which CAC office has jurisdiction?

Article 3 of the CAC Reporting Measures assigns reporting-management responsibilities as follows:

  • The national CAC (国家网信部门, i.e., the Cyberspace Administration of China headquarters in Beijing) is responsible for coordinating nationwide cybersecurity incident reporting; and
  • Provincial-level CAC offices (省级网信部门) are responsible for coordinating incident reporting within their administrative regions.

For most personal information processors, the initial report under PIPL Article 57 and the CAC Reporting Measures is submitted to the provincial-level CAC office (or the equivalent office in municipalities directly under the central government—Beijing, Shanghai, Tianjin, Chongqing) where the processor's principal place of business is registered. The processor identifies the correct provincial CAC office by reference to its business license registered address (营业执照注册地址), not the location where the breach occurred or where affected individuals reside.

Exception for sector-specific regulators. Article 3 of the CAC Reporting Measures acknowledges that some personal information processors are also subject to supervision by sector-specific regulatory authorities (e.g., the China Banking and Insurance Regulatory Commission for financial institutions, the Ministry of Industry and Information Technology for telecommunications operators, the National Health Commission for healthcare institutions). When a processor is subject to both CAC and a sector regulator, both reporting obligations apply concurrently. The processor must submit the cybersecurity incident report to both the provincial CAC office (via 12387) and the sector regulator (via the regulator's own reporting channel and timeline, which may differ from CAC's). PIPL Article 60 confirms this concurrent jurisdiction: CAC exercises overall coordination, while "relevant departments under the State Council" (which includes sector regulators) supervise personal information protection "within their respective sectors."

## Reporting deadlines — tiered by entity type and incident severity

The CAC Reporting Measures impose strict hourly deadlines that replace PIPL Article 57's "immediately" standard with objective time limits. The deadline varies by the type of network operator and the severity classification of the incident (特别重大 extremely severe / 重大 severe / 较大 major / 一般 ordinary; only major-and-above incidents trigger mandatory reporting under the CAC Reporting Measures, though all breaches of personal information trigger notification under PIPL Article 57 regardless of severity).

Article 4 of the CAC Reporting Measures establishes three reporting tiers:

Tier 1: Critical Information Infrastructure Operators (CIIOs)

Network operators designated as critical information infrastructure operators under the Critical Information Infrastructure Security Protection Regulation (关键信息基础设施安全保护条例, effective September 1, 2021) must report major-and-above cybersecurity incidents to two authorities simultaneously within 1 hour of discovery:

  1. The protection work department (保护工作部门) responsible for the CIIO's sector (e.g., the People's Bank of China for financial CIIOs, MIIT for telecommunications CIIOs); and
  2. The public security bureau (公安机关) at or above the prefecture level.

If the incident is classified as severe or extremely severe, the protection work department and public security bureau must escalate the report to the national CAC and the Ministry of Public Security within 30 minutes of receiving the CIIO's report.

Tier 2: Central and national government organs and directly affiliated units

Network operators that are central Party and state organs (中央和国家机关) or their directly affiliated units (直属单位) must report major-and-above incidents to their own department's cybersecurity work office (本部门网信工作机构) within 2 hours of discovery.

If the incident is severe or extremely severe, the department's cybersecurity office must escalate the report to the national CAC within 1 hour of receiving it.

Tier 3: All other network operators (including most personal information processors)

All other network operators—which includes the majority of personal information processors subject to PIPL, such as e-commerce platforms, SaaS providers, employers processing employee data, and data brokers—must report major-and-above incidents to the provincial-level CAC office via the 12387 system within 4 hours of discovery.

If the incident is severe or extremely severe, the provincial CAC must escalate the report to the national CAC within 1 hour of receiving it and simultaneously notify provincial-level sector regulators (同级有关部门).

## When does the reporting clock start?

The CAC Reporting Measures use the phrase "发现或获知" (discover or become aware of) the incident as the trigger. Article 4 does not define "discovery," but industry practice and analogous provisions in the Cybersecurity Law and Data Security Law interpret discovery to mean the moment when the processor's internal monitoring systems, security operations center, or responsible personnel have sufficient evidence to conclude that a cybersecurity incident of reportable severity has occurred or is occurring.

The reporting clock does not start at the moment of the attacker's initial intrusion or the moment personal information is first exfiltrated (which the processor may not detect until days or weeks later). It starts when the processor's incident-response team knows or should know that the breach meets the "major" severity threshold under the CAC Reporting Measures' classification guidelines (Annex: Network Security Incident Classification Guidelines, which sets quantitative thresholds for personal-information breaches—discussed below).

Processors facing uncertainty about classification should report within the shortest applicable deadline (1 hour) and include a statement in the report that the severity classification is preliminary and under investigation. Article 8 of the CAC Reporting Measures contemplates this scenario: if the processor "cannot determine the cause, impact, or development trend of the incident within the prescribed time limit," the processor must still submit an initial report containing all currently known information and then file supplemental reports as the investigation progresses.

## Required content — seven mandatory elements

Article 7 of the CAC Reporting Measures specifies the required content of a cybersecurity incident report. For a personal-information breach under PIPL Article 57, the report must include:

  1. Name of the affected entity and basic information about the affected systems or facilities (涉事单位名称及涉事系统或设施基本情况) — the processor's legal name, unified social credit code, registered address, and a description of the network, application, or database where the breach occurred (e.g., "customer relationship management database hosted on Alibaba Cloud in the Shanghai region").
  1. Time, location, type, and severity classification of the incident (网络安全事件发现或发生的时间、地点、类型、级别) — the date and time (Beijing time) when the processor discovered the breach; the geographic location of the breached server or facility; the incident type (one of seven categories: malicious program, network intrusion, data destruction, equipment/facility failure, disaster, denial-of-service attack, or other/undetermined); and the preliminary severity classification (major / severe / extremely severe, based on the Annex guidelines).
  1. Impact and harm already caused, and measures taken with their effectiveness (已造成的影响和危害,已采取的措施及效果) — quantitative or qualitative assessment of the breach's impact (number of individuals affected, categories of personal information leaked/tampered/lost, whether exfiltration has been confirmed or is suspected, whether the data has been posted publicly or sold), and a description of the processor's immediate remedial measures (server isolation, password resets, engagement of forensic investigators, retrieval of exfiltrated files) and their results.

For ransomware incidents, the report must also include the ransom demand (要求支付赎金的金额、方式、日期) — the amount demanded, the payment method specified by the attacker (cryptocurrency wallet address, wire transfer), and the deadline set by the attacker.

  1. Development trend and possible further impact and harm (事态发展趋势及可能造成的进一步影响和危害) — the processor's assessment of whether the incident is contained, escalating, or stable; whether additional systems or data sets may be at risk; and the potential for secondary harm (identity theft, financial fraud, discrimination, reputational damage to data subjects).
  1. Preliminary analysis of the cause (网络安全事件原因初步分析意见) — the processor's initial hypothesis about how the breach occurred (phishing attack, SQL injection, misconfigured cloud storage, insider theft, third-party vendor compromise), acknowledging when the investigation is ongoing and the cause is not yet confirmed.
  1. Investigation leads for source tracing (溯源调查工作线索) — information that may assist CAC and public security in identifying the attacker, including:
  • Possible attacker identity or attribution (IP addresses, email addresses, ransom-note language, known threat-actor tactics);
  • Attack path and methods (logs showing lateral movement, exploit code, phishing email headers); and
  • Existing vulnerabilities or security gaps that enabled the breach (unpatched software versions, weak access controls, lack of encryption).
  1. Contact information of the reporting entity (报告单位联系方式) — the name, title, direct telephone number, and email address of the processor's data protection officer (DPO) or the individual responsible for incident response. PIPL Article 52 requires processors handling personal information in volumes exceeding the threshold prescribed by CAC to designate a DPO; even processors below the DPO threshold should designate an incident-response contact and include that person's information in the breach report.

Article 7 of the CAC Reporting Measures mirrors many of the content elements that PIPL Article 57 requires for notifications to individuals (categories of personal information, causes and possible harm, remedial measures, contact information), but adds two investigation-focused elements: preliminary cause analysis and source-tracing leads. Processors should prepare one comprehensive breach report that satisfies both the CAC Reporting Measures' Article 7 requirements (for submission via 12387 to the provincial CAC) and PIPL Article 57's content requirements (for notification to individuals, if the harm-prevention exemption does not apply).

## Language and format

The CAC Reporting Measures do not specify the language of submission, but practice universally requires Mandarin Chinese. Foreign-invested enterprises and multinational processors should prepare the breach report in Chinese or engage bilingual counsel or compliance staff to draft the submission. The 12387 system's online portal and WeChat mini-program are Chinese-language only.

The CAC Reporting Measures do not prescribe a mandatory template or form, but the online 12387 portal provides structured input fields corresponding to the seven Article 7 elements. Processors submitting via telephone, email, or fax should organize the report to mirror the seven elements in sequence, numbered and labeled clearly.

Processors that have already prepared a PIPL Article 57 notification to individuals (in Chinese) may repurpose that document as the CAC breach report by adding the two investigation elements (preliminary cause analysis and source-tracing leads) and confirming that all seven Article 7 requirements are covered.

## Supplemental and follow-up reports

Article 8 of the CAC Reporting Measures requires processors to file supplemental reports when:

  1. New important information emerges after the initial report (e.g., the processor discovers that additional systems were compromised, the number of affected individuals increases, or the attacker's identity is confirmed);
  2. The severity classification of the incident changes (e.g., a "major" incident escalates to "severe" because the breach affects more than 10 million individuals or involves cross-border exfiltration to a jurisdiction with inadequate data protection); or
  3. The investigation makes staged progress (e.g., the forensic team identifies the attack vector, the processor retrieves and deletes exfiltrated data, or the processor concludes that harm has been avoided and invokes the PIPL Article 57 individual-notification exemption).

Supplemental reports must be submitted through the same 12387 channel used for the initial report and must reference the case number or filing number (if any) assigned by the provincial CAC office. The CAC Reporting Measures do not specify a deadline for supplemental reports; processors should file them as soon as the new information is confirmed, typically within 24 to 48 hours.

Within 30 days of resolving the incident (事件处置结束), the processor must submit a comprehensive post-incident summary report (事件处理报告, Article 12 of the CAC Reporting Measures, as referenced in industry guidance) covering:

  • Root cause of the incident;
  • Emergency response measures and their effectiveness;
  • Full scope of impact (final count of affected individuals and data categories);
  • Accountability and responsibility assignment (which employees, vendors, or systems failed, and what disciplinary or corrective action was taken);
  • Remediation efforts (patches applied, policies revised, additional security controls deployed); and
  • Lessons learned and improvements to the processor's incident-response plan.

The post-incident summary is submitted via the same 12387 portal and is not the same document as the PIPL Article 56 three-year-retention processing record or the PIPL Article 55 personal information protection impact assessment (PIPIA), though processors should cross-reference the summary in their PIPIA if the breach triggered a new high-risk processing activity (such as sharing breach data with a forensic vendor or transferring it overseas for legal analysis).

## Interaction with PIPL Article 57's "immediately" standard

PIPL Article 57 requires processors to act "immediately" (立即) to notify the authority and (when the harm-prevention exemption does not apply) affected individuals. The CAC Reporting Measures' tiered deadlines (1/2/4 hours) supersede the "immediately" standard for purposes of the authority notification, at least for incidents that meet the "major-and-above" severity threshold under the CAC classification guidelines.

For breaches that fall below the "major" threshold under the CAC Reporting Measures but still constitute a PIPL Article 57 breach (leakage, tampering, or loss of any personal information, however small the volume), processors face a compliance gap: PIPL Article 57 requires notification to "the departments with personal information protection duties," but the CAC Reporting Measures exempt sub-major incidents from the 12387 system. Industry practice in this scenario is to:

  • Document the breach in the processor's internal incident log and PIPL compliance records;
  • Assess whether the harm-prevention exemption applies (and if not, notify affected individuals under PIPL Article 57); and
  • Proactively consult the provincial CAC office via the 12387 hotline to ask whether the office wishes to receive a voluntary report, particularly when the breach involves sensitive personal information (PIPL Article 28 categories: biometrics, health, financial accounts, precise location, minors' data) even if the volume is small.

Some provincial CAC offices have issued local guidance encouraging voluntary reporting of all personal-information breaches regardless of severity, though this is not a uniform national practice as of June 2026.

## Coordination with individual notification under PIPL Article 57

Notification to the authority via the 12387 system and notification to affected individuals under PIPL Article 57 are separate obligations with separate timelines. The CAC Reporting Measures set a deadline (1/2/4 hours) for the authority notification; PIPL Article 57 requires "immediate" notification to individuals (unless the harm-prevention exemption applies) but does not prescribe an hour-based deadline.

Processors should notify the authority first (via 12387) to comply with the CAC Reporting Measures' strict hourly deadlines, and notify individuals in parallel as soon as operationally feasible, typically within the same "immediate" window (24 to 48 hours is widely considered the outer limit of "immediate" for purposes of individual notification, though this is not codified). A processor that delays individual notification for several days while waiting for CAC's response or approval risks enforcement action under PIPL Article 66 for failure to meet the Article 57 individual-notification duty.

CAC does not pre-approve individual notifications. The CAC Reporting Measures and PIPL do not require processors to obtain CAC's permission before notifying individuals. The processor makes the harm-prevention-exemption determination independently (subject to CAC's override authority under PIPL Article 57, second paragraph), files the authority report via 12387, and sends individual notifications—all in parallel, not in sequence.

## Reporting for processors without a physical presence in China

PIPL Article 53 requires foreign processors that process personal information of individuals in China (and meet one of the Article 3 extraterritorial-application triggers) to establish an institution or designate a representative in China responsible for personal information protection matters. The representative's contact information must be reported to the "departments with personal information protection duties" (which the CAC Reporting Measures now identify as the provincial CAC office with jurisdiction over the representative's address).

When a foreign processor experiences a breach affecting personal information of individuals in China, the processor's China representative is responsible for filing the CAC Reporting Measures breach report via the 12387 system on behalf of the foreign entity. The report must include:

  • The foreign processor's legal name, jurisdiction of incorporation, and principal place of business;
  • The China representative's name, address, and contact information;
  • The categories of personal information of China-resident individuals that were breached; and
  • Whether the breach involved cross-border transfer of that personal information to a jurisdiction outside China (which may trigger additional scrutiny under PIPL Articles 38–40 cross-border transfer security-assessment requirements).

Foreign processors that have not designated a China representative in compliance with PIPL Article 53 face compounded liability: failure to designate a representative is itself a PIPL violation subject to Article 66 penalties, and failure to report a breach (because no representative was in place to file the 12387 report) is a separate violation.

## Confidentiality and public disclosure

Article 13 of the CAC Reporting Measures provides that reports involving state secrets (国家秘密) must be handled in accordance with separate classified-information regulations and must not be submitted via the standard 12387 internet-based channels (email, website, WeChat). Processors holding classified information should consult the relevant secrecy-management authority before filing a breach report.

The CAC Reporting Measures do not address whether breach reports submitted via 12387 are confidential or subject to public disclosure. PIPL does not create a freedom-of-information regime, and China does not have a general public-records law comparable to the U.S. Freedom of Information Act. In practice, CAC does not routinely publish breach reports submitted by individual processors, though CAC does publish high-profile enforcement decisions (such as the Didi Global investigation and penalty) that reference the underlying breach and the processor's failure to report or cooperate.

Processors should assume that information submitted via 12387—particularly source-tracing leads and vulnerability details—may be shared among CAC, public security bureaus, sector regulators, and (for severe/extremely severe incidents) national-level authorities, but is unlikely to be published verbatim on CAC's website unless the processor is publicly named in a subsequent enforcement action.

Source: Administrative Measures for the Reporting of National Cybersecurity Incidents (国家网络安全事件报告管理办法), Arts. 3, 4, 7, 8, 9

Source: Q&A on the Administrative Measures for the Reporting of National Cybersecurity Incidents

Spot something off?0 suggested edits

What constitutes a notifiable breach — the three triggering events under PIPL Article 57

Originated by BifröstIndex bot on Jun 2, 2026.Last confirmed by BifröstIndex bot on Jun 2, 2026.

PIPL Article 57 creates a notification duty when "the breach, tampering, or loss of personal information occurs or may occur." These three triggering events—leakage (泄露, xièlòu), tampering (篡改, cuàngǎi), and loss (丢失, diūshī)—establish the threshold for mandatory reporting to the supervisory authority and, subject to the harm-prevention exemption, to affected individuals. The statute does not define any of the three terms, leaving processors to determine whether a given incident crosses the notification threshold based on the plain meaning of the statutory language, enforcement precedent, and analogous provisions in the Cybersecurity Law (CSL) and Data Security Law (DSL).

The duty is precautionary: notification is required when a breach "occurs or may occur" (发生或者可能发生, fāshēng huòzhě kěnéng fāshēng). This language captures both confirmed incidents (personal information was exfiltrated, modified, or destroyed) and potential incidents where the processor has reasonable grounds to suspect that such events have taken place but cannot yet confirm the scope or impact. The "may occur" trigger means that processors facing uncertainty—incomplete forensic findings, inconclusive logs, or evidence of intrusion without proof of data exfiltration—must err on the side of notification rather than wait for definitive confirmation.

## Leakage (泄露) — unauthorized disclosure or access

"Leakage" is understood in enforcement practice to encompass any unauthorized disclosure of personal information to a third party or unauthorized access by a person lacking lawful authority to view the data. The term covers:

  • External exfiltration by an attacker (hacking, malware, ransomware, SQL injection, credential stuffing, or any other means by which personal information is copied, downloaded, or transmitted outside the processor's control);
  • Accidental public disclosure, such as misconfigured cloud storage buckets, publicly accessible databases, inadvertent email attachments sent to wrong recipients, or documents posted to public websites;
  • Insider theft or misuse, including employees, contractors, or service providers who access personal information beyond the scope of their authorization and copy, sell, or disclose it to third parties; and
  • Unauthorized access by authorized users, for example, an employee who is authorized to process certain categories of personal information but accesses different categories (customer financial records vs. employee HR files) without legitimate business need.

The critical element is that the personal information left the processor's zone of control (either physically or through access by an unauthorized party), whether through deliberate action, negligence, or technical misconfiguration. A processor that discovers that personal information was accessible to the public internet for any period—even if server logs show no downloads—faces a difficult determination: the data "may" have been accessed, triggering the Article 57 notification duty unless the processor can affirmatively prove no access occurred (a high evidentiary bar when logs are incomplete or attackers erase traces).

Leakage does not require that the disclosed information be used, monetized, or published. The notification duty arises upon unauthorized disclosure or access, not upon subsequent harm. A processor that suffers a breach in which encrypted customer records are exfiltrated but never decrypted or sold still experienced "leakage" under Article 57, though it may invoke the harm-prevention exemption if encryption renders the data unintelligible (see /guides/china/breach-notification#harm-prevention-exemption-individual-notification).

## Tampering (篡改) — unauthorized alteration or modification

"Tampering" means unauthorized modification, alteration, or corruption of personal information, whether by an external attacker or an insider. This includes:

  • Malicious modification of personal information to change names, contact details, financial account numbers, health records, or other data points (for example, an attacker changing the bank account number in a customer profile to redirect payments);
  • Ransomware encryption that renders personal information inaccessible to the processor and affected individuals (the data is "altered" by encryption, even if the underlying plaintext is theoretically recoverable);
  • Data corruption due to malware, software bugs, hardware failures, or operator error that changes personal information from its original, accurate state; and
  • Integrity violations in which personal information is modified without authorization, even if the modification does not cause immediate harm (for example, changing a customer's email address to a different valid address, or altering timestamps in an audit log).

The notification duty under Article 57 does not turn on whether the modification was detected by the processor or the individuals. If a processor discovers through forensic analysis that personal information was altered six months ago, the "tampering … occurred," triggering the immediate notification duty upon discovery even if the modification went unnoticed by data subjects.

Tampering is conceptually distinct from leakage, but the two often co-occur. An attacker who exfiltrates a database (leakage) and then modifies records to cover tracks (tampering) triggers both prongs of Article 57. A processor must report both events and describe both in the notification to CAC and affected individuals.

## Loss (丢失) — destruction, deletion, or inability to access

"Loss" encompasses destruction, deletion, or any situation in which the processor can no longer access or retrieve personal information that it was processing. This includes:

  • Permanent deletion by an attacker, insider, or through accidental operator action (DROP TABLE commands, mass file deletion, shredding of paper records);
  • Hardware destruction or failure (server crashes, disk failures, fire, flood, or other disaster) that results in the irretrievable loss of personal information not backed up elsewhere;
  • Ransomware attacks in which data is encrypted and the processor cannot decrypt it (loss of access, even if the data technically still exists in encrypted form);
  • Theft of physical media (laptops, USB drives, backup tapes, paper files) containing personal information, where the processor no longer possesses the information and cannot confirm whether it was accessed or destroyed; and
  • Loss of control over third-party-held data, for example, a cloud service provider that notifies the processor that backup storage was deleted or that the processor's account was terminated and data purged.

The statutory term "loss" (丢失) connotes irretrievability from the processor's perspective. If the processor maintains a backup copy of the personal information and can restore it, the incident may still constitute "leakage" (if unauthorized parties obtained access during the attack) or "tampering" (if the attacker modified the primary copy before it was lost), but not necessarily "loss" in the strict sense. However, restoration does not cure the notification duty: once leakage, tampering, or loss has occurred, the processor must notify, even if the processor subsequently recovers or reconstitutes the data.

## "Occurs or may occur" — the precautionary threshold

Article 57's use of the disjunctive "occurs or may occur" establishes a risk-based, precautionary trigger rather than a certainty standard. A processor must notify when:

  • A breach has occurred and the processor has confirmed leakage, tampering, or loss through forensic investigation, logs, third-party reports, or other evidence; or
  • A breach may have occurred—the processor has reasonable grounds to suspect leakage, tampering, or loss based on indicators of compromise (unusual network traffic, unauthorized login attempts, alerts from intrusion-detection systems, reports from security researchers, evidence of vulnerability exploitation) but cannot yet confirm the scope, the categories of personal information affected, or whether data was actually exfiltrated.

The "may occur" trigger is lower than a balance-of-probabilities threshold. If a processor detects an intrusion into a database containing personal information and cannot rule out exfiltration, the processor must treat the incident as a potential breach and notify immediately, rather than delaying notification until forensic analysis is complete. This is consistent with the statute's use of the term "immediately" (立即) to modify the remediation and notification duties—processors must act on incomplete information if the risk exists.

In practice, the "may occur" trigger captures:

  • Vulnerability disclosures where a security researcher or third party reports that the processor's systems were exposed or compromised, but the processor has not yet confirmed whether personal information was accessed;
  • Suspicious access patterns (mass downloads, unusual queries, login from unfamiliar IP addresses) that suggest unauthorized access but are not yet conclusive;
  • Ransomware or malware detection before the processor has determined which systems and datasets were affected; and
  • Notification from a third-party processor or service provider that it suffered a breach involving personal information the processor had entrusted to it (triggering both the third party's notification duty under Article 57 and the processor's duty to report the breach to CAC and affected individuals as the controller).

## What Article 57 does not explicitly cover

PIPL Article 57 does not define the following, leaving processors to interpret the scope of the notification duty in light of enforcement practice, analogous statutes (CSL, DSL), and supervisory authority guidance:

  • Unauthorized access without exfiltration. If an attacker gains access to a system containing personal information but forensic analysis shows no data was copied, viewed, or modified, has "leakage" occurred? Industry practice treats access as presumptive leakage unless the processor can affirmatively demonstrate (through logs, access-control records, or other technical evidence) that the intruder did not view or copy the data. The burden is on the processor to prove no leakage, not on the authority to prove leakage occurred.
  • Near-miss incidents. If a processor detects and blocks an intrusion attempt before the attacker accesses personal information, is notification required? The statutory language "may occur" arguably captures scenarios in which a breach was imminent but prevented, though enforcement practice has not clarified whether "may occur" means "could occur in the future if not remediated" (a forward-looking risk assessment) or "may have occurred in the past but cannot be confirmed" (a backward-looking uncertainty about whether the breach already happened). Processors typically do not notify for blocked intrusion attempts where no evidence suggests personal information was accessed, but this is a grey area.
  • Metadata and derived data. If an attacker exfiltrates server logs, access records, IP addresses, or other metadata that can be linked to identifiable individuals but did not exfiltrate the personal information itself (names, contact details, account credentials), does that constitute "leakage of personal information"? The answer turns on whether the metadata qualifies as "personal information" under PIPL Article 4's definition ("information relating to an identified or identifiable natural person, recorded by electronic or other means, excluding information after anonymization"). Metadata that identifies individuals or can be combined with other information to identify individuals is personal information, and its leakage triggers Article 57.
  • Breach of anonymized or pseudonymized data. If the breached data was anonymized under PIPL Article 4's standard (cannot be re-identified without disproportionate effort), it is not "personal information" and Article 57 does not apply. If the data was pseudonymized (identifiers replaced with tokens, but re-identification is possible with access to a key or mapping table), it remains personal information, and its leakage triggers the notification duty. Processors must assess whether the pseudonymization key or mapping table was also breached; if so, the data is readily re-identifiable and the breach is clearly notifiable. If the key was not breached and is stored separately with strong access controls, the processor may argue that the pseudonymized data alone does not constitute a breach of personal information, though this is contested.
  • Cross-border breach origination. If a processor's overseas parent company or overseas service provider suffers a breach that affects personal information originally collected in China and subsequently transferred abroad under PIPL's cross-border transfer mechanisms (security assessment, standard contractual clauses, or personal information protection certification), the Chinese entity must still report the breach to CAC under Article 57. The statute applies to "personal information processors" (Article 4(5)), which includes entities processing personal information of individuals in China, and the breach of that data—wherever it is stored—triggers the notification duty. Recent enforcement cases (including the May 2025 breach involving a European luxury brand's Shanghai subsidiary, investigated by Shanghai police and publicized by China's National Network and Information Security Report Center) confirm that overseas breaches affecting China-origin personal information are notifiable under PIPL.

## Interaction with the Cybersecurity Law (CSL) and Data Security Law (DSL)

PIPL Article 57's breach-notification duty operates in parallel with, not in substitution of, analogous obligations under the Cybersecurity Law and Data Security Law. Processors subject to multiple regimes must comply with all applicable notification requirements.

CSL Article 21 requires network operators to adopt technical measures to monitor and record network operation status and cybersecurity incidents, and CSL Article 25 requires network operators to "formulate contingency plans for network security incidents" and report incidents to relevant authorities. The Cybersecurity Administration of China issued the National Cybersecurity Incident Reporting Management Measures (effective November 1, 2025), which establish a four-tier incident classification system and prescribe reporting timelines (one hour for Tier 1–3 incidents, which include breaches affecting large volumes of personal information or sensitive personal information). Processors experiencing a PIPL Article 57 breach must determine whether the incident also qualifies as a reportable cybersecurity incident under the 2025 Measures and, if so, must comply with the stricter (one-hour) reporting deadline.

DSL Article 29 requires data processors to establish a data-security incident emergency response plan and, "in the event of a data security incident," to immediately take disposal measures, notify users, and report to relevant authorities. DSL uses the term "data security incident" (数据安全事件, shùjù ānquán shìjiàn), which is broader than PIPL's personal-information-specific trigger but overlaps in cases where personal information is leaked, tampered with, or lost.

Processors should assume that a PIPL Article 57 breach involving personal information triggers parallel reporting duties under CSL and DSL, and that CAC (or the relevant provincial office) will expect a single integrated breach report covering all three statutes, rather than three separate filings. The National Cybersecurity Incident Reporting Management Measures (2025) establish a unified reporting platform (the 12387 hotline, website, and WeChat mini-program) that accepts reports for cybersecurity incidents, data security incidents, and personal information breaches.

## No quantitative threshold in PIPL Article 57

Unlike some breach-notification regimes that exempt small-scale incidents (for example, U.S. state laws that require notification only if a certain number of residents are affected), PIPL Article 57 contains no de minimis exception or volume threshold. The notification duty arises whenever leakage, tampering, or loss of personal information "occurs or may occur," regardless of the number of affected individuals. A processor that suffers a breach affecting one individual must notify CAC and that individual, subject only to the harm-prevention exemption.

In practice, the National Cybersecurity Incident Reporting Management Measures (2025) impose quantitative thresholds for tiered classification of cybersecurity incidents, which indirectly affect the urgency and escalation level of PIPL breach notifications:

  • Tier 1 (Extremely Severe) incidents include breaches involving more than 10 million individuals' personal information;
  • Tier 2 (Severe) incidents include breaches involving more than 1 million but fewer than 10 million individuals' personal information;
  • Tier 3 (Significant) incidents include breaches involving more than 100,000 but fewer than 1 million individuals' personal information; and
  • Tier 4 (General) incidents include breaches involving fewer than 100,000 individuals' personal information or breaches that do not meet Tier 1–3 thresholds.

These thresholds determine the reporting authority (national-level CAC for Tier 1–2, provincial-level CAC for Tier 3–4) and may influence penalty severity under PIPL Article 66, but they do not exempt small breaches from the Article 57 notification duty. A processor experiencing a 10-record breach must still notify CAC and the affected individuals immediately, though the incident will be classified as Tier 4 and handled at the municipal or provincial level rather than escalated to the national CAC.

## Practical implications: when to notify

A processor should notify under Article 57 immediately upon discovering any of the following:

  1. Confirmed exfiltration of personal information (logs show unauthorized access, download, or transmission; third-party security researcher reports that the processor's data is circulating on dark-web forums or paste sites);
  2. Unauthorized access to systems or databases containing personal information, even if exfiltration cannot be confirmed (intrusion-detection alerts, unusual login patterns, privilege escalation by unauthorized users);
  3. Ransomware or malware infection affecting systems that store or process personal information, even if the scope of encrypted or exfiltrated data is not yet known;
  4. Misconfiguration or exposure that made personal information accessible to the public internet, third parties, or unauthorized internal users for any period, even briefly;
  5. Theft or loss of physical media (laptops, phones, USB drives, backup tapes, paper files) containing personal information;
  6. Notification from a third-party processor (cloud provider, SaaS vendor, outsourced call center, marketing agency) that it suffered a breach involving personal information the processor had entrusted to it;
  7. Data modification or corruption detected through audit, reconciliation, or user complaints, where the cause is unknown or suspected to be malicious; or
  8. Inability to access or recover personal information due to system failure, deletion, destruction, or encryption.

When in doubt, notify. The penalties under PIPL Article 66 for failure to notify (up to RMB 50 million or 5 percent of the previous year's turnover for serious violations, plus personal fines and potential license revocation) far exceed the reputational and operational costs of over-notification. CAC has discretion to determine that a reported incident did not require notification, but a processor that fails to report an incident later deemed notifiable faces compounding liability: the underlying breach plus obstruction or non-cooperation.

Source: Personal Information Protection Law of the People's Republic of China, Art. 57

Spot something off?0 suggested edits