ISO/IEC 42001 clause 7, explained without jargon: competence and awareness

"We've already done the AI training" usually means a two-hour online course, identical for everyone from the warehouse to risk management, with no verifiable record of who finished it and no check on what stayed useful to any particular role. In an audit that sentence doesn't hold up, and the reason has nothing to do with the length of the course.

Clause 7 has five parts, not two

Most people know it as "the training clause". Within the harmonised structure ISO/IEC 42001 shares with ISO 27001 and ISO 9001, clause 7 is called Support and contains five sub-clauses: resources (7.1), competence (7.2), awareness (7.3), communication (7.4) and documented information (7.5).

Anyone preparing for certification by working only on 7.2 and 7.3 covers two fifths of the requirement and meets the other three during the audit, when there's no time left to build them. The three that get ignored are also the easiest to evidence, because much of what they ask for already exists in the organisation's other management systems.

Resources come before people

Sub-clause 7.1 requires the organisation to determine and provide the resources needed to establish, implement, maintain and continually improve the management system. The verb that matters is determine: the organisation has to be able to show how it concluded those resources were the right ones, not merely that something was allocated.

In an AI context, resources aren't only people. Area A.4 of Annex A deals specifically with resources for AI systems and distinguishes data, tooling, computing resources and human resources, requiring each to be identified and documented. A management system declared without anyone having time allocated to maintain it, or without access to the data needed to assess what you intend to assess, is a statement of intent.

The question an auditor asks here is direct: how many hours a week are assigned to whoever keeps the system register current and runs the assessments, and which decision produced that number.

What determining a competence actually means

Sub-clause 7.2 breaks into four steps, and the third is the one that dismantles the equivalence between a course and a competence. The organisation must determine the competence required for people whose work affects the management system's performance, ensure they are competent, where applicable take action to acquire the missing competence and evaluate the effectiveness of those actions, and retain documented evidence.

Evaluating effectiveness is an obligation separate from delivery. An attendance record shows someone was connected, not that the training produced the intended effect. What's needed is something that measures the outcome: a practical case completed, real work reviewed by someone more experienced, a field check weeks later.

There's a second element almost everyone overlooks. The standard recognises competence acquired through education, training or experience. That conjunction is alternative, meaning prior experience counts as evidence, provided it's documented rather than assumed.

Demonstrating competence without a course

For several roles, formal training is the least efficient route, and the standard doesn't mandate it. Other forms of evidence hold up in an audit.

Documented experience, where a person is paired with a description of what they actually did rather than just a professional profile. A work sample, meaning a risk assessment or impact assessment genuinely carried out by that person, dated and signed, which counts for more than any certificate. Peer review, with a recorded outcome. Structured shadowing, with a start date, an end date and a closing assessment from whoever supervised.

External certifications sit among the options rather than exhausting them, and on their own they don't show the person can apply that knowledge to the organisation's specific systems.

The perimeter of awareness

Under 7.3, people working under the organisation's control need to know the AI policy, understand how they contribute to the management system's effectiveness, and know what follows from not meeting its requirements.

The phrase "under the organisation's control" reaches wider than "employees". It takes in temporary staff, consultants operating inside your processes, contractors, and in many cases personnel of suppliers carrying out work on your behalf. The external agency running your customer service with an AI-assisted tool falls inside the perimeter, and the only way to govern it is the contract, because you have no training plan covering that agency's people.

For most roles the content of awareness comes down to three things: what the system they use does, where the system's responsibility ends and theirs begins, and who to flag anomalous behaviour to. None of them needs to know how to build a model.

The communication almost nobody plans

Determining what to communicate about the management system, when, to whom, how and who does it: that's what 7.4 sets out. It's a short sub-clause, skipped almost universally, with concrete consequences when it's needed.

The questions it answers are operational. Who responds to a customer asking whether the decision affecting them was made or suggested by an automated system, and in what words. Who communicates internally that a system has been suspended, and how quickly. Who speaks to an authority if a request arrives. This intersects directly with the transparency obligations under Article 50 of the AI Act, binding since August, which in several cases require informing people that they're interacting with an AI system.

Without a plan, the answer gets improvised by whoever receives the question first, who is usually the person least equipped to give it.

Maintain and retain are different verbs

Two obligations that get confused routinely are separated under 7.5. Some documented information must be maintained, meaning kept current because it describes a present state: the management system's scope, the AI policy, the procedures. Other documented information must be retained, meaning kept as proof that something happened: completed risk assessments, impact assessments, training records, results of effectiveness checks.

Sub-clause 7.5.2 adds how documents get created and updated: identification, appropriate format, review and approval before use. Sub-clause 7.5.3 adds control: availability where and when needed, protection against loss or improper use, version management and access control.

The practical consequence is sharp. A document with no version, no date and no evidence of approval isn't documented information for the purposes of the standard, it's a file. The distinction surfaces at the first sampling, when an auditor asks which version of a procedure is in force and two slightly different ones are circulating in two folders.

What actually happens during the audit

An auditor doesn't check everyone. They sample three or five people across different roles and ask simple questions, usually the same ones: what's the company's AI policy and where is it, what does the system you use every day do, what would you do if you noticed it getting something wrong, who would you report that to.

When the sampled person can't answer, the nonconformity isn't about that person. It's about the management system, which planned a training action without verifying its effectiveness. Which is why the effectiveness check is worth running beforehand, against a sample resembling the one the auditor will use.

A second recurring check concerns recent joiners. If someone has been with the company three months, working on a process touched by an AI system, and has received nothing, the update mechanism required by 7.2 isn't working, however complete the plan is for everyone who was already there.

The most frequent mistakes

The one-size-fits-all course is the most visible, though not the most expensive. The most expensive is treating an attendance register as evidence of competence, because it produces the feeling of being covered right up until the auditor asks for the effectiveness assessment and none exists.

Next comes awareness confined to people who write code, which leaves exposed exactly the roles where system-assisted decisions touch real people. Then the contractor perimeter, forgotten because it doesn't appear in HR systems. Then sub-clauses 7.4 and 7.5, never addressed because nobody associates them with the word training.

The last one is the absence of a trigger: no mechanism firing an update when someone changes role or when the system they use changes. A plan built once and never revisited stops being valid the moment the organisation moves, and organisations move.

The next step

Separating competence from awareness, assigning each to the right roles and deciding how both get verified is the work missing from most companies that say the training is done. The next piece goes into operational detail with the matrix connecting each role to what it needs to be able to do, and how to keep that matrix aligned as the organisation changes.