Want the Detailed Version?

VISTA InfoSec’s ISO/IEC 42001 Readiness Checklist contains 93 checks across 12 readiness domains, with mandatory requirement and Annex A references and a structured scoring methodology.

Download the Free 93-Point ISO 42001 Readiness Checklist →

Have You Clearly Defined the Scope of Your AIMS?

Start with the boundary of your AI Management System.

Which AI systems are included? Which business units, processes and locations are covered? What has deliberately been left outside the scope?

Your organization also needs to understand its role in relation to the AI systems involved. You may develop an AI system, provide it to customers or use AI supplied by another organization.

An unclear scope causes problems later because risk assessment, impact assessment, responsibilities, controls and audit evidence all depend on knowing what the AIMS actually covers.

Evidence to look for: A documented AIMS scope identifying the relevant AI systems and organizational boundaries.

Readiness question: Could you give an assessor your AIMS scope today and clearly explain what is inside and outside it?

Common gap: Defining the scope around what seems easiest to certify rather than how AI is actually developed, provided or used.

Does Your AI Policy Reflect What Your Organization Actually Does?

An AI policy should be more than a statement of responsible AI principles.

It needs to make sense in the context of the AI systems your organization develops, provides or uses.

It should also work alongside your existing information security, privacy, enterprise risk, HR and procurement policies.

For example, imagine your AI policy requires review before employees use external GenAI platforms, while teams can purchase and deploy SaaS products containing GenAI capabilities without triggering that review.

The policy exists. The governance doesn’t.

Evidence to look for: An approved AI policy, evidence of communication, alignment with related organizational policies and an established review cycle.

Readiness question: Does your AI policy influence real decisions about AI?

Your full checklist examines these issues against the AIMS foundation requirements and relevant Annex A controls.

Can You Identify the AI Systems Being Used Across Your Organization?

You cannot effectively govern AI you don’t know exists.

AI can enter an organization through internally developed models, SaaS platforms, APIs, foundation models, productivity applications and AI functionality embedded inside software that teams already use.

Ask four departments — engineering, IT, security and procurement — to list the organization’s AI systems.

Would you get the same answer?

If not, that is a useful readiness signal.

An organization should understand what AI systems it is responsible for, what those systems are intended to do and the resources and dependencies on which they rely.

Evidence to look for: A maintained inventory of relevant AI systems and resources, with ownership and purpose documented.

Readiness question: Can you produce an accurate list of the AI systems currently within your intended AIMS scope?

Do You Have a Repeatable AI Risk Assessment Process?

ISO/IEC 42001 takes a risk-based approach.

But saying “our enterprise risk team reviews AI” does not automatically demonstrate a repeatable AI risk assessment process.

Your organization should be able to explain how AI risks are identified, analyzed and evaluated, what criteria are applied, when reassessment occurs and how the results are retained.

Consistency matters.

If two business units assess comparable AI systems using completely different approaches and arrive at conclusions that cannot be compared, your risk process may require further work.

Evidence to look for: A defined AI risk assessment process, risk criteria, risk acceptance criteria and completed assessment records.

Readiness question: If an assessor requested your recent AI risk assessments tomorrow, what could you produce?

Your detailed checklist examines this area across risk assessment, risk treatment, retained results and the Statement of Applicability.

Can You Demonstrate What Happened After an AI Risk Was Identified?

Identifying a risk is only the beginning.

Organizations need to determine how identified risks will be treated, which controls are necessary, who owns the risk and whether the residual risk is acceptable.

There should be a traceable path from:

Risk identified → Risk evaluated → Treatment selected → Control applied → Owner assigned → Residual risk considered

This is also where Annex A should be handled carefully.

The 38 Annex A controls are a reference set rather than a checklist that every organization automatically implements in full. Applicability should follow the organization’s risk and impact assessment and be appropriately justified in its Statement of Applicability.

Readiness question: Pick one significant AI risk. Can your team show exactly what happened after it was identified?

How Mature Is Your AI Risk Process?

The full checklist contains dedicated sections covering AI Risk Management and AI System Impact Assessment.

Download the 93-Point Readiness Checklist →

Are You Performing AI System Impact Assessments?

AI risk is not limited to what could go wrong for the organization.

Organizations also need to consider potential consequences of AI systems for individuals, groups of individuals and society across the AI system lifecycle.

Depending on the system, relevant considerations may include fairness, privacy, transparency, safety, accessibility, financial consequences and human oversight.

The key word here is process.

An informal discussion between product, engineering and legal may identify important impacts, but that is different from having a defined process for determining when an assessment is required, performing it and retaining the results.

Evidence to look for: An AI system impact assessment process and completed assessment records.

Common gap: Teams discuss impacts during development but cannot demonstrate how the decision was reached or why an assessment was required.

Your VISTA checklist maps this area specifically to Clauses 6.1.4 and 8.4 and Annex A.5.

Is Accountability for AI Clearly Assigned?

“AI governance belongs to everyone” may be a useful cultural principle.

It is not a substitute for accountability.

Your organization should be able to determine who is responsible for areas such as AI risk management, impact assessment, development, testing, data quality, security, supplier management, human oversight and monitoring.

Then ask the more difficult question:

If a serious AI risk emerged before a production release, who has the authority to stop that release?

If nobody can answer confidently, you may have an accountability gap rather than a technology gap.

Evidence to look for: Documented and communicated responsibilities and authorities across the AI lifecycle.

Common gap: Responsibilities appear on a RACI chart, but the people named do not have the authority to make the decisions assigned to them.

Are People Competent for the AI Responsibilities Assigned to Them?

Assigning responsibility does not automatically establish competence.

The people making decisions within your AIMS may include developers, product owners, compliance personnel, security teams, procurement, legal, risk teams, domain specialists, operators and senior management.

The organization needs to determine what competence those roles require and retain appropriate evidence.

That doesn’t necessarily mean sending everybody through the same “Responsible AI” course.

A developer responsible for model testing, a procurement professional evaluating an AI supplier and an executive approving residual risk have different responsibilities.

Readiness question: Do the people responsible for AI governance understand what is expected of their specific role?

Is Governance Embedded Throughout the AI System Lifecycle?

One of the clearest indicators of maturity is when governance happens.

If risk assessment, compliance review and documentation happen immediately before deployment, governance has effectively been bolted onto the development process.

A more mature approach integrates governance across:

Requirements → Design → Development → Testing → Deployment → Operation → Monitoring → Change → Decommissioning

Your full checklist looks at responsible-development objectives, requirements, verification and validation, deployment planning, monitoring, technical documentation and logging.

Evidence to look for: Traceability showing how requirements and risk considerations influenced development, testing, approval and deployment.

Readiness question: Could you reconstruct why a particular AI system was approved for production?

Can You Explain Where Your AI Data Came From?

AI governance quickly becomes data governance.

Organizations should understand the datasets relevant to their AI systems, including their origins, intended purpose, quality, preparation and known limitations.

Ask:

• Where did the data originate?
• What was it originally collected for?
• How was it labelled or transformed?
• What quality criteria were applied?
• Are known bias issues documented?
• Can its lineage be reconstructed?

These questions become particularly important when an AI system produces an unexpected result and someone asks why.

Evidence to look for: Dataset documentation covering provenance, purpose, preparation, quality and lineage.

Your detailed checklist examines data acquisition, quality, preparation and provenance as part of the AI-data readiness domain.

Do Users Understand What Your AI System Can — and Cannot — Do?

Transparency is not simply adding the sentence:

“This product uses artificial intelligence.”

Relevant users and affected parties may need information that helps them understand the system’s intended purpose, capabilities, limitations, expected inputs and outputs, known failure modes and available human oversight.

Organizations also need mechanisms for people to raise concerns or report problems.

And when an AI-related incident occurs, somebody needs to know who communicates what, to whom and when.

Readiness question: If someone affected by an AI system challenged its output tomorrow, could your organization explain what happened and route the complaint appropriately?

Your checklist addresses these operational transparency considerations within its Transparency & Information for Interested Parties domain.

Are AI-Specific Security Risks Integrated Into Your Security Program?

ISO 42001 does not make information security requirements disappear.

Organizations still need to understand the models, frameworks, libraries, infrastructure, data and other resources on which their AI systems depend.

AI-related threats also need to be considered within the appropriate security and monitoring processes.

For example, your checklist brings data poisoning into the monitoring discussion and also identifies prompt injection, model extraction and inference attacks as threats worth considering in the broader security conversation.

Organizations with mature ISO/IEC 27001 environments may already have useful management-system foundations.

However:

ISO 27001 certification does not automatically mean you are ISO 42001-ready.

Could You Produce Your AIMS Documentation and Records Today?

There are two different questions here.

Do the necessary documents exist?

And:

Can you demonstrate that the processes described in those documents actually operate?

An AIMS needs appropriate documented information, but operating evidence is equally important.

That may include risk assessment results, impact assessment results, competence records, monitoring results, internal audit evidence, management-review outputs and corrective actions.

Your full checklist distinguishes maintained AIMS documentation from the records generated by operating the management system.

Common gap: The procedure says an activity will happen quarterly, but the organization cannot produce evidence that it has happened.

Are Third-Party AI Providers Inside Your Governance Process?

Most organizations do not control every component of their AI stack.

You may rely on foundation-model providers, hosted inference APIs, cloud platforms, datasets, labelling vendors, SaaS applications and other third parties.

That makes your AI supply chain part of your governance problem.

Organizations should determine responsibilities between themselves and relevant suppliers and establish appropriate processes for supplier evaluation and ongoing oversight.

Your complete checklist dedicates a readiness domain to supplier and third-party management.

One question often exposes the issue quickly:

If a critical AI provider materially changed its model tomorrow, would you know — and who would assess the impact?

Has Your AIMS Been Operating Long Enough to Produce Evidence?

This is worth asking before agreeing to an aggressive certification date.

Writing documentation can happen relatively quickly.

Generating meaningful operating evidence takes time.

Your AIMS needs to operate. Monitoring needs to occur. Internal audits need to happen. Management needs to review the system. Nonconformities need to be addressed and improvement needs to be demonstrated.

The VISTA checklist specifically notes that having real operating records can influence the earliest realistic timing for a Stage 2 audit more than simply completing the documentation build.

So don’t ask only:

“Have we finished our ISO 42001 documentation?”

Ask:

“Can we demonstrate that our AIMS is actually operating?”

AI Governance & Management System Foundation • AI Risk Management • AI System Impact Assessment • Roles, Responsibilities & Competence • AI System Lifecycle • Data for AI Systems • Transparency • Security & System Resources • Documentation • Monitoring, Internal Audit & Management Review • Supplier & Third-Party Management • Continual Improvement

Free Self-Assessment

How ready is your organization for ISO 42001?

Go beyond these 15 screening questions with VISTA InfoSec’s 93-point ISO/IEC 42001 Readiness Checklist.

Download the Free Checklist →

Free self-assessment • 93 readiness checks • 12 readiness domains

Need a Deeper Assessment?

Talk to VISTA InfoSec about an ISO 42001 Readiness Assessment and Gap Analysis.

Talk to an ISO 42001 Specialist →

What is an ISO 42001 readiness assessment?

An ISO 42001 readiness assessment examines how prepared an organization’s Artificial Intelligence Management System is against relevant ISO/IEC 42001 requirements before certification activities begin. It can identify gaps in processes, documentation, controls and operating evidence.

Is an AI policy enough for ISO 42001 certification?

No. An AI policy is one part of an AIMS. Organizations also need to address areas such as scope, risk management, impact assessment, responsibilities, competence, operational processes, monitoring, documented information and continual improvement.

Do we have to implement all 38 Annex A controls?

Not automatically. Annex A is a reference set. Control applicability should be determined through risk treatment and appropriately justified in the Statement of Applicability.

Is ISO 27001 required before ISO 42001?

No. ISO/IEC 27001 certification is not a prerequisite for ISO/IEC 42001. Organizations that already operate an ISMS may, however, be able to reuse elements of their existing management-system processes rather than creating an entirely parallel system.

Is ISO 42001 only for companies that develop AI?

No. An organization may develop AI systems, provide them to others or use AI systems supplied by third parties. Determining the organization’s role is part of establishing the AIMS context and scope.

How long does it take to become ISO 42001-ready?

There is no single timeline that applies to every organization. The scope of the AIMS, number and complexity of AI systems, existing management-system maturity, identified gaps and availability of operating evidence all influence readiness.