A Privacy Policy Written for a Real Business

Why generated policies fail

A generator produces a document covering every possibility, which means it describes a business that collects things you do not and uses services you have never heard of.

It is not that the document is illegal. It is that it is inaccurate, and an inaccurate description of your practices is a poor foundation if anybody ever examines it.

It also fails the practical test: a customer reading it learns nothing about what you actually do with their information, which is what they came to find out.

What follows is a general description rather than legal advice, and where you operate and what sector you are in affects what is required.

Write it from the inventory

The method that makes this straightforward.

Before writing anything, list what you actually collect, where it sits, and which third parties are involved.

The policy is then a description of that list rather than an attempt to imagine what a business might do.

Writing it in the other order, document first, produces the generated result even when a person wrote it, because there is nothing specific to draw on.

An afternoon on the inventory makes the policy itself about an hour.

The sections and what to actually say

• What you collect, listed, in ordinary words.
• Why, as a purpose rather than a legal formula.
• Who else sees it, named, not described as partners.
• How long you keep it, with actual periods.
• How it is protected, briefly and truthfully.
• What people can ask for, and how.
• Who to contact, with a monitored route.

The third and fourth are where generated policies are vaguest and where a specific one is most useful.

Name the third parties

The section that most clearly separates a real policy from a template.

Your website form sends through a service. Your bookings go through a platform. Your invoices are issued by software. Your mailing list sits with a provider. Your analytics is somebody else's system.

Naming them is more useful to a reader than a sentence about trusted third parties, and it is the honest answer to the question they are asking.

It also forces you to know, which is frequently the more valuable outcome, since businesses are regularly surprised by how many services are involved in a modest website.

Where a list would be unwieldy, name the categories and the main ones, and offer the full list on request.

State real retention periods

The other section that templates handle badly.

As long as necessary is not a retention period. It is a placeholder that tells a reader nothing and gives you no rule to follow.

Write actual periods: enquiries kept for a stated time if they do not become customers, customer records kept for a period matching your tax and warranty obligations, mailing list entries kept until somebody unsubscribes.

Then apply them, which is the harder part and the reason to state periods you can genuinely keep to.

A policy stating two years while you hold nine years of email is worse than one stating a longer period honestly.

A worked example

A firm had a generated policy referring to cookies they did not use, a mobile application they did not have, and international transfers they had never considered.

They spent an afternoon listing what they held, which produced eleven locations and six third-party services.

The policy was then rewritten in about an hour: what the contact form collects and where it goes, what the booking system holds, that invoicing is handled by a named provider, that the mailing list is with a named platform, and that job photographs are kept for a stated period.

It came to roughly two pages, shorter than the generated one.

A customer asked a question about it six months later and the office manager answered from the document in a minute, which had not been possible before.

That was the actual test, and the generated version would have failed it.

Write it for a customer

A framing choice that improves the result.

The audience is somebody mildly concerned, not a regulator, and the document works if that person finishes it understanding what happens to their information.

Which means ordinary sentences, short sections, and no defined terms unless they are necessary.

We keep enquiry emails for two years and then delete them communicates. Personal data shall be retained for such period as is necessary for the purposes for which it was collected does not.

Regulators have consistently encouraged plain language, so writing for the reader is not in tension with writing for compliance.

Keep it current

The maintenance point, which is where good policies decay.

Adding a booking system, changing mailing platforms, or installing a chat widget all change what the document should say, and none of those prompt anybody to open it.

Put a review in the calendar annually, and add a line to whatever process you use for adding new tools: check whether this changes the privacy policy.

Date it, so a reader can see when it was last considered, and keep the previous version rather than overwriting, since knowing what it said when somebody signed up is occasionally useful.

The counter-case

Templates are not worthless and starting from nothing is harder than it needs to be.

A good template provides the structure and reminds you of sections you would forget, and using one as a skeleton to be filled with your own facts is sensible.

The failure is publishing it unedited, not consulting it at all.

There is also a level of complexity where this stops being a self-service task: a business handling health information, children's data, or operating across several jurisdictions needs professional input, and an afternoon and a template is not adequate.

For an ordinary small business with a website, a form, an invoicing system and a mailing list, writing it yourself from an inventory is both achievable and better than the alternative.

Writing yours

1. Do the inventory first.
2. Use a template as a skeleton, not as content.
3. Name the third parties you actually use.
4. State retention periods you can keep to.
5. Give a contact route somebody monitors.
6. Write it for a customer, in plain sentences.
7. Date it and review it annually.

Step one is what makes the rest possible, and skipping it is why so many of these documents describe somebody else.

The case for having one at all is covered in the privacy policy nobody wrote.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.