Table of Contents

Reach SOC 2 Compliance in 6 Weeks or Less.

  /

  / The EU AI Act in 2026: What It Means for Businesses

The EU AI Act in 2026: What It Means for Businesses

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.

The EU AI Act in 2026 What It Means for Your Business

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.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

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 — the kind of system that assigns citizens a trustworthiness rating based on their behaviour.

Predictive policing based solely on profiling. Untargeted scraping of facial images to build recognition databases. Emotion inference in workplaces and schools. Biometric categorisation that infers sensitive attributes like race or sexual orientation. And real-time remote biometric identification in public spaces for law enforcement, with only narrow exceptions.

Maximum fines for breaches of Article 5 are EUR 35 million or 7% of worldwide annual turnover, whichever is higher.

High-Risk AI Systems

The Act’s main regulatory weight falls here. The clearest example — and the one most organisations will recognise — is hiring algorithms: AI used to screen CVs, rank candidates, or score applicants against a job profile. Under the Act, those systems are high-risk by default, with all the documentation, oversight, and conformity-assessment obligations that come with the classification.

High-risk systems are split into two groups. The first covers AI used as a safety component in products already regulated under existing EU sectoral law: medical devices, machinery, toys, lifts, and vehicles.

The second is the Annex III list — a defined set of standalone AI use cases in sensitive areas: biometric identification, critical infrastructure, education and vocational training, employment and worker management (where the hiring algorithm sits), access to essential private and public services like credit scoring and insurance, law enforcement, migration and border control, and administration of justice and democratic processes.

A 2023 study by appliedAI of 106 enterprise AI systems found that 18% were high-risk, 42% low-risk, and 40% were unclear, which gives a sense of how much classification work most organisations still have ahead of them.

Limited or Transparency Risk

This middle tier covers AI systems that are not high-risk but still warrant disclosure. Chatbots must tell users they are talking to a machine. Deepfakes and AI-generated content must be labelled. Emotion recognition and biometric categorisation systems must inform the people they observe. These are transparency obligations, not full compliance regimes.

Minimal or No Risk

Everything else. Spam filters, AI in video games, basic recommender systems, predictive text. The AI Act introduces no rules for AI deemed minimal or no risk. The vast majority of AI systems currently used in the EU fall into this category, though other laws — GDPR compliance, consumer protection, and sectoral rules — still apply.

 

Requirements for High-Risk AI Systems

Providers of high-risk AI systems carry the heaviest compliance burden under the Act. The requirements form an interlocking set of obligations covering the entire lifecycle of the system, from design through post-market monitoring.

Technical and Data Standards

Every high-risk system needs a risk management system that runs continuously throughout the system’s life — not a one-off pre-launch checklist. Training, validation, and testing data must meet quality criteria around relevance, representativeness, and accuracy. Bias must be identified and addressed, particularly where it could affect protected characteristics.

Technical documentation must be prepared before the system is placed on the market and kept up to date. Automatic logging must be built into the system to enable traceability of outputs.

Systems must reach an appropriate level of accuracy, robustness, and cybersecurity. After satisfying those requirements, the system goes through a conformity assessment, receives a CE mark, and is registered in an EU-wide database before it can be sold.

Obligations on Operators of High-Risk AI Systems

Deployers of high-risk systems must use the system in accordance with the provider’s instructions, ensure adequate human oversight by people with the necessary competence and authority, monitor the system for malfunctions or unexpected behaviour, keep automatic logs, and inform workers (and their representatives) before deploying a high-risk AI system in the workplace. Public-sector deployers and certain private operators in finance and insurance must also conduct a Fundamental Rights Impact Assessment before first use, assessing impact against the rights protected under the Charter of Fundamental Rights of the European Union.

Transparency Requirements

Across the high-risk regime, transparency runs as a thread. Deployers must be given enough information to understand how the system works, what its limitations are, and how to interpret its outputs. End users affected by automated decisions have the right to an explanation and to contest outcomes.

Insider Note: The Commission’s Digital Omnibus package, agreed politically on 7 May 2026, ties the application of high-risk obligations to the availability of harmonised technical standards. If those standards are not ready, the high-risk deadlines slip to late 2027 or August 2028, depending on the system type. Most organisations are still planning around August 2026; the practical date may now be later for many of them.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Rules for General-Purpose AI (GPAI) Models

GPAI models are regulated separately from AI systems. They sit upstream of most products that integrate them, so the Act treats them as a distinct layer with its own enforcement track inside the AI Office.

What Qualifies as a General-Purpose AI Model?

A GPAI model is one that shows significant generality, can competently perform a wide range of distinct tasks, and can be integrated into many downstream systems. Providers of GPAI models — defined as those trained above 10²³ floating-point operations — must meet transparency obligations and comply with EU copyright law.

A subset of these, GPAI models with systemic risk, face additional obligations. The current threshold is models trained with more than 10²⁵ FLOPs, which covers a small set of frontier models from a handful of providers.

Core Obligations for GPAI Providers

All GPAI providers face three core obligations. They must maintain detailed technical documentation of the model and share information with downstream developers integrating it. They must comply with EU copyright law, including respecting a clear opt-out for rightsholders who do not want their work used for training. And they must publish a detailed summary of the content used for training, using a template issued by the AI Office — the most novel of the three, since it forces transparency over training data in a way no other major jurisdiction currently requires.

Providers of systemic-risk GPAI models do all of the above and must additionally evaluate their models for systemic risks, conduct adversarial testing, assess and mitigate identified risks, report serious incidents to the AI Office without undue delay, and maintain an adequate level of cybersecurity. The GPAI rules became applicable on 2 August 2025, with full enforcement powers entering application on 2 August 2026.

Code of Practice for General-Purpose AI

To bridge the gap between the law coming into force and harmonised technical standards being published, the Commission worked with independent experts and over 1,000 stakeholders to develop the General-Purpose AI Code of Practice, finalised in July 2025. The Code has three chapters: Transparency, Copyright, and Safety and Security. The first two apply to all GPAI providers; the third only to systemic-risk providers.

Signing the Code is voluntary, but providers that do not sign must demonstrate alternative adequate means of compliance for the Commission to approve. The Safety and Security chapter has been drafted on the assumption that only about 5 to 15 providers worldwide will currently meet the systemic-risk threshold — a deliberately narrow group covering the makers of the most advanced frontier models.

EU AI Act Compliance Timeline and Application Dates

The Act applies in stages, and those stages have been moving. The May 2026 political agreement on the Digital Omnibus has reset several of the later deadlines. Here is the current picture:

1 August 2024 — The Act entered into force, twenty days after publication in the Official Journal. This is not a compliance deadline; it is the moment the law became part of the EU legal system.

2 February 2025 — Prohibitions under Article 5 became enforceable. AI literacy requirements under Article 4 also became live. These two chapters are already in full effect.

2 August 2025 — GPAI obligations became applicable. Governance structures, including the AI Office and its advisory bodies, became operational.

2 August 2026 — The headline general application date. High-risk AI obligations under Annex III, transparency requirements, and most operational provisions apply from this date — subject to the Omnibus caveat that where harmonised standards are not available, certain deadlines shift further.

Late 2027 / August 2028 — The revised outer limits for Omnibus-affected high-risk obligations where harmonised standards have not yet been published. For Annex I embedded systems (safety components in regulated products), the deadline now falls in August 2027.

2 December 2026 — The revised deadline for AI-generated content watermarking, pushed back from August 2026 under the Omnibus deal.

 

Governance and Enforcement

The AI Act is enforced through a hybrid model. The Commission, through the AI Office, holds direct enforcement powers over GPAI models. Member States enforce most of the rest through national market surveillance authorities.

The EU AI Office

The European AI Office sits inside the Commission’s Directorate-General for Communications Networks, Content and Technology (DG CNECT). It enforces the rules for general-purpose AI models EU-wide and supports national governance bodies. Its powers include conducting evaluations of GPAI models, requesting information and measures from model providers, and applying sanctions.

The Office works alongside three advisory bodies: the European Artificial Intelligence Board (Member State representatives), the Scientific Panel of Independent Experts, and the Advisory Forum (stakeholders from industry, civil society, and academia).

 

EU AI Act Fines and Penalties

The penalty structure has three tiers, set out in Article 99.

Prohibited practices (Article 5): Up to EUR 35 million or 7% of worldwide annual turnover, whichever is higher.

Most other breaches (high-risk obligations, GPAI rules, transparency requirements): Up to EUR 15 million or 3% of worldwide annual turnover, whichever is higher.

Providing incorrect or misleading information to authorities: Up to EUR 7.5 million or 1% of worldwide annual turnover, whichever is higher.

The “whichever is higher” formula means the percentage almost always wins for companies of any meaningful size. These penalties exceed GDPR’s maximum of EUR 20 million or 4% of turnover, making the AI Act the second-highest percentage-based penalty regime in EU digital regulation.

For SMEs and startups, the formula is inverted: the fine is the lower of the fixed amount or the percentage. A startup with EUR 2 million in revenue that breaches Article 5 faces a maximum fine of EUR 140,000 — not EUR 35 million. The reduction is real but not trivial; EUR 140,000 can still be existential for an early-stage company.

Important: The turnover used to calculate the percentage is group-level, not entity-level. A subsidiary deploying a prohibited AI system can expose the parent company’s full global revenue to the percentage calculation. This is the same trap that caught several companies under GDPR.

Reach SOC 2 Compliance in 6 Weeks or Less

Schedule Your Free SOC 2 Assessment Today

Supporting Compliance and Innovation

AI Regulatory Sandboxes

By 2 August 2026, every Member State must have at least one national AI regulatory sandbox operational. These are controlled environments where providers can develop, train, validate, and test AI systems under regulatory supervision before placing them on the market. Providers participating in sandboxes remain liable under applicable liability laws but are protected from administrative fines if they follow sandbox guidelines in good faith.

SMEs and startups get priority, free access to sandboxes. Documentation generated through sandbox participation can be used to demonstrate compliance with the Act, which materially reduces the cost of getting a high-risk product to market. The Omnibus deal also introduces an EU-level sandbox for cross-border or particularly complex cases.

AI Literacy Requirements Under Article 4

Article 4 has been live since 2 February 2025. It requires providers and deployers to ensure a sufficient level of AI literacy among their staff and others operating AI systems on their behalf. There is no mandated curriculum, no minimum number of hours, no certificate.

What organisations need is a documented program covering: general understanding of AI, the organisation’s role as provider or deployer, the specific risks of the AI systems in use, and role-appropriate depth (a compliance officer needs different training from a software engineer).

Insider Note: Standalone enforcement of Article 4 is unlikely to be a regulator’s first priority. The real risk is that absence of a documented AI literacy program becomes an aggravating factor in enforcement action for some other breach. Treat it as foundational, not optional.

How the Commission Is Simplifying EU AI Act Implementation

The Digital Omnibus, presented by the Commission on 19 November 2025 and politically agreed on 7 May 2026, is the most significant softening of the AI Act since it was adopted. As reported by the Financial Times, the package reflects sustained pressure from European industry — particularly German manufacturing — and broader anxiety in Brussels (sharpened by the Draghi report on European competitiveness) that the EU has been over-regulating itself out of the AI race.

Key changes include: conditioning the application of high-risk obligations on the availability of harmonised technical standards, with deadlines pushed to late 2027 or August 2028 where standards lag; narrowing the definition of “safety component” so that AI which merely assists users will not automatically be high-risk; extending simplified requirements to small mid-cap companies (SMCs), a new category sitting between SMEs and large enterprises; reinforcing the AI Office’s enforcement powers; expanding sandbox access including an EU-level sandbox; and pushing the AI-generated content watermarking deadline from August to 2 December 2026.

Small Business Guide to the EU AI Act

There is no general size exemption. A microenterprise developing a high-risk AI system has the same core obligations as a multinational. But the Act builds in specific support measures that meaningfully change the compliance calculus for smaller players.

These include the inverted fine calculations described above, free priority access to regulatory sandboxes, simplified technical documentation requirements, and the principle of proportionality applied to fees for third-party conformity assessment.

The Commission must regularly assess the cost of compliance for SMEs and consult them directly when developing standards and implementing acts. The Omnibus deal extends several of these concessions to the new SMC category as well.

For SMEs grappling with AI governance alongside broader data management obligations, frameworks like ISO/IEC 42001 — the international standard for AI management systems — can provide a useful structural backbone that satisfies both regulatory and certification goals simultaneously.

How Axipro Helps Clients Navigate the EU AI Act

EU AI Act compliance is not a single workstream. It sits at the intersection of technical auditing, data governance, legal interpretation, and product design — and it has to be maintained as the regulation itself keeps moving. Axipro’s AI Governance team supports clients across four areas.

AI Risk Categorisation.

We inventory the AI systems already in use across an organisation, map each one against the Act’s risk tiers, and flag the systems most likely to fall under the high-risk regime. For most clients, this is the single highest-value first step, since the appliedAI research found 40% of enterprise AI systems sit in a grey zone where the classification is unclear without expert review.

Governance Framework Design.

We help clients build the internal policies that the Act requires in practice: risk management procedures, data quality standards, transparency disclosures, AI literacy programs, and the documentation that ties them together. The goal is a framework that satisfies Article 4 today and scales to the high-risk requirements as they come into effect.

Conformity Assessments.

For clients with high-risk systems, we prepare the technical documentation, run pre-assessment audits, and coordinate with notified bodies on the mandatory certification process so that systems clear the CE-marking and EU database registration steps before they go to market.

Continuous Monitoring.

Compliance is not a launch event. Models retrain, use cases shift, and the regulation itself changes — the Omnibus deal being the clearest recent example. We provide continuous monitoring so that as AI systems and rules evolve, the compliance posture stays intact.

For organisations building, deploying, or selling AI in markets that touch the EU, the next twelve months are when planning becomes execution. Contact the Axipro Global Consulting Team to scope an AI governance review for your business.

What Is the EU AI Act in Simple Terms?

It is a single EU regulation that classifies AI systems by risk and applies different rules to each tier — from outright bans on the most harmful uses, to mandatory transparency and risk management for high-risk uses, with most everyday AI left alone.

Any software system meeting the Act’s definition of an AI system: one that operates with varying levels of autonomy, may exhibit adaptiveness after deployment, and infers from its inputs how to generate outputs such as predictions, content, recommendations, or decisions. Both narrow AI systems and general-purpose AI models are covered, with separate regimes for each.

Two groups: AI used as a safety component in products already regulated under EU sectoral law (medical devices, machinery, vehicles), and standalone AI in the Annex III use cases — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, and administration of justice.

The headline date is 2 August 2026, but several obligations are already live (prohibitions and AI literacy since February 2025; GPAI rules since August 2025), and several others now apply later (Annex I high-risk in August 2027; some Omnibus-affected obligations as late as August 2028).

Up to EUR 35 million or 7% of worldwide annual turnover for prohibited practices; EUR 15 million or 3% for most other breaches; EUR 7.5 million or 1% for misleading authorities. For SMEs, the lower of the fixed amount or the percentage applies rather than the higher.

Yes. If the output of an AI system is used in the EU, the provider is in scope regardless of where they are based. Non-EU providers of high-risk AI systems must appoint an authorised representative established in a Member State.

 

The same core obligations apply as for large companies, but with inverted fine calculations, free priority sandbox access, simplified documentation requirements, and proportional fees for third-party conformity assessment. The Omnibus extends several of these concessions to the new small mid-cap category.

A unit inside the European Commission that enforces GPAI obligations EU-wide, coordinates national authorities, runs the AI Pact and Service Desk, and develops most of the secondary legislation and guidance underpinning the Act.

The EU’s position is not that AI is inherently dangerous, but that certain uses of AI can cause serious harm to health, safety, and fundamental rights — and that existing law does not adequately cover those uses.

The risk-based approach is the EU’s attempt to regulate the harmful uses without smothering everything else. Whether the balance is right is now the central political question, and the May 2026 Omnibus deal is evidence that even the EU is not fully convinced it landed in the right place the first time.

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

Vanta Implementation Checklist

Most companies configure Vanta backwards. They connect integrations first, watch tests turn green, and only then ask which framework they are actually being audited against. By the time the auditor asks for the observation window start date, half the account needs to be rebuilt. The order you set things up in Vanta matters almost as much as what you set up, and getting it wrong costs weeks you do not have before a first audit. This checklist walks through the sequence that actually holds up under audit: the decisions to make before you touch the platform, the sequence of configuration inside it, and the final readiness checks before you hand the account to an auditor. Why a Vanta Implementation Checklist Matters Before Your First Audit Vanta is compliance automation software, not a compliance program. It monitors, syncs, and flags. It does not decide your scope, pick your framework, or tell you when your observation window can safely begin. Those calls are yours, and if you make them after connecting integrations rather than before, you end up rescoping mid-implementation, which resets test history and pushes your audit timeline back by weeks. A first-time implementation typically runs six to twelve weeks from account creation to a fully passing test suite, depending on how much of the underlying control environment already existed. Companies that skip the pre-implementation planning stage and jump straight into connecting AWS and Okta tend to discover, three weeks in, that half their integrations are out of scope, their policies do not match their actual operations, and their observation window needs to restart. Ready for your first audit? Get audit-ready with expert Vanta implementation support. Schedule Pre-Implementation: Foundational Decisions to Make First Define Your Target Framework (e.g., SOC 2, ISO 27001, HIPAA) Every downstream Vanta setting, from which integrations you connect to which policies you publish, depends on the framework you are pursuing. SOC 2 Type II evaluates your controls against the AICPA’s five Trust Services Criteria, security, availability, processing integrity, confidentiality, and privacy, with security as the only mandatory category. ISO 27001 asks you to build a full Information Security Management System (ISMS) under a structured set of clauses, backed by a broader set of technical, physical, and organizational controls in Annex A. HIPAA and PCI DSS bring their own control sets tied to specific data types, protected health information and cardholder data, respectively. If your customers are asking for a specific report, let that drive the decision rather than defaulting to whichever framework has the most templates in Vanta’s library. A fintech company with enterprise banking customers may need SOC 2 first and PCI DSS second. A healthcare SaaS vendor almost always needs HIPAA regardless of what else it pursues. Mapping frameworks to actual customer and contractual requirements before configuration saves you from scoping controls you will never use. Important: Choosing multiple frameworks at once is common, but sequencing them wrong creates duplicate work. Configure your primary framework fully, get through a full observation cycle if pursuing Type II, and add secondary frameworks once your evidence collection habits are established. Vanta will map shared controls across frameworks automatically, but only once both are active in the account. Set Your Audit Timeline and Observation Window If you are pursuing SOC 2 Type I, there is no observation window. The audit evaluates whether your controls are designed correctly as of a single point in time, and you can move to audit as soon as your tests pass. SOC 2 Type II is different: the observation window, also called the audit window or monitoring period, is the span during which the auditor samples evidence to confirm your controls actually operated, not just that they existed on paper. For a first Type II audit, a three to six month window is standard. Mature organizations settling into an annual cadence typically move to a full twelve-month window once they have proven consistent operation. Do not start the observation window until you are confident your controls are actually running as designed. Auditors can sample any event from the first day of the window forward, and a control failure in week two of a six-month window is just as damaging to your report as one in week twenty. This is the single most common timeline mistake first-time customers make in Vanta: they start the clock the day they finish connecting integrations, before policies are published, before HR sync is confirmed, and before access reviews have actually happened once. Identify Internal Owners and Stakeholders Every control needs a named owner inside Vanta, not a department. “Engineering” is not a control owner. The engineering manager who reviews production access quarterly is. Before you start configuring, map out who owns identity and access management, who owns vendor risk, who owns HR onboarding and offboarding, and who owns policy publication and employee acknowledgment. If your organization is small enough that one person wears several of these hats, that is fine, but it needs to be explicit in the tool, because Vanta’s task assignments and reminder emails route based on these ownership fields. Choose Your Auditor Before You Configure Vanta Auditor selection affects configuration choices that are expensive to reverse. Different CPA firms and ISO certification bodies have different tolerances for exceptions, different expectations around evidence formatting, and different preferences on how granular your control mapping should be. Get your auditor engaged, or at minimum shortlisted, before you finalize your framework scope and observation window in Vanta. Some firms will do a pre-audit readiness call that surfaces scoping issues Vanta’s automated checks will not catch, like whether a particular subprocessor needs to be in scope. Step 1: Configure Company Settings in Vanta Add Company Details and Business Information Start with the basics: legal entity name, headquarters address, description of the service you provide, and the systems that process customer data. This becomes the backbone of your system description, the narrative document that accompanies your SOC 2 report and explains what your company does and how the in-scope systems support

ISO 27001 Business Continuity Plan

Two controls decide whether your ISO 27001 business continuity plan survives an audit: Annex A 5.29 and Annex A 5.30. One keeps your security controls working while everything else is failing. The other gets your systems back online before the damage becomes permanent. Plenty of teams write a continuity policy that satisfies neither in the way a certification auditor expects, and they discover the gap during the Stage 2 audit, when it is expensive to fix. This article covers what ISO 27001:2022 actually requires for business continuity, the components an auditor will ask to see, the step-by-step build, and the mistakes that turn a continuity plan into a non-conformity. What Is an ISO 27001 Business Continuity Plan? An ISO 27001 business continuity plan is the documented set of procedures that keeps information security effective and critical ICT services available during a disruption. It is not a generic “keep the lights on” binder. Under ISO 27001, the plan protects the confidentiality, integrity, and availability of information when normal operations break down: a ransomware event, a cloud outage, a data center failure, or a supplier collapse. The plan lives inside your Information Security Management System (ISMS). It draws on your risk assessment, your asset register, and your Business Impact Analysis (BIA), and it feeds your disaster recovery procedures. Scope is the part people get wrong. ISO 27001 cares about the information security aspects of continuity, not every operational hiccup a full business continuity program might cover.   Why You Need a Business Continuity Plan for ISO 27001 Compliance Downtime is expensive, and the bill arrives fast. For most organizations, the question is not whether a disruption will happen, but how quickly they recover when it does. There is also a hard compliance reason. You cannot certify to ISO 27001 while ignoring continuity. The standard requires you to maintain information security during disruption and to keep ICT able to support recovery, and an auditor will ask for the evidence. A continuity plan is where availability stops being a promise and becomes a tested capability. Let Axipro help you build a business continuity plan that’s practical, compliant, and audit-ready. Strengthen Your Business Continuity Strategy Schedule A Consultation ISO 27001 Requirements Related to Business Continuity Planning ISO/IEC 27001:2022 carries 93 Annex A controls across four categories: organizational, people, physical, and technological. Continuity sits in the organizational set, and two controls do the heavy lifting, supported by two more on the technical side. Annex A 5.29 – Information Security During Disruption A.5.29 requires you to maintain information security at an appropriate level when a disruption hits. The point is that security controls have a habit of degrading under pressure. People disable multi-factor authentication to “speed things up,” logging stops on a failover system, or access controls loosen while everyone scrambles. A.5.29 says the confidentiality and integrity of your information must be maintained even while availability is under threat. It is classed as both a preventive and a corrective control, meaning it should reduce the chance of an incident and also help resolve one already underway. Annex A 5.30 – ICT Readiness for Business Continuity A.5.30 is the technical engine. It requires that your ICT readiness is planned, implemented, maintained, and tested against business continuity objectives and ICT continuity requirements. In plain terms, your servers, networks, applications, and cloud services need a defined recovery path, each with a Recovery Time Objective (RTO) and Recovery Point Objective (RPO), and you need to prove the path works. This control is entirely new in the 2022 revision. It has no precedent in ISO 27001:2013, which is exactly why teams migrating from the older version so often have a gap here. Important: A.5.30 did not exist in ISO 27001:2013. If your continuity documentation was written against the old Annex A 17 cluster and never updated, you are missing a control the auditor will specifically test. Treat ICT readiness as a fresh requirement, not a relabel. Two technological controls back these up. Annex A 8.13 (Information Backup) requires backups to be taken and tested in line with an agreed policy, and Annex A 8.14 (Redundancy of Information Processing Facilities) covers the failover and redundancy that let critical systems keep running when a component dies. Relationship Between ISO 27001 and ISO 22301 This is where confusion is common. ISO 27001 requires the information security aspects of continuity. ISO 22301 is the dedicated standard for a full Business Continuity Management System (BCMS), covering people, facilities, supply chain, and operations far beyond information security. An ISO 27001 certificate does not certify your wider continuity program. The good news: both standards share the Annex SL high-level structure, so risk assessment, internal audit, management review, and document control carry across. Teams that already run ISO 27001 can layer ISO 22301 on top with far less effort than starting from scratch. Key Components of an ISO 27001 Business Continuity Plan Business Impact Analysis (BIA) The BIA is the foundation. It identifies your critical business processes, the ICT systems they depend on, and the cost of losing each one over time. It is where your recovery objectives come from, not from a vendor datasheet. A BIA also sets the Maximum Tolerable Period of Disruption (MTPD): the point beyond which an activity’s failure causes unacceptable damage. Risk and Disruption Scenario Assessment Your risk assessment identifies what could cause a disruption and how likely it is, feeding the Risk Treatment Plan and the Statement of Applicability (SoA) that records which controls apply. Continuity planning then runs concrete scenarios: ransomware, a regional outage, a key supplier failure, the loss of a data center. Response and Recovery Strategies For each critical system, you define how you will respond and recover: failover to a secondary site, restore from backup, or switch to a manual workaround. This links incident response to crisis management, the executive-level decision-making that kicks in when an incident escalates beyond a routine fix. Roles and Responsibilities Name real people, not departments. “IT will handle it” is the single most common

When researchers found that Microsoft 365 Copilot could be tricked into leaking corporate data from a single email, the flaw got a clean public identifier: CVE-2025-32711, severity 9.3. When a bug hunter coaxed ChatGPT into producing valid Windows product keys by framing the request as a guessing game, it got nothing.  Both were prompt injections. Only one is trackable. That Vulnerability Tracking Gap in AI Security, and what it costs defenders, is the subject of this article. What Is a CVE and Why Does It Matter for Software Security? A CVE (Common Vulnerabilities and Exposures) is a unique public identifier for a specific software flaw. It gives the whole industry one name for one bug, so a researcher in Berlin and an analyst in Bahrain know they mean the same thing. The Role of MITRE’s CVE Program in Traditional Vulnerability Management The CVE program is run by the MITRE Corporation, a US nonprofit. Since 1999 it has assigned hundreds of thousands of IDs, each tied to a discrete, reproducible defect in a defined product and version. A CVE is the connective tissue of coordinated disclosure: a researcher reports the flaw, the vendor patches it, the ID is published, and defenders map it to their own assets. Without that shared label, the same bug ends up with three names and no clear owner. The National Vulnerability Database (NVD) and CVSS Scoring The National Vulnerability Database, maintained by NIST, enriches each CVE with a CVSS (Common Vulnerability Scoring System) score from 0 to 10. That lets teams triage: a 9.3 jumps the queue, a 4.0 waits. Why Prompt Injection Breaks the Traditional CVE Model The CVE model assumes a bug lives in code, sits in a version, and can be fixed. Prompt injection violates all three. Prompt Injection as a Class of Attack, Not a Discrete Bug Prompt injection smuggles instructions into the data an LLM reads, so the model follows the attacker rather than the user. OWASP ranks it as LLM01, the top entry in its 2025 Top 10 for LLM Applications. It is a property of how language models work, not one line of faulty code, so you cannot file a CVE against it. A SQL injection either works or it does not. A prompt injection might succeed nine times in ten, fail on the eleventh, then stop working after a silent model update, which makes the “reproducible” part of reporting genuinely hard. Model Versioning vs. Software Versioning Software has clean version numbers. A weight update to a hosted model can ship silently, with no version a researcher can cite. Two calls to “gpt-4o” a week apart may not behave the same way, and there is no changelog to point at. Why “Patching” an LLM Differs From Patching Code Patching code closes a specific hole. A developer rewrites the faulty line, ships the diff, and the exploit path is gone for good. That clean, binary, auditable loop is the entire premise on which the CVE system rests. “Patching” a model offers none of it. There is no single line to fix, because the behavior the attacker abused is the same behavior that makes the model useful: it reads text and follows instructions. A vendor’s only levers, retraining, hardening the system prompt, or wrapping the model in input and output guardrails, all lower the odds of a successful attack rather than removing the possibility. The fix reduces the success rate from 80 percent to 5 percent and marks it as remediated. The hole is narrower, not closed. The recent record shows how thin that margin is. EchoLeak got past Microsoft’s dedicated cross-prompt-injection classifier by hiding its exfiltration channel in reference-style Markdown that the filter did not recognize, and the AgentFlayer exploit slipped through OpenAI’s URL safety check by routing stolen data through trusted Azure Blob Storage links. Each guardrail worked against the obvious version of the attack and fell to a rephrasing. There is a tuning tax on top of that: crank the filters too tight and the model starts refusing legitimate work, so vendors settle for a balance point rather than elimination.  The practical takeaway is to treat “we’ve addressed this” as risk reduction, not closure. SOC 2, ISO 27001 and HIPAA done for you. Fixed fee, 100% audit pass rate. Audit-ready in 6 weeks. Not 6 months. Schedule A Free ASSESSMENT The Current State of AI Vulnerability Tracking Several frameworks exist. None is a true registry of individual, citable prompt injection vulnerabilities. OWASP LLM Top 10 and the LLM01 Classification The OWASP GenAI Security Project’s LLM01:2025 entry is the most cited reference point. It is a category, not a catalog: it does not enumerate specific incidents with IDs. MITRE ATLAS for Adversarial AI Threats MITRE ATLAS is an ATT&CK-style knowledge base of adversarial tactics against AI systems, documenting 16 tactics and more than 80 techniques with real-world case studies as of late 2025. It maps how attacks work, but is not a per-vulnerability ledger with scores. AVID (AI Vulnerability Database) and Its Limitations AVID, run by a nonprofit, is the closest thing to a dedicated AI vulnerability database, cataloging failure modes with reproducible evidence. But it leans on community submissions, skews toward bias and broader failure modes, and notes that the definition of an “AI vulnerability” is itself still a working one. Vendor-Specific Disclosures vs. Industry-Wide Registries Disclosure happens vendor by vendor. OpenAI patched the Windows-key jailbreak server-side; Microsoft fixed EchoLeak and issued a CVE. There is no common venue where these land side by side.   The Consequences of No Shared Threat Registry for Prompt Injection Fragmented Disclosure Across AI Vendors Each lab discloses on its own terms, on its own blog, if at all. A defender protecting a multi-model stack has to monitor a dozen channels and hope nothing slips by. Duplicate Discovery and Wasted Research Effort Researchers rediscover the same attack repeatedly. The guessing-game jailbreak, the “dead grandma” trick, and other framing attacks are variations on one theme nobody numbered. No Standardized Severity Scoring for