Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  / ,

  / ISO 27001 & GDPR: Why Certification Isn’t Compliance

ISO 27001 & GDPR: Why Certification Isn’t Compliance

Plenty of companies treat an ISO 27001 certificate as proof of GDPR compliance. It is not. The two frameworks overlap heavily, but they answer different questions, and the gap between them is exactly where regulators tend to look.

ISO 27001 tells you how to build a defensible security program.

GDPR tells you what the law expects when that program touches personal data.

Run one without understanding the other, and you will either over-engineer security you do not strictly need, or miss privacy obligations that carry real financial exposure.

This article maps where ISO 27001 and GDPR meet, where they part ways, and how to run them as a single coordinated effort rather than two competing projects.

ISO 27001 and GDPR

What Is ISO 27001?

ISO/IEC 27001 is the international standard for an Information Security Management System, or ISMS. The current edition is ISO 27001:2022. It is not a checklist of technical fixes. It is a management framework: a structured, repeatable way to identify information security risks, decide how to treat them, document those decisions, and improve over time.

Clauses 4 to 10 of the standard define the mandatory ISMS requirements, covering leadership, risk assessment, internal audit, and management review. Annex A then lists 93 controls grouped into four themes: organisational, people, physical, and technological.

You do not implement all 93 by default. You select the controls that address your assessed risks and justify your choices in a document called the Statement of Applicability. Certification against ISO 27001 is voluntary and is granted by an accredited third-party body after an audit.

What Is GDPR?

The General Data Protection Regulation is European Union law. It has been applied since 25 May 2018, and it applies to any organisation that processes the personal data of people in the EU, wherever that organisation is based.

GDPR is fundamentally about the rights of individuals, not just the security of data. It grants people rights over their personal data, including access, correction, erasure and portability. It places obligations on the organisations that decide how data is used (controllers) and those that process it on their behalf (processors).

It requires a lawful basis for every processing activity, mandates breach notification, and demands transparency about what happens to people’s information. You do not implement GDPR and receive a certificate. You obey it, and a regulator decides whether you have.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Key Differences Between ISO 27001 and GDPR

Scope and Purpose

ISO 27001 protects all information assets an organisation holds: intellectual property, financial records, operational data, source code and, yes, personal data. Its purpose is the confidentiality, integrity and availability of information in general. GDPR is narrower in one sense and broader in another. It covers only personal data of individuals in the EU, but it protects the person behind the data, not merely the data itself. A system can be flawlessly secure and still violate GDPR.

Legal Obligation vs. Voluntary Certification

This is the difference that catches people out. GDPR is binding law. If you process EU personal data, compliance is not optional, and there is no opting out. ISO 27001 is a voluntary standard. Organisations pursue it for assurance, for competitive advantage, and because customers increasingly demand it. Crucially, there is no such thing as a GDPR certificate. Regulators assess compliance through investigation and enforcement, not through a badge you can display.

Penalties for Non-Compliance

GDPR fines run on two tiers under Article 83. Less severe infringements — such as failures around records of processing or breach notification — can reach €10 million or 2% of global annual turnover, whichever is higher. The more serious tier, covering breaches of the core processing principles and data subject rights, can reach €20 million or 4% of global annual turnover. Failing an ISO 27001 audit carries no legal fine at all. The consequence is commercial: you do not get the certificate, or you lose it, and that can cost you contracts.

How ISO 27001 and GDPR Align

Despite their different purposes, the two frameworks were built on compatible logic, which is why running them together works.

Both treat information security as central.

GDPR Article 32 requires “appropriate technical and organisational measures” to secure personal data. That phrasing is almost a direct description of what an ISO 27001 ISMS produces. The controls an organisation selects for confidentiality and access already serve the regulation’s security expectations.

Both are risk-based.

ISO 27001 starts every control decision from a risk assessment. GDPR expects the same proportionality: the measures you apply should match the sensitivity of the data and the likelihood and severity of harm. One risk methodology can serve both, provided you assess personal data processing risks alongside broader security risks.

Both demand incident response.

ISO 27001’s incident management controls require organisations to detect, assess and respond to security events. GDPR Article 33 requires notifying the supervisory authority of a personal data breach within 72 hours of becoming aware of it. The ISO process is the engine that makes the GDPR deadline achievable.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

How ISO 27001 Can Help You Comply With GDPR

Four areas of an ISMS do direct, practical work toward GDPR compliance.

Asset management.

ISO 27001 requires an inventory of information and associated assets, with owners assigned. You cannot protect personal data, respond to access requests, or maintain records of processing if you do not know where that data lives. The asset inventory is the foundation for both frameworks.

Access control.

Identity management, privileged access controls and the principle of least privilege limit who can see personal data. That directly supports the GDPR requirement to ensure confidentiality and to prevent unauthorised access.

Operational security.

Logging, malware protection, backup and secure configuration keep personal data accurate, available and resistant to compromise. These map cleanly onto the integrity and availability expectations in Article 32. Techniques such as data masking for GDPR and ISO 27001 also sit within this space, reducing exposure without sacrificing operational utility.

Incident management.

A defined process for detecting and handling security events gives you the evidence trail and the response capability you need to meet breach notification obligations and to demonstrate you took the breach seriously.

 

Does ISO 27001 Certification Mean You Are GDPR Compliant?

No. This is the single most expensive misconception in this area. ISO 27001 builds strong security, and security is one part of GDPR.

It does not address lawful basis for processing, consent management, transparency notices, the handling of data subject rights such as access and erasure, data protection impact assessments, the appointment of a Data Protection Officer where required, or the legal mechanisms for transferring data outside the EU.

A certified ISMS can sit on top of processing that is entirely unlawful. It is also one of the most common pitfalls organisations encounter with ISO 27001 — assuming the certificate does more than it actually does.

 

GDPR Principles and How ISO 27001 Supports Them

Article 5 of GDPR sets out seven principles for processing personal data. Looking at each one shows precisely where ISO 27001 carries weight and where it leaves you exposed.

Lawfulness, fairness and transparency requires a valid legal basis for processing and clear communication with individuals about it. ISO 27001 barely touches this. It is almost entirely privacy work.

Purpose limitation means data collected for one purpose should not be repurposed incompatibly. ISO 27001 does not govern why you collect data, so it offers little here.

Data minimisation calls for collecting only what you need. ISO 27001 will secure whatever you hold, but it does not tell you to hold less. The principle is a privacy and design decision.

Accuracy requires personal data to be correct and current. ISO 27001’s integrity controls help protect data from unauthorised alteration — partial support — though data quality processes themselves sit outside the standard.

Storage limitation means not keeping data longer than necessary. ISO 27001 provides retention and secure deletion controls that operationalise a retention schedule, but deciding the actual retention period is a legal call.

Integrity and confidentiality — the security principle — is where ISO 27001 is at its strongest. The overlap with Article 32 is near-total. An ISMS is, in effect, a delivery mechanism for this principle.

Accountability requires you to demonstrate compliance, not just achieve it. Here, ISO 27001 is genuinely powerful: its documented policies, risk registers, internal audits and management reviews produce exactly the kind of evidence the accountability principle demands.

The pattern is clear. ISO 27001 supports the last two principles strongly and the rest partially or barely. Everything that is distinctly about privacy still needs dedicated work.

Control Mapping: ISO 27001 Annex A vs. GDPR

GDPR states what you must achieve. ISO 27001 Annex A offers a practical set of controls for how to achieve the security-related parts of it. The table below maps common GDPR requirements to the ISO 27001 controls that support them.

GDPR Requirement

Relevant ISO 27001 Annex A Controls

Coverage

Article 32 — Security of processingA.8.1 User endpoint devices, A.8.3 Information access restriction, A.8.5 Secure authentication, A.8.24 Use of cryptographyStrong
Article 33 — Breach notification (72-hour rule)A.5.24 Information security incident management planning, A.5.25 Assessment of information security events, A.5.26 Response to information security incidentsStrong
Article 30 — Records of processing activitiesA.5.9 Inventory of information and other associated assets, A.5.10 Acceptable use of informationPartial
Article 25 — Data protection by design and by defaultA.8.25 Secure development life cycle, A.8.27 Secure system architecture and engineering principlesPartial
Article 28 — Processor obligationsA.5.19 Information security in supplier relationships, A.5.20 Addressing information security within supplier agreementsPartial
Article 17 — Right to erasureA.8.10 Information deletionPartial
Article 6 — Lawful basis for processingNone directly applicableNot covered
Articles 13–14 — Transparency and privacy noticesNone directly applicableNot covered
Article 35 — Data protection impact assessmentNone directly applicable (risk assessment methodology can inform a DPIA)Not covered

A mapping like this is worth building for your own environment. It shows teams which work serves both objectives and prevents the duplication that comes from treating the two programmes as unrelated. An ISO 27001 gap analysis is the natural starting point: it tells you where your ISMS controls already satisfy GDPR expectations and where the gaps are large enough to require separate privacy work.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Why Technical Measures Alone Are Not Enough for GDPR Compliance

Article 32 deliberately requires technical “and organisational” measures. The wording is not decorative. Encryption, firewalls and access controls reduce the risk of a breach, but they say nothing about whether you had the right to process the data in the first place.

Consider a system protected to the highest technical standard that processes personal data with no lawful basis, sends no transparency notice, and ignores erasure requests. Every security control could pass an audit, while the processing remains unlawful from the first record.

GDPR compliance is a governance, legal and operational discipline as much as a technical one. ISO 27001 strengthens one pillar of it. It does not replace the others.

 

Why You Need Both ISO 27001 and GDPR Compliance

Time and Cost Savings by Pursuing Both Together

Organisations that treat ISO 27001 and GDPR as separate, unconnected projects end up paying twice. They run two risk assessments, write two overlapping sets of policies, deliver two training programmes and maintain two toolsets. Treated together, the shared elements are done once. A single risk assessment can cover personal data processing risks and broader security risks.

Encryption, access management and logging serve certification and compliance simultaneously. The marginal cost of addressing both at once is far lower than tackling them in isolation. If you are still scoping out where to start, gap analysis services can give you a clear picture of what already maps across and what still needs attention.

Building Trust With Customers and Partners

ISO 27001 certification is recognised globally and shortens vendor due diligence: a procurement team that sees the certificate can move faster. GDPR compliance, meanwhile, is effectively table stakes for doing business involving EU data, and customers increasingly ask for evidence of it directly.

Holding both signals a mature, deliberate approach to managing information and privacy. It tells partners you treat data protection as a discipline rather than a box to tick. According to Gartner research, only a minority of customers believe organisations will handle their personal data responsibly without being asked — demonstrable compliance changes that calculation.

 

How to Integrate ISO 27001 and GDPR Compliance

There are three workable approaches to organising the documentation when you run both programmes.

A fully unified system merges all policies, risk registers and evidence into a single management system. This works well for smaller organisations where the security and privacy functions are not sharply separated, but it can become unwieldy as the business grows, since GDPR-specific items such as DPIAs and records of processing activities sit awkwardly inside an ISMS structure designed around information assets.

Completely separate systems keep the ISMS and the privacy management framework entirely independent, with their own documentation, risk registers and review cycles. This avoids confusion about ownership but creates real risk of duplication and drift — the two programmes can develop inconsistencies that neither team notices until an audit or investigation surfaces them.

An integrated but distinguishable structure treats the ISMS as the foundation and builds GDPR-specific documentation alongside it, with explicit cross-references where controls serve both. The same risk assessment methodology drives both; the same incident process feeds both breach response obligations. Privacy-specific obligations live in dedicated documents owned by the privacy function, but they are linked to the security controls that support them. For most organisations this is the pragmatic middle ground. You can also use compliance tools to manage the cross-framework evidence in a single platform, which reduces the administrative overhead considerably.

 

ISO 27701: The Privacy Extension That Bridges ISO 27001 and GDPR

If ISO 27001 covers security and GDPR covers privacy, ISO/IEC 27701 is the standard built to close the distance. It defines a Privacy Information Management System, or PIMS, and adds privacy-specific controls for organisations acting as data controllers and processors. Its annexes include a direct mapping to GDPR requirements, which makes it the closest thing to a certifiable demonstration of privacy governance.

One important development is worth knowing. ISO 27701 was first published in 2019 as an extension to ISO 27001, meaning you had to hold an ISMS before you could implement or certify it.

In October 2025, ISO published a revised edition, ISO/IEC 27701:2025, which turns it into a stand-alone standard.

Organisations can now implement and certify a privacy management system independently, without ISO 27001 as a prerequisite, with a transition deadline of October 2028 for those already certified to the 2019 version.

In practice, ISO 27701 still works best alongside ISO 27001, since privacy depends on security. It gives a structured, auditable way to address the privacy obligations that ISO 27001 leaves untouched. One caveat carries over from GDPR itself: certification to ISO 27701 supports and evidences compliance, but no certificate is a substitute for the legal assessment a regulator would make.

Frequently Asked Questions

Is ISO 27001 compliant with GDPR?

ISO 27001 is compatible with GDPR and supports many of its requirements, particularly around security of processing, access control and incident management. It is not, by itself, a complete route to GDPR compliance, because it does not address privacy-specific obligations such as lawful basis and data subject rights.

No. Certification proves you have a working information security management system. GDPR compliance additionally requires lawful basis, transparency, consent where relevant, handling of data subject rights, data protection impact assessments and lawful international transfers. A certified ISMS covers the security pillar of GDPR, not the whole regulation.

No. GDPR is European Union law, enforced by national supervisory authorities. ISO standards are voluntary frameworks published by the International Organization for Standardization. They can support legal compliance, but they are not laws and cannot replace one.

If you process personal data of individuals in the EU, GDPR compliance is legally required. ISO 27001 remains optional, but it provides the security backbone that GDPR expects and is often demanded by customers and partners. Most organisations handling EU personal data benefit from running both.

GDPR is the legal obligation, so its requirements cannot wait. In practice, building the ISMS first is efficient, because it produces much of the risk assessment and many of the “appropriate technical and organisational measures” GDPR requires. The pragmatic answer is to plan them together rather than strictly sequencing one before the other.

GDPR carries administrative fines of up to €10 million or 2% of global turnover for less severe breaches, and up to €20 million or 4% for serious ones, whichever is higher. ISO 27001 has no legal penalty. Failing an audit means losing or not obtaining the certificate, which is a commercial consequence rather than a fine.

Organisations that handle significant volumes of EU personal data and that sell to security-conscious customers gain the most. Technology and SaaS providers, healthcare and financial services firms, and any processor handling data on behalf of EU clients benefit from pairing a recognised security certification with demonstrable privacy compliance.

ISO 27701 defines a Privacy Information Management System and adds privacy controls that ISO 27001 does not cover, with a built-in mapping to GDPR requirements. It began as an extension to ISO 27001 and, since the 2025 revision, can be implemented and certified as a stand-alone standard. It is the most direct bridge between an ISO security programme and GDPR’s privacy obligations, though it still does not amount to legal certification of compliance.

Axipro Author

Picture of Pedro Dias

Pedro Dias

Pedro has been writing online for over 10 years. With experience in all things programming, cyber security, and compliance, he is our editor-in-chief at Axipro.

Blog Highlights

Explore More Articles

Plenty of companies treat an ISO 27001 certificate as proof of GDPR compliance. It is not. The two frameworks overlap heavily, but they answer different questions, and the gap between them is exactly where regulators tend to look. ISO 27001 tells you how to build a defensible security program. GDPR tells you what the law expects when that program touches personal data. Run one without understanding the other, and you will either over-engineer security you do not strictly need, or miss privacy obligations that carry real financial exposure. This article maps where ISO 27001 and GDPR meet, where they part ways, and how to run them as a single coordinated effort rather than two competing projects. What Is ISO 27001? ISO/IEC 27001 is the international standard for an Information Security Management System, or ISMS. The current edition is ISO 27001:2022. It is not a checklist of technical fixes. It is a management framework: a structured, repeatable way to identify information security risks, decide how to treat them, document those decisions, and improve over time. Clauses 4 to 10 of the standard define the mandatory ISMS requirements, covering leadership, risk assessment, internal audit, and management review. Annex A then lists 93 controls grouped into four themes: organisational, people, physical, and technological. You do not implement all 93 by default. You select the controls that address your assessed risks and justify your choices in a document called the Statement of Applicability. Certification against ISO 27001 is voluntary and is granted by an accredited third-party body after an audit. What Is GDPR? The General Data Protection Regulation is European Union law. It has been applied since 25 May 2018, and it applies to any organisation that processes the personal data of people in the EU, wherever that organisation is based. GDPR is fundamentally about the rights of individuals, not just the security of data. It grants people rights over their personal data, including access, correction, erasure and portability. It places obligations on the organisations that decide how data is used (controllers) and those that process it on their behalf (processors). It requires a lawful basis for every processing activity, mandates breach notification, and demands transparency about what happens to people’s information. You do not implement GDPR and receive a certificate. You obey it, and a regulator decides whether you have. Key Differences Between ISO 27001 and GDPR Scope and Purpose ISO 27001 protects all information assets an organisation holds: intellectual property, financial records, operational data, source code and, yes, personal data. Its purpose is the confidentiality, integrity and availability of information in general. GDPR is narrower in one sense and broader in another. It covers only personal data of individuals in the EU, but it protects the person behind the data, not merely the data itself. A system can be flawlessly secure and still violate GDPR. Legal Obligation vs. Voluntary Certification This is the difference that catches people out. GDPR is binding law. If you process EU personal data, compliance is not optional, and there is no opting out. ISO 27001 is a voluntary standard. Organisations pursue it for assurance, for competitive advantage, and because customers increasingly demand it. Crucially, there is no such thing as a GDPR certificate. Regulators assess compliance through investigation and enforcement, not through a badge you can display. Penalties for Non-Compliance GDPR fines run on two tiers under Article 83. Less severe infringements — such as failures around records of processing or breach notification — can reach €10 million or 2% of global annual turnover, whichever is higher. The more serious tier, covering breaches of the core processing principles and data subject rights, can reach €20 million or 4% of global annual turnover. Failing an ISO 27001 audit carries no legal fine at all. The consequence is commercial: you do not get the certificate, or you lose it, and that can cost you contracts. How ISO 27001 and GDPR Align Despite their different purposes, the two frameworks were built on compatible logic, which is why running them together works. Both treat information security as central. GDPR Article 32 requires “appropriate technical and organisational measures” to secure personal data. That phrasing is almost a direct description of what an ISO 27001 ISMS produces. The controls an organisation selects for confidentiality and access already serve the regulation’s security expectations. Both are risk-based. ISO 27001 starts every control decision from a risk assessment. GDPR expects the same proportionality: the measures you apply should match the sensitivity of the data and the likelihood and severity of harm. One risk methodology can serve both, provided you assess personal data processing risks alongside broader security risks. Both demand incident response. ISO 27001’s incident management controls require organisations to detect, assess and respond to security events. GDPR Article 33 requires notifying the supervisory authority of a personal data breach within 72 hours of becoming aware of it. The ISO process is the engine that makes the GDPR deadline achievable. How ISO 27001 Can Help You Comply With GDPR Four areas of an ISMS do direct, practical work toward GDPR compliance. Asset management. ISO 27001 requires an inventory of information and associated assets, with owners assigned. You cannot protect personal data, respond to access requests, or maintain records of processing if you do not know where that data lives. The asset inventory is the foundation for both frameworks. Access control. Identity management, privileged access controls and the principle of least privilege limit who can see personal data. That directly supports the GDPR requirement to ensure confidentiality and to prevent unauthorised access. Operational security. Logging, malware protection, backup and secure configuration keep personal data accurate, available and resistant to compromise. These map cleanly onto the integrity and availability expectations in Article 32. Techniques such as data masking for GDPR and ISO 27001 also sit within this space, reducing exposure without sacrificing operational utility. Incident management. A defined process for detecting and handling security events gives you the evidence trail and the response capability you need to

A company that already holds a SOC 2 report has, by most industry estimates, already built somewhere between 60 and 80 percent of what ISO 27001 certification requires. Yet only a small fraction of organizations actually capture that overlap. Teams run the second framework as a fresh project, rewrite policies that already exist, and re-collect evidence they already have on file. The result is paying twice for the same security program. SOC 2 to ISO 27001 mapping is the discipline that stops this. It is a control crosswalk: a structured comparison that shows which SOC 2 controls already satisfy which ISO 27001 requirements, where the genuine gaps sit, and what new work the second framework actually demands. Done well, it turns the second audit from a rebuild into a mapping exercise. What Is SOC 2 to ISO 27001 Mapping? SOC 2 to ISO 27001 mapping links each SOC 2 Trust Services Criterion to its corresponding ISO 27001 clause or Annex A control. The output is a single control library: each control is defined once, tagged to both frameworks, and backed by evidence that both auditors will accept. Worth being clear about upfront: a crosswalk does not make you compliant with anything. It shows where coverage already exists and where it does not. The real work still sits in control design, evidence discipline, and keeping the mapping current as systems and vendors change. A spreadsheet built once and never touched again becomes an audit liability, not an asset. For a structured starting point, a thorough SOC 2 to ISO 27001 gap analysis will surface those liabilities before an auditor does.   SOC 2 Trust Services Criteria: An Overview SOC 2 is an attestation framework from the American Institute of Certified Public Accountants (AICPA). It is built on five Trust Services Categories: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is the only mandatory category, and every SOC 2 report includes it. The Security category is evaluated through the Common Criteria, written as CC1 through CC9, containing 32 individual criteria in total. CC1 through CC5 cover the control environment, communication, risk assessment, monitoring, and control activities, and they align directly with the COSO internal control framework. CC6 through CC9 are more technology-specific, covering logical and physical access, system operations, change management, and risk mitigation. A SOC 2 audit produces one of two report types. A Type 1 report assesses control design at a single point in time. A Type 2 report assesses both design and operating effectiveness across an observation window, usually 3 to 12 months. A licensed CPA firm issues the report. SOC 2 is an attestation, not a certification, and there is no such thing as a SOC 2 certificate. ISO 27001 Annex A Controls: An Overview ISO/IEC 27001 is the international standard for an information security management system, or ISMS. The current version, ISO 27001:2022, has two distinct layers, and the distinction matters for any mapping effort. Clauses 4 through 10 define the management system itself: organizational context, leadership, planning, risk treatment, support, operations, performance evaluation, and improvement. These clauses are mandatory. Annex A is the second layer, a reference catalogue of 93 controls grouped into four themes: Organizational (37 controls), People (8), Physical (14), and Technological (34). The 2022 revision consolidated the previous 114 controls and 14 domains and added 11 new controls covering areas such as threat intelligence and cloud security. Annex A controls are not all mandatory. Organizations select controls based on a risk assessment and record their choices, including any exclusions and the reasoning behind them, in a Statement of Applicability. Certification is granted by an accredited body, lasts three years, and requires annual surveillance audits. Learn more about what the full certification process involves.   Key Structural Differences That Affect Mapping The two frameworks share a large security foundation, but they are built differently, and a mapping that ignores the structural gaps will fail. Understanding ISO 27001 vs SOC 2 at a structural level is the prerequisite for any mapping work worth doing. Four differences matter most. ISO 27001 certifies a management system, while SOC 2 attests to a set of controls. ISO Clauses 4 through 10 have no direct SOC 2 equivalent, because SOC 2 never asks you to prove you run a continuous, governed program; it asks only whether specific controls met specific criteria during the review period. Scope differs too. An ISO 27001 ISMS is expected to cover the organization broadly, while SOC 2 scope is set at the level of a system or service. The outputs differ as well: ISO produces a pass or fail certificate, whereas a SOC 2 report can carry noted exceptions or a qualified opinion and still be a valid, useful report. And because SOC 2 Type 2 tests evidence across a defined window, a control that worked only on audit day will not pass. The most common mapping mistake is treating ISO 27001 as SOC 2 plus a few extra controls. It is not. The Annex A controls map cleanly, but the ISMS management clauses, including internal audit, management review, and continual improvement, are a separate body of work with no SOC 2 starting point. Budget for them as net-new.   SOC 2 Common Criteria to ISO 27001 Control Mapping The Common Criteria map to ISO 27001 with a high degree of overlap. The table below is a practical starting crosswalk for the CC series. It lists the primary ISO 27001 references rather than every possible match, and your auditor’s judgment will shape the final mapping. SOC 2 Common Criteria Topic Primary ISO 27001:2022 References CC1 Control Environment Clauses 5 (Leadership), 6 (Planning), A.5.1, A.5.2, A.6.1–A.6.4 CC2 Communication and Information Clause 7.4 (Communication), A.5.1, A.6.3, A.8.2 CC3 Risk Assessment Clause 6.1 (Risk Assessment), A.5.7, A.8.8 CC4 Monitoring Activities Clause 9 (Performance Evaluation), A.5.35, A.5.36, A.8.16 CC5 Control Activities Clause 6.1.3 (Risk Treatment), A.5.37, A.8.9 CC6 Logical and Physical Access A.5.15–A.5.18, A.5.31, A.7.1–A.7.4, A.8.2–A.8.5, A.8.18 CC7 System Operations and Incident Response A.5.24–A.5.28, A.8.15, A.8.16 CC8

The world’s first comprehensive AI law is not a single switch that flips on in August 2026. It is a layered regulation that has been activating in stages since February 2025. As of May 2026, it is already being rewritten to give companies more time on the hardest parts. Anyone trying to plan around a single deadline is working from a map that no longer matches the territory. The law’s reach is also global. Just as GDPR exported European privacy norms worldwide, the EU AI Act is producing a Brussels Effect for artificial intelligence: a regulation drafted in Europe that becomes the de facto global standard. Companies in the US, the UK, Bahrain, and anywhere else with EU customers or EU-facing outputs are already in scope, whether or not they have a European office. This guide cuts through the noise. It explains what the EU AI Act actually requires, who it applies to, which rules are already live, which were just pushed back by the EU’s recent simplification deal, and what the penalties really look like for companies of different sizes. What Is the EU AI Act? The EU AI Act (Regulation (EU) 2024/1689) is a horizontal law that sets harmonised rules for developing, placing on the market, and using artificial intelligence systems across the European Union. It is the first comprehensive AI law passed by any major regulator anywhere in the world, and it entered into force on 1 August 2024. The Act takes a risk-based approach. Rather than regulating AI as a single category, it sorts AI systems into tiers based on the harm they could cause to health, safety, or fundamental rights. The higher the risk, the stricter the obligations. Prohibited uses are banned outright. High-risk uses are heavily regulated. Most everyday AI — like spam filters and product recommenders — is left alone. The law also creates a separate, parallel regime for general-purpose AI (GPAI) models, the foundation models behind systems like ChatGPT, Claude, and Gemini. That regime is enforced at the EU level rather than at the national level. Why Was the EU AI Act Created? The official answer is to foster trustworthy AI in Europe. The real answer is broader: the EU watched generative AI go mainstream in late 2022 and concluded that existing law — particularly GDPR — was not enough to address the specific risks AI systems pose. Opacity in decision-making, bias in hiring tools, biometric surveillance, and the manipulation potential of generative models all sat uneasily in the regulatory gap between data protection law and product safety law. The EU’s stated goals are to protect health, safety, and fundamental rights, while preserving innovation and the single market. The political subtext is the Brussels Effect: do for AI what GDPR did for privacy, and let European rules become the global default by virtue of market access. Brazil, Canada, the UK, several US states, and Gulf jurisdictions, including Bahrain, are already drafting AI rules that borrow heavily from the EU framework. For a broader view of how AI governance is likely to evolve through the end of the decade, the trajectory is already becoming clear. Who Does the EU AI Act Apply To? The Act does not apply to AI itself. It applies to people and organisations that build, sell, or use AI systems. Article 3 defines those roles without reference to company size, so a two-person startup is in scope on the same legal basis as a Fortune 500 enterprise. Providers and Developers A provider is anyone who develops an AI system — or has one developed — and places it on the EU market or puts it into service under their own name or trademark. Providers carry the heaviest load of obligations, particularly for high-risk systems: risk management, technical documentation, conformity assessment, post-market monitoring, and incident reporting. A provider is distinct from a downstream developer who simply integrates a third-party AI component. But the line moves: if you take a general-purpose model and put your name on the resulting product, you can become a provider yourself. Deployers and Operators A deployer is anyone using an AI system in a professional capacity. If you are a bank running a credit-scoring model you bought from a vendor, you are a deployer. Deployers have lighter obligations than providers but still carry real ones: ensuring human oversight, monitoring system behaviour, informing affected individuals, and conducting fundamental rights impact assessments where required. The term operator in the Act is an umbrella that covers providers, deployers, importers, distributors, and authorised representatives. Application Outside the EU This is where many non-EU companies get caught. The AI Act applies extraterritorially. A US LLC training a model in Texas, a UK firm running an AI hiring tool, or a Bahrain-based fintech using AI for credit scoring is in scope the moment the output affects someone in the EU. If a US company develops an AI hiring tool and a German employer uses it on German candidates, the US provider is in scope — even with no EU office. The trigger is whether the system’s output is used in the Union, not where the company sits. Pro Tip: Selling AI tools to EU customers outside the EU. If you sell AI tools to EU customers from outside the EU, you must appoint an authorised representative established in a Member State before placing high-risk systems on the market. This is not optional and is one of the most commonly missed obligations for non-EU providers. The Risk-Based Approach: How the EU AI Act Classifies AI Systems The framework sorts AI systems into four tiers. The obligations scale with the tier. Unacceptable Risk: Prohibited AI Practices Article 5 prohibits eight categories of AI practice outright. These prohibitions became enforceable on 2 February 2025, well before the rest of the Act. The banned practices are: Subliminal or manipulative techniques are designed to distort behaviour and cause significant harm. Exploitation of vulnerabilities related to age or disability. Social scoring by public or private actors —