Privacy Policy

Handing over a name and a phone number to sign up for something is old behavior. Finding out what happened to them afterward was impossible. The signup screen said the fields were required, and everything past that point — what the data was used for, how long it was kept, who else got a copy — lived inside the company.

So the same story kept repeating. Three months after registering with an online store, calls from unknown numbers start arriving to sell insurance. The person has a guess about where the number leaked from and no way to confirm it. Customer support replies that data is handled lawfully, and there is no document anywhere against which that claim could be checked.

A privacy policy pins the situation to a single artifact. The law fixes the list of items the document has to contain, and the company fills them in and publishes the result. Once it is out in public, two things exist that did not before. Users have grounds to ask a specific question instead of a vague one, and regulators have a baseline to compare actual processing against.

What the document is not is permission. The right to process personal data at all comes from somewhere else — consent from the person, or a legitimate interest the company can justify — and the policy is where a company discloses what it is doing with that right. Publishing a line about an activity does not create the authority to carry it out, and the two get conflated constantly.

The company does not choose the contents. The law sets the list, and a missing item is itself a violation, so the wording and order can change but the items cannot.

1. Data collected and how — the fields actually taken: name, email, payment details. It also covers what accumulates on its own, like access logs and device information, which teams routinely forget because nobody typed those into a form.
2. Purposes — attached per item. Because of purpose limitation, nothing written here can later be used for a purpose not listed, which makes this the most carefully drafted section in the whole document.
3. Retention periods — stated per item, not once for everything. A retention period is fixed by law for some data, such as five years for payment records, and chosen by the company for others, such as three months for access logs. Writing "deleted when the account closes" collapses both cases and matches neither.
4. Third-party sharing and processing on the company's behalf — named, company by company. The email delivery tool, the payment processor, and the outsourced support desk all belong on this list.
5. Cross-border transfers — which country and which recipient, wherever data is processed abroad. A team serving only domestic users still triggers this the moment it runs on a foreign cloud.
6. Rights and how to exercise them — that a data subject can see what is held about them or ask for deletion, plus the actual channel for making the request.
7. Safeguards and the responsible person — the protective measures in place, such as encryption and access control, together with the title and contact details of the privacy officer.
8. Revision history — what changed, when, the previous version, and the date the new one takes effect.

Drafting belongs to whoever owns legal, and at a company without that role the founder works through it with an engineer. The order matters more than the drafting: list every external tool in use and confirm what data reaches each one, then write the document from that list. Starting from a template found online leaves in fields nobody collects and leaves out the tools that are actually running.

Four audiences read it.

1. Ordinary users — the smallest audience by far. The exception is a user who has had a problem, a stream of marketing calls or a compromised account; that person reads closely and quotes sentences back in a support email.
2. Regulators — the first document pulled when a complaint or an investigation starts. Any gap between the text and the real processing becomes an item in the inquiry.
3. Enterprise customers — security review before a contract asks for it directly. An empty list of processors, or a revision date two years old, produces questions in the meeting.
4. Platform reviewers — app store listings and sensitive account-connection permissions require a policy URL at submission.

The trigger for updating it is a change in data flows, not a change in features. Adding an analytics tool, switching a vendor, or asking for one more field at signup all qualify. When a change works against users, it gets announced before it takes effect, usually with at least seven days' notice.

"If we ship this feature the policy has to change with it. We're collecting two more fields."

A request to put the document revision inside the development schedule.

"The customer wants our processor list and what's in the policy doesn't match what we run."

The document has fallen behind the system it describes.

"Writing it in the policy isn't what makes it allowed. We need a separate consent checkbox."

Drawing the line between disclosure and legal basis.

Pagedeck first took this document seriously in the middle of its first enterprise deal. The customer's security reviewer asked for the processor list and the cross-border transfer section, and the policy at the time still held the paragraphs written on the week of launch. Grace asked Theo to pull every external service that data leaves for, and the list came back with nine entries, including an overseas storage bucket and the email delivery tool. Four of them appeared nowhere in the policy.

Rewriting the document took two days. Building the list took a week, because nobody in the company held the whole picture and several tools only surfaced by going through the card statements.

The most common assumption is that this is a formality: the law names the sections, so filling in a template looks like the whole job. The real risk in this document is not an empty section but a sentence that does not match reality. State a one-year retention period while deleting nothing, and that sentence becomes the company's own published standard and the cleanest evidence of the violation. A company that wrote something inaccurate ends up in a worse position than one that wrote nothing.

The second misreading is that disclosure grants permission — it feels like telling people is the substance of the obligation. Disclosure and authority are separate steps. Marketing use needs consent collected for that purpose, and processing without consent needs a justification that the company's need outweighs the effect on the user. Send promotional messages on the strength of one line in the policy and the document stops being a defense: it becomes the record that the practice was deliberate.