AI security & compliance5 min read

ISO 42001 scope and leadership: getting clauses 4 and 5 right

How to define AI management system scope, identify interested parties, write an AI policy and establish leadership accountability under ISO 42001 clauses 4 and 5.

By FORTE/CYBERx AdvisoryReviewed by FORTE/CYBERx Advisory10 August 2026

Why clauses 4 and 5 decide the cost of the whole programme

Most ISO/IEC 42001 implementations that run over time and budget do so because the scope was drawn badly at the start. Clause 4 asks the organisation to understand its context and define the boundaries of the AI management system. Clause 5 asks leadership to own it. Everything downstream — risk assessment, controls, evidence, audit — inherits whatever those two clauses established.

A scope that is too wide forces an SME to evidence governance over experimentation it has no intention of operationalising. A scope that is too narrow fails at the first customer question, because the AI system the buyer cares about sits outside the certificate.

Treat the scoping exercise as a commercial decision made with the executive team, not a documentation exercise delegated to a compliance coordinator.

Understanding the organisation and its context

Clause 4.1 requires the organisation to determine the internal and external issues relevant to its AI purpose. In an Australian context that usually means the Privacy Act and OAIC expectations on automated decision-making, sector obligations such as APRA CPS 234 or the SOCI Act, customer contractual terms, the AI Ethics Principles, and any funding or procurement conditions that reference responsible AI.

Internally, the issues are more prosaic: which business units are already using AI tools, whether data quality supports the intended use, whether the organisation has the engineering capacity to monitor a deployed model, and what the appetite is for automated decisions that affect people.

Write this down as a short context statement. Auditors will ask how the organisation determined its issues, and a two-page statement referencing real obligations is more defensible than a generic template.

Identifying interested parties and their requirements

Clause 4.2 covers interested parties. For AI systems the list is wider than for information security, because ISO 42001 explicitly contemplates effects on individuals and society, not just on the organisation.

A workable list for a mid-sized Australian organisation includes customers, employees whose work is affected, individuals subject to automated or semi-automated decisions, regulators, insurers, technology suppliers and model providers, and the board. For each, record what they actually require: transparency, an explanation pathway, a human review route, data residency, contractual warranties, or evidence for a tender.

The value of this list is practical. It becomes the input to your transparency obligations and to the impact assessment described in ISO/IEC 42005.

Determining the scope of the AI management system

Clause 4.3 requires a documented scope. Define it across three axes: organisational units, AI systems, and roles in the AI value chain. The third axis is unique to ISO 42001 — the standard distinguishes between being an AI provider, producer, user, partner or subject, and the obligations differ.

Most Australian SMEs are AI users deploying third-party models with configuration, prompts and retrieval over their own data. Some are producers who fine-tune or build systems for customers. Say which you are, per system. A scope that claims provider obligations you do not meet is worse than a narrow one.

State exclusions explicitly and justify them. Excluding a research sandbox that never touches production data is reasonable. Excluding the customer-facing assistant because governance is immature is not.

Building the AI system inventory that makes scope real

Scope is unverifiable without an inventory. Build a register that records each AI system, its purpose, the business owner, the underlying model or vendor, the data it touches, whether it affects decisions about people, the degree of autonomy, and whether it sits inside or outside the declared scope.

Include shadow usage. Consumer AI tools accessed with corporate credentials are in scope of the risk even when out of scope of the certificate, and an auditor will expect the organisation to know they exist and to have a position on them.

Refresh the inventory on a set cadence and at every material change. It is the single artefact that most often distinguishes a working AI management system from a documented one.

Apply this to your organisation

Want this assessed against your environment?

Send us the specifics and a senior advisor will respond within one business day.

Leadership commitment: what clause 5.1 actually demands

Clause 5.1 asks top management to demonstrate leadership and commitment. Auditors test this through evidence of decisions, not through a signed policy page. Expect questions about who approved the AI policy, who allocated budget and people to the management system, how AI risk reaches the board, and what happened the last time a proposed use case was rejected or paused.

The most persuasive evidence is a decision record: a use case that was stopped, delayed or redesigned because the governance process found an unacceptable impact. Organisations that have never said no to an AI proposal struggle to demonstrate that their gates function.

Integrate AI reporting into the existing risk or audit committee rather than creating a parallel forum. One agenda item with real content beats a standalone AI committee that meets twice and lapses.

Writing an AI policy people can follow

Clause 5.2 requires an AI policy appropriate to the purpose of the organisation, providing a framework for objectives and including commitments to meet requirements and to continual improvement. Keep it to two or three pages.

The content that matters: the organisation's stated purpose for using AI, prohibited uses, the classes of decision that always require a human, the data that may never be sent to an external model, the approval route for a new use case, and where responsibility sits when something goes wrong.

Reconcile it with existing policy. Acceptable use, information classification, privacy and supplier management policies almost certainly already say something about data handling. A contradictory AI policy creates an audit finding and, more importantly, gives staff an excuse to ignore both.

Roles, responsibilities and authorities

Clause 5.3 requires assigned responsibilities and authorities. In practice four roles cover most organisations: an executive owner accountable for the management system, a business owner per AI system, a technical owner who can change or disable the system, and an independent reviewer who assesses impact without owning delivery.

Independence matters at the review point. If the person who approves an AI system is the person whose targets depend on it shipping, the gate is decorative.

Record the authority to stop. Someone must be able to disable a deployed AI system quickly, and everyone should know who that is before the incident rather than during it.

A practical first four weeks

Week one: interview business units and build the AI inventory. Week two: draft the context statement, interested-party register and candidate scope, then test the scope against the customer questions the organisation is already receiving.

Week three: draft the AI policy and role assignments, and reconcile them against existing security and privacy policy. Week four: take scope, policy and roles to the executive for formal approval, with the resourcing decision made explicit.

At the end of the month the organisation should be able to answer, in one page, which AI systems it governs, who is accountable, and what it will not do. That is a defensible clause 4 and 5 position, and it makes the risk work that follows substantially cheaper.

Sources and further reading

This article provides general information and decision support. It is not legal advice, audit assurance, certification advice or a guarantee of outcome.