Logo
  • Home
  • Service
  • About LLH
  • FAQ
  • Contact
  • Русский
  • Doing Business in China: What Companies Need to Know About Data Protection

    21.04.2026

    Anyone operating in China faces a dual compliance burden that many companies underestimate. A practical guide to simultaneously and seamlessly complying with the European GDPR and China’s PIPL.

    Geschäfte in China

    China is not just another country when it comes to data protection law. It operates an entirely separate regulatory system — one that exists in parallel to, and frequently in direct tension with, European data protection law. For any company with even a minimal footprint in China, understanding both frameworks is not optional — it is a legal obligation.

    The Dual Compliance Landscape

    When a European company operates in China — whether through a local subsidiary, an employee on assignment, a distribution partnership, or simply by offering goods and services to Chinese users — this typically triggers obligations under two entirely separate legal frameworks simultaneously:

    GDPR

    Protects the personal data of EU citizens. Applies extraterritorially when a non-EU company offers goods or services to individuals in the EU or monitors their behaviour. A fundamental-rights-oriented, principles-based framework.

    PIPL

    China’s comprehensive data protection law, in force since November 2021. Governs the processing of personal data within China and extraterritorially where Chinese citizens are specifically targeted. A state-centric, rules-based framework.

    Both laws share a common objective — protecting individuals from harm caused by the misuse of their personal data — but they stem from fundamentally different legal philosophies, and the practical compliance requirements diverge in ways that carry significant weight in day-to-day business operations.

    Practical reality: A routine, low-risk cross-border transfer of employee data to a payroll service provider — a transaction that would rarely require a formal DPIA under the GDPR — will always trigger a PIPIA and a CAC filing under PIPL. The operational burden under Chinese law is considerably higher.

    Understanding PIPL: China’s Data Protection Framework

    The Personal Information Protection Law (PIPL) entered into force on 1 November 2021 and is enforced by the Cyberspace Administration of China (CAC) — the country’s competent data protection and internet regulatory authority. It applies to any processing of personal data of individuals located in China, regardless of where the processing entity is established.

    What counts as “personal information” under PIPL?

    The PIPL concept of personal information is broadly defined: it covers all information recorded electronically or otherwise that relates to an identified or identifiable natural person, excluding anonymised data. This includes names, contact details, employment records, location data, IP addresses, and business contact details of distributor or hospital representatives — categories that many companies handle routinely without any data protection classification. PIPL also defines a category of sensitive personal information (SPI) which is subject to enhanced regulatory requirements and stricter processing conditions. SPI includes biometric data, religious beliefs, health and medical data, financial account data, location tracking data, and personal data of children under the age of 14. Processing SPI requires explicit, separate consent and triggers mandatory impact assessment obligations.

    Extraterritorial scope

    Like the GDPR, PIPL reaches beyond China’s borders. It applies to entities outside China that offer products or services to individuals in China or that analyse or assess the behaviour of individuals in China. This means: a US or European parent company that receives data from its Chinese subsidiary may itself be subject to PIPL obligations — not merely by virtue of contractual arrangement, but by operation of law.

    The absence of an EU adequacy decision for China means: every transfer of personal data from the EEA to China requires an appropriate safeguard under Art. 46 GDPR — and every transfer from China in the opposite direction requires a separate mechanism under PIPL.

    Cross-Border Data Transfers: The Central Compliance Challenge

    For most companies operating in China, the greatest practical challenge is managing cross-border data flows. The two legal systems impose obligations in opposite directions — and both must be satisfied simultaneously.

    Transfers from the EEA to China (GDPR perspective)

    The European Commission has not issued an adequacy decision for China. China is therefore treated as an “unsafe third country” under the GDPR, and any transfer of personal data from the EEA to China requires an appropriate safeguard under Art. 46. In practice, this means: EU Standard Contractual Clauses (EU SCCs). The EU Standard Contractual Clauses (2021) adopted in June 2021 must be executed under the module that reflects the actual data processing relationship—most commonly Module 1 for controller-to-controller transfers or Module 4 for processor-to-controller scenarios. The correct module selection depends on the factual roles and responsibilities of the parties involved.

    In addition, a Transfer Impact Assessment (TIA) should be conducted to document whether the legal framework in China provides a level of data protection that is “essentially equivalent” to that guaranteed under the GDPR.This is inherently challenging for China, given the extensive government access rights under the National Intelligence Law and related legislation — a circumstance that must be addressed honestly in the TIA and mitigated through supplementary measures.

    Transfers from China to third countries (PIPL perspective)

    Under Art. 38 PIPL, any transfer of personal information from mainland China requires one of three recognised mechanisms. For most companies with a limited China presence, the appropriate route is the PIPL Standard Contract:

    Step 1 — Conduct a PIPIA (Personal Information Protection Impact Assessment) This must be completed before the Standard Contract is executed. It is a structured assessment of the lawfulness, necessity, and proportionality of the transfer, as well as an evaluation of risks to data subjects and the adequacy of protective measures.

    Step 2 — Execute the PIPL Standard Contract The CAC has published a binding standard form (in force since 1 June 2023) that must be used without substantive amendment. It is a single contract type that applies regardless of the roles of the parties. Additional clauses are permitted, provided they do not contradict the standard terms.

    Unlike EU SCCs, which require no submission to any authority, the PIPL Standard Contract must be filed — together with the PIPIA report — with the competent CAC branch at provincial level at the seat of the Chinese entity. The CAC reviews the submission and may request amendments or reject the filing. All documentation must be submitted in Chinese.

    Important: The CAC filing is not a mere formality. It establishes an ongoing compliance relationship with a Chinese regulatory authority. The overseas recipient (e.g. the parent company in the US or EU) must expressly consent in the Standard Contract to CAC supervision — including the obligation to respond to enquiries, cooperate with inspections, and report data breaches. This is a commitment that the parent company’s legal team must fully understand before signing.

    For larger operations, different thresholds apply: companies transferring personal data of more than 100,000 individuals (or sensitive data of more than 10,000 individuals) must undergo a mandatory CAC security assessment instead of the Standard Contract route.

    A Common Scenario: The International Assignment

    One of the most frequently overlooked compliance scenarios in China operations is the internationally assigned employee — for example, a German or US national working in China under a local employment arrangement. This single individual creates a web of obligations in both directions:

    Data FlowGDPR RequirementPIPL Requirement
    Home country HQ → China (HR, payroll, and assignment data)EU SCCs + TIA required (EEA-to-China transfer, no adequacy decision)Not applicable — PIPL governs outbound, not inbound transfers
    China → Home country HQ (timesheets, tax, visa data)Receiving entity must ensure lawful basisPIPL Standard Contract + PIPIA + CAC filing required

    The key takeaway: a single assignment triggers obligations under both frameworks — EU SCCs in one direction, a PIPL Standard Contract in the other. For the vast majority of companies operating in China, neither mechanism is in place.

    The Distributor Gap: An Underestimated Risk

    Companies operating in China exclusively through a master distributor often believe their data protection exposure is limited. In our experience, this assumption is almost always wrong. What a typical distribution partnership actually involves:

    Lead & contact data

    Marketing leads, contact form submissions, and business contact data processed in global CRM systems (e.g. HubSpot) are routinely forwarded to local distributors for follow-up. The distributor receives personal data of Chinese individuals from the company’s global systems.

    Adverse event & complaint data

    In regulated industries (particularly medical devices), distributors monitor government platforms for adverse events and forward reports — including hospital names and case details — to the global complaints management team. This constitutes a cross-border transfer from China within the meaning of PIPL.

    In both scenarios, the distributor is processing personal data either as a data processor acting on the company’s instructions or as a joint controller. Under both GDPR (Art. 28) and PIPL, a formal data processing agreement (DPA) — with a clear allocation of roles, obligations, and liability — is required. In practice, most distributor contracts in China contain no data protection provisions whatsoever.

    Note on the allocation of responsibility: Under PIPL, the question of whether data protection obligations fall primarily on the Chinese entity or on the distributor is a contractual matter. However, the entity that determines the purposes of processing remains liable under PIPL, regardless of how the distributor contract is structured. A contractual allocation of responsibility reduces practical risk; it does not eliminate statutory liability.

    Impact Assessments: DPIA vs. PIPIA

    Both GDPR and PIPL require documented risk assessments for certain types of processing — but the triggers and operational consequences differ fundamentally.

    Processing ActivityGDPR DPIAPIPL PIPIA
    Processing sensitive personal dataOnly at large scale or in combination with other risk factorsAlways required, regardless of scale
    Use of a third-party vendor / data processorOnly if the overall processing presents a high riskAlways required when entrusting processing to a third party
    Cross-border data transfersOnly if the transfer is part of a high-risk processing activityAlways required for any transfer outside mainland China
    Automated decision-makingOnly where legally significant or similarly significant effects ariseAlways required when using personal data for automated decisions
    Sharing data with another controllerNot a standalone triggerAlways required

    The practical consequence: under PIPL, the PIPIA is not a strategic exercise reserved for high-risk initiatives. It is a routine transactional requirement that must be embedded as a standard step in procurement, HR, IT, and legal processes. Every vendor contract involving personal data, every cross-border transfer, every HR benefits process involving sensitive employee data — each requires a documented PIPIA. PIPIA reports must be retained for a minimum of three years — a hard, auditable requirement under Art. 56 PIPL. The GDPR imposes no equivalent minimum retention period, although the accountability principle implies similar discipline.

    Internal Governance: Who Bears Responsibility in China?

    Under PIPL, every organisation processing personal data in China must establish an internal data protection function. This goes beyond the mere designation of a named individual — it requires genuine compliance infrastructure.

    Is a formal data protection officer required?

    A formal Personal Information Protection Officer (PIPO) is mandatory only for organisations that process personal data of more than one million individuals. For most foreign companies with a limited China presence, this threshold is not reached, and a formal PIPO appointment is not legally required.

    Nevertheless, PIPL requires every organisation — regardless of size — to maintain an internal data protection function with clear accountability. This “directly responsible person” must be embedded within the Chinese entity and cannot fulfil this function remotely from the European parent company. They must possess genuine data protection expertise and the authority to ensure compliance.

    The local representative requirement

    For foreign companies that fall within PIPL’s extraterritorial scope — i.e. those processing personal data of individuals in China from outside China. However, without a local legal entity — PIPL requires the designation of a local representative in China responsible for compliance matters and reachable by Chinese regulatory authorities.

    Where a local legal entity already exists, it fulfils this function directly and a separate representative appointment is not required.

    Personal liability:

    PIPL’s enforcement model provides for direct personal liability for “directly responsible persons” in serious cases. Fines of RMB 100,000 to RMB 1 million may be imposed on individuals — including senior executives. Additionally, they may be prohibited from holding key positions for a specified period. This represents a significant departure from the GDPR, under which liability rests with the organisation rather than with individuals.

    Practical Compliance Checklist for Companies Operating in China

    • Map your data flows: Identify every category of personal data moving between China and other countries — in both directions. This includes employee data, business contact data, marketing leads, and complaint and adverse event data. The data flow map is the foundation for everything else.
    • Execute a data processing agreement with your Chinese distributor: If your distributor receives leads, processes contact data, or forwards complaint information on your behalf, a DPA is required under both GDPR Art. 28 and PIPL. This is the most commonly missing document in China operations.
    • Implement the PIPL Standard Contract for outbound transfers from China: First conduct a PIPIA, then execute the CAC standard form contract between the Chinese entity and the overseas recipient. File both documents with the competent provincial CAC within 10 business days of execution.
    • Put EU SCCs + TIA in place for EEA-to-China transfers: Where data flows from an EU Member State to China (including data sent to employees on assignment), EU SCCs in the appropriate module are required, supplemented by a Transfer Impact Assessment addressing government access rights under Chinese law.
    • Add a China entry to your Record of Processing Activities (RoPA): Your processing register must reflect China operations, even if minimal. Document data subject categories, data categories, purposes, legal bases, and transfer mechanisms for each identified data flow.
    • Establish internal accountability in China: Designate an individual within your Chinese entity as responsible for data protection compliance. Ensure they possess genuine expertise and the necessary authority to act. For companies above the one million threshold, a formal PIPO must be appointed.
    • Embed PIPIA into standard operating procedures: PIPIA is not a one-off project. It must be triggered automatically whenever the company onboards a new vendor handling personal data, establishes a new cross-border data access, or changes the scope of an existing transfer. Integrate it into procurement, IT, and HR workflows.

    Conclusion: Compliance is a Process, Not a Project

    The most important insight for companies approaching GDPR and PIPL compliance in China is that neither framework is satisfied by a one-time documentation exercise. Both impose ongoing obligations that must be firmly embedded in the operational fabric of the business.

    What distinguishes companies that manage this well from those that do not is typically not the size of their China operations — it is the quality of their data flow mapping and the robustness of their contractual framework with local partners. A company with a single employee and a small distribution partnership can achieve full compliance with comparatively modest effort, provided the right foundations are in place. A company with a larger footprint but no transparency over its data flows is exposed to risks that regulatory action — or a due diligence review by the parent company — will quickly bring to light.

    The dual nature of China compliance is genuine complexity — but it is manageable. The starting point is always the same: know what data you hold, know where it goes, and build the right legal architecture around it.

    This article is for informational purposes only and does not constitute legal advice. The law in this area is evolving rapidly. Please consult qualified legal counsel before taking any compliance action.

  • 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
  • CRA vs AI Act: A Guide to Regulatory Overlap

    13.11.2025

    Introduction

    With the adoption of the Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) and the Artificial Intelligence Act (AI Act, Regulation (EU) 2024/1689), the European Union has created two landmark legislative acts that will fundamentally shape the digital landscape.

    For companies developing products that contain both digital elements and AI components, a crucial question arises:

    How do these two regulations interact with each other?

    Executive Summary

    In brief: The AI Act generally takes precedence. However, products with digital elements that fall within the scope of the CRA and are simultaneously classified as high-risk AI systems within the meaning of Article 6 of the AI Act must additionally fulfill the essential cybersecurity requirements of the CRA.

    If these high-risk AI systems meet the cybersecurity requirements set out in Annex I Parts I and II of the CRA, they are presumed to also fulfill the requirements under Article 15 of the AI Act.

    By way of exception, the CRA takes precedence for products classified as “important” or “critical” products with digital elements according to Annex III or IV of the CRA. However, this precedence applies exclusively with regard to cybersecurity requirements.

    The Central Interface: Article 12 CRA

    The main provision for coordination between both regulations is found in Article 12 of the CRA (“High-risk AI systems”). This is supplemented by Recitals 63 to 65 and Article 52(14) CRA on market surveillance.

    The legislator has recognized that many products may simultaneously fall under both regulations – particularly when dealing with high-risk AI systems that also qualify as products with digital elements.

    The Principle of Conformity Presumption

    Dual Applicability

    Products that fall within the scope of both the CRA and are classified as high-risk AI systems according to Article 6 AI Act must, in principle, comply with both regulatory frameworks. However, the CRA establishes an important facilitation through the principle of conformity presumption.

    The Conformity Presumption in Practice

    When a high-risk AI system:

    • meets the essential cybersecurity requirements in Annex I Part I of the CRA, and
    • the procedures established by the manufacturer comply with the requirements in Annex I Part II of the CRA,

    it is automatically presumed that the cybersecurity requirements according to Article 15 AI Act are also fulfilled. This compliance must be documented in the EU declaration of conformity issued under the CRA.

    Practical Note: This provision avoids duplicate compliance work and creates legal certainty for manufacturers.

    Enhanced Risk Assessment for AI Systems

    AI-Specific Threat Scenarios

    When conducting the risk assessment required under the CRA, manufacturers of high-risk AI systems must pay special attention to AI-specific cyber threats:

    • Data Poisoning: Manipulation of training data to corrupt AI behavior
    • Adversarial Attacks: Targeted inputs to deceive the AI system
    • Model Extraction: Unauthorized access to the trained model
    • Manipulation of system behavior and performance

    Fundamental Rights Protection as Assessment Criterion

    It is particularly noteworthy that the risk assessment must also consider potential impacts on fundamental rights according to the AI Act. This establishes a direct connection between technical cybersecurity and legal fundamental rights protection.

    The Conformity Assessment Procedure: A Complex Regulatory System

    General Rule: Priority of the AI Act

    As a general rule, the conformity assessment procedure under the AI Act takes precedence. This means:

    • The procedure provided in Article 43 AI Act also applies to the assessment of CRA cybersecurity requirements
    • Notified bodies under the AI Act are also responsible for CRA conformity, provided they meet the requirements of Article 39 CRA

    The Exception: Priority of the CRA

    However, CRA conformity assessment procedures take precedence when all of the following conditions are cumulatively met:

    1. Product classification under CRA:
      • The product is classified as an “important product with digital elements” (Annex III CRA) and is subject to the procedures under Article 32(2) and (3) CRA, or
      • The product is classified as a “critical product with digital elements” (Annex IV CRA) and requires a European cybersecurity certificate or is subject to Article 32(3) CRA
    2. Simultaneously: The conformity assessment procedure under the AI Act is based on internal control according to Annex VI AI Act

    Important: In these exceptional cases, CRA priority applies only to cybersecurity aspects. All other AI Act requirements continue to be assessed according to the internal control procedure of the AI Act.

    Synergies and Practical Benefits

    AI Regulatory Sandboxes

    An important advantage for innovators: Manufacturers of products falling under both regulations can participate in AI regulatory sandboxes according to Article 57 AI Act. This enables controlled testing environments for innovative developments.

    Coordinated Market Surveillance

    Market surveillance is conducted in a coordinated manner:

    • AI Act authorities are also responsible for CRA aspects of high-risk AI systems
    • Close cooperation with CRA market surveillance authorities, CSIRTs, and ENISA
    • Information exchange about relevant findings between authorities

    Practical Recommendations

    1. Early Classification: Determine early whether your product falls under both regulations
    2. Integrated Compliance Strategy: Develop a holistic compliance strategy that considers both regulatory frameworks
    3. Documentation: Utilize the conformity presumption through careful documentation of CRA compliance
    4. Risk Management: Implement comprehensive risk management covering both classical cybersecurity and AI-specific threats

    Legal Living Hub provides you with modern data protection consulting and AI compliance on an equal footing.

    Secure a free 30-minute initial consultation

    Conclusion

    The overlap provisions between CRA and AI Act demonstrate the European legislator’s commitment to creating practical solutions despite complex regulation. The conformity presumption and coordinated market surveillance are important instruments for avoiding duplicate burdens.

    At the same time, practical application remains complex and requires careful analysis on a case-by-case basis. Companies should seek legal advice early and align their compliance processes accordingly.

    Successfully navigating this regulatory landscape is increasingly becoming a competitive advantage – both in terms of legal certainty and regarding the trust of customers and partners in the security and legal compliance of offered products.


    This article provides initial guidance on the overlap provisions between CRA and AI Act. For specific legal advice on your particular case, we recommend consulting specialized legal advisors.

    Date: November 2024
    Legal Basis: Regulation (EU) 2024/2847 (CRA), Regulation (EU) 2024/1689 (AI Act)

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.