GDPR for Trades and Construction SMEs: 6 Common Pitfalls

Main article: Creating a record of processing activities — it sets out the nine RoPA fields per processing activity (eight mandatory fields derived from the seven items in Art. 30(1)(a)-(g) GDPR, plus the legal basis as a practical field), the 250-employee exemption in detail and 14 typical SME entries.

1. Customer data in spreadsheets

A customer spreadsheet with addresses and appointments is not a problem in itself — but it belongs in the record of processing activities (RoPA), requires a legal basis under Art. 6(1) GDPR, an access restriction and a deletion rule.

Specifically: Art. 30(1) GDPR lists seven mandatory items (points (a)-(g)). Because point (c) bundles two items — categories of data subjects and categories of personal data — practice derives from this eight mandatory fields per processing activity, supplemented by the legal basis as a ninth field. The exemption in Art. 30(5) GDPR applies only cumulatively: fewer than 250 employees AND no risk to the rights and freedoms of data subjects AND no regular processing AND no special categories under Art. 9 or criminal-conviction data. Customer base, newsletter and payroll are regular processing operations — which disposes of the exemption for the typical trades business. The official wording refers to 'a risk', not a high risk; the 'high risk' threshold applies solely to the data protection impact assessment under Art. 35(1) GDPR.

'Restricting access' is the technical and organisational measure under Art. 32 GDPR; in the RoPA a reference to a central TOM concept is sufficient instead of repeating it in every row — no RoPA without a TOM annex, and the supervisory authority reviews the concept for whether it matches the risk profile of the processing operations. Practical recommendation (not a statutory requirement): for the customer list this means in concrete terms: a designated storage location instead of desktop copies, a named-person authorisation concept, an encrypted drive or password protection — recorded once in the TOM annex and merely referenced in the RoPA. For deletion periods, the retention obligations per data category must be recorded (in Germany, 10 years under the Commercial Code (HGB) and the Fiscal Code (AO), 5 years under the Social Code (SGB), employment-law retention); the conflict with the right to erasure under Art. 17 GDPR is documented, not ignored. One documentation error comes up again and again: a RoPA kept as a PDF instead of in an editable format.

2. Employee tracking via vehicle GPS

In Germany, GPS tracking of company vehicles stands or falls on two data protection assessments: the conditions of § 26 of the German Federal Data Protection Act (BDSG) for employee data, and a data protection impact assessment where there is a high risk; alongside this, works council co-determination must be clarified where a works council exists in the business. For Austria, the standard is set out at the end of this section.

In Germany, § 26 BDSG is the provision for employee data — it applies there only. If the preliminary assessment indicates a likely high risk to the rights and freedoms of data subjects, in particular where new technologies are used, the data protection impact assessment must be carried out in advance (Art. 35(1) GDPR); Art. 35(3) GDPR names standard examples, including systematic monitoring of publicly accessible areas on a large scale. Practical recommendation (not a statutory requirement): record the outcome of this preliminary assessment in writing, even where it comes out against a DPIA — if the supervisory authority asks, the documentation is the evidence (Art. 5(2) GDPR).

The consequence is frequently overlooked: where a processing operation is subject to the DPIA obligation under Art. 35 GDPR, a data protection officer must be designated in Germany — irrespective of the number of employees (§ 38(1) sentence 2 BDSG). A business with eight employees can therefore become subject to the DPO obligation without ever reaching the 20-person threshold in § 38(1) sentence 1 BDSG.

Austria: the Austrian Data Protection Act (DSG) contains no separate provision on employee data protection. The standard is set by Art. 6 and Art. 88 GDPR; where employee data include special categories, the prohibition on processing in Art. 9(1) GDPR applies in addition. Monitoring measures that affect human dignity are permitted only with the consent of the works council or by means of a works agreement (§ 96(1) no. 3 of the Austrian Labour Constitution Act (ArbVG)). The processing belongs in the record of processing activities (Art. 30(1) GDPR); 'vehicle fleet + GPS tracking' is one of the typical SME entries. Practical recommendation (not a statutory requirement): limit the tracking purpose in writing.

3. Construction site photos (individuals identifiable)

As soon as individuals are identifiable in the photo, you are processing personal data and need a legal basis under Art. 6(1) GDPR before the image ends up on a website, a quotation or social media — in practice two routes get you there fastest: pixelation or written consent.

Anyone choosing consent (Art. 6(1)(a) GDPR) must be able to demonstrate that consent was given (Art. 7(1) GDPR) and must make withdrawal possible at any time and as easily as consent was given (Art. 7(3) GDPR); the lawfulness of processing carried out up to that point is unaffected. Practical recommendation (not a statutory requirement): keep a list of publication locations for every photo — without it, a withdrawal cannot realistically be implemented. Anyone relying instead on legitimate interests (Art. 6(1)(f) GDPR) documents the balancing test; the Accountability principle in Art. 5(2) GDPR requires the evidence. The other route, pixelation, only works to the extent that no individual remains identifiable in the image afterwards; if they remain identifiable, the first sentence of this section applies and you still need a legal basis under Art. 6(1) GDPR.

Germany: alongside Art. 6 GDPR, the KunstUrhG (right to one's own image) applies where individuals are identifiable — purely German law. Where your own employees appear in the image, § 26 BDSG applies in addition as the provision for employee data (see section 2).

Austria: protection of a person's image follows from § 78 UrhG. If it is not just a mobile phone camera running on the site but permanent image recording (video surveillance), §§ 12, 13 DSG apply in addition: the signage obligation under § 13(5) DSG and the 72-hour rule in § 13(3) DSG — retention lasting longer than 72 hours must be proportionate and must be separately logged and justified. Image recording for the purpose of monitoring employees is not permitted under § 12(4) no. 2 DSG.

4. Subcontractor data processing agreements

Clarify the role first, then the contract: anyone who, when data are passed on, processes them on your behalf — typically IT service providers or bookkeeping — is a Data Processor (Art. 4 no. 8 GDPR) and needs a data processing agreement under Art. 28 GDPR; anyone who determines purposes and means jointly with you is a joint controller (Art. 26 GDPR). A tax adviser, by contrast, is a Controller in their own right, not a Data Processor: they belong in the RoPA as a recipient, and no data processing agreement is needed for them.

Art. 28(1) GDPR permits cooperation only with processors providing sufficient guarantees of appropriate technical and organisational measures. Under Art. 28(3) GDPR, the contract must set out at least the subject matter and duration of the processing, the nature and purpose of the processing, the type of personal data, the categories of data subjects and the obligations and rights of the Controller. The allocation of roles itself follows Art. 4 no. 7 GDPR (Controller) and Art. 4 no. 8 GDPR (Data Processor) — confusing processing on behalf of a controller with what is actually joint controllership is one of the common documentation errors.

Every recipient also belongs in the RoPA: the categories of recipients are a mandatory item under Art. 30(1) GDPR. Out-of-date recipient lists — the old IT service provider is still listed, the new one is missing — are, in practical experience, a frequent finding in an inspection; in the editorial assessment, the supervisory authority typically proceeds in the order RoPA, data processing agreement, TOM, DPIA. Practical recommendation: create the data processing agreement and the RoPA row together when the contract is concluded, not afterwards.

Austria: there is no Austrian special rule for processing on behalf of a controller — Art. 28(1) and (3) GDPR apply. In addition, § 6 DSG obliges controllers, processors and their staff to observe data secrecy.

5. WhatsApp communication with customers

WhatsApp is a US provider, so using it is a Third Country transfer — you need separate, documented consent from the customer or an alternative such as Threema Work or Element, whose registered office, server location and data processing agreement under Art. 28 GDPR you check in advance; if you stay with WhatsApp, the RoPA entry on the Third Country transfer with its safeguard is added.

Consent 'bundled into' the terms and conditions is not sufficient: consent must be given for the specific case, in an informed manner and unambiguously (Art. 6(1)(a) GDPR); it must be demonstrable and as easy to withdraw as it was to give (Art. 7(1) and (3) GDPR, set out in full in section 3).

A further point on documentation: Third Country transfers belong in the RoPA together with the relevant safeguard (SCCs, Data Privacy Framework or BCRs) — in practical experience, the missing Third Country note for US tools is one of the frequent RoPA errors. The legal basis and the transfer safeguard are two separate RoPA fields: the documented consent belongs in the legal basis field (Art. 6(1)(a) GDPR), the safeguard in the Third Country transfer field — one does not replace the other. Practical recommendation: which of the three safeguards a provider uses is stated in its privacy information; in the RoPA it belongs in a separate column next to the Third Country transfer — following the pattern of the example entries in the main article on the record of processing activities, such as 'Mailchimp (USA, DPF)' or 'Google Workspace (USA, DPF)'. In practice, Art. 7(3) GDPR means: anyone who obtains consent by message must accept and record withdrawal by message. And customer communication by email, telephone or chat is a separate processing activity in the RoPA — a blanket 'communication collective processing' is too unspecific.

6. Applicant data by email

Three points are decisive: the Privacy notice in the application form, scheduled deletion six months after the end of the procedure and — for the talent pool — separate consent; the six months are derived from the periods for asserting claims and are used in RoPA practice as a deletion-period example.

The information obligation follows directly from Art. 13 GDPR and applies to the application form just as it does to the application mailbox. The underlying deadline logic differs by country: in Germany, claims under § 15(1) or (2) of the German General Equal Treatment Act (AGG) must be asserted in writing within two months, in the case of an application from receipt of the rejection (§ 15(4) AGG). The corresponding RoPA entry reads 'applicants 6 months (AGG)'. In Austria, the anchor is a different one: claims arising from a failure to establish an employment relationship must be asserted in court within six months of the rejection (§ 15 and § 29 of the Austrian Equal Treatment Act (GlBG)); a dismissal or termination must be challenged within 14 days.

The email route has a weak point of its own: the mailbox in which the documents land. Practical recommendation (not a statutory requirement): a dedicated address for applications instead of the general shared mailbox, access limited by name to the individuals involved in the procedure, forwarding to specialist departments only in extracts and documented. Here too, the access restriction is the technical and organisational measure under Art. 32 GDPR (see section 1).

For the talent pool, Art. 6(1)(a) GDPR applies: separate consent, demonstrable and as easy to withdraw as it was to give (Art. 7(1) and (3) GDPR, set out in full in section 3). Where documents contain information within the meaning of Art. 9(1) GDPR — health data, for example — the general prohibition on processing applies, with the narrow exceptions in Art. 9(2) GDPR. If a rejected person requests access, the one-month period in Art. 12(3) GDPR runs — details in the FAQ.

Which obligation each pitfall triggers

The six pitfalls come down to a few clearly identified obligations. Each row of the table names a statutory obligation with its trigger, the source provision and the pitfalls from which it arises; recommended review cycles are set out further below in the section 'Practical rhythm in the business'.

When data go missing: 72 hours

A breach of the security of personal data must be reported to the competent supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it — unless it is unlikely to result in a risk to the rights and freedoms of natural persons (Art. 33(1) GDPR). Where the report is made later, it must be accompanied by reasons for the delay. Where there is likely to be a high risk, notification of the data subjects is added (Art. 34(1) GDPR); it is not required where appropriate protection measures — in particular encryption — were applied, where the high risk no longer exists as a result of subsequent measures, or where the effort involved would be disproportionate — only in this last case does a public communication take its place (Art. 34(3) GDPR).

Practical classification from the Personal Data Breach procedure: a lost, encrypted hard drive is classified as a low risk (no report, no notification of data subjects), an unencrypted one as a high risk (report and notification of data subjects); an email containing master data sent to the wrong recipient is reportable but regularly does not trigger notification of data subjects.

Addressee: in Germany, companies report to the authority competent under Land law (§ 40(1) BDSG); the Federal Commissioner for Data Protection (BfDI) is competent for federal public bodies and certain providers of telecommunications services (§ 9(1) BDSG), not for trades businesses. In Austria, the Austrian Data Protection Authority (Datenschutzbehörde) is competent as the national supervisory authority (§ 18(1) DSG).

Germany and Austria: where they differ

The GDPR articles themselves (including Art. 6, Art. 7, Art. 28, Art. 33, Art. 35) apply identically in both countries. What differs is the supplementary national law and the competent supervisory authority — here is the overview, with references to the sections in which the details are set out in full:

• Germany: the BDSG applies in addition. Supervision of non-public bodies: the Land data protection authorities competent under Land law (§ 40(1) BDSG). Employee data under § 26 BDSG: see section 2; protection of a person's image under the KunstUrhG (right to one's own image, purely German law): see section 3; the designation thresholds in § 38(1) BDSG: see the obligations table.
• Austria: the DSG applies in addition. It provides for no numerical threshold for the data protection officer (§ 5 DSG additionally governs confidentiality and — in the public sector — freedom from instructions). Supervision: the Datenschutzbehörde as the national supervisory authority under § 18(1) DSG. Administrative fines of up to EUR 50,000 under § 62(1) DSG apply alongside Art. 83 GDPR — they cover separate offences, such as intentionally obtaining unlawful access to a data processing operation or intentional transfer in breach of data secrecy (§ 6 DSG). In addition, § 11 DSG provides for the proportionate application of Art. 83 GDPR — in particular a reprimand instead of a fine for first-time infringements. Protection of a person's image under § 78 UrhG instead of the KunstUrhG: see section 3; employee data (no equivalent to § 26 BDSG) and monitoring measures under § 96(1) no. 3 ArbVG: see section 2.

The fine framework in both countries is that of the GDPR: up to EUR 10 million or 2 % of the total worldwide annual turnover of the preceding financial year for infringements of, among others, Art. 25 to 39 GDPR (Art. 83(4) GDPR), and up to EUR 20 million or 4 % for infringements of the processing principles, the conditions for consent or the rights of data subjects (Art. 83(5) GDPR) — whichever is higher.

Practical rhythm in the business

The following rhythms and intervals are practical recommendations from implementation work; the deadlines referred to within them, by contrast, are statutory deadlines. The statutory obligations and their triggers are set out in the table above.

• Ad hoc on every change: new processing, new IT system, new Data Processor — add the RoPA row and review the data processing agreement.
• Quarterly: a RoPA review as the practical standard, particularly in growing businesses; as a lower limit, an annual review plus ad hoc cases is recommended (practical rhythm, not a statutory deadline).
• Before every publication: reconcile photo consents and the list of publication locations; what is filed is the consent given itself.
• After every recruitment procedure: put the deletion date in the calendar instead of 'tidying up at some point' — the deadline anchors for Germany and Austria are set out in section 6; what is documented is the deletion run carried out, not the intention.
• Always: version every RoPA change with a date and the person making it — if the supervisory authority asks, the currency of the record is part of Accountability (Art. 5(2) GDPR).