YT YouTube2Text

YouTube2Text → Transcripts → The Complete ISO 42001 Certification Roadmap For 2026 (FREE AI Governance Course)

The Complete ISO 42001 Certification Roadmap For 2026 (FREE AI Governance Course) — Transcript

by StackAware · 14,558 words · 2,275 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:00In this video, I'm going to show you
0:01exactly how to achieve ISO 4201
0:04certification in 2026. This is a
0:06fulllength AI management system course
0:09for free. I'm Walter Hok, the founder of
0:11Stackaware. We help AI powered companies
0:13measure and manage risk. And this is the
0:15exact process that we use with clients
0:18like Elios, Rightway, and Acurus to
0:20achieve ISO4201 readiness in 90 days.
0:24This isn't going to be your average AI
0:26governance introduction video. I'm going
0:28to show you exactly how to build a
0:29complete ISO 4201 compliant AI
0:32management system so you can confidently
0:34answer customer security questions,
0:36satisfy board demands for AI risk
0:38management, and avoid millions and fines
0:40under laws like the EU AI Act and
0:43Colorado SP 205. This video will show
0:45you the exact step-by-step process you
0:47need to follow so you never have to
0:49watch another ISO 4201 video again.
0:52Let's get into it.
0:55All right, here we go. So let's level
0:57set on what exactly ISO 4201 is. ISO IEC
1:0242012023
1:04is the global standard for building an
1:06artificial intelligence management
1:08system A IM or as for short. It gives
1:11you a blueprint for building your Ames
1:13which according to ISO 4201 is a set of
1:16interrelated or interacting elements of
1:18an organization that establishes
1:20objectives related to AI along with
1:22policies and processes to achieve these
1:25objectives. The document has six parts.
1:28Clauses 1 through three are mainly
1:30introductions and definitions. Clauses
1:32four through 10 are the meat of the
1:34standard which tells you exactly what
1:36you need to do. Annex A has a set of
1:39controls you need to at least consider
1:41for your aims. AnnexB has detailed
1:44implementation guidance for these
1:46controls. Annex C has some sample AI
1:49objectives for your aims to pursue or
1:52measure. And then annexd lists how you
1:55can integrate with other management
1:56systems or topics as appropriate for
1:59your organization. So why should
2:01organizations consider ISO 420001
2:03certification? First of all, it's an
2:05effective way to manage AI risks and
2:07impacts. AI introduces a whole new set
2:10of challenges related to fairness and
2:12accountability, environmental impact,
2:14cyber security, compliance, privacy, and
2:17a whole host of other issues. An
2:19effective AI management system gives you
2:21a solid way to assess and manage these
2:23risks. ISO 4201 can also help you comply
2:27with the wave of new AI specific
2:29regulations that are coming into force
2:31across the globe. Some examples include
2:33the European Union's AI act, Colorado's
2:36SP 205, and New York City's local law
2:39144. Some of these laws like SP205
2:42specifically identify ISO 420001
2:45compliance as providing legal safe
2:47harbor under certain circumstances. But
2:49more broadly, an AI management system
2:51gives you a method to regularly analyze
2:54and adapt to changes in laws and
2:56regulations. Finally, ISO 420001 helps
3:00you build trust with key stakeholders.
3:02This lets you assess and manage
3:04individual and societal impacts of AI to
3:06reassure customers and others to
3:08accelerate sales cycles and AI
3:10deployments and avoid bad press from AI
3:14training as companies like Zoom and
3:16Docyign encountered when they rolled out
3:19new policies related to how they were
3:21training on customer data. Well-managed
3:23AI is a unique selling proposition. So,
3:26who should get ISO4201 certified? There
3:28are three main categories of companies
3:30that benefit most from certification.
3:33The first would be AI powered B2B
3:35startups. The certification covers a
3:37wide range of different issues,
3:39security, societal impact, regulatory
3:41alignment with a single framework. And
3:43this can help accelerate due diligence
3:45and deal closure, especially for
3:47organizations that are resource
3:49constrained and can only pursue one
3:51compliance framework at a time.
3:53Companies that are training on customer
3:54data would also benefit greatly from ISO
3:57420001 certification. This provides
3:59stakeholders assurance about responsible
4:01AI use and development and can help you
4:03avoid bad press or tough questions
4:06related to your AI training practices.
4:08Finally, heavily regulated enterprises,
4:10specifically those in healthcare and
4:12financial services would benefit greatly
4:14from ISO 420001 certification.
4:16Regulators AC across the globe are
4:18focused closely on AI use, especially in
4:21these sectors and ISO 420001 provides a
4:24defensible framework about how you're
4:26managing AI risk and proof that it was
4:29in fact done. All right, let's talk
4:30about some potential failure modes
4:32before we dive into how to build your
4:34IMS. So failure mode one would be taking
4:37a checkbox approach. Creating one set of
4:40audit ready documentation but another
4:42for daily use will create
4:43inconsistencies in how you operate. and
4:45auditors can tell whether an AI IMS is
4:48fake or not. So follow your procedures
4:50and document that you have done so.
4:52Another failure mode would be to have an
4:54unclear scope and inventory. So the
4:56scope of the audit covers the management
4:58system, not the products within the
5:01management system, but you need to know
5:02what is in and out of scope of that
5:05defined management systems bounds.
5:08Tracking fourth-party dependencies, for
5:09example, AI models and services used by
5:12current V vendors is also challenging
5:14and related to the scoping and asset
5:16management problem. Automation is key to
5:18avoiding these inconsistencies and
5:20something that stackware specializes in.
5:22A final failure mode is a lack of
5:25executive buyin. So only top management,
5:27which has a specific definition
5:29according to ISO 4201, can perform
5:32things like management reviews, which
5:34are required by the standard. A
5:35consultant cannot come in and do it. A
5:38GRC team cannot do a management review
5:41by itself. Auditors may also question
5:43members of top management about the A
5:46IM. So they must be knowledgeable about
5:48its operation and its existence. And
5:51then also if engineering and product
5:53teams are not participating,
5:55certification is unlikely. You will need
5:57them to take certain steps at a minimum
6:00producing evidence to help you achieve
6:02certification. By the way, if you want
6:04us to help you build an ISO 4201
6:07compliant AI management system without
6:09spending 6 to 12 months figuring it out
6:11on your own, book a call using the first
6:14link in the description. We'll build
6:15your complete AI management system for
6:17you, doing all the risk and impact
6:19assessments, implementing the 38 annex
6:22controls, building all required
6:23documentation, conducting the internal
6:25audit, and helping you through the
6:26certification process. We've helped
6:28companies like Elios, Rightway, and
6:30Acturis get certification ready in 90
6:32days, and we can do the same for you.
6:34Again, that's the first link in the
6:36description to book a call. All right,
6:37let's chat about the key ISO 420001
6:40organizations and the roles that they
6:42play. So, there are five that we're
6:43going to touch on here. First of all, we
6:45have the certified organization. This is
6:47you. ISO 420001 applies to organizations
6:50of all sizes, industries, and methods of
6:52using AI. Some examples include
6:54stackawware itself which is ISO4201
6:56certified since 2024. Elios which is a
6:59stackaware client as well as
7:00scrutination another stackware customer.
7:03Another important role would be that of
7:05adviser. This is optional but can help
7:07you with advice and consulting doing
7:09risk and impact assessments as well as
7:11control design and implementation. Stack
7:13aware is the obvious choice here. Next
7:15would be the internal auditor. This is
7:16required by clause 9.2 of ISO 4201. This
7:20is an impartial person who can check the
7:22work of others and must not have
7:24designed or implemented the controls
7:26they audit. Stackaware can fill this
7:28role by bringing in an expert who has
7:30not performed any of the control design
7:32or implementation or the auditor
7:34organization can use a trained and
7:36competent employee. The external auditor
7:39is up next. This is the firm that grants
7:41the certification. They must be
7:42independent of the ISO 4201 advisory and
7:45implementation work. And some examples
7:47which are all stackaware partners
7:49include A-ine mastermind preient
7:52security and shell. Finally we have the
7:54accredititation body which authorizes
7:56the external auditors to grant
7:58certifications and they perform quality
8:00controls on these auditors namely by
8:02witnessing audits. For example,
8:04Stackware's 2025 surveillance audit was
8:07witnessed by the ANAB which is the Anzy
8:11National Accreditation Board. Another
8:14accredititation body is the
8:16international accredititation service.
8:18All right, let's talk about ISO 420001
8:20roles and scope. Auditor organizations
8:23must pick one or more of the following
8:25AI roles. I'm only going to talk about
8:27three of them because the last three
8:29aren't really relevant and organizations
8:31in these categories are unlikely to
8:33pursue ISO 420001 certification. You can
8:36also see ISO IEC22989
8:402022 which is a free document for more
8:42detail. So the first role I'll talk
8:44about is producer and this is an
8:46organization that designs, develops,
8:48tests and deploys products or services
8:50that use one or more AI system. An
8:52example would be a frontier model
8:54developer like OpenAI or Anthropic. It
8:56could also be a smaller company that
8:57develops AI products itself. Next would
9:00be an AI provider which is similar and
9:03provides products or services that use
9:05one or more AI systems. So AI powered
9:08product companies and service companies
9:09would fit into this category. Finally,
9:12you have the AI customer or AI user
9:15category. And this is an organization
9:17that uses one or more AI product or
9:19service. And basically any company using
9:21AI can fit into this category. On
9:23scoping, some key considerations are to
9:26explain what is in your AIMS and what is
9:29not. That is the goal of your scope.
9:31Making it too broad and you can waste
9:33resources. For example, customers might
9:35not care about how your marketing team
9:36is using chat GBT. But if you make it
9:38too narrow, you could reduce your
9:40effectiveness and the value of the
9:42certification. For example, if you don't
9:44cover your core product, why are you
9:45even doing ISO 420001? You don't need to
9:48worry about what's GA or generally
9:50available, what's in development, what's
9:51on the road map, etc. Because ISO 420001
9:54does not certify products. That's a key
9:57distinction. Focus on the management
9:59system for those products and ensuring
10:01that all products developed within the
10:03scope of the Ames have followed your
10:05policies and procedures. That is key.
10:07Moving to inheritance and types of
10:09systems. It's important to note that ISO
10:114201 does not lay out a clear
10:14inheritance framework similar to
10:16standards like high trust which are very
10:18explicit in what controls can be
10:19inherited and what is not. This means
10:21you need to develop a defensible
10:23approach and this is something that
10:24stackware specializes in. An AI
10:26management system can also include any
10:29of these situations. training
10:30proprietary models, deploying open-
10:32source models in infrastructure as a
10:34service, for example, Meta Lama, using
10:36thirdparty SAS AI tools like ChatGpt or
10:40Claude, and operating software that
10:41itself leverages thirdparty SAS AI. So,
10:45basically everything in the market
10:46today. In terms of physical locations,
10:48virtual audits are possible for ISO 4201
10:51because there aren't any physical
10:53controls in Annexa A. But you still do
10:56need to list the inscope locations
10:58considering do you have multiple offices
11:00where AI work is happening. What are the
11:03jurisdictional impacts on your use of AI
11:06and how do this impact your regulatory
11:09footprint? Okay, let's dive into ISO
11:11420001 certification timelines. Starting
11:14from zero, it will take about 210 days
11:17to go from beginning to end of the
11:19certification process, assuming you're
11:21moving at a good pace. So by day 30, you
11:25should have in place a clear scope,
11:27inventory of AI systems and models and
11:30have implemented your AI risk criteria,
11:33assessment and treatment procedures. By
11:36day 60, you should have implemented
11:38clauses 4 through 10 of ISO 4201,
11:41creating an AI policy, establishing
11:44monitoring and measurement requirements,
11:46and starting your management reviews. By
11:48day 90, you should have in place your
11:50annex controls, creating a statement of
11:53applicability based on your risk
11:55assessment process, and have conducted
11:58any required data providence, quality,
12:00and bias analyses. By day 120, you
12:03should have completed an internal audit
12:05from an impartial party and that party
12:08should provide recommendations for
12:10improvement as well as any
12:11nonconformities with ISO 420001 or your
12:14internal requirements. Next up would be
12:17the external auditor gap assessment.
12:20This is optional, but I would recommend
12:22it because it is a pre-check by the
12:24auditor on your AI management system,
12:27and they can identify areas of concern
12:30beforehand. They can't tell you how to
12:32fix those issues, but they can tell you
12:33what are areas of concern ahead of time.
12:36Next, 30 days later, would be the stage
12:38one audit. This is a review of clause 4
12:41through 10 design and identification of
12:44any nonconformities with the standard.
12:46By day 210, you will likely be able to
12:49complete your stage 2 audit, which is
12:51focused on the operating effectiveness
12:53of clauses 4 through 10 and your annex A
12:56controls. If any nonconformities are
12:58identified, your auditor may provide you
13:00with a corrective action plan or request
13:03one from you in which you need to commit
13:05to implementing it. and that will be
13:07checked up on during your surveillance
13:08audits, which I'll talk about next. And
13:10then if everything goes well and you
13:13demonstrate enough conformity with the
13:15ISO 420001 standard and your own
13:17requirements, you will get a
13:19certificate. Okay, so let's talk about
13:21the certification cycle. So we're
13:24zooming out a little bit here because
13:26we're moving to years rather than days.
13:29So assuming at year zero you get your
13:32initial external certification the audit
13:34is complete then between year zero and
13:37one you'll need to do another internal
13:39audit at least one at year 1 you'll have
13:41an external surveillance audit which is
13:43a scaledown version of the initial
13:45certification audit which will focus on
13:47specific sections of the ISO 4201
13:50standard either clauses 4 through 10 or
13:52the annexa controls. Then you'll do
13:54another internal audit between years 1
13:56and two. And then in year two, you'll
13:58have an external surveillance audit for
14:00the second time around. Between years 2
14:01and three, you'll need to have yet again
14:03an internal audit. And then at year
14:05three, you'll need to go through the
14:07entire reertification process again. And
14:10you will continue this indefinitely as
14:11long as you want to maintain ISO 4201
14:14certification. All right. So now that
14:17we've laid out a road map, let's get
14:19into how exactly you're going to achieve
14:21ISO4201 certification. Starting with
14:24clauses 4 through 10. So with clause 4,
14:27we're going to start with sub clause
14:284.1, which is the context of the
14:31organization, including your AI roles.
14:34Clause 4.1 requires you to identify
14:37internal and external issues such as
14:39regulatory obligations, contractual
14:41commitments, as well as the competitive
14:43landscape and internal cultural issues,
14:46as well as determining whether climate
14:48change is an issue or not. So,
14:51oftentimes it's unclear exactly what
14:53form this should take. So, what I'm
14:55going to show you is how Stackware
14:56presents this information to our
14:58external auditors, which clearly has
15:00gotten the job done so far. So, I'm
15:02going to pull up a spreadsheet that has
15:04a list of our internal and external
15:07issues. And just to use one example,
15:09we've got the HIPPA databach
15:11notification rule. Because we are a
15:13HIPPA business associate, we need to
15:16abide by this requirement and it has
15:19potential implications for how we use
15:21artificial intelligence. So, we've got
15:23the relevant organization or
15:24jurisdiction. We've got the issue
15:26description uh detail explaining why we
15:29uh believe this to be applicable to us.
15:31We also identify whether this is an
15:33internal or external issue. And then we
15:36have a true or false column explaining
15:39whether or not it is addressed by the AI
15:41management system. If you have multiple
15:43different management systems, you'll
15:44want to have columns for each of those
15:46to explain which issue is covered or
15:49addressed by which management system. If
15:51you go down, we'll we'll get into the
15:53internal issues. And this looks into
15:54things like our incentives, like limited
15:57manpower. Uh I also mentioned climate
15:59change. We do believe this is applicable
16:00to us and we explain how we are impacted
16:03and how we track our carbon footprint
16:06using Google Workspaces tools. This is
16:08not required by ISO4201 but something I
16:11would recommend is having a list of
16:13issues that are not applicable but
16:16considered. So these are issues that um
16:21have been considered but are not
16:22applicable and we document why they are
16:24not applicable. So this gives us the
16:27ability to explain to auditors why
16:29something is not an applicable internal
16:31or external issue. So we provide our
16:34justification here and we can revisit
16:36this on a regular basis using stackhorse
16:38automation. Every 365 days these items
16:41come up for review. So we determine
16:43whether or not these now do apply or if
16:46they continue not apply. Another thing
16:48to think about in clause 4.1 is the AI
16:51roles. So, Stackaware is both an AI
16:54provider and AI producer. Although we do
16:56not train or fine-tune our own models,
16:59we do serve as an AI governance and
17:01oversight professional, which is a
17:03subcategory of AI producer, which is why
17:05we have identified ourselves as being
17:08that. So, document what roles you think
17:10you're filling and justifications for
17:13those roles. Okay. Next up is clause
17:164.2, which looks at the needs and
17:18expectations of interested parties.
17:20These necessarily flow from your
17:22internal and external issues and I'll
17:24show you exactly how we do it. So if you
17:26go to interested parties, every
17:29organization that levies a requirement
17:31on stackaware is necessarily an
17:34interested party by our analysis. So we
17:36have them listed here and we refer back
17:38to the internal and external issues to
17:39explain what their requirement is. We
17:41also have others such as independent
17:43contractors, adviserss, business
17:45partners, customers, folks that have
17:47interest in how our AI management system
17:50operates and we also identify whether
17:53they are addressed by the AI management
17:55system or not in this column. Okay, we
17:57also do the same thing uh explaining
18:00which interest parties are not
18:02applicable and again this pulls from the
18:05internal external issues tabs for the
18:08requirement and then uh we also explain
18:11why different organizations for example
18:13the IAP are maybe not interested parties
18:17for our AI management system. Okay, next
18:19up is looking at the scope of the AI
18:23management system. Here you have
18:25Stackaware's AI management system scope
18:27statement. Note, this is written in pros
18:30format. I don't necessarily love this,
18:32but all the guidance I've gotten from
18:34auditors is that it must appear in this
18:38manner. And as you can see, it covers
18:40our AI governance platform, the AI risk
18:43assessment and governance services, and
18:44the third party AI systems used by the
18:46organization. It also lists our roles.
18:50So, as part of the audit, the external
18:52auditors will drill down on your scope
18:54and they will look at things like your
18:56inventory and confirm that you were
18:59incorporating all the appropriate items
19:01into your scope, but they will
19:03ultimately want to have a pros form
19:06description of your AI management system
19:08scope like this. Okay. Clause 4.4. This
19:12is something of a self-explanatory item
19:15and basically it just says that an
19:17organization must establish an AI
19:19management system. What I recommend
19:20doing is having the AI policy which
19:23we'll talk about next. Declare the
19:25establishment of the AI management
19:26system to make sure that you are meeting
19:28the clause 4.4 requirements and
19:31eliminate any ambiguity. Moving along,
19:34we have clause 5. 5.1 requires the
19:38establishment of leadership for the AI
19:41management system and their commitment
19:42to certain principles. This will
19:44primarily be evaluated through
19:47explanation and discussion with key
19:50stakeholders to ensure that the
19:52requirements are met. 5.2 is a clear
19:56documented information requirement of
19:58ISO 4201 and something that demands
20:01certain elements in it. So review the
20:03standard for the exact requirements and
20:06stackaware's draft policy will hit all
20:09of these items. But you must have a
20:11document called the AI policy. And what
20:13I'll do is show you our template for
20:17such a document. So as you can see here,
20:19we've got a freely available AI policy
20:22template. And what this does, it lays
20:24out a purpose, scope, provides some
20:26definitions, and it also does things
20:28like um establish the AI management
20:32system. It includes a commitment to meet
20:36all applicable requirements as well as
20:38continual improvement of the AI
20:40management system. We'll talk about that
20:41a little bit more, but these sorts of
20:43things are required by the ISO 4201
20:46standard. And again, they are detailed
20:48in depth in that document. So please
20:50refer to it for all of the required
20:53elements. Okay. Next is 5.3 roles and
20:56responsibilities. Some organizations
20:58will create a separate matrix for roles
21:00and responsibilities separate from the
21:01policy. I don't like that approach. I
21:04like being very clear who is responsible
21:06for what in the AI policy. Rather than
21:08creating two documents, one that's kind
21:10of a aspirational thing and one that's
21:12more more tactical. I combine the two
21:14together whenever possible. So if you
21:17look at the AI policy, you've got things
21:19like the chief information security
21:21officer must do certain things within
21:23certain timelines, general counsel,
21:26chief privacy officer, all of these
21:28folks, employees, business unit, general
21:31managers. Again, how you structure this
21:33is up to you. Feel free to use stackor
21:35template, but the key is that you must
21:36be explicit about these roles and
21:38responsibilities in your policy
21:40document. I've also seen things like
21:42racy matrices work fairly well, but I
21:45prefer to combine the AI policy and the
21:48roles and responsibilities. With clause
21:506, we're talking about AI risk and a
21:53variety of other items. This is a pretty
21:55meaty clause and very important to ISO
21:58421. So, we'll start with 6.1.1, which
22:01focuses on risk criteria. This is how
22:04you lay out what risks are acceptable
22:06and what risks are unacceptable in your
22:08AI management system. I'll show you
22:10exactly how stackaware does this. So I'm
22:12going to provide a template document
22:14that shows two different ways of
22:16explaining your risk criteria. The first
22:19which is preferable is using a
22:21quantitative approach. So in this
22:23example we are using the hubard sir
22:26rapid risk audit method to establish a
22:29risk appetite/annual
22:31loss expectancy of $100,000 a year. So
22:34in this example, if we have an annual
22:36loss expectancy below $100,000 a year
22:39for the organization, then that's okay.
22:41We can proceed along. Anything that
22:43spikes above $100,000 a year, then we
22:46must take some sort of risk treatment
22:48action, which we define in another tab,
22:51which I'll show you briefly, but we make
22:53clear which assets are in scope. For
22:56example, uh the inception stage we don't
22:58worry about because that's not actually
23:00risk. That's just contemplated risk.
23:02It's something that we're thinking
23:03about. It's not risk that can actually
23:05materialize if we're just in the
23:07inception stage of an AI system. So, we
23:10limit the life cycle phases where this
23:12applies. I'll talk more about that later
23:13on in this course. In terms of risk
23:15management options, these are pretty
23:17standard. Avoid, accept, transfer,
23:20mitigate. We document these just to be
23:22clear what we're talking about so that
23:24there's no confusion when we're
23:25communicating with auditors. And then we
23:26link out to some references that go more
23:30in depth. So quantitative is the
23:32preferred approach. It is much more
23:34precise. It's less handwavy. However,
23:36many organizations use a qualitative
23:38risk model, also known as a heat map.
23:40And what you can see here is this heat
23:43map with some definitions of the impact
23:46as well as impact examples. And then we
23:49have categories of impact, minor,
23:51moderate, major, extreme, and then
23:52likelihoods, which are unlikely,
23:54moderate, likely, almost certain. And
23:56then you have your classic heat map
23:58here. So we also make clear that risks
24:00classified as low or medium are
24:02acceptable. Risks classified as high or
24:04critical are unacceptable. This will get
24:06the job done for ISO 420001
24:08certification but I don't think it's
24:10very useful. If you want to use this
24:12model then go ahead and stack aware will
24:14support you in doing it but we would
24:15recommend maturing your program to take
24:17a quantitative approach. Now something
24:19that is unique to ISO 4201 is the need
24:23to factor in not just organizational
24:26risk but also individual and societal
24:28risks. So for both the qualitative and
24:31quantitative approaches we have a list
24:33of additional unacceptable risks and
24:35I'll drill down here. So what this is is
24:38a list of risks that by themselves would
24:41be unacceptable. So irrespective of
24:44whether we're breaching our annual loss
24:46expectancy threshold or whether it's a
24:48low, medium, high critical risk from the
24:50qualitative approach, any of these
24:52things are unacceptable to this
24:54organization. Again, these are examples
24:56and you'll need to tailor this to your
24:58organization and be able to defend it to
25:00your auditors. So on the organization
25:02level, training or fine-tuning AI
25:04systems using AI generated content could
25:06potentially cause model collapse. So
25:08that's an unacceptable risk. At the
25:09individual level, knowingly deploying
25:11any system that has a net negative
25:13impact on expected lifespan of a human
25:16could be an unacceptable risk. Anything
25:18related to hiring or termination
25:20automatically using AI could be an
25:21unacceptable risk. And then societal
25:24level, you know, trainer fine-tuning AI
25:26systems with pirated content could be
25:27unacceptable. Accelerating
25:29misinformation or accelerating labor
25:31displacement without compensating
25:32offsets. These could all be unacceptable
25:34societal risks. So, however you're going
25:36to do this, make sure that you hit all
25:38of these requirements when you're
25:40establishing your risk criteria. Next,
25:42we're going to talk about risk
25:43assessment. So, having a repeatable risk
25:46assessment process is absolutely key to
25:49ISO 420001 compliance. And the way to
25:52ensure that you have a repeatable risk
25:54assessment process is to document all
25:56the steps. I'm going to show you exactly
25:58how Stackware does it and how we
26:00implement it in the real world. So what
26:02we're going to do here is pull up our
26:05risk assessment procedure. So this is
26:07publicly available. We have purpose,
26:09scope, requirements. The requirements
26:11are the key piece here. So this lists
26:14who must do what and it's very clear
26:16about what must be evaluated. How we
26:19implement this in the real world is we
26:21take a list of these requirements which
26:23are stored on our backend and then
26:24automatically generate Jura tickets when
26:27we need to perform this process. So if
26:29you look here, we will show you exactly
26:32how this manifests for a realworld
26:34system. So when we were building our
26:37model context protocol server, we did a
26:39risk assessment following this
26:40procedure. And this is the result of an
26:42automation that takes all the steps from
26:44the risk assessment procedure and
26:46creates a juro ticket through which we
26:48can go line by line and make sure that
26:50everything is done correctly. So once
26:53you've done your risk assessment, then
26:55you move into risk treatment. So from
26:58that perspective, we'll pull back up our
27:01documentation here. And if you look at
27:03the risk treatment, it also has a set of
27:05steps that are required to be performed.
27:08And we take the same approach as with
27:10the risk assessment in that we will
27:12generate tickets to ensure that all of
27:15these requirements are met. So, however
27:18you do it, make sure the process is
27:20clear and repeatable and allows you to
27:23compare the results to your risk
27:25criteria, which we established at the
27:27start of clause six. So, now we're going
27:29to talk impact assessment. This is where
27:31things get pretty difficult to
27:34understand and disentangle. So, I'm
27:37going to show you at a high level how
27:39stackware thinks about this from a
27:42comprehensive perspective. Here's where
27:44things start getting interesting. So ISO
27:464201 is a revolutionary way to manage
27:51artificial intelligence. Unfortunately,
27:53it is the first draft of a standard and
27:56it is clearly written by committee and
27:58that means there are lots of overlapping
28:00and duplicative requirements which can
28:02make it very hard to implement in the
28:03real world. Stackaware specializes in
28:06doing. So we're going to talk through
28:07here our approach how it aligns to ISO
28:11420001 and even other standards that are
28:13relevant. So, Stackaware uses three
28:16processes in addition to risk assessment
28:18that are relevant to ISO4201. We do
28:21model assessments, we do system
28:22assessments, and we do impact
28:24assessments. I'm going to talk through
28:25exactly what those mean. Okay, so the AI
28:28model assessment, which is a stackaware
28:30concept, it incorporates several annex
28:34controls into a comprehensive procedure.
28:37And we'll talk through exactly what this
28:38looks like. We're talking about this now
28:40because it leads into the AI impact
28:43assessment. But a model assessment is
28:45separate from the AI impact assessment.
28:47And this is something we do for every
28:48single AI model. It also feeds into the
28:51risk assessment process. And if we
28:53identify issues during the AI model
28:55assessment, we will generate risks as a
28:57result. Also relevant is the AI system
28:59assessment which incorporates some
29:01annexa requirements and comes up with a
29:05set of checklist items that you can go
29:07through when you're evaluating a new AI
29:10system. We'll talk more about this
29:12later. Most relevant to clause 6.1.4 is
29:15the AI impact assessment. This is an ISO
29:18concept that is required by the
29:19standard. It's also detailed in ISO
29:214205,
29:23which is a more detailed look at AI
29:25impact assessments, but it is not a
29:28normative reference for ISO 4201. It is
29:30not binding. It just provides some
29:32suggested practices. So, we separate out
29:36these items so that we're clear about
29:38what we're doing. Every model gets a
29:40model assessment. Every system gets a
29:43system assessment, but not every system
29:45gets an impact assessment. That's
29:47because organizations need to create
29:50criteria for when they conduct AI impact
29:53assessments. And I'll show you where we
29:56establish that criteria in our
29:57documentation and how it works in the
29:59real world. Back in our documentation,
30:02we have here the clause 6.1.4
30:05model system and impact assessment
30:07procedure. As I mentioned, we do model
30:09assessments for every single AI model in
30:12which we look at these things. algorithm
30:14types, optimization methods, tools to
30:16aid in development, providence
30:18categories, intended use, quality, bias,
30:20so on so forth. For every AI system, we
30:22look at intended purpose, complexity,
30:24reliability, transparency, so on so
30:26forth. This is something we do for every
30:29AI model and system. Now, for systems
30:32that are general purpose AI systems,
30:35this is according to the European Union
30:37AI act definition or those are specially
30:39designated by the chief information
30:41security officer. We also look at
30:43additional things. For example,
30:45categories of people and groups
30:46impacted, environmental, sustainability
30:48impacts, economic impacts, legal,
30:50governmental, and public policy impacts,
30:52normative, societal, cultural, and human
30:54rights impacts. This is what we call an
30:57impact assessment at Stackaware. These
31:00can have different definitions in
31:01different places. But what we do is we
31:04tie every definition we have to specific
31:07requirements from the ISO 420001
31:09standard as I demonstrated in previous
31:11slides showing how we incorporate a lot
31:14of different demands by the standard
31:16into a coherent process. So the model
31:19system and impact assessment procedures
31:22can drive risks and they should
31:24according to the ISO 4201 standard that
31:27we then evaluate compared to the risk
31:29criteria and determine whether we need
31:31to treat them or we can accept them as
31:33is. Next up is clause 6.2 where we look
31:37at our AI objectives. 6.2 ties into a
31:40lot of other pieces of ISO 4201. So I'm
31:44going to show you the comprehensive view
31:46from Stackware's perspective. So what we
31:48have here are listed objectives and the
31:52ID is pulled from annex of ISO 4201. So
31:55we've used some of the recommended
31:57objectives from that standard and for
32:00example C.210 is security. We list out
32:03the applicable requirements here pulling
32:05from our internal and external issue
32:07analysis. We also specifically identify
32:10what we're measuring as a result of this
32:12objective. So the objective is security.
32:15The measurement that we're taking is the
32:18number of two-factor authentication
32:20capable systems that are processing
32:22anything but public data. This is
32:24something that we track over time. We
32:26have identified some exceptions to this
32:28where we're unable to implement
32:30two-factor authentication because the
32:31platform does not provide it. It's
32:33something we track over time and we have
32:35a designated success criteria which is
32:38we are looking for 100% compliance with
32:41this requirement. We are not necessarily
32:43meeting it though if you look at our
32:45evaluation. So 100% is the target upper
32:48bound and it has fluctuated over time
32:50you know 90 to 95% but we have
32:53identified that we are falling short of
32:55this goal. We have established risks in
32:57our risk register to track this
32:59requirement. We have applied controls to
33:01address it and it is something that we
33:04are aware of and we are constantly
33:06seeking to improve our security through
33:09two-factor authentication for all
33:11systems processing non-public data. But
33:13this is how we track our ISO 420001
33:17objectives. Clause 6.3 is up next. This
33:20focuses on control of changes within the
33:23scope of your AI management system. This
33:25requirement is pretty high level, but
33:27I'll show you exactly how we implement
33:29it at Stackaware to make sure that we're
33:31ISO 420001 compliant and also manage the
33:34risk from AI systems. So, I'm going to
33:36pull up our asset life cycle procedure
33:39here. And this is a set of steps that we
33:42apply to AI systems and models that
33:45we're using. So, it has a list of
33:46requirements. It also has a set of life
33:48cycle stages, which we'll talk about in
33:50the annex section where all these things
33:52happen. Furthermore, just like with the
33:54risk assessment procedure, what we do is
33:56we have an automation that pulls these
33:59tasks and creates Jira tickets for each
34:02requirement. So when we moved up to GPT
34:055.2, we fired the automation for the
34:09asset life cycle procedure and went
34:11through all of these steps. Now you can
34:12see some of them we didn't actually do.
34:14For example, there was no remediation
34:16required. We didn't do unit testing
34:18because we don't have access to the
34:19source code. And then also some items
34:21are still open. For example, we're going
34:23to review monitoring measurement results
34:25and see if it's relevant for our AI
34:27management system. Um, the next time we
34:28do a management review, we're going to
34:30review the results of risk assessment
34:32and and risk treatment plans next time
34:34we can. And then also some steps here
34:36are related to decommissioning of the
34:38system, which we aren't doing yet
34:39because as of this recording, we are
34:41currently using GPT 5.2. So key thing
34:44here is having a comprehensive procedure
34:47for how you're going to track your AI
34:49models and systems throughout their life
34:51cycle. All right, we're now at clause
34:54seven. So, we're going to start with
34:567.1, which focuses on resourcing for the
34:59organization. Basically, this just says
35:01the organization needs to provide
35:02appropriate resources for the AI
35:04management system. How do you track
35:05that? Well, I'll show you how we do it
35:07at Stackware. So, one thing that we do
35:10is we align our objectives specifically
35:14with the resources required to
35:16accomplish them. So for two-factor
35:18enabled systems, we need systems that
35:20have two-factor authentication
35:22available. For privacy, we need
35:24pseudonymization techniques and
35:25training. We need database table
35:27references. For um contractors and
35:29employees being trained, we need money
35:31for the AIGP or other certification
35:34regimes. And we need resources for them.
35:36We also track our spend uh using certain
35:39AI systems and vendors down to the
35:41dollar. These are exported from our
35:43financial management software and
35:45populated here. I'm not going to share
35:47the exact figures, but we do track these
35:49very precisely and we use our accounting
35:51software to do it in a way that allows
35:53us to say this is exactly how much money
35:55we are spending on our AI management
35:57system resources. 7.2 requires that you
36:01have appropriate competence for
36:03personnel in your AI management system.
36:05And I'll show you how we track this at
36:08Stackaware. So, what I'm going to show
36:10you first is our personnel register,
36:13which has a list of people that are
36:16within scope of our AI management
36:18system. So, let me pull this up here.
36:20And we list the roles of these people as
36:24well as their uh employee or contractor
36:26type. And we list whether they're active
36:28or not. And then we give them a user ID.
36:30This is to pseudonmize their identity.
36:33As you can probably tell, I am 99, but
36:36uh I'm happy to disclose that publicly.
36:38And then for our competence register, we
36:41have another set of uh unique
36:43identifiers. These are randomly
36:45generated and do not tie back to the
36:47original personnel identifier because
36:49some of these are publicly available
36:51credentials. Um for example, ISO 420001
36:54lead auditor certifications, AIG
36:56certifications, other types of AI
36:59governance and security credentials. And
37:01we track all of this in our database
37:03here, which is populated and allows
37:06auditors to review it and make sure that
37:08our people are meeting their required
37:10education and training requirements.
37:12Next up, we're going to talk about
37:14awareness. So, this means that the
37:16people operating in the scope of the AI
37:19management system need to be aware of
37:21the AI policy as well as the
37:24consequences of not complying with the
37:26AI policy. So just like every
37:28information security policy, our AI
37:30policy does have a requirement saying
37:32that non-compliance can result in
37:34termination of employment or end of
37:37contract if applicable. So in our
37:40contracts with those contractors who are
37:42within scope of the AI management
37:43system, we do have a requirement to
37:45adhere to the AI policy and related
37:49requirements for our AI management
37:51system. We document all of that in their
37:54consultant or contractor agreements. And
37:56we also for employees require
37:58acknowledgement of the AI policy. And
38:01I'll show you how we do it. It is in a
38:03structured database that we export to a
38:06spreadsheet that can be reviewed by
38:08auditors. And as you can see, this is
38:10the awareness register. Individual
38:13unique person identifiers don't reveal
38:15who this is. These are randomly
38:16generated. But we do have things like
38:18consultant advisor agreements, AI risk
38:20training, um, and then confidential
38:22information and invention assignment
38:24agreements, things of that nature where
38:26we're documenting the awareness of the
38:28AI policy. We also track our training
38:31records here. We require all members of
38:34the AI management system to take the
38:365-day AI risk email course once a year
38:39and we update that on a regular basis
38:41and we track the results here in this
38:44database. You can use an HR system. You
38:46can use a spreadsheet. However you do
38:47it, make sure that you can
38:49operationalize it and present evidence
38:51to auditors when they ask. Okay. Getting
38:54into 7.4 with communication. This is a
38:58set of requirements about how, when, and
39:00about what you are communicating. And
39:02the easiest way to document this is in a
39:06table, which we will give you an example
39:07of for stackaware. And as you can see,
39:10we do a variety of different things.
39:12making our AI policy available. We train
39:15interested persons. We ensure everyone's
39:18aware of the whistleblower procedure. We
39:20explain who's responsible for doing
39:22this, when we do it, and how we do it.
39:24Some important things to note are the
39:26internal versus external communications.
39:29Auditors will often want to see this
39:30documented. And then, of course, you'll
39:32need to have evidence of this happening
39:34on a regular basis during the audit.
39:37Again, how you design this is going to
39:38be up to you based on your
39:39organizational requirements, but you'll
39:41need to be able to defend it. All right.
39:43For clause 7.5, this relates to
39:45documented information and how you store
39:48it. So, there are a couple nuances here.
39:50And for ISO 4201, auditors will often
39:54want to see for your documented
39:56information some key change control
39:58notes. So, I'll pull up our onboarding
40:01policy or onboarding procedure right
40:03here. And as you can see, we list out
40:05the requirements that are addressed by
40:07this document. You know, clause 7.2 of
40:09ISO 42,0001 as well as 27,0001. Not
40:12necessary, but you know, it's helpful to
40:13understand. Data classification, which
40:15we list here, it's public. And then we
40:17also list the actions taken by we use
40:20user IDs. This is 99 obviously me. And
40:22then the task completed and the date
40:24completed and the versioning. So this is
40:26the type of thing that auditors will
40:28expect to see during the audit. Um, and
40:31you can track these in a variety of
40:33different ways. You can use hero tickets
40:35which have audit trails on them. You can
40:37use structured databases. I would
40:38recommend having an archive table that
40:41stores historical records for anything
40:43that you generate. The key thing is that
40:45you meet the documented ISO 420001
40:47requirements in a way that's repeatable
40:49and a way that you can show evidence
40:51for. All right, so that kind of wraps up
40:54clause 7 and it is something of a
40:56catch-all clause. It's got a lot of
40:58different individual requirements here
41:00and there. It can sometimes be a little
41:01difficult to understand exactly what ISO
41:04is talking about here, but I've given
41:05you some examples of how to implement it
41:08in the real world. Time to talk clause
41:118. So clause 8 is essentially where you
41:14do the work that you described in clause
41:17six. It's essentially where you evaluate
41:20or confirm the outputs of your various
41:23processes that you've defined. So 8.1 is
41:27pretty high level and it basically just
41:29says that you plan, implement and
41:31control the processes needed to meet the
41:33requirements determined in clause six.
41:35So essentially saying that you have
41:37evidence that you are following your
41:38procedures that you have oversight over
41:41them and that you are achieving the
41:44intended results that you're controlling
41:45plan changes. So documentation like the
41:48jurot that I showed you previously of an
41:50asset life cycle would be useful here.
41:53Now clauses 8.2 2 through 8.4. This is
41:57where the auditors are going to look to
42:00see the outputs of your risk assessment
42:03and treatment process as well as your
42:05impact assessment process. So, I'm going
42:08to start with 8.2 and 8.3. This is where
42:11we're going to go to the Stackaware risk
42:14register template. And what this is is a
42:17way to depict the outputs of your risk
42:20assessment process. So, I'm going to
42:23pull this up here. And this document has
42:26a whole set of different tabs. I have an
42:28entire training dedicated specifically
42:30to the risk register that I will link in
42:34the description. But with that said,
42:36essentially what you need to do is take
42:38the outputs of your risk assessment
42:40process and document them. So, what
42:42we're doing here is we're describing a
42:45risk, unintended risk using chat GPT.
42:47This is something that Amazon
42:49experienced reportedly in early 2023
42:53when their engineers were allegedly
42:55using Chatchebt in its default training
42:58mode. And this allowed OpenAI to collect
43:01a lot of sensitive information about
43:04Amazon's internal architecture to the
43:06extent that chat GPT got so good and so
43:08knowledgeable about Amazon's internal
43:11architecture and systems and was able to
43:15serve as a very effective interview prep
43:18system. This may have allowed
43:20individuals to get a job at Amazon when
43:23they might not have been otherwise
43:24qualified. and I did an entire
43:26quantitative risk assessment that looked
43:29into everything that resulted from this
43:31episode. Here's that analysis I
43:33mentioned and in it I do a full
43:36quantitative assessment of the situation
43:39pulling from the headlines related to
43:42the reporting about Amazon and look into
43:45the different categories of loss that
43:48likely was suffered as a result. Another
43:50related incident illustrating this risk
43:52is something that Samsung ran into in
43:562023 reportedly and that employees
43:59allegedly submitted sensitive code to
44:02chat GPT presumably in its default
44:04training mode. So these are just two
44:06examples of unintended training risk
44:09using chat GBT. And what we've done is
44:11in this risk register we have laid out a
44:14description detail recommendation
44:16applicable frameworks for this risk. If
44:19there are any references, then they are
44:21listed here, as well as any assumptions
44:23we've made. We've also tied it to a
44:25specific asset in our inventory. And
44:27then here, this is important from an ISO
44:294201 perspective because we're looking
44:31at the individual, organizational, and
44:33societal impact of these risks
44:35materializing, which is absolutely key.
44:38So, as you can see, we've depicted those
44:40there. And this is addressing the clause
44:438.2 requirements. We also do a
44:46calculation from a quantitative
44:48perspective of each risk looking at a
44:50variety of different issues. Again,
44:51check out the AI risk register video for
44:54details on how this works. Once we've
44:56calculated that risk, then we determine
44:59how we are going to treat it. In this
45:01case, we're mitigating it. We're saying
45:02that our AI policy requires users to opt
45:05out, although acknowledging that it is
45:06imperfect. And we're saying that there's
45:08a 50% risk treatment effectiveness as a
45:11result. We're saying that the product
45:12owner is the owner of this risk and
45:15we've documented the risk treatment
45:18decision date. So this is all the type
45:20of stuff that you want to have to
45:21address clauses 8.2 and 8.3. Stackware's
45:25AI risk register is available for free
45:28and will help you meet all of these
45:31demands. Moving on to clause 8.4, we're
45:34going to look at impact assessments. So
45:36remember, Stackware separates out model
45:39and system assessments from impact
45:41assessments. We're going to go through
45:42all of these things and explain exactly
45:44how they work. So we'll go back to our
45:48documentation here and show you the move
45:52over to the AI model system and impact
45:55assessment register. This is another
45:56free template that you can get from
45:58Stackware. And what you're looking at
46:00here, this is what we call the AI
46:02governance standard. This sets a minimum
46:04requirement for how certain systems must
46:08operate to be acceptable and if they
46:11fall below this standard then that
46:12creates a risk which requires treatment.
46:14So what we do is we create three
46:16different categories of systems so or
46:19and models those that process public
46:20data those that process confidential
46:22data and those that are high risk. We
46:24explain what high-risk means here and
46:26this depends on your organization how
46:28you want to structure this how many
46:30categories you want to have. Stackware
46:31provides these as defaults, but you can
46:34do whatever you would like as long as
46:36you meet the ISO 420001 requirements,
46:38and we'll talk about how that works. So,
46:40moving into the model assessment side of
46:42things, we've done an example assessment
46:44for Gemini 2.0 Flash. And remember, we
46:47talked about the model assessment
46:49procedure in clause 6.1.4. What we're
46:51doing here is we're just implementing
46:52that procedure. So we're doing an
46:54analysis of algorithm types,
46:55optimization methods, tools to use in
46:58development and then we're comparing
46:59that against the AI governance standard.
47:02So if Gemini 2.0 flash uh doesn't meet
47:05the requirement, say it's processing
47:07confidential data and it doesn't provide
47:09any information about the type of
47:10algorithm, then that would create a risk
47:12in our register that we would need to
47:14track. Moving to system assessment, this
47:16is similar. We do these for all AI
47:18systems. We look at things like intended
47:20purpose, criticality, complexity. We
47:22look at the reliability, observability,
47:25logging and monitoring and these all
47:27have requirements for given AI systems.
47:30We do an analysis of them based on
47:32information that is uh available to us.
47:35This is all public information but you
47:37can use confidential information when
47:39doing these assessments and you should
47:40if uh if it can help you improve the
47:42accuracy of the assessments. something
47:44here and we'll talk about this more when
47:46we get into annexa controls but we need
47:49to define which life cycle stages the AI
47:52governance standard applies to and those
47:54are defined here uh in this document and
47:57we have eight different life cycle
47:58stages these are recommended by ISO 5338
48:03which is another nonnormative reference
48:05it is an informative reference it is not
48:07mandatory but it gives you a good set of
48:10guidelines when you're creating your AI
48:13system life cycle stages and it helps
48:15you do these types of evaluations. So,
48:18we've done our system assessment and
48:20then in this case we're going to uh this
48:22applies to Google Workspace business
48:24standard using the Gemini 2.0 model or
48:26another model and we're going to say
48:28that this does reach our threshold of
48:31requiring an AI impact assessment
48:33because this could be considered general
48:34purpose AI according to the European
48:36Union AI act in which case we will do an
48:39impact assessment for this system. So
48:41we'll look at categories of people and
48:43groups affected, environmental
48:45sustainability impacts, economic life
48:47opportunity impacts, and so on and so
48:49forth. And on each of these assessments,
48:51you'll see the specific annex controls
48:54that are implicated by these
48:56assessments. This helps us track exactly
48:58why we're doing a given assessment and
49:00where it maps back to in the ISO 4201
49:04requirements for annexa, which we will
49:06talk about in depth later in this
49:08course. Okay, so there you have it.
49:10Those are the clause 8 requirements and
49:14how to meet them. Welcome to clause 9.
49:16So for 9.1, we pretty much already
49:19covered this when we addressed the
49:20objectives and the resourcing in clauses
49:236.2 and 7. So I'm not going to go back
49:27to rehash this. Review those sections if
49:29you'd like a refresher. But basically we
49:31tied our objectives to the monitoring
49:33and measurement as well as the analysis
49:35and and evaluation by providing
49:37thresholds that our targets were for
49:40those given objectives and requirements.
49:42So it's key that you tie these things
49:44together in a comprehensive way which we
49:46did in the previous lessons. 9.2. Okay.
49:50So this is where things get interesting
49:51and important. Clause 9.2 two requires
49:54that organizations pursuing ISO4201
49:57certification have an effective internal
50:00audit function. This means an impartial
50:02auditor who is not involved in control
50:04design or implementation reviews the
50:07structure and effectiveness of the
50:09controls of the AI management system. If
50:12you have multiple employees involved in
50:13control design, what you can do is you
50:15can have them check each other's work
50:17such that they are not reviewing exactly
50:19what they did. They're reviewing what
50:20their colleagues did to make sure that
50:22it aligns to ISO 420001 requirements and
50:25the organization's requirements. That's
50:27a key one. So, if you document
50:28something, you're going to need to make
50:30sure that you follow it and that your
50:31internal audit also addresses whether or
50:34not you're following your own
50:35procedures. You can also have an outside
50:37party for example stackaware conduct
50:40your internal audit for you. And what
50:42we'll do is if we're involved in the
50:44control design and implementation, we'll
50:46take someone who was not and have that
50:49person do the internal audit or check
50:51the pieces that maybe the impletor has
50:54touched and cannot do the internal audit
50:57for. Internal auditing could be an
51:00entire course and it already is in uh
51:03several different media. So, I'd
51:05recommend checking those out. But what
51:07I'll say is something that's helpful and
51:09Stackaware uses is having an internal
51:11audit plan, which I will show you here.
51:14And essentially what this is is just a
51:16timeline showing when we're conducting
51:18our internal and external audits as well
51:20as the results of those. We track this
51:22uh mostly via jer tickets. That way it's
51:24tagged and timestamped and you can
51:27review what happened when. And then um
51:29historically we have done some stuff on
51:31Google Drive. That's why that folder is
51:33there. And you can see that we have a
51:35plan for both internal and external
51:37audit preparation that goes all the way
51:39through uh the end of 2026. So recommend
51:42having a solid audit plan to make sure
51:44that you're meeting those clause 9.2
51:47requirements. Let's talk management
51:49review. Clause 9.3 of the ISO 4201
51:52standard requires that you conduct
51:54management reviews on a regular basis.
51:56These must include top management and
51:59top management are those who determine
52:01the strategic course of the
52:03organization. So if you have someone who
52:05is making decisions related to the AI
52:07management system and that person has
52:09veto authority and his or her
52:11considerations dominate above all else,
52:14it's likely that that's that that person
52:16will be considered top management and
52:18needs to participate in management
52:19reviews. I would say you need to have
52:21management reviews at least once a year,
52:24although I'd say quarterly is better and
52:27you may want to have monthly if your AI
52:29program is moving fast. Management
52:31review is a little tricky because you
52:33absolutely must address certain items in
52:36that review. If you miss those items,
52:39that can trigger non-conformities. So,
52:41it may seem a little cookie cutter, but
52:43you absolutely need to have a very solid
52:45management review template and procedure
52:48before you go into those meetings to
52:50make sure you hit everything. So, what
52:52I'm going to do is I'm going to pull up
52:53a stackware template for conducting an
52:56AI management system review. We have
52:57this as well as one for doing a joint
52:59ISO 27,0001 420,0001 management review,
53:03but we'll just focus on 42,0001 here. So
53:06what we do is we have the agenda up
53:08front which addresses status of actions
53:10from previous reviews, changes in
53:12internal external issues, changes in
53:14needs and expectations, aimed
53:16performance, looking at nonconformities,
53:18monitoring and measurement audit results
53:20and continual improvement opportunities.
53:22Stackaware also looks at new risk
53:25assessments and treatments new um during
53:28management review just to make sure
53:29we're staying on top of those. That is
53:31not a requirement of the standard. It is
53:33something that we do because we find it
53:35to be helpful and effective. All right.
53:37So if you look at status of actions for
53:39previous management review, we get very
53:42cookie cutter with this. So what we do
53:44is we have a management review jura
53:46filter that is tagged with a label of
53:48management review. And this opens up
53:50that filter and make sure that we hit
53:52every item that is open and that we
53:54address it and close it out or schedule
53:56it for future management review. You can
53:58put things on the slide. That's why I
53:59have the action items placeholder here.
54:01But we prefer to keep it super simple
54:03and make sure we hit every requirement
54:05by just using the Jira filter. Okay.
54:07Changes in internal and external issues.
54:09These are items that are pending
54:11management review. Earlier in the course
54:13for clause 4, I showed you the confirmed
54:16applicable issues. These are issues that
54:17are pending management review. This is
54:19blank right now, but this does sync to
54:21our register of those issues so that we
54:23will know what we need to cover. Um and
54:26we have this reminder here to refresh
54:28the table to view the issues for
54:29discussion. This makes sure that you
54:31don't miss any changes in internal and
54:33external issues which can trigger a
54:35nonconformity. We also address the
54:37likely not applicable issues. I
54:38mentioned why earlier so that you have
54:40documented rationale why an issue does
54:42not apply to your organization and AI
54:45management system. Needs and
54:46expectations. Same thing here. These are
54:48likely applicable issues but still
54:50pending management review and require
54:51discussion. And then we also tackle
54:53likely not applicable issues here. Okay.
54:56Non-conformities and corrective action.
54:58Again, this is something where I
54:59recommend just having a filter in your
55:02workflow management tool. We use Jill
55:03Jira applying a label and make sure you
55:06address every non-conformity and
55:08corrective action that you have not
55:10touched since your last management
55:12review. And make sure you close it out
55:14or you have a clear path for resolution.
55:16I'll talk more about non-conformities in
55:19the next clause, but it's key that you
55:21have a centralized area for tracking all
55:23these things. If you have information in
55:25lots of different repositories, it's
55:26going to get tricky and you're going to
55:28miss something. Monitoring and
55:29measurement. We've shown you the uh
55:31monitoring and measurement register
55:33earlier. I've already addressed that.
55:34What we do is we review the results,
55:36compare them to our thresholds, and
55:39confirm or deny whether we're on course
55:41or not. Audit results. We have both an
55:44internal audit and external audit
55:46filter. And we'll tag things using
55:48labels accordingly to make sure that we
55:50review everything we need to review and
55:52that we knock it out in the management
55:55review. And then continual improvement.
55:57We'll talk more about this in a little
55:58bit, but we tag continual improvement
56:00issues with the OFI opportunity for
56:03improvement label in this filter. And we
56:06don't always go in-depth on every single
56:08one, but we'll review kind of the
56:10status, see how many we've closed out,
56:11and make sure that we are on track to
56:14continually improve our AI management
56:17system, which is a requirement of ISO
56:19420001. As I mentioned, we do a risk
56:21register review, not mandatory, but
56:23something I find useful for new risks
56:26and treatments. And then we've got a
56:27closing slide here reminding people
56:29about the whistleblowing program. We'll
56:30talk about that more in annexa. So ISO
56:334201 management reviews are cookie
56:36cutter. They are required to follow a
56:38certain format. You can cover more than
56:40is in the standard but you cannot cover
56:41less. You also need to make sure that
56:43top management is involved in the
56:45process every step along the way. Almost
56:47there. Clause 10. So clause 10 has two
56:51sub clauses. First of all, it has a
56:53continual improvement requirement. So
56:55you need to commit to continual
56:57improvement as part of your AI policy.
57:00That's something that top management
57:01needs to ensure is happening. So what
57:03does this mean from a realistic
57:04perspective? During your audits,
57:06internal and external, you may get
57:08findings that are called opportunities
57:10for improvement. These suggest that
57:12while you are meeting the requirement
57:14right now, if you do not address this
57:16issue in future audits, you will get a
57:19nonconformity or you may get a
57:21non-conformity. So it is critical that
57:23you track these opportunities for
57:25improvement and turn them into continual
57:27improvement exercises and uh tasks. So
57:31stackaware historically used Google
57:33sheets to track these opportunities for
57:36improvement. We now use Jira, but I'll
57:37show you our Google sheet uh which just
57:40has some items here that uh you know
57:43address how we tackle continual
57:46improvement and how we focus on ensuring
57:50that we are improving the way the system
57:52operates over time. So we've had
57:55proposal dates, we've had completion
57:56dates and those are all documented here.
57:58Now we're just doing uh Jira tickets.
58:01Additionally, something that ISO 420001
58:04requires is having a non-conformity and
58:06corrective action plan and procedure.
58:09So, you need to identify situations
58:11where you are not meeting your uh
58:14requirements of ISO 4201 or your own
58:17internal requirements and then document
58:19how you're going to fix those things. So
58:21again, we do this in Jira and we create
58:24Jira tickets based on our non-conformity
58:27procedure and I'll show you that right
58:28now. So what we have here is we have the
58:32non-conformity procedure and essentially
58:34we initiate the non-conformity procedure
58:36when you know organizational
58:38requirements are not met or management
58:39system requirements determine whether
58:41suspected actual or imminent loss to
58:43data CIA in which case that would kick
58:45off the incident response procedure
58:47report concerns via whistleblower uh you
58:50know if if appropriate if required um
58:52and then data owners are required for
58:54remediating the nonconformity incident
58:56or vulnerability beginning in RCA a a
58:59root cause analysis, documenting the
59:01root cause analysis, preserving that,
59:03and making sure that the nonconformity
59:05does not recur. The final step here is
59:07determining if there's a policy, risk
59:09treatment, continuous improvement, or
59:11other review recommended as a result of
59:13this nonconformity. Now, I won't share
59:16our full non-conformity register cuz it
59:18may have some things in there that might
59:20be security sensitive, but I'll tell you
59:21that historically, we have received
59:23non-conformities from external auditors.
59:25For example, in one case, we did not
59:28correctly follow our risk assessment
59:30procedure when we're onboarding a new
59:32system during an emergency. Um, we moved
59:35over to use the anthropic API because
59:37OpenAI was under a data retention order
59:39and we moved over quickly to use the
59:42anthropic API to avoid that indefinite
59:44retention. Now the non-conformity that
59:46resulted was we hadn't done our full
59:49risk assessment procedure against the
59:50anthropic API due to the time-sensitive
59:54nature of that situation. To fix this in
59:56future now we get notifications that are
59:59autogenerated whenever there's a new
1:00:00system but the risk assessment procedure
1:00:03has not been fully followed through yet.
1:00:05You'll continually get email
1:00:07notifications until you close out the
1:00:09procedure and everything is documented
1:00:11in the correct format. So that's an
1:00:12example of a nonconformity that led to a
1:00:15change in our procedure. It led to some
1:00:18technical modifications to ensure that
1:00:20we could hit the requirements and maybe
1:00:23even a little continual improvement in
1:00:24there. So there you have it. That is
1:00:26clause 10.2 of ISO4201. Okay. So we have
1:00:31wrapped up clauses 4 through 10 of how
1:00:34to build an AI management system
1:00:36according to the ISO 4201 specification.
1:00:39This is only half of your journey
1:00:41though. A key part of ISO4201 is
1:00:45implementing after you select the
1:00:47correct annex controls to treat the
1:00:50risks that you've identified as part of
1:00:52the process. So in the next section
1:00:54we're going to get into annexa and how
1:00:57to realistically implement it in an AI
1:01:00powered company. And here we go. We are
1:01:03now going into part two of the complete
1:01:07ISO 4201 certification road map for 2026
1:01:11and we are going to be talking annex
1:01:14controls in this section. So annexa is a
1:01:18set of recommended and optional controls
1:01:23for managing the risks that you have
1:01:26identified in the risk assessment
1:01:28process in clause 6.1.2
1:01:31too. NXA is a little tricky for a couple
1:01:34different reasons. First of all, I say
1:01:36optional because technically most of the
1:01:39controls are optional. Some of them are
1:01:42not. For example, you have to have an AI
1:01:44policy. It's also tricky because there's
1:01:47a lot of overlap between annex A and
1:01:50clauses 4 through 10. So what stackware
1:01:53has done is created a mapping that shows
1:01:57all these overlaps and group them into
1:02:00different categories and this is
1:02:01something that is in the description if
1:02:04you want to check it out. So what we'll
1:02:06do is we'll pull up this annex a control
1:02:08mapping and what you can see is we've
1:02:11got a couple different colors here.
1:02:12We've got this neon green which means
1:02:15that the control is implied by clauses 4
1:02:19through 10. As I mentioned things like
1:02:20the AI policy, we'll get into that.
1:02:22There are some additional administrative
1:02:24controls that are kind of policy
1:02:27procedureesque but they are in annex A.
1:02:29There are some data governance controls
1:02:31in blue. There are some technical
1:02:33controls in gray. And then there are
1:02:35three other categories that are covered
1:02:37by the AI system model and impact
1:02:40assessments which I've described
1:02:41previously. And essentially what
1:02:44stackaware does is it takes a bunch of
1:02:46these annexa controls that are somewhat
1:02:49duplicative and groups them into the AI
1:02:52system model and impact assessment
1:02:56processes. So without further ado with
1:02:58these laid out we're going to go to the
1:03:00annex key here. And basically what
1:03:02you're looking at is these are all the
1:03:05annexa controls contained in ISO 4201.
1:03:09and we're going to go section by section
1:03:12talking about ways to fulfill each of
1:03:15these controls. So, we're going to start
1:03:17with these ones in green starting with
1:03:202.2 and going to 3.2. So, 2.2 and 3.2 in
1:03:24my opinion are completely duplicative of
1:03:27clause 5.2 and 5.3. 5.2 being an AI
1:03:31policy, 5.3 being roles and
1:03:33responsibilities. So this is already
1:03:36tackled by existing requirements in the
1:03:39document. Now where it gets a little bit
1:03:41trickier is with 2.3 and 2.4. So 2.3
1:03:46requires alignment with other
1:03:47organizational policies and 2.4 requires
1:03:50review of the AI policy. 2.4 is pretty
1:03:53straightforward in that you should have
1:03:54a regular cadence for reviewing your AI
1:03:57policy. Stackaware uses a Jurro ticket
1:03:59that triggers on the 1st of January
1:04:01every year to make sure that we remember
1:04:04to review the AI policy and then
1:04:06document it accordingly. 2.3 is a little
1:04:10more complex, but it is relatively
1:04:12simple to implement in that you need to
1:04:14ensure the AI policy refers to and
1:04:17incorporates guidance from and for these
1:04:21other organizational policies. Let me
1:04:22show you an example. Okay, we are back
1:04:24in the stackaware AI policy template and
1:04:28if you scroll down to the policy,
1:04:31there's a requirement for the chief
1:04:34information security officer to propose
1:04:36to the respective owners updates to the
1:04:38following policies and procedures. And
1:04:40these are all things that are probably
1:04:42relevant for your AI policy. Business
1:04:45continuity, thirdparty risk, security
1:04:47awareness, vulnerability management,
1:04:49change management, so on so forth. So
1:04:51this policy is calling out to other
1:04:54policies and procedures for the
1:04:55organization saying that the owners need
1:04:58to at least consider the AI policy in
1:05:01updates to these additional documents.
1:05:04So really that's the core of this annexa
1:05:07control is making sure that you are
1:05:09integrating the AI policy with other
1:05:11organizational policies. Moving along to
1:05:14annex a control 3.3 reporting of
1:05:17concerns. The goal of this control is to
1:05:20allow primarily internal stakeholders
1:05:23but also external ones the ability to
1:05:26report concerns with respect to the use
1:05:28of AI. The best way to do this in my
1:05:31opinion is to have a whistleblower form
1:05:34that someone can complete anonymously.
1:05:36So specifically for stackaware you can
1:05:39go to whistleblower.stackaware.com
1:05:41stackaware.com and then you can navigate
1:05:44to this form which is a Zapier
1:05:46automation and you can input information
1:05:49about impropriety related to finance
1:05:52security HR and artificial intelligence
1:05:54use. You have the option to have an
1:05:56email to contact you if you want to be
1:05:59contacted. We also have whistleblower
1:06:01stackawware.com which is also an option
1:06:03but not anonymous like this unless you
1:06:06hide your identity. So, couple key
1:06:09things to keep in mind for this are that
1:06:12you need to have a way for anonymous and
1:06:16confidential communications and make
1:06:19sure that you test that these forms work
1:06:21and that they're being monitored because
1:06:23during audits, someone may ask you to
1:06:26prove that there is an actual workflow
1:06:28related to whistleblowing that actually
1:06:30does something. So another important
1:06:32thing to do is to make sure that people
1:06:35know how to access this form and that
1:06:38they should access this form. So
1:06:40something that I'll also show you here
1:06:42is our master services agreement which
1:06:45is publicly available and this is
1:06:46integrated into our contracts. We have a
1:06:50section here that says provider welcomes
1:06:52reports from whistleblowers about all
1:06:54these things and you can report via
1:06:56email or anonymously via internet form
1:07:00linking to that form that we were just
1:07:03at. These are also baked into contractor
1:07:05agreements with those who are supporting
1:07:07the stackawware AI management system and
1:07:10that gives us evidence that we are
1:07:12actively soliciting reporting of
1:07:14concerns with respect to artificial
1:07:17intelligence use. Next up is annex a
1:07:19control 4.2 which is resource
1:07:22documentation. In my assessment, this is
1:07:24almost identical to the clause 7.1
1:07:28requirements and the ways that I showed
1:07:31you earlier to depict the resources for
1:07:34meeting your AI objectives will almost
1:07:37certainly meet the requirements of this
1:07:39control. So, refer back to that section
1:07:42if you'd like more information on how to
1:07:44meet NXA4.2 requirements. Next up is
1:07:48annex a control 4.3 data resources. This
1:07:51is pretty duplicative of the annex 8.7
1:07:54controls and it focuses on providence
1:07:57date of last update categories labeling
1:07:59processes quality retention and disposal
1:08:02a bunch of different things. And the way
1:08:05that stackware handles this is through
1:08:07our model and system assessment
1:08:10procedures. So I'm going to head over to
1:08:11the model system and impact assessment
1:08:14register. And if we do a controlF for
1:08:174.3, we'll see it is under retention and
1:08:21disposal. Um it's under if you go to the
1:08:23model assessment tab, it's under
1:08:25intended use, quality, it's under known
1:08:28or potential bias, date of update or
1:08:30modification. It's basically covered for
1:08:32all of these categories or many of these
1:08:34categories on the model assessment
1:08:36procedure. So to get this information,
1:08:39if you're training the model, you'll
1:08:40have this data available from your
1:08:42engineering and data science team. But
1:08:43if you're not, if you're using a
1:08:45third-party model, open source or
1:08:47proprietary. I find that model cards are
1:08:49especially helpful to get this type of
1:08:51data. So for example, this looks at GPT
1:08:545.2 and it broadly describes the 5.2
1:08:58training data. It mentions diverse data
1:09:00sets including information that is
1:09:01publicly available, things from
1:09:03partners, things from human trainers,
1:09:05but it is relatively vague. So it
1:09:07depends whether or not you are putting
1:09:10this above or below your AI governance
1:09:12standard. But this could represent a
1:09:14risk in terms of the vagueness of the
1:09:17data providence and this could create a
1:09:20risk on your risk register. Again, it
1:09:21depends on what your requirements are
1:09:24from an AI governance standard
1:09:25perspective. But you do need to
1:09:27establish a clear set of criteria for
1:09:29what's going to trigger a risk and what
1:09:31is not for 8.4.3 and a lot of the other
1:09:35data related controls in ISO 4201. NXA
1:09:39controls 4.4 4 and 4.5 are somewhat
1:09:42similar in that these are addressed in
1:09:45the model and system assessment
1:09:47procedures. 4.4 looks at things like
1:09:51algorithm types, uh, data conditioning
1:09:53tools, optimization methods, and those
1:09:56are tracked in the AI model assessment
1:09:58here. So you see those match up to 4.4.
1:10:01And then 4.5 is focused on system and
1:10:03computing resources like associated
1:10:05hardware where the process is running.
1:10:08and we track that here. Uh under we've
1:10:11got physical location and then we have
1:10:13the software and hardware for design,
1:10:15development and deployment. So those are
1:10:17things that are available through things
1:10:19like subprocessor lists for AI systems
1:10:22for uh including software bills of
1:10:25material things of that nature is where
1:10:27you would get this type of information
1:10:29to evaluate the AI system or model
1:10:31against your AI governance standard. NXA
1:10:34control 4.6 Six is focused on human
1:10:37resources and this in my opinion is
1:10:40pretty duplicative of clause 7.2 in the
1:10:43first part of the course because it
1:10:45talks about expertise related to AI
1:10:48systems and domain knowledge and things
1:10:51like that. The only difference is that
1:10:53it also talks about oversight of AI
1:10:55systems and this ties directly into the
1:10:59accountability and human oversight
1:11:01aspect of the system assessment. So if
1:11:04you look at column O here,
1:11:06accountability and human oversight is
1:11:08something that does correspond with 4.6
1:11:11and is something that we do track. The
1:11:13way you can evaluate this is through
1:11:16looking at terms of service. For
1:11:17example, if they put all the
1:11:19accountability on the user and say that
1:11:21the user is responsible for all outputs,
1:11:23that would make things clear there. If
1:11:25the system is operating
1:11:26semi-autonomously, if it has the ability
1:11:28to make decisions or call other
1:11:30functions without human approval, then
1:11:32that would certainly be something to
1:11:34look at. And having clear standards on
1:11:36what is acceptable and what is not is
1:11:38important here. So, you know, for the
1:11:39public data systems, entirely automated
1:11:42decision-m is acceptable. Here the uh
1:11:45decision making making related to
1:11:47confidentiality of information uh must
1:11:49be deterministic and for the high-risk
1:11:52systems these need to undergo evaluation
1:11:54to ensure compliance with regulatory and
1:11:56ethical requirements. So for example if
1:11:59you are using an AI system for HR or
1:12:02recruiting then it would likely trigger
1:12:04the high-risk requirements and demand a
1:12:06certain level of human oversight. What
1:12:08that is depends on your applicable
1:12:11requirements. Okay. So, annex A.5
1:12:15focuses on AI impact assessments. And in
1:12:19my opinion, this is entirely duplicative
1:12:21of the clause 6.1.4
1:12:24and 8.4 requirements to do just that.
1:12:27So, I think this is kind of a trap to
1:12:29see if anyone says that they don't need
1:12:32to do AI system impact assessments
1:12:34because it is required by clauses 6.1.4
1:12:37and 8.4. You definitely need to do these
1:12:39and follow the procedure that we
1:12:41described in the earlier parts of this
1:12:44lesson. What annexa will give you here
1:12:46is a little bit more guidance on how to
1:12:48do these things as well as annex which
1:12:50has a lot more implementation details
1:12:52for how to do your impact assessments.
1:12:56Okay, so moving on to 6.1.2 objectives
1:12:59for responsible development of AI
1:13:01systems. This is something that requires
1:13:04you to consider a variety of different
1:13:06things like testing requirements, human
1:13:08oversight requirements, training data
1:13:10expectations, release criteria,
1:13:13usability and control, and things like
1:13:15change control. So, this is a pretty
1:13:17broad list and I would recommend going
1:13:20back to your AI objectives to help to
1:13:22flesh these out. Additionally, in the
1:13:25stackaware AI system assessment, if you
1:13:27look at things like human oversight,
1:13:30that's definitely something covered by
1:13:316.1.3, as well as testing and release
1:13:34criteria, that's also covered.
1:13:36Accessibility, usability, documentation,
1:13:38those are all things covered by 6.1.3.
1:13:41So some things to look at for testing
1:13:43and release criteria is seeing if the
1:13:45company that's making the AI system has
1:13:47ISO 27,0001, 420,0001 or sock 2
1:13:51attestations or certifications because
1:13:53these require having change control
1:13:55processes in place. So that can give you
1:13:57some hope that they are in fact
1:13:59following those procedures and can
1:14:01support an evaluation of change control
1:14:03and release criteria. Moving along to
1:14:066.2.2
1:14:08and 6.2.3.
1:14:10These are focused around AI system
1:14:12requirements, specifications and
1:14:14documentation. So you can record these
1:14:17things in your system assessment
1:14:19register as well as your model
1:14:21assessment register which I showed
1:14:23previously. Additionally, some things
1:14:24you'll want to have are architectural
1:14:26diagrams for any AI systems that you're
1:14:28building or relying on if you're if
1:14:30you're deploying them uh but you're not
1:14:32building them. As well as documentation
1:14:34of how you are integrating these with
1:14:37other systems, deterministic systems, if
1:14:39you're using them in no code workflows,
1:14:40having the steps in that workflow will
1:14:44be helpful to provide evidence that you
1:14:46are applying appropriate controls to
1:14:49meet these requirements. Moving along to
1:14:51the additional AI system life cycle
1:14:53controls, we have 6.2.4 which is focused
1:14:56on AI system verification and
1:14:57validation. So important elements here
1:15:00would be to have evidence of
1:15:01pre-eployment testing, any penetration
1:15:03testing or red teaming that you might
1:15:05have done for your AI system, that would
1:15:07be helpful here. If vendors can provide
1:15:08data on how they've done verification
1:15:10and validation, that would also be
1:15:12useful. Moving to 6.2.5 for AI system
1:15:15deployment. This is where having change
1:15:17control logs, evidence of going through
1:15:19release procedures will be especially
1:15:22helpful. Tracking AI systems through
1:15:24various stages, making sure that they're
1:15:27going through release gates related to
1:15:29their performance, their security, their
1:15:31reliability. Moving to annex a control
1:15:346.2.6 system operation and monitoring.
1:15:38This is more focused on the status,
1:15:41uptime, the availability, reliability of
1:15:44AI systems. So you can look at things
1:15:46like service level agreements to
1:15:48determine whether you're meeting your AI
1:15:50governance standard. You can also look
1:15:52at status pages to see how frequently
1:15:55systems has suffered downtime
1:15:57historically and compare that to your AI
1:15:59governance standard. NXA control 6.2.7
1:16:02is focused primarily on technical
1:16:05documentation. The way I read this is
1:16:07it's for users of the AI system. So
1:16:09making sure that if you're building an
1:16:10AI system, there's enough documentation
1:16:12to explain users to users how to operate
1:16:14it or that it's intuitive enough to do
1:16:17so using a natural language interface.
1:16:19And making this available to auditors
1:16:21will be important to confirm adherence.
1:16:24It could also apply to thirdparty
1:16:25systems that you're using, making sure
1:16:27that they provide enough documentation
1:16:29for you to use. 6.2.8 Eight is focused
1:16:31on recording of event logs. And having a
1:16:34clear policy in place for how long you
1:16:36retain certain types of event logs for
1:16:38how long is critical here because
1:16:40auditors will expect to see these logs
1:16:43to understand how long they're retained
1:16:45and make sure that it's meeting your AI
1:16:47governance standard and your other
1:16:48operational requirements for your AI
1:16:51management system. Basically all of
1:16:52Annex A.7 is focused on data for AI
1:16:56systems which is handled by the model
1:16:59assessment. A little bit for 8.7.2 is
1:17:02handled by the system assessment. And
1:17:03the model cards for commercial or open
1:17:06source models are a good place to pull
1:17:08this type of data. Obviously if you're
1:17:10training proprietary models then you
1:17:11should have this internally available
1:17:13from your engineering and data science
1:17:14teams. So if we look at the AI model and
1:17:18system assessment register here, we've
1:17:20got the uh providence, we've got
1:17:23categories, we've got quality, we've got
1:17:25known or potential bias, preparation,
1:17:26conditioning tools and techniques. These
1:17:28are all things that are covered by annex
1:17:308.7. And also on the system assessment
1:17:33side of things, we have the um
1:17:36transparency, explanability, and
1:17:38interpretability that is also covered by
1:17:40the annex 8.7 controls, specifically
1:17:437.2. NXA control 8.2 is very similar to
1:17:47the 8.6.2
1:17:49series focused on documentation and I
1:17:52believe it's duplicative. It requires
1:17:54that you have sufficient documentation
1:17:56for users. Moving on to 8.3. This is a
1:18:00requirement to have the ability to
1:18:02receive reports regarding your AI
1:18:04systems from external sources. A great
1:18:07and free way to do this is through a
1:18:08vulnerability disclosure program. If you
1:18:10look at stackaware's VDP, we
1:18:12specifically call out artificial
1:18:14intelligence systems where the outputs
1:18:16are offensive, unethical, illegal, or
1:18:18have otherwise adverse impacts. And we
1:18:20explain exactly how you contact us if
1:18:23you have any concerns about our AI
1:18:25systems. Moving to communication of
1:18:27incidents. So this is something that we
1:18:31do using our trust center. We have the
1:18:33ability to broadcast alerts regarding
1:18:36incidents. We haven't had any AI
1:18:38specific incidents that have reached our
1:18:40threshold for reporting to customers,
1:18:42but we have had vendors that have had
1:18:44security incidents and we do broadcast
1:18:46these on our trust center giving all the
1:18:49details that we need. We also will
1:18:50follow up directly with any impacted
1:18:52customers if there are any if we have
1:18:55concerns about data confidentiality,
1:18:57integrity or availability. For 8.5, we
1:19:01also leverage our trust center heavily
1:19:03to meet this requirement. We provide
1:19:05lots of information on our AI systems
1:19:09under this section here where we talk
1:19:12about AI risk management, AI security.
1:19:14We provide an overview, thirdparty due
1:19:16diligence. We go in depth and provide
1:19:18useful information for our customers and
1:19:21other interested parties if they want to
1:19:22evaluate our AI systems. Coming down the
1:19:25home stretch here. So for annex 8.9,
1:19:29we're starting with processes for
1:19:31responsible use of AI systems. So this
1:19:33is pretty broad and the implementation
1:19:35guidance talks about required approvals,
1:19:38legal requirements applicable to the
1:19:40organization. I would recommend having
1:19:42this documented in policies, procedures.
1:19:44You can use some of your existing things
1:19:46like your risk assessment procedure,
1:19:47your impact assessment procedure to help
1:19:49meet these demands as well as your
1:19:51change control and approval logging
1:19:53whether you're using Jira or a similar
1:19:56workflow system. Objectives for
1:19:58responsible use of AI systems is
1:20:01something that is heavily mirrored in
1:20:03clause 6.2 where you build out your AI
1:20:06objectives and explaining how you meet
1:20:08these in that document but also in the
1:20:11system assessment can be helpful. So for
1:20:14example, this talks about fairness,
1:20:15accountability, transparency and these
1:20:17are all things that are covered
1:20:19specifically in the system assessment
1:20:21register as you can see here. So we
1:20:24knock out a lot of these requirements in
1:20:25the system assessment register and these
1:20:28are things you can find from
1:20:29documentation for the AI system. If
1:20:31you're building your own AI models,
1:20:33you'll want to test these types of
1:20:35things, understand, you know, is it
1:20:37benchmarked against the the BBQ, which
1:20:39is a industry standard way of evaluating
1:20:42for bias. Are you um making these
1:20:44accessible to all types of users? Are
1:20:46you disadvantaging certain types of
1:20:48users? These are all types of things to
1:20:50consider when you're building and
1:20:51deploying AI systems. Intended use of AI
1:20:54systems is covered by annexa 9.4. And
1:20:59the way we track this is in the system
1:21:01assessment register. We look at the
1:21:03intended purpose of the system which
1:21:06corresponds to a variety of different
1:21:08requirements. And we make sure that
1:21:10according to our AI governance standard,
1:21:12there are restrictions on how a system
1:21:13can be used. So for the lowest risk
1:21:15system, it can be used for any lawful
1:21:17purpose, even if it's not designed for
1:21:18it. But for a high-risk system, it can
1:21:20only be used for purposes documented by
1:21:23the developer. And of course, we explain
1:21:25what the exact purpose of the system is
1:21:27in the relevant row as part of our
1:21:29register. Annex A.10.2
1:21:32allocating responsibilities. This is a
1:21:34pretty vague one in my opinion. I think
1:21:36it could be covered by your roles and
1:21:37responsibilities like in your AI policy
1:21:39and other procedure documents. It could
1:21:41also be covered through your contracts
1:21:43with various parties like suppliers with
1:21:46customers and that bleeds kind of into
1:21:48the next two which are A10.3 which is
1:21:51focused on suppliers. Here I'd make sure
1:21:53that you have appropriate AI specific
1:21:54controls in your contracts with your
1:21:56vendors. A good example is OpenAI in
1:21:59their services agreement which applies
1:22:01to their business offerings like their
1:22:03API chat GBT enterprise and chatgbt
1:22:05business. They have certain requirements
1:22:07for how they're going to treat your
1:22:08data. for example, uh you know, they're
1:22:11going to, you know, make clear that they
1:22:13will receive your input, but you retain
1:22:15all ownership rights to it. They will
1:22:17take certain security measures. They
1:22:19will maintain confidentiality of your
1:22:21data. They won't train on it. These are
1:22:23the types of things that you should have
1:22:24in place with your suppliers. And it
1:22:26could also extend if they are data
1:22:29suppliers and you're building models
1:22:30using their data, making sure that there
1:22:32are contractual standards for what they
1:22:34are providing to you when it comes to
1:22:35quality, bias, provenence, things of
1:22:38that nature. And going to the final
1:22:40annex control 10.4 which focuses on
1:22:43customers. This is a way to track how
1:22:47you interact with your customers making
1:22:49clear what the roles and
1:22:50responsibilities are. One piece of
1:22:52evidence that I use is our master
1:22:54services agreement where we talk about
1:22:56confidentiality with our customers.
1:22:58Specifically, we point out that we will
1:23:00not train on confidential information of
1:23:03theirs and we will make sure that uh you
1:23:06know it is protected as part of our
1:23:09master services agreement. All right, we
1:23:11made it through all the annexa controls
1:23:12in ISO 4201. Now, the way that you take
1:23:16all of your annexa controls and describe
1:23:18how you're using them is something
1:23:19called the statement of applicability.
1:23:21Clause 6.1.3 requires that you establish
1:23:24a statement of applicability explaining
1:23:26which annex a controls you are using and
1:23:28which ones you are not. You can also add
1:23:30voluntary additional controls from other
1:23:33frameworks if you'd like. That's
1:23:34absolutely possible and even encouraged.
1:23:37And what we do in the statement of
1:23:38applicability is list out those annexa
1:23:41controls and provide an inclusion
1:23:42justification. This needs to be well
1:23:45thought out. You can't just simply say
1:23:47best practice because auditors will dig
1:23:49into that. Ask why. If you have a
1:23:51control and there's not a good reason
1:23:52for it, then that's probably a waste of
1:23:55money and resources. So have a good
1:23:57reason why you're applying a certain
1:23:59control. Additionally, you'll have an
1:24:00exclusion justification if you're not
1:24:02applying that control. For Stackaware,
1:24:04we apply all of the annexa controls, so
1:24:07it's not applicable for all of them, but
1:24:09you'll want to go down the list and make
1:24:10sure that you spell out why you were
1:24:13applying each of these annex controls.
1:24:16and your statement of applicability will
1:24:18be something that your auditor looks
1:24:20closely at. So with that, we have made
1:24:22it through the entire ISO 4201 AI
1:24:26management system course. We've looked
1:24:28at certification timelines. We've looked
1:24:30at requirements in clauses 4 through 10.
1:24:33We've gone through the annexa controls,
1:24:35provided some evidence of how you can
1:24:37implement these, and discuss the
1:24:39statement of applicability. So look, the
1:24:41information in this free course
1:24:43genuinely has the power to completely
1:24:44transform your AI risk management
1:24:46program and protect your company from
1:24:48the millions in dollars in fines under
1:24:50laws like the EU AI act and Colorado
1:24:53SP205, a lengthened sales cycle from
1:24:55customers demanding and you not having
1:24:57ISO 420001 certification and disaster
1:25:00scenarios like Samsung leaking
1:25:02proprietary code or Amazon losing almost
1:25:04a million half dollars from unintended
1:25:06chat GBT training. At this point, you
1:25:08have two options. Option one is try to
1:25:11implement all of this yourself, spending
1:25:12the time, money, and headache figuring
1:25:14it out in a step-by-step process. All
1:25:17the problems you will definitely face
1:25:19doing the first time include translating
1:25:21ISO 420001's dense requirements into
1:25:24language that can actually drive
1:25:26operational processes. Building
1:25:27quantitative risk assessments instead of
1:25:29using useless low, medium, and high type
1:25:32heat maps. conducting AI impact
1:25:34assessments that examine economic,
1:25:36environmental, legal, normative, and
1:25:38human rights effects. Implementing all
1:25:4138 annex A controls in a way that
1:25:43satisfies external auditors. Managing
1:25:45the certification timeline starting from
1:25:47scratch and going all the way through a
1:25:49stage 2 audit, maintaining continuous
1:25:51monitoring as regulations evolve and
1:25:53your AI systems change, and avoiding
1:25:55compliance drift that creates audit
1:25:57findings and potentially even
1:25:59certificate suspension. Option two is
1:26:01get help from AI riskmanagement experts
1:26:04who've achieved ISO 420001 certification
1:26:06for themselves and helped clients like
1:26:09Elios Rightway and Acurus also get ISO
1:26:12420001 ready. And if we're being honest,
1:26:14if you're not already ISO 420001
1:26:16certified, you definitely have something
1:26:18to learn and could probably use some
1:26:19help. That's why I want you to click on
1:26:21the first link in the description and
1:26:23book a call with me to discuss ISO4201
1:26:26readiness. On that call, we'll review
1:26:28your current AI governance posture,
1:26:30identify the gaps between where you are
1:26:32in the ISO 420001 requirements, map out
1:26:34your 90-day implementation timeline, and
1:26:36show you exactly how we'll build your
1:26:38complete AI management system, including
1:26:41all assessments, documentation,
1:26:42policies, controls, and explain how
1:26:45we're going to get you ready for the
1:26:46audit. We provide full service white
1:26:48glove implementation where we actively
1:26:50build your AI management system for you.
1:26:52So, if that's what you want, click the
1:26:54link in the description, book a call
1:26:55with me, and I'll speak to you

About this transcript

This page contains the full transcript of The Complete ISO 42001 Certification Roadmap For 2026 (FREE AI Governance Course) by StackAware, generated from the public captions YouTube serves with the video. The transcript has 14,558 words across 2,275 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.