How to Write a Website Privacy Policy: PDPA Principles and Cookie Consent Design
At a lot of companies, the privacy policy was copied from another website when the site was built a decade ago. It describes things the company has never done, and omits the tracking codes, support widgets, and marketing tools that were added in the years since.
The risk is not that the document reads badly. It is that a privacy policy is, by its nature, a public promise and a formal disclosure. When the words and the practice do not match, you have neither achieved a valid disclosure nor done yourself any favors on the record. This guide covers how to write one from the facts, and which parts have to go to a lawyer.
Start with an inventory: what personal data your website actually collects
Personal data means information that can identify a specific individual, directly or indirectly. The first blind spot for most site owners is assuming that “we do not even have member accounts” is the same as collecting nothing. In practice the common sources include at least these categories:
Forms. Contact forms, quote requests, newsletter signups, event registrations. Names, phone numbers, email addresses, and company names all count.
Membership and transactions. Registration details, delivery addresses, order records, purchase history. If you offer social login, this also includes the identifying data returned by the platform; for the design, see Social Login and SSO.
Tracking and analytics. Web analytics tools, remarketing tags from advertising platforms, heatmap tools, A/B testing tools. This category is the easiest to overlook, because the tags are usually added by the marketing team and the owner may not know what is installed.
Technical records. Server access logs, error logs, support chat transcripts. Most of these contain network addresses and device information.
External tools. Live chat, messaging app tools, newsletter systems, CRM. Once data reaches an outside service, the obligation to disclose outsourced processing comes into play.
The method is simple: list every field on the site that accepts input, then ask your engineering or marketing team to list every piece of third-party code currently loaded on the site. That list is the basis for writing the policy.
What a privacy policy has to disclose
A policy that will hold up should at minimum answer these questions for the reader:
| The reader’s question | What the policy should cover |
|---|---|
| What data have you taken from me? | The categories of data collected, organized by source |
| Why did you take it? | The purposes of collection and use, such as contact, fulfillment, support, marketing |
| Where will it be used? | The scope and manner of use, including whether it is used for marketing |
| Who will receive it? | Whether it is provided to service providers or other third parties, and whether that crosses borders |
| How long will you keep it? | The retention period, or the criteria that determine it |
| What can I do about it? | How to request access, review, copies, correction, cessation of use, and deletion |
| What happens if something goes wrong? | How a data breach will be handled and how people will be notified |
| Who do I ask? | The contact point and how to reach it |
The two most commonly mishandled items are retention period and disclosure to third parties. The first is often written as “retained indefinitely,” which is hard to defend in practice; the second routinely omits analytics tools and external support systems, which do in fact come into contact with the data.
The policy should also carry a version and an effective date, with historical versions preserved when it is amended. If a dispute arises later, that is the key evidence of what was disclosed at the time.
Translating the principles of the Personal Data Protection Act onto a website
What follows covers principles only, not their application to any particular case. Whether the collection, processing, and use of personal data is lawful involves findings of fact and legal judgment, so consult a lawyer, and rely on the latest announcements from the competent authority for the detail of the regulations. The Personal Data Protection Act, usually shortened to PDPA, is Taiwan’s main law governing personal data.
The duty to disclose. At the moment data is collected, the individual has to know who is collecting it, for what purpose, which categories are involved, over what period and within what scope it will be used, and which rights they hold. On a website, that means a clickable link to the policy beside the form, not a link buried in the footer for people to find on their own.
Purpose limitation. What you said you would do at the point of collection is the only thing you may use the data for. A familiar dispute is a list gathered through quote requests being used to send marketing newsletters, which goes beyond the purpose disclosed. If you want to do marketing, add a separate, explicit, unticked consent option to the form.
Valid consent. Consent has to be given knowingly. Pre-ticked boxes, consent buried inside long terms, and “continued use constitutes agreement” are all easy to challenge.
Security maintenance. You have a duty to take appropriate security measures to protect the data, including access control, encryption in transit, backups, and log retention. This is not only compliance, it is practical risk management; for the fundamentals, see Website Security Basics for Businesses.
Incident handling and notification. In a breach you should establish what happened, take remedial action, and notify the individuals as required. The practical point is that you have to be capable of knowing what leaked, which means keeping adequate records as a matter of routine.
A mechanism for responding to individual rights. When an access or deletion request arrives, someone has to own it, with a process and a deadline. If your member data is scattered across several systems, this becomes extremely difficult, which is one reason consolidating member data is worth the investment; see Building a Membership and CRM System.
Designing consent for cookies and tracking tools
A cookie is a small piece of data a website stores in your browser to remember your sign-in state, your cart contents, or whether you are the same visitor as before. The technology itself is neutral; the controversy arises when it is used to track behavior across sites.
When designing a consent mechanism, cookies are usually sorted into categories:
- Strictly necessary: the site cannot function without them, covering things like sign-in state, the cart, and security protection
- Functional: remembering language, region, and preferences
- Analytics: understanding how visitors use the site
- Advertising and remarketing: used for ad delivery and performance tracking
The disputes concentrate on the last two. If you adopt a consent mechanism, what matters is not the wording in the banner but three things: whether those scripts genuinely do not load before consent is given, whether declining is as easy to click as accepting, and whether the consent record is kept. Plenty of sites install a banner and go on loading the tracking code in the background anyway, which makes the banner purely decorative.
How to configure the privacy settings inside an analytics tool, and which data should never be sent to it, belong to tool configuration; for that, see A Practical Guide to GA4. This article covers how to describe it in the policy and how to design the consent, and the two have to line up. If the policy says you track only after consent, the implementation has to actually work that way.
Details on the implementation side
- Give the policy page a permanent URL. Do not put it somewhere that disappears at the next redesign, and do not make it a modal only.
- Make the link beside a form open in a new window, so users do not have to abandon a half-completed form.
- Make consent records storable: when it was given, which version was agreed to, and by what means.
- Announce policy updates proactively, especially when you expand the purposes of use.
- Keep terms of service and the privacy policy as separate documents. They deal with different things.
- Put both pages on the pre-launch checklist, so you do not end up live with template text still sitting on your legal pages; for the full sweep, see The Website Launch Checklist.
Common mistakes
The policy says it, the company does not do it. For example, the policy states data is deleted after a set period, but the system has never had a deletion mechanism at all.
Marketing consent folded into the terms of service. The user believes they are agreeing to use the service, and it is read as agreement to receive marketing messages.
Third-party tools left out of the description. Tracking codes, support widgets, and form tools added later by the marketing team go unmentioned in the policy.
Personal data stuffed into URLs or analytics events. A name, phone number, or email address appearing in a URL parameter or an event name amounts to sending personal data into the analytics platform.
Writing it for search engines only. A block of legal language nobody can parse, tucked into the footer, does limited work toward the duty of disclosure.
The right approach to a privacy policy is to establish clearly what you actually do, write it down honestly, and have a lawyer confirm the wording and the obligations. Reversing that order, finding a template first and then trying to make reality fit it, is where most of the problems come from.
If you are reorganizing how your website collects data, or you are unsure whether your current systems can support access and deletion requests, talk to NETVANA about the state of your systems. NETVANA’s advisory services include technical architecture review, which can establish where the data actually lives and who can reach it before you decide what to change; for what each service includes, see the software services overview. For legal advice, consult a lawyer.
Further reading: for analytics configuration and privacy handling, see A Practical Guide to GA4; for the technical fundamentals of protecting data, see Website Security Basics for Businesses; for consolidating member data, see Building a Membership and CRM System; for the data obtained through social login and how to design that consent, see Social Login and SSO; and for the complete pre-launch inventory, see The Website Launch Checklist.
