Responding to a Personal Data Breach: Scoping, Reporting Deadlines and Notifying Individuals

Scope first: what data, whose, how many records, is it still leaking?

Almost everything you will report and notify rests on the scope. The Ministry of Digital Affairs (MODA) reporting form, for example, asks for when the incident happened, the type of infringement (theft, leak, alteration, damage, loss), the approximate number of records split into general and special-category data, the cause and a summary, the damage, the likely consequences, the response measures planned, and when and how data subjects will be notified^[2]. Collect along these fields from the start and you can reuse them for every report and notice.

• Which fields: name, phone, address, email, date of birth, national ID number, order details, password hashes, payment data. Each carries different risks and calls for different actions by the people affected. Medical records, medical treatment, genetic data, sex life, health examinations and criminal records are special categories under PDPA Article 6 and must be flagged separately^[3].
• Whose data: customers, members, employees, job applicants, or data you host on a client's behalf.
• How many records, how many people: records are not people; one person may have several records, so deduplicate first, then count by field. Also check whether you hold contact details for these people, because that decides whether you can notify them individually^[4].
• Was the data protected: confirm with your forensic team whether measures such as encryption were enabled at the time^[4], and whether the keys leaked too.
• Time window: when it started, when it was discovered, and whether it is still going on.
• Is it still leaking: public storage, API keys or access tokens that still work, and accounts the attacker can still sign in to must all be confirmed closed.

The numbers will change as the investigation goes on. Internally, label every figure "confirmed" or "estimated"; externally, state the confirmed minimum first and say when you will update. The MODA regulations also allow report information to be provided in phases^[2].

Is it your data, or data you hold for someone else?

If you are a systems integrator, hosting provider or marketing contractor, what leaked may be data a client entrusted to you. Article 8 of the PDPA Enforcement Rules requires the entrusting party to supervise its contractor, including what the contractor must report to it, and what remedial measures it must take, when the contractor breaches the PDPA^[5]. The ACS also reminds hosting and platform providers to notify their partners and brands promptly as their contracts require^[1]. Conversely, if the leak happened at your supplier, the people affected will still come to you, so use your contract to get a timeline and a list of affected records from the supplier. See also Supply chain attacks.

Contain and preserve evidence: close the door, then clean up

• Close the leak path first: set misconfigured public storage, databases or sharing links back to private, and disable the abused API or feature. The US Federal Trade Commission (FTC) advises taking affected equipment offline immediately, but not turning any machines off until the forensic experts arrive^[4].
• Replace credentials that may have leaked: the ACS advises that after a compromise you reissue or revoke every key, password and access token that may have leaked, move to short-lived credentials, and check all similar systems and internal back-office tools^[1].
• Preserve logs before patching: the ACS stresses that system logs must be preserved before patching and that a professional forensic team should confirm no backdoor remains^[1]; the FTC likewise says not to destroy forensic evidence during investigation and remediation^[4].
• Deal with data already exposed: if the data was posted on your own website, remove it immediately and contact search engines so they do not keep cached copies; also search for copies on other sites and ask them to remove them^[4].
• Interview the people who found it and keep records: talk to whoever discovered the breach and anyone else who may know about it, make sure customer service knows where to forward relevant information, and document the investigation^[4].
• Check supplier access: if service providers were involved, review what personal data they can access, whether their access needs to change, and verify that the fixes they claim have actually been made^[4].

Record the facts, the impact and what you did from the very first minute. The 2025 amendments discussed in the next section require these to be recorded and the records kept for inspection by the competent authority^[6]; that provision is not in force yet, but doing it now will help whenever you have to explain yourself to any authority.

Legal obligations: which version of the PDPA applies now

Current law: Article 12, notifying data subjects

The version in force is the one last amended and promulgated on 31 May 2023. Article 12 provides that when a government or non-government agency violates the PDPA and personal data is consequently stolen, leaked, altered or otherwise infringed, it must notify the data subjects in an appropriate manner after investigating the facts^[3]. Article 22 of the Enforcement Rules (amended 2 March 2016) explains that an "appropriate manner" means promptly, orally or in writing, by phone, text message, email, fax, electronic document or any other means through which the data subject can learn of it; where the cost would be excessive, the agency may, taking into account technical feasibility and the data subjects' privacy, use the internet, the news media or another appropriate public method instead; and the notice must include the facts of the infringement and the response measures already taken^[5].

The current article is triggered when a violation of the PDPA leads to the infringement. Early in an incident it is hard to be sure you met every security obligation, so rather than arguing over the trigger, treat notification as the default; the ACS also advises that companies can send a first notice once they have an initial grasp of who is affected, without waiting for the investigation to finish^[1].

On penalties, a violation of Article 12 leads to an order from the central industry regulator or the municipal or county (city) government to correct it within a deadline, and failing that, a fine of NT$20,000 to NT$200,000 for each further failure. Failing to take the appropriate security measures required by Article 27(1), or failing to draw up a security plan when designated to, is fined NT$20,000 to NT$2 million with an order to correct within a deadline, then NT$150,000 to NT$15 million for each further failure; serious cases are fined NT$150,000 to NT$15 million directly (Article 48)^[3]. When a company is fined, its representative, manager or other person with authority to represent it receives a fine of the same amount unless they can prove they did their best to prevent the violation (Article 50)^[3].

The current PDPA itself contains no provision on reporting to an authority. Reporting obligations come from the security regulations that each central industry regulator issues under Article 27(3)^[3]; the "Who must report" section below gives some examples.

The 2025 amendments: promulgated, not yet in force

Amendments to Article 12 and other provisions of the PDPA were promulgated on 11 November 2025, with the effective date to be set by the Executive Yuan. The national Laws & Regulations Database (data compiled up to 6 November 2026) still states that some or all provisions are not yet in force and that the final effective date is "undetermined"; Article 1-1, added in 2023 to make the Personal Data Protection Commission (PDPC) the competent authority, likewise has no effective date yet^[6]. The PDPC Preparatory Office's Q&A on the amendments explains that the PDPC needs its own organization act as its legal basis, and that the Executive Yuan will decide the effective date of the amended law after that act has been passed; until then, the PDPA currently in force continues to apply^[7].

Key points of the amendments^[6]:

• Notifying data subjects: an agency that becomes aware that personal data it holds has been stolen, altered, damaged, lost or leaked must notify the data subjects, no longer conditional on a violation of the Act (Article 12(1)).
• Reporting to the authority: where the incident meets a defined reporting threshold, a non-government agency must report it to the competent authority, which passes it on to the industry regulator (Article 12(2)).
• Response and records: the agency must take immediate and effective response measures to keep the incident from spreading, and record the facts, the impact and the measures taken and keep those records (Article 12(3)); the content, method, deadlines and threshold for notification and reporting are left to regulations issued by the competent authority (Article 12(4)).
• Penalties: violating the notification duty leads first to an order to correct within a deadline, then a fine of NT$20,000 to NT$200,000 for each further failure; violating the reporting, response or record-keeping rules is fined NT$20,000 to NT$200,000 directly, with an order to correct within a deadline (Article 48(1)(iii) and 48(2))^[7].

The draft implementing regulations: 72 hours

On 22 January 2026 the PDPC Preparatory Office published for comment the draft Regulations on Notification, Reporting and Response for Personal Data Incidents^[8]. They will only bind anyone once the amended Act takes effect and the regulations are formally issued, and the text may still change, but the direction is clear:

• Notify data subjects individually, in an appropriate manner, within 72 hours of becoming aware of the incident. If there are no contact details for them, if the data is not special-category data and is protected so that unauthorized people cannot read it, or if individual notice would cost so much that it would affect operations, the agency may instead publish the notice through the internet, the news media or similar means for at least 30 consecutive days.
• The notice must cover when the incident happened and what happened, the categories of personal data affected, the response measures taken, and the agency's contact details and channels for redress or inquiries.
• Incidents involving special-category data, involving an information system that holds 10,000 or more personal data records, or affecting 100 or more records must be reported to the competent authority within 72 hours of becoming aware of them.
• A contractor's awareness of an incident counts as awareness by the entrusting agency, and the contractor must notify the entrusting agency immediately; records must be kept for at least five years from the day after the agency became aware.

Who must report, and within how many hours: sector regulations and GDPR

Until the amendments take effect, whether and how quickly you must report to an authority depends on the security regulations issued by your central industry regulator, and their thresholds and deadlines differ:

• Digital-economy industries (MODA, issued and in force 12 October 2023): covers online retail of goods, software publishing, computer programming and consultancy, data processing and hosting, other information services, and third-party payment services. When a personal data security incident will endanger normal operations or the rights of a large number of data subjects, it must be reported to MODA using the form in Annex 2 within 72 hours of becoming aware of it, or reported to the municipal or county (city) government with a copy to MODA; if the deadline cannot be met or not all the information is available at once, the business must give reasons for the delay or provide it in phases (Article 8)^[2].
• Manufacturing and technical service industries (Ministry of Economic Affairs, amended 30 October 2023): businesses holding 5,000 or more consumer records must draw up a security plan; consumer data incidents that will endanger normal operations or the rights of a large number of data subjects must likewise be reported within 72 hours of becoming aware of them, to the Ministry of Economic Affairs or to the local government with a copy to the Ministry (Articles 2 and 6)^[9].
• Telecommunications, broadcasting and other communications businesses (National Communications Commission, amended 1 July 2022): a major personal data incident, such as one likely to endanger normal operations or cause serious harm to data subjects' rights, must be reported to the NCC within one hour of becoming aware of it, followed by a report using the annexed form within 72 hours (Article 4)^[10].

If your industry is not listed here, check whether your own central industry regulator has issued similar regulations. Even where you have no duty to report, the ACS advises reporting security incidents to TWCERT/CC to get help with scoping, analyzing malware samples and finding experts^[1]. Two other common parallel obligations have their own articles: listed companies must assess whether to publish a material information announcement, see Cyber incident disclosure by Taiwan-listed companies; and specific non-government agencies under the Cyber Security Management Act have separate incident reporting deadlines, see Taiwan's Cyber Security Management Act.

Users in the EU: GDPR Articles 33 and 34

A Taiwanese company with no establishment in the EU is still subject to the GDPR when it processes the personal data of people in the EU in connection with offering them goods or services, or monitoring their behavior within the EU (Article 3(2))^[11]. After becoming aware of a personal data breach, the controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a late notification must give reasons for the delay, information may be provided in phases, and a processor must notify the controller without undue delay (Article 33)^[11]. Where the breach is likely to result in a high risk, the controller must also tell the data subjects without undue delay, in clear and plain language; exceptions include data rendered unintelligible by measures such as encryption, or cases where individual notice would involve disproportionate effort (a public communication that is equally effective is used instead) (Article 34)^[11].

Notifying the people affected: what to say and how

The current Enforcement Rules require the facts of the infringement and the response measures taken^[5]; the draft regulations add the categories of data and contact and redress channels^[8]; the GDPR requires clear and plain language plus a contact point, the likely consequences and the measures taken^[11]. The FTC's model notice follows a similar structure^[4], so you can write it in this order:

1. What happened: when it happened, when you found out, and roughly how it happened (as far as the investigation allows).
2. What information was involved: list the exposed fields one by one; you may also name fields confirmed not to be exposed (for example full card numbers or passwords), but only those already confirmed.
3. What we are doing: vulnerabilities closed, credentials reissued, authorities notified, and support offered.
4. What you can do: concrete steps matched to the type of data exposed^[4], such as changing passwords reused on other sites, turning on multi-factor authentication, and watching for calls from people posing as customer service.
5. How we will contact you from now on: the FTC suggests explaining how you will contact people in future (for example by letter only, never by phone) so they can spot breach-related scams^[4]; the ACS also suggests spelling out what the company will never do, such as asking people to use an ATM or online banking, or to accept a refund via LINE^[1].
6. Contact points and where updates will appear: a hotline, an email address, a fixed web page and the time of the next update; also remind people that they can check suspicious calls with the 165 anti-fraud hotline^[1].

Notify individually by text message, email, phone and similar means by default; under the current Enforcement Rules, public methods such as the internet or the news media are only allowed when the cost would be excessive^[5]. In what you publish, also avoid sharing information that could put people at further risk^[4].

Common mistakes

• Announcing wrong numbers too early: rushing out an unconfirmed record count and then revising it again and again. The FTC warns against making misleading statements about a breach and against withholding key details that would help people protect themselves^[4]; it is better to say "at least X records confirmed so far, investigation ongoing, next update on a given date".
• Notifying too late: waiting for the full forensic report while people are already getting scam calls. The Enforcement Rules require notice to be given "promptly"^[5]; if a report to the regulator misses the deadline in your sector regulations, attach the reasons for the delay^[2].
• Blaming users and giving no concrete steps: writing only "please stay alert" without explaining what happened at the company, what it has done, and what people should actually do; or claiming "our systems were not breached" before the facts are known.
• A notice that looks like phishing: including sign-in links, asking people to reply with their details, or sending from an unfamiliar domain, so recipients cannot tell real from fake. For the scams involved, see Phishing and business email compromise.
• Inconsistent messages across channels: customer service, press releases, material information announcements and regulatory reports giving different numbers. The FTC recommends designating a single point person to release information^[4].

Action checklist

1. Record when you became "aware", who found the issue and what they saw, and start a timeline; sector deadlines mostly run from awareness.
2. Close the leak path and reissue or revoke keys, passwords and tokens that may have leaked; preserve logs before patching, and take affected hosts off the network without turning them off.
3. Build a scope table by field, type of data subject, records and people, time window and encryption status, labeling every number "confirmed" or "estimated".
4. Check whether the data was processed on a client's behalf: if so, notify the client as the contract requires; if the leak is at a supplier, demand a timeline and list of affected records.
5. Identify your central industry regulator and its security regulations, confirm the reporting threshold, deadline (one hour or 72 hours) and form, and record the reasons for any delay.
6. Confirm parallel obligations with legal: material information, Cyber Security Management Act reporting, GDPR, client contracts and insurance.
7. Notify data subjects promptly under current PDPA Article 12 and Enforcement Rules Article 22, covering the facts, the fields involved, measures taken, what people can do, how you will contact them and who to call; at the same time prepare customer service Q&A and a fixed notice page so numbers and wording stay consistent.
8. Track the effective date of the PDPA amendments and the final implementing regulations, and when they arrive, build 72-hour notification and reporting into your response procedures; if you need outside forensic or response support, see our incident response service.
9. Afterwards, minimize personal data: delete unnecessary fields and expired records, store sensitive data separately and encrypted, and shrink the impact of the next incident.