A.4.6 Human resources: requirements and evidence

What A.4.6 human resources requires and why auditors check it

A.4.6 asks the organization to document the human resources, and their competences, used across AI system life cycle activities, from development and deployment through operation, maintenance and decommissioning. If you are the compliance lead or engineer who has to show this control is met, the question an assessor will ask is simple: who does the work that affects this AI system, what competence do they need, and where is that written down for each stage? The risk behind the control is straightforward. People without the right knowledge who train, tune, deploy, monitor or retire an AI system can make decisions that change its performance, its fairness or its safety, and nobody has recorded that those people were the right ones for the job.

A.4.6 is easy to confuse with clause 7.2, which covers competence across the management system. Clause 7.2 requires you to determine the competence needed by people doing work that affects AI performance and to keep evidence of it. A.4.6 is narrower in its Annex A focus: it asks for a documented account of the human resources attached to each AI system's life cycle. It sits alongside A.4.2 Resource documentation, which ties the whole resource record together, and A.4.3 to A.4.5, which cover data, tooling and computing. The human side is the one most often left out of those records, because staff are not inventory items in the way a dataset or a model framework is.

What usually makes A.4.6 hard is movement. Engineers rotate, contractors roll off, and a data scientist who signed off a model last year may now be on another product. A competence record that was accurate at the time of the audit can be stale within months. Annex B gives implementation guidance for this control, and the NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft, maps related AI RMF items such as GOVERN 3.1 on diverse teams and MAP 3.4 on operator proficiency to B.4.6; NIST notes that posting the crosswalk is not an endorsement. Confirm the current wording of the Annex B guidance with the standard itself, and treat the crosswalk as a starting point for your own mapping rather than a finished answer.

Which roles, teams and third parties fall inside A.4.6

A.4.6 only works when the organization decides who counts as a resource before it writes anything down. The cards below cover the scoping decisions that change the work, from which AI systems are in scope to how contractors and decommissioning staff are recorded. Each decision feeds the statement of applicability, which must justify including or excluding A.4.6.

AI systems in management system scope

Start by fixing which AI systems sit inside the AI management system boundary. A.4.6 records people per system or per life cycle activity, so an AI system left out of scope also drops its staff from the record. Write the boundary as a list of named systems, and check that it matches the scope statement required by clause 4.3 and the entries in the AI system inventory. Systems added later, such as a vendor model switched on in one team, should trigger an update to both lists.

Life cycle stages each team touches

Map each team to the stages it actually works in: design, development, deployment, operation, maintenance and decommissioning. A.4.6 names these activities, so a record that lists only the engineering team leaves operators and retirement staff undocumented. For each team, note the stage and the period it is involved. A short matrix of teams against stages is usually enough for an assessor to see whether any stage has no named people.

Contractors and third-party staff

Decide whether contractors, outsourced labelers, managed service staff and implementation partner personnel appear in the record. Staff who build, tune, operate or retire an AI system affect its performance, so omitting them leaves a gap. Where a third party employs the person, record the organization, the role and the competence evidence the contract provides, and link that to the supplier controls in A.10. Confirm what the contract allows you to obtain from the third party before you rely on it.

Grouping data scientists, operators and reviewers

Group roles by the work they perform on the system rather than by job title. Data scientists who train models, operators who run inference and monitor outputs, and reviewers who approve model changes or assess outputs have different competence needs and different risks. Use a small set of role groups, define each one in a sentence, and assign each named person to one primary group. Titles such as analyst or engineer often hide that one person both builds and reviews the same system, which an assessor will ask about.

Decommissioning and retirement staff

Decommissioning is easy to leave out because it happens late and involves few people. Record who approves retirement, who removes data, models and access, who archives logs and documentation, and who signs off that the system is no longer in use. These roles often sit with infrastructure, security or records teams outside the AI group. Confirm that each named person still holds the competence needed for the retirement steps, since a system may be retired years after the people who built it have moved on.

Statement of applicability justification

Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization needs and justifies including or excluding each one. If the organization excludes A.4.6, the written justification must show why no people resources need documenting for its AI systems, which is hard to defend when any AI system has staff. Record the decision, the date, the approver and the systems it covers. Review the justification whenever the scope or the teams change.

How A.4.6 links the people record to clause 7.2 competence evidence

The A.4.6 record and the clause 7.2 competence evidence should be kept as two linked records, not one document that tries to do both jobs. The A.4.6 record answers who is involved in each AI system life cycle activity, such as development, deployment, operation, maintenance and decommissioning, and what role each person plays. Clause 7.2 asks a different question: what competence is needed for work that affects AI performance, and what evidence shows that people have it. The first record defines the demand for people by activity; the second shows whether the people named against that demand are qualified for it.

The practical link is a shared key. Each person entry in the A.4.6 record should reference the activity or role it covers, and each competence entry under clause 7.2 should point back to the person, role and life cycle activity it supports. A reader auditing one record should be able to reach the other in a few steps. For example, if the A.4.6 record lists a model evaluation role during deployment, the competence file for that role should show the training, experience or review that qualifies the person for it, and a dated check that the qualification is still current. Illustrative only: a gap appears when a deployment role is staffed by someone with no recorded competence evidence.

Confirm three things with your own management system owner before you build the cross-reference. First, whether your competence process already sets the required competence per role, so the A.4.6 entries reuse those definitions rather than duplicating them. Second, who updates the record when staff change roles, since a stale A.4.6 entry is the most common way the two records drift apart. Third, how your internal audit and management review will sample both records together. The clause 7.2 requirement is about keeping evidence, so the cross-reference is only useful if each link is dated and retrievable when an assessor asks for it.

How an assessor tests A.4.6 human resources

This table sets out the steps an assessor typically takes to test A.4.6, the test each step applies, the evidence requested and the findings that most often appear. Read it top to bottom as the audit sequence, and use the last column to check your own record before the assessor arrives.

Test step	What the assessor checks	Evidence requested	Common finding
Review the resource record	Whether the human resources record lists the roles, people and competences for each life cycle stage, including development, deployment, operation, maintenance and decommissioning	Current human resources section of the resource record, with version history and owner	Record lists job titles only, with no named individuals or no link to life cycle stages
Sample life cycle activities	Whether the people who performed sampled activities appear in the record for that stage	Change tickets, release approvals, deployment logs and incident records for a sample of AI systems	Activities performed by people who are absent from the record
Check competence against the record	Whether the people doing the work held the competence the record and clause 7.2 evidence say they needed	Training records, certificates of completion, role-based competence matrices and assessment results	Competence records that do not match the names or roles in the resource record
Interview stage owners	Whether owners can describe their responsibilities, handovers and escalation paths in their own words	Interview notes, owner sign-off on the record and responsibility descriptions	Owners unaware they are listed, or describing duties not recorded anywhere
Test decommissioning roles	Whether someone is assigned to retire the AI system, its data and its access, and whether that assignment is documented	Decommissioning plan, named retirement owner and access revocation records	Decommissioning roles missing or assigned only to a team with no named person
Review contractors and suppliers	Whether external staff who build, operate or maintain the system are named, with their competence evidenced	Contractor list, statements of work, supplier competence evidence and access records	Unnamed contractors or vendor staff with system access but no record entry
Check maintenance across staff changes	Whether the record was updated when people joined, moved or left, and whether handovers were recorded	Change log for the record, leaver and mover checklists, and handover notes	Record unchanged for months while staff have left or changed roles
Confirm link to clause 7.2	Whether the competence needs in the record match the competence determination and evidence kept under clause 7.2	Clause 7.2 competence determination, cross-referenced to the resource record	Two separate lists that disagree on who is competent for which role

How to build the A.4.6 people record step by step

This sequence turns the life cycle into a named register of roles, competences and evidence, so an assessor can trace who did what on each AI system and why they were qualified to do it. Each step produces a record that the next step builds on.

Map the AI system life cycle stages
Start by listing the life cycle stages your organization actually runs for each AI system in scope, such as development, deployment, operation, maintenance and decommissioning. Use the stages your own AI management process defines, and confirm them with the owners of each system. The output is a short stage list per system, agreed by the people who run those stages, so that no stage is left without a named set of people.
List the activities within each stage
Under each stage, record the concrete activities performed, such as model training, data labeling review, release approval, monitoring alerts, retraining, access revocation and archiving of records at decommissioning. Work from tickets, runbooks and change records rather than memory, because those artifacts show what really happens. The output is an activity list where every activity has a stage, a system and a short description.
Identify roles and people for each activity
For every activity, name the role that performs it and the individuals who currently hold that role, including contractors and staff at third parties who work on the system. Distinguish people who perform work from people who approve it, since both affect AI performance. The output is a role-to-activity matrix with named people, which shows gaps such as an activity with no named owner or one person covering a critical stage alone.
Record the competences each role needs
For each role, describe the knowledge, skills and experience the work requires, such as model evaluation, data protection, secure deployment or incident handling. Clause 7.2 asks you to determine this competence for people whose work affects AI performance, so write the requirement before checking the person. The output is a competence profile per role that a reviewer can compare against each person's record.
Link each person to competence evidence
For each named person, attach the evidence that shows they meet the competence profile for their role. Evidence can include training completion records, certifications held, documented assessments, supervised work history or performance reviews, depending on what your organization accepts. Where a gap exists, record the planned action, such as training or supervised assignment, and who will track it. The output is a per-person record that ties each role assignment to dated, retrievable evidence.
Assign an owner for the record
Name one accountable owner for the people record and a deputy, typically in AI governance, HR or platform engineering, and document their responsibilities. The owner decides how changes are submitted, who approves them and where the record is stored. The output is a documented ownership statement and a stated update process that the team can follow without asking who holds the pen.
Review the record at defined points
Set review triggers in writing, such as a role change, a new hire or contractor joining an activity, a material system release, a retirement from the system and the annual management review cycle your organization uses. At each trigger, check that the matrix, competence profiles and evidence still match reality, then record the review date and reviewer. The output is a dated review history that shows the record is maintained and not written once and forgotten.

Evidence that satisfies A.4.6 and how to keep it current

An assessor testing A.4.6 looks for a human resource record that names the people and competences behind each life cycle stage, and for proof that the record is maintained. The cards below cover the artifacts that carry that proof and the habits that keep them accurate between audits. Each one links back to the competence evidence required under clause 7.2.

Human resource record by life cycle stage

This is the core artifact for A.4.6: a register that lists the roles or named people involved in development, deployment, operation, maintenance and decommissioning of each AI system. Structure it by stage so an assessor can trace who did what at each point. Check that every stage in your system's life cycle has at least one accountable role, and that decommissioning is not left out because it happens least often. Review the record whenever a system moves stage or changes owner.

Role descriptions for AI work

Role descriptions state what each person is expected to do with an AI system, which decisions they own and which they must escalate. For A.4.6, they connect the human resource record to actual responsibilities rather than job titles alone. Ask whether each description names the AI-specific duties, such as model evaluation, data review or monitoring, and whether it was approved by someone outside the team doing the work. Store them with version history so the reviewer can see when a responsibility was added or removed.

Competence matrix per role

A competence matrix maps each role to the skills, knowledge and experience it requires, and records whether each person meets them. This is where clause 7.2 meets A.4.6: the matrix shows the competence needed and the evidence that it is held. Update it when staff join, move or leave, and when an AI system adopts a new technique or tool that demands skills the team did not previously need. Gaps should show as open actions with owners and dates, not silent blanks.

Training and completion records

Training records prove that people acquired the competences the matrix says they need. Keep the course or activity, the date completed, the outcome and the person who verified it. Completion tracking built into a learning platform can generate much of this automatically, but confirm that the platform records completion on the basis you intend, such as a grade or a manual sign-off, rather than simply opening the material. Review records against the matrix at a set interval so lapsed or missing training is caught before an audit.

Change history of the record

An assessor will ask who edited the human resource record, when, and what changed. Version control on the wiki or document system that holds the record answers this directly, because each change is stored with its author and timestamp and earlier versions can be compared or restored. Confirm that edits to role assignments are made in the controlled system, not in offline copies, and that the history cannot be cleared by ordinary editors. Keep the history for the full period you expect to be audited.

Access permissions on the record

Who can edit the human resource record is itself evidence. Role-based permissions let you restrict edits to the accountable owner while allowing wider read access to staff and assessors. Check that permissions are set at the level where the record actually lives, whether shelf, book, chapter or page, and that overrides are documented. Review who holds edit rights at the same cadence as the competence review, and remove access for people who have changed roles.

Cross-references to clause 7.2 evidence

A.4.6 records should point to the clause 7.2 competence evidence rather than duplicate it. Each role or person in the record links to the matrix entry, training record and any assessment that shows competence was held. Broken links are a common finding, so check them at each review. The aim is that an assessor can start from any AI system, follow its stages to the people involved, and reach proof of their competence in a few steps.

Open-source tools that keep A.4.6 competence and role records

Moodle is a learning management platform that can record whether people have completed AI-related training, such as courses on responsible use, model risk or secure development. Its activity completion feature is the part that produces evidence, because the completion state depends on the conditions set for each activity. An activity can be marked complete when a learner views it, when they receive a grade from it, or when they tick it manually. The choice of condition determines what the record proves, so it should match the competence the course is meant to build.

View-based completion: Suitable for orientation material, but it shows exposure to content rather than understanding.
Grade-based completion: Links completion to a scored assessment, which gives a stronger signal of competence.
Manual completion: Needs a named supervisor to confirm, so the record should show who ticked it and when.
Course-level reports: Export completion status by learner for review against the role requirements in your resource record.
Licence: Moodle is licensed under GPL-3.0-or-later.

Confirm with your own environment whether your Moodle version and plugins provide the completion reports, retention settings and access controls your auditors will ask for.

What meeting A.4.6 costs in money and effort

This table lists the main cost components of documenting human resources under A.4.6, who carries each one, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are stated because none were supplied, so use the table to shape a quote request and internal estimate rather than as a budget.

Cost component	Who carries it	One-time or recurring	What drives it up or down
Defining roles and required competences for each AI life cycle stage	Internal governance, AI leads and HR specialists	One-time, then revisited when roles change	Number of AI systems, number of distinct roles, and how many life cycle stages each system touches
Maintaining the people record and linking it to clause 7.2 competence evidence	HR and line managers	Recurring	Staff turnover, contractor churn, and how often competence records are reviewed
Tooling for the record and training evidence	Internal platform or IT team	One-time setup, then recurring administration	Open-source tools remove license spend, but hosting, patching, backups and access administration still need staff time
Training delivery and completion tracking	Training owners and subject matter experts	Recurring as roles and AI systems change	Size of the affected workforce, the depth of role-specific content, and whether training is built in house or bought
Internal review of competence gaps and records	Internal audit or compliance staff	Recurring, usually tied to the internal audit cycle	Scope of the AI management system and the number of records sampled before audit
External review or auditor sampling of human resource evidence	Independent certification body or auditor, paid by the organization	Recurring at each audit cycle	Number of AI systems in scope, number of people sampled, and the quality of records at the start of the audit
Outside readiness support, if used	Implementation partner or consultant under a written scope	Usually one-time for readiness, optional retainers after	Scope agreed in writing, number of systems and roles covered, and how much record-building the internal team handles itself

Who owns A.4.6 and what can be outsourced

Your organization owns A.4.6 in full. Only your people can decide which roles touch each AI system life cycle stage, which competences those roles need, and whether a given person meets them. Those decisions create the accountability that an auditor will trace, so they cannot be delegated to a consultant or a tool.

Role decisions: Name the people and roles involved in development, deployment, operation, maintenance and decommissioning for each AI system, and assign an accountable owner.
Competence judgments: Decide what competence each role needs and whether individuals meet it, in line with the competence requirement in clause 7.2.
Record content: Maintain the entries, update them when staff change, and remove people who leave the work.
Evidence of competence: Keep training completions, qualifications and assessment results that support each judgment.
Management review: Confirm the record is current during internal audit and management review.

Confirm with your internal audit lead which person signs off on the competence judgments before any outside party starts work.

Where A.4.6 records usually fall short

Most A.4.6 human resource records fail the same way: they name people and titles but not the competences those people need, and they drift out of date as staff, contractors and vendors change. The cards below cover the gaps assessors most often find and how to close each one before the evidence is requested.

Job titles without competences

A roster that lists titles such as ML engineer or data steward tells an assessor who exists, not what they can do. For A.4.6, record the competences each role needs across the life cycle, such as model validation, privacy review or incident handling, and the evidence that the person holds them. Clause 7.2 expects the organization to determine required competence and keep evidence of it, so each role entry should point to training records, certifications or documented assessments. Check that every role touching AI performance has both a required-competence line and a current evidence link.

Contractors and vendor staff missing

AI systems are often built, tuned or operated by contractors, consultants and vendor engineers whose names never reach the internal roster. Those people still affect AI performance and risk, so they belong in the A.4.6 record, with the employer, the scope of their work and the competence evidence the contract requires. Confirm that supplier agreements require vendors to provide that evidence and to notify changes in staffing. Where a vendor cannot name its people, record that gap as a risk and assess it under the third-party controls in A.10.

No decommissioning roles

Most records cover development and deployment but name nobody for maintenance, retirement or decommissioning. A.4.6 asks for the people involved across the whole life cycle, including decommissioning, so each system should list who retires the model, removes its data access, archives its documentation and closes its logs. Confirm the named owner exists in the current organization chart and that the role has been exercised on at least one planned change or test retirement. Gaps here often surface only when a system is switched off, so check them during planning rather than at the end.

Records not updated after reorganizations

A record that was accurate at launch can point to people who have moved teams, left or changed responsibilities after a restructuring. Stale entries are easy to miss because the system still runs, but an assessor comparing the record with access lists and HR data will see the mismatch. Set a trigger for review on every reorganization, departure and change of AI system owner, and reconcile the A.4.6 record against directory and access-management data at a defined interval. Keep the change history so the record shows who was responsible on any given date.

Competence evidence not linked to records

Training certificates and assessment results often sit in an HR system or learning platform that is not connected to the AI resource record, so the link between a person, a role and proof of competence has to be rebuilt during an audit. Link each A.4.6 entry to its evidence by identifier or location, and state which competence each piece of evidence supports. Learning platforms such as Moodle can record activity completion for a course, which helps show that training occurred, but confirm that the completion condition reflects competence and not only page views. Keep the link current as records are renewed.

Questions buyers ask about A.4.6 human resources

How much effort does A.4.6 take for a small team?

For a small team, A.4.6 is usually a bounded documentation task rather than a large program, because the control asks you to record the people and competences involved in each AI life cycle stage, not to build new processes from scratch. The effort rises with the number of AI systems, the number of teams that touch them, and how many people change roles over time. A small team with one or two AI systems can often complete a first record in a few working sessions. Ask any partner to show how they would scope the record, which roles they would list, and which existing documents (job descriptions, training logs, on-call rotations) they would reuse.

Can we do A.4.6 in-house without outside help?

Yes, most organizations can document A.4.6 in-house, because the work depends on knowing who does what, which your own managers and engineers already know. The organization owns its controls, its statement of applicability and its evidence. Outside help is useful when the team lacks a clear view of its own roles, when several business units share AI systems, or when the record must line up with an external audit. An implementation partner can prepare the record and the evidence trail, but it cannot decide who is competent for a role or issue an audit report.

What does an implementation partner need from our side?

A partner needs access to the people who actually run AI work, not only the HR org chart. Typical inputs include a list of AI systems in scope, the life cycle stages each one passes through, role descriptions, training and qualification records, and the names of owners for development, deployment, operation, maintenance and decommissioning. The partner also needs your decision on the statement of applicability and a named internal owner who can approve the record. Ask for these inputs in writing as part of the fixed scope before work starts.

How long does A.4.6 work take?

The duration depends on scope, and no fixed figure applies to every organization. The main drivers are the number of AI systems, how many teams and vendors contribute people, how current your role descriptions and training records are, and whether the record must be reviewed by internal audit or an external assessor. Work that reuses existing HR and learning records usually moves faster than work that needs interviews across several departments. Ask for a written timeline tied to the agreed deliverables, and confirm which dependencies sit with your team.

How does A.4.6 relate to clause 7.2 on competence?

A.4.6 asks you to document the human resources and their competences across AI life cycle activities, while clause 7.2 asks you to determine the competence needed by people whose work affects AI performance and to keep evidence of it. In practice, the A.4.6 record names the roles and the competences each stage needs, and the clause 7.2 evidence shows that the named people meet those needs, through training, qualifications or documented experience. Treat the two as one linked set of records so an assessor can trace a role to a competence to proof that the person holds it.

Can the NIST AI RMF crosswalk support our A.4.6 mapping?

The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft and posted by NIST, maps AI RMF GOVERN 1.6, GOVERN 3.1, MAP 1.2 and MAP 3.4 to B.4.6, so it can help you see where your NIST AI RMF work already covers human resources. NIST states that posting the crosswalk is not an endorsement. Use it as a starting point for discussion, not as proof of conformance. Confirm the mapping against the current text of both documents and check with your certification body how it will accept the cross-reference.

Which open-source tools can keep our competence evidence?

Learning platforms, wikis and permission systems can hold A.4.6 and clause 7.2 evidence if they record completions, versions and access. Moodle's activity completion can mark a training activity complete for each learner when they view it, receive a grade or tick it manually, which can support competence records. XWiki keeps version history of each page, showing what changed, when and by whom, which helps show how a role record changed over time. BookStack assigns permissions through roles, which helps limit who can edit the record. Confirm each tool's fit with your evidence requirements before you commit to it.

How DeployOpen prepares A.4.6 people records and evidence

DeployOpen starts this work with a written, fixed-scope agreement that names the AI systems covered, the life cycle stages in scope (development, deployment, operation, maintenance and decommissioning), and the people roles whose competence records must exist. The agreement also states who inside the client organization approves the record structure and who signs off the evidence. Before any build begins, the client should confirm which roles count as people involved in each stage, because A.4.6 is only as complete as the role inventory behind it. Deliverables, timelines and exclusions are fixed in writing before work starts, and the organization owns its controls throughout.

Inside the client's own infrastructure, DeployOpen configures the people record as a set of linked pages with a fixed template: role, life cycle stages served, required competences, training or qualification evidence, and the date of the last review. Moodle can record completion of training activities, with the activity completion conditions set so that a record reflects a deliberate step rather than a page view alone. XWiki keeps version history so reviewers can see when a role description or competence requirement changed and who changed it. BookStack permissions can be set per shelf, book or page so that only authorized owners edit competence records while auditors and other staff have read access. Each choice is a decision the client confirms, not a default DeployOpen imposes.

The evidence pack links each person's role to the competence requirements that clause 7.2 asks the organization to determine and retain, and maps those records to A.4.6 for the statement of applicability. The client should confirm the mapping with its own certification body or assessor before relying on it, since DeployOpen prepares the records but does not judge conformity. An independent auditor or certification body issues any report or certificate, and DeployOpen does not hold that status. Ongoing upkeep, such as periodic reviews of competence records after staff changes, is handled by the client's owners or by a separate retainer if the client chooses one.

A.4.6 Human resources