ISO 42001 competence and AI literacy requirements

What ISO 42001 competence requirements mean for your AI team

Clause 7.2 of ISO/IEC 42001 requires you to determine the competence needed by people whose work affects AI performance, and to keep evidence that they have it. Control A.4.6 adds that you document the human resources and their competences used across the AI system life cycle, from development and deployment through operation, maintenance and decommissioning. When a customer or regulator asks for ISO 42001 competence requirements evidence, they are usually asking two things: who does what on each AI system, and how you know those people can do it. The depth you need depends on your role. An organization that provides or develops AI systems will need records covering design, data, testing and monitoring roles. An organization that only uses a third-party AI tool will focus on the staff who configure it, feed it data, review its outputs and decide when to stop using it. Start by listing each AI system in scope, the roles touching it and the competences each role needs.

Your organization owns these decisions. Only you can decide what competence a role requires, who meets it and what happens when someone falls short. An implementation partner can help build the competence matrix, role profiles, training records and review cycle, and can prepare the evidence so it is easy to test. That work does not replace your judgment, and it does not produce a certificate. Only the certification body that audits your AI management system issues one, and the certification body's assessors will sample your records against your own stated requirements. Before you engage anyone, confirm with your certification body how it expects competence to be shown, and confirm with your internal HR and legal teams which records you may hold on individuals.

How to determine and evidence competence under clause 7.2

This sequence turns the clause 7.2 competence requirement into a traceable chain, running from the roles that affect AI performance through to records that show those people can do their work and a check that the measures worked.

Identify roles that affect AI performance
Start by listing every role whose work touches an AI system across its life cycle: development, deployment, operation, maintenance and decommissioning. Include staff inside the organization, contractors and people at suppliers who act on the organization's behalf. Ask the system owners and the people who run each stage to confirm who actually does the work, not only who holds the job title. The output is a role register that maps each role to the AI systems and life cycle stages it touches. The step is done when system owners have signed off that no stage or role is missing.
Define the competence each role needs
For each role in the register, write down the knowledge, skills and experience the work requires, such as data handling, model evaluation, security configuration, impact assessment or incident response. Separate general AI literacy from role-specific competence, because a reviewer needs different proof for each. Human oversight roles should also state the authority the person holds to intervene. The output is a competence profile per role, reviewed by the accountable manager. The step is done when every profile names observable skills rather than generic labels like "AI experience".
Assess current competence against the profiles
Compare what each person can already demonstrate with the profile for their role. Use a mix of evidence: records of prior training, certifications the organization has verified, work samples, peer review, and short practical checks. Record the result as a gap list showing, for each person and role, what is missing. Avoid treating a completed course as proof of competence unless it covered the profile's skills. The output is a gap analysis. The step is done when every person in the register has an assessed status against their profile.
Close gaps through training, hiring or supervision
For each gap, choose a closing measure: targeted training, a hire, a reassignment, or supervision by a competent person until the gap is closed. Record who approves each choice and the expected result. Training should be tied to the profile it addresses, and the training plan should state what the person must be able to do afterward. Where an outside provider delivers training, the organization still owns the plan and the records. The output is a training plan with one entry per gap. The step is done when each gap has an owner and a documented closing measure.
Deliver training and retain evidence
Run the agreed training and supervision, then file the evidence that shows it happened and what it covered. Useful records include attendance, course content, assessment results, supervisor sign-offs and the date each person entered the role. The European Commission's AI literacy guidance notes that organizations can keep internal records of training and other AI literacy initiatives, and that relying only on instructions for use is often not enough. Store the records under the documented information controls in clause 7.5 so they remain current and retrievable. The output is a competence record for each person. The step is done when an assessor could pick any role and trace it to its profile and its records.
Document human resources under A.4.6
Consolidate the role register, competence profiles and records into the human resources documentation that Annex A control A.4.6 asks for. Cover the people used across development, deployment, operation, maintenance and decommissioning, and link each to the AI systems they support. Keep the entry current when staff change roles or when a system moves to a new stage. The output is a human resources record that sits alongside the other resource records. The step is done when the record matches the role register without gaps.
Review effectiveness and feed results back
Check whether the measures worked. Compare later assessments with the original gap list, review incidents and quality issues for links to competence, and ask people in each role whether they can perform the tasks the profile describes. Record the findings and decide whether profiles, training or supervision need changing. Share the results with management review so leaders can see whether competence keeps pace with the AI systems in use. The output is an effectiveness review with recorded actions. The step is done when each finding has an owner and a decision on follow-up.

What A.4.6 adds to the human resources record

A.4.6 asks for more than a list of staff. The record must show who takes part in each AI life cycle activity, what competence they bring, and how their people entries tie back to the resource record in A.4. The cards below cover the parts an assessor is likely to test.

Role inventory by life cycle activity

Map each AI system to the life cycle activities it passes through, such as development, deployment, operation, maintenance and decommissioning, and name the people or teams who perform each one. Keep the inventory at role level first, then attach named individuals. An assessor will look for gaps, such as a deployed system with no named operator or a retired system with no owner for decommissioning. Confirm the inventory is owned and reviewed by the organization, not by the implementation partner.

Competence profile for each role

For each role in the inventory, record the competence it needs to do the work that affects AI performance, along with the evidence that the person holds it. Evidence may include training records, supervised experience, qualifications or sign-off on prior work. This is the link to clause 7.2, which requires the organization to determine required competence and keep evidence of it. Write the profile in terms of tasks, such as validating training data or approving a deployment, so it can be tested.

Contractors and third parties acting for you

Record contractors, outsourced developers, model providers and consultants who perform AI work on your behalf, including what they do and which of your people supervise them. The organization stays responsible for the competence of people working under its name, so an external party's own training does not replace your evidence. Check that contract terms let you obtain their competence records when an auditor asks for them.

Link to the A.4 resource record

A.4.6 sits inside the resource set for AI systems, so each human resource entry should point to the AI system and to the other resources it depends on, such as data, tooling and computing. Use the same system identifiers across both records. An auditor reading a human resource entry should be able to follow it to the system it supports and the tools that person uses on that system.

Change triggers for staff and responsibilities

Define events that force a review of the record: a role change, a leaver, a new system going live, a material change to a model, or a shift of an activity to a new team. Set who is notified and who updates the entry. Stale entries are a common finding, so test the triggers by simulating a departure and checking whether access and assignments are updated in the same cycle.

Comparison with project and access records

Auditors compare the human resource record with what actually happened. They check project assignments, change tickets, code repository permissions, deployment approvals and privileged access grants against the named roles and competences. Any person who appears in a system without a matching entry is a finding. Run that comparison yourself before the assessment, using the same records the auditor will request.

How AI literacy under Article 4 of the EU AI Act fits the same records

One training register can serve both ISO/IEC 42001 clause 7.2 and Article 4 of the EU AI Act, but the two tests ask different questions, so the register should record more than course completions. Article 4 has applied since 2 February 2025 and covers providers and deployers of all AI systems, not only high-risk ones. As replaced by Regulation (EU) 2026/1744, Article 4(1) requires providers and deployers to take measures to support the AI literacy of their staff and of others operating AI on their behalf. It does not require any specific level of literacy for any individual. Clause 7.2 asks something narrower and more operational: the organization must determine the competence that people doing work affecting AI performance need, and keep evidence that they have it.

The European Commission's AI literacy Q&A states that organizations can keep internal records of training and other AI literacy initiatives, and that relying only on instructions for use is often not enough. For the records, this means the register should show who was in scope, what role they play with the AI system, what measures were delivered (for example, role-specific training, guidance on the system's limits, or briefings for staff who operate it on the organization's behalf), when they took place and how the organization checked that they were understood. Vendor documentation can be cited as one input, but it should not stand alone as the evidence.

Confirm the scope with counsel or the relevant market surveillance authority before you treat the register as complete for Article 4. Ask whether contractors and other third parties who operate AI for you fall within scope, and whether the existing register meets the Commission's expectations for internal records. The auditor will assess the clause 7.2 test against your own competence criteria, not the Article 4 test, so a register built only for one may need additional fields for the other. Agree the fields and retention rules once, then review them when a new AI system or role is introduced.

Human oversight competence for high-risk deployers

Providers of high-risk AI systems design the system so that people can oversee it, and they must give deployers the information needed to do so. Article 26(2) sits on the deployer side, but the provider's instructions for use, technical documentation and design choices shape what a deployer's oversight team needs to know. An ISO/IEC 42001 record under clause 7.2 and Annex A control A.4.6 can show how the provider identified the competence its own staff need to build and support the system, and how that competence was kept current.

Oversight design records: Documents showing how human oversight measures were specified during development, tied to the AI system's intended purpose.
Information for deployers: Instructions for use that state the competence and training a deployer's overseers should have, so the deployer does not have to guess.
Provider staff competence: Records of the roles, qualifications and training of people who develop, test and support the system.
Support and escalation contacts: Named channels through which deployers report malfunctions or unexpected outputs.
Change records: Evidence that updates to oversight features were communicated to deployers before they took effect.

Check whether your contracts and instructions for use state the oversight competence you expect from deployers, and whether your own staff records would satisfy an assessor reviewing them.

Which records satisfy which requirement

This table compares the common competence and AI literacy records against clause 7.2, Annex A control A.4.6, Article 4 of the EU AI Act and Article 26(2). Read each row as one piece of evidence: what it proves, and what an assessor or regulator will ask to see. No single record covers every test, so the combination matters more than any one document.

Record	What it proves	What an assessor or regulator will ask to see
Role register for AI work	Which roles affect AI performance or life cycle activities, and who holds them (clause 7.2, A.4.6)	Current register linked to named people, with dates of last review and the AI systems each role touches
Competence profile per role	The competence each role needs, set out before people are assigned (clause 7.2)	Written criteria for each role, the basis for them, and who approved them
Training and attendance records	That specific training was delivered to specific people, with dates and content (Article 4(1), clause 7.2)	Course content, attendance lists, dates, and which staff and third parties on the organization's behalf were included
Awareness communications	That staff were told about the AI policy and their responsibilities (clause 7.3, supports Article 4(1))	Copies of communications, distribution lists and acknowledgements. Attendance alone shows little about understanding
Assignment letters for human oversight	That named people were given oversight authority for a high-risk system (Article 26(2))	Signed or approved assignments stating authority, the system covered and the competence held, plus the training backing it
Effectiveness reviews	Whether training and competence actions changed behavior or closed the gap found earlier (clause 7.2 evidence of actions taken)	Review method, findings, follow-up actions and who signed off the review
Human resource entries in the AI resource record	That the people behind each life cycle activity are documented, with their competences (A.4.6)	Entries linked to development, deployment, operation, maintenance and decommissioning activities, kept current

What must be in place before an assessment

An assessor will not accept a training certificate on its own as proof of competence. The checks below connect roles to competence, competence to training, and training to the people actually assigned to AI work, so each link can be traced from start to finish before the audit begins.

Current role inventory for each AI system

List every AI system in scope and the people or teams who develop, deploy, operate, maintain, monitor or decommission it, as clause 7.2 and control A.4.6 expect. Record the roles by name or position, not only by department, and include contractors and third parties who perform work that affects AI performance. Confirm the inventory is dated and updated when staff move, systems change or a new system enters scope. An inventory that predates a reorganization is one of the first gaps an assessor finds.

Competence profiles tied to each role

For each role in the inventory, write down the knowledge, skills and experience the work requires, such as model evaluation, data handling, incident escalation or human oversight. Keep the profile specific enough that someone can judge whether a candidate meets it. Review profiles when a system's risk or purpose changes, because the competence needed for a low-risk internal tool differs from that needed for a system affecting customers or employees.

Training records with dates and content

Keep a record for each training activity showing who attended, the date, the content covered, the provider or instructor, and any assessment result. Records that state only that a course was completed do not show what the person learned. Link each record to the competence profile it addresses. Confirm with your own training provider what their records contain, and ask whether they can export them in a form your auditor can read.

Awareness and communication records

Clauses 7.3 and 7.4 require that people know the AI policy, their contribution to the AI management system, and the consequences of not conforming, and that the organization communicates internally and externally as needed. Keep dated evidence such as policy acknowledgments, briefing attendance, internal notices and the communication plan that set out who tells what, to whom and when. Treat awareness as a separate record from formal training.

Controlled documented information

Under clause 7.5, competence records, role inventories and profiles must be identified, versioned, approved, stored and kept available for use. Assign an owner to each record, set a review cycle, and restrict edit rights so older versions cannot replace current ones silently. Confirm where the records live, who can change them and how old versions are retained, since an assessor will ask to see the history of each document.

Traceable chain from role to assignment

Choose a sample of people in AI-related roles and walk the chain: the role in the inventory, the competence profile, the training and awareness records, and the assignment record showing that person was given the work. For example, in an illustrative case, a reviewer of a high-risk system should find a documented oversight role, a matching profile, dated training and a written assignment. Run this walk-through internally before the auditor does, and fix any broken link.

Who owns competence and who prepares the evidence

The organization owns every competence decision. Human resources and the AI governance owner decide which roles affect AI performance, what competence each role needs, and whether a person meets that standard. Clause 7.2 asks the organization to determine the competence needed by people whose work affects AI performance and to keep evidence of it, so the decision and its record must sit with the organization, not with a vendor.

Role definition: HR and AI governance agree which roles build, operate, monitor, or oversee AI systems, and which roles only use them.
Competence criteria: Each role has written criteria for education, training, experience and authority, reviewed by a named owner.
Sign-off: The AI governance owner approves competence decisions and records the date and approver.
Training records: HR keeps attendance, completion and assessment results in a system it controls and can retrieve for an auditor.
Periodic review: Competence needs are reviewed when AI systems, tools or regulatory duties change.

Before relying on any template, confirm with your HR and governance leads that they have approved the role criteria and that the records live in a system you own.

Questions buyers ask about competence evidence

How much effort does competence evidence take, and what drives it?

The effort depends mostly on how many people touch AI systems and how many distinct roles they hold. Competence evidence under clause 7.2 starts with determining which competences each role needs, then confirming that people hold them and keeping records. A small team building one AI feature has a short role list and a manageable record set. A company that develops models, deploys them into regulated processes and operates them across several business units has many roles, more training paths and more records to keep current. The main drivers are the number of AI systems in scope, the number of roles across the life cycle, how often roles change, and whether records already exist in your learning or HR systems. Ask any partner to size the work from your role inventory, and to state which records they will build and which you must maintain after handover.

Does completing AI training satisfy clause 7.2?

No. Training is one way to close a competence gap, but clause 7.2 first requires you to determine the competence each person needs for work that affects AI performance. Training completion shows attendance, not competence. An auditor will ask how you decided what a data engineer, a model reviewer or an operator needs to know, how you checked that the person has it, and what you did when someone did not. Evidence that holds up usually includes a competence matrix for each role, the basis for each requirement, records of assessment such as supervised work, reviews or tests, and actions taken where gaps appeared. Course certificates belong in that record, but they should sit beside the reasoning that made the course necessary.

Can we build competence evidence in-house without outside help?

Yes, many organizations do, provided someone owns the process and has authority across development, operations and HR. The organization owns its controls and its records, and an internal team can determine competence needs, define roles and keep the matrix current. Outside help is usually most useful for a readiness review against clause 7.2 and A.4.6, a check of how the records will look to an assessor, and hands-on support for building the documentation. An implementation partner prepares systems and evidence, but only an independent certification body issues a certificate. Whichever route you take, confirm early that the person accountable for competence records has time for them, because the work is continuous rather than a one-off project.

What do HR and line managers need to contribute?

HR and line managers supply the facts that competence records depend on. HR holds job descriptions, hiring criteria, learning histories and role changes, and should be able to export them reliably. Line managers know what work each person performs with AI systems and where performance has been strong or weak. Practical contributions include agreeing role definitions with the AI owner, confirming who operates, reviews or decommissions each system, recording supervised experience, and flagging changes such as transfers or new tooling. Expect these tasks to recur, because staff turnover and new AI systems change the picture. Agree the handoffs, owners and review frequency in writing before stage 1 so the records do not drift.

Can one record set serve ISO 42001 and the EU AI Act?

Largely yes, but the two regimes ask different questions, so one set needs a clear structure. Under the EU AI Act, Article 4 applies to providers and deployers of all AI systems and requires measures to support AI literacy of staff and others operating AI on their behalf. The European Commission's Q&A says internal records of training and other literacy initiatives are acceptable, and that relying only on instructions for use is often not enough. Article 26(2) separately requires deployers of high-risk systems to assign human oversight to people with the necessary competence, training and authority. A single competence register can cover ISO clause 7.2, A.4.6 and these obligations if it records role, required competence, evidence of attainment, oversight assignments and the legal basis for each. Confirm with counsel which obligations apply to your role before relying on the same file.

What should we confirm with the certification body before stage 1?

Confirm how the certification body will test competence, because methods differ between bodies. Ask which documents they expect for clause 7.2 and A.4.6, how they want the competence matrix presented, and whether they will sample individual personnel files during stage 2. Ask how they treat AI literacy training that must also meet EU AI Act obligations, and whether they hold accreditation for ISO/IEC 42001 work and how it applies to their scope. Note that ISO itself does not certify organizations, and that ISO/IEC 42006:2025 adds requirements for bodies certifying AI management systems. Get the answers in writing, and confirm that the body has no role in designing your records, since its independence depends on that separation.

Where competence programs usually fall short

Most competence programs under ISO/IEC 42001 fail at the link between training and roles. A training catalogue lists courses, but nothing shows which people doing AI work need which course, or what they must be able to do afterwards. Clause 7.2 asks the organization to determine the competence needed by people whose work affects AI performance and to keep evidence of it, so the fix is a role-to-competence matrix that names each AI-affecting role, the competences it requires, and the course, assessment or on-the-job record that proves them. Annex A control A.4.6 points the same way, asking for the human resources and their competences across the life cycle, from development through decommissioning. Without that matrix, an assessor sees a list of courses and cannot tell whether the person reviewing a model's outputs is competent for that task.

The second and third gaps sit outside the training team. Competence records often live in individual managers' spreadsheets or in an HR system that nobody on the AI team can query, so the evidence leaves when the manager does. Contractors, labelers and vendor engineers who operate or tune AI systems are frequently absent from the record altogether, even though they fall within the human resources the organization relies on. The practical check is to ask who could produce, within a day, the competence record for each person who changed a model, approved an output or responded to an AI incident, including people the organization does not employ. Where the answer depends on one manager or a supplier's goodwill, the records need to move into a shared, controlled repository and the supplier terms need to require evidence of training.

Competence also decays silently when roles change. A person who moved from testing a chatbot to approving its deployment may still hold the competence record for the old role, and no review is triggered. Clause 7.2 implies a recurring check, and a practical trigger is any change of role, system or scope recorded in the AI inventory or change process, followed by a documented confirmation that the person still meets the required competences or a dated training plan. Organizations should confirm with their certification body how often they expect these reviews to be sampled, since that expectation is set in audit practice rather than in the standard's wording alone.

How DeployOpen prepares competence evidence

DeployOpen helps organizations set up the records that show who works on AI systems, what competence each role needs and how that competence was built and checked. The organization owns its people, roles and training decisions, while DeployOpen prepares the systems, templates and evidence that an independent certification body will review.

How we scope

Engagements are fixed-scope, with the roles, AI systems and life cycle stages covered agreed in writing before work starts.
The written scope lists which people groups need competence records, such as developers, operators, reviewers and oversight staff.
Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.

How we build

We set up a competence matrix that maps each AI-related role to the skills, training and experience it requires.
We configure self-hosted training and learning records inside your own infrastructure so completion data stays under your control.
We build the A.4.6 human resources record, listing the people and competences used across development, deployment, operation and decommissioning.

How we hand over

You receive the competence matrix, training records, and A.4.6 documentation in formats your internal audit team can review.
We document how records are created, updated and controlled, aligned with the documented information requirements of clause 7.5.
Handover includes a walkthrough so your AI governance owner can keep the records current after the engagement ends.

How we support

We can review training records against EU AI Act Article 4 AI literacy measures and the Article 26(2) oversight competence needs you identify.
Retainer support can keep competence records current as new AI systems, roles and suppliers enter the scope.
Certification decisions, audit reports and certificates come only from an independent auditor or certification body, which we do not replace.