What Actually Goes in a Privacy Policy
6 min read
Most privacy policies arrive the same way. Somebody finds an online generator, types in a company name, ticks a few boxes, pastes the output onto the site, and never looks at it again. The generator is not the problem. The problem is that what it produces describes a generic website rather than yours. It does not know which fields your forms collect, which outside services you hand data to, or whether your admin panel can actually delete one member record. This is about checking whether that document matches what you really do. The rules cited here are Taiwan's Personal Data Protection Act, usually shortened to PDPA. If you are elsewhere the ideas carry over, but your own regime is what binds you. This is general information, not legal advice.
1. The problem is not that generators write too little
What comes out of a generator is usually long and thorough, thorough enough to look like a professional document. Thorough and accurate are different things. The only input a generator has is the boxes you ticked, and it assembles pre-written paragraphs from those. What it assembles describes a standard site doing standard things.
Two results are common. One is a policy covering things you do not have, such as loyalty points, marketing push notifications or a mobile app. The other is worse: a policy promising things you cannot do, such as letting a person demand deletion of all their data when your admin panel can only deactivate an account.
2. A usable policy has to match three facts
Set the statute aside for a moment. Whether a policy is usable comes down to whether it honestly describes three things: what you actually collect, who else receives it, and how long you keep it. The answers are not in your memory. They are in your admin panel and in the settings of every outside service you use.
What you collect is the one people underestimate. Most owners think only of the visible form fields, but a site also records things in the background: visitor IP addresses, which pages were viewed, device details captured at checkout, support conversations, uploaded files. All of that is data too, and all of it has to be accounted for.
Who receives it is usually a longer list than expected. Analytics, ad tracking, the newsletter platform, live chat, payments, SMS notifications, hosted form services: each one holds a share of it. You are not selling data, but you are certainly handing it over, and that is what a policy has to describe.
| Wording you see in a generated policy | What to go and confirm |
|---|---|
| This site collects your personal data | Which fields exactly. Lay out every form and every background log and list them |
| May be shared with third-party partners | Which companies. Analytics, ads, newsletter, chat and payments all get named |
| Retained until the purpose is fulfilled | How long each category is kept, and who deletes it when that time is up |
| You may request deletion of your data | Can your admin panel really delete it, including backups and the mailing list |
If two or more cells in the right-hand column have no answer, the gap is not in the document. It is that the inventory has never been done. A policy is the product of an inventory, and doing it the other way round produces a handsome file that describes somebody else's website.
3. The six items Article 8 requires you to disclose
For Taiwan there is an explicit list. Article 8 of the Personal Data Protection Act requires that when you collect personal data from a person, you tell them six things clearly. Those six are the skeleton of a privacy policy, and the fastest way to spot a missing limb.
The six items in Article 8
- Who is collecting. The full legal name of your company or sole proprietorship, not the site name or the brand.
- The purpose of collection. A concrete use, such as order processing and shipping notices. Writing "business purposes" says nothing.
- The categories of data. List them honestly: name, contact details and transaction history each count as a category.
- The period, territory, recipients and manner of use. How long, whether it leaves the country, who receives it, what is done with it.
- What rights the person has, and how to exercise them. Access, review, copies, correction, deletion, stopping use, and who to contact.
- The consequences of not providing it. For example that registration cannot complete or nothing can be shipped, so they can decide for themselves.
The fourth item is the one generators blur most, because it asks four questions at once and every one of them sends you back to check something. The fifth is the one most often written and least often honoured, which the fifth section comes back to.
4. Five places a generated policy stops matching
If you only check five things, check these. Each is something a generator has no way of knowing, and each is among the first things asked about when a dispute actually happens.
Five things no generator can ask you
- The real list of third-party tools. Which analytics, advertising, chat and newsletter scripts you run, named in the policy. An old tool installed and never removed is the one most often missed.
- Whether data leaves Taiwan. Using an overseas cloud service, mailing platform or form service puts data outside the country. The policy has to say so rather than skip it.
- Cookie wording has to match what actually loads. Plenty of sites claim to use only essential cookies while the home page loads ad trackers.
- Retention periods need numbers. Writing "until the purpose is fulfilled" is not a period, and it usually means nobody is deleting anything.
- Somebody has to read the contact channel. Publish an address or a form and name the person who answers it. An unread inbox is the same as no inbox.
5. Once it is written, the back end has to keep up
The practical value of a privacy policy is that it forces you to write your promises down. Once written, the back end has to be able to honour them. The gaps usually show up in three places: deletion, the contact channel, and redesigns.
Deletion is the promise broken most often. The policy says people can ask for it, and in practice the data sits in the main database, in backup files, in the newsletter platform and in the support system. Clearing one of those is not deletion. Some records also have to be kept because the law requires it, transaction and invoice records among them. That is fine, but the policy should say which ones stay and for how long rather than glossing over it.
The contact channel needs an owner and an internal deadline. Who checks the request, who replies, within how many days: agree on that in advance. With nobody responsible, requests sit quietly in a shared mailbox.
Redesigns are the third. Change a form, add a new tracking tool, switch newsletter platforms, and the policy should change with it, with the revision date updated as well. A policy stamped three years ago tells every reader that nobody is looking after it.
6. What belongs to a lawyer, and what is technical
There is a line here worth drawing. How a clause has to be worded to hold up, whether a particular provision applies to your situation, how liability falls if there is a dispute: those are legal judgements and they belong with a lawyer. Neither a generator nor this article replaces that.
The technical half sits on the other side: which fields you collect, which third parties receive the data, whether the back end can delete it, whether it is protected in transit and at rest. That part can be established precisely, and it has to be, because a lawyer needs the same list before they can draft anything.
So the order worth following is this. Establish what actually happens, then decide what the document says. Reversed, you end up with a polished file and a website that contradicts it.
A privacy policy is not decoration, and it is not something a generator finishes for you. It is a public promise, and the promise has to equal what you actually do. Checking it is simple enough: establish what you really collect, who receives it and how long you keep it, then read the document again and look for what is wrong or invented. As a reminder, this is general information about Taiwan's PDPA rather than legal advice, and the current statute and the regulator's announcements are what govern.
Common questions
- Can I use an online privacy policy generator?
- Use it for structure, not as a finished document. A generator assembles pre-written paragraphs from the boxes you ticked. It does not know which fields your forms collect, which third parties receive the data, or whether your back end can delete anything. The output often covers features you do not have, or promises things you cannot honour. Take the skeleton and rewrite each clause against what you actually do.
- Where should the privacy policy live on the site?
- Somewhere reachable from every page, which for most sites means the footer. It also has to be visible wherever personal data is collected: next to registration, checkout and contact forms, ideally with one short sentence and a link. The law requires that the person be told, so what matters is whether the person filling in the form can see it, not whether the file exists.
- How often should a privacy policy be updated?
- There is no fixed interval, but there are clear triggers: changed form fields, a new tracking or analytics tool, a different newsletter or support platform, a new service launched. Update the policy at those moments and change the revision date with it. Rather than booking an annual review, tie it to the redesign and vendor-change process you already run.