ISO 42001 for Support Teams: An AI Management System for the Inbox

A security questionnaire lands in the shared inbox. Question 14 reads: Is your AI vendor certified to ISO/IEC 42001? If not, provide your AI management system documentation.

Two years ago that question didn't exist. Now it turns up in mid-market procurement packs, and the honest reaction from most support leaders is a quiet panic followed by forwarding it to whoever owns SOC 2.

That instinct is understandable and mostly wrong, because ISO 42001 asks a different kind of question than a security standard does, and a good part of the answer sits inside the support org rather than inside security.

What the standard actually certifies

ISO/IEC 42001:2023 was published in December 2023 by ISO/IEC JTC 1/SC 42. It is the first international standard for an artificial intelligence management system, and the important word in that phrase is management system, not artificial intelligence.

A management system is the set of policies, roles, processes and records through which an organisation consistently governs an activity. ISO 9001 does it for quality. ISO 27001 does it for information security. ISO 42001 does it for the responsible development, provision and use of AI. It uses the same harmonised clause structure as its siblings — context, leadership, planning, support, operation, performance evaluation, improvement — and then adds AI-specific controls on top.

What it does not do is test your model.

Nothing in the standard says your email agent has to answer correctly 94% of the time. It says you must decide what “correct enough” means for your context, measure it, record the decision, review it, and act when the number moves. An auditor checks that the loop exists and runs. They are not going to read your responses and grade them.

This trips people up constantly. A certified organisation can still ship a mediocre agent. What it can't do is ship one without anybody having assessed the risk, defined the acceptable behaviour, or noticed when the behaviour changed. The standard itself is explicit that it applies to any organisation providing or using AI products and services, which is the line that pulls support teams into scope.

Are you the provider or the user? Scope decides everything

Before anything else, work out which side of the chain you're on, because the obligations differ sharply.

If you buy an email agent from a vendor and run it on your support address, you are a user of an AI system. Your AIMS has to cover how you selected it, what you decided it's allowed to do, how you monitor it, and how you handle it going wrong. It does not have to cover how the underlying model was trained.

If you built the thing in-house — your own orchestration, your own prompts, your own retrieval layer, put into service under your own brand — you're closer to a provider, and the lifecycle controls around design, verification and technical documentation land on you directly. Several enterprise support orgs went the build route in 2025 specifically to reduce vendor risk, and inherited a governance role in the process.

Now the part that gets misread in procurement. Your vendor's certificate covers your vendor's management system, within whatever scope statement their auditor accepted. It is evidence about how they govern their product. It says nothing about whether you configured refund limits sensibly or whether anyone at your company has looked at an escalation sample since March.

A vendor certificate is a useful input. It is not a substitute for your own answer, and any buyer treating it as one has misunderstood what they bought.

Annex A is a reference set, not a checklist

This is the single most misunderstood thing about the standard, and it's the reason so many implementation projects go sideways.

Annex A lists 38 controls grouped under nine objectives. Teams open it, read it as a to-do list, and start working through all 38. That's not how it works. You run a risk assessment first, choose the controls that treat the risks you actually found, and then justify — in writing, to an auditor — both what you included and what you left out. That document is the Statement of Applicability, and it's the centre of gravity of the whole certification.

The standard even allows for controls beyond Annex A where your risks call for them. Nine objectives, 38 controls, and none of them automatically yours.

For a support team running an AI agent in the inbox, a handful of them do real work:

• Impact assessment (A.5): the effect of the system on individuals and groups. Your affected individuals are customers, and the harms are concrete — a wrong refund decision, an account change made on a fraudulent request, a vulnerable customer handled by a machine when they needed a person. ISO/IEC 42005 gives you a structured process for this if you'd rather not invent one.
• Data for AI systems (A.7): provenance, quality and preparation of the data feeding the system. In practice this is your knowledge base and your historical ticket archive, and the awkward question is whether anyone has audited either for accuracy since the agent went live.
• Information for interested parties (A.8): what you tell people about the system. Disclosure that an AI is answering, the route to a human, and how someone reports a problem. This one overlaps heavily with what Article 50 of the EU AI Act requires for email support, and the same artefacts serve both.
• Responsible use (A.9): the intents your agent is permitted to resolve autonomously, and the ones it isn't. Written down, approved, and reviewed on a cadence rather than adjusted quietly in a config file.
• Third-party and customer relationships (A.10): who is responsible for what, across you and your vendor. This is where most buyer-side AIMS work sits, and where most contracts written before 2025 say nothing useful.
• Lifecycle and monitoring (A.6): objectives for the system, verification before deployment, and monitoring after it. Event logging lives here, which makes your audit trail design a compliance artefact rather than just an operational one.

Notice how much of that is documentation of decisions you have already made informally. Most support teams have an escalation policy. Very few have one with a version number, an owner and a review date.

What certification will not get you

Four honest limits, because the marketing around this standard has got loud.

It doesn't prove your AI is accurate. It proves you have a process for deciding what accuracy means and checking it.

It doesn't satisfy the EU AI Act. The Act is binding law; ISO 42001 is a voluntary standard. They overlap substantially — the risk assessments and technical documentation you build for one feed the other — but no clause of the Act says a certificate discharges an obligation. Anyone telling you otherwise is selling something.

It doesn't cover information security. That's still ISO 27001's job, and if you already hold 27001 you're a meaningful way into 42001 because the clause structure, internal audit programme and management review process carry over. Teams with existing ISO infrastructure report roughly half the effort of teams starting cold.

And it doesn't audit outputs. No sampling of your sent folder. No review of whether the agent's tone was appropriate on a complaint thread. If you want that assurance you need a QA programme scoring real responses, which the standard will happily require you to have but will not run for you.

How it differs from the NIST framework

US buyers tend to ask about both in the same breath, which suggests they're alternatives. They're not.

The NIST AI Risk Management Framework is voluntary and non-certifiable. Nobody audits you against it, you self-claim alignment, and its value is a shared vocabulary plus a genuinely good Playbook for deciding what to measure. ISO 42001 is the certifiable counterpart: same broad territory, but written as auditable requirements that a third party signs off on.

In practice they stack rather than compete. Teams use the NIST functions to work out what to do and the ISO clauses to prove they did it. If your questionnaire asks about both, the answer isn't to pick one — it's that the NIST functions mapped onto an email queue produce most of the evidence an ISO auditor would want to see anyway.

Reading a vendor certificate without being fooled

Certificates are issued by accredited certification bodies, not by ISO. Three things to check before you file one as evidence.

The scope statement. Every certificate carries one, and it defines what was assessed. “AI management system for the design, development and operation of the [Product] platform” is meaningful. A scope naming only a corporate research function while the product you're buying sits elsewhere is not. Read the scope, not the logo.

The accreditation. ISO/IEC 42006:2025 sets the requirements for the bodies that audit and certify AI management systems — competence, impartiality, and how audit time gets calculated. It matters because accreditation bodies assess certifiers against it, and a certificate from an unaccredited body means considerably less. BSI was the first body accredited by UKAS for 42001; several others now hold ANAB or RvA accreditation.

The date and the cycle. Certification runs a Stage 1 and Stage 2 audit, is valid for three years, and requires annual surveillance audits in between. A certificate issued eighteen months ago with no surveillance record behind it is worth asking about.

If you're building a procurement process around this, it belongs alongside the other questions in an AI email support vendor scorecard rather than as a standalone gate. Certification is a signal about governance maturity. It is not a proxy for product quality, and treating it as one will lead you to buy the better-documented tool rather than the better tool.

The European wrinkle you'll hear about soon

CEN approved the standard as EN ISO/IEC 42001:2026 on 13 March 2026, taken over by CEN-CENELEC/JTC 21 without modification. Thirty-four countries have to give it national-standard status by September 2026.

The technical content hasn't changed. What changes is procedural weight: a European Standard sits in a different position in European procurement and regulatory conversation than an international one, and public-sector buyers in particular tend to start citing EN references once they exist. If your customer base includes European enterprises or public bodies, expect the question to arrive with more force in 2027 than it does today.

What to do this quarter if you're not certifying

Most support teams reading this aren't going to pursue certification. It runs somewhere between four and nine months and costs tens of thousands of dollars depending on scope, organisation size and how much ISO infrastructure you already have. That's a real decision, not a formality.

The useful move is to build the artefacts anyway, because the artefacts are what a procurement questionnaire actually asks for. Six of them, none requiring an auditor:

1. An inventory of every AI system touching customer conversations — the email agent, any summarisation running in the helpdesk, the sentiment scoring nobody remembers switching on.
2. An impact assessment for the inbox, naming who could be harmed and how, with the worst realistic case written down rather than implied.
3. A policy on autonomous action: which intents resolve without a human, which never do, and who has authority to change that.
4. A named owner with the authority to pause the agent, plus the path for anyone in the org to raise a concern about its behaviour.
5. A monitoring cadence with actual numbers attached — sample size, review frequency, what triggers escalation to the owner.
6. A supplier responsibility map saying which controls you rely on the vendor for and which you run yourself.

Two weeks of work for a support ops lead who already knows the answers and just hasn't written them down. Do it before the questionnaire arrives rather than during the fortnight you have to respond, which is when everyone else does it and it shows. For teams in sectors with existing compliance obligations, much of this will duplicate work already done under a different heading, and the mapping exercise is usually faster than the drafting.

Where Robylon sits in this

Most of an AIMS is your organisation's work, not your vendor's, and any vendor claiming otherwise is overselling. What a platform can do is make the artefacts producible rather than reconstructible.

Robylon's email agent keeps per-workflow permissions and autonomous-action boundaries as explicit configuration rather than emergent behaviour, so the policy document and the running system say the same thing. Every action across 60+ write-access integrations is logged with the context that produced it, escalation reasons are recorded as structured events instead of inferred, and human-in-the-loop review is captured distinctly from ordinary ticket handling. That covers the evidence side of the lifecycle and monitoring controls. It does not write your impact assessment, and we'd be suspicious of anyone who said it did.

The standard is easier than its reputation and less impressive than its marketing. Somewhere in the middle is a support org that knows what its AI is allowed to do and can prove somebody decided that on purpose.

Ready to run email automation you can document as well as deploy? Robylon AI resolves 60–80% of customer emails autonomously with AI agents that take action across Zendesk, Freshdesk, Shopify, Salesforce and 60+ other integrations. Start free at robylon.ai