Seeing further, standing on giants

72 Hours to Report a Data Breach: What Taiwan's PDPA Amendments Mean Before You Commission a System

Member profiles on a website, order histories in an app, phone numbers and birthdays in a booking system: all of it is personal data. Taiwan's Personal Data Protection Act was amended and promulgated in November 2025. Once it takes effect, private-sector organizations that suffer a theft or leak of personal data will have to notify the people affected and report to the regulator, and draft regulations published early this year set the deadline at 72 hours from discovery. The effective date is still waiting on the Executive Yuan, but the direction is clear: data breach notification tests not only a company's response process, but how its systems were designed in the first place. This article summarizes the new rules and four things to clarify before commissioning a website, app or internal system.

What the Amended Act Adds for Businesses

A compliance manager at her desk studying a thick regulation document with a highlighter

According to law firm summaries, the amendments promulgated on November 11, 2025 give the new Personal Data Protection Commission (PDPC) the supervisory powers it needs, and require private-sector organizations that learn of a personal data incident to notify data subjects and report to the competent authority. The Executive Yuan will set the effective date, and private organizations will have a transition period to adjust.

In January 2026, the PDPC preparatory office published draft amendments to the enforcement rules and three draft regulations. Two of them directly affect businesses:

  • Regulations on Security Maintenance of Personal Data Files: common measures for all public and private organizations, including regularly taking stock of the personal data held and defining the scope of management, setting up reporting and response mechanisms, personnel management and training, security for equipment and information systems, and deletion or destruction when business ends.
  • Regulations on Notification, Reporting and Response for Personal Data Incidents: the draft requires individual notice to data subjects within 72 hours of learning of an incident. If the incident involves sensitive data, the affected system holds 10,000 or more records, or 100 or more records are affected, it must also be reported to the regulator within 72 hours.

One more provision in the draft deserves attention from companies that outsource development: when a contractor learns of an incident within the scope of its work, the commissioning company is deemed to have learned of it too, and the contractor must notify the company immediately. In other words, your 72 hours start the moment your developer or hosting provider spots the problem.

Is 72 Hours Enough? Data Breach Notification Is a Test of System Design

Two engineers working late, reviewing access logs on screen to trace a data leak

When an incident happens, a company has three days to answer several questions. What happened? Which people, which fields and how many records are affected? How did the data get out? Has the leak been stopped?

Whether you can answer depends almost entirely on how the system was designed before launch. Without access logs, you cannot know who viewed the data. If personal data is scattered across spreadsheets, form tools, backups and test environments, you cannot describe the scope. If no one knows what each field stores, you cannot write the notice to data subjects. Most of the 72 hours of data breach notification is not spent writing an announcement. It is spent digging through data.

Four Things to Ask Before Commissioning Development

A developer showing a client an admin table of customer records with sensitive fields masked

1. What personal data will the system collect, and where will it live?

Ask the developer to produce a data inventory during the specification stage: what each field is, why it is collected, which database or cloud service stores it, and whether it is shared with third parties such as payment, email or analytics tools. Not collecting data you do not need is the cheapest security measure there is.

2. Who can see the data, and is access logged?

Admin permissions should be role-based. Customer service may not need to see a full national ID number or birthday. Administrator logins, exports and bulk queries should all leave searchable access logs, kept for a reasonable period.

3. If something goes wrong, can you find the scope?

During acceptance testing, ask the developer to run a drill: "Suppose this account was compromised. How quickly can you tell me whose data it viewed or exported, and when?" If they cannot answer, you will not be able to answer the regulator either.

4. Put incident notice and data deletion in the contract

State in the contract how quickly the development or maintenance vendor must notify you of a suspected incident and what information they must provide, and how they will delete the data they hold, including test data and backups, when the project or relationship ends, with proof of deletion.

Related reading: "It Runs, but Is It Safe? Four Security Questions to Ask Before Commissioning Custom Software."

Small Businesses Need Not Do Everything at Once, but Should Start

A bakery owner reviewing customer membership records on a tablet at the shop counter

Under the draft, the fuller enhanced measures, such as a security maintenance plan, designated staff and annual risk assessments and audits, mainly apply to public agencies and to large private organizations, meaning companies that are not SMEs and hold 10,000 or more personal data records. Most small and medium businesses will need the common measures.

But two of those common measures, taking stock of the personal data held and setting up incident response, depend on the systems themselves. A practical order is: first inventory the personal data in your existing systems and delete what you do not need; then add access logs and role-based permissions to core systems such as membership, orders and bookings; finally, write a one-page incident procedure so everyone knows who to call first.

Note that this article summarizes publicly available information on the amendments and drafts. Actual obligations depend on the final text and regulations once they take effect, and specific cases warrant professional legal advice.

Conclusion: Build Compliance Into the System, Not Into Paperwork Later

A business owner and a developer shaking hands after a project review

The most expensive way to protect personal data is to go looking for it after something goes wrong. Writing a data inventory, permissions, logging and deletion into your requirements when you commission a system often costs only a few lines in the specification. Technology keeps every record in order. People make the right, honest call when it matters.

TitApeX helps businesses plan and build websites, apps and internal systems, and can design data protection and incident response in from the requirements stage. Take a look at our services or get in touch.

References

Leave a Reply

Your email address will not be published. Required fields are marked *