For twelve months, Brussels asked nicely. As of August 2, 2026, it doesn't have to anymore.

If your compliance team spent the summer congratulating itself on a "quiet" AI Act rollout, it's time for an uncomfortable conversation. The obligations for general-purpose AI (GPAI) providers didn't just appear this month — they've technically applied since August 2, 2025. What changed on August 2, 2026 is that the European Commission's AI Office can finally do something about non-compliance: audit models, demand corrective action, restrict market access, and issue fines of up to €15 million or 3% of global annual turnover, whichever is higher.

That distinction — obligation versus enforcement — is exactly what most European boardrooms missed while they were busy tracking the wrong deadline.

The Grace Period Is Over

When the EU AI Act entered into force in August 2024, it built in a deliberate one-year runway for GPAI providers. Chapter V obligations — training-data summaries, copyright compliance, technical documentation, and systemic-risk management for the most powerful models — became legally binding on August 2, 2025. But the AI Office needed time to build its own supervisory machinery before it could act on any of it.

That runway has now ended. From August 2, 2026, the Commission can request technical documentation, run model evaluations, order risk-mitigation measures, and pull non-compliant GPAI models from the EU market. Models placed on the market before August 2, 2025 get a slightly longer runway — they must be fully compliant by August 2, 2027 — but every model launched after that date has already been operating on borrowed time.

Signing the voluntary GPAI Code of Practice helps, but it isn't a shield. Regulators have indicated that Code signatories will have their good-faith commitments weighed when calculating penalties, yet enforcement applies "signatures or not." A partial signature — committing to some chapters of the Code while skipping others — is a detail worth scrutinising in any vendor's compliance claims, not taking at face value.

Article 50 Is the Deadline Everyone Underestimated

While GPAI enforcement grabbed the headlines, Article 50 transparency obligations quietly went live the same day — and this one reaches far beyond model providers. Any organisation deploying a chatbot or conversational AI system must now disclose, clearly and at the start of the interaction, that the user is talking to an AI. AI-generated or manipulated content, including deepfakes, requires machine-readable labelling. The same €15 million / 3% turnover penalty ceiling applies here too.

This is the requirement that catches European businesses off guard, because it isn't aimed at Silicon Valley labs — it's aimed at every customer service bot, marketing assistant, and generative content workflow running inside ordinary companies across Germany, France, Ireland, and the Netherlands. If your team's AI inventory doesn't already flag which systems talk directly to customers, that's the gap to close first.

Don't Confuse This With the Digital Omnibus Delay

Here's where a lot of internal risk registers went wrong this year. The Digital Omnibus, finalised by the European Parliament on June 16, 2026 and given final Council sign-off on June 29, 2026, pushed high-risk AI system obligations under Annex III from August 2026 out to December 2, 2027. That's a genuine, significant delay — but it applies to a completely different track of the Act.

It does nothing to soften GPAI enforcement powers or Article 50 disclosure duties. If your compliance roadmap assumed the Omnibus bought extra breathing room on chatbot transparency, it was working from an outdated script. Two separate clocks, two separate consequences — and conflating them is precisely how well-resourced teams end up caught flat-footed on the deadline that actually mattered.

What Your Team Likely Missed

1. Treating "GPAI obligations" and "GPAI enforcement" as the same milestone. They weren't. The rules existed for a year with no teeth; now they have teeth.
2. Assuming the Omnibus delay covered everything. It covered high-risk systems only — not GPAI supervision, not Article 50.
3. Ignoring deployer-side exposure. Being a "deployer" rather than a "provider" doesn't create a safe harbour under Article 50. Disclosure duties reach anyone whose customers interact with AI.
4. No live AI inventory. Regulators, national market surveillance authorities, and even downstream providers can now trigger scrutiny. Without a current inventory of AI systems, owners, and purposes, an inquiry response starts from zero.
5. Reading "Code of Practice signatory" as full compliance. It's a mitigating factor in penalty calculation, not an exemption.

What To Do Before the Next Inquiry Lands

European organisations — not just AI labs — now sit inside an active enforcement regime. Practical next steps look less like a policy rewrite and more like an operational audit: build (or refresh) a complete AI systems inventory, classify which tools are GPAI-adjacent versus deployer-only, confirm chatbot disclosure is actually implemented at the interaction level, and stress-test whether your documentation would survive a Commission request this quarter.

The Bottom Line

August 2, 2026 didn't introduce new rules. It introduced consequences. For European businesses running customer-facing AI, procuring GPAI models, or quietly letting departments adopt generative tools without central oversight, the honest question isn't "are we compliant on paper" — it's "could we produce evidence of compliance inside a week if the AI Office asked." If the answer is uncertain, the runway to find out just got a great deal shorter.

Three years ago, a SOC 2 report was the single piece of paper that opened enterprise doors. No SOC 2, no procurement shortlist, no matter how good your product was. In 2026, European AI vendors are watching a new document take that seat at the table: ISO/IEC 42001, the world's first certifiable standard for an Artificial Intelligence Management System (AIMS).

If you sell AI-powered software to European enterprises, banks, or public bodies, this isn't a distant compliance trend. It's already showing up in RFPs, vendor security questionnaires, and boardroom risk registers. Here's why ISO 42001 is following SOC 2's exact playbook, and what you need to do about it this year.

Why SOC 2 Stopped Being Enough

SOC 2 was built to answer one question: can this vendor be trusted with our data? It says nothing about whether an algorithm is biased, whether a model's decisions can be explained, or whether an organisation has a documented process for retraining, monitoring, and decommissioning AI systems. As generative AI and automated decision-making moved into lending, hiring, healthcare, and customer service, European buyers started asking questions SOC 2 was never designed to answer.

Enter ISO 42001: The AIMS Standard

Published by ISO and IEC in December 2023, ISO/IEC 42001 gives organisations a Plan-Do-Check-Act framework, modelled on the same structure as ISO 27001, but built specifically for how AI is developed, procured, deployed, and monitored. It covers AI risk assessment, data governance, human oversight, transparency, supplier AI risk, and lifecycle monitoring precisely the gaps SOC 2 leaves open.

Certification is voluntary, but "voluntary" is doing less work than it used to. Enterprise procurement teams across Europe are folding ISO 42001 into vendor due diligence the same way they folded in SOC 2 a decade ago not because a regulator demands it, but because it's the fastest way to prove AI governance is real rather than a slide deck.

The EU AI Act Is the Real Accelerant

The EU AI Act's obligations for high-risk AI systems became enforceable on 2 August 2026, covering risk management, data governance, technical documentation, human oversight, and accuracy and robustness requirements under Articles 9–15. ISO 42001 doesn't automatically satisfy the Act as of 2026 it is not yet a harmonised standard published in the Official Journal of the EU, and CEN-CENELEC is still finalising a dedicated European deliverable (prEN 18286) aligned with it. But regulators and auditors consistently point to ISO 42001 as the strongest available evidence of structured AI governance while that harmonisation work continues, which is exactly why European vendors are moving now rather than waiting.

For a practical breakdown of what auditors expect before enforcement dates land, VistaInfosec's EU AI Act compliance checklist is worth a read it lays out exactly which evidence buyers and regulators will ask for first.

What This Means for European AI Vendors, Specifically

• Sales cycles are shifting left. Security questionnaires now include ISO 42001 status alongside SOC 2 and ISO 27001, often before a demo is even scheduled.
• ISO 27001 holders have a head start. Because both standards share the same management-system backbone, organisations with an existing ISMS typically cut ISO 42001 implementation effort by roughly a third to a half.
• Timelines are compressing. Certification generally runs four to twelve months from gap assessment to certificate, but firms with ISO 27001 already in place can often get there in three to four months.
• Cost is real but manageable. First-year costs for a mid-size organisation typically fall in the €80,000–€140,000 range, covering gap assessment, documentation, internal audit, and the external certification audit.

ISO 42001 vs SOC 2: How They Actually Compare

Building an AIMS Doesn't Mean Starting from Zero

The organisations moving fastest aren't building AI governance from scratch they're extending what they already have. If you're certified against ISO 27001, your risk register, internal audit programme, and management review process already exist; ISO 42001 adds an AI-specific layer on top rather than replacing anything. VistaInfosec's guide on ISO 42001 certification timeline and cost breaks down exactly how much faster this path is, stage by stage.

"ISO 42001 is becoming the new SOC 2 the certificate buyers ask for before they sign."

Getting Started: A Practical Sequence

• Run a gap assessment against ISO/IEC 42001:2023, reusing your ISO 27001 scope and risk process wherever possible.
• Build (or extend) your AI risk register and complete impact assessments for each AI system in production.
• Formalise human oversight, data governance, and supplier AI assurance controls.
• Run an internal audit and management review before inviting an accredited certification body for Stage 1.
• Automate evidence collection so documentation doesn't lag behind what your engineering team ships.

Vendors that treat this as a checkbox exercise tend to stall at Stage 1. Vendors that treat it as an extension of existing security maturity the same instinct that made SOC 2 straightforward for mature SaaS companies move through certification in a fraction of the time.

The Bottom Line

ISO 42001 is not a legal mandate, and it won't single-handedly make you EU AI Act compliant. But it is rapidly becoming the commercial signal European enterprises use to separate serious AI vendors from the rest exactly the role SOC 2 played for cloud software a decade ago. Vendors who certify early won't just tick a compliance box; they'll shorten sales cycles, win procurement conversations before competitors even reach the table, and walk into EU AI Act enforcement with governance already in place.

If your engineering team has been treating the EU AI Act as "next year's problem," it's time for a hard reset. The Act (Regulation 2024/1689) is not a future proposal anymore it is live law, and its most demanding milestone yet arrives on 2 August 2026, when obligations for high-risk AI systems and Article 50 transparency duties become fully enforceable across the EU. For CTOs, engineering leads, and compliance-adjacent developers from Berlin to Bucharest, this is the deadline that turns "we should probably look into this" into "our system is non-compliant and the fine is up to €35 million or 7% of global turnover."

This isn't a legal briefing. It's a practical, developer-facing look at what actually needs to change in your codebase, your pipelines, and your documentation before the milestone hits.

Where things actually stand right now

A quick reality check, because there's a lot of noise online: prohibited AI practices and AI literacy obligations have been in force since February 2025. GPAI (general-purpose AI) obligations and the designation of national authorities followed in August 2025. The big one full compliance for high-risk AI systems under Annex III (biometrics, critical infrastructure, education, employment, law enforcement, migration, justice, and democratic processes) activates on 2 August 2026.

Yes, the European Commission's November 2025 Digital Omnibus package proposed easing some administrative burdens, and parts of it were provisionally agreed in mid-2026. But unless final technical standards are approved in time, the backstop compliance date for high-risk systems remains 2 December 2027 at the latest, and the August 2026 date for GPAI penalty powers and transparency rules stays firmly on the calendar. In other words: don't build your roadmap on the hope of a delay. Build it on the assumption that enforcement is real, and soon.

What your dev team must actually change

1. Stop treating "the model" as the whole system

Auditors and regulators evaluate the AI system data pipeline, model, interface, monitoring, and human oversight controls together. If your risk classification only covers the model weights, you're already behind. Map every AI-touching component your team owns and classify each one against the Act's four risk tiers.

2. Build (and keep) a technical documentation trail

Annex IV technical documentation isn't a one-off PDF. It needs to be a living artifact: training data provenance, evaluation metrics, known limitations, and change logs updated every time a model is retrained or fine-tuned. If your CI/CD pipeline doesn't already generate this documentation automatically, this is the milestone to fix that.

3. Wire in logging and human oversight, not just uptime monitoring

High-risk systems require automatic event logging sufficient to trace decisions after the fact, plus a genuine human-in-the-loop override not a rubber-stamp approval button. Engineering teams should treat this the same way they'd treat audit logging for financial transactions: immutable, timestamped, and queryable.

4. Implement Article 50 transparency by design

From 2 August 2026, chatbots must disclose they're AI, emotion-recognition systems must notify users, and synthetic or manipulated content (including deepfakes) needs machine-readable watermarking. If your frontend team hasn't already added disclosure UI and your generation pipeline hasn't added content provenance metadata, this is now a blocking ticket, not a backlog item.

5. Treat GDPR and the AI Act as one compliance surface, not two

Every high-risk AI system that processes personal data needs both an AI-specific risk assessment and, in most cases, a Data Protection Impact Assessment. Running these as separate workstreams doubles the effort and doubles the chance of gaps. Teams that have already mapped their GDPR compliance obligations for AI data processing are finding it far easier to extend that same governance model to AI Act requirements, rather than starting from scratch.

6. Register before you deploy

High-risk AI systems must be registered in the EU database before being placed on the market or put into service. This is a deployment gate, not a paperwork afterthought build it into your release checklist alongside security sign-off.

A practical control checklist

For teams that want a structured starting point rather than reverse-engineering the regulation article by article, VISTA InfoSec has published a detailed EU AI Act readiness guide covering the 10 controls every organisation should implement in 2026, mapped against the specific deadlines each control gates. It's a useful cross-check against your own implementation plan, especially where high-risk and transparency obligations now sit on different compliance clocks.

Why "later" is no longer a strategy

The Brussels Effect means this isn't just a European problem companies outside the EU that touch EU users or EU markets are restructuring their AI governance to match, because Japan, Canada, Brazil, and South Korea are already modelling their own AI laws on this framework. If your product ships anywhere near the EU, your dev team's AI governance decisions this quarter will likely define your architecture for years.

The organisations that are ahead right now didn't wait for a final legal interpretation of every clause. They ran a gap assessment, fixed what a tested control revealed rather than what a checklist implied, and moved. If your team needs an outside, evidence-based view of where your AI estate actually stands rather than another internal checklist nobody has time to finish it's worth getting a second set of eyes before the August milestone, not after. VISTA InfoSec's compliance and AI governance advisory services run exactly this kind of practitioner-led gap assessment.

The bottom line

2 August 2026 doesn't mark the end of the EU AI Act's rollout Annex X systems in justice and migration have until December 2030, and legacy public-sector systems get grandfathering until the same year. But for most product and engineering teams building or deploying AI in or for the European market, this is the milestone that turns "AI governance" from a slide in a board deck into code, logs, and documentation that a regulator can actually inspect. Start there.

What Actually Changes on September 11, 2026

The CRA (Regulation (EU) 2024/2847) entered into force on December 10, 2024. From September 11, 2026, manufacturers of "products with digital elements" must report to ENISA and their national CSIRT whenever they become aware of:

• An actively exploited vulnerability in their product
• A severe incident affecting the security of the product

The timeline is unforgiving and staged:

1. Early warning within 24 hours of becoming aware — a bare-bones notification, not a full report
2. Full notification within 72 hours — more detail on nature, severity, and indicators of compromise
3. Final report within 14 days after a corrective measure is available (for exploited vulnerabilities), or within one month for severe incidents

Reporting goes through the CRA Single Reporting Platform, and manufacturers report only once, with the notification routed to the relevant authorities. Note that vulnerability patching and remediation obligations don't formally kick in until December 11, 2027 but you can't report what you haven't detected, and you can't detect what you haven't inventoried. That's why the real work starts now.

Why Dev Teams, Not Just Legal, Own This

Compliance teams can write policy, but Article 14 is fundamentally an engineering problem. Reporting "actively exploited vulnerabilities" within 24 hours requires:

• Real-time visibility into every open-source and third-party component in production
• A working Software Bill of Materials (SBOM) generation pipeline
• Automated vulnerability monitoring tied to exploit intelligence feeds, not just CVE publication
• An internal escalation path that can move from "we detected this" to "regulator notified" in under a day

None of that exists overnight. If your team is only starting SBOM generation now, you're behind — most compliance practitioners recommend having automated SBOM and vulnerability-tracking pipelines operational well before the reporting clock starts, since accurate component-level visibility is the prerequisite for the 24-hour trigger, not a nice-to-have.

The Pre-September Checklist

Every product team building on top of ChatGPT, Claude, Gemini, or an open-source model eventually asks the same question: does GDPR even apply here? The honest answer is yes almost always. The moment your application sends a user's name, email, support query, or behavioral data into a large language model (LLM), you have created a new personal data processing activity, and GDPR's obligations follow that data wherever it goes, including into a model's context window or, in some cases, its training pipeline.

In 2026, this is no longer a theoretical debate. Regulators have moved from general warnings to detailed, model-specific guidance, and enforcement against AI-powered products is accelerating. If your app uses an LLM, here is what actually changes under GDPR and what you need to do about it.

Why LLM-Powered Apps Are Still "Controllers" and "Processors"

Wrapping a chatbot around GPT-4o or Claude doesn't remove you from the GDPR chain of accountability it adds a link to it. If your app decides why and how user data is processed before it reaches the model, you remain the data controller, and the LLM provider is typically your processor under Article 28. That means you still need a compliant Data Processing Agreement with the model vendor, exactly as you would with any cloud host or SaaS subcontractor. Businesses new to this obligation often benefit from reviewing VistaInfosec's breakdown of core GDPR requirements before mapping how an LLM integration fits into their existing compliance structure.

What the Regulators Actually Said in 2026

The European Data Protection Board's foundational opinion on AI models (adopted in late 2024) remains the reference point regulators use today, and it has since been reinforced by newer guidance. Two takeaways matter most for app builders:

• An LLM is rarely "anonymous" in the legal sense. The EDPB has confirmed that a model can only be treated as anonymous if it is very unlikely that personal data can be extracted from it directly or through queries a high bar that few commercial LLMs meet on their own. If personal data can be inferred or regurgitated, GDPR applies to the model itself, not just to your app's data flows.

• Legitimate interest can justify AI processing but only after a documented balancing test. The EDPB has laid out a three-step test: identify the legitimate interest, prove the processing is necessary, and show it doesn't override user rights. Skipping this documentation is one of the fastest ways to fail a GDPR audit.

Separately, the EDPB's 2026–2027 work programme confirms that dedicated guidelines on generative AI and data scraping are still being finalized, and the EDPS updated its own generative AI guidance in 2026 to address hallucination risks, purpose limitation, and lifecycle risk monitoring for AI deployments inside organizations. In short: the guidance is maturing fast, and "we didn't know" is no longer a credible defense.

The Practical Compliance Gaps LLM Apps Create

1. Purpose limitation gets harder. LLMs are open-ended by design, but GDPR requires you to define a specific purpose before processing begins. You need to document, in advance, exactly what the LLM is being used for in your app support automation, summarization, personalization rather than treating it as a general-purpose data sink.

2. Data minimization is easy to violate by accident. Developers routinely paste entire user records or support tickets into a prompt when only one field was needed. Strip identifiers, redact free-text fields, and pass the model only what the task requires.

3. Data subject rights don't disappear. Access, rectification, and erasure requests still apply, even when data has passed through a model. If a user asks you to delete their data, you must be able to show whether that data was used only in a stateless inference call (relatively simple to resolve) or whether it was retained for fine-tuning (which requires unlearning techniques, opt-outs, or retraining all far harder to deliver, and something the EDPB explicitly flags as a mitigation measure developers should have ready).

4. Vendor due diligence becomes non-negotiable. Before connecting to any third-party LLM API, confirm where the vendor processes data, whether it trains on your inputs by default, and what safeguards exist for cross-border transfers. This due diligence overlaps closely with a standard GDPR compliance audit process, so many teams fold their AI vendor review directly into their existing audit cycle rather than running it separately.

Do You Need a DPIA for Your LLM Feature?

In most cases, yes. Using AI to process personal data at scale is one of the scenarios regulators expect a Data Protection Impact Assessment for, particularly where profiling, automated decision-making, or sensitive categories of data are involved. The DPIA should cover the specific LLM integration not just your app in general and should document your legal basis, retention period, and any output-filtering safeguards used to prevent the model from regurgitating personal data in its responses.

Regulatory guidance is consistent on one point: claiming an AI model is "safe" or "anonymous" without evidence is a compliance risk in itself. Documentation DPIAs, model cards, and audit trails is what regulators actually ask for during an investigation.

A Practical Compliance Checklist for LLM-Powered Apps

• Map every place personal data flows into a prompt, embedding, or fine-tuning dataset.

• Sign a GDPR-compliant DPA with every LLM vendor before go-live.

• Run a DPIA specific to the AI feature, not a generic app-level assessment.

• Apply data minimization and redaction before data reaches the model.

• Build a process to honor erasure and access requests across both your database and any vendor-side logs or fine-tuning sets.

• Re-review your privacy notice so it discloses AI processing in plain language.

If you're unsure where your organization currently stands, VistaInfosec's complete GDPR compliance guide is a useful starting point for mapping these obligations against your existing data protection program, and their 2026 GDPR compliance cost breakdown is worth reviewing when budgeting for AI-specific impact assessments, which regulators increasingly expect on top of standard DPIAs.

The Bottom Line

Generative AI doesn't get a carve-out from GDPR it gets extra scrutiny. Every LLM integration is a new personal data processing activity that needs a legal basis, a documented risk assessment, and a plan for honoring user rights. Teams that treat AI features as "just another API call" are the ones most likely to fail an audit or face a regulator's questions after an incident. Teams that build privacy safeguards into the AI feature from day one the way they would for any other processor relationship are the ones that scale confidently in 2026 and beyond.

For organizations that want expert support mapping AI-specific risks onto their GDPR program, VistaInfosec's GDPR compliance consulting and audit services offer hands-on help with DPIAs, RoPA documentation, and vendor risk reviews tailored to AI-powered products.

AI coding assistants like GitHub Copilot, Claude, and Cursor have become standard tools in modern software teams. They write boilerplate, suggest functions, and even generate entire modules in seconds. But when that code touches payment processing, cardholder data, or transaction systems, a new question arises: does AI-generated code meet PCI DSS (Payment Card Industry Data Security Standard) requirements? In 2026, this question is no longer theoretical — auditors are actively scrutinizing how AI tools are used across the software development lifecycle (SDLC). For organizations navigating payment security compliance, working with experts like Vista InfoSec can provide the structured guidance needed to stay ahead of these requirements.

Why PCI DSS Cares About AI-Generated Code

PCI DSS v4.0, now fully enforced, places heavy emphasis on secure software development practices under Requirement 6. This includes secure coding training, code review processes, and vulnerability management — all of which assume a human-driven, auditable development process. AI-generated code introduces gaps in that assumption: who reviewed it, what training data shaped it, and can its security posture be verified the same way as human-written code? For the authoritative source on these requirements, developers should always refer to the official PCI Security Standards Council document library.

Top Risks of Using AI-Generated Code in Payment Systems

1. Hidden Vulnerabilities

Large language models are trained on vast public codebases that include insecure patterns. Without careful review, AI tools can reproduce SQL injection flaws, hardcoded secrets, weak cryptographic implementations, or improper input validation — all of which directly violate PCI DSS Requirements 6.2 and 6.3. A thorough PCI DSS compliance assessment can help identify these vulnerabilities before they surface in an audit.

2. Lack of Traceability

PCI DSS auditors expect a clear chain of custody for code changes. AI-assisted commits can blur accountability if developers simply accept suggestions without documenting review and testing steps.

3. Dependency and License Risks

AI tools sometimes suggest outdated or vulnerable third-party libraries. Under PCI DSS Requirement 6.3.2, organizations must maintain an inventory of custom and third-party software components and monitor them for known vulnerabilities, a process well explained by the OWASP Top 10 project.

4. Sensitive Data Exposure to AI Models

Pasting real cardholder data, API keys, or production configurations into AI prompts can itself be a compliance violation, since that data may be logged or used for model training, depending on the tool's data handling policy.

How Developers Can Stay PCI DSS Compliant in 2026

Treat AI Output Like Untrusted Code

Every AI-generated snippet should go through the same static analysis, peer review, and security testing as code written by a junior developer. Tools like SAST and DAST scanners remain essential, and many CI/CD pipelines now run these automatically before merge.

Maintain Human Accountability

PCI DSS Requirement 6.2.4 specifically calls for reviewing code for security vulnerabilities prior to release. Assign a named reviewer for every AI-assisted pull request, and document that review in your version control system.

Use Approved AI Tools with Clear Data Policies

Choose AI coding assistants with enterprise data protection guarantees that explicitly state prompts and code are not used for model training and are not retained beyond the session. Anthropic's own approach to enterprise data handling is detailed in the Anthropic Enterprise documentation.

Update Your Secure SDLC Policy

Your written software development policy — required under PCI DSS Requirement 6.2.1 — should explicitly mention AI-assisted development, defining acceptable use, review gates, and prohibited data inputs. If you need help structuring this, Vista InfoSec's security consulting services cover policy development tailored to PCI DSS environments.

Automate Dependency Scanning

Since AI tools often recommend packages, integrate automated software composition analysis (SCA) into your pipeline to catch vulnerable or malicious dependencies before deployment.

Train Developers on AI-Specific Secure Coding

Traditional secure coding training doesn't cover prompt injection, model hallucination of insecure patterns, or AI-specific data leakage risks. Updated training materials are increasingly available through resources like the SANS Institute, which now offers AI-security-focused courses.

What Auditors Are Asking in 2026

Qualified Security Assessors (QSAs) now routinely ask:

• Which AI coding tools are approved for use in the cardholder data environment?
• What is your policy for reviewing AI-generated code before deployment?
• How do you prevent sensitive data from being pasted into AI prompts?
• Can you demonstrate that AI-suggested dependencies are tracked in your software bill of materials (SBOM)?

Organizations unable to answer these clearly risk findings during their next Report on Compliance (ROC) assessment.

The Bottom Line

AI-generated code isn't inherently non-compliant with PCI DSS, but it does shift more responsibility onto developers and security teams to verify, document, and govern its use. As AI coding tools become deeply embedded in payment software development, the organizations that thrive in 2026 will be the ones that treat AI output with the same rigor — or more — as human-written code, backed by clear policies, automated tooling, and continuous developer education. To get a head start on your compliance posture, explore the Vista InfoSec resource centre for expert guidance on PCI DSS, AI security, and secure SDLC practices.

For the most current compliance requirements, always consult the PCI Security Standards Council directly, as standards and guidance continue to evolve.

If you build SaaS products and serve European customers, two major EU regulations are demanding your attention right now NIS2 and DORA. But which one actually applies to you? And what happens if both do? 

This guide cuts through the legal jargon and gives developers and technical teams a clear, practical breakdown of what each regulation requires, who it covers, and exactly what you need to do next. 

What Is NIS2 And Why Should SaaS Teams Care? 

The Network and Information Security Directive 2 (NIS2) officially Directive EU 2022/2555 replaced the original NIS1 Directive in October 2024. It is the EU's broadest cybersecurity law to date, covering 18 critical sectors including energy, healthcare, transport, digital infrastructure, and critically for tech companies cloud computing services and managed service providers. 

NIS2 defines two tiers of covered organizations: 

• Essential Entities - Organizations in high-criticality sectors like energy, banking, healthcare, and digital infrastructure. 
• Important Entities - Organizations in sectors like food production, waste management, and ICT service management. 

Size threshold: Companies with more than 50 employees OR revenue exceeding €10 million in these sectors are directly in scope. Smaller companies may be indirectly affected if they serve essential or important entities. 

What NIS2 Requires From You 

If NIS2 applies to your SaaS product, here is what you must implement: 

• Risk management measures — regular risk assessments, vulnerability management, and documented security policies 
• Supply chain security — auditing vendors and third-party SaaS tools used within your organization 
• Incident reporting — a three-stage process: early warning within 24 hours, full notification within 72 hours, and a final report within 30 days 
• Executive accountability — senior management must approve cybersecurity measures and can face personal liability for failures 
• Business continuity planning — documented disaster recovery and crisis management procedures 
• Asset inventory — a complete map of all information systems, including shadow IT and SaaS applications 

Penalties for non-compliance: Up to €10 million or 2% of global annual turnover for essential entities, and €7 million or 1.4% of turnover for important entities whichever is higher.

What Is DORA And How Is It Different? 

The Digital Operational Resilience Act (DORA) Regulation EU 2022/2554 has been fully applicable since January 17, 2025. Unlike NIS2, DORA is a regulation, not a directive. This means it applies directly and uniformly across every EU member state with zero national variation. 

DORA is laser-focused on the financial sector and its ICT supply chain. It covers roughly 22,000 financial entities, including: 

• Banks and credit institutions I
• nsurance companies and reinsurers 
• Investment firms and asset managers 
• Payment institutions and e-money institutions 
• Crypto-asset service providers (CASPs) 
• Trading venues and central counterparties 

Crucially for SaaS teams: If your product serves any of these financial entities, DORA reaches you indirectly through contractual requirements your customers will push down to you. 

What DORA Requires 

DORA's requirements are stricter and more prescriptive than NIS2: 

• ICT Risk Management Framework — a formal, board-approved framework covering identification, protection, detection, response, and recovery 
• Incident Reporting — major ICT incidents must be reported within 4 hours of classification, followed by updates at 24 and 72 hours 
• Digital Operational Resilience Testing — including mandatory Threat-Led Penetration Testing (TLPT) for significant entities 
• Third-Party Risk Management — a formal Register of Information (ROI) documenting all critical ICT vendors, with contractual security clauses 
• ICT Concentration Risk — managing over-dependence on a single cloud or ICT provider 
• Information Sharing — participating in threat intelligence sharing with other financial entities 

Penalties: Up to 2% of global annual turnover, with potential daily penalties for continued non-compliance. 

In 2026, DORA enforcement has fully shifted from guidance to active supervision. National regulators including BaFin (Germany), AFM/DNB (Netherlands), and ACPR/AMF (France) are actively conducting supervisory reviews and audits.

NIS2 vs DORA: Side-by-Side Comparison

Here is the legal rule that every compliance team must know: 

Article 4 of NIS2 explicitly states that DORA takes precedence (in legal terms: DORA is lex specialis) wherever the two regulations address the same matter for financial entities. 

This means: 

• If you are a financial entity (bank, insurer, payment institution, etc.) DORA applies, full stop. NIS2 defers to DORA for overlapping requirements. 
• If you are a SaaS company serving financial entities you are subject to NIS2 directly, and DORA contractually through your customers. 
• Full DORA compliance will satisfy most equivalent NIS2 obligations, but NIS2 may add narrow additional requirements around national CSIRT coordination and certain physical security elements.

Which Regulation Applies to Your SaaS Product? 

A Decision Framework Ask yourself these three questions in order: 

Question 1: Are you a financial entity as defined by DORA? Banks, insurers, payment institutions, investment firms, crypto-asset service providers if you are any of these, DORA applies directly. NIS2 defers to DORA for overlapping areas. 

Question 2: Do you serve financial entities as an ICT provider? If yes, you are not directly in DORA scope, but your customers will contractually impose DORA requirements on you. You may also fall under NIS2 as an ICT service provider depending on your size and sector. 

Question 3: Do you operate in any of NIS2's 18 sectors, or provide cloud/digital services? If yes, NIS2 applies to you directly. This catches most SaaS companies serving healthcare, energy, public administration, and digital infrastructure clients. 

The uncomfortable reality for many mid-sized SaaS companies: You may end up implementing NIS2 controls for your overall operation and DORA-aligned controls specifically for your financial sector customers. Deliberate planning is essential.

Practical Steps for SaaS Teams Starting Compliance Today 

Whether NIS2, DORA, or both apply to you, here is where to focus first: 

1. Build your asset inventory. Both regulations assume you know exactly what systems you run, who owns them, and how critical they are. Without this, everything else is theoretical. 
2. Set up incident classification and reporting workflows. DORA's 4-hour initial reporting deadline is aggressive. Build pre-approved notification templates, define escalation paths, and run tabletop exercises before an incident occurs not during one. 
3. Map your third-party dependencies. Know your critical vendors, have contracts with security clauses on file, and document your exit strategy if a vendor fails. For DORA, maintain the Register of Information in the format specified by the European Supervisory Authorities (ESAs). 
4. Get leadership formally involved. Both NIS2 and DORA attach personal accountability to senior management. Security must become a board-level conversation not just an engineering team concern. 
5. Use ISO 27001 as your compliance foundation. ISO 27001 is the single best starting point for both DORA and NIS2. Achieving ISO 27001 certification significantly reduces incremental effort for both regulations and demonstrates verifiable controls to regulators and customers alike

How VISTA InfoSec Can Help 

Navigating overlapping EU regulations is complex especially when your SaaS product serves customers across multiple sectors and geographies. At VISTA InfoSec, our compliance experts specialize in helping SaaS companies, fintechs, and digital service providers map their NIS2 and DORA obligations, build gap assessment frameworks, and achieve certification-ready postures efficiently. 

With 20+ years of experience across PCI DSS, ISO 27001, SOC 2, GDPR, and EU digital resilience frameworks, we bring the cross-regulation expertise your team needs without the overhead of building it in-house. 

Book a free compliance consultation with VISTA InfoSec

Key Takeaways 

• NIS2 is a broad EU cybersecurity directive covering 18 sectors, including cloud and SaaS providers. It requires risk management, supply chain security, 72-hour incident reporting, and executive accountability. 
• DORA is a stricter, directly applicable regulation targeting the financial sector and its ICT suppliers with a demanding 4-hour incident report requirement and mandatory penetration testing. 
• Where they overlap, DORA takes precedence for financial entities (the lex specialis principle). 
• Most SaaS companies are touched by at least one of these regulations — and many will need to satisfy elements of both. 
• Start with an asset inventory, incident response workflow, and ISO 27001 as your compliance foundation. 

The enforcement window is no longer ahead of you. It is now. The sooner your team understands its obligations, the less painful and expensive the path to compliance will be.