Table of contents
- Why preparation comes before drafting
- Step-by-step data inventory
- Practical example
- Common mistakes
- Limitations and professional review
- Best practices
- Official reference points
- Related resources
- FAQs
- Final checklist
Introduction: why preparation comes before drafting
A privacy policy should describe what an organization actually does with personal information. A short template cannot discover which form fields you collect, which analytics scripts run, where vendors store records, how long backups survive, or which rights apply in a visitor's jurisdiction. Publishing generic text before answering those questions can create statements that are incomplete or inconsistent with real operations.
This page is therefore a preparation checklist, not a privacy-policy generator. It does not create legal text, verify compliance, inspect your website, or decide which law applies. Its purpose is to help an owner, engineer, privacy lead, or qualified reviewer gather evidence before drafting or updating a policy.
Step-by-step data inventory
1. List collection points
Record every place where information enters the service: account forms, checkout, contact forms, newsletter signup, support tickets, uploaded files, analytics, advertising, cookies, server logs and offline imports. For each point, write the exact fields collected and whether a field is required or optional. Include identifiers created automatically, such as account IDs, IP addresses and device information.
2. Document purpose and access
For every data type, state why it is needed and which roles can access it. Separate operational needs from optional marketing or analytics uses. A vague statement such as “to improve services” is not a substitute for documenting concrete activities such as fraud prevention, customer support, invoice delivery or aggregate traffic analysis.
3. Inventory cookies and analytics
List first-party and third-party cookies, local-storage keys, analytics tags, advertising scripts and consent tools. Record when each item loads, what it measures, its lifetime and whether it transfers data to another company. Verify every entry against browser inspection, tag-manager configuration and current vendor documentation.
4. Map processors and vendors
Create a vendor table containing the provider, service, data categories, processing purpose, storage region, contract owner and deletion procedure. Include hosting, email, payments, analytics, customer support, error monitoring, document processing and backups. Link to current vendor terms and data-processing information so a reviewer can verify rather than infer the relationship.
5. Define retention and deletion
Write a retention rule for each record type. “As long as necessary” is not an operational schedule. Identify active retention, backup retention, legal holds, account-closure handling and the team responsible for deletion. Test whether the stated process can actually remove or anonymize data across primary systems and vendors.
6. Record user choices and rights
Document how a person can request access, correction, deletion, portability, objection or withdrawal where applicable. Note identity-verification steps, response ownership and contact channels. Do not promise a right or response time until a qualified reviewer confirms the applicable requirements and the organization can perform the workflow.
7. Check children, transfers and sensitive data
Identify whether the service is directed to children or knowingly receives children's data. Separately flag health, financial, biometric, precise-location, government-identifier and other sensitive categories. Record international transfers and relevant vendor locations. These facts often require specialized legal and security review rather than generic wording.
8. Prepare contact and change records
Confirm the legal entity name, postal address, privacy contact, complaint channel and policy owner. Keep a dated change log explaining why disclosures changed. A public “last updated” date should correspond to a real review, not an automated timestamp.
Practical example
Consider a small subscription website with account signup, card payments, email support and traffic analytics. Its preparation file might record that email addresses are stored in the account database, payment details are handled by a payment processor, support messages remain in a ticketing vendor, and analytics uses a consent-dependent identifier. It would also identify deletion steps for the account database, ticket history and vendor records.
That evidence gives a qualified reviewer something concrete to assess. It does not prove compliance, and it does not determine whether consent, contract, legitimate interests or another legal basis applies. Those decisions depend on jurisdiction, audience and actual practice.
Common mistakes
- Copying another company's policy even though the vendors and data flows differ.
- Claiming that data is never sold or shared without checking contractual and statutory definitions.
- Omitting logs, backups, embedded media, advertising scripts or offline customer records.
- Naming user rights that the organization has no process to fulfil.
- Publishing vendor names from memory instead of current configuration and contracts.
- Treating a cookie banner as evidence that every script respects the selected choice.
Limitations and professional review
This checklist is educational information, not legal advice. It does not identify applicable laws, provide jurisdiction-specific clauses, draft a policy, audit technical controls, or certify compliance. Privacy requirements can depend on location, industry, audience, processing purpose and contractual obligations. A qualified privacy or legal professional should review the completed inventory and final publication where the risk warrants it.
Do not place confidential personal data in a public checklist. Store the working inventory in an access-controlled system and share only the facts required for review.
Best practices
- Assign an owner to every collection point and vendor relationship.
- Reconcile the inventory with code, tag managers, cloud configuration and contracts.
- Review the policy whenever a new form, vendor, purpose or transfer is introduced.
- Write in language the intended audience can understand.
- Keep the public policy consistent with the Privacy page, contact process and actual product controls.
Official reference points
For a U.S. business-security starting point, the Federal Trade Commission's guide to protecting personal information recommends understanding what information a business holds, retaining only what it needs, protecting it, disposing of it securely and preparing for incidents. That security guidance does not determine which privacy laws apply or replace a policy review.
Organizations operating in the United Kingdom can use the UK Information Commissioner's Office accountability framework to review governance and records against official regulatory guidance. The ICO states that these accountability resources are under review following changes in UK law and may change. It also directs smaller organizations to its small-organization data protection resources rather than treating the audit framework as a small-business checklist. Applicability still depends on the organization, its processing and current law, so qualified jurisdiction-specific review remains necessary.
Related resources
- Privacy Red-Flag Checklist for a narrow keyword-based reminder, not compliance verification.
- TanzaiTools Privacy page as a public example to compare with verified product behavior, not as reusable legal text.
- Security tools for supporting technical checks.
- Contact TanzaiTools for questions about TanzaiTools itself.
FAQs
Does this page generate a privacy policy?
No. It helps collect facts for a qualified reviewer. It does not produce policy wording or certify that the resulting document is legally sufficient.
Can it scan my website or identify every tracker?
No. Review source code, tag-manager configuration, browser storage, network requests, vendor settings and contracts. Automated scanners can also miss conditional or authenticated behavior.
Is completing the checklist proof of compliance?
No. Compliance depends on applicable requirements and real operational controls. The checklist is only evidence preparation.
When should the inventory be updated?
Update it before launching a new collection point or vendor and whenever retention, sharing, audience or geographic processing changes. Schedule periodic verification even when no change was planned.
Conclusion and final checklist
Before asking for drafting or review, confirm that the packet includes collection points, purposes, access roles, cookies, vendors, retention, deletion, user requests, sensitive categories, children, transfers, contact details and a dated change record. Mark unknown items openly instead of filling gaps with assumptions.