Skip to main content
AI Governance

Microsoft's Supplier Requirements Put ISO 42001 on the Table for AI Suppliers

By Alfred Obeng, Founder, Goldline Consultancy

ISO 42001 Lead Implementer · ISO 42001 Lead Auditor · ISO 27001 Senior Lead Implementer · ISO 27001 Lead Auditor · CISSP · PMP

9 min read

Contents

    A supplier to a Microsoft business unit forwarded me a renewal pack earlier this year with one line highlighted. The commercial terms were unchanged. The data protection annex was not. Somewhere in the supplier requirements there was now a clause asking for ISO 42001 certification, and the renewal date was eleven weeks away.

    That is how most organisations discover this. Not from a strategy paper about the future of AI assurance, but from a contract renewal with a date on it.

    The requirement sits in Microsoft's Supplier Data Protection Requirements, the document that governs suppliers processing Microsoft personal data or Microsoft customer personal data under the Supplier Security and Privacy Assurance programme. It is worth reading carefully, because the obligation it creates is narrower than the panic it generates and harder than the reassurance that usually follows.

    What the requirements actually say

    The Supplier Data Protection Requirements is a single document that applies across Microsoft's supplier base wherever in-scope personal data is processed. Suppliers attest against it annually, and the attestation is a condition of continued engagement rather than a nice-to-have.

    Version 12 of the requirements is dated March 2026 and carries a dedicated AI section, Section K, running to a block of requirements covering AI risk assessment, transparency, monitoring, and AI incident response. That section is the substance of the change, and it is new obligation rather than restated security control.

    For suppliers in scope of Section K, the companion programme guide sets out independent assurance options: complete an independent assessment against Section K, or submit ISO/IEC 42001 certification. Either satisfies the assurance requirement. A supplier that has invested in a credible internal governance programme and can withstand third-party scrutiny of it does not necessarily need a certificate.

    What circulates in secondary commentary, and what I have not been able to confirm from Microsoft's published documents, is that a further category of Sensitive Use AI removes the independent assessment option and leaves ISO 42001 as the only route. That claim appears on advisory sites rather than in the public requirements or programme guide. It may reflect portal-only guidance or an assessor practice not visible in the published PDFs. Treat it as reported rather than established, and if it is being applied to you, ask your Microsoft contact to point to the source.

    That distinction matters, because most commentary collapses the whole thing into "Microsoft requires ISO 42001", which overstates the published position while understating how quickly the certificate is becoming the path of least resistance.

    Why Sensitive Use is worth understanding anyway

    Even where it is not the trigger for a hard certification requirement, the Sensitive Use concept shapes how Microsoft's own Responsible AI framework treats a system, and buyers apply the same logic when scoping supplier scrutiny.

    The classification is not about the technology. It is about consequence.

    Microsoft's Responsible AI framework treats a use as sensitive where the reasonably foreseeable use or misuse of the AI system could produce one of three outcomes.

    The first is a consequential impact on a person's legal position or life opportunities. This covers systems that influence access to employment, credit, housing, education, insurance, or a legal entitlement.

    The second is a risk of physical or psychological injury. This reaches health and safety contexts, clinical support, and systems whose failure could harm a person directly.

    The third is a threat to human rights. This is the broadest of the three and the one most often skipped over, and it reaches surveillance, biometric identification, and systems operating on vulnerable populations.

    The recurring examples are the ones to test yourself against: hiring and recruitment, credit and lending decisions, healthcare, and biometrics. If your product sits in any of those areas and touches Microsoft or Microsoft customer personal data, you should assume the heaviest reading applies until someone at Microsoft tells you otherwise in writing.

    The classification is not self-certified in a vacuum. Microsoft reserves the ability to determine how a supplier is treated, and in my experience the safer working assumption is the one that costs more.

    Who this catches

    The catchment is wider than the phrase "Microsoft supplier" suggests to most people.

    It reaches any organisation engaged under the Supplier Security and Privacy Assurance programme that processes Microsoft personal data or Microsoft customer personal data, and does so using AI. That includes software vendors selling into Microsoft, outsourced service providers, professional services firms operating on Microsoft data, and organisations delivering AI features into a Microsoft product or programme.

    Two patterns recur.

    The first is late discovery. Suppliers find the requirement in a renewal pack rather than in advance, because the supplier requirements document is updated on Microsoft's cycle rather than the supplier's. Nobody sends a warning eighteen months out. Given that a credible ISO 42001 implementation and certification cycle runs to several months, discovering the requirement at renewal is discovering it late.

    The second is scope confusion. A supplier concludes it is not caught because its AI feature is peripheral to the contract, and Microsoft's assessor takes a different view because the AI processes in-scope personal data. The question is not how central the AI is to your commercial proposition. It is whether AI is applied to the data.

    Why this matters beyond Microsoft, and why it may not

    It is tempting to present this as the leading edge of a wave. I would be cautious.

    As matters stand, Microsoft is the only major enterprise I am aware of that has published ISO 42001 certification as a supplier requirement in its standard data protection terms. Several large technology organisations have certified their own AI services to ISO 42001, and a number have published statements to that effect. Certifying yourself is a different act from requiring it of your supply chain, and conflating the two produces a claim about market direction that the evidence does not currently support.

    What can be said honestly is narrower and still significant. A very large enterprise buyer has decided that ISO 42001 is the instrument it will accept as evidence of governed AI in its supply chain for the highest-consequence uses. Supply chain requirements have historically propagated. ISO 27001 arrived in enterprise procurement by the same route. Whether AI governance follows the same path is a reasonable expectation rather than an established fact, and an organisation should make its decision on the Microsoft contract in front of it rather than on a forecast.

    What the evidence actually looks like

    Here is where most suppliers underestimate the work.

    The certificate is the entry ticket. It is not the answer. A Microsoft assessment of an AI supplier will typically want to see the certificate, the scope statement on the certificate, and then the substance behind it.

    The scope statement matters more than the certificate. A certificate scoped to a corporate function, or to a product line that is not the one delivering the Microsoft engagement, does not evidence governance of the system in question. I have seen scope statements that would not survive ten seconds of a buyer's attention.

    Behind the certificate, a supplier should expect to produce the AI system inventory entry for the relevant system, the impact assessment carried out for it, the documented human oversight arrangement, the record of testing carried out before deployment and the monitoring in operation since, the position on whether customer data is used to train or fine-tune models, and the named individual accountable for the system.

    The gap between holding a certificate and answering that set of questions is the gap that stalls deals. ISO 42001 requires an organisation to manage these things. It does not require the organisation to have packaged the outputs in a form a buyer can read. Those are different pieces of work, and only one of them is audited.

    What to do if you are caught by this

    Establish the classification first, in writing. Ask your Microsoft contact whether the engagement is treated as Sensitive Use. The answer determines whether you have one route or two, and it is worth the awkward email.

    If you have two routes, price both. An independent assessment of AI governance practices is faster and cheaper than a certification cycle, and for a supplier with a genuinely operating governance function it can be the right answer. It is also a route that will need repeating for the next buyer who asks, whereas a certificate travels.

    If you have one route, start counting backwards from the renewal date. A management system needs to be operating, not merely documented, before a certification body will complete a stage 2 audit. Work backwards from the certificate to the audit to the operating period to the implementation, and you will usually find that a renewal eleven weeks out is not achievable without a conversation with Microsoft about a remediation timeline. That conversation goes considerably better held early with a dated plan than late without one.

    Whichever route applies, build the evidence pack alongside the management system rather than after it. The artefacts a buyer asks for are largely derivable from the work you are doing anyway, and assembling them as you go costs a fraction of reconstructing them under questionnaire pressure.

    Source: Microsoft Supplier Data Protection Requirements, version 12, effective 30 March 2026. Microsoft updates this document periodically. Confirm the version in force against the current publication and against the terms in your own contract before acting on any summary of it, including this one.

    The questions worth asking Microsoft before you commit budget

    Suppliers tend to jump straight from discovery to procurement of a certification programme. There are four questions worth putting to your Microsoft contact first, in writing, because the answers change the shape of the response.

    Ask which classification applies to the engagement, and on what basis. If the answer is Sensitive Use, ask which of the three consequence tests is being applied, because that tells you how the assessor is reading your product and it occasionally reveals a misunderstanding you can correct.

    Ask what scope of certification would be accepted. A certificate scoped to the entity is broader and slower than one scoped to a product line, and if the narrower scope is acceptable the programme is materially shorter.

    Ask what evidence is expected alongside the certificate. Buyers vary in whether they want the certificate alone or the certificate plus the underlying artefacts, and building for the wrong expectation wastes a quarter.

    Ask what the position is for a supplier with a credible programme underway but no certificate at the attestation date. Microsoft's assessors deal with remediation timelines routinely. A dated plan with a certification body engaged is a different conversation from an intention.

    What this costs in time, not money

    The money varies with scope and organisation size and I am not going to invent a figure. The time is more predictable, and it is the constraint that actually bites.

    A certification body will want to see a management system that has been operating, not one that was documented last week. In practice that means the policy set, the AI inventory, the impact assessments, at least one internal audit and at least one management review need to have happened before a stage 2 audit is credible. Implementation itself is the shorter part for most organisations; the operating period and the certification body's own scheduling are the parts you cannot compress.

    Work backwards from your attestation or renewal date and add the certification body's lead time, which is not within your control and has been extending as demand for ISO 42001 audits grows. Organisations that discover the requirement with a full quarter in hand generally make it. Organisations that discover it with six weeks generally need the remediation conversation, and there is no shame in that provided it is held early.

    If your organisation is caught by a Sensitive Use classification and needs ISO 42001 in place against a contractual date, the ISO 42001 Sprint builds and certifies the management system on a defined timeline. See the programme.

    Last reviewed: August 2026.

    We use cookies and similar technologies to measure how this site is used, to see which organisations visit, and to measure our advertising. If you accept, we load Plausible, Google Analytics and Google Ads, Microsoft Clarity, which records session replays, and Apollo. Nothing loads until you accept. Read our Cookies policy.