EU Compliance Glossary

Annex IV of the EU AI Act specifies the technical documentation that providers of high-risk AI systems must draw up and maintain under Article 11. This documentation is the evidentiary record that demonstrates a high-risk AI system was designed, built, and validated in compliance with the Act's requirements. It must be kept up to date throughout the system's lifecycle and made available to national market surveillance authorities and notified bodies on request. The Annex IV documentation requirement is substantial. It must include: a general description of the AI system, including its intended purpose, the version placed on the market, and how it interacts with hardware and software; a detailed description of the design specifications, including general logic, key design choices, the assumptions made, and the limitations of the system; a description of the system architecture and processes involved in developing and monitoring the system; a description of the training and testing methodologies used, including the datasets used and the validation approach; a description of the technical measures for human oversight under Article 14; a copy of the EU declaration of conformity; detailed information on the monitoring, functioning, and control of the AI system; and the results of all tests carried out to demonstrate conformity with Article 15 requirements on accuracy, robustness, and cybersecurity. For a provider deploying an AI system under its own name, this documentation must exist before the system is placed on the EU market or put into service. For deployers using a third-party high-risk system, the documentation obligation sits with the original provider, but deployers must be able to obtain it and understand it sufficiently to fulfil their own obligations around human oversight and monitoring. For an EU SME developing AI products in the high-risk categories, Annex IV documentation is best treated as a continuous engineering artefact rather than a compliance document produced after the fact. Regulators evaluating a system will look for evidence that the documentation reflects actual design decisions, not post-rationalisation. Failure to produce adequate technical documentation — or producing documentation that is found to be misleading — can attract fines of up to €15 million or 3% of global annual turnover. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

Binding Corporate Rules are internal data protection policies adopted by a multinational corporate group that constitute an appropriate safeguard for intra-group transfers of personal data from the EU or EEA to group companies in third countries. Authorised under GDPR Article 47, BCRs enable a corporate family to transfer data freely among its members worldwide — avoiding the need to execute Standard Contractual Clauses for every intra-group data flow — provided the group's internal rules meet a comprehensive set of requirements. BCRs must include a description of the group structure, the categories of personal data transferred, the types of processing and the purposes, the countries of origin and destination, the rights of data subjects (which must be directly enforceable against every member of the group), the mechanism for updating the BCRs, and the technical and organisational measures applied. Critically, BCRs must be binding on all members of the group and the obligations must be genuinely enforceable — both by data subjects and by the supervisory authority. At least one entity in the group, established in the EU, must accept liability for breaches by non-EU group members. The approval process involves submitting the BCRs to the lead supervisory authority, which reviews them under a consistency mechanism involving the European Data Protection Board. The process is thorough, expensive, and slow — most organisations report a timeline of one to two years and significant legal fees before approval is granted. For this reason, BCRs are primarily used by large multinational corporations with complex global data flows that make the investment worthwhile. For most SMEs, Standard Contractual Clauses are a more proportionate alternative. For an EU SME that is part of a larger corporate group with existing BCRs, compliance is straightforward — you must adhere to the group's BCRs as a binding obligation. If your company is considering adopting BCRs independently, the threshold question is whether the volume and complexity of your intra-group transfers justify the substantial approval effort. Transferring data without an adequate safeguard can result in fines of up to €20 million or 4% of global annual turnover. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Regulation (EU) 2024/2847, the Cyber Resilience Act, establishes mandatory cybersecurity requirements for products with digital elements sold in the European Union. It entered into force on 10 December 2024, with a phased application timeline: reporting obligations for actively exploited vulnerabilities apply from 11 September 2026, and the main product security requirements apply from 11 December 2027. The CRA covers hardware and software products ranging from consumer IoT devices and industrial controllers to operating systems, routers, and connected appliances — essentially anything with digital components that can connect to a network or another device. The regulation distinguishes between default products, important products (Class I and Class II), and critical products. Default products can be self-assessed. Important products — those that play a significant role in cybersecurity risk, such as password managers, firewalls, network management systems, and microprocessors — face stricter requirements and, for Class II, mandatory third-party assessment. The core obligations under Article 13 require manufacturers to perform a cybersecurity risk assessment, design products secure by default, minimise the attack surface, implement protection against unauthorised access, ensure data integrity and confidentiality, and keep products free of known exploitable vulnerabilities at the time of placing on the market. Manufacturers must also provide security updates for the expected product lifecycle or at minimum five years, whichever is shorter. For an EU SME that manufactures or imports connected products, the CRA creates obligations that flow through the entire product development lifecycle. You must document your risk assessment, maintain a software bill of materials (SBOM), notify ENISA and your national authority within 24 hours of becoming aware of an actively exploited vulnerability, and affix a CE mark only after completing the appropriate conformity assessment procedure. Importers and distributors also carry obligations to verify manufacturer compliance before placing products on the EU market. Penalties for non-compliance reach €15 million or 2.5% of global annual turnover for violations of essential cybersecurity requirements, and €10 million or 2% for other obligations. Market surveillance authorities can order product recalls, restrict market access, and require immediate patches. See the CRA compliance guide at eurocomply.app/regulations/cra

Conformity assessment is the process by which a high-risk AI system is evaluated against the requirements of the EU AI Act before it is placed on the market or put into service in the EU. It is a mandatory gate through which all high-risk AI systems must pass, and it results in the provider drawing up an EU declaration of conformity and affixing a CE mark to the system (or its documentation, where the physical product does not accommodate marking). The EU AI Act provides two routes to conformity assessment. The first, available for most high-risk AI systems listed in Annex III, is internal conformity assessment — sometimes called self-assessment. The provider carries out its own assessment, working through a checklist of the Act's requirements, generating Annex IV technical documentation, and drawing up the declaration of conformity. This self-assessment route mirrors the approach used for many CE-marked products and places the entire burden of demonstrating compliance on the provider. The second route applies to AI systems listed in Annex III paragraphs 1(a) — remote biometric identification systems intended to be used in publicly accessible spaces — and paragraph 6 when used by law enforcement. These systems require third-party assessment by a notified body: an independent, accredited conformity assessment organisation designated by an EU member state and notified to the European Commission. The notified body examines the technical documentation, audits processes, and issues an EU-type examination certificate if the system meets the requirements. For an EU SME, understanding which route applies to your specific AI system is the critical first step. Even for self-assessed systems, the documentation burden is substantial and the declaration of conformity is a legal statement for which the provider takes direct responsibility. Market surveillance authorities can challenge conformity assessments, require additional evidence, and in cases of non-conformity order withdrawal from the market and suspension of services. Placing a non-conforming high-risk AI system on the market can attract fines of up to €15 million or 3% of global annual turnover. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

CE marking — from the French Conformité Européenne — is the visible symbol indicating that a product meets the EU's safety, health, environmental, and consumer protection requirements applicable to it and may be freely placed on the EU market. For high-risk AI systems under the EU AI Act, CE marking is a mandatory step before the system can be placed on the market or put into service in the EU. The CE mark is not a quality label or an endorsement — it is a declaration by the manufacturer or provider that the product complies with applicable EU law. For high-risk AI systems, the steps required before affixing a CE mark are prescribed in Articles 43 and 48. The provider must first complete the applicable conformity assessment procedure — internal self-assessment for most Annex III systems, or third-party assessment by a notified body for biometric identification systems and certain others. The provider must then draw up an EU declaration of conformity under Article 47, a legally binding document that identifies the system, lists the applicable AI Act provisions it conforms with, includes the name and address of the provider and any authorised representative, and is signed by a person authorised to bind the provider. Once the conformity assessment is complete and the declaration is drawn up, the CE mark may be affixed to the system, its packaging, or its accompanying documentation. The CE mark under the AI Act must appear together with any other CE marks required by other applicable EU legislation. If the product is also subject to the Machinery Regulation, the Medical Devices Regulation, or another CE-marking framework, a single CE mark covers all applicable legislation, but each assessment must be completed separately. If a notified body was involved in the assessment, the notified body's four-digit identification number must accompany the CE mark. For an EU SME, placing a CE mark on a high-risk AI system without completing the required conformity assessment is not only a regulatory violation — it is a misrepresentation to customers, procurement authorities, and regulators. Market surveillance authorities actively check for CE marks on AI systems and can require providers to demonstrate the underlying documentation. Unlawful affixing of a CE mark can attract fines of up to €15 million or 3% of global annual turnover, and national authorities can order immediate market withdrawal. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

The Digital Operational Resilience Act (Regulation (EU) 2022/2554) is the EU's mandatory cybersecurity and operational resilience framework for the financial sector. Directly applicable across all member states since 17 January 2025, DORA applies to a broad range of financial entities including credit institutions, payment institutions, electronic money institutions, investment firms, insurance and reinsurance undertakings, crypto-asset service providers, central counterparties, trade repositories, and many others. Critically, it also applies to ICT third-party providers — cloud platforms, data analytics providers, and software vendors — that are designated as critical by the European Supervisory Authorities. DORA is structured around five pillars. The first is ICT risk management: financial entities must implement a comprehensive ICT risk management framework under Chapter II that includes policies for protection, detection, response, recovery, and learning from incidents. The second pillar is ICT-related incident management, classification, and reporting under Chapter III, with mandatory reporting timelines to competent authorities for major incidents. The third pillar, Chapter IV, covers digital operational resilience testing — including basic testing annually and advanced threat-led penetration testing (TLPT) at least every three years for significant entities. The fourth pillar manages ICT third-party risk under Chapter V, requiring due diligence, contractual provisions, and exit strategies for all ICT service providers. The fifth pillar addresses information sharing arrangements among financial entities. For an EU SME in the financial sector, DORA's most immediate practical demands are a documented ICT risk management framework, a register of all ICT third-party service providers (Article 28), contractual clauses in every ICT provider agreement covering audit rights, security standards, and termination rights, and a tested incident response and recovery plan. Regulators can impose administrative sanctions — the specific penalty regime is set by member states and sector-specific supervisory authorities, but supervisory powers include requiring remediation, suspending activities, and imposing fines calibrated to the severity and duration of the breach. See the DORA compliance guide at eurocomply.app/regulations/dora

Regulation (EU) 2022/2065, the Digital Services Act, creates a harmonised EU-wide framework for the accountability and transparency of online intermediary services. It has applied to very large online platforms and very large online search engines (those with over 45 million average monthly active EU users) since 25 August 2023, and to all other in-scope providers since 17 February 2024. The DSA covers a layered set of services: mere conduit providers, caching services, hosting services, online platforms (including marketplaces and social networks), and online search engines, with obligations scaling up as you move through the layers. For most SMEs, the DSA's relevant obligations sit in the hosting and online platform tiers. Hosting services must have a notice-and-action mechanism allowing anyone to flag illegal content, and must process notices and inform the notifier of outcomes. Online marketplaces — platforms allowing consumers to conclude contracts with traders — carry additional due diligence obligations: they must verify trader identities, ensure compliance with consumer law, and trace and take down illegal products. All platforms must publish transparency reports, maintain a single point of contact for authorities, and designate a legal representative in the EU if not established there. Very large platforms face the heaviest obligations: mandatory annual risk assessments of systemic risks (including algorithmic amplification of harmful content, election integrity risks, and mental health impacts on minors), independent annual audits, access to data for researchers, algorithmic transparency including an option to use recommendation systems not based on profiling, and real-time API access for authorities. They also pay a supervisory fee to fund the European Commission's Digital Services Coordinator network. For an EU SME operating a platform, marketplace, or hosting service, the DSA demands terms-of-service documents that accurately describe content moderation policies, an accessible complaint mechanism, and cooperation with trusted flaggers and Digital Services Coordinators. Fines can reach 6% of global annual turnover for violations, and 1% for providing incorrect or misleading information. Repeat infringement can lead to temporary access restrictions. See the DSA compliance guide at eurocomply.app/regulations/dsa

Under GDPR Article 4(7), a data controller is the natural or legal person, public authority, agency, or other body that, alone or jointly with others, determines the purposes and means of processing personal data. The key distinguishing feature is decision-making power: if your organisation decides why data is being collected and how it is going to be used, you are the controller for that processing activity. Being a controller is not about physically holding data — a company that instructs a cloud provider to store customer records remains the controller even though the servers belong to someone else. Controllers bear the primary compliance burden under GDPR. They must identify and document a lawful basis for each processing purpose under Article 6 (and Article 9 for special category data), provide transparent information to individuals at the point of collection under Articles 13 and 14, maintain a Record of Processing Activities under Article 30, implement appropriate technical and organisational measures under Article 32, notify their supervisory authority of data breaches within 72 hours under Article 33, and respond to data subject requests within one month under Articles 15 to 22. Where they engage processors, controllers must enter into written Data Processing Agreements under Article 28 and restrict processor choices to those offering sufficient guarantees of compliance. Joint controllers — where two or more organisations jointly determine the purposes and means of processing — must enter into an arrangement under Article 26 that allocates GDPR responsibilities between them and designates a point of contact for data subjects. This is common in affiliate marketing, co-branding, and platform ecosystems. For an EU SME, being miscategorised as a processor when you are actually a controller is a serious compliance risk. Regulators look at substance over label: if a contract says you are a processor but your operational reality involves deciding how customer data is used, you will be treated as a controller. Administrative fines for controller violations can reach €20 million or 4% of global annual turnover, and supervisory authorities can prohibit processing entirely — a potentially business-ending outcome. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Under GDPR Article 4(8), a data processor is a natural or legal person, public authority, agency, or other body that processes personal data on behalf of the controller. The hallmark of a processor is that it acts on instructions: it does not decide why personal data is processed or set the purposes — that authority belongs to the controller. A payroll bureau processing employee data for a company, a cloud provider storing a SaaS customer's database, and an email delivery platform sending marketing messages are all classic examples of processors. Processors have a narrower but still binding set of GDPR obligations. They may only process personal data on documented instructions from the controller, must ensure that anyone with access to personal data is bound by confidentiality, must implement appropriate technical and organisational measures under Article 32, must assist the controller in fulfilling data subject requests and breach notification obligations, must delete or return data at the end of the service relationship, and must make available all information necessary to demonstrate compliance. Under Article 28(2), processors may not engage a sub-processor without prior specific or general written authorisation from the controller, and must flow down equivalent obligations to any sub-processor they appoint. A written Data Processing Agreement (DPA) is mandatory under Article 28. The DPA must specify the subject matter, duration, nature, and purpose of the processing; the type of personal data and categories of data subjects; the obligations and rights of the controller; and the technical and organisational measures to be maintained. Absent a compliant DPA, both parties are exposed to regulatory action. For an EU SME acting as a processor — for example, providing SaaS software to business customers — you must be prepared to sign customer DPAs, maintain your own records of processing, manage sub-processor chains, and assist customers with breach response. Processors face direct regulatory liability for breaches of their specific Article 28 obligations and for acting outside or contrary to the controller's instructions, with fines reaching €10 million or 2% of global annual turnover. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Each EU member state has a national Data Protection Authority — an independent public body responsible for monitoring and enforcing compliance with GDPR and related data protection legislation, advising the public and organisations, and cooperating with its counterparts across the EU. The GDPR refers to these bodies as supervisory authorities; DPA is the common shorthand used in practice. Well-known examples include the CNIL in France, the BfDI in Germany, the Datatilsynet in Denmark and Norway, the Garante in Italy, and the Data Protection Commission (DPC) in Ireland. The UK's Information Commissioner's Office (ICO) performs the same function but operates under UK GDPR following Brexit. For cross-border processing — where an organisation processes personal data of individuals in more than one EU member state — the one-stop-shop mechanism under Article 56 designates a single lead supervisory authority based on where the organisation has its main establishment (usually its EU headquarters or the place where decisions about processing are taken). Other concerned supervisory authorities in member states where individuals are affected can cooperate and object under Articles 60 and 65 if they disagree with the lead authority's draft decision. DPAs have significant investigative powers: they can conduct audits, demand access to premises and processing systems, compel production of documents, carry out data protection sweeps, and initiate own-initiative investigations based on complaints or media reports. Their corrective powers include issuing warnings and reprimands, ordering compliance, imposing temporary or permanent bans on processing, and imposing administrative fines. They can also order data to be erased, rectified, or not transferred to third countries. For an EU SME, your lead supervisory authority is the DPA in the member state where your EU establishment is located. If you have no EU establishment but target EU residents, the DPA of the member state in which you have a representative under Article 27 is your primary point of contact. Engaging proactively with your DPA — for example, seeking prior consultation under Article 36 before high-risk processing — is a legitimate risk management strategy and demonstrates the accountability the regulation requires. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

A Data Protection Officer is a designated individual or external service provider responsible for independently overseeing an organisation's data protection compliance. The DPO role was created by GDPR Article 37, which mandates appointment in three situations: where the processing is carried out by a public authority or body; where the core activities of the controller or processor consist of processing operations which, by virtue of their nature, scope, or purposes, require regular and systematic monitoring of data subjects on a large scale; or where the core activities consist of processing special category data or personal data relating to criminal convictions and offences on a large scale. Many organisations that are not strictly required to appoint a DPO do so voluntarily as a governance best practice. The DPO's tasks are set out in Article 39. They include informing and advising the organisation and its employees of their obligations under GDPR, monitoring compliance with the regulation and with the organisation's own data protection policies, advising on Data Protection Impact Assessments and monitoring their performance, cooperating with the supervisory authority, and acting as the contact point for the supervisory authority on processing issues including prior consultation under Article 36. Importantly, the DPO does not take personal liability for the organisation's GDPR compliance — responsibility remains with the controller or processor — but the DPO must be independent, report to the highest management level, and must not receive instructions regarding the exercise of their tasks. The DPO must be registered with the competent supervisory authority. The name and contact details must also be published and communicated to the authority under Article 37(7). A DPO can serve multiple organisations within a corporate group, provided they are accessible to all relevant data subjects and authorities. For an EU SME, the threshold question is whether you conduct large-scale systematic monitoring (a CCTV network covering a city, behavioural advertising, real-time location tracking) or large-scale special category processing (health data, biometrics, trade union membership). If either applies, appointing a DPO is not optional. Failure to appoint a required DPO is a violation subject to fines of up to €10 million or 2% of global annual turnover. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

A Data Protection Impact Assessment is a structured process for identifying and minimising data protection risks before commencing a new processing activity. Required under GDPR Article 35, a DPIA is mandatory when processing is likely to result in a high risk to the rights and freedoms of natural persons. Article 35(3) gives three examples where a DPIA is always required: systematic and extensive profiling with significant effects on individuals; large-scale processing of special category data; and systematic monitoring of a publicly accessible area on a large scale. Supervisory authorities also publish lists of specific processing types in their jurisdiction that require a DPIA — consulting these lists is a practical starting point. The DPIA must contain at minimum a systematic description of the envisaged processing operations and their purposes, including the legitimate interest pursued by the controller; an assessment of the necessity and proportionality of the processing operations in relation to the purposes; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address the risks. The assessment must be carried out before the processing begins, not retrospectively, and must be consulted on with the Data Protection Officer where one has been appointed. If the DPIA reveals that the processing would result in a high residual risk — one that cannot be mitigated by the measures the controller intends to implement — the controller must consult the competent supervisory authority before proceeding, under Article 36. The authority has up to eight weeks (extendable to 14) to respond, and may prohibit the processing or require modifications. This prior consultation mechanism gives regulators a veto over the highest-risk processing activities. For an EU SME, DPIAs are not just regulatory box-ticking. They are a risk management discipline that helps you identify whether a new product feature, a new marketing technique, or a new vendor integration crosses a threshold that could expose you to enforcement action. Failing to conduct a required DPIA is an independent breach of Article 35, attractable a fine of up to €10 million or 2% of global annual turnover — separate from any fine for the underlying processing violation itself. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

GDPR grants individuals — called data subjects — a suite of rights over the processing of their personal data, set out in Articles 15 through 22. These rights give individuals active control over their information rather than passive protection, and controllers must have processes in place to receive, verify, and respond to rights requests before they receive one — not after. The eight rights are as follows. The right to be informed (Articles 13 and 14) requires controllers to provide transparency about processing at the point of data collection. The right of access (Article 15) allows an individual to obtain confirmation of whether their data is being processed and, if so, a copy of the personal data together with supplementary information about the processing. The right to rectification (Article 16) requires correction of inaccurate data and completion of incomplete data. The right to erasure (Article 17) — colloquially the right to be forgotten — allows individuals to request deletion in specific circumstances, such as when the data is no longer necessary for its original purpose or when consent is withdrawn. The right to restriction of processing (Article 18) allows individuals to request that processing be paused while accuracy or legitimacy is contested. The right to data portability (Article 20) gives individuals the right to receive their data in a structured, machine-readable format and, where technically feasible, to have it transmitted directly to another controller. The right to object (Article 21) allows individuals to object to processing based on legitimate interests or for direct marketing, requiring the controller to stop unless compelling legitimate grounds are demonstrated. The right not to be subject to solely automated decision-making (Article 22) protects individuals from decisions with significant legal or similarly significant effects that are made without any human involvement, with limited exceptions. Controllers must respond to requests without undue delay and within one month. This period can be extended by a further two months for complex or numerous requests, with notification to the requester. Requests must be processed free of charge unless manifestly unfounded or excessive. For an EU SME, having a documented process for handling rights requests — including identity verification, routing to the right team, and keeping a response log — is essential. Failure to comply with a request is a direct violation enforceable by the supervisory authority, with fines up to €20 million or 4% of global annual turnover. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Regulation (EU) 2024/1689, known as the EU AI Act, is the world's first comprehensive horizontal legal framework for artificial intelligence. Published in the Official Journal of the EU on 12 July 2024, it entered into force on 1 August 2024 and applies in phases over a 36-month transition period. The regulation applies to providers who place AI systems on the EU market or put them into service in the EU, regardless of whether the provider is established inside or outside the Union. It also applies to deployers — organisations that use AI systems in a professional context — when those systems are classified as high-risk. The Act classifies AI systems into four risk tiers. Unacceptable-risk practices (Article 5) are prohibited outright and have applied since 2 February 2025. Limited-risk systems — such as chatbots — carry transparency obligations requiring users to be informed they are interacting with AI. Minimal-risk systems face no mandatory requirements. High-risk systems, defined in Article 6 and Annex III, are the Act's main regulatory target: they must meet requirements covering risk management, training data governance, technical documentation (Annex IV), logging, transparency, human oversight, accuracy, and robustness before being placed on the market. For EU SMEs, the most pressing deadline is 2 August 2026, when obligations for high-risk AI systems under Annex III fully apply. If your business uses AI in hiring decisions, creditworthiness assessment, access to essential services, or safety-critical operations, you are almost certainly in scope. The Act also introduces requirements for General Purpose AI models (Chapter V) — large foundational models such as those underlying popular AI tools. Penalties are steep: up to €35 million or 7% of global annual turnover for deploying prohibited AI, up to €15 million or 3% for violations of other obligations, and up to €7.5 million or 1.5% for supplying incorrect information to regulators. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

Essential entity is a classification under NIS2 Directive Article 3 that identifies organisations facing the most stringent cybersecurity supervision and the highest financial penalties. An organisation is classified as an essential entity if it operates in a sector listed in Annex I of the Directive — the highly critical sectors — and meets the threshold for a large enterprise, defined in EU law as having 250 or more employees or an annual turnover exceeding €50 million with a balance sheet exceeding €43 million. Certain categories of organisations are classified as essential regardless of size: qualified trust service providers, top-level domain name registries, DNS service providers, public electronic communications networks, operators of critical infrastructure identified by member states, and public administration bodies at central level. Essential entities are subject to proactive, ex-ante supervision by their national competent authority. This means regulators do not wait for an incident before examining compliance — they can conduct audits, request evidence of security measures, and carry out on-site inspections on a scheduled basis or at any time they have reason to believe non-compliance exists. Competent authorities can also require essential entities to submit to security audits carried out by qualified independent bodies. The Article 21 security obligations that essential entities must implement cover ten domains: risk analysis and security policies; incident handling; business continuity, backup management, and disaster recovery; supply chain security including security in relationships with direct suppliers and service providers; network and information system security in acquisition, development, and maintenance; policies and procedures to assess effectiveness of cybersecurity measures; basic cyber hygiene practices and cybersecurity training; policies on the use of cryptography and, where appropriate, encryption; human resources security, access control policies, and asset management; and the use of multi-factor authentication, continuous authentication solutions, and secure communications. For an EU SME that qualifies as an essential entity — even if not yet aware of the classification — the stakes are high. Fines for essential entities in breach of NIS2 obligations can reach €10 million or 2% of global annual worldwide annual turnover, whichever is higher. Management boards bear personal oversight responsibility. See the NIS2 compliance guide at eurocomply.app/regulations/nis2

EU data residency refers to the requirement that data be stored and processed within the territorial boundaries of the European Union or the European Economic Area. While GDPR does not impose a blanket data residency requirement on private sector organisations — its Chapter V restrictions apply to transfers of personal data to third countries, not to restrictions on processing within the EU — data residency is increasingly mandated by sector-specific regulations, public sector procurement rules, contractual requirements, and national security frameworks. In healthcare, the processing of patient data is subject to residency requirements in several member states under national health data laws. In financial services, requirements under DORA and various national prudential rules restrict where critical data and operational systems can be hosted. In public administration, many member states require that government data be stored on EU-based infrastructure, and some require specifically national territory. Defence and dual-use sectors frequently require both EU residency and physical access controls that exclude non-EU nationals. Data residency must be distinguished from data sovereignty, although the two are frequently conflated. Residency is a geographic constraint: data physically does not leave a defined territory. Sovereignty is a legal and access constraint: it concerns who has the legal right to access the data, regardless of where it physically sits. A data centre in Frankfurt operated by a US-headquartered hyperscaler satisfies a geographic residency requirement but does not provide data sovereignty, because US law — including the CLOUD Act — can compel the US parent to access data stored in that Frankfurt facility. True data sovereignty requires that the provider be subject only to EU law and have no legal relationship with jurisdictions whose government access powers are incompatible with GDPR. For an EU SME evaluating cloud and SaaS procurement, the practical questions are: where is data stored, under what law is the provider governed, which jurisdictions could compel access, and do any contractual or regulatory requirements in your sector or customer base mandate residency or sovereignty. Answering these questions requires a structured sovereignty audit of your entire technology stack, mapping each provider's legal structure against the data flows your business generates.

The EU AI Act database is a publicly accessible registration system established under Article 71 of the EU AI Act, maintained by the European AI Office at the European Commission level. Its purpose is to ensure that high-risk AI systems are identifiable before they are placed on the EU market or put into service, giving market surveillance authorities, procurement bodies, and the public a searchable record of which AI systems are available in the EU and who is responsible for them. Providers of high-risk AI systems listed in Annex III — except for systems in law enforcement, migration, and certain public sector uses, which are registered in a non-public section — must register their systems in the EU database before placing them on the market. The registration must include the name and contact details of the provider; the system's trade name and other commercial identifiers; a description of the intended purpose, the persons or groups it is intended to be used on, and the specific categories of natural persons at risk; the member states where the system is placed on the market or put into service; the version information; and where the conformity assessment was carried out by a notified body, the name and number of the notified body and the certificate number. For high-risk AI systems used by public sector deployers — government agencies, public health bodies, public schools — the provider must also register the deployer's information in the database on the deployer's behalf where the deployer is not a provider itself. Deployers in certain public sector contexts are themselves required to register use of high-risk AI systems. For an EU SME developing high-risk AI products, registration in the EU database is a non-negotiable pre-market step. Systems may not be placed on the market without completed registration, and registration information must be kept accurate and up to date throughout the system's lifecycle. Failure to register, providing false registration information, or failing to update registration details are independent violations attracting fines of up to €15 million or 3% of global annual turnover. The database is publicly searchable, meaning registration also creates a public accountability record that customers, civil society, and media can consult. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

The General Data Protection Regulation (Regulation (EU) 2016/679) is the cornerstone of EU data protection law, replacing the 1995 Data Protection Directive and entering into force on 25 May 2018. It applies to any organisation — regardless of where it is established — that processes personal data of individuals residing in the European Union or European Economic Area. Personal data means any information that can identify a living person, directly or indirectly: a name, an email address, an IP address, a cookie identifier, or a combination of attributes that singles someone out. The regulation is built on seven foundational principles set out in Article 5: lawfulness, fairness, and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. Accountability is the principle that distinguishes GDPR from its predecessor — organisations must be able to demonstrate compliance, not merely assert it. For an EU SME, GDPR creates concrete operational obligations. You need a documented lawful basis for every processing activity (Article 6), a privacy notice that meets the transparency requirements of Articles 13 and 14, a mechanism to respond to data subject requests within one month (Articles 15–22), and a procedure for notifying your national Data Protection Authority of a personal data breach within 72 hours (Article 33). If your processing is high-risk, you must complete a Data Protection Impact Assessment before starting (Article 35). The consequences of getting it wrong are severe. The supervisory authority in your member state can impose administrative fines of up to €10 million or 2% of global annual turnover for violations of organisational requirements such as missing records or inadequate processor contracts. The upper tier — up to €20 million or 4% of global annual turnover, whichever is higher — applies to breaches of the fundamental principles, lack of lawful basis, or violations of data subject rights. These percentages apply to the entire corporate group's worldwide revenue, not just the entity in breach. Beyond fines, supervisory authorities can issue temporary or permanent bans on processing, which can be existential for data-dependent businesses. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

General Purpose AI models — universally abbreviated as GPAI — are defined in EU AI Act Article 3(63) as AI models trained on large amounts of data using self-supervision at scale that displays significant generality and is capable of competently performing a wide range of distinct tasks. In practical terms, this covers the large language models and foundation models that underlie popular AI tools and APIs: systems capable of generating text, code, images, and other outputs across multiple domains. The GPAI provisions occupy Chapter V of the Act, comprising Articles 51 through 56, and have applied since 2 August 2025. All GPAI model providers must comply with a baseline set of obligations regardless of model scale. Under Article 53, they must draw up and keep up to date technical documentation containing information specified in Annex XI; establish and publish a policy to comply with EU copyright law, including identifying and honouring reservations of rights for training data; and make publicly available a summary of the training data used, sufficient to provide meaningful transparency. For GPAI models deemed to pose systemic risk — those trained using a compute threshold exceeding 10 to the power of 25 floating point operations — additional obligations apply under Article 55. These include performing model evaluations including adversarial testing before release and after significant updates, assessing and mitigating systemic risks, reporting incidents and malfunctions to the European AI Office, and implementing cybersecurity measures proportionate to the risk. The European AI Office is the primary enforcement body for GPAI models, with powers to request documentation, carry out evaluations, and impose fines. For an EU SME using a GPAI model via an API or embedding it in a product, you are typically a deployer rather than a provider — most of the Chapter V obligations sit with the model provider. However, if your product integrates a GPAI model into a high-risk use case, the high-risk provisions of Title III apply to your system. Fines for GPAI providers in breach of their obligations can reach €15 million or 3% of global annual turnover. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

The EU AI Act's concept of a high-risk AI system is the regulation's central regulatory category — it is where the vast majority of substantive obligations sit, and where most compliance effort for commercial AI applications must be focused. High-risk AI systems are defined in Article 6 and Annex III, and the classification has two tracks. The first track covers AI systems that are themselves safety components of products subject to existing EU product safety legislation — such as the Machinery Regulation, the Medical Devices Regulation, or the Radio Equipment Directive — where those products require a third-party conformity assessment. The second track, which is far broader in commercial significance, covers AI systems in eight use-case categories listed in Annex III: biometric identification and categorisation of natural persons; management and operation of critical infrastructure; education and vocational training; employment, workers management, and access to self-employment; access to and enjoyment of essential private and public services and benefits; law enforcement; migration, asylum, and border control management; and administration of justice and democratic processes. With certain exceptions for narrow or low-risk applications, an AI system that falls into these Annex III categories is presumed high-risk. Before deploying such a system, providers must implement a risk management system under Article 9; use high-quality training, validation, and testing datasets under Article 10; produce and maintain Annex IV technical documentation under Article 11; build in automatic event logging under Article 12; ensure transparency to deployers under Article 13; design for effective human oversight under Article 14; achieve appropriate levels of accuracy, robustness, and cybersecurity under Article 15; and — for providers — complete a conformity assessment and register the system in the EU database before placing it on the market. For an EU SME deploying AI, the critical threshold question is whether the system materially influences an outcome that significantly affects a person's access to employment, services, education, or similar consequential domains. Getting this classification wrong — deploying a system that should be classified as high-risk without the required documentation and assessment — can result in fines of up to €15 million or 3% of global annual turnover. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

Important entity is a classification under NIS2 Directive Article 3 that applies to medium-sized organisations operating in sectors covered by the Directive, as well as large organisations in the sectors listed in Annex II — the other critical sectors. A medium-sized enterprise for this purpose is one with 100 to 249 employees and an annual turnover between €10 million and €50 million, or a balance sheet between €10 million and €43 million. Annex II sectors include postal and courier services, waste management, manufacture and distribution of chemicals, food production and distribution, manufacturing of medical devices and other critical products, digital providers such as online marketplaces and cloud computing services, and research organisations. Important entities are subject to reactive, ex-post supervision rather than the proactive approach applied to essential entities. This means that competent authorities generally act in response to evidence of non-compliance, a notified incident, or a complaint, rather than initiating audits on a scheduled basis without prior cause. However, the substantive obligations are identical: important entities must implement the same ten categories of cybersecurity measures under Article 21 and must comply with the same incident reporting timelines under Article 23 — early warning within 24 hours of becoming aware of a significant incident, incident notification within 72 hours, and a final report within one month. The primary distinction between the two tiers is the penalty ceiling and the supervisory intensity. Important entities face maximum administrative fines of €7 million or 1.4% of global annual turnover, compared to €10 million or 2% for essential entities. Member states may set higher specific penalties within these ceilings in their national transposition legislation. For an EU SME in a covered sector that falls into the important entity tier, the lower maximum fine should not encourage complacency. Supervisory authorities still have the power to issue binding instructions, require immediate remediation, and impose temporary operational restrictions. Management bodies bear personal responsibility for approving cybersecurity risk management measures and face personal liability for persistent or negligent non-compliance. The first step for any organisation uncertain about its classification is to carry out a scoping assessment against the Annex II sector definitions and the headcount and turnover thresholds. See the NIS2 compliance guide at eurocomply.app/regulations/nis2

Incident reporting is one of the core operational obligations in NIS2 Directive Article 23, requiring essential and important entities to notify the competent national authority and their national CSIRT — Computer Security Incident Response Team — when they experience a significant cybersecurity incident. The obligation applies from the moment the organisation becomes aware that an incident has occurred, triggering a three-stage notification timeline that is among the most demanding in EU regulatory law. The first stage is an early warning, which must be submitted within 24 hours of becoming aware of the significant incident. The early warning must indicate, without substantive analysis required at this stage, whether the incident is suspected to be caused by unlawful or malicious acts and whether it is likely to have cross-border impact. The second stage is the incident notification, due within 72 hours of awareness, which must provide an initial assessment of the incident including its severity, impact, and indicators of compromise. The third stage is a final report, due within one month of the incident notification, which must contain a detailed description of the incident, its root cause, mitigating measures taken and ongoing, and any cross-border impact. A significant incident is defined as one that has caused or is capable of causing severe operational disruption to the services provided or financial losses to the entity concerned, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The NIS2 Directive deliberately uses broad, impact-based thresholds rather than specific technical criteria to capture a wide range of events including ransomware, supply chain compromises, and data breaches affecting system availability. For an EU SME operating as an essential or important entity, having a pre-built incident response playbook is not optional — it is a compliance prerequisite. The 24-hour early warning timeline in particular requires organisations to have pre-established relationships with their CSIRT, internal escalation paths, and pre-approved notification templates ready to deploy before an incident occurs. Failure to report a significant incident within the required timelines, or providing incomplete notifications, can result in fines of up to €10 million (essential entities) or €7 million (important entities) independent of any penalty for the underlying incident itself. See the NIS2 compliance guide at eurocomply.app/regulations/nis2

GDPR Article 6 establishes the principle that processing personal data is prohibited unless it falls within one of six exhaustive lawful bases. Choosing and documenting the correct lawful basis before processing begins is one of the most foundational GDPR obligations, because the lawful basis determines which data subject rights apply, how you must respond if a data subject objects, and what you must communicate in your privacy notice. The six bases are: consent (the individual has given a clear, specific, informed, and unambiguous indication of agreement); contract performance (processing is necessary for the performance of a contract with the individual, or to take steps at their request prior to entering a contract); legal obligation (processing is necessary to comply with a legal requirement the controller is subject to); vital interests (processing is necessary to protect someone's life); public task (processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority); and legitimate interests (processing is necessary for the purposes of the controller's or a third party's legitimate interests, except where those interests are overridden by the interests or fundamental rights of the data subject). Consent deserves particular attention for SMEs. Under GDPR, consent must be freely given (meaning it cannot be bundled with service access unless processing is genuinely necessary for the service), specific (covering each distinct purpose), informed (explained in plain language), and unambiguous (requiring a positive opt-in act — pre-ticked boxes do not qualify). Consent can be withdrawn at any time, and withdrawal must be as easy as giving consent. Legitimate interests requires a documented three-part balancing test: identifying the legitimate interest, demonstrating that the processing is necessary to achieve it, and confirming the interest is not overridden by the data subject's rights and freedoms. For an EU SME, selecting the wrong lawful basis is a common and costly mistake. Using consent as a basis when legitimate interests would be more appropriate means you must stop processing if consent is withdrawn, even if you have a genuine business need. Conversely, relying on legitimate interests without documenting the balancing test leaves you exposed in any audit. Fines for processing without a lawful basis can reach €20 million or 4% of global annual turnover. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union — known as NIS2 — entered into force on 16 January 2023, with member states required to transpose it into national law by 17 October 2024. It replaces the original NIS Directive (2016/1148) and represents a dramatic expansion in scope, bringing thousands of additional organisations across Europe under mandatory cybersecurity requirements for the first time. NIS2 covers 18 sectors divided into two annexes. Annex I contains highly critical sectors including energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, and space. Annex II contains other critical sectors including postal and courier services, waste management, chemicals, food production, manufacturing, digital providers, and research organisations. Within these sectors, organisations are classified as essential entities or important entities depending on their size and criticality, with different supervisory regimes and penalty ceilings applying to each tier. The core obligations in Article 21 require all in-scope organisations to implement appropriate and proportionate technical, operational, and organisational measures to manage cybersecurity risks. These measures must cover ten minimum areas: risk analysis and information system security policies; incident handling; business continuity and crisis management; supply chain security; network and information system acquisition and development; policies and procedures to assess cybersecurity risk management measures; basic cyber hygiene practices and training; cryptography and encryption policies; human resources security and access control policies; and the use of multi-factor authentication and secure communication systems. For an EU SME operating in a covered sector, NIS2 compliance means conducting a scope assessment, implementing the Article 21 measures, registering with your national competent authority, and establishing the processes needed to submit incident notifications within the required timeframes. Management bodies — boards and senior executives — bear personal responsibility for approving and overseeing cybersecurity measures, and can be held personally liable for non-compliance. Fines for essential entities can reach €10 million or 2% of global annual turnover; for important entities, €7 million or 1.4%. See the NIS2 compliance guide at eurocomply.app/regulations/nis2

A notified body is a third-party conformity assessment organisation that has been designated by an EU member state authority and formally notified to the European Commission as competent to carry out specific conformity assessment procedures on behalf of commercial operators. Notified bodies are the institutional mechanism through which the EU delivers independent technical verification of product compliance across a wide range of regulations — from medical devices and pressure equipment to the EU AI Act. For the EU AI Act, notified bodies play a role in the conformity assessment of specific high-risk AI systems that cannot rely on the self-assessment route. Under Article 43, AI systems listed in Annex III paragraphs 1(a) — AI systems intended to be used for the real-time remote biometric identification of natural persons in publicly accessible spaces — require a third-party conformity assessment by a notified body. Other systems may also require notified body involvement if they are safety components of products subject to third-party assessment under other EU product safety legislation. A notified body is not a government agency: it is an accredited private or public organisation that has been evaluated by the national accreditation body — such as DAkkS in Germany or COFRAC in France — and found to meet the competence, impartiality, and independence requirements set out in the AI Act and in ISO/IEC 17065. Notified bodies are listed in the NANDO database maintained by the European Commission, and providers must use a notified body from this registry. The process of engaging a notified body involves submitting technical documentation, application documentation, and potentially sample systems for evaluation. The notified body issues a certificate valid for a defined period, subject to surveillance audits. The certificate is required before the CE mark can be affixed and before the system can be registered in the EU AI Act database. For an EU SME developing a biometric identification AI system, selecting and engaging a notified body early in the development lifecycle is essential — lead times can be substantial. Placing a system that requires notified body assessment on the market without such assessment can attract fines of up to €15 million or 3% of global annual turnover. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

Privacy by Design — formally codified in EU law as data protection by design and by default under GDPR Article 25 — is the principle that data protection should be an integral part of system design from the earliest stages, not a layer added after a product has already been built. The concept, originated by Canadian privacy commissioner Ann Cavoukian in the 1990s, was elevated to a legal obligation by GDPR and applies to both controllers designing new processing systems and product manufacturers building products used for processing. Article 25(1) requires controllers, both at the time of determining the means of processing and at the time of the processing itself, to implement appropriate technical and organisational measures — such as pseudonymisation — designed to implement data protection principles effectively and integrate necessary safeguards into the processing. The controller must take into account the state of the art, the cost of implementation, the nature, scope, context, and purposes of the processing, and the likely risks to individuals' rights and freedoms. Article 25(2) specifies the complementary obligation of data protection by default: controllers must ensure that, by default, only personal data necessary for each specific purpose is processed. This applies to the amount of data collected, the extent of its processing, the period of storage, and its accessibility. In practice, this means pre-setting the most privacy-protective option — for example, analytics tracking disabled by default, location data not requested unless essential, and profile fields not pre-populated from inferences. For an EU SME, privacy by design means embedding privacy considerations into product roadmaps and engineering sprints: minimising data collection to what is genuinely necessary, tokenising or pseudonymising sensitive identifiers, implementing access controls at the schema level rather than the application layer, configuring retention policies in the database rather than leaving data indefinitely, and documenting these design decisions as part of Annex IV technical documentation if an AI system is involved. Supervisory authorities increasingly examine whether privacy by design was genuinely implemented during design review, and the absence of it can support findings of systemic non-compliance. Fines can reach €10 million or 2% of global annual turnover. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Pseudonymisation is defined in GDPR Article 4(5) as the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person. Common techniques include replacing a natural person's name or identifier with a randomly generated token, hashing a key identifier, or using encryption where the decryption key is held separately from the pseudonymous data. The critical distinction between pseudonymisation and anonymisation is reversibility. Pseudonymised data is still personal data under GDPR because it can, with access to the additional information, be re-attributed to an individual. Truly anonymous data — data from which the individual cannot be identified by any means reasonably likely to be used — falls outside GDPR's scope entirely. This distinction has real consequences: a dataset of pseudonymous customer records is still within scope; a genuinely de-identified statistical dataset is not. Despite remaining personal data, pseudonymisation carries meaningful GDPR benefits. Article 25 recognises it as an appropriate technical measure for implementing privacy by design. Article 32 cites pseudonymisation as one of the measures controllers and processors should consider as part of their security obligations. Recital 85 indicates that pseudonymisation can reduce the likelihood of a personal data breach meeting the threshold of notification. In the context of research, public health, and archiving under Article 89, pseudonymisation is explicitly identified as a safeguard that enables processing beyond the original collection purpose. For an EU SME, pseudonymisation is a high-value technical investment that reduces risk across multiple compliance obligations simultaneously: it reduces breach severity, supports data minimisation in analytics and testing environments, enables data sharing within or outside the organisation with reduced exposure, and can be documented as a concrete privacy-by-design measure. Implementing pseudonymisation in development and testing databases — where real production data is otherwise frequently used — is one of the most accessible compliance improvements an engineering team can deliver. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Article 5 of the EU AI Act establishes an outright prohibition on certain AI practices that the EU legislature determined pose unacceptable risks to fundamental rights, human dignity, and democratic values. These prohibitions are not subject to a risk-balancing assessment — they apply absolutely, regardless of the technical quality, accuracy, or intended benefit of the AI system in question. The Article 5 prohibitions entered into force on 2 February 2025, six months after the Act's entry into force. The eight prohibited practices are: AI systems that deploy subliminal techniques beyond a person's consciousness to distort their behaviour in a way that causes or is likely to cause harm; AI systems that exploit the vulnerabilities of specific groups due to their age, disability, or social or economic situation; social scoring systems by or on behalf of public authorities that evaluate or classify natural persons based on their social behaviour or personal characteristics and lead to detrimental or unfavourable treatment; real-time remote biometric identification of natural persons in publicly accessible spaces for law enforcement purposes, except in a narrow set of permitted circumstances such as searches for missing children, prevention of imminent terrorist threats, or identification of serious crime suspects; retrospective remote biometric identification systems used for law enforcement purposes where not specifically authorised; emotion recognition systems used in the workplace or educational institutions, except for safety or medical reasons; biometric categorisation systems that infer sensitive attributes such as race, political opinion, trade union membership, religious or philosophical beliefs, or sexual orientation from biometric data; and AI-assisted compilation of facial recognition databases by scraping facial images from the internet or CCTV footage. For an EU SME, the Article 5 prohibitions are most relevant for HR technology (emotion recognition at interviews is prohibited), marketing technology (behavioural manipulation systems are prohibited), and any law enforcement or public sector AI application. Using a prohibited AI system is the most serious category of violation under the Act, attracting fines of up to €35 million or 7% of global annual worldwide turnover — the highest penalty tier in the regulation. See the AI Act compliance guide at eurocomply.app/regulations/ai-act

A Record of Processing Activities — universally abbreviated as ROPA — is the central accountability document required by GDPR Article 30. It is an internal register of every processing activity that an organisation carries out, maintained in writing (which includes electronic form). Controllers must keep a ROPA that includes, for each processing activity: the name and contact details of the controller and, where applicable, the DPO; the purposes of the processing; a description of the categories of data subjects and personal data; the categories of recipients to whom data has been or will be disclosed; details of transfers to third countries or international organisations and the safeguards relied upon; envisaged retention periods; and a general description of the technical and organisational security measures. Processors must maintain their own ROPA under Article 30(2), covering each category of processing carried out on behalf of controllers, including the controller's identity, the categories of processing, third-country transfers, and security measures. The processor ROPA mirrors the controller's but is structured around the service relationships rather than the underlying processing purposes. The formal obligation applies to organisations with 250 or more employees. However, the Article 30(5) exemption for smaller organisations does not apply if the processing is likely to result in a risk to the rights and freedoms of data subjects, if the processing is not occasional, or if the processing includes special category data or personal data relating to criminal convictions. In practice, most SMEs involved in any systematic processing — regular email marketing, a CRM, employee HR systems — will be required to maintain a ROPA regardless of headcount. For an EU SME, the ROPA is not a compliance checkbox to be completed once and forgotten. Supervisory authorities request it as the first document in any investigation or audit, and an absent, incomplete, or out-of-date ROPA is itself an administrative violation subject to fines of up to €10 million or 2% of global annual turnover. Equally important, building and maintaining a ROPA forces the discipline of knowing what data you hold, where it goes, how long you keep it, and on what legal basis — the foundation of every other GDPR obligation. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

Standard Contractual Clauses are sets of pre-approved contractual terms adopted by the European Commission under GDPR Article 46 that provide an appropriate safeguard for transferring personal data from the EU or EEA to third countries that do not benefit from an adequacy decision. When a controller or processor sends personal data to a recipient in, for example, the United States, India, or the Philippines, they need a legal mechanism to ensure the data will be protected to the EU standard at destination. SCCs are by far the most commonly used such mechanism for commercial transfers. The current EU SCCs were adopted by the European Commission on 4 June 2021, replacing the previous 2001 and 2010 clauses. They are structured in four modules: Module 1 covers controller-to-controller transfers; Module 2 covers controller-to-processor transfers; Module 3 covers processor-to-processor transfers; and Module 4 covers processor-to-controller transfers. Organisations select the module or combination of modules appropriate to their transfer relationship and incorporate the clauses — without modification to the pre-approved text — into their contracts. The SCCs may be supplemented with additional clauses provided the additions do not contradict the SCCs or undermine the fundamental rights of data subjects. Following the Schrems II judgment of the Court of Justice in July 2020, reliance on SCCs alone is no longer automatically sufficient. Controllers must conduct a Transfer Impact Assessment (TIA) for each third country involved, evaluating whether the law and practice of the destination country — particularly government access powers — would prevent the SCCs from being effective in practice. Where the TIA reveals a shortfall, supplementary technical measures such as end-to-end encryption or pseudonymisation may need to be implemented before the transfer can proceed. For an EU SME using US-based SaaS tools, cloud services, or analytics platforms, SCCs combined with a TIA are typically the primary legal mechanism for the data flows involved. Transferring personal data to a third country without an adequate safeguard in place is a violation attracting fines of up to €20 million or 4% of global annual turnover. See the GDPR compliance guide at eurocomply.app/regulations/gdpr

A sovereignty audit is a structured assessment of an organisation's digital infrastructure and service stack designed to identify which systems, data flows, and providers are subject to the jurisdiction of non-EU legal regimes — and to quantify the legal access risk this creates for data that must be protected under EU law. The term is distinct from a cybersecurity audit, which assesses technical vulnerabilities, and from a GDPR compliance audit, which assesses the lawfulness of processing activities. A sovereignty audit focuses specifically on the legal and jurisdictional question: who, outside the EU, has a legal right to access our data without our knowledge or consent? The primary legal frameworks that create sovereignty risk for EU organisations are the US CLOUD Act (2018), which allows US law enforcement to compel US-headquartered cloud providers to produce data stored anywhere globally; the US FISA Section 702, which authorises US intelligence agencies to collect communications of non-US persons from US electronic communications service providers; and the UK Investigatory Powers Act (IPA, 2016), which grants UK intelligence and law enforcement agencies access powers over providers subject to UK jurisdiction. Conducting a sovereignty audit involves five steps. First, inventory every SaaS application, cloud provider, and data processor the organisation uses. Second, for each provider, identify its legal headquarters, its ultimate parent company, and the jurisdiction of its parent — since CLOUD Act obligations flow through corporate ownership. Third, map the categories of personal and sensitive data that flow through or are stored in each system. Fourth, assess whether the legal regime governing each provider creates access risk that is incompatible with GDPR or with contractual or regulatory obligations to your customers or sector. Fifth, prioritise the highest-exposure services and evaluate EU-sovereign alternatives or data minimisation strategies that reduce the volume of sensitive data flowing through non-EU-governed providers. For an EU SME, a sovereignty audit is both a compliance exercise and a procurement framework. It produces a ranked list of sovereignty risk by provider and data category, enabling risk-informed decisions about which systems to replace, which to remediate through encryption and data minimisation, and which are acceptable given their risk profile. Regulators in healthcare, finance, and defence sectors increasingly expect evidence of sovereignty risk management as a component of broader security and data protection assessments.

Technical and Organisational Measures — universally referred to as TOMs — is the umbrella term used across EU data protection and cybersecurity law to describe the security and privacy safeguards that organisations must implement to protect personal data and information systems. The term appears in GDPR Article 32, NIS2 Article 21, DORA Chapter II, and the EU AI Act Article 9, each with a tailored but overlapping set of required measures. TOMs are the practical expression of the regulatory principle that security must be proportionate to risk — organisations must implement measures that are appropriate to the specific threats they face, the sensitivity of the data they hold, and the potential consequences of a breach. Under GDPR Article 32, controllers and processors must implement TOMs appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing. The Article gives examples — pseudonymisation, encryption, ensuring ongoing confidentiality and integrity, a process for regularly testing and evaluating the effectiveness of measures, and the ability to restore data after a physical or technical incident — but these are illustrative, not exhaustive. The goal is a risk-based security posture, documented and demonstrably implemented. Under NIS2 Article 21, the required TOMs are more prescriptive, covering ten specific domains: policies on risk analysis and information system security; incident handling; business continuity including backup management, disaster recovery, and crisis management; supply chain security; network and information systems security in acquisition, development, and maintenance; policies and procedures for assessing the effectiveness of cybersecurity measures; basic cyber hygiene and training; cryptography; human resources security and access control; and multi-factor authentication and secure communications. For an EU SME, TOMs are the tangible deliverable that regulators examine when conducting audits or investigating breaches. A data breach that occurs because basic TOMs were absent — no encryption, no access controls, no patching process — will attract significantly higher fines and more severe corrective orders than a breach that occurs despite documented and appropriate TOMs being in place. Demonstrating your TOMs through documented policies, system configurations, training records, and test results is the most effective way to reduce regulatory exposure across GDPR, NIS2, DORA, and the AI Act simultaneously.

The Clarifying Lawful Overseas Use of Data Act — commonly called the CLOUD Act — is a US federal law enacted in March 2018 that gives US law enforcement agencies, including the FBI and the Department of Justice, the authority to compel US-headquartered cloud providers and their subsidiaries to produce data stored anywhere in the world, including in EU data centres, in response to a lawful US court order or warrant. The CLOUD Act applies to any provider that is subject to US jurisdiction — meaning incorporated in the United States, listed on a US stock exchange, or having its principal place of business in the United States — regardless of where the data sits physically. The CLOUD Act creates a direct conflict with GDPR for organisations that store personal data of EU residents with a US-based cloud provider. If a US government agency compels that provider to hand over EU personal data without the data subject's knowledge and without a GDPR-compliant legal basis, the transfer likely violates GDPR's Chapter V restrictions on transfers to third countries. The data subject's rights of access, rectification, and transparency are also unavailable when data is accessed covertly by government agencies. This conflict has not been definitively resolved by EU–US treaty, and neither the EU–US Data Privacy Framework nor Standard Contractual Clauses neutralise CLOUD Act obligations — SCCs bind the parties to a commercial contract but cannot override a US statutory obligation. The CLOUD Act's reach extends to US parent companies: a subsidiary incorporated in Germany but owned by a US parent can receive a CLOUD Act order directing the parent to produce data from the subsidiary's EU systems. This means that the nationality of the operating entity's local subsidiary does not provide protection if the ultimate parent is US-headquartered. For an EU SME, CLOUD Act exposure is a genuine operational risk when using AWS, Microsoft Azure, Google Cloud, Salesforce, or any other service operated by a US corporate group. A sovereignty audit — mapping each SaaS and cloud provider against its legal headquarters and parent company structure — is the starting point for understanding and reducing this exposure. EU-sovereign alternatives from providers with no US parent and no US listing are outside CLOUD Act jurisdiction.