Logo
  • Home
  • Service
  • About LLH
  • FAQ
  • Contact

  • Email Tracking and Data Protection: France’s CNIL Requires Explicit Consent for Marketing Tracking from July 2026

    07.08.2026

    Tracking pixels are tiny, usually invisible images that are not embedded in the email itself but are loaded from a remote server when the message is opened. Through the individualised image URL, the sender learns whether, when and on which device an email was opened.

    The French data protection authority CNIL has published its final “Recommendation on tracking pixels in emails” on this subject and makes clear: reading out this information constitutes a read/write operation on the recipient’s terminal equipment within the meaning of Article 82 of the French Data Protection Act (Loi Informatique et Libertés), which implements Article 5(3) of the ePrivacy Directive. In doing so, the CNIL expressly follows EDPB Guidelines 2/2023 on the technical scope of the ePrivacy Directive.

    The recommendation states verbatim that the integration of tracking pixels constitutes “an instruction given to the user’s terminal to return targeted information” — that is, an instruction to the terminal equipment to send back specific information (pixel identifier, IP address, etc.).

    The consequence: as a general rule, the recipient’s prior, freely given, specific, informed and unambiguous consent is required unless an exemption applies.

    E-Mail Tracking

    Applicability

    The rules have applied since mid-July 2026 to recipients in France. The Italian supervisory authority will follow with comparable requirements in October 2026. Observers expect further EU supervisory authorities to adopt the CNIL’s approach: the position is based on the EDPB Guidelines and is therefore capable of being applied across the Union.

    What is actually new about this?

    The consent requirement as such is not new. Article 5(3) of the ePrivacy Directive has long applied in a technology-neutral manner to any access to terminal equipment. In Germany, section 25 TDDDG governs the same matter, and the fact that personalised newsletter tracking falls within its scope has been the settled European view since EDPB Guidelines 2/2023. Many companies therefore already obtain consent today, though often in the form of a blanket sentence in the newsletter sign-up text (“We analyse open and click rates in order to improve our content”), bundled together with the marketing consent. This is precisely where the CNIL comes in: the recommendation does not create new law, but for the first time defines in a binding and concrete manner how consent texts, sign-up forms and privacy policies for email tracking are to be designed.

    The following points are new in detail:

    Granularity instead of blanket consent. A collective consent covering “newsletter incl. tracking” is no longer sufficient. Each tracking purpose (campaign optimisation, profiling, fraud detection) requires its own active opt-in action — with a short title and a brief description for each purpose; the CNIL provides verbatim model wording for this (section 4.1). Only closely related purposes may be bundled, for example direct marketing expressly advertised as personalised together with the pixels used for that purpose.

    The cookie banner is not a suitable place. In a dedicated note, the CNIL clarifies that obtaining consent via a consent management platform on the website is problematic: users do not understand there that their choice concerns a different environment — their email inbox — and a specific email address; the informed nature of the consent is therefore lacking. The correct place is the newsletter sign-up form itself, at the point where the email address is collected.

    Concrete data minimisation requirements. For consent-free deliverability measurement, only the date of the last opening may be stored, to the day — without a time stamp, without any history, on an overwriting basis. Anyone who currently retains complete opening logs will have to adapt their systems.

    Concrete requirements on withdrawal. A withdrawal link in the footer of every email, withdrawal without having to re-enter the address, and effectiveness also for emails already sent when they are re-opened.

    Obligation to adapt the privacy policy. Even consent-free pixels (deliverability, authentication, compliance evidence) should, as good practice, be disclosed transparently in the privacy policy.

    In practice this means: the implementation effort lies less in the “whether” of consent than in revising existing consent texts, sign-up journeys and privacy policies — away from the blanket sentence and towards purpose-separated consents that have to be actively ticked, with documented evidence.

    Purposes requiring consent

    Under section 3.1 of the recommendation, the recipient’s consent is required in particular for the following purposes:

    Campaign optimisation and performance measurement. Analysing the open rate in order to measure and optimise campaigns — for example by personalising content, adjusting sending frequency or choosing the communication channel (email, SMS, push) — requires an opt-in. This also covers send-time optimisation based on individual opening times.

    Profiling. Creating recipient profiles based on observed preferences and interests in order to address individuals outside the email channel (websites, apps, other channels) requires consent. This includes classic practices such as follow-up campaigns to openers or non-openers, or triggering the next email in a series upon an opening.

    Fraud detection for the sender’s benefit. Detecting and analysing suspicious activity — for instance mass automated openings in prize draws or indications of ad fraud — also requires consent.

    Individual open measurement outside the deliverability exemption. Individual measurement of the open rate for deliverability purposes is exempt from consent only within the narrow limits of section 3.2 (see below); beyond that, the consent requirement applies.

    Purposes exempt from consent

    Section 3.2 of the recommendation lists purposes for which pixels may be used without consent — provided they are used exclusively for those purposes:

    Security measures in the context of user authentication, for example verifying whether an email containing an authentication code is in fact opened on a device attributed to the user.

    Individual open measurement for deliverability purposes. The CNIL acknowledges that managing distribution lists is, in practice, dependent on opening statistics. However, the controller must be able to demonstrate that the processing is limited to what is strictly necessary — specifically, adjusting the frequency or stopping sending to inactive recipients (database cleansing). Subject to that proviso, the following are additionally permissible: assessing and adjusting the communication channel (choosing alternative contact routes) and evidencing compliance with statutory information obligations (e.g. receipt of legally required communications within a contractual relationship).

    Strict data minimisation applies here: in principle, only the date of the last known opening may be stored — to the day, without a time stamp — with each new opening overwriting the previous entry. A history of opening behaviour is not permitted.

    Aggregated, anonymised open rates. According to the recommendation, the further use of effectively anonymised data does not constitute an additional interference within the meaning of Article 82; the GDPR remains applicable to the anonymisation process itself.

    Important: the exemptions apply only to emails that the recipient has requested or that relate to a service requested by them — in particular transactional emails (order confirmations, dispatch notifications, password resets, appointment confirmations, etc.) as well as emails from public authorities within the scope of their public task. The CNIL also points out that the consent regime for pixels is independent of the one governing the sending of the email itself: even for emails that may be sent without consent (e.g. marketing to existing customers), separate consent may be required for the use of pixels.

    How companies can implement the requirements

    At its core, implementation comes down to adapting three documents or processes: the newsletter sign-up form with its consent texts, the privacy policy, and the withdrawal/preference process. In detail:

    1. Audit of the current state.

    First, an inventory should be taken of which tracking pixels are in use, who sets them (in-house sending, email service provider, third-party technology) and for which purposes the opening data is actually used. The CNIL requires each actor to determine its role: the sender is regularly the controller (even where sending is outsourced), the email service provider is generally a processor; where list rental companies or technology providers also use the data for their own purposes, joint controllership under Article 26 GDPR may arise — with a corresponding obligation to conclude an arrangement.

    2. Obtain granular consent — ideally at the point of address collection.

    The CNIL recommends obtaining consent for the use of pixels already when the email address is collected, i.e. in the sign-up form. Each purpose must be presented with a short title and a brief description; the recommendation contains concrete wording examples for this. In principle, it must be possible to give consent separately for each purpose — one separate, non-pre-ticked checkbox per purpose. In two-tier consent solutions, an overall consent at the first level is permissible only if a purpose-specific choice (or a choice by related families of purposes) can be made at the second level. A single consent covering both direct marketing and pixels is possible only exceptionally, where the purposes are closely connected — for instance marketing expressly advertised as personalised together with the pixels used for it.

    3. Subsequent collection via a pixel-free email.

    Where consent could not be obtained at the point of address collection, it can be obtained subsequently by email — that email must not itself contain any tracker requiring consent. The link should lead to a page on which the person performs an active action (clicking a button), in order to avoid unintended “consents” caused by email clients automatically pre-loading links. Inactivity is to be treated as a refusal. As good practice, the CNIL suggests not re-approaching recipients who have refused for at least six months.

    4. Withdrawal as easy as giving consent.

    The CNIL recommends an individualised link in the footer of every email leading to a page where withdrawal is possible without further hurdles — in particular without having to re-enter the email address. The withdrawal must be effective: pixels that have already been set must no longer be evaluated when old emails are re-opened.

    5. Evidence of consent.

    Under Article 7(1) GDPR, consent must be demonstrable on an individualised basis at any time. Where consent is obtained by third parties (such as list brokers), a mere contractual clause is not sufficient — but the contract can govern evidence mechanisms, retention and regular audits. The controller’s liability remains in place if the third party is unable to provide the evidence.

    6. Transitional arrangement for existing addresses.

    For addresses already collected, tracking may initially be continued provided that recipients are informed clearly and accessibly within, in principle, three months from publication of the recommendation and can object to the use for future emails. In practice this meant: anyone who has not informed existing subscribers (sign-up before 14 April 2026) by 14 July 2026 and given them an opt-out option must now actively obtain consent on an opt-in basis. For addresses collected after 14 April 2026 and before the go-live of the new opt-in process, the opt-in requirement applies from the outset, as for new subscribers.

    7. Transparency also for consent-free pixels.

    Article 82 does not require separate information for consent-free uses; the CNIL nevertheless recommends, as good practice, disclosing them in the privacy policy.

    What happens in the event of non-implementation?

    The recommendation itself is formally non-binding (“neither regulatory nor exhaustive”), but it gives concrete shape to binding law: Article 82 of the Loi Informatique et Libertés and thus Article 5(3) of the ePrivacy Directive. The CNIL can sanction infringements of Article 82 directly — and has done so consistently for years: the cookie fines against Google (EUR 150 million in total) and Amazon (EUR 35 million) were based on precisely this provision; the fining framework extends up to EUR 20 million or 4% of worldwide annual turnover. Since, by its own account, the CNIL is receiving an increasing number of complaints about email pixels, enforcement by the supervisory authority is to be expected. In addition, there are civil law risks (data subject rights, damages under Article 82 GDPR) and — where downstream data processing takes place without a legal basis — parallel GDPR infringements, since the recommendation makes clear that any further processing of the data obtained via pixels must additionally satisfy the requirements of the GDPR.

    Alongside the legal risk, practical considerations also argue for a realignment: since Apple’s Mail Privacy Protection, opening data has in any event been of only limited reliability, and since November 2025 measured Gmail open rates have fallen by around 30% as a result of stricter requirements for bulk senders. Marketing professionals are therefore increasingly shifting performance measurement and segmentation to clicks, conversions, website activity and zero-party data (preference centres) — signals that can at the same time be structured in a more robust way from a data protection perspective.

  • Pseudonymised is not anonymous – EUR 5 million against IQVIA and what MedTech should take from it

    07.08.2026

    CNIL decision of 26 May 2026 – SAN-2026-008 (IQVIA Operations France)

    Anyone consolidating health data at scale cannot fall back on the argument that the result is “anonymous” and therefore outside the scope of the GDPR. That calculation did not work out for IQVIA’s French entity: the CNIL imposed a fine of EUR 5 million.

    The facts in brief

    IQVIA produces studies for the pharmaceutical industry and operated two health data warehouses for this purpose, both previously authorised by the supervisory authority. They were fed from roughly 14,000 pharmacies and from several thousand physicians. The inspection revealed that data subjects were not properly informed, that data subject rights were ineffective in practice, and that the technical safeguards fell short of what was required.

    The company’s line of defence: the datasets were anonymous, so data protection law did not apply in the first place.

    Why the authority saw it differently

    In the CNIL’s assessment the datasets were not anonymous but pseudonymised, because tracing them back to individuals remained possible with reasonable effort. Three considerations carried that finding:

    1. A persistent identifier per patient, tying every data point of an individual together.
    2. The level of detail held – including year of birth, sex, treating general practitioner, prescriptions, diagnoses, symptoms, allergies, body measurements, vital signs, vaccination status, examinations performed and periods of sick leave.
    3. The ability to combine the data with publicly accessible sources. How low that threshold actually sits was demonstrated in the proceedings: through a patient support group on a social network, a study participant was matched within minutes.

    Two further points matter particularly for day-to-day practice:

    • Contractual re-identification bans are not enough. Prohibiting partners from re-identifying by agreement does not change the objective possibility. A statutory prohibition may be assessed differently – a contract clause is no substitute.
    • Intention is irrelevant. The fact that nobody in the organisation wanted to re-identify anyone was expressly treated as immaterial. What counts is whether it could be done.

    How this sits alongside the CJEU’s SRB judgment

    The company was able to invoke a line of authority that is genuinely favourable to data recipients: on 4 September 2025 (C-413/23 P, SRB), the CJEU confirmed a relative standard. The same pseudonymised dataset may constitute personal data in the hands of the party holding the key while being anonymous for a third party with no means of attribution.

    The CNIL draws the line where the role changes: IQVIA was not a recipient at the end of a chain but controller of the entire processing operation from the point of collection onwards – and the party creating the linkage in the first place. The relativity established in SRB relieves the third party without the key. It does not relieve the party that designs the warehouse, populates it and controls the linking logic.

    The additional findings

    Beyond the anonymity question, the authority criticised concrete implementation gaps: access logs were not reviewed systematically, multi-factor authentication was absent, patient information was inaccurate, and no functioning objection procedure was in place. On top of that, some pharmacies failed to inform their own customers correctly about the transfer, and the pharmacy software transmitted patient data without consent – a textbook privacy-by-design failure already built into the product architecture.

    In setting the amount, the sensitivity of the category, the volume (several tens of millions of data subjects), the market position and the financial strength of the company were treated as aggravating. The pseudonymisation actually carried out was recognised as mitigating, since it did rule out direct identification.

    Dos

    • Derive anonymity demonstrably rather than asserting it. Document, for each dataset, which attack scenarios (singling out, linkability, inference) you tested and how you excluded them.
    • Differentiate by constellation. What may be anonymous vis-à-vis an external recipient remains personal data internally. Determine the status separately for each recipient role.
    • Attack the identifier, don’t just mask it. Consider aggregation, k-anonymity, noise, generalisation of date fields, and breaking up longitudinal records.
    • Actively limit data depth. Every additional attribute – a vital sign, a prescription, the treating clinician – shrinks the comparison group. Fewer attributes is the legally more robust design here as well.
    • Get the basics working: intelligible patient information, a functioning objection route, systematic review of access logs, MFA on privileged accounts.
    • Think upstream. Where clinics, practices or pharmacies collect on your behalf, their information and legal basis chain is your risk – down to the configuration of the software they use.
    • Keep authorisations current. A regulatory approval protects you only to the extent that actual practice matches it.

    Don’ts

    • Don’t rely on SRB if you are the one performing the consolidation. The relative standard helps the third party without means of attribution – not the operator of the dataset.
    • Don’t treat contractual clauses as an anonymity argument. A re-identification ban is a sensible addition, but no substitute for technical effectiveness.
    • Don’t argue absence of intent. What is assessed is the possibility, not the motive.
    • Don’t use “pseudonymised” and “anonymous” interchangeably – not internally, and not in records of processing, privacy notices or customer-facing statements.
    • Don’t ignore publicly available sources. Social networks, patient forums and public registers belong in the risk assessment.
    • Don’t treat AI training data as a special case. The same standard applies to real-world evidence products, registry analyses and model training.

    What this means for MedTech specifically: this affects anyone maintaining post-market surveillance data, device telemetry, registry data or RWE datasets with stable identifiers over time. The combination of a persistent identifier and an expanding set of attributes is precisely the pattern the CNIL held to be incapable of anonymisation here.

    CNIL decisions are open to judicial review, so the case is not necessarily settled. For practical purposes, that changes little about the analytical framework applied.

  • Security Screening in the Workplace: What Employers Need to Know

    05.06.2026

    When your employees come into contact with government contracts, classified information, or critical infrastructure, a standard hiring process quickly becomes a legally demanding procedure. Here’s what to expect – and where the pitfalls lie.

    When Does This Apply to You?

    Security screenings are not an issue exclusively for public authorities. Private companies are also affected as soon as they execute government contracts where employees gain access to security-relevant information or work in so-called security-sensitive positions.

    The law identifies two main categories:

    Personnel classified information protection: Employees who are to be given access to information classified as VS-CONFIDENTIAL, SECRET, or TOP SECRET must be vetted in advance.

    Preventive personnel sabotage protection: Anyone working in a security-sensitive position within a facility that is vital to life or national defense – for example in energy supply, water supply, telecommunications, or the defense industry – also falls within the scope of the law.

    Whether your company or specific positions are concretely affected is decided by the competent public authority. At the federal level, this is generally the Federal Ministry for Economic Affairs and Climate Action (BMWK); at the state level, the relevant state authority.

    The Three Screening Levels

    The Federal Security Screening Act (SÜG) – most recently amended by the Act Modernising the SÜG in January 2026 – provides for three graduated levels of screening:

    Ü1 – Basic Security Screening Applies where there is the possibility of access to VS-CONFIDENTIAL classified information. Queries are made with the domestic intelligence service, the Federal Central Criminal Register, the Commercial Central Register, the Federal Criminal Police Office, and the police authorities at previous places of residence. An internet search of publicly visible content is also conducted – under current law explicitly including social media.

    Ü2 – Extended Security Screening Applies where there is access to SECRET-classified information or a large volume of VS-CONFIDENTIAL material. Additionally, identity and previous addresses are examined in greater depth; social media may be reviewed.

    Ü3 – Extended Security Screening with Security Investigations The most intensive level, applying to TOP SECRET matters or work at intelligence agencies. In addition, reference persons named by the individual concerned as well as other suitable informants are interviewed.

    Your Obligations as an Employer

    Registration: Before any screening of your employees can even be requested, you must register your company with the BMWK or the BDBOS under the preventive personnel sabotage protection scheme. This requires a formal letter from management designating a sabotage protection officer.

    Security officer: The tasks associated with the security screening must be handled within the company by a unit separate from regular HR – HR must not have access to the outcome of the screening (§ 25(5) SÜG).

    Initiating the process: You can trigger a screening by writing to the BMWK describing the security-sensitive activity and enclosing the written consent of the person concerned.

    Outcome: The BMWK will only inform you whether clearance can be granted or not – you will not receive any substantive details from the screening.

    Checking the prerequisites: Importantly, before initiating a screening you should carefully verify that the statutory requirements are actually met. A screening that is not justified can have consequences under employment and data protection law.

    Employee Consent – Without It, Nothing Works

    A security screening requires the written consent of the person concerned without exception. This is non-negotiable. Without consent, the process may not be initiated.

    This puts you, as an employer, in a practical position: what happens if an employee or applicant refuses? The person simply cannot perform the security-sensitive role. Whether this has employment law consequences – for example at the point of hiring or in the context of an ongoing employment relationship – depends on the individual case and should be assessed legally.

    The GDPR is, according to the prevailing view, not applicable to the security screening process itself (Art. 2(2)(a) GDPR). For your transmission of data as an employer to the authority, Art. 6(1)(b) GDPR may serve as the legal basis where the screening is necessary for the performance of the employment relationship, because the employees would otherwise be unable to fulfil their contractually owed duties.

    What Is Examined and What Constitutes a Security Risk

    The law defines three categories of security risk (§ 5 SÜG):

    First, doubts as to the reliability of the person in carrying out a security-sensitive activity. Second, a particular vulnerability to approaches or recruitment attempts by foreign intelligence services or extremist organisations. Third, doubts about the person’s commitment to the free democratic basic order.

    In practice, the following aspects are relevant: membership in anti-constitutional groups (including suspected cases), extremist statements on social media or in chats, liking or sharing such content, tattoos bearing relevant symbols, contacts with such persons, and false statements in the security declaration. The last point is particularly sensitive: anyone who provides false information in the security declaration regularly risks a finding of a security risk – regardless of the substantive allegation.

    Important for practice: A finding of a security risk requires only actual indications. There is no need for a criminal conviction. In cases of doubt, the security interest takes precedence (§ 14(3) SÜG).

    Excursus: Lie Detectors – Legal and Practical Considerations

    In the context of security screenings, the question occasionally arises as to whether the use of a polygraph (colloquially: lie detector) is or could be permissible.

    The answer in Germany is clear: its use is not recognised as a means of evidence in either criminal proceedings or employment law. The Federal Court of Justice has fundamentally rejected its admissibility on the grounds that the method lacks scientific reliability. Based on current knowledge, no clear connection can be established between physical reactions such as pulse, blood pressure, and perspiration and whether a person is lying.

    The Federal Labour Court confirmed in 2023 (BAG, 28.02.2023 – 2 AZR 194/22; BGH 30 November 2010 – 1 StR 509/10 – para. 6; 24 June 2003 – VI ZR 327/02 – paras. 6 ff.; BVerwG 31 July 2014 – 2 B 20.14 – paras. 9 ff.) that a polygraph result does not constitute a suitable means of evidence in employment court proceedings.

    Beyond this, there are significant data protection and personal rights concerns: the processing of biometric and health-related data captured in the process constitutes a serious interference for which there is generally no adequate legal basis. Given the typical dependency inherent in an employment relationship, truly voluntary consent is scarcely conceivable. Works council co-determination rights may also apply.

    In short: the lie detector remains a legally impermissible instrument in Germany – including, and especially, in the context of security screenings.

    What Does This Mean for Your Company in Practice?

    If you are pursuing a government contract that requires security screening of your employees, we recommend the following steps:

    First, verify whether the statutory requirements for a screening are actually met. Clarify at an early stage which employees are specifically affected and whether they are prepared to complete the required security declaration. Ensure that a unit separate from HR is responsible for handling the process within your company. Allow for the time involved: security screenings can take months and should therefore be initiated well in advance of the planned deployment of the employees. Document the consent of the persons concerned carefully and in the legally prescribed form.

    Our Conclusion

    Security screenings are not a bureaucratic end in themselves, but a legally regulated procedure with real consequences for both sides – companies and employees alike. Anyone who fails to carefully examine the prerequisites or initiates the process incorrectly risks not only the failure of the contract, but also employment and data protection law problems.

    At Legal Living Hub, we advise you both on determining whether a screening is required in your specific case and on implementing the entire process in a data protection-compliant manner.

    Legal status: June 2026 | This article is for general information purposes only and does not replace individual legal advice.

    Further information is available from the Federal Commissioner for Data Protection and Freedom of Information (BfDI): https://www.bfdi.bund.de/DE/Buerger/Inhalte/SÜG/FAQ.html

  • Data Protection for Freelancers: Avoiding Legal Pitfalls

    09.03.2026

    Your company now wants to work with freelancers, i.e. independent contractors. There are several advantages, such as flexible deployment on an invoice basis without employment law obligations. At the same time, there are legal questions that need to be considered and clarified. Depending on how closely a freelancer is integrated into your business, completely different rules apply. And you should know them – otherwise you risk not only trouble with the data protection authority, but in the worst case also consequences under social security law.

    This article focuses in particular on the data protection hurdles.

    A Freelancer is Not Just a Freelancer

    When you bring in external specialists and they process personal data for you or with you, this can take on very different legal forms. The GDPR recognises several models for classifying freelancers as data recipients in the context of data protection:

    • Independent controller (Art. 24 GDPR)
    • Joint controllers (Art. 26 GDPR)
    • Processor (Art. 28 GDPR)
    • Person subject to the authority of the controller (Art. 29 GDPR)

    Which model applies to your situation depends on the specific working relationship. And this is where it gets interesting.

    The Decisive Factor: How Much Control Do You Exercise Over a Freelancer?

    The central question is: How much do you dictate to the freelancer what to do and how to do it?

    A lot of autonomy

    If the freelancer decides for themselves the purpose and manner in which they process data, they act as an independent controller. In that case, they are a third party under data protection law and bear full responsibility themselves. If you jointly determine the purpose and nature of the data processing, joint controllership applies. In both cases, a Data Processing Agreement is required – clearly regulating responsibilities and their limits.

    Subject to instructions, but organisationally independent = Processor

    The term “subject to instructions” is already tricky in the context of a freelancer contract. However, if a freelancer processes data on your behalf and that work is bound by your instructions, this constitutes order processing.

    Caution! It is important to note here that even though someone works according to your content guidelines, they should still distance themselves from your organisation as much as possible – for example, by using their own tools or by independently deciding on their working hours and location. In this case, you absolutely need a Data Processing Agreement (DPA) that precisely governs what is to be done and how, and in particular that the instructions relate exclusively to data processing.

    When Is a Freelancer to Be Classified as an Employee?

    If your freelancer effectively works like an employee, they may qualify as a “person subject to the authority of the controller” within the meaning of Art. 29 GDPR. That sounds practical at first, but it has its pitfalls.

    The following points indicate that someone is legally treated like an employee:

    • Works with your hardware and software
    • Has fixed working hours on your premises
    • Uses your time-tracking systems
    • Wears a staff ID badge
    • Submits regular project reports
    • Has little scope to exercise their own judgement in performing tasks
    • Is integrated into workflows just like your permanent employees

    Caution: Bogus Self-Employment!

    Now it gets tricky: if someone is as closely integrated as an employee – why are they still “self-employed”? This is where the danger of bogus self-employment lurks, which can have massive employment, social security, tax, and even criminal law consequences for both parties.

    Bogus self-employment exists when someone is formally engaged as self-employed but is in fact in a dependent employment relationship and would actually need to be employed subject to social security contributions.

    Additional warning signs include:

    • No work for other clients
    • Non-competition and secondary employment restrictions
    • No use of own capital or resources
    • Inability to engage third parties to perform the service

    Important to understand: The data protection classification is not identical to the social security law assessment. You can classify someone as a person subject to authority under Art. 29 GDPR without this automatically constituting bogus self-employment – but the areas overlap significantly. So: keep your eyes open when drafting contracts!

    How to Avoid Mistakes

    The different classifications require a careful case-by-case review. Our tip:

    • Analyse the actual working relationship – not just what the contract says
    • Clearly distinguish between order processing and Art. 29 GDPR – do not use Art. 29 as an excuse to avoid a proper DPA
    • Document everything carefully – precise contracts are your best protection
    • Review regularly – working relationships evolve, and so does their legal classification

    Legal Living Hub Takes Care of It for You

    Sounds complicated? It is. But that’s what we’re here for.

    At Legal Living Hub, we help small businesses like yours stay on the safe side of the law. We analyse your freelancer collaboration, classify it correctly under data protection law, and create the appropriate contracts – whether DPA, joint controllership agreement, or confidentiality declarations.

    That way, you can focus on your business, while we make sure you don’t receive any unpleasant correspondence from the data protection authority or the pension insurance provider.

    Let’s talk about your freelancer situation – together we’ll find the legally clean solution for your company.

  • Cybersecurity Regulations Overhauled: NIS-2 Launches in Germany

    08.12.2025

    On December 5, 2025, the Act on the Implementation of the NIS-2 Directive and the Establishment of Fundamental Standards for Information Security Management within the Federal Administration was officially promulgated. Just one day later, on December 6, this comprehensive reform of German cybersecurity law came into force. The new regulations tighten security requirements for both federal authorities and numerous private-sector organizations.

    Organizations are required to independently assess whether they fall within the scope of the NIS-2 Directive.

    This may make them part of the approximately 29,500 entities that will be subject to BSI supervision and face new IT security obligations. Previously, only around 4,500 organizations were subject to the regulations of the BSI Act – primarily KRITIS operators, digital service providers (DSP), and entities of particular public interest (UBI).

    Through the NIS-2 Implementation Act, the scope of application of the BSIG (Federal Office for Information Security) has been significantly expanded: Organizations operating in specific sectors and meeting the legally defined thresholds for number of employees, annual turnover, and balance sheet total will in future be classified as “important entities” and “particularly important entities.”

    When Does Your Company Fall Under NIS-2?

    A company is subject to NIS-2 regulations if two conditions are met simultaneously: First, it must operate in one of the sectors defined in § 28 and Annex 1 of the NIS-2 Implementation Act.

    Second, it must meet or exceed certain size thresholds.

    The size thresholds are based on the EU recommendation for the definition of micro, small, and medium-sized enterprises. A company is considered medium-sized and thus falls under NIS-2 if it has at least 50 employees or has an annual turnover or annual balance sheet total of at least 10 million euros. It is sufficient if one of these two financial criteria is met.

    Companies that do not meet these thresholds generally do not fall under NIS-2 obligations. However, there are exceptions for particularly critical areas. KRITIS operators must always be classified as particularly important entities regardless of their size. Certain providers of digital services may also be covered regardless of thresholds if their services are particularly relevant to society or the economy.

    Affected Sectors and Providers

    The new regulations cover, among others, operators of online marketplaces. Additionally, the following providers fall within the scope: DNS service providers, TLD name registries, cloud computing providers, data center service providers, content delivery network operators, managed service providers, managed security service providers, search engine providers, social media platforms, and trust service providers.

    Indirect Impact on Software Providers

    Software providers that supply solutions to NIS-2-regulated companies should also pay particular attention to the new regulations. Although they may not be directly subject to the NIS-2 Directive themselves, they may become relevant as an integral part of, for example, a KRITIS company. In this context, they will be considered during audits or risk assessments of the regulated entity. In such cases, software providers must also be able to provide all relevant documentation and evidence.

    Core Obligations for Affected Companies

    Affected organizations must fulfill three main obligations:

    Registration requirement: There is a legal obligation to register as an NIS-2-regulated organization.

    Reporting requirement: Significant IT security incidents must be reported to the BSI.

    Risk management: Implementation and documentation of risk management measures is required.

    Operators of critical infrastructure are automatically assigned to the category of “particularly important entities.”

    Registration Process: Special Importance of BSI Portal Registration

    The BSI is introducing a two-stage registration (BSI explains) procedure for NIS-2-obligated organizations with a German tax identification number. First, companies must register via “Mein Unternehmenskonto” (MUK – My Business Account). This serves as a central user account for digital administrative services and is technically based on ELSTER. Existing ELSTER certificates can be used for this purpose.

    The BSI recommends completing registration in MUK by the end of 2025. From January 2026, registration will then take place in the new BSI portal, which launches on January 6, 2026. This portal will be used to report relevant security incidents, among other things. Until registration in the BSI portal, incidents can be reported via an online form. KRITIS operators and federal agencies will continue to use their existing reporting channels.

    Definition of Significant Security Incidents

    According to the BSI Act, a significant security incident exists when an event significantly disrupts or damages an organization’s operations or finances – or when it can significantly affect other persons materially or immaterially (§ 2 No. 11 BSIG).

    For certain digital services (e.g., cloud providers, data centers, online marketplaces, search engines, social networks, managed service providers), EU Regulation 2024/2690 applies additionally. According to this regulation, an incident is considered significant if, for example:

    • financial damage exceeding €500,000 or 5% of annual turnover is threatened or occurs,
    • business secrets are leaked,
    • people die or are seriously injured,
    • a successful, malicious hacker attack with severe operational disruptions occurs,
    • or other specifically named impacts in the regulation occur.

    Planned maintenance and announced outages are explicitly not considered significant security incidents.

    What Companies Should Do Now

    Companies should first assess whether they fall under the NIS-2 Directive. Then they should register with “Mein Unternehmenskonto” in 2025. Registration in the BSI portal should be prepared from January 6, 2026 onward. In parallel, companies must implement risk management measures and carefully document all measures taken. Additionally, they must ensure they can detect and properly report security incidents.

    Further information can be found on the BSI website.

    We support you in implementing the new NIS2 requirements:

    • Applicability check: Determining whether your company falls under NIS2.
    • Gap analysis: Assessing the difference between your current security level and NIS2 requirements.
    • Implementation roadmap: Creating a concrete plan with priorities, actions, and timelines.
    • Training: Workshops for management and staff on NIS2 obligations and reporting processes.

    Secure a free 30-minutes consultation with Legal Living Hub

    Contuct us

  • GEMA vs. OpenAI: Landmark Ruling on Copyright in the AI Era

    26.11.2025

    The Case That’s Shaking the AI Industry

    On November 11, 2025, the Munich Regional Court issued a decision* that could have far-reaching consequences for the development of artificial intelligence. GEMA, Germany’s largest music rights management organization, had sued OpenAI – and won. The allegation: ChatGPT had used copyrighted song lyrics without a license and reproduced them almost verbatim.

    *LG München I, Endurteil v. 11.11.2025 – 42 O 14139/24– can be found here: gesetze-bayern.de

    The Core Question: What is Text & Data Mining?

    In its defense, OpenAI had invoked so-called Text & Data Mining (TDM). This exception anchored in copyright law generally allows the use of protected works for automated analysis of large data sets. The idea behind it: science and research should be able to recognize patterns and correlations in texts without having to acquire a license for each individual text.

    GEMA vs. OPENAI

    However, the Munich court made it clear: What OpenAI was doing goes beyond pure TDM. The crucial difference lies in the type of use. TDM typically analyzes data and derives new insights from it. ChatGPT, however, had apparently processed the song lyrics in such a way that they could later be output almost word-for-word.

    The Problem of “Memorization”

    A central concept in this legal dispute is so-called “memorization.” This refers to the process by which AI systems go beyond simply learning patterns from training data. Instead, they effectively store this content and can later reproduce it.

    In large language models like ChatGPT, memorization can occur under specific conditions. This happens when certain texts are processed so frequently during training or are so distinctive that the model essentially “memorizes” them. The system then develops the ability to reproduce these texts almost identically. This process is similar to a human who has memorized a poem.

    It was precisely this memorization that became OpenAI’s undoing. The court’s argumentation addressed a crucial distinction in AI usage. When an AI internalizes copyrighted works so strongly that it can reproduce them verbatim, it crosses a legal boundary. This is no longer permissible analysis, but constitutes unauthorized reproduction and public communication.

    The Legal Classification

    The Munich Regional Court established a clear boundary in AI copyright law. When AI training results in content being permanently retained or later reproduced word-for-word, it exceeds the scope of the TDM exception. This exception is intended only for pure analysis, not for the reproduction of protected works.

    Therefore, if an AI application uses and reproduces song lyrics without a license, developers violate German copyright law. This directly interferes with the economic exploitation interests of the creators. Users could then access texts via AI instead of purchasing them from licensed providers.

    Reactions and Outlook

    Dr. Tobias Holzmüller, CEO of GEMA, was combative after the verdict: The internet is not a self-service store and human creative achievements are not free templates. They had created a precedent that makes clear – operators of AI tools must also comply with copyright law. Therefore GEMA sees the verdict as a successful defense of musicians’ livelihoods (Zitat: gema.de)..

    The verdict is not yet legally binding. OpenAI could appeal, and it remains to be seen whether higher courts will share the Regional Court’s assessment.

    What Does This Mean for the Future?

    This decision could have profound implications for the development and deployment of AI systems. Companies may need to rethink their training methods and ensure that their models cannot memorize and reproduce protected content. This could lead to technical adjustments, such as filters that prevent copyrighted texts from being output.

    At the same time, the verdict raises fundamental questions: How can AI developers ensure that their systems do not violate copyrights? What technical measures are necessary and practicable? And how can innovation in AI development be reconciled with the protection of creative works?

    In any case, the Munich verdict makes one thing clear: The message “Copyright remains in force – even in the AI age” has reached the courts. Song lyrics and other creative works are not free training resources for artificial intelligence. Those who want to use them must pay for it – or find technical ways that exclude memorization and reproduction.

    You want to read more about AI? Check out our articles on “What is an AI System?” and “CRA vs. AI Act“.

    Do you have questions about using AI systems? Secure your free initial consultation now!

    Secure a free 30-minute initial consultation

  • When Do You Need a Data Protection Officer?

    25.10.2025

    Send us an email to [email protected] and receive a Checklist “Does My Company Need a Data Protection Officer (DPO)?

    Are you wondering whether your company needs a Data Protection Officer (DPO)? Many business owners and managers ask themselves this question. The good news: there are clear rules that can help you make this decision.

    The Data Protection Conference (DSC), a body of the independent data protection authorities of Germany’s federal and state governments, has published a short paper that serves as an initial guide explaining when do you need a DPO. It’s aimed particularly at organizations outside the public sector and explains when, in the DSC’s view, a Data Protection Officer is required. It also outlines which rules apply to both controllers and processors in this regards.

    The Three Most Important Situations When You Must Act

    In Germany, there are three specific cases in which you must appoint a Data Protection Officer — regardless of what the EU General Data Protection Regulation (GDPR) requires:

    1. You Have at Least 20 Employees with Data Access

    Once you regularly employ 20 or more people who handle personal data automatically, appointing a Data Protection Officer becomes mandatory.

    Important to know: The term “people” is interpreted broadly. It includes not only full-time employees but also:

    • Part-time staff
    • Temporary workers
    • Freelancers
    • Trainees

    However, your management team is not counted — they are not considered “employees” in the traditional sense, as they lead the company rather than being employed by it.

    What does “automated processing” mean?
    It’s easier to meet this condition than many think. Even if your employees send business emails, they are already processing personal data. Typical departments affected include:

    • Customer service and sales
    • IT department
    • Human resources
    • Accounting

    2. You Conduct High-Risk Data Processing

    If your company carries out processing activities that require a Data Protection Impact Assessment (DPIA), you would also need a DPO. This obligation can arise even from a single such processing activity.

    A DPIA is necessary when your data processing is likely to pose a high risk to the rights and freedoms of individuals. This is often the case in situations such as:

    Automated evaluations and profiling
    If you systematically create profiles of individuals or automatically assess them — for example, through scoring systems or automated decisions about credit approval or recruitment.

    Extensive processing of sensitive data
    This includes particularly sensitive information such as:

    • Health data
    • Ethnic origin
    • Religious or political beliefs
    • Criminal convictions or offenses

    Systematic monitoring of public areas
    Video or audio surveillance in publicly accessible areas falls into this category. The use of sensors that systematically observe their surroundings can also qualify.

    3. You Process Data on a Commercial Basis

    If you process personal data commercially — for example, to transfer, anonymize, or use it for market or opinion research — you must appoint a DPO.

    When Does It Become Particularly Critical?

    The likelihood that you’ll need to carry out a DPIA (and therefore appoint a DPO) increases significantly if your data processing meets at least two of the following criteria:

    • You evaluate or classify individuals
    • You make automated decisions with legal consequences
    • You carry out systematic monitoring
    • You process particularly sensitive or personal data
    • You process data on a large scale
    • You combine different data sets
    • You process data of vulnerable individuals (e.g., children)
    • You use innovative or new technologies
    • Your processing prevents individuals from exercising their rights or accessing services

    Not Sure Whether You Need a DPO?

    Get in touch with us, and we’ll help you determine whether your company falls under this obligation.
    With Legal Living Hub, you’ll receive modern data protection consulting and AI compliance guidance at eye level.

    Conclusion

    The decision about whether you need a Data Protection Officer is usually quite straightforward. Simply check whether one of the three main situations applies to your company. When in doubt, it’s best to consult an expert — because fines for violations can be severe.

    Remember: appointing a Data Protection Officer isn’t just about compliance. It’s also an opportunity to minimize data protection risks and build greater trust with your customers.

    If you need legal support with the assessment, get in touch with us.

    Secure your free 30-minute initial consultation.

  • Compliance Essentials for Founders

    19.10.2025

    Building a company in 2025 means building with trust from day one. Founders who treat privacy, security, and AI governance as core product features scale faster, avoid rework, and inspire investor confidence. 

    This article summarises our masterclass into a practical guide you can implement immediately.

    Why Compliance Matters

    Compliance = Trust + Credibility + Scalability.

    Compliance is not bureaucracy, it’s your growth strategy. Investors, partners, and customers expect transparency, accountability, and readiness from day one. Laying the foundations early helps you avoid costly fixes and product delays later.

    Sanctions and Business Risks

    Understanding the potential risks of non-compliance is essential for every founder. Regulatory frameworks like the GDPR and the EU AI Act are designed to protect individuals and ensure responsible innovation but violations can be costly. Beyond financial penalties, non-compliance can damage your brand, delay product launches, and erode investor and customer trust. The following overview highlights the main legal and financial risks founders should be aware of when handling data or deploying AI systems.

    • GDPR: Administrative fines up to €20 million or 4% of global turnover. Common triggers include data misuse, insufficient security, and unlawful processing.
    • Unlawful marketing: Unsolicited communications can lead to claims of harassment, individual damages (around €5,000 per person), and legal expenses.
    • EU AI Act: Non-compliance with transparency, risk, or data-governance obligations can result in fines of up to €35 million or 7% of annual turnover. High-risk AI faces the strictest rules.

    First Steps: Your Legal Foundations

    Every successful company begins with a sound legal foundation. Before focusing on product growth or marketing, founders should ensure that their business model and digital presence are compliant from the start.

    1. Check your business model.

    Begin by confirming that your activities are lawful in all target markets. Review whether your product or service requires any licences, certifications, or regulatory approvals before launch. At the same time, assess whether your business falls under the obligation to appoint a Data Protection Officer (DPO), a requirement for many data-driven or customer-facing companies in the EU.

    2. Fix your online presence.

    Your website is your company’s legal face to the world. Make sure it includes a clear and complete imprint (legal notice), an up-to-date privacy policy written in plain language, and a cookie banner that allows users to make an informed, balanced choice without manipulative design patterns. Don’t forget well-structured Terms & Conditions (T&Cs) and the mandatory consumer information that protects both you and your users.

    3. Contact customers lawfully.

    Before sending newsletters, promotional emails, or outreach messages, clarify who you may contact and on what legal basis. Marketing activities must comply not only with the GDPR but also with anti-spam and e-privacy regulations, which differ slightly between EU member states. Aligning your communication strategy with these rules helps you build trust, avoid fines, and keep your brand reputation intact.

    GDPR Essentials for Startups

    Why GDPR Still Matters in 2025

    Since May 2018, the General Data Protection Regulation (GDPR) has set the global benchmark for data privacy and accountability. It’s not just a European framework, it has influenced data protection laws from California to South Africa and continues to shape how startups handle personal data worldwide.

    For founders, the GDPR is both a legal requirement and a business opportunity. Implemented early, it becomes a foundation for trust, transparency, and scalability. Ignored, it can lead to reputational damage, product delays, and significant financial risks. Under the regulation, national supervisory authorities can impose fines of up to €20 million or 4% of global annual turnover, whichever is higher. But more often, the real cost of non-compliance lies in lost investor confidence and user trust.

    Core Principles Every Founder Should Know

    The GDPR is built around six key principles that should guide every product and data-handling decision:

    • Lawfulness: Every data processing activity must have a valid legal basis  such as contract performance, consent, or legitimate interest.
    • Fairness and Transparency: Individuals must understand how and why their data is used. Hidden or overly complex privacy notices violate both the letter and the spirit of the law.
    • Data Minimisation: Collect only the data you actually need. More data doesn’t mean better insight, it often just means more liability.
    • Purpose Limitation: Use data only for the specific purpose you’ve communicated to users. Repurposing data without a new legal basis is one of the most common GDPR breaches.
    • Accuracy and Storage Limitation: Keep data up to date and don’t store it longer than necessary. Define clear retention periods and deletion processes.
    • Integrity and Confidentiality: Implement security measures to protect data against unauthorised access, loss, or destruction.

    Practical Steps to Stay Compliant

    Turning these principles into practice requires both strategy and structure. Here’s how to begin:

    1. Map your data. Identify what personal data your startup collects, where it’s stored, who can access it, and for what purpose. A clear data inventory helps you meet documentation requirements and quickly respond to data subject requests.
    2. Manage access control. Limit access to personal data strictly to those who need it to perform their work. Implement strong authentication (e.g. MFA) and keep audit trails.
    3. Strengthen technical security. Encryption, regular backups, patching, and incident response plans aren’t optional, they’re essential for compliance and resilience.
    4. Formalise relationships with vendors. Whenever a third party processes data on your behalf, sign a Data Processing Agreement (DPA) and ensure they meet equivalent security and privacy standards.
    5. Manage international transfers. If you use tools or providers outside the EU, apply Standard Contractual Clauses (SCCs) and perform a transfer impact assessment to ensure adequate safeguards.
    6. Prepare for incidents. When a data breach occurs, you may have to notify the supervisory authority within 72 hours. Having an incident response plan can make this manageable and prevent escalation.

    Common Pitfalls to Avoid

    Many startups make the same avoidable mistakes:

    • Outdated or hard-to-find privacy policies. Your privacy notice must be clear, accessible, and written in plain language.
    • Overreliance on consent. Not every data use requires consent. In fact, consent can be withdrawn at any time, so it’s important to use it only where necessary.
    • Manipulative cookie banners. “Accept all” buttons that are easier to click than “Reject all” risk enforcement actions and reputational harm.
    • Excessive form fields. Asking for more data than needed, especially in contact or sign-up forms which violates data minimisation principles.
    • Ignoring small incidents. A pattern of minor lapses can reveal deeper systemic issues later. Every incident should be assessed, documented, and reviewed.

    The key is to treat privacy and compliance as part of your product design, not as an afterthought. When embedded early, compliance becomes a natural part of the development workflow.

    The EU Digital Strategy: The Bigger Picture

    The EU Digital Strategy complements the GDPR and the AI Act, forming the backbone of Europe’s vision for a trusted and competitive digital economy. For startups, it’s not just another layer of regulation it’s a roadmap for building future-proof businesses in Europe.

    The strategy aims to create a single digital market where data can flow freely, innovation can thrive, and users can trust the technologies they use. It includes key initiatives like the Data Governance Act, the Digital Markets Act, and the Digital Services Act, which set clear rules for data sharing, online platforms, and fair competition.

    In simple terms: the EU wants companies to innovate boldly but with transparency, user protection, and ethical data use at the core. Understanding these principles early helps founders design products and business models that can scale confidently across Europe and beyond.

    Understanding the EU AI Act

    The EU Artificial Intelligence Act (AI Act) is one of the world’s first comprehensive regulatory frameworks for artificial intelligence. It applies to developers, providers, and deployers of AI systems that have an EU connection, even if they operate abroad. The AI Act takes a risk-based approach: the greater the potential impact on people or society, the stricter the obligations. This means low-risk tools can operate with minimal requirements, while high-risk applications  such as those affecting health, employment, or access to essential services  face rigorous compliance duties, documentation, and oversight.

    Rather than introducing all rules at once, the EU has designed a phased implementation to give organizations, especially startups and SMEs, time to adapt and build compliant systems.

    Timeline Overview:

    • August 2024: Regulation enters into force.
    • February 2025: Ban on “unacceptable-risk” AI systems (e.g. manipulative or social scoring applications).
    • August 2025: Governance and transparency obligations become applicable.
    • 2026–2027: Full obligations for high-risk AI systems take effect.

    What Founders Should Do Now

    For founders building or using AI systems, preparation is key. Start by determining whether your product qualifies as an AI system under the Act and defining your role: are you a provider, deployer, or user? Each role carries different legal duties.

    Next, assess your system’s risk level: minimal, limited, high, or prohibited. For high-risk systems (e.g. those used in employment, healthcare, or critical infrastructure), you’ll need detailed documentation covering datasets, training processes, explainability, and human oversight.

    Data governance also becomes crucial. High-quality, representative, and well-documented datasets help prevent bias and discrimination while demonstrating accountability. Finally, integrate AI compliance into your broader digital strategy  alongside ethics, privacy, and security.

    Make Compliance Part of Your DNA

    Compliance is not a blocker, it’s a strategic advantage. Startups that take privacy, security, and governance seriously from the beginning build stronger relationships with users, attract more confident investors, and reduce legal risks as they grow.

    • At the Early Stage, focus on the basics: privacy policy, imprint, non-disclosure agreements, cookie banner, and Terms & Conditions.
    • At the Seed Stage, expand your scope to include employee data protection, contractual frameworks, and GDPR documentation.
    • At the Expansion Stage, prepare for cross-border data transfers, AI Act readiness, and investor due diligence.

    By building compliance into your company’s DNA, you don’t just meet legal standards, you signal to the market that your business is mature, trustworthy, and built to last.

    Conclusion

    Sustainable growth today is built on trust, transparency, and accountability. Compliance isn’t about ticking boxes it’s a core element of smart business strategy. Founders who embed privacy, security, and AI governance into their products from day one save time, reduce risk, and earn lasting trust from customers, partners, and investors.

    Startups that treat ethics and compliance as part of their DNA don’t just stay compliant they help shape the digital future of Europe.

    If you’re unsure and need legal support with the implementation, get in touch with us.

    Secure your free 30-minute initial consultation.

    Read also our article to Legal Tips for eCommerce

  • Legal Tips for eCommerce

    27.02.2025

    Legal Tips for eCommerce

    February 27, 2025

    Anyone offering products or services online must comply with legal regulations. These rules are designed to protect consumers and ensure that customers receive all relevant information. Missing details can be costly, as competitors or consumer protection organizations may issue warnings.

    Mandatory Information for Your Customers

    Your customers must be informed about all conditions that apply to shopping in your online store. This includes the following details in particular:

    1. Product and Contract Details

    • Essential characteristics of the goods or services
    • Information about contract conclusion
    • Minimum duration for long-term contracts
    • Clear delivery time specifications (e.g., “3 to 5 days”; vague terms like “available soon” are not allowed)
    • Possible delivery restrictions or replacement deliveries of equal quality and price

    2. Prices and Additional Costs

    • Total price, including all taxes and fees
    • Shipping costs (separately specified for freight shipments)
    • Any additional costs or taxes not collected by the provider

    3. Payment, Delivery, and Cancellation

    • Accepted payment methods and shipping options
    • Existence or non-existence of a right of withdrawal, including deadlines and conditions
    • Provision of withdrawal instructions and a withdrawal form (e.g., via email or as a printed document with delivery)

    4. Additional Information

    • Extra charges for specific communication methods (e.g., paid hotlines)
    • Duration of limited-time offers
    • Technical steps required to conclude a contract
    • Storage of the contract text and accessibility for the customer
    • Languages available for contract conclusion
    • Existing manufacturer warranties
    • Information about adherence to any codes of conduct, if applicable
    • Link to the EU Online Dispute Resolution platform
    • Statement on whether your business participates in consumer arbitration

    5. Data Protection Notices

    • Types of collected data
    • Purpose and legal basis of data processing
    • Recipients of the data and processing in third countries
    • Rights of the affected individuals
    • Contact details of a data protection officer or responsible person in the company

    B2B or B2C? Clear Labeling Is Mandatory!

    If your online store is exclusively for business customers (B2B), this must be clearly indicated. The notice must be immediately visible and not just included in the terms and conditions (T&Cs).

    For a store to be recognized as a B2B-only shop, the following requirements must be met:

    • A clearly visible notice stating that only business customers can place orders
    • This notice must appear on every page of the shop
    • The customer’s business status should be confirmed before purchase via a checkbox (placed near the order button)

    Otherwise, consumers may assume that your shop is also for them and claim rights such as the right of withdrawal.

    Who Qualifies as an Online Retailer?

    The following providers qualify as online retailers:

    • Operators of online stores and auction platforms
    • Providers of websites with direct ordering options

    Providers who only present their products online but complete sales via phone or email are not considered online retailers. However, they still have specific information obligations.

    Right of Withdrawal: What Applies to Online Purchases?

    When consumers purchase online, via phone, email, or fax, they generally have a 14-day right of withdrawal. This applies to both goods and services.

    • The withdrawal period begins upon receipt of the goods. For partial deliveries, it starts with the final delivery.
    • For services, the period starts upon contract conclusion.
    • The 14-day period can be extended but not shortened.
    • Certain items, such as custom-made goods or hygiene products, may be excluded from the right of withdrawal. Customers must be informed of this before ordering.

    Withdrawal Instructions and Form

    Online retailers must provide correct withdrawal instructions and a withdrawal form. There are legal templates for this that should not be modified. Errors or outdated texts can result in warnings.

    ⚠️ Important: If the instructions are missing or incorrect, the withdrawal period does not start. Consumers may then withdraw up to 12 months and 14 days later.

    Withdrawal does not require a specific format. The customer must only clearly state that they wish to cancel the contract.

    Right of Withdrawal for Business Customers?

    Business customers do not have a right of withdrawal. If your store serves both consumers and businesses, the latter might still attempt to claim withdrawal rights. To avoid this, explicitly state in your terms and conditions that the right of withdrawal applies only to consumers.

    Return Costs in Case of Withdrawal

    If specified in the terms and conditions, the customer must cover the cost of returning items. However, the initial shipping costs must be refunded to the customer.

    Frequently asked questions

    Where do I start when creating a procedure directory?

    List your data processing operations by

    1. determine which data you process
    2. why you process it
    3. how you process it

    When do I have to delete the data?

    The following steps can help you to find the right storage duration:

    1. find out what data you have
    2. list the reasons why you need it
    3. check or have LLH check for you whether you are legally obliged to retain it
    4. if the data is needed for several purposes and you have different deletion periods, take the longest storage period (there are a few more points to consider here)
    5. define an appropriate deletion mechanism

    What do I need to bear in mind when consenting to a newsletter?

    There are legal requirements as to how a newsletter consent should be formulated. Here are the most important points:

    1. Voluntary (i.e. no opt-out)
    2. Clear and understandable
    3. Contains all information (who receives which data and for what purpose)
    4. Possibility of cancellation
    5. Link to data protection information

    But that’s not all! Further steps should be taken in the technical background, such as saving consent, verifying data, etc.

    Contact LLH if you need support in designing your newsletter process.

Copyright 2024

  • Imprint
  • Privacy Notice
Cookie Consent
Legal Living Hub uses cookies to ensure the website functions reliably and to collect information for statistical analysis. You can change your cookie settings at any time in the footer of the website. For more information, please refer to our privacy notice.