5.1 Clause 7 Support
Key Takeaways
- Clause 7.1 requires resources adequate for establishing, implementing, maintaining, and continually improving the AIMS—including people, compute, data infrastructure, tooling, and specialist support.
- Clause 7.2 competence is a four-step loop: determine needed competence, ensure people are competent (education/training/experience), evaluate effectiveness of actions taken, and retain appropriate evidence.
- Clause 7.3 awareness covers the AI policy, contribution to AIMS effectiveness, implications of not conforming, and benefits of improved AI performance—not a one-slide annual video alone.
- Clause 7.4 requires determining what, when, with whom, how, and who communicates—internally and externally—for AI-relevant topics such as incidents, model changes, and transparency notices.
- Clause 7.5 documented information must be created/updated with identification, format, and review/approval, then controlled for availability, protection, distribution, retention, and disposition—critical for model cards, SoA, impact assessments, and training records.
5.1 Clause 7 Support
Auditor focus: Do people, tools, and records exist so the AIMS can work? Can the organization prove competence for AI roles? Are model cards, impact assessments, and the SoA controlled as documented information—not orphan files on a laptop?
Clause 7 is the Support block of the Harmonized Structure. After Clauses 4–6, the organization must equip the AIMS with resources, competent people, aware personnel, planned communication, and controlled documented information. For AI, support failures are concrete: wrong people approve models, training is generic "AI ethics" with no role mapping, and critical artifacts lack version control.
Subclause Map for Auditors
| Subclause | Requirement theme | Evidence auditors request | Frequent weakness |
|---|---|---|---|
| 7.1 | Resources | AI governance capacity, MLOps/monitoring platforms, compute/data pipelines | Policy exists; no sustained tooling for oversight |
| 7.2 | Competence | Role matrix, training records, effectiveness checks | Certificates collected; effectiveness never evaluated |
| 7.3 | Awareness | Campaign materials; interview probes | Staff know a policy exists but not contribution or nonconformity implications |
| 7.4 | Communication | Plan for what/when/whom/how/who | No plan for model-change or external transparency notices |
| 7.5 | Documented information | SoA, model cards, impact assessments, training evidence under control | Uncontrolled wikis; model cards with no owner/version |
7.1 Resources
The organization shall determine and provide resources needed to establish, implement, maintain, and continually improve the AIMS.
| Resource type | AI-specific examples | Why auditors care |
|---|---|---|
| People | Model owners, AI risk roles, data stewards, human-oversight operators | Unowned production models; committees with no capacity |
| Infrastructure | Compute, feature stores, logging/monitoring stacks | Monitoring promised but no platform |
| Data & information | Evaluation sets, lineage tooling | Bias/impact work starved of resources |
| Budget / time | Independent evaluation, gated releases | "Ship weekly" with zero gate funding |
| External support | Specialists, validators, cloud AI under contract | Over-reliance without oversight |
Probe: If risk treatment requires drift monitoring but tooling and on-call roles are "next year," 7.1 (and linked Clause 8) is in play.
7.2 Competence
Competence is the most exam-sensitive Support subclause—a closed loop:
- Determine necessary competence for persons whose work affects AIMS performance and AI outcomes.
- Ensure competence via education, training, or experience.
- Where applicable, take actions to acquire competence and evaluate effectiveness of those actions.
- Retain documented information as evidence of competence.
| Role | Competence themes to sample | Evidence examples |
|---|---|---|
| Data scientists / ML engineers | Evaluation design, bias metrics, secure MLOps | Project history, evaluation reports |
| Model / product owners | Risk tiering, gates, impact assessment, change control | Decision records, procedure training |
| AI risk / compliance | 42001 process, risk method, residual risk acceptance | Method training, authored risk files |
| Human-oversight operators | Escalate/stop rules, interface limits, authority | Scenario drills, SOP sign-off |
| Procurement / vendor managers | Third-party AI due diligence, contract clauses | RFP checklists, supplier assessments |
Effectiveness trap: An LMS completion rate of 100% without post-training assessment, observed correct use of release checklists, or other effectiveness evaluation does not close the 7.2 loop.
Scenario: A bank maps all data scientists to "AI ethics e-learning," yet credit-model owners cannot design fairness evaluation and outsource it without understanding results. Finding: 7.2—competence not determined/ensured for roles affecting AI outcomes; effectiveness of actions not evaluated.
7.3 Awareness
Persons doing work under the organization's control shall be aware of the AI policy, their contribution to AIMS effectiveness (including benefits of improved AI performance), and the implications of not conforming.
Awareness is broader than competence. A call-center agent may not need model-training skill, but must know acceptable use, data restrictions, escalation, and that shadow public chatbots for customer data are nonconforming.
Interview probe: What is the AI policy about? What if you paste personal data into an unapproved tool? How do you escalate a harmful output?
7.4 Communication
Determine internal and external communications relevant to the AIMS: on what, when, with whom, how, and who communicates.
| Direction | Example topics |
|---|---|
| Internal | Policy updates; go-live/rollback; operator limitations; incident reporting |
| External | Transparency notices; regulator notifications; customer model-change notices; supplier coordination |
Trap: "We have Slack and a website" is not a determination. High-impact systems need accountable channels for incidents, bias findings, and material model changes.
7.5 Documented Information
Create/update (7.5.2): identification and description (title, date, author, reference), format/media, review and approval for suitability.
Control (7.5.3): availability and protection; distribution, access, retrieval, use, storage, preservation, change control, retention, disposition. Control external-origin documented information determined necessary for the AIMS (vendor model cards, API terms, evaluation reports).
| Artifact | Sampling expectation |
|---|---|
| AI policy & objectives | Approved, accessible |
| SoA | Versioned, approved, linked to risk treatment |
| Risk / treatment files | Current, change-controlled |
| Impact assessments | Identified, approved, retrievable |
| Model / system cards | Owner; version matches deployed model ID |
| Competence records | Retained as 7.2 evidence |
Auditor sampling of training records and AI docs
- Pull document-control rules.
- Sample 3–5 AI systems across risk tiers.
- Trace: production model ID → model card → impact assessment → risk file → SoA references → model-owner competence evidence.
- Test version alignment (card vs live model) and orphan stores (uncontrolled wikis/drives as the real procedure).
Scenario: Chatbot v3.2 is live; model card is an unapproved shared doc describing v2.1; impact assessment is email-only. Primary hook: 7.5 (often with 8.1).
Common Nonconformities
Resources promised in treatment plans not provided; competence as "data science degree" without AI-risk skills; training without effectiveness evaluation; awareness as generic IT modules only; no external communication determination; SoA/model cards/impact assessments uncontrolled or misaligned with deployment; vendor docs not identified as external-origin controlled information.
Clause 7 enables Annex A and Clause 8—it does not replace them. Weak support predicts operational evidence collapse.
Under ISO/IEC 42001 Clause 7.2, which sequence best reflects the competence requirements an auditor expects to see evidenced?
During Stage 2, an auditor finds that production model cards are editable wiki pages with no version history, approval, or link to the deployed model identifier, while the SoA is a two-year-old email attachment. Which subclause is most directly implicated?
Which situation best illustrates a Clause 7.3 awareness gap rather than a pure Clause 7.2 competence gap?
What should an ISO/IEC 42001 lead auditor primarily look for when sampling Clause 7.4 communication for a high-impact AI system?