A good website privacy policy is a document that clearly explains how a site collects, uses, and protects its visitors’ personal data, rather than legal text copied from another site. It’s the first piece of written evidence a visitor sees before deciding whether to trust a company with their data.
Indonesia’s Constitutional Court recently underlined why this openness matters, in Case No. 284/PUU-XXIII/2025 decided on 2 March 2026, which rejected a challenge to the PDP Law’s explicit consent requirement. The ruling confirmed that a data controller must provide transparent information before processing personal data, and a privacy policy is the primary place that information gets delivered.
The trouble is that a good website privacy policy is often mistaken for one that simply exists. This article breaks down the required elements, what good writing looks like in practice, and how to build one from scratch.
7 Pieces of Information Required in a Website Privacy Policy
Article 21(1) of Indonesia’s Law No. 27 of 2022 on Personal Data Protection (the “PDP Law”) lists 7 pieces of information a controller must disclose whenever processing is based on consent, obligations that, like the rest of the PDP Law, apply extraterritorially, so a foreign-run website can fall within scope simply by collecting the personal data of visitors in Indonesia. These 7 elements should form the backbone of any website privacy policy, not an afterthought.
1. Legality of the Processing
This section explains the legal basis for processing, whether that’s user consent, contractual necessity, or another legal obligation. Without this, a visitor has no way of knowing on what grounds their data can be processed at all.
2. Purpose of the Processing
This section explains what the personal data is collected for, such as processing transactions, sending a newsletter, or analysing user behaviour. Stating the purpose specifically prevents data from later being used in a context the visitor never agreed to.
3. Type and Relevance of the Data
This section lists the categories of data collected, such as name, email, phone number, or location, along with why each one is relevant. Listing data that has nothing to do with the service on offer tends to raise questions from any careful reader.
4. Retention Period for the Documents
This section states how long personal data will be kept before it’s deleted or destroyed. This is the point most often missing from a privacy policy copied off a generic template, despite being explicitly required under Article 21.
5. Details of the Information Collected
This section goes further than the data type, explaining the concrete form the data takes, including anything collected automatically through cookies or activity logs. It fills in the practical detail behind how that data actually gets captured.
6. Duration of the Processing
This section explains how long the data will remain actively processed, which can differ from how long it’s simply retained in storage. Active processing can stop well before the data is actually deleted from the system.
7. Data Subject Rights
This section lists the visitor’s rights over their own data, including the right to access, correct, delete, and withdraw consent already given. These rights need a concrete way to exercise them, not just a list of legal terms.
Traits of a Well-Written Website Privacy Policy
Legal completeness alone isn’t enough, since a good policy also needs to be genuinely usable by the people reading it. Here are 5 traits that separate a privacy policy people actually read from one that only satisfies a legal checkbox.
- Written in language an ordinary reader can follow, not a wall of rigid legal terminology.
- Structured with clear section headings, not one long paragraph that makes readers give up halfway through.
- Includes a last-updated date, so visitors know how current the information actually is.
- Easy to find from the homepage, not buried in tiny footer text.
- Updated whenever data processing practices genuinely change, rather than left untouched for years.
As a concrete example, Pasal.id’s privacy policy reflects most of these traits: it has a table of contents linking straight to each section, a clearly stated effective date, and specific retention periods.
Example, “data is deleted within 30 days of account closure” instead of a vague line like “data is stored as needed.” Details like these are what separate a privacy policy people can actually rely on from one that’s purely for show.
5 Steps to Build a Website Privacy Policy
Building a website privacy policy follows 5 steps in order: inventory the data collected, map the legal basis and purpose, draft it around the required elements, test it for readability, then publish it with a review process. Each step is explained below.
1. Inventory Every Point of Data Collection on the Site
Trace every place the website gathers data, from signup forms and comment sections to third-party analytics cookies. Many privacy policies end up incomplete simply because whoever wrote them didn’t realise data was being collected automatically outside the obvious forms.
2. Map the Legal Basis and Purpose for Each Data Type
For every type of data identified, determine its legal basis and purpose before writing anything down. This step makes sure every sentence in the policy is backed by something defensible, not an assumption made by whoever drafted it.
3. Draft It Around the 7 Required Elements
Use the 7 required elements above as the chapter structure, then fill each one with details specific to your company. A draft built this way is far less likely to leave out required information than writing freely from a blank page.
4. Test It for Readability With Someone Outside Legal
Ask someone who wasn’t involved in drafting to read it and explain it back in their own words. If they struggle to explain it, website visitors will likely struggle too.
5. Publish It With a Clear Review Process
Place the privacy policy somewhere easy to find, then set a review schedule triggered by any business process change involving personal data. A policy that never gets reviewed quickly loses relevance the moment a new service or vendor is added.
Common Mistakes in Website Privacy Policies
There are at least 5 mistakes that most often undermine a website privacy policy. Recognising the pattern helps avoid repeating it.
- Copying a privacy policy from another website without adapting it to what actually happens with the company’s own data.
- Writing something so generic it never actually describes the company’s specific practices.
- Leaving out the data retention period entirely, despite it being a clear requirement under Article 21.
- Leaving the privacy policy unchanged even after data processing practices have clearly moved on.
- Burying data subject rights at the very end of the document, where they rarely get read.
Conclusion
A good website privacy policy isn’t finished the moment the 7 required elements from Article 21 are checked off, because how the information is delivered matters as much as how complete it is. Clear language, an easy structure to follow, and consistent updates are what separate a privacy policy people actually read from one that gets skipped entirely.
Building one properly takes coordination between legal, product, and the technical team who actually knows what data gets collected. The result is worth it, since a well-built privacy policy also builds visitor trust in how a company handles their data.
Ready to Manage Privacy Compliance as a Business Risk?
See how GRC helps map personal data risks, monitor compliance with the PDP Law, and prepare companies for audits without complicated manual processes.
FAQ
Yes, for any website processing personal data based on user consent, since Article 21 sets out the information that must be disclosed before consent is obtained.
No. A privacy policy explains personal data processing, while terms of service govern the general rules for using the service.
Whenever there’s a genuine change in data processing practices, such as adding a new vendor or a feature that collects extra data. Without a meaningful change, an annual review is enough as a safety net.
Not ideally, since the information required under the PDP Law needs to be delivered in a way data subjects genuinely understand. Offering an Indonesian version reduces the risk of being seen as non-transparent.
The company risks being found in breach of the PDP Law’s transparency principle, regardless of how polished the document looks. This mismatch is also usually what surfaces first during an audit or an incident.
