A European enterprise customer has just sent you a 120-question NIS2 supplier questionnaire, and procurement wants answers within two weeks. You already hold ISO 27001 or a SOC 2 report, so you are covered, right? Not quite. The gap between “certified” and “NIS2-ready” is exactly where EU deals quietly stall.

Here is what your customers really ask, what ISO 27001 and SOC 2 prove, and how to close the gaps before the next questionnaire lands.

Why EU Customers Are Sending NIS2 Supplier Questionnaires

The NIS2 Directive (Directive (EU) 2022/2555) requires essential and important entities to manage cyber risk. NIS2 supply chain security is one of its ten minimum measures under Article 21(2)(d), and Article 21(3) tells customers to weigh each direct supplier’s specific vulnerabilities, product quality and cybersecurity practices.

The pressure is real. As of October 2026, national NIS2 laws are in force in 24 of 27 EU member states, with France, Ireland and Spain still outstanding after the Commission referred four states to the Court of Justice in July. The Netherlands’ law took effect on 15 August 2026 and Austria’s on 1 October 2026. Fines reach €10 million or 2% of worldwide turnover for essential entities (€7 million or 1.4% for important ones), and Article 20 makes management bodies accountable. Your customer’s risk becomes your sales cycle, even if your own country has no live law.

What a NIS2 Supplier Questionnaire Really Asks

Expect questions mapped to the Article 21(2) measures. Typical themes:

• Governance and risk analysis: policies, risk assessments, management sign-off.
• Incident handling: detection, escalation and how fast you will notify the customer.
• Business continuity: backups, disaster recovery and tested restores.
• Supplier management: your own subprocessors and fourth parties.
• Secure development and vulnerabilities: patching, disclosure, penetration testing.
• Access control and encryption: who touches customer data, and how it is protected.

Does ISO 27001 Satisfy a NIS2 Supplier Questionnaire?

Largely, as strong evidence rather than complete proof. An ISO 27001:2022 certificate shows an independently audited information security management system covering risk, incident response, continuity and supplier controls (Annex A 5.19–5.23). Procurement teams like it because they can verify it with the certification body.

Before attaching it, check four things: the scope covers the exact service you sell; the certificate is to the 2022 edition (the transition from ISO 27001:2013 ended on 31 October 2025); the issuing body is accredited; and you can share your Statement of Applicability. Still building towards it? VISTA InfoSec’s ISO 27001 audit and certification service is a practical starting point.

Does SOC 2 Satisfy a NIS2 Supplier Questionnaire?

SOC 2 is an attestation report issued by a CPA firm against the AICPA Trust Services Criteria, not a certification. A Type II report tests whether controls operated effectively over a review period, and it addresses vendor management under CC9. Our guide to SOC 2 Type 1 vs Type 2 explains the difference.

The blind spots for EU buyers: reports are usually treated as current for about 12 months, so older ones need a bridge letter; exceptions and carve-outs for subservice organisations matter; and only the Security criterion is mandatory, so confirm what is in scope. Need a report? See SOC 2 compliance and attestation.

Where ISO 27001 and SOC 2 Both Fall Short

NIS2 itself does not name either framework as mandatory proof, and there is no “NIS2 certificate”. Customers still need answers neither document gives:

• Incident notification to customers. Under Article 23 your customer must send an early warning within 24 hours and a notification within 72 hours, so they will expect you to tell them much sooner.
• Data location and subprocessors. EU buyers ask where data sits and who can access it, tied to GDPR processor terms.
• Contract clauses. Audit rights, security requirements and exit terms.
• Vulnerability evidence. Recent penetration testing results.
• Sector rules. Cloud, data-centre and managed-service providers face detailed technical requirements under Implementing Regulation (EU) 2024/2690, and financial clients may add DORA demands.

How to Answer a NIS2 Supplier Questionnaire and Win the Deal

1. Map first. Link each Article 21(2) measure to a control you already run.
2. Lead with evidence. Attach your certificate and Statement of Applicability or SOC 2 report, plus a penetration-test summary.
3. Be precise about scope. State which services, sites and periods the assurance covers.
4. Commit to a notification window. Put a fast, written incident-notification commitment in the contract.
5. Build an answer library. Reuse approved responses for every future questionnaire.

National rules differ, so tailor answers by market. VISTA InfoSec’s NIS2 compliance consulting for Germany and NIS2 compliance in the Netherlands cover local specifics, while the broader NIS2 compliance and audit service supports gap assessments.

Frequently Asked Questions

Is ISO 27001 enough for a NIS2 supplier questionnaire?

It is strong evidence, not a guarantee. NIS2 expects a risk-based view of each supplier, so customers may still ask about scope, incident-notification commitments and contract terms.

Do non-EU suppliers need to worry about NIS2?

Not automatically, although some non-EU digital providers serving the EU are in scope themselves. Either way, EU customers pass requirements down through contracts.

Should I get ISO 27001 or SOC 2 first?

Start with whichever your buyers request most. ISO 27001 is widely recognised across Europe, SOC 2 is common with US-linked buyers, and many suppliers eventually hold both.

The Bottom Line

ISO 27001 and SOC 2 open the door, but neither answers a NIS2 supplier questionnaire alone. Pair your assurance with a clear scope, fast incident notification and EU-ready data answers, and a compliance hurdle becomes a trust signal. Ready to see where you stand? Book a free consultation with VISTA InfoSec.

Sources: Directive (EU) 2022/2555 (NIS2), EUR-Lex | European Commission: NIS transposition status

What the 2026 EU Proposal Actually Says

On 20 January 2026, the European Commission published COM(2026) 13, a proposal to amend the NIS2 Directive alongside a revised Cybersecurity Act (COM(2026) 11). The PQC change is a new point (k) in Article 7(2): Member States must adopt policies, within their national cybersecurity strategies, for the transition to post-quantum cryptography, taking into account the timelines set in applicable EU law and policy.

Two points matter for developers. First, it is still a proposal. It is moving through the ordinary legislative procedure as 2026/0012(COD), and as of early October 2026 neither the European Parliament nor the Council had adopted a position. Second, it addresses Member States, not companies directly. Your existing duty sits in Article 21, which already requires policies and procedures on the use of cryptography and encryption. If the amendment is adopted, Member States would have 12 months to transpose it.

The EU PQC Roadmap: Three Dates to Know

The proposal leans on the Coordinated Implementation Roadmap for the transition to PQC, released in June 2025 by the NIS Cooperation Group in response to Commission Recommendation (EU) 2024/1101. Its milestones:

• 31 December 2026: Member States have implemented the first steps, drawn up initial national roadmaps and started pilots for high- and medium-risk use cases.
• 31 December 2030: high-risk use cases are migrated, and quantum-vulnerable public-key mechanisms are no longer used stand-alone for them.
• 31 December 2035: medium-risk use cases are migrated, and low-risk ones as far as feasible.

The roadmap is a recommendation, not binding law, and the 2026 milestone is addressed to Member States. Even so, the NIS Cooperation Group's April 2026 FAQ says entities in scope of NIS2 should, at a minimum, build a cryptographic inventory and dependency maps, involve their supply chain and run a quantum risk analysis. Expect audit and procurement questions to follow.

A Developer's PQC Checklist for 2026

1. Build a cryptographic inventory. Find every use of RSA, ECDSA, ECDH and Diffie-Hellman across your code, dependencies, certificates, HSMs and firmware, and record it in a standard format such as a CycloneDX CBOM. According to the NIS Cooperation Group, you do not need a finished inventory before you start planning.
2. Prioritise by data lifetime. The roadmap treats data that must stay confidential for 10 years or more, and systems that would take over 8 years to migrate where compromise would have high impact (software-update signing is the example), as high risk.
3. Design for crypto-agility. Put algorithms behind interfaces, avoid hard-coded key sizes and make algorithm choice configurable, so swapping primitives becomes a configuration change rather than a rewrite.
4. Learn the NIST standards. FIPS 203 (ML-KEM) covers key establishment; FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) cover signatures. All three were finalised on 13 August 2024. FN-DSA (FIPS 206) is still a draft, and NIST selected HQC in March 2025 as a backup KEM. ML-KEM-768 and ML-DSA-65 are common starting points for civilian systems.
5. Plan for size and hybrids. Hybrid key exchange, pairing a classical algorithm with ML-KEM, is a widely used bridge. ML-DSA signatures run from roughly 2.4 to 4.6 KB, so test certificate chains, token limits, packet sizes and HSM support early.
6. Question your suppliers. Ask vendors and library maintainers for PQC roadmaps. The Cyber Resilience Act's main obligations apply from 11 December 2027, and the EU roadmap recommends that products with a lifetime beyond 2030 be upgradable to PQC, with post-quantum signatures protecting update mechanisms.
7. Test what you ship. New cryptography brings new bugs: misconfigured hybrids, downgrade paths and side channels. Include PQC changes in your penetration testing and vulnerability assessments, ideally with a CREST-accredited provider.

A practical way to begin: pick one high-value service this quarter, such as your API gateway or code-signing pipeline, map its cryptography and run a pilot with hybrid key exchange in a test environment. A small, well-documented pilot gives you evidence for auditors, realistic performance numbers for architects and a template for every service that follows.

Why This Matters for NIS2 Compliance

NIS2 penalties are substantial: maximum fines of at least €10 million or 2% of worldwide annual turnover for essential entities, and at least €7 million or 1.4% for important entities, whichever is higher. Management bodies can also be held liable for failing to comply. PQC readiness belongs inside your wider NIS2 compliance programme, alongside risk analysis, incident handling and supply chain security, not in a side project. A vendor-neutral cybersecurity consultancy such as VISTA InfoSec can support gap analysis and risk assessment, so developers and compliance teams work from the same plan.

Frequently Asked Questions

Is NIS2 post-quantum cryptography mandatory today?

Not as a standalone obligation on companies. The amendment is only a proposal and targets Member States. However, Article 21 already requires cryptography policies, and Member States are expected to have national PQC roadmaps by the end of 2026.

Which post-quantum algorithms should developers start with?

Start testing ML-KEM for key establishment and ML-DSA for signatures, ideally in a hybrid setup, and keep your code crypto-agile so FN-DSA and HQC can follow once finalised.

Start Now, Not on 31 December

The 31 December 2026 date is a Member State milestone, not a developer deadline, but it is the clearest signal yet that Europe expects organisations to know where their cryptography lives. Start with an inventory, rank your risks and build agility into every release. For an expert second opinion on your cryptographic risk, talk to the VISTA InfoSec team about cybersecurity and compliance support.

References

• EU Coordinated Implementation Roadmap for the Transition to PQC
• Recommendation (EU) 2024/1101
• COM(2026) 13, proposal amending NIS2
• Directive (EU) 2022/2555 (NIS2)
• European Parliament Legislative Observatory, 2026/0012(COD)

It is Monday, 9:07 a.m. A message from your national cybersecurity authority reaches your CISO: please provide evidence of the cybersecurity risk-management measures you have implemented. Do you have an answer ready, or does a week of panic begin?

By mid-October 2026, 24 of the 27 EU Member States have transposed NIS2 into national law, according to the ECSO NIS2 tracker, so supervisors increasingly have the legal power to ask. This guide explains what a NIS2 evidence pack is, what belongs in it, and how to build one in 30 days.

Why 2026 Is the Year to Become Audit-Ready

Directive (EU) 2022/2555, known as NIS2, had to be transposed by 17 October 2024. Most Member States missed that date, but 2026 closed much of the gap. Germany's law has applied since December 2025, the Netherlands' Cyberbeveiligingswet took effect on 15 August 2026 (see our NIS2 compliance support in the Netherlands), and Austria's NISG 2026 followed on 1 October 2026. France, Ireland and Spain still lacked a national law in recent trackers, so check your own Member State's status. Even so, group-wide customers and supply-chain contracts rarely wait for local legislation. Operating there? Review our pages on NIS2 in France and NIS2 in Ireland.

Under Article 32, authorities can run on-site inspections, security audits and scans, and request evidence that your policies are genuinely implemented. Essential entities face proactive supervision; important entities face reactive supervision after an incident or complaint. The Article 21 duties are the same for both.

The stakes are real. Member States must set maximum fines of at least €10 million or 2% of worldwide annual turnover (whichever is higher) for essential entities, and at least €7 million or 1.4% for important entities. Article 20 also makes management bodies answerable for approving and overseeing the measures, and authorities can temporarily bar individuals from management roles in essential entities.

What Is a NIS2 Evidence Pack?

A NIS2 evidence pack is one indexed, version-controlled set of records that proves, control by control, that your obligations are met and working. It is the answer to every question a regulator might ask, stored so your team can produce it in hours, not weeks.

The NIS2 Compliance Checklist: 8 Things Your Evidence Pack Needs

Give every item an owner, date, version and review cycle. For evidence rows 7 and 8, independent penetration testing and a vulnerability assessment produce exactly the dated proof supervisors like to see.

Show That It Works, Not Just That It Exists

Policies earn half the marks. Supervisors want operating evidence: approvals, test results, tickets and logs showing controls ran during the period. Article 21 requires measures that are appropriate and proportionate, so record your reasoning (size, sector, exposure) beside each decision.

An ISO 27001 programme is a strong foundation, but certification alone does not prove NIS2 compliance, so map each control to the Article 21 measures. Financial entities should also align with DORA, the sector-specific regime for ICT risk and incident reporting, while one incident can also start the GDPR 72-hour clock. Cut duplicated effort with our guide to NIS2 and GDPR compliance, or run frameworks together through Audit Fusion 360. Board members who need a clear briefing can use CISO advisory services.

Three Evidence Mistakes That Slow Audits Down

First, stale documents: a policy last reviewed in 2023 signals that nobody owns it. Second, scattered proof: evidence spread across inboxes and personal drives cannot be produced quickly. Third, untested plans: an incident procedure nobody has rehearsed will not survive a 24-hour deadline. Fix these three and most supervisory requests become routine.

Watch the Horizon: NIS2 Is Being Amended

On 20 January 2026, the European Commission proposed targeted amendments to NIS2 alongside a revised Cybersecurity Act, building on the Digital Omnibus package of 19 November 2025, which aims to simplify incident reporting. These proposals are still moving through the legislative process, so today's obligations apply in full. Build your pack in modular form so it can adapt.

Build Your Pack in 30 Days

1. Week 1: confirm scope, entity type and national authority; run a gap analysis against Article 21.
2. Week 2: close governance and incident-response gaps; collect board approvals.
3. Week 3: test, running a tabletop exercise, a backup restore and a vulnerability scan.
4. Week 4: assemble the index, then run a mock regulator request and time your response.

NIS2 Evidence Pack FAQ

Who needs a NIS2 evidence pack? Every in-scope essential and important entity, because supervisors can request proof of Article 21 measures.

Does NIS2 apply outside the EU? It can, when you provide in-scope services within the EU. Check Member State rules and your regulatory exposure. German-speaking teams can also download the NIS2 Readiness Guide für deutsche Unternehmen.

Sources: Directive (EU) 2022/2555, EUR-Lex; ECSO NIS2 Transposition Tracker; Covington, Commission NIS2 amendment proposal. Informational only, not legal advice; national laws vary.

Scroll through any European feed today and a quiet question hangs over every image, voice and chat bubble: was a human behind this? Since 2 August 2026, EU law expects an honest answer. EU AI Act Article 50, the rule behind AI labelling and AI transparency obligations, is now live, and developers shipping chatbots, image generators or synthetic media to EU users sit on the front line. Here is what it demands, what changed this year, and a practical checklist you can run against your product this week.

What Is EU AI Act Article 50?

Article 50 of Regulation (EU) 2024/1689 sets transparency duties for AI systems that talk to people or create content. It applies whether or not a system is classed as high-risk, so even a simple marketing chatbot is in scope. It contains four core duties, plus a rule on how disclosures must look and when they must appear:

• Article 50(1): providers must design AI systems that interact with people so users are told they are dealing with AI, unless that is obvious from context.
• Article 50(2): providers of systems generating synthetic audio, images, video or text must mark outputs in a machine-readable format so they are detectable as AI-generated or manipulated.
• Article 50(3): deployers of emotion recognition or biometric categorisation systems must inform the people exposed to them.
• Article 50(4): deployers must disclose deepfakes, and AI-generated text published to inform the public on matters of public interest.
• Article 50(5): disclosures must be clear, distinguishable, accessible, and given at the latest at first interaction or exposure.

Was Article 50 Delayed by the Digital Omnibus? Mostly No

This is the question developers keep asking, and the answer matters. The Digital Omnibus on AI, in force since 27 July 2026, postponed high-risk obligations: Annex III systems now follow on 2 December 2027, and AI embedded in regulated products (Annex I) on 2 August 2028. Article 50 was not postponed and has applied since 2 August 2026.

There is one narrow exception. For generative systems already on the EU market before 2 August 2026, the Article 50(2) machine-readable marking duty applies from 2 December 2026. Anything placed on the market from 2 August 2026 must comply from day one. With that date less than two months away, treat the grace period as a countdown, not a reprieve.

Provider or Deployer? Know Your Role

Providers build AI systems or place them on the market; deployers use them under their own authority. Many teams are both. A SaaS company that fine-tunes a model and embeds it in its product is a provider for Articles 50(1) and 50(2), and a deployer for 50(4) when it publishes outputs itself. Map your role per feature, not per company.

The AI Labelling Checklist for Developers

1. Inventory every AI touchpoint. List chatbots, voice agents, image, video, audio and text generators, and any emotion or biometric features. You cannot label what you have not found.
2. Disclose AI interaction by design (50(1)). Show a clear "you are talking to an AI" notice at or before the first message. Skip it only where context makes AI use genuinely obvious, and document why.
3. Apply machine-readable marking (50(2)). Embed watermarks, metadata or equivalent signals into generated audio, image, video and text. Aim for solutions that are effective, interoperable, robust and reliable as far as technically feasible. Assistive editing that does not substantially alter the input is carved out.
4. Make marks detectable. A mark nobody can read is a failed control. Test that your signals survive compression, cropping and format conversion, and that detection works for third parties.
5. Label deepfakes visibly (50(4)). Where your product publishes realistic synthetic media, add a clear visible or audible disclosure. For evidently artistic, creative, satirical or fictional works, disclosure can be lighter so it does not spoil the experience.
6. Flag AI text on public-interest topics. Published AI-generated text that informs the public needs a label, unless a human has reviewed it and a person holds editorial responsibility. Record that review.
7. Notify people exposed to emotion recognition or biometric categorisation (50(3)). Pair the notice with GDPR-compliant processing.
8. Make disclosures timely and accessible (50(5)). Show them at first exposure, in plain language, and in formats everyone can use. Audio-only content needs an audio disclaimer.
9. Log, test and document. Keep evidence of design decisions, marking tests and review workflows. Include your marking and disclosure flows in security testing so they cannot be stripped or spoofed easily.

Your Shortcut: The Code of Practice and Commission Guidelines

Two official resources make life easier. The European Commission published the final Code of Practice on marking and labelling AI-generated content on 10 June 2026. It is voluntary, and the Commission and the AI Board have assessed it as adequate, so signatories can rely on it to demonstrate compliance. On 20 July 2026, the Commission added non-binding guidelines that explain scope, with practical examples for each Article 50 duty. Read both before you finalise your design.

What Happens If You Ignore It?

Breaches of Article 50 can draw administrative fines of up to €15 million or 3% of worldwide annual turnover, whichever is higher; for SMEs and start-ups the lower amount applies. National authorities enforce the rules, and unlabelled synthetic content also puts customer trust at risk in a market that already expects strong data protection.

Turn the Checklist Into Compliance Evidence

A checklist is a start; evidence is what regulators and enterprise buyers ask for. VISTA InfoSec's EU AI Act compliance services can help you scope your obligations and close gaps, and the EU AI Act compliance checklist offers a wider walkthrough. Because AI systems process personal data, align your labelling work with GDPR compliance consulting and the AI and GDPR preparation expert roundup.

Finally, prove your controls hold up. Penetration testing can show whether your marking and disclosure flows can be bypassed, while ISO 27001 consulting gives you a management system to keep them governed. Ready to move? Book a free compliance consultation and turn Article 50 from a risk into a trust signal.

Since 11 September 2026, a new regulatory clock has been running for every manufacturer selling connected products in the EU. The Cyber Resilience Act (CRA) reporting duties are now live, and they sit on top of NIS2, DORA and GDPR obligations your security team already juggles. One incident can now trigger four different deadlines, four recipients and four sets of wording. If your incident response runbook still treats them as one generic "notify the regulator" step, this guide is for you.

Why CRA incident reporting changes your runbook now

The Cyber Resilience Act (Regulation (EU) 2024/2847) entered into force on 10 December 2024. Its main requirements apply from 11 December 2027, but the reporting obligations for manufacturers arrived much earlier: 11 September 2026. That includes products already on the EU market, not just new launches.

Manufacturers of products with digital elements, such as connected devices, software and components, must report two things: actively exploited vulnerabilities and severe incidents that affect the security of their product. Reports go through the ENISA single reporting platform, which routes them to the CSIRT designated as coordinator and to ENISA.

CRA, NIS2, DORA and GDPR deadlines at a glance

The pattern is clear: 24 hours is the new baseline, and DORA is the strictest of all. A fintech that ships its own connected app could face every one of these at once.

What counts as reportable under the CRA?

Two triggers matter. The first is a vulnerability in your product that is being actively exploited, meaning there is reliable evidence that a malicious actor used it without the system owner's permission. The second is a severe incident with an impact on the security of your product. A theoretical flaw found in testing is not reportable on its own; one seen in the wild is.

The CRA reporting clock also starts at awareness, not at confirmation of full root cause. Your team needs authority to file an early warning before the investigation is finished.

6 steps to update your incident response runbook

1. Build one triage decision tree. Ask the same questions once: Is a product vulnerability exploited? Is personal data affected? Is a financial ICT service disrupted? Is an essential or important service impacted? Each "yes" activates a regulation-specific track.
2. Start separate clocks. Log the "awareness" timestamp and run parallel timers for 4 hours (DORA), 24 hours (CRA, NIS2) and 72 hours (CRA, NIS2, GDPR). Document who decides that an incident is "major" or "significant" and how quickly.
3. Assign named roles with deputies. Incident commander, legal and DPO, product security lead and regulatory submitter, each with a backup for weekends and holidays.
4. Pre-write report templates. Keep early-warning, notification and final-report drafts ready for each regime so analysts fill in facts instead of drafting prose under pressure.
5. Prepare platform access. Make sure the right people can use the ENISA single reporting platform and national authority portals before you need them.
6. Test it. Run a tabletop exercise that mixes a CRA vulnerability with a GDPR breach. Measure how long it takes to produce a defensible first report.

Common mistakes to avoid

• Waiting for certainty. Early warnings exist precisely because facts are incomplete.
• Ignoring suppliers. Your open-source components and third-party code can be the source of an exploited vulnerability. Keep an up-to-date software bill of materials (SBOM) and clear vendor notification clauses.
• Inconsistent messaging. Regulators compare notes. Use a single fact sheet as the source for every submission.
• Forgetting users. The CRA expects manufacturers to inform affected users about incidents and the corrective measures available.

Penalties: why this is a board-level issue

The stakes are real. GDPR fines reach up to €20 million or 4% of global annual turnover. NIS2 allows up to €10 million or 2% for essential entities and €7 million or 1.4% for important ones. Breaching CRA essential requirements can cost up to €15 million or 2.5% of worldwide turnover, and failing other CRA obligations, including reporting, up to €10 million or 2%. Supplying incorrect information to authorities carries its own penalty.

Frequently asked questions

Does CRA incident reporting replace NIS2 or GDPR reporting?
No. The CRA covers product security, while NIS2 covers entity-level incidents and GDPR covers personal data breaches. One event can trigger all of them, so your incident response plan must run them in parallel.

Is a single EU reporting channel coming?
The European Commission has proposed simplifying incident reporting through a single entry point as part of its digital simplification agenda, but proposals can change. Until a final law applies, keep separate obligations in your runbook and monitor official EU sources.

Final thoughts

CRA incident reporting is not a future problem. It is live, overlaps with NIS2, DORA and GDPR, and rewards organisations that decide fast and document well. Update your triage logic, pre-build your templates and rehearse. Then talk to VISTA InfoSec about turning your runbook into an audit-ready compliance asset.

This article is for general information, not legal advice. Deadlines and national rules can change; confirm current requirements with your legal counsel and official EU and national authority guidance.

Two standards. One regulation. And a certificate that may not mean what your board thinks it means.

If you build, sell or deploy AI in Europe, 2026 has handed compliance teams a new dilemma: certify to ISO 42001 now, or organise everything around EN 18286, the first standard written specifically for the EU AI Act? The honest answer is that they do different jobs, and only one of them is aimed squarely at the law. Here is what is confirmed, what is still pending, and how to plan around both.

What Is EN 18286?

EN 18286:2026, titled Artificial intelligence – Quality management system for EU AI Act regulatory purposes, was prepared by CEN/CLC/JTC 21 under the European Commission's standardisation request M/613 and approved by CEN-CENELEC on 12 July 2026. CEN-CENELEC describes it as the first harmonised European standard supporting the AI Act, and it is not tied to any single sector.

Its job is narrow and important: it turns Article 17, the quality management system (QMS) duty for providers of high-risk AI systems, into auditable requirements. Its Annex ZA, the section that links a standard to the law, covers Article 17(1) and the first sentence of Article 11(1).

What Is ISO 42001?

ISO/IEC 42001:2023, published in December 2023, is the world's first certifiable AI management system (AIMS) standard. It follows the same harmonised structure as ISO 27001, so it slots neatly beside an existing security programme, and any organisation that develops, provides or uses AI can adopt it. Certification is voluntary and third-party audited. However, it is not a harmonised standard under the AI Act, so a certificate alone gives no legal presumption of conformity.

EN 18286 vs ISO 42001: Key Differences

The Catch: No Presumption of Conformity Yet

Under Article 40 of the AI Act, a provider that follows a harmonised standard gets a presumption of conformity with the requirements it covers, but only once the Commission cites that standard in the Official Journal of the European Union. In the latest public checks we found (August 2026), EN 18286 was published but not yet cited, and CEN-CENELEC has said the reference is expected later in 2026. Verify the current status before briefing your board.

Two practical consequences follow. Until citation, EN 18286 is not a legal safe harbour, yet it is the clearest preview of what regulators and notified bodies will expect. And even after citation it covers only part of the Act, so other obligations still need their own evidence.

Digital Omnibus: More Time, Not Less Work

The Digital Omnibus on AI has been in force since 27 July 2026. It moved the stand-alone high-risk (Annex III) deadline from 2 August 2026 to 2 December 2027, and high-risk AI embedded in regulated products (Annex I) to 2 August 2028. The telling reason: harmonised standards and national authorities were not ready.

Do not mistake this for a pause. Prohibited practices and AI literacy duties already apply, general-purpose AI obligations are unchanged, and Article 50 transparency rules have applied since 2 August 2026, with a grace period to 2 December 2026 for machine-readable marking on generative systems already on the market. Fines for prohibited practices can reach €35 million or 7% of global turnover. For European buyers and regulators, documented readiness now is fast becoming a trust signal, not just a legal checkbox.

Do You Need Both? Usually, Yes

Think of it this way: ISO 42001 is your organisation-wide AI governance engine; EN 18286 is the regulator-facing QMS blueprint. EN 18286 even includes annexes relating it to ISO 9001 and ISO/IEC 42001, a sign that Europe expects the standards to coexist rather than compete. Building once and mapping twice saves both budget and audit fatigue.

For most providers, the smartest sequence is to build an AIMS on ISO 42001 now, since enterprise buyers recognise it and it reuses your ISO 27001 scaffolding, then gap-assess it against EN 18286. VISTA InfoSec's guide to EU AI Act vs ISO 42001 explains why a certificate never replaces conformity assessment, CE marking or registration duties.

Your 5-Step Plan for 2026

1. Inventory every AI system, including AI hidden inside SaaS tools. This EU AI Act compliance checklist shows how.
2. Confirm your role and risk class: provider, deployer, importer or distributor, and whether anything is high-risk.
3. Stand up an AIMS with expert ISO 42001 certification support.
4. Gap-assess against EN 18286 (clauses 4–10) and document evidence for Articles 11 and 17.
5. Track the Official Journal and re-baseline your roadmap to December 2027, using these 10 EU AI Act readiness controls as a working list.

FAQs

Final Thoughts

EN 18286 is the standard built for the EU AI Act; ISO 42001 is the governance foundation that gets you there faster. Start with ISO 42001, map to EN 18286, keep evidence audit-ready, and treat the Omnibus extension as runway, not relief. Ready to turn standards into evidence? Talk to the team at VISTA InfoSec, whose European engagements run through Zulon Audits OÜ, and request an EU AI Act readiness review.