Logo
  • Home
  • Service
  • About LLH
  • FAQ
  • Contact
  • Русский

  • 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

  • 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. 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.