FRUKIT KNOWLEDGE BASE
Creating a Proper Privacy Notice, Cookie Policy and Data Protection Policy
Why good privacy documentation starts with understanding the business — not copying a template
1. Introduction
Privacy documentation is one of those jobs that can look deceptively simple. There are plenty of templates on the internet, and it is tempting to change the business name, insert an email address and publish the result.
That approach may produce a document that looks official. It does not necessarily produce a document that describes what a real business actually does.
The more we looked at the privacy documentation for our own business, European Vintage Emporium, the clearer this became. The finished documents are only the visible part of the job. The real work is investigating the business, its website, its suppliers, its plugins, its data flows and its actual practices, then making sure the resulting documents agree with one another.
This article explains the process we used and the lessons it highlighted. It is intended as a practical guide to the work involved, rather than as a substitute for legal advice.
2. The three documents are not the same thing
A proper privacy documentation set normally has different jobs to perform. Treating the three documents as interchangeable makes it much easier to leave gaps or create contradictions.
2.1 Privacy Notice — the public explanation
The Privacy Notice explains to customers, visitors and other people whose information the business handles what personal data is collected, why it is used, who may receive it, how long it is retained and what rights people have.
It is written for the people whose data is being processed, so it needs to be understandable as well as accurate.
2.2 Cookie Policy — the technical explanation
The Cookie Policy deals specifically with cookies and similar technologies. It should reflect what the website actually uses, including necessary technologies and optional tracking or analytics where relevant.
A cookie table copied from another website is not a reliable substitute for checking the actual website.
2.3 Data Protection Policy — the internal framework
The internal Data Protection Policy is different again. It explains how the business itself manages personal data and provides an internal framework for processing activities, retention, security, access, suppliers, rights requests, breaches, reviews and accountability.
It can therefore contain operational detail that would not be appropriate or useful in a public-facing Privacy Notice.
3. Don’t start by writing the documents
One of the biggest lessons from our EVE project was that writing should come after investigation.
Before drafting anything, we needed to establish what the business actually does and where personal data travels. For a new client, this discovery stage could easily be a substantial part of the work.
Start with the business
Questions can include:
What does the business sell or provide?
Does it operate through a website, marketplace, social platform or a combination of these?
Does it have customer accounts?
Does it collect enquiries through contact forms?
Does it buy, sell or value items from members of the public?
Does it send transactional emails or marketing communications?
Does it use newsletters?
Does it deliver internationally?
Does it take payments online?
Does it use external suppliers or service providers?
Then investigate the website
For a WordPress/WooCommerce business, for example, the investigation may need to cover:
WooCommerce and customer accounts
Contact Form 7 or another form system
Payment gateways such as Stripe or PayPal
Google Analytics and other Google services
Cookie-consent and blocking tools
Security and firewall systems
Backup systems
Shipping and tracking plugins
Email and newsletter platforms
Hosting providers
SEO, advertising and conversion tools
Other active plugins that may interact with personal data
The important point is that an installed plugin is not automatically evidence that a particular processing activity is currently taking place. The configuration and actual behaviour need to be considered.
4. Build a picture of the data flows
A useful way to approach the investigation is to follow information through the business.
For example, an online order may begin with information entered by a customer, move into WooCommerce, involve a payment provider, generate an invoice, be passed to a delivery provider and result in transactional emails. Each stage needs to be understood.
The same approach applies to enquiries, buying or valuation requests, newsletters, analytics, security logs and backups.
A simple set of questions
For each processing activity, ask:
1. What personal data is involved?
2. Where does it come from?
3. Why does the business need it?
4. What is the appropriate legal basis?
5. Who receives or processes it?
6. Could it be processed outside the country or the European Economic Area?
7. How long does the business need to retain it?
8. What security measures protect it?
9. What happens if the person asks about their data?
10. What happens if something goes wrong?
5. The processing register is where the detail comes together
For the internal policy, these questions can be turned into a master processing register. This is one of the most useful parts of the exercise because it forces the business to describe its actual processing activities rather than relying on general statements.
A practical register can record:
Processing activity
Categories of personal data
Purpose
Legal basis
Data subjects
Recipients or processors
International processing or transfers
Retention period or review point
Security measures
Relevant systems and suppliers
Notes or evidence supporting the entry
The register also becomes a useful reference when the website, plugins or suppliers change.
6. Cookies require their own investigation
Cookies are frequently treated as a simple list. In practice, the important questions are often behavioural.
Which cookies or similar technologies actually appear?
Which are necessary for the website to function?
Which are optional?
Do optional technologies appear before consent?
What happens when the visitor declines optional cookies?
What happens after consent is given?
Can consent be withdrawn or changed?
Which service introduces each technology?
Is local storage used as well as conventional cookies?
Are the stated purposes confirmed, or merely guessed from a cookie name?
For EVE, testing a clean browser session before and after consent was more informative than simply copying a cookie inventory from a generic source. The exercise also showed why uncertain technical items should be identified as uncertain rather than given an invented purpose.
7. Installed does not necessarily mean active
This is an important lesson for anyone carrying out a website privacy audit.
A plugin may be installed but configured not to perform a particular function. A feature may have been switched off. A service may be connected but not currently used. Another system may already provide the same information, making a particular tracking feature redundant.
For example, during the EVE review, WooCommerce Order Attribution was disabled. Its associated Sourcebuster cookies were therefore not treated as an active processing activity merely because the software was capable of using them.
The correct documentation should describe the real configuration, not every theoretical capability of every plugin.
8. Retention is more complicated than one number
A common mistake is to decide that customer information will simply be ‘deleted after three years’ and put that sentence into every document.
Real businesses rarely work that neatly.
Different categories of information can have different retention requirements. Customer accounts, general enquiries, buying or valuation records, orders, invoices, accounting records, security logs, backups and information needed for legal claims may all have different lifecycles.
A sensible retention framework therefore distinguishes between operational review periods and information that must be retained for statutory, legal, security or evidential reasons.
This was one of the areas where the EVE documents needed careful reconciliation. A customer account review period is not the same thing as automatically deleting every record associated with that customer.
9. Third-party suppliers matter
Modern small-business websites often depend on a surprisingly large number of external services.
Hosting companies
Payment providers
Delivery providers
Email providers
Newsletter platforms
Analytics services
Advertising platforms
Cookie-consent providers
Security services
Backup providers
Cloud storage and other technical services
The documentation needs to reflect the actual relationship with each supplier. It is not always correct to describe every third party simply as a ‘processor’. Some providers may process information on the business’s instructions for one purpose while carrying out their own processing for other purposes such as security, fraud prevention or regulatory obligations.
10. International processing should not be overlooked
International delivery and cloud services can introduce additional considerations. A French business can easily use a service whose infrastructure, corporate group or subprocessors involve other countries.
This is another reason that generic templates can become misleading: the document needs to reflect the actual suppliers and arrangements used by the business.
11. The three documents must agree
Creating three documents independently is an easy way to create contradictions.
A final reconciliation should compare at least:
Business identity and contact details
Services and brands covered
Processing activities
Legal bases
Payment providers
Delivery providers
Analytics and advertising
Cookies and consent
Marketing communications
Retention periods
International processing
Data-subject rights
Security measures
Third-party suppliers
Other related ventures where applicable
If one document says customer accounts are reviewed after two years and another says three years, the discrepancy should be investigated and resolved before publication.
12. A real-world example: what this looked like for EVE
European Vintage Emporium provided a useful case study because it is a real small business with a reasonably complex online operation.
The work involved investigating the website configuration, payment systems, customer accounts, contact forms, delivery arrangements, Google services, cookie consent, security, backups, tracking, newsletter arrangements and related business activity.
Some of the work was straightforward because the business owners already knew the systems. Other parts required checking what was actually enabled, what had been disabled and what could or could not be established from the available evidence.
The final result was not simply three pieces of text. It was a coordinated set of documents supported by an understanding of how the business actually operates.
How long did it take? A long day. How long would it take for a business we don’t know? Probably up to a week.
13. Why this can take several days for a new business
For a business you already know, the investigation is much faster because much of the background is already available.
For a new client, the process could involve an initial discovery meeting, website and plugin review, supplier research, configuration checks, document drafting, questions back to the client, reconciliation and final review.
The visible documents may therefore represent only a fraction of the work involved.
The important lesson is simple: the more complex the business and its digital footprint, the more time is needed to understand what is actually happening before accurate documentation can be produced.
14. Templates still have a place
This does not mean templates are useless. They can provide a useful structure and a checklist of subjects that should be considered.
The problem starts when the template becomes the investigation.
A template should help answer the question ‘What do we need to consider?’ It should not be used to avoid asking ‘What does this particular business actually do?’
15. A practical workflow
A repeatable project can be organised into stages:
1. Initial business discovery
2. Website and technical audit
3. Supplier and data-flow investigation
4. Processing register
5. Cookie and consent review
6. Retention and security review
7. Draft Privacy Notice
8. Draft Cookie Policy
9. Draft internal Data Protection Policy
10. Cross-document reconciliation
11. Client review and factual corrections
12. Final publication and internal adoption
13. Scheduled review when the business or its systems change
16. Where FRUKit can help
This kind of work sits at the intersection of business processes and technology. A business owner may understand their customers and suppliers perfectly well but not necessarily know what every WordPress plugin, analytics service or payment integration is doing.
FRUKit’s role can be to help small businesses understand that technical side, document the actual arrangements and turn that information into clear, practical documentation.
Where a matter requires legal advice or a formal legal opinion, an appropriately qualified legal professional should be involved. The purpose of a technical and operational review is to make sure the underlying facts are understood and documented accurately.
17. The bigger lesson
Good privacy documentation is not really a writing exercise.
It is an investigation followed by documentation.
The final Privacy Notice, Cookie Policy and Data Protection Policy are simply the three visible outputs of that process.
The quality of the documents depends on whether the business has first taken the time to understand what information it collects, why it uses it, where it goes, who has access to it, how long it is kept and what happens when circumstances change.
That is why a generic template can be a useful starting point, but it should never be mistaken for a completed privacy review.
18. Important note
This article describes a practical documentation and website-audit process. It is not legal advice and does not constitute a guarantee that a business is compliant with GDPR, French data-protection law or any other legal requirement. Businesses with complex processing activities, significant risk or specific legal questions should obtain appropriate professional advice.
You can see the documents we produced for European Vintage Emporium here:
European Vintage Emporium Cookie Policy
European Vintage Emporium Privacy Policy
The Data Protection Policy is an internal document not normally made available for public viewing.