ISO/IEC 42001: standing up an AI management system without drowning in it

You know, there is a very particular way that good intentions can just completely drown a team. Oh, absolutely. And I want you to picture this scenario, because, well, if you work in enterprise technology, you have probably lived some version of it.

Yeah, I'm sure they have. Right. So it's like 4.00 p.m. on a Friday, someone in executive leadership at your company has just returned from this massive tech conference, or maybe they just read a terrifying article about AI liability.

Always a dangerous combination. Exactly. And they hear that there is finally an international standard for governing artificial intelligence.

They hear it's certifiable by an accredited third party, you know, exactly the way ISO 27001 certifies information security. Right, which sounds great on paper. It does, and they think, perfect, this is the silver bullet.

This is going to reassure our enterprise customers, our regulators, the board of directors, literally everybody all at once. So the instruction comes down from on high in this really terse email, just get it certified. It truly is a tale as old as corporate governance itself.

I mean, the email is basically the starting gun for what usually becomes a massive self-inflicted wound. It really is. So you have this well-meaning project manager, or maybe a newly appointed head of AI governance who is, you know, really eager to prove their worth, and they open up the standard.

And what do they see? They look at this control framework, and they see dozens and dozens of requirements, subclauses, annexes, and what do they do? Because they are a good corporate citizen, they start a spreadsheet. Of course they do. The classic governance spreadsheet.

Exactly. They create a row for every single requirement they can find. And six months later, that spreadsheet has mutated into this 200-row monster.

Oh, easily 200 rows. Right. And you've got three different outside consulting firms billing by the hour just to tell them how to fill out the spreadsheet.

Cross-functional meetings are dragging on for hours. And the absolute worst part... Nobody actually knows what they're doing. Exactly.

Nobody can actually say which of those controls really matter for the two specific AI systems the company actively runs. And you know, we really have to look at the opportunity cost of that. Because crucially, the artificial intelligence itself hasn't been governed one single hour better than the day the project started.

Wow. Yeah, that's a great point. Right.

I mean, the engineers are still doing whatever they were doing. The data scientists are still pulling data from the exact same unvetted sources. The governance effort just became entirely disconnected from the operational reality.

Right. The team isn't being carried by this management system. They're actively drowning in it.

It becomes this paperwork exercise designed entirely to feed a spreadsheet. Exactly. But on the flip side, there is an equal and opposite failure that we have to name in the same breath here.

Some teams, especially in fast-moving startups or agile engineering departments, they sense how heavy this standard looks from the outside. Oh, yeah. They take one look at ISO-IEC 42001, see the word governance, and they just avoid it entirely.

Right. They view it as legacy enterprise friction. They think it's going to slow down their sprint cycles.

Which is a completely understandable fear. It is. So they decide they're just going to keep governing their AI on instinct.

We hire smart people, we'll be fine. They dodge the paperwork, they dodge the standard, and honestly, they feel great about it right up until the Tuesday afternoon when they lose a massive multi-million dollar enterprise contract. Because the buyer's procurement team demands an ISO 42001 certificate they simply don't have.

Exactly. Or worse. A regulator comes knocking and asks to see their systemic risk controls, and they have nothing to show.

Right. They chose dodging over drowning, but I mean, the end result is still a catastrophic failure of the business. Yeah.

So the skill we're unpacking today sits directly between those two extremes. It's about not drowning in the standard, but certainly not avoiding it either. It is about scoping it to fit your actual lived reality.

Okay, let's unpack this. Welcome to this deep dive into an executive education masterclass on right-sizing an AI management system. It's a critical topic.

It is. Our mission today is highly specific and, well, if you work anywhere near AI, highly urgent. We are treating the challenge of standing up an ISO IC 42001 AI management system without drowning in paperwork or bleeding out in consulting fees.

Which happens all the time. Constantly. So if you are a sharp, busy professional, whether you are prepping for a vendor risk meeting, leading a procurement team, or you're the person who just received that terrifying get a certified email from the CEO, this is for you.

Absolutely. We are going to be precise. We are going to be vivid.

And there will be zero villor. We are treating this like a strategy session, not a textbook reading. I love that.

And, you know, to execute on that, we cannot skip the foundational definition. Right. Let's start there.

Because the term AI management system or AMS, as you'll see it abbreviated, it's deceptively simple. It sounds like a product. It really does.

And that linguistic trap leads a lot of incredibly smart technical leaders down the wrong path immediately. I see this constantly. So let's establish the ground truth right now, and I want to make sure every listener internalizes this.

A management system is people and process, not software. Yes. This is the most critical paradigm shift a team has to make.

The word system in the tech world almost always implies software. You think of an operating system, a CRM, a database management system. Exactly.

Right. It sounds like something I can just license. Like, oh, our compliance is messy.

I'll just go buy the Enterprise AI Governance Suite 5000 from a SaaS vendor. I'll install it, give everyone a login, and boom, we'll be certified. And vendors absolutely lean into that misconception.

I mean, they will market their software as an AI management system. Of course they do. But an AI management system in the strict ISO vocabulary is the set of human policies, the defined roles, the accountability structures, the reporting lines, the processes, and the historical records through which an organization directs and controls artificial intelligence across its entire lifecycle.

So buying a massive enterprise governance software platform to try and pass this audit is like buying a $50,000 commercial oven and expecting it to earn you a Michelin star by itself. That is the perfect analogy. Right.

The management system is the recipes. It's the safety checks on the raw chicken. It's the sourcing of the ingredients.

And it's the rigorous training of the kitchen staff. It is not the shiny stainless steel appliance sitting in the corner. Spot on.

You cannot buy a software tool to instantly pass an ISO audit because the audit fundamentally checks human operations. Now, to be clear, governance tools and software platforms can absolutely help you keep your records straight. They're great for tracking who improved a model release or logging an evaluation metric.

They're useful tools. But buying a tool does not stand up a management system. The auditor from the certification body is there to check that human beings are actually operating the organizational machinery.

Wow. It's the machinery through which your executives decide what AI you will build and use, who is legally and operationally accountable for it, how you assess and treat risks, and how you keep improving when things go wrong. Okay, I want to push back a little here, representing the skeptical executive.

Because when you say human operations and organizational machinery, that sounds incredibly broad. It can sound that way, yeah. If I look at the landscape of AI governance right now, it is a total mess of acronyms.

There's the EU AI Act. There's the NIST AI risk management framework out of the U.S. There's this ISO 42001 standard. If I am sitting in the C-suite, my first question is, which one of these do we actually have to do? Because we only have budget to implement one.

That is the most common strategic question executives ask, and it reveals a fundamental category error. Oh, really? Yes. You do not choose between them.

They're not competing products on a shelf. They are entirely different types of instruments that stack on top of one another. Okay, interesting.

In the source material, they introduce this brilliant concept of the three-instrument stack to help you map your operations. A mature organization runs all three as distinct but integrated layers. Okay, let's break down this stack, starting from the bottom.

First, at the bottom of the stack, you have the floor. The floor is binding law. The primary, most mature example globally right now is the EU AI Act.

This is what you absolutely must achieve to operate legally in the European Union. And it has teeth. Oh, real teeth.

Penalties can go up to the higher of 35 million euros or 7% of a company's worldwide annual turnover for the worst breaches involving prohibited AI practices. Just to pause on that 7% global turnover, for a major multinational, that is a board-level existential threat. It's the floor.

You have to stand on it or you fall through and get sued into oblivion. Precisely. But here is the critical catch about the EU AI Act, or really any binding law.

It tells you what you must achieve. It mandates transparency. It mandates risk management for high-risk systems.

But it doesn't hand you a step-by-step, day-to-day operational method to actually do it. Right. It doesn't give you the instruction manual.

Exactly. And crucially for B2B companies, the EU AI Act doesn't give you a neat little badge to put on your website to prove to a buyer in Tokyo or New York that you are safe. Okay.

So the law is the floor. Moving up the stack, what is the next layer? Next you have the engine. The engine is the NIST AI Risk Management Framework.

The NIST AI RMF. I've heard a lot about this one. Yeah.

It's a voluntary, continuous method. It is a cycle built around four core functions. Govern, map, measure, and manage.

You point this engine at any operational problem to actually run risk management day-to-day. It tells your engineers how to map a system's context, how to measure its accuracy and bias, and how to manage those risks over time. That sounds incredibly useful.

It is fantastic. It's rigorous, it's highly respected by engineers, and it's completely free to download. But I sense a massive but coming here.

But nobody can audit you against the NIST framework in a formalized, internationally recognized way and hand you a certificate. There is no such thing as an accredited NIST certified badge that a customer's procurement team can definitively rely on. It is an internal engine.

Which brings us to the top layer of the stack. Yeah. ISO-IS 42001 is the certifiable shell.

Exactly. ISO-IS 42001 is the certifiable shell. So just to clarify for the listener, like NIST, ISO-IS 42001 is voluntary.

No government regulator is going to fine you 35 million euros simply for not having an ISO certificate on your wall. Correct. But it is structured differently than NIST.

It's structured like ISO-IS 27001 for information security or ISO-IS 9001 for quality management. Right. And because of that specific formal structure, an accredited certification body can audit your organization and issue a certificate that buyers, partners, and boards of directors already know exactly how to read.

They understand the language of ISO. This is such a critical distinction for a business leader to understand. The law sets the floor, NIST turns the engine.

ISO puts a certifiable frame around the whole thing. Perfectly said. So when a large enterprise customer's procurement team asks, how do we know your AI is governed responsibly, handing them a 50-page PDF of your NIST mapping might just totally overwhelm them.

It absolutely will. But handing them an ISO-42001 certificate is an answer they can verify instantly without just having to trust your marketing brochure. Yes.

And we really need to emphasize what that word certifiable actually buys you because it's an expensive process. What you are buying is external verifiable trust, but only, and this is a massive only that catches a lot of companies off guard, only if the certification body is actually accredited. Yes.

Let's talk about this because there is a lot of confident-sounding nonsense out there right now. You see startups everywhere claiming they are. Like ISO-42001 aligned.

Aligned is purely a marketing word. A self-declared aligned claim carries absolutely none of the independent verification that makes the standard worth anything. I mean, I can say my driving is aligned with Formula One standards.

It doesn't mean you should let me drive a race car. That's a great way to put it. Furthermore, even if a company claims to be certified, if there is no accredited body behind it, it's virtually meaningless.

Wait, how can you be certified by an unaccredited body? Isn't that an oxymoron? It happens all the time in emerging standards. A consulting firm will say, pay us, we'll audit you and we'll give you a certificate we printed ourselves. Oh wow.

But true, accredited certification relies on a chain of trust. An independent certification body like a Shellman, a BSI, or a TUV must itself be overseen and audited by a national accreditation authority like UKs in the UK or ANA in the United States. So they audit the auditors.

Exactly. That national body ensures the auditor is actually competent to audit AI. So the certification body stakes its own credibility and its own accreditation on having audited your organization honestly.

I see. That unbroken chain of trust from national authority to certification body to your organization is what a procurement team is actually buying when they accept your certificate. Okay, so to build this certifiable shell, to build the people and processes, the recipes and the kitchen staff, we need a structure.

We need to know what the walls and the floors of this shell actually look like before the auditor shows up. Exactly. And the standard doesn't just leave you guessing.

It provides a very rigid battle-tested skeleton. It is deliberately built on the same skeleton as every other modern ISO management system standard. Internally in the standards world, it's called the harmonized structure.

You might also hear veteran auditors call it the high-level structure or Annex SL. Let me stop you there because as someone who has sat through tech compliance audits, I hear rigid battle-tested skeleton and I immediately think massive inflexible bureaucracy. Sure.

Is this going to require a company to invent a whole new operational language? That is the beauty of the harmonized structure. If your company has ever been through an ISO 27001 audit for data security, which almost every B2B SaaS company has, you already speak this language. Oh really? Yes.

The seven clauses that make up the core management system in 42001 are the exact same skeleton as 27001 and 9001. So we need to state this explicitly. The seven clauses are the same skeleton as ISO 27001 and 9001.

The exact same skeleton. There are seven management clauses, numbered four through ten, that every one of these standards shares. Let's look at how they work in the real world because this is the actual operating system you are installing in your company.

To make this concrete, let's bring in a scenario from our source material. There's this fantastic immersive case study about a fictional mid-sized tech company called Cedar Line Analytics. Yeah, that's a great example to use.

Let's follow their governance lead, a guy named Marshall, as he builds this skeleton. Because Marshall is the guy who got that Friday afternoon get-us-certified email from his CEO. Perfect.

Let's walk Marshall through the clauses. Clause four is context of the organization. This is about defining who you are, what you do with AI, and who your interested parties are, meaning customers, regulators, affected people, your staff.

But most critically, clause four is where Marshall must define the scope. The scope is the exact boundary of what the management system covers. So if an auditor is looking at clause four, the blunt question they're going to ask is, what does this management system cover and why did you draw the boundary there? Precisely.

Now Cedar Line Analytics sells two external AI products, a document summarizing assistant used by corporate law firms and a high-risk hiring screening model that ranks job applicants for HR departments. But they also have an internal AI tool, their marketing team, built to draft blog posts. If Marshall is a panic novice, what does he do with the scope? The panic novice says, the CEO said get certified, so we are certifying all AI at Cedar Line.

Oh no. Yeah. He draws a massive company-wide scope boundary.

He includes the hiring model, the document summarizer, the internal marketing tool, and probably some random experimental shadow IT that a developer built over the weekend. And what happens to that panic novice? He drowns. He has just committed his tiny governance team to maintaining flawless operating records, continuous risk assessments, and rigorous internal audits on tools that the company's customers don't even care about.

That sounds exhausting. It is. The internal marketing tool poses virtually zero business risk, but by putting it in scope, it now requires the same heavy governance machinery as the high-risk HR product.

But Marshall isn't a novice, he's sharp. How does he handle Clause 4 context? Marshall draws a tight maintainable boundary. He explicitly bounds the scope to the two customer-facing products, the document summarizer and the hiring screening model.

He names a specific AI product development team and the two physical office locations where they work. He explicitly excludes the internal marketing tool. His justification to the auditor is bulletproof.

This scope covers the AI services our customers depend on, size, so our team can realistically keep the evidence current. That is a masterful execution of Clause 4. It's bounded reality. I love it.

Okay, moving to Clause 5, leadership. Clause 5 requires top management commitment, and the auditor isn't just looking for an executive who sent an email. You need an AI policy, and you need clearly assigned roles and accountability.

This isn't about vague promises that we care about AI safety, it's about naming a human being who is accountable for the system. The auditor's blunt question here is, who is the single accountable owner and where is the signed policy? And there's a phenomenal pro tip from our executive guide here regarding that policy document. Marshall doesn't let his legal team draft a 50-page manifesto.

He writes a policy that is exactly five sentences long. A 50-page policy is a compliance artifact that nobody reads, which means nobody follows it, which means an auditor will eventually find you in breach of your own rules. Exactly.

A five-sentence policy is an operational tool. It simply states what we will and will not use AI for, who holds ultimate accountability, how we commit to assessing risks, how employees can raise concerns without retaliation, and a commitment to continually improve the system. Done.

Signed by the CEO. That is right-sizing in action. Next is Clause 6, planning.

This is the critical juncture. Planning is where you figure out how you identify and treat AI risks and opportunities and how you set objectives. This is really the AI-specific heart of the standard skeleton because this is where Marshall must execute his AI risk assessment and his AI system impact assessment.

The auditor asks, show me your AI risk assessment and show me the impact assessment for your riskiest system. And we're going to dive incredibly deep into the difference between those two assessments in just a moment because conflating them is a massive trap. It really is.

But let's finish the skeleton first. Clause 7 is support. Support covers the resources, the competence, the awareness, the communication, and the documented information that keep the system alive.

So training and documentation. Exactly. Marshall has to prove that the people building the hiring model actually have the competence to do so and that everyone knows what the five-sentence policy is.

Clause 8 is operation. This is where the rubber meets the road. Right.

Clause 8 is actually doing it. It's running the risk assessments you planned in Clause 6 and controlling the AI lifecycle and practice. The auditor wants to see the system being governed in reality.

They want to see the date stamps on the model evaluation reports. They don't just want to read your beautiful procedures in a binder. They want to see your engineers actually following them on a Tuesday afternoon.

Clause 9 is performance evaluation. Monitoring, measurement, internal audit, and management review. This is you checking that the system actually works.

The auditor's question is incredibly blunt. Where is the report from your internal audit and where are the signed minutes from your management review with the CEO? If Marshall doesn't have those two documents, the audit is over before it begins. And finally, Clause 10, improvement.

Clause 10 is handling non-conformities and continually improving. It's fixing what the checks in Clause 9 found, the auditor asks. When your internal audit inevitably found a problem, what process did you actually change to fix it? Now, you look at these clauses 4 through 10, and for anyone who has studied process engineering or manufacturing quality, a very distinct pattern emerges here.

It's unmistakable. These clauses map perfectly onto a foundational management concept called PDCA. Plan, do, check, act.

Oh, yes. It's a continuous loop pioneered by W. Edwards Deming. Clauses 4 through 7, context, leadership, planning, and support, that entire block is the plan phase.

You are setting up the rules. Clause 8, operation is do. Clause 9, performance evaluation is check.

And Clause 10, improvement is act. Plan, do, check, act. It is not a project plan with a finish line.

It's an operating system that runs continuously forever, which, if we think back to our stack, rhymes perfectly with the NIST framework's govern, map, measure, manage loop. They rhyme on purpose. As we said, ISO 42001 gives you the certifiable shell with its plan, do, check, act clauses, and you can run those NIST functions as the risk engine continuously turning inside it.

I want to revisit a strategic question I hinted at earlier, because this is where a lot of companies can save a fortune. If an organization, let's say Cedar Line Analytics, already holds ISO 27001 for information security, which is practically table stakes for SaaS companies today, aren't they basically halfway to ISO 42001? Essentially, yes. Because they already do plan, do, check, act for data security.

It sounds like we aren't building a new house from scratch. We're just adding a new AI wing to a building we already own. That is exactly right.

And it is a massive strategic and financial advantage. Because both standards use that harmonized structure, the bureaucratic machinery is already running. The mechanism for Clause 4, context, Clause 5, leadership, Clause 9, internal audit, and Clause 10, improvement, Cedar Line already has that muscle memory.

Marshall already has a rhythm for getting the CEO to sit down for a management review. They already know how to write a corrective action plan for a nonconformity. So Marshall doesn't have to invent a whole new bureaucracy just for AI.

Exactly. He integrates. He just adds the AI specific pieces onto the existing machinery.

He adds the AI impact assessment into the Clause 6 planning cycle. He adds the AI lifecycle controls into Clause 8 operations. It makes reaching ISO 42001 significantly cheaper, faster, and less disruptive for a 27001 shop.

That makes total sense. The shared skeleton is the payoff for all the hard work they did on security. Okay.

So that seven-clause skeleton tells us how to run the management system. It's the bureaucracy, the PDCA loop. But it doesn't actually tell us what specific technical and operational safeguards we need to put around our AI system.

That's right. The skeleton doesn't mention data provenance or hallucination risks or human oversight. Where does the actual AI-specific governance live? That brings us to Annex A, the menu.

The menu. Let's dive into this because this is where the spreadsheet monsters are born. Annex A is the catalog of AI-specific controls attached to the standard.

It is broken down into nine overarching control objectives, and beneath those objectives, there are 38 specific controls in total. I want to understand what these controls actually look like in practice. Let's look at a few of these nine objectives, not as a dry list, but as operational realities for Marshall at Cedarline.

Okay. Let's look at the objective for resources for AI systems. This objective demands that you control the data, the tooling, the compute, and the human competence your AI relies on.

Right. In a spreadsheet mindset, a PM might try to write a new resource tracking policy document. But Marshall, Marshall knows they already maintain an AI systems inventory that tracks what models they use, what compute they run on, and who the lead engineer is.

He just maps that existing inventory artifact directly to the resources control. That's brilliant. What about the objective for AI system lifecycle? That governs everything from design through testing to final decommissioning.

If you have an engineering team building an AI product, they are already writing evaluation reports. Yeah. That's standard engineering practice.

Right. They are running benchmarks. They are logging test prompts.

Marshall takes those existing engineering evaluation reports and uses them as the evidence for the lifecycle controls. Let's touch on data for AI systems. This covers data provenance, data quality, and how you handle training data.

If Cedarline's data engineering team has built a data provenance file detailing exactly where they scraped their training data for the HR model and how they filtered it for PII, Marshall points that file directly at this objective. And then there's the objective for use of AI systems, which includes responsible operation and human oversight. Right.

If you have a customer service chatbot, do you have logs showing when a human agent overrode the AI? Those override logs live here. Okay. So those are examples of the objectives containing those 38 specific controls.

Now, I need every listener to pay close attention because we are about to state the single most important fact in this entire deep dive. I know exactly what you're going to say. This is the truth that separates a team that gets certified gracefully from a team that drowns in a 200-row spreadsheet of terror.

Say it with me. You do not implement all 38 controls. I'm going to repeat that.

You do not implement all 38 controls. ISOAE 42001 is fundamentally a risk-based standard. Annex A is a menu.

It is not a mandatory checklist. The fastest, most guaranteed way to drown your organization is to treat it as a checklist and try to force your engineering team to implement every single one. I mean, if you treat a restaurant menu as a checklist, you order all the food, you bankrupt yourself, you can't possibly eat it all, and it's disaster.

You have to order what you actually need. Exactly. What you actually do is run your AI risk assessment first back in Clause 6. You look at your specific scope, then you read through Annex A and you select only the controls that treat the risks you actually identified.

Okay. That makes sense. Now, in reality, it's a bit of an iterative back-and-forth process.

Reading the menu of controls often makes you realize you missed a risk in your initial assessment. You might be reading Annex A, see the control for vendor management, and suddenly realize, oh, no, we never actually assessed the risk of our cloud AI provider changing their model weights without telling us. Wow.

That back-and-forth between the risk assessment and the control menu is totally normal. But the core principle remains absolute. You only pick the controls your risk demands.

Let's illustrate this deeply with one of the most misunderstood objectives, third-party and customer relationships. Imagine a different company for a moment, a massive Midwestern insurance company. Sure.

They don't have a single machine learning engineer on staff. They only buy AI. They buy HR sales products with AI built in.

They use Microsoft Copilot. But they never, ever build or train their own foundational models. If they treat Annex A like a checklist, what happens? If they treat it like a checklist, they will spend months trying to figure out how to implement controls around foundational model training data provenance when they don't even have access to that data.

That's crazy. It's madness. Instead, they should look at those development controls, mark them not applicable, and state exactly why.

Our organization does not develop or train AI models. But on the flip side, what controls do they pick? For an organization that only buys AI, that third-party relationship control becomes the most load-bearing pillar of their entire management system. Oh, because they're relying on vendors for everything.

Exactly. Their actual tangible business risk lives entirely in what their external suppliers do. So their ISO 42001 management system is going to lean heavily into vendor governance.

They will implement rigorous controls requiring impact assessments from their suppliers. They will demand contractual audit rights. Right-sizing the standard doesn't mean shrinking the job to nothing.

It means shifting the weight to the controls that actually matter for how your specific organization interacts with AI. Wait, let me ask a highly skeptical business question here. Let's say I am a procurement officer at a Fortune 500 company.

A vendor hands me their ISO documentation, and I see they excluded a bunch of controls. They skipped 12 out of the 38. Okay.

Doesn't that make them look lazy? Doesn't that make them look unsecure compared to their competitor who promises me they implemented all 38? This is a fantastic question. And the answer is highly counterintuitive for beginners, but universally understood by veteran auditors. Oh, really? Yes.

An honest, justified exclusion actually demonstrates a mature, sophisticated understanding of a company's actual risk profile. How so? If a vendor says, control X regarding automated decision-making is not applicable because our InScope systems are purely advisory and cannot execute decisions without a human, an auditor or a smart enterprise procurement officer reads that as high competence. It proves they actually did the deep, risk-based thinking.

And the vendor claiming to do all 38. A vendor who hands you a matrix where every single control is marked applicable with no exclusions and no nuanced justifications is waving a massive red flag. Really? It almost certainly proves that no risk-based thinking happened at all.

It means they just checked all the boxes to look thorough for the marketing brochure. Wow. And when an accredited auditor looks at that, they are going to ask for the operational evidence for all 38 controls.

The vendor won't have it. They will find massive gaping holes in the evidence and the vendor will fail the audit. An honest not applicable with a one-line operational reason is infinitely stronger than an unevidenced applicable.

This is a perfect transition. If I am Marshall at Cedarline and I've figured out my scope, run my risk assessment and pick my specific controls off the annex A menu, how do I actually prove to the auditor which ones I picked and which ones I skipped? Where does that live? We have to write it down in one central undeniable document. That brings us to the spine of the entire system, the statement of applicability.

The statement of applicability, usually abbreviated as the SOA. We need to state explicitly, the statement of applicability is the spine. It is the spine and it is almost always the very first document an external auditor asks to read.

Before they look at your code, before they look at your policies, they ask for the SOA. So what exactly is it mechanically? Mechanically, it is a highly structured document, often a spreadsheet or a table in a governance tool that lists all 38 controls from annex A. Next to each control, you must make a binary declaration. You mark it as applicable or not applicable and next to that declaration, you must provide a concise justification and crucially, a link to the evidence that proves it.

Let's dive deep into the mechanics of this because this is where the rubber meets the road for the project manager. We established that an unevidenced applicable is a disaster, a total disaster. If you mark a control as applicable, you better have a hyperlink to a real artifact, a policy, a log, an inventory in your company's files.

But let's look at a realistic scenario for Marshall. He runs his risk assessment. He realizes that a specific control for monitoring model drift is highly applicable to his HR screening system.

But because they are a startup, they haven't actually built the automated drift monitoring yet. He's doing the gap analysis and realizes, uh-oh, we absolutely need this control but we have zero evidence for it today. Does he mark it not applicable just to hide it from the auditor until next year? Never.

Never hide it. Really? If you have an applicable control but no evidence yet, the defensible mature move is to mark it GAP in capital letters right there in the SO. Just literally write GAP.

Yes. Marking it GAP converts the problem from a hidden failure into a visible, manageable, dated to-do list. I see.

In this scenario, it shows the auditor and your own executive leadership that you possess profound self-knowledge. You know exactly where your system is weak or incomplete and because of the PDCA loop, you can create a formalized corrective action plan to close that gap before the stage two audit happens. A board of directors or an external auditor trusts an organization that names and tracks its own gaps far more than an organization whose statement of applicability looks suspiciously perfect.

Here is where this process gets really fascinating, especially for teams who are terrified of drowning in paperwork. Our source material emphasizes a golden rule for the evidence linking in your statement of applicability. Reuse.

Do not rewrite. I cannot overstate the importance of this rule. You do not need to write 38 fresh, pristine, heavily formatted ISO documents for the auditor.

Right. If you sit down and try to write 38 new policies from scratch, you will drown, your engineers will revolt, and you will fail. You must reuse the artifacts your business already naturally generates.

Give me some concrete examples of reuse. We touched on this earlier, but let's formalize it for the SOA. If your IT department maintains an AI systems inventory in JIRA or a spreadsheet, you link that directly to the resources control in the SOA.

Boom. Done. Easy.

If your engineers write a technical evaluation report before pushing a model to production, that satisfies the performance evaluation and lifecycle controls. You link to the engineering wiki. You do not ask the engineer to copy-paste their work into a new ISO compliance form 4B.

Why is rewriting so dangerous beyond just being a waste of time? Because it creates conflicting organizational realities. If you rewrite things for the audit, you end up with the audit version of reality in a binder and the engineering version of reality in GitHub. Oh, and they'll drift apart.

Exactly. And when those two versions inevitably drift apart because the engineers updated the model but forgot to update the ISO binder, an auditor is going to catch the contradiction immediately. Right-sizing an AI management system is largely the strategic act of pointing your existing operational artifacts at the clauses they already satisfy.

So to summarize the framework so far, the NXA controls are the menu, our risk assessment is what we decide to order, and the statement of applicability is the receipt we show the auditor. That is the perfect analogy. A complete stranger should be able to read that receipt and understand exactly how you govern your AI, what you care about, and what you chose to ignore.

But there is one item on that menu that you absolutely cannot skip, ignore, or mark not applicable if your system affects human beings in any meaningful way. This brings us to the most critical component of the entire standard, section 5, the center, the impact assessment. We need to state this explicitly and unequivocally.

The impact assessment is central, not optional. This is where we need to clear up a massive point of confusion because the terminology in the industry is a mess. People hear AI risk assessment in clause 6, and then they hear AI system impact assessment in NXA, and they think, oh, that's just a duplicate requirement, I'll just do one form and call it a day.

They are related concepts, but they do entirely different jobs. Conflating them weakens your entire management system and will almost certainly trigger a major nonconformity during an audit. Break down the difference for us.

The AI risk assessment, which lives up in the clause 6 planning phase, looks inward. It looks at the risks an AI system poses to the organization itself and its business objectives. So like financial risk.

Financial risk, reputational risk, intellectual property leakage, operational downtime. That inward looking business risk assessment is what drives which NXA controls you select. So the risk assessment says, if our AI cloud provider goes down, we breach our SLAs and lose a million dollars a day.

That is an inward risk to the company. Exactly. The AI system impact assessment, on the other hand, looks outward.

It looks at the specific effects and potential harms of your AI system on individuals, on demographic groups, and on society at large. This is the standards version of fundamental rights thinking. It is so critical to the architecture of global AI governance that ISO actually published a completely separate dedicated guidance standard just to explain how to do it.

ISO IEC 42005, which is coming out in 2025. Yes. For any system categorized as high risk, the impact assessment is the single control an auditor is going to probe the hardest and the deepest.

If you only run an inward facing risk assessment, if you only document your financial and reputational risks and you try to pass that off to the external auditor as your impact assessment, you have completely skipped the outward facing analysis that the standard cares about most. You will fail that control instantly. Let's make this highly concrete.

What does an impact assessment actually look like? What questions is Marshall answering when he does one for Cedar Line? The impact assessment answers a very specific, rigorous set of plain English questions. First, what does the system do and what does it actually decide or influence? Okay. Second, who does it affect? And crucially, this includes stakeholders who are not your direct customer.

That's a big distinction. Third, what is the worst realistic harm to those people if the system functions incorrectly or is misused? Is it a wrongful denial of financial services? A discriminatory ranking? A massive privacy exposure? Fourth, how likely is that harm and how severe is the impact? Fifth, what specific technical or human safeguards exist like human in the loop oversay or clear contestation paths for the affected user? And finally, what is the residual risk that remains after those safeguards are in place and which executives signed off to accept it? Those questions force a company to look at the human cost of their technology, not just the financial upside. And note the reuse principle here again.

If your organization operates in Europe and has already prepared a conformity file to comply with the EU AI Act, you have already done this fundamental rights thinking. Yes, absolutely. You aren't starting from zero for the ISO audit.

You were just formatting that existing deep analysis into the structural shape the ISO standard expects in the SOA. Exactly. Now, let me play devil's advocate for a second because I can hear a startup founder listening to this right now saying, isn't assessing the impact on society a bit abstract and grandiose for a midsize B2B company? We just sell SAWS workflow tools to HR departments.

We aren't altering the fabric of society. This is a very common objection. Society sounds grand, but the harms are intensely local, highly specific and legally actionable.

Give us an example. Let's ground this with Marshall at Cedar Line Analytics. Remember, one of the two products in his scope is a hiring screening model.

It reads resumes and ranks job applicants for corporate HR departments. Which is a very common, highly lucrative B2B product today. Right.

Is it abstract to say that this specific model might rank applicants in a way that disadvantages a protected demographic group based on historical training data? Not at all. No. That is a highly concrete, discriminatory outcome affecting real individuals.

If that system is biased, a real human being doesn't get a job interview to pay their mortgage. That is the exact outward harm the auditor will look for. The impact assessment for Marshall's hiring model would center entirely on that discrimination risk.

It would document the evidence that the model was rigorously tested for bias before release. And it would mandate the human oversight that must exist, for example, requiring a human HR professional to review the context before any applicant is formally rejected based solely on the AI's low score. It's not abstract at all when you put it like that.

It's the difference between a defensible, trusted product and a massive class-action discrimination lawsuit that destroys the company. Precisely. Which is exactly why the impact assessment is the center of gravity for the entire standard.

Okay, so let's summarize where Marshall is at. He has a bounded intelligence scope that focuses on his two core products. He has his statement of applicability with justified inclusions, exclusions, and g-gays.

And he has a rigorous outward-facing impact assessment for his high-risk HR system. He's in good shape. But having the documents isn't the same as having the certificate.

How do we actually get the piece of paper on a wall without failing the audit? Let's walk through section six, the journey. Getting certified is a journey with five distinct sequential stages. Knowing these stages is what lets a leader plan the work practically rather than fearing it.

Stage one, the GAF analysis. What is Marshall actually doing here? Before he builds a single new process, Marshall compares what Cedarline already does against what the ISO standard asks for. He looks at their existing engineering evaluation reports, their data policies, their security access controls, and maps them to the seven clauses and the annex A controls.

And what's the output of that? His output here is not a 200-row spreadsheet of terror. It is a highly targeted shortlist of real operational gaps. These become the GPs in his statement of applicability.

Also, this is the exact moment he needs to choose his accredited certification body and sign the contract. Wait, why do it now in stage one before the documentation is even finished? Why not wait until they are ready? Because a certification body's own scope of accreditation can legally constrain what they are actually allowed to audit. Oh, I haven't thought of that.

You need to confirm early on that the specific auditing firm is accredited by their national authority to certify your specific industry sector and AI system type. You do not want to spend six months prepping only to call an auditor and find out they aren't legally permitted to issue a certificate for an HR AI product. That is a critical operational tip.

Stage two, build the missing pieces. This is where Marshall closes the specific gaps he found in stage one, and only those gaps. If his gap analysis found five missing items, he builds five items.

Usually this means formalizing that five-sentence AI policy, perhaps formalizing the risk assessment methodology, and completing the impact assessment for the hiring system. Makes sense. If Marshall had skipped stage one and just tried to build all 38 controls from scratch, this is the stage where he would have drowned.

Stage three, run the system to generate records. This feels like the biggest trap for executives who want things done yesterday. I can't just hire an expensive consulting firm to write all my perfect policies in October and get the certificate on November 1st.

Absolutely not. A management system cannot be certified on the date it's written. Why not? The external auditor doesn't just want to see your beautiful, freshly printed policy documents.

They need undeniable evidence that the system is actually operating in reality. That means the system must run for a period of time, usually a few months, generating real dated historical records. Risk assessments actually performed and signed off.

Impact assessments completed for new product features. System monitoring results logged. And there are two specific bureaucratic activities in Clause 9 that companies always forget to do during this run phase.

Yes, the internal audit and the management review. This is the check phase of Plan to Check Act. What? Before the external auditor ever arrives at your office, you must conduct an internal audit, having someone independent within your company check your own work to see if the system is functioning.

And you must conduct a formal management review, where top leadership, the CEO, formally looks at the system's performance metrics and decides what resources need to be improved. And if you skip those? Skipping the internal audit and the management review is the fastest, most common way a well-documented system outright fails its external audit. A polished binder with zero operating records is a dead system.

Stage 4. The two-stage external audit. Let's clarify this because earlier we mentioned a stage 2 audit and we need to define what that actually means. Certification audits always happen in two distinct stages, usually separated by a few weeks.

Stage 1 is essentially a high-level review of your documentation and readiness. So they just look at the paperwork? Yes, the auditor looks at your scope definition, your five-sentence policy, and your statement of applicability. They are checking if the design of your system makes sense.

If you have a clean scope and an honest OA, stage 1 is short and smooth. Stage 2 is the main event. Stage 2 is where they start digging.

Exactly. In stage 2, the auditor checks that the system is actually operating precisely as you documented it. They do this through evidence sampling and deep interviews with your staff.

If your policy says all models are tested for bias, they will ask an engineer, show me the bias test logs from last Tuesday. And if they find something wrong, if the engineer says, oh, we skipped it last Tuesday because we were rushing a release, do you just fail instantly and go home in disgrace? No. This is a huge misconception.

Audit findings are called nonconformities, and finding them is completely normal. OK, good to know. A major nonconformity means the system is fundamentally failing a core requirement, like completely missing an impact assessment.

You have to fix a major nonconformity before the certificate can be issued. And a minor one. A minor nonconformity is a smaller, isolated lapse, like one missing signature on a log.

You address a minor nonconformity by creating a formalized corrective action plan, showing how you will fix the root cause, and the certificate can usually proceed. In fact, an auditor who looks at a system and finds zero nonconformities is often suspicious. A system that never surfaces an error is usually a system that is being hidden, not governed.

And finally, stage 5, keep it alive. Getting the certificate is not the finish line. You have surveillance audits in the intervening years before your formal recertification.

A certificate is usually on a three-year cycle, with lighter surveillance audits every year. So it never really stops. Right.

Organizations that treat the certificate as a one-and-done project let the system decay the day the auditor leaves, and they struggle massively and often lose their certificate at their first surveillance audit. The companies that treat it as a running operating system, the PDCA loop, sail right through. OK, let's look at how this plays out in the wider industry.

Section 7, Real-World Applications and Common Mistakes We've talked a lot about Marshall and our fictional feeder line analytics, but this pattern is playing out at the absolute highest levels of the tech industry right now. Our sources highlight Anthropic's January 2025 ISO 42001 certification as the anchor real-world example of this exact philosophy. Yes.

Anthropic, one of the premier frontier AI labs in the world, was certified by Shellman, a highly respected accredited certification body, in January 2025. And if you look closely at how they architected their certification, it perfectly mirrors the best practices we've discussed. How so? They didn't claim a grandiose scope certifying everything the company does.

The certificate is tightly scoped to define AI research, development and services roles, and specific office locations. A bounded scope is a sign of operational maturity. Exactly.

Importantly, they built their certifiable shell on the foundation of the deep governance work they already had, like their famous responsible scaling policy and their rigorous safety evaluations. They didn't throw out their engineering culture to create a fresh paperwork project. They mapped their existing reality to the standard.

But not everyone does it with that level of integrity. We have to talk about the most deceptive practice in the industry right now. Yeah.

The shell game mistake. Ah, the shell game. This is the dark side of soaping.

Yeah. This happens when a vendor deliberately scopes their AI management system to an internal, highly isolated, low-risk tool. Maybe that internal marketing copywriter tool we mentioned at Cedarline.

Right. They get that tiny, irrelevant system certified easily because it has no risk. And then they plaster the ISO 42001 certified logo all over their company homepage and their enterprise sales decks, heavily implying to buyers that their flagship, high-risk, customer-facing product is covered by the certification.

It's incredibly deceptive. It'd be like hiring a security guard who only watches the basement broom closet, but then putting a sign on the front door claiming the entire bank is secured by armed guards. That is exactly what it is.

And it destroys trust entirely when it's discovered. An informed enterprise customer will ask to read the actual scope statement printed on the certificate. They will see that the flagship product they're buying is completely outside the boundary, and they will instantly trust that vendor less, not more.

Wow. Scope is a truth statement. Certifying the wrong boundary just to get a logo and implying a wider one is a fundamental governance failure.

The standards own transparency mechanism. The fact that the specific scope must be published right on the certificate itself is specifically designed to expose this exact shell game. So for the enterprise leaders listening to this who are on the buying side, evaluating vendors, how do we read a vendor certificate so we don't fall for the shell game? You must check three critical things every single time.

One, look at the issuing body's logo. Are they actually accredited by a recognized national authority? If not, the certificate is just a piece of paper. Okay, accreditation.

Two, read the scope statement carefully. Does it actually cover the specific AI product or service your company is buying? That's the scope. Three, check the dates.

Is the certificate current and valid? Certificates operate on a strict cycle. An expired certificate means the management system died and the auditor walked away. Check the accreditation.

Check the scope. Check the date. Simple but incredibly powerful.

Now there's one more ISO document mentioned in the sources that we have to bring up before we close because it solves a very specific, very annoying internal corporate argument. It's ISO-IEC-22989. We call it the standard underneath the standard.

Yes, ISO-IEC-22989 is the AI concepts and terminology standard. It doesn't tell you how to govern or audit anything. It simply settles at an international level what the words actually mean, what technically counts as an AI system.

What is a machine learning model? What exactly is inference? Why do we care about an international dictionary? Because terminology disputes cost serious time and money and they derail governance projects. If you roll out an AI policy, you will inevitably see a business unit pushback. A product manager will insist that their new predictive scoring feature is not really AI.

They'll claim it's just advanced statistics or a rules engine and therefore they argue they don't have to put it in the AI inventory and it's magically exempt from all the governance rules. I see. Or conversely, a vendor will call their product cutting edge AI in the sales pitch to justify the price.

But when your legal team asks them to sign the AI liability clauses, suddenly they say, oh, it's just a statistical tool. Oh, I have seen that exact pivot in vendor negotiations. It's infuriating.

When definitions are contested internally or externally, pointing to a neutral, internationally recognized vocabulary standard like 2D989 ends the argument instantly. You don't need to study it cover to cover. You just keep it in your back pocket.

You cite it when a conversation turns into a semantic turf war designed to avoid governance. It removes the emotion from the definition. That is an incredibly practical tool.

Okay. We have covered an immense amount of ground today, from the core philosophy to the deepest mechanics of the audit. Let's bring all this home for the listener.

If we summarize the critical path to success, it comes down to a few unshakable principles. Scope honestly and draw a tight, maintainable boundary. Understand that the statement of applicability is your spine and use it to justify every single inclusion and exclusion.

Center the outward facing impact assessment for any system that affects human beings. Right. Generate real dated operating records, especially your internal audits and management reviews.

And above all, reuse the operational artifacts your company already relies on instead of starting from scratch to build a shadow bureaucracy. That is how you stand up an AI management system without drowning in it. But before we sign off, I want to leave you with a preview of where this entire field is heading.

Because we've been talking about ISO 42001 as a globally neutral standard. The standards framework is the exact same in Toronto and Bangalore in Berlin or in Silicon Valley, but the binding laws surrounding it are absolutely not neutral. This is the massive rooming challenge for multinational companies.

We are looking at wildly divergent legal rules globally. You have China implementing strict mandatory labeling for AI generated content. You have the UK deliberately choosing a pro innovation stance with no comprehensive AI statute at all right now.

And you have the EU AI Act sitting in the middle with heavy fundamental rights mandates and massive fines. Soon, this unified ISO management system you are building today is going to have to absorb all of those divergent, conflicting legal rules. A single certifiable shell is going to have to hold divergent global truths, applying completely different technical controls and transparency procedures depending on which specific market a software feature is shipping to.

Exactly. The standard itself won't break. It's designed to handle this, but your scope definitions and your impact assessments will have to flex to absorb those highly localized legal realities.

Which is exactly why building a maintainable, right-sized, honest shell today is so critical. If your system is a bloated, 200-row spreadsheet built by a consultant who didn't understand your engineering culture, it will shatter under its own weight the moment it has to handle cross-border legal divergence. A tight, honest, natively integrated system can adapt to anything the regulators throw at it.

So what does this all mean for you? What is the single most valuable, concrete move you can make when you sit down at your desk on Monday morning? It is this. Draft your scope boundary in exactly one sentence. One single sentence.

Name the specific AI systems, the specific product team, and the specific physical or cloud sites it covers, and then write a second sentence justifying to yourself why that specific boundary is both meaningful to an enterprise customer and operationally maintainable by your existing small team. If you cannot state your boundary in one clear sentence, you do not have a scope yet. You have a wish list.

And wish lists drown teams. Draft your sentence, draw your boundary, and start building. Scope is a truth statement.

Make it a true one. I couldn't have said it better. Take that one sentence, take control of your governance, and stop drowning.

Until next time.