Collecting Customer Data Under Taiwan's PDPA
8 min read
Plenty of site owners assume the law is somebody else's problem: we do not sell data, so it does not apply to us. But the moment your website lets someone type in an email address, a phone number, a postal address or a national ID number, you are a collector in the eyes of the law and you answer for that data. What makes Taiwan's Personal Data Protection Act, usually shortened to PDPA, uncomfortable is that it puts the question of whether you took care into the open, and after a leak the site owner is the first one asked. This piece turns those duties into things you can check today. Two caveats before starting. This describes Taiwan's PDPA. If you read this from Europe, the UK or anywhere else, the ideas will feel familiar, because the PDPA rests on much the same concepts as the GDPR, but the thresholds, the timings and the penalties are not the same and your own regime is what binds you. And this is general information, not legal advice.
1. What counts as personal data is wider than you think
The law protects data that can identify a specific person directly or indirectly, not just a national ID number. Names, email addresses, mobile numbers, postal addresses, IP addresses, order histories and browsing preferences all count once the combination points at somebody.
Medical records, genetic data, sex life, health examination results and criminal records are special categories, which as a rule may not be collected at all without a strict exception. If a form on your site asks for medical history or health status, ask whether you truly need it. If the answer is no, delete the field. That is far less work than protecting the data afterwards.
Two beliefs need clearing out first. Encrypting or pseudonymising data does not take it out of scope: if it can still be traced back to a specific person, it is still regulated. And publicly available data is not free to use however you like, because the use still has to match the purpose you declared.
So step one is an inventory. Open the database and every form, and list the fields you actually store, including back-end logs and backup files. Do not forget third-party tools. Form plugins, newsletter services and helpdesk systems all hold personal data on your behalf, and that sits inside your responsibility.
2. Collection needs a specific purpose, and you have to tell people
You cannot collect personal data for no reason. There has to be a stated specific purpose, such as member administration, order processing or marketing. And when you collect from the person directly, Article 8 of Taiwan's PDPA puts an active duty on you to tell them certain things. In practice this is what your privacy policy and the note beside the form have to cover.
Do not paste the text of the statute in and call it done. If the person filling in the form cannot understand it, you have not told them anything. Write it in language they use, covering the six points below one at a time.
The six things Article 8 requires you to state
- Who you are. The name of the collecting entity, meaning your full registered company or trading name.
- What it is for. The specific purpose, stated concretely, for example "member services and order notifications" rather than "business needs".
- Which categories you collect. Name, contact details, transaction records and so on, listed honestly.
- How long, where, to whom and how it is used. Including whether it goes to third parties and whether it leaves the country.
- What rights the person has and how to use them. Access, correction, deletion, and who to contact.
- What happens if they do not provide it. For example that registration cannot complete or the order cannot ship, so the person can decide for themselves.
3. Collection, processing and use are three stages, all bound by data minimisation
The law splits the data lifecycle into collection, processing and use, and every stage has to match the specific purpose you declared. Using data outside that purpose, say taking an order list and running unrelated advertising off it, generally needs separate consent or another legal basis.
The principle running through all three stages is to collect the minimum. Go field by field and ask whether this purpose really needs it. If not, take it out. A delivery address is needed to ship goods and identity details are needed to book a medical appointment, so neither has to be mandatory at plain registration.
The other half is not hoarding. Set a retention period for each category, and delete, de-identify or archive once the purpose is gone or the period is up. "We might need it later" is not a retention reason. Data kept on that basis only widens the damage when there is a leak.
4. People have rights: access, correction, deletion, stopping use
The data belongs to the person, not to you. They can ask to see or review what you hold, ask for it to be completed or corrected, ask for deletion, and ask you to stop collecting, processing or using it. These rights cannot be signed away in advance, so a clause in your terms saying the user waives them has no effect.
What you need is not the statute memorised. It is a process that actually runs. The table converts each right into a capability your back office has to have.
| What a person can ask for | What you need in place |
|---|---|
| Access, review, a copy | A way to find everything held under one person's name, including the copy inside third-party tools |
| Completion or correction | Either editable in the admin area, or somebody able to make the change and log it |
| Deletion | Deletion that actually works, backups and mailing lists included. Where the law requires retention, such as invoices and transaction records, you have to be able to explain why |
| Stopping collection, processing or use | The ability to switch marketing off for one account, rather than only being able to delete the account entirely |
Set up one point of contact for these requests, an email address or a form, and state it plainly in the privacy policy. Agree an internal response time and the steps to follow so requests do not vanish. When a member deletes their own account, spell out what gets deleted and what has to be kept because the law requires it.
5. The security duty: the law requires appropriate measures
This is the most overlooked part and the most concrete. Article 27 requires anyone holding personal data to take appropriate security measures to prevent it being stolen, altered, damaged, lost or disclosed. "Appropriate" has no single standard, because it is judged against your size, how sensitive the data is, and what is technically feasible. Doing nothing at all definitely fails.
In other words, this article turns security from something you get to later into a legal duty. The items below are within reach of most websites, and they are what you can point to in an audit or after an incident.
Six basics for the security duty
- HTTPS everywhere, passwords always hashed. Encrypt the traffic and keep no plaintext passwords in the database.
- Keep the admin software and the host updated. Disable default accounts, use strong passwords, and turn on two-factor authentication.
- Control access by role. Give each person the least access their job needs instead of making everybody an administrator.
- Run vulnerability scans and host health checks regularly. Catch plugin flaws, misconfiguration and reachable entry points early.
- Keep the access and activity logs you need. After an incident, these are what tell you the scope and the cause.
- Back up off-site and test the restore. After ransomware or an accidental deletion, this is the only thing that gets the data back.
6. After a leak: tell the people affected once you know
If data does leak, Article 12 requires you to notify the people affected by an appropriate means once the facts are established. The notice should tell them what happened, which data was involved, what the likely impact is, and what they can do about it, such as changing a password quickly or watching for suspicious calls.
The worst response in the moment is concealment or delay. It does not stop the bleeding and it makes the later accounting for it worse. Write the incident process down in advance: who decides, how affected systems get isolated, how evidence is preserved. Work out ahead of time which situations also require notifying the authorities, for which the notices published by the Personal Data Protection Commission are the place to start.
Keep records throughout. When it was found, what was done, when each party was told. Those records do more for you afterwards than any explanation.
7. Outsourcing the build or the hosting does not move the responsibility
Handing the website to a developer, or the servers to a hosting company, does not send the data protection duty out with it. Under the PDPA the party commissioning the work, meaning you, has a duty to supervise the party doing it. If they cause the incident, you can still be the one answering for it.
So this lives in the contract and in the supervision, not in a verbal assurance. The contract has to set out the data protection, confidentiality and security obligations and their scope, and agree how quickly the supplier tells you about an incident and what help they will give. Confirm they can actually meet it before signing, rather than treating the signature as the end of the matter.
Three things still need attention afterwards. Confirm the developer's or host's access rights, backup method and deletion practice, so you know where your data physically sits. Review whether they are doing what was agreed, and keep a record of the reviews, because that record is your evidence of having supervised. And settle in advance how data gets returned or destroyed when the relationship ends.
8. What goes in a privacy policy, and what happens if you get it wrong
A privacy policy is not decoration. It is the formal document through which you discharge the notification duty and disclose how you handle data, and after an incident it is the basis for showing you took that duty seriously. It has to cover the six Article 8 points, plus how you use cookies and third-party tracking tools such as analytics and advertising.
Put it where people can find it, which for most sites is the footer. Update the revision date whenever you change it, so the document reads as maintained rather than abandoned. Above all, the back office has to be able to do what the policy promises. Writing "you may request deletion" with nobody handling the requests is worse than not writing it.
As for consequences, the authority can generally order correction within a set period and impose repeated penalties if that period passes without it. People who suffer harm can claim compensation. Serious cases, or ones involving unlawful intent, carry criminal liability as well. Actual enforcement follows the rules in force and the authority's judgement, and a serious matter is one to take to a lawyer. Bear in mind that these are Taiwan's penalties: under the GDPR or another regime, both the thresholds and the sanctions look different.
The duties come down to four sentences: collect only what you should, say clearly what you will do with it, protect it properly, and tell people honestly and fix things when it goes wrong. None of that is hard to understand. The hard part is doing it. Work through the checklists above once and the weakest link usually turns out to be the security section, which happens to be the part technology can help with. A reminder, again: this is general information about Taiwan's PDPA rather than legal advice, and the data protection law that applies where you are will read differently.
Common questions
- Does a website have to have a privacy policy?
- If your site collects personal data at all, and member accounts, orders, forms and newsletters all count, then in practice you should publish one to discharge the notification duty under Taiwan's PDPA and to let people know how their data is handled. It is also what you point to after an incident to show you took the duty seriously. It should cover the collection purpose, the categories of data, the scope of use and the rights people have, sit somewhere easy to find, and be written in plain language.
- Do we always have to notify people after a leak?
- Under the PDPA, where personal data is stolen, disclosed, altered or otherwise compromised, the holder must notify the people affected by an appropriate means once the facts are established, so they can protect themselves. Concealing or delaying usually makes the later accounting for it worse. Prepare an incident process in advance and work out whether the authority has to be notified as well. Take serious cases to a lawyer.
- If we outsource the build or the hosting, whose responsibility is the data?
- Outsourcing does not transfer it. Under the PDPA the commissioning party has a duty to supervise the supplier, and if the supplier causes the incident the commissioning party can still be answerable. Put the data protection and security obligations and the incident notification timing in the contract, review whether they are being followed, and keep the records of those reviews. The technical side of that checking is something a specialist can take on.