Self-policing AI does not happen by accident. It happens because top management decides it will, puts it in writing, and makes sure someone owns it. That is the job of Clause 5.

In the previous post in this series, we looked at Clause 4, Context of the Organization, and how understanding your environment, stakeholders, and role in the AI ecosystem lays the foundation for responsible AI. But knowing your context is only the first step. Someone has to act on it, and in ISO/IEC 42001 that responsibility starts at the top.

Clause 5, Leadership, sets out what top management must do to make an Artificial Intelligence Management System (AIMS) real. It covers leadership commitment, the AI policy, and the assignment of roles, responsibilities, and authorities. Together, these requirements answer a question every self-policing program must face: who is accountable when the AI gets it wrong?

Why Self-Policing Needs Visible Leadership

Internal oversight only works when people believe it matters. If AI governance is seen as a side project for a compliance team, it will be bypassed the moment a deadline or a revenue target gets in the way. When executives visibly own it, fund it, and ask about it, governance becomes part of how the organization does business.

ISO/IEC 42001 recognizes this by placing leadership requirements directly on top management, the people who direct and control the organization at the highest level. Responsibility for tasks can be delegated. Accountability for the management system cannot.

5.1 Leadership and Commitment

Top management must demonstrate leadership and commitment to the AIMS. In practice, that means:

• Setting direction: ensuring the AI policy and AI objectives are established and are compatible with the organization’s strategic direction.
• Integrating governance: building AIMS requirements into everyday business processes rather than running them in parallel.
• Providing resources: making sure the people, budget, tools, and time needed for the AIMS are available.
• Communicating importance: explaining why effective AI management matters and why conforming to AIMS requirements is expected.
• Driving results: ensuring the AIMS achieves its intended results and directing and supporting people who contribute to it.
• Promoting improvement: encouraging continual improvement and supporting other managers in showing leadership in their own areas.

For self-policing, this is the difference between a program that exists on paper and one that has teeth. When leaders commit resources and expect results, internal controls are far more likely to be used, respected, and improved.

5.2 AI Policy

Top management must establish an AI policy that is appropriate to the organization’s purpose, provides a framework for setting AI objectives, and includes commitments to meet applicable requirements and to continually improve the AIMS. The policy must be available as documented information, communicated within the organization, and made available to interested parties as appropriate.

A strong AI policy is the organization’s own rulebook. It states, in plain terms, what the organization will and will not do with AI. Good policies typically address the principles that guide AI use, such as fairness, transparency, accountability, privacy, and safety, and they connect to related policies on information security, data protection, and quality. The policy should be specific enough to guide real decisions and flexible enough to evolve as technology and regulation change.

5.3 Roles, Responsibilities, and Authorities

Finally, top management must ensure that responsibilities and authorities for relevant roles are assigned and communicated. At a minimum, someone must be responsible for making sure the AIMS conforms to the standard and for reporting on its performance to top management.

This requirement is where self-policing becomes personal. Every AI system should have a clear owner. Every risk decision should have a named approver. Every escalation path should lead somewhere. Without defined roles, problems fall between teams, and no one feels empowered to stop a system that is behaving badly.

Putting Clause 5 to Work: Practical Steps

1. Secure a named executive sponsor. Choose a senior leader who will champion the AIMS, remove obstacles, and answer for its performance.
2. Draft the AI policy with real input. Involve legal, IT, data, operations, and business leaders so the policy reflects how AI is actually used.
3. Tie the policy to objectives. Make sure every commitment in the policy can be traced to measurable AI objectives developed under Clause 6.
4. Build a responsibility matrix. Use a RACI or similar tool to show who is responsible, accountable, consulted, and informed for each AI system and process.
5. Give people the authority to say stop. Make it clear who can pause or withdraw an AI system when it produces harmful or unexpected results.
6. Put AI governance on the leadership agenda. Schedule regular reporting on AIMS performance so leaders see results, not just activity.

Common Pitfalls to Avoid

• Delegating accountability away. Handing AI governance entirely to a single department signals that leadership is not truly involved.
• A policy nobody reads. A generic, copy-and-paste AI policy that is never communicated or applied gives no real direction.
• Responsibility without authority. Assigning people to oversee AI without the power to act on what they find undermines the whole program.
• Ignoring shadow AI. Leaders who do not ask how AI is being used across the business may not realize where their policy is being bypassed.

The Bottom Line

Clause 4 tells an organization where it stands. Clause 5 decides who leads. Self-policing AI depends on leaders who commit resources, set clear rules through the AI policy, and make sure every role in the system knows what it owns. When accountability is visible at the top, it tends to be taken seriously everywhere else. In the next post, we will look at Clause 6, Planning, where that leadership turns into concrete risk assessments, impact assessments, and AI objectives. For further information email us at pjr@pjr.com or for a quote for ISO 42001 certification Click Here.

Your ISMS Was Built Before Your AI Was

If your organization added AI tools, models, or data pipelines after your last ISO/IEC 27001 risk assessment, your Information Security Management System (ISMS) may no longer describe how information actually moves through your business.

AI changes where data goes, who (or what) can access it, and what can be learned from it.

A customer record pasted into a public chatbot, a training dataset copied to a new cloud region, or a model that quietly memorizes sensitive inputs can each create risks your current Statement of Applicability never considered.

The good news: ISO/IEC 27001:2022 already gives you the framework to manage these risks. The Annex A controls you rely on today still apply.

They simply need to be interpreted, scoped, and evidenced with AI in mind. This guide shows you how.

Why Traditional Annex A Controls Fall Short

Most Annex A controls were written with conventional IT assets in mind: servers, applications, databases, and the people who use them. AI pipelines break several of the assumptions those controls quietly rely on.

• Data becomes part of the asset. Once training data shapes a model, the model itself can carry traces of that data. Deleting the source file does not necessarily remove the information.
• Inputs are instructions. In AI systems, user prompts and retrieved content can change system behavior, blurring the line between data and code.
• Usage spreads faster than governance. Employees can adopt AI tools in minutes, often outside procurement, IT review, or your asset inventory.
• Suppliers multiply. A single AI feature may depend on a model provider, a hosting platform, a vector database, and open-source components, each a link in your ICT supply chain.
• Data crosses borders by default. Inference and training workloads are often routed to wherever compute is available, not where your data residency commitments say it should stay.

None of this requires abandoning your ISMS. It requires revisiting your context (Clause 4), your risk assessment and treatment (Clause 6.1), and the controls you selected in your Statement of Applicability.

The AI Vulnerabilities Your Auditor Will Ask About

Shadow AI

Shadow AI is the use of AI tools, plugins, or models without the knowledge or approval of IT and security teams.

An employee who pastes source code, contract terms, or customer data into an unapproved chatbot has transferred information outside your controlled environment, often to a provider with no supplier agreement in place.

Shadow AI undermines your asset inventory, acceptable use rules, supplier controls, and information transfer controls at the same time. If it isn’t in your inventory, it isn’t in your risk assessment.

Model Inversion

Model inversion is an attack in which an adversary queries a trained model and uses its outputs to reconstruct sensitive information from the training data.

Related techniques, such as membership inference, can reveal whether a specific individual’s record was used to train the model.

This means a model can leak confidential or personal data even when the underlying database is fully locked down.

Your access controls, data masking, and privacy controls must extend to the model and its outputs, not just the data store.

AI Risk to Annex A Control Mapping

The breakdown below maps common AI risks to the ISO/IEC 27001:2022 Annex A controls they affect, and shows how each control’s implementation should evolve.

Use it as a starting point for updating your risk assessment and Statement of Applicability; your final control selection should always follow your own risk treatment decisions.

Shadow AI

The risk: Employees use unapproved AI tools that move company data outside your controlled environment.

Annex A controls:

• 9 Inventory of information and other associated assets
• 10 Acceptable use
• 19 Information security in supplier relationships
• 3 Awareness, education and training

Traditional focus: Inventory of approved hardware, software, and data

What needs to change:

• Discover and inventory AI tools, plugins, and APIs in use
• Publish an AI acceptable use policy
• Route AI services through supplier review
• Train staff on what data may enter AI tools

Model inversion and membership inference

The risk: Attackers query a trained model to reconstruct sensitive training data or confirm whose records were used.

Annex A controls:

• 11 Data masking
• 34 Privacy and protection of PII
• 3 Information access restriction

Traditional focus: Restricting access to stored records

What needs to change:

• Treat trained models as assets that may contain sensitive data
• Minimize, de-identify, or mask PII before training
• Restrict and rate-limit model query access
• Test models for data leakage

Data leakage through prompts and outputs

The risk: Sensitive data entered into prompts, or returned in model outputs, reaches people or providers who should not see it.

Annex A controls:

• 12 Data leakage prevention
• 12 Classification of information
• 14 Information transfer

Traditional focus: Monitoring email, file transfers, and removable media

What needs to change:

• Extend DLP to AI prompts, uploads, and responses
• Define which classification levels may be used with which AI tools
• Filter outputs for sensitive content

Prompt injection

The risk: Malicious instructions hidden in user input or retrieved documents cause the AI system to ignore its rules, expose data, or take unintended actions.

Annex A controls:

• 26 Application security requirements
• 28 Secure coding
• 29 Security testing in development and acceptance

Traditional focus: Input validation for conventional applications

What needs to change:

• Treat all prompts and retrieved content as untrusted input
• Limit what actions AI agents can take
• Include adversarial prompt testing before release

Training data poisoning

The risk: Tampered or low-quality data introduced into training or fine-tuning sets skews model behavior.

Annex A controls:

• 25 Secure development life cycle
• 32 Change management
• 33 Test information

Traditional focus: Protecting source code and test data

What needs to change:

• Verify the source and integrity of training and fine-tuning data
• Version-control datasets
• Require approval for changes to data and models

AI supply chain compromise

The risk: Third-party models, open-source weights, and libraries introduce vulnerabilities you didn’t build and may not be able to inspect.

Annex A controls:

• 21 Managing information security in the ICT supply chain
• 20 Addressing information security within supplier agreements
• 8 Management of technical vulnerabilities

Traditional focus: Vetting software vendors and patching

What needs to change:

• Assess third-party model providers and open-source models
• Add AI-specific terms (data use, retention, training on your data) to contracts
• Track vulnerabilities in AI frameworks and libraries

Model theft and extraction

The risk: Attackers copy a proprietary model, or approximate it through repeated queries, exposing valuable intellectual property.

Annex A controls:

• 2 Privileged access rights
• 5 Secure authentication
• 24 Use of cryptography

Traditional focus: Protecting systems and credentials

What needs to change:

• Protect model weights as high-value assets
• Encrypt models at rest and in transit
• Monitor for unusual query volumes that suggest extraction

Undetected AI misuse

The risk: Without AI-specific logging and monitoring, misuse of AI tools, prompts, or agents can go unnoticed.

Annex A controls:

• 15 Logging
• 16 Monitoring activities
• 7 Threat intelligence

Traditional focus: Logging system and user activity

What needs to change:

• Log AI prompts, outputs, and agent actions where lawful
• Monitor for anomalous AI behavior
• Follow emerging AI threat intelligence

Uncontrolled cross-border processing

The risk: AI training, inference, and logging run in regions that may conflict with your data residency and transfer obligations.

Annex A controls:

• 23 Information security for use of cloud services
• 31 Legal, statutory, regulatory and contractual requirements
• 34 Privacy and protection of PII

Traditional focus: Selecting cloud providers and regions

What needs to change:

• Confirm where training, inference, and logging occur
• Align AI data flows with residency and transfer obligations in every jurisdiction you operate in

Organizations that need to govern AI more broadly, including fairness, transparency, and accountability, can pair ISO/IEC 27001 with ISO/IEC 42001, the international standard for AI management systems.

One Mapping, Any Jurisdiction

ISO/IEC 27001 is an international standard, and that makes this mapping portable.

Whether your AI workloads run in a single cloud region or span providers across North America, Europe, and Asia-Pacific, the same Annex A controls apply.

That consistency matters for international compliance teams. Cross-border cloud architectures often involve data collected in one country, models trained in another, and inference served globally.

Each hop is an information transfer, a supplier relationship, and potentially a new set of legal obligations.

By anchoring AI risk to Annex A, your team can:

• Apply one control framework across every region, rather than maintaining separate approaches for each market
• Map local privacy and data protection requirements into a single, auditable set of controls through 5.31 and 5.34
• Demonstrate to customers, partners, and regulators worldwide that AI risk is managed within an accredited, internationally recognized management system
• Scale AI adoption into new markets without rebuilding your security program each time

Your AI-Ready ISMS Checklist

• Update your context and interested parties (Clauses 4.1 and 4.2) to reflect how your organization develops, provides, or uses AI
• Discover and add AI tools, models, datasets, and APIs to your asset inventory
• Rerun your risk assessment with AI-specific threats, including Shadow AI and model inversion
• Revisit your Statement of Applicability and document how selected controls apply to AI
• Publish an AI acceptable use policy and train employees on it
• Review AI suppliers and update contracts with data use and retention terms
• Map where AI training, inference, and logs are processed across regions
• Include AI systems in your internal audit program and management review

Certify with Confidence

Perry Johnson Registrars, Inc. (PJR) provides accredited ISO/IEC 27001 certification for organizations around the world.

Our auditors understand how modern cloud and AI environments affect your ISMS, and our certification gives your customers independent assurance that your information security, including your AI pipeline, is managed to an internationally recognized standard.

PJR also offers ISO/IEC 42001 certification for organizations ready to demonstrate responsible AI governance alongside information security.

If your organization is certified to IATF 16949, or is working toward it, you have probably heard that a new edition is on the way. In its July 2026 stakeholder communiqué, the International Automotive Task Force (IATF) shared the first official look at what is driving the revision.

A quick note on roles: the IATF owns and maintains IATF 16949. Perry Johnson Registrars (PJR) is a certification body that audits and certifies organizations to the standard. We follow every update closely so the organizations we work with are never caught off guard, and this post is written from that perspective.

What the IATF Has Actually Announced

Revision 2 is being driven by feedback from stakeholders across the automotive industry. Based on that input, the IATF has identified five priority topics. These are not new clauses, and they are not final requirements. They signal where the industry believes the current system can work better.

The Five Priority Topics

1. Simplification, Clarity and Efficiency
   The goal is a standard that is easier to understand, implement and audit without losing effectiveness. That means reducing unnecessary complexity, narrowing the room for inconsistent interpretation, and avoiding duplication with ISO 9001.

   Ask yourself: Where does our quality management system create complexity without adding real control?

2. Software Quality Assurance
   Software is playing a bigger role in both automotive products and the processes that build them. Revision 2 is expected to apply existing quality principles more consistently across the software lifecycle, with a focus on embedded software, and without adding unnecessary complexity.

   Ask yourself: Does software receive the same quality discipline as our products and processes?

3. Tier N Supply Chain Management
   Automotive quality depends on the whole supply chain, not just direct suppliers. The revision aims to promote a more consistent risk-based approach to lower-tier suppliers, better deployment of customer requirements, and clearer communication, while keeping requirements practical and auditable.

   Ask yourself: Do we understand the risks that sit beyond our direct suppliers?

4. Launch Management
   Product and process launches are among the highest-risk phases of the automotive lifecycle. Revision 2 is expected to put more emphasis on a structured approach to new products, change management and industrialization, with the aim of improving launch readiness and reducing quality risk during implementation.

   Ask yourself: Can we demonstrate launch readiness before start of production?

5. Customer-Specific Requirements (CSR)
   Customer-Specific Requirements are one of the most discussed topics in the IATF 16949 scheme, and stakeholders consistently describe them as a challenge. The IATF aims to improve how applicable CSR are identified and managed, and to look at whether common CSR could be incorporated into the standard itself where possible.

   Ask yourself: Are all applicable CSR identified, current, deployed and effective?

Five Priorities, Five Familiar Problems

None of these priorities will come as a surprise to anyone who has lived inside an automotive quality system. Each one points to a challenge many organizations already recognize:

• A quality management system with complexity that does not always add control
• Software treated separately from established quality disciplines
• Limited visibility beyond direct suppliers
• Launches that still create quality and delivery disruption
• Customer-specific requirements that are hard to identify, update and deploy consistently

That is useful news. It means the work of getting ready is largely the work of improving what you already do.

What We Know About the Timeline

The IATF has shared a high-level plan and is clear that the dates are indicative and may be adjusted as work progresses. Working draft development and external feedback are planned for 2026. Final validation, translation and supporting documents follow in 2027, with publication planned for mid-2027. The IATF has also stated that the end of the transition period will be aligned with the end of the ISO 9001 transition.

Specific transition rules for certified organizations have not been announced. As details are released, we will share what they mean for audits and certificates.

How to Prepare Without Getting Ahead of the Standard

The standard has not been published, so there is no reason to build new procedures around assumptions about what it will say. Rewriting your system now risks solving problems that the final text does not contain.

What you can do today is use the five priorities as a self-check. Walk through the questions above with your quality, supply chain, engineering and program management teams. Gaps you find are worth closing under the current standard, and they will put you in a stronger position whatever the final text looks like. It is also a good moment to review how your team tracks CSR and how clearly your launch readiness evidence is documented.

Frequently Asked Questions

Has IATF 16949 Revision 2 been published?

A: No. The IATF currently plans to publish the 2nd edition in mid-2027, and it has noted that dates may change. Until then, IATF 16949:2016 remains the standard organizations are certified to.

Do I need to change my quality management system now?

A: You do not need to create new procedures based on a standard that has not been released. You can, however, review your current system against the five priority areas and strengthen any weak spots.

Are the five priority topics new requirements?

A: No. They are the areas the IATF has identified for improvement. How they are reflected in the final standard will not be known until the revision is published.

Will customer-specific requirements go away?

A: The IATF has not said that. Its stated aim is to improve how applicable CSR are identified and managed, and to explore incorporating common CSR into the standard where possible.

Who sets the rules for IATF 16949, and where does PJR fit in?

A: The IATF develops and maintains IATF 16949 and the rules of the certification scheme. PJR is a certification body that audits organizations against the standard and issues certification based on the outcome.

Talk to PJR About IATF 16949 Certification

Whether you are already IATF 16949 certified or exploring certification for the first time, our team can help you understand where things stand and what to expect. Call Perry Johnson Registrars at (248) 422-3013, email pjr@pjr.com, or Request A FREE Quote.

Know Thyself: How ISO 42001 Clause 4 Lays the Groundwork for Self-Policing AI

As AI tools move from pilot projects into everyday operations, more organizations are asking the same question: how do we keep our own AI in check before a regulator, customer, or headline does it for us? ISO/IEC 42001, the international standard for Artificial Intelligence Management Systems (AIMS), offers a structured answer. And that answer starts not with algorithms or audits, but with self-awareness.

Clause 4, Context of the Organization, is the foundation the rest of the standard is built on. It asks an organization to look honestly at its environment, its stakeholders, and its own role in the AI ecosystem, and then to draw clear boundaries around what its management system will cover. Get this step right, and self-policing becomes a disciplined, repeatable practice. Skip it, and every control that follows is built on guesswork.

Why Self-Policing Starts with Context

Self-policing means an organization sets its own rules for responsible AI, watches for its own failures, and corrects them without waiting for outside pressure. That only works if the organization knows what “responsible” means in its specific situation. A hospital using AI to triage patients faces very different risks than a retailer using AI to recommend products. A company that builds AI models carries different obligations than one that simply buys them.

Clause 4 forces those distinctions into the open. It turns vague good intentions into a documented picture of the organization’s circumstances, and that picture becomes the yardstick against which every later decision, from risk assessment to internal audit, is measured.

4.1 Understanding the Organization and Its Context

The first requirement is to identify the external and internal issues that are relevant to the organization’s purpose and that affect its ability to achieve the intended results of its AIMS. For AI, that list tends to be broad.

External issues: applicable laws and regulations (such as the EU AI Act), industry expectations, competitive pressure, public attitudes toward AI, and the maturity of available technology.

Internal issues: governance structure, organizational culture, internal policies, contractual obligations, available skills, and the organization’s appetite for risk.

Clause 4.1 also asks the organization to determine its role with respect to AI systems. Is it an AI producer, provider or user, or some combination? Each role carries different responsibilities, and many organizations play more than one. It must also consider the intended purpose of the AI systems it develops, provides, or uses.

For self-policing, this is where the organization defines its own jurisdiction. You cannot police what you have not identified, and you cannot hold yourself accountable for obligations you have not acknowledged.

4.2 Understanding the Needs and Expectations of Interested Parties

Next, the organization must identify the interested parties relevant to its AIMS, determine their relevant requirements, and decide which of those requirements it will address through the management system. In AI, interested parties reach well beyond customers and shareholders. They can include employees whose work is changed by automation, end users who interact with AI outputs, people who are the subject of AI decisions without ever touching the system, regulators, data suppliers, and the broader community.

This requirement is the conscience of a self-policing program. By asking “who could be affected, and what do they reasonably expect of us?”, the organization builds an outside perspective into its internal rules. Expectations around fairness, transparency, privacy, and human oversight often surface here first, long before they appear as formal complaints.

4.3 Determining the Scope of the AIMS

With context and stakeholders understood, the organization defines the boundaries and applicability of its AIMS. The scope must take into account the issues from 4.1 and the requirements from 4.2, and it must be available as documented information.

A well-defined scope answers practical questions: Which AI systems are covered? Which business units, locations, and processes? Which lifecycle stages, from design and data acquisition through deployment and retirement? A scope that is too narrow leaves high-risk systems ungoverned. One that is too broad spreads resources thin and weakens accountability. The goal is a scope that is honest about where AI risk actually lives.

4.4 The AI Management System

Finally, Clause 4.4 requires the organization to establish, implement, maintain, and continually improve an AIMS, including the processes needed and how they interact. This is the commitment that turns analysis into action. Context is not a one-time exercise; it feeds directly into leadership (Clause 5), risk planning and impact assessment (Clause 6), and the monitoring and improvement cycle of Clauses 9 and 10.

Putting Clause 4 to Work: Practical Steps

Build an AI inventory. List every AI system the organization develops, provides, or uses, including tools embedded in purchased software. Shadow AI is one of the most common blind spots.

Define your role for each system. Record whether you are the producer, provider and user and note where responsibilities are shared with vendors.

Run a structured context review. Use a PESTLE, SWOT, or similar analysis to capture external and internal issues, and revisit it when laws, technology, or business strategy change.

Map interested parties. Identify who is affected by each system, what they expect, and which of those expectations you will commit to meeting.

Write a scope statement you can defend. Document what is in, what is out, and why. Exclusions should be justified, not convenient.

Connect context to risk. Carry the issues and stakeholder requirements forward into your AI risk assessments and AI system impact assessments so nothing identified in Clause 4 is lost.

Common Pitfalls to Avoid

Treating context as paperwork. A context document written once and filed away quickly goes stale in a field that changes as fast as AI.

Overlooking indirect stakeholders. People affected by AI decisions are often not the people using the system.

Scoping out the hard parts. Excluding high-risk or high-visibility systems to simplify certification undermines the credibility of the entire program.

Ignoring third-party AI. Buying an AI capability does not transfer accountability for how it is used.

The Bottom Line

Self-policing an AI system is ultimately an exercise in self-knowledge. Clause 4 of ISO/IEC 42001 gives organizations a disciplined way to understand their environment, their stakeholders, their role, and the limits of their responsibility. That understanding is what makes every later control meaningful. Organizations that invest in getting their context right are better positioned to catch problems early, earn stakeholder trust, and demonstrate, to themselves and to others, that their AI is governed with intent. For further information email us at pjr@pjr.com or request a quote for ISO 42001 certification.