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.