In many landscaping businesses data protection only reaches the desk when a letter arrives: a warning notice about a font loaded from someone else's server, a query from a supervisory authority after a complaint, or a former customer who wants to know what happened to the enquiry he sent three years ago. Until then the website counts as a technical side issue that somebody else looks after. In reality every trade website processes personal data, even the plainest one: as soon as a form is submitted, a server logs a request or an enquiry lands in the office mailbox, the duties of the General Data Protection Regulation apply. The good news is that the scope stays manageable once it has been sorted properly. This article works through the points that should be settled on a website for a landscape gardening business: privacy policy, contact form, consent, hosting, processing agreements and audience metrics. It is written factually and does not replace legal advice — assessing a specific case remains a matter for a lawyer.
Key takeaways
- A trade website processes personal data even without any audience metrics: form entries, server log files and the mail delivery of enquiries are enough for the duties of the GDPR to apply.
- A contact form usually needs no consent checkbox when it serves the initiation of a contract; what it does need is few mandatory fields, a visible link to the privacy policy and encrypted transmission.
- For cookies and comparable access to a visitor's device, section 25 TDDDG requires prior consent; audience metrics that avoid such access can be run without any banner at all.
- With every service provider that processes data on your behalf — host, mail provider, maintenance partner —, a processing agreement under Art. 28 GDPR has to be concluded and kept on file.
- A data breach must be reported within 72 hours (GDPR Art. 33) and an access request answered within one month (GDPR Art. 12) — both only work if it has been documented beforehand where which data sits.
What a trade website actually processes
The first reaction in conversation is almost always the same: we do not collect any data, we just show our work. That holds for the photographs of the finished terrace, but not for the rest of the site. A website for a landscape gardening business processes personal data in at least four places: in the contact form, in the log files of the web server, when enquiries are delivered to the office mailbox, and in everything that is loaded from someone else's server. None of these points is particularly delicate on its own. Together they add up to processing that needs a legal basis, a description and a retention period.
The point most often overlooked is the log files. Every page request leaves an entry on the server with an IP address, a timestamp, the address requested and the browser identifier. Case law treats the IP address as personal data, because a link to the account holder can be established. That is no cause for alarm: such logs are necessary for secure operation and can be based on a legitimate interest. But they should be kept briefly and named in the privacy policy — with the retention period the host has actually configured, not the one taken from a template.
Landscaping adds a particularity that many other trades do not have: enquiries almost inevitably contain a property address. Anyone asking about a terrace, a driveway or a rainwater cistern names the town, often the street, sometimes the house number. That is information attributable to a person, and the accompanying photographs from the build are too. This link between enquiry, address and image is why a deletion concept in landscaping concerns not only the mailbox but the image archive as well.
Form entries
Name, phone number, mail address, location of the project and a description of the wish. Personal as soon as they can be attributed to a specific person — which is the rule with an enquiry.
Server log files
IP address, timestamp, page requested and browser identifier arise with every request. Necessary for operation, but to be given a fixed and short retention period.
Job applications
CV, references, driving licence categories and contact details. Tied to the purpose of the current procedure and to be deleted afterwards, unless consent for a talent pool exists.
Contract and invoice data
Whatever arises in the business after the enquiry is additionally subject to commercial and tax retention periods. Those periods take precedence over the duty to delete and must be considered separately.
Embedded content
Fonts, maps, videos and review widgets from external servers transmit the visitor's IP address before he has clicked anything. The most common trigger for complaints.
Accountability
The GDPR demands accountability. Anyone who has noted which data is processed for which purpose and for how long can answer a query in minutes rather than weeks.
The privacy policy describes the actual state
A privacy policy is not a legal text you obtain and file away, it is a description of what your own website does. Art. 13 GDPR sets out what has to be in it: who is responsible and how they can be reached, for which purposes data is processed, which legal basis this rests on, who receives the data, how long it is stored, which rights the data subject has and that they may lodge a complaint with a supervisory authority. Those points are a structure, not a word count. A good policy for a business with fifteen staff is shorter than most templates, because it describes only what is actually there.
This is where the most common mistake sits. Templates describe someone else's website, not your own. They name services the business has never used and stay silent about the form through which enquiries arrive every day. In a complaint that is the first thing to stand out, because an inspection does not begin with the wording but with a comparison: what does the page load, which fields does the form have, where does the data go? If the policy does not match, the shortcoming is obvious without any fine legal work.
Separate from this in practice is the legal notice under section 5 DDG. It contains the provider identification with name, address, legal form, authorised representatives, contact details and, where applicable, register entry and VAT identification number. Both pages must be reachable from every subpage with one click, usually through the footer. On mobile pages this is easily lost when the footer collapses and the links end up in a menu that is hard to open.
The template that does not fit
The contact form: fewer fields, a clearer position
For a contact form through which someone asks for a quotation, the legal basis in most cases is Art. 6 (1) (b) GDPR: the processing is necessary for steps taken at the request of the data subject prior to entering into a contract. Anyone asking about a terrace renovation wants a quotation; without a name and a way to call back there will be none. For the accompanying processing such as spam defence or logging, the legitimate interest under (f) applies. Both belong in the privacy policy, not in the form itself.
The most effective lever is data minimisation, and it helps twice over: fewer fields mean less processing and at the same time more enquiries actually sent. For landscaping, a name, a callback number or mail address, the postcode or town of the project, the trade and a free text field are usually enough. The full address is not needed for a callback — it comes up in the conversation anyway. Questions about budget, plot size or preferred timing can be useful, but should stay optional so that nobody is stopped by a mandatory field they cannot answer yet.
- Mark only those fields as mandatory that are genuinely required for a callback
- Place a visible, linked reference to the privacy policy below the form, in normal type size
- Transmit exclusively over HTTPS with a valid certificate, on every subpage
- Solve spam protection on the server side, without loading anything from an external server
- Route enquiries to a mailbox in the business, not to a private mail address
- Set a fixed retention period for enquiries that never led to a job
The path of an enquiry does not end when it is sent. The form notification is often distributed to several addresses — the owner, the office and the site manager — and out of convenience a copy lands in a private account. At that point the record leaves the controlled area and the deletion run never reaches it. A single recipient inside the business, from which mail is forwarded internally, is far easier to document. How such a form can be built so that it also pre-qualifies is described in detail on our page about the enquiry form for landscaping businesses.
Consent: when it is needed and when it is not
Consent is used wrongly on many trade websites: it is missing where it is required and sits where it improves nothing. Consent is required when information on the visitor's device is accessed or something is stored there — section 25 TDDDG covers this, regardless of whether the stored information is personal. It is likewise required for a newsletter, for embedded content from external providers and for publishing photographs on which a customer's property is identifiable. In those cases there is no way around an agreement obtained in advance.
It is usually not required for the contact form itself. A checkbox stating that the sender agrees to the processing of the data does not make the enquiry safer, it makes it weaker: if the processing is necessary in order to reply, the consent is not freely given, and consent that is not free does not hold. On top of that, any consent may be withdrawn at any time — the enquiry would then have to be deleted while a quotation is being written. The reference to the privacy policy fulfils the duty to inform; the tick box does not replace it.
Where consent is required, four requirements apply: it must be freely given, informed, declared through an active step and as easy to withdraw as it was to give. Pre-ticked boxes, nested switches and a design in which agreeing is prominent while refusing is hidden do not meet that standard. And the fourth point, the one most often missing: consent must be demonstrable. Whoever obtains it should record when it was given, in what wording and for what.
| Element | Frequently found | Cleanly solved |
|---|---|---|
| Privacy policy | Template from the web, never adapted | Describes the services actually in use |
| Contact form | Ten mandatory fields including address | Four mandatory fields, everything else optional |
| Consent | Tick box for the enquiry itself | Only where it is legally required |
| Hosting | Provider known, location unclear | Data centre in Germany, contract on file |
| Fonts and maps | Loaded from an external server | Served locally or only after a click |
| Audience metrics | Banner covering the entire content | Measurement without access to the device |
| Deletion | Enquiries from 2019 still in the mailbox | Fixed period, one run per year |
Hosting in Germany and the path of the data
Where the website runs decides which chapter of the GDPR has to be examined. If the data stays in Germany or in the European Union, European law applies without an intermediate step. If it leaves that area, a transfer to a third country has to be justified, with an adequacy decision, standard contractual clauses or supplementary measures. For a trade business with fifteen staff that is effort without return. A data centre in Germany is therefore less a matter of conviction than a simplification. It spares an assessment that would otherwise have to be repeated regularly.
The location involves more than the web server. What needs clarifying is where the backups sit, which route the form notifications take when they are sent by mail, whether a delivery network is placed in front of the images and where log data is analysed. It happens that the web server stands in Frankfurt while the form mails travel through a dispatch service outside Europe. That question can be put to the provider in two sentences, and the answer belongs in your own documentation, not in someone's memory.
The second part is operation. Art. 32 GDPR requires measures appropriate to the risk: encrypted transmission with a valid certificate, current software, working and tested backups, separate accounts per person instead of one shared password in the office. None of this is demanding, but all of it lapses if nobody keeps it up. That is exactly what ongoing website maintenance is for — in data protection it is not a comfort but the execution of a duty.
A location does not solve everything, but a lot at once
Processing agreements: the contracts nobody enjoys reading
As soon as a service provider processes personal data on behalf of the business, Art. 28 GDPR requires a processing agreement. More parties are involved than one might assume at first: the host, the provider of the mailboxes, the firm that maintains the website and has access for that purpose, any service used to dispatch the form notifications, an external backup store. With reputable providers these agreements are prepared and can be retrieved in the customer account or requested. The effort lies not in signing them but in having a complete list of who is involved at all.
In substance the agreement sets out that the provider acts only on instruction, which technical and organisational measures it applies, how it handles sub-processors, how it assists with access requests and data breaches, and what happens to the data at the end. The section worth reading above all is the one on sub-processors, because that is where the further companies involved and their locations are named. Anyone who needs a list of the parties involved usually finds it exactly there.
Alongside this comes the record of processing activities under Art. 30 GDPR. The exemption for companies with fewer than 250 employees rarely applies in practice, because it only covers processing that is occasional and free of risk — incoming customer enquiries and personnel administration are neither. The record does not have to be software, though. A table with one row per processing activity, kept up once a year, serves the purpose and is the document that answers most questions at once when it matters.
Processing Contact enquiries through the website
Purpose Initiating and handling jobs
Legal basis Art. 6 (1) (b) GDPR
Data types Name, phone, mail address, town, description of the project
Recipients Host (agreement under Art. 28, enter date)
Mail provider (agreement under Art. 28, enter date)
Location Data centre in Germany
Retention 6 months without a job, with a job per commercial and tax law
Access Owner, office (2 people)
Reviewed on Enter dateAudience metrics without cookies
Without any measurement the website remains a guess. It is useful to know whether the paving page is opened more often than the grounds maintenance page, whether enquiries arrive mostly in the evening from a phone, and when the spring increase begins so that preparation does not start too late. The question is not whether to measure but how. And the decisive line here is not drawn by the GDPR but by section 25 TDDDG: it requires consent as soon as information on the device is accessed or something is stored there.
From that follows a simple rule: a consent banner is not an obligation, it is a consequence. Anyone setting cookies for recognition needs prior agreement and has to make refusal as easy as agreement. Anyone who avoids such access and instead evaluates on the server which pages were requested, with a shortened IP address and without cross-device recognition, manages without a banner. That processing is based on a legitimate interest, has to be described in the privacy policy and needs an option to object.
Something is lost in the process, and it is more honest to name it: without recognition you cannot tell whether the same person came back three times, and attributing an enquiry to a particular search term becomes less precise. For a business with a service radius of forty kilometres that hardly matters. The questions that actually arise — which trade pulls, which location page is found, how many enquiries arrive per week — can be answered this way too. And a visitor who does not have to dismiss a banner first is more likely to still be there when the service page has loaded.
A privacy policy is not a text you obtain, it is the description of what your own website actually does.
Embedded content: maps, fonts, videos
The most frequent cause of complaints and warning letters is inconspicuous: content loaded from an external server when the page is opened. That includes fonts, embedded maps with directions, videos, review displays and social network buttons. During loading the visitor's IP address is transmitted to the external server before he has clicked anything. In legal terms that is processing which would have to be justified in advance — and which mostly cannot be justified, because it is not necessary for the display.
The remedies are unspectacular and are done once. Fonts are stored on your own server and delivered from there, which is faster as well. Instead of an embedded map, a still image of the location with a link that opens the map service only after a click is usually enough — on a phone that is the more comfortable route anyway, because otherwise the map pushes itself into the scrolling. Videos are loaded only after active agreement. Review displays can be replaced by quoted reviews in your own text.
How many external requests a page triggers cannot be seen without technical knowledge, but it can be measured: the developer tools of any browser show every request with its destination under the network view. Open the home page and one service page that way and you will see within five minutes which external servers are involved. The result is the most reliable basis for comparing the page with the privacy policy — and usually the shortest task list this whole topic produces.
Click first, load second
Deleting, answering, reporting a breach
The storage limitation principle in Art. 5 GDPR requires that data is not kept longer than necessary for the purpose. In practice this rarely fails for lack of will, but because nobody has set a period. For enquiries that never turned into a job, a period of a few months is common and easy to justify. For jobs, the commercial and tax retention periods apply and take precedence over the duty to delete. The separation matters: a quotation that was never accepted is not subject to the same periods as a paid invoice.
Two deadlines should be known in the business. An access request under Art. 15 GDPR has to be answered within one month (GDPR Art. 12); the person is entitled to learn which data about them is stored, where it came from, who received it and how long it stays. A personal data breach has to be reported to the competent supervisory authority within 72 hours (GDPR Art. 33), provided there is a risk to those affected. Both deadlines run from the moment of knowledge — and both can only be met if it was noted beforehand where which data sits.
- A record of processing activities, if need be as a two-page table (Art. 30 GDPR)
- One named person in the business where access requests and deletion wishes come together
- Retention periods per data type, written down and worked through once a year
- An emergency sheet for a breach: who reports, to which authority, within 72 hours
- Separate accounts per person for website, mailbox and file storage, no shared password
- A check of whether a data protection officer has to be appointed under BDSG section 38
What can be done on one winter evening
The order matters more than completeness. Anyone starting with the wording of the privacy policy is writing a text about a website he does not yet know. The reverse route makes more sense: first establish what the page does, then remove what is superfluous, then collect the agreements, and only at the end adapt the text to the state reached. The policy then describes a situation that genuinely exists, and the text has to be written only once.
The effort is manageable as long as the website has not grown over many years. For a business with a site of ten to twenty subpages, the stocktaking takes one to two hours, removing the external requests takes half a day depending on the technical build, and the agreements take a few mails. The only point that really costs time is the deletion concept — because it is the first occasion on which the business says out loud how long enquiries and project photographs should remain. Nobody from outside can make that decision.
Stocktaking
Which forms exist, which fields are mandatory, where do the notifications go, who has access? Then use the browser developer tools to check which external servers are involved when the page is opened.
Remove what is superfluous
Serve fonts locally, replace embedded maps with a still image and a link, load videos only after a click, swap external spam defence for a server-side solution, cut the number of mandatory fields.
Collect the agreements
Request the processing agreement from the host, the mail provider, the maintenance partner and the backup store and keep them in one place. Read the section on sub-processors and note the locations.
Adapt the privacy policy
Align the text with the state reached: controller, purposes, legal bases, recipients, retention periods, the rights of data subjects and the reference to the right to complain to a supervisory authority.
Set periods and a date
Write down retention periods per data type, create the record of processing activities and enter an annual date on which both are compared with how the business actually works.
After that the topic becomes small. One run a year, usually in winter, is generally enough: has anything changed on the form, has a service provider been added, are there enquiries to delete, does the policy still match? Anyone who keeps that appointment need not fear that a letter will uncover a state of affairs nobody in the business remembered. And a customer who wants to know what happens to his data gets an answer that fits into two sentences.