7.2 A.2 Policies Related to AI & A.3 Internal Organization
Key Takeaways
- A.2 covers three controls: AI policy (A.2.2), alignment with other organizational policies (A.2.3), and review of the AI policy (A.2.4)—auditors test approval, communication, conflict resolution with security/privacy/HR policies, and planned or triggered reviews.
- A.3 covers AI roles and responsibilities (A.3.2) and reporting of concerns (A.3.3)—accountable owners, decision rights, and protected channels for AI-related concerns are expected evidence.
- Clause 5.2 AI policy and A.2.2 are complementary: leadership requirements in the management system and Annex A control measures reinforce each other; plan criteria carefully when classifying findings.
- Strong evidence includes approved policy versions, RACI/role descriptions for AI decisions, concern logs with non-retaliation, and review records after incidents or regulatory change.
- Typical NCs: draft policy never approved; policy silent on prohibited uses; dual-hatted “everyone owns AI”; no concern channel; reviews never executed despite annual schedule claims.
7.2 A.2 Policies Related to AI & A.3 Internal Organization
Auditor focus: Governance fails in silence—policies nobody can find, roles nobody owns, and concerns nobody can raise. For A.2 and A.3, sample approval, communication, alignment, role clarity, and concern handling, then walk those controls into one high-risk AI system.
A.2 Policies Related to AI
Control objective (intent): Provide management direction and support for AI consistent with business requirements and the organization’s approach to AI risk and impact.
Control group at a glance
| Control | Name | What “good” looks like | Weak signals |
|---|---|---|---|
| A.2.2 | AI policy | Top-management-approved AI policy covering principles, scope of AI activities, responsibilities pointers, and expectations for development/use | Draft wiki page; marketing “AI ethics” poster with no approval |
| A.2.3 | Alignment with other organizational policies | Explicit reconciliation with security, privacy, quality, HR, procurement, acceptable use | AI policy contradicts privacy retention rules or security change control |
| A.2.4 | Review of the AI policy | Planned intervals and triggers (regulation, major incident, strategy shift); records of review outcomes | “Annual review” checkbox with no minutes or version change in three years |
A.2.2 — AI policy (audit content)
Expect a documented AI policy that is appropriate to the organization’s purpose and context. Content themes auditors commonly test (tailored to risk):
- Commitment to responsible/trustworthy AI characteristics relevant to the organization (e.g., fairness, transparency, safety, human oversight where needed)
- Direction on acceptable and prohibited AI uses
- Linkage to risk appetite and escalation
- Expectations for compliance with law and contractual AI terms
- How the policy is communicated to relevant personnel and, where appropriate, external parties
Interview probes:
- Who approved the current AI policy version, and when?
- How do data scientists and product managers learn what is prohibited?
- Where is the policy published (intranet, LMS, onboarding)?
Evidence set: approved policy PDF/controlled document; communication records; training acknowledgment for roles that develop or operate AI; management review references to policy suitability.
Relationship to Clause 5.2: Clause 5.2 requires top management to establish an AI policy with defined attributes (appropriate, provides framework for objectives, includes commitment to satisfy requirements and continual improvement, etc.). A.2.2 is the Annex A control reinforcing policy as an operational control. When both are audit criteria, one NC may cite the clause, the control, or both—avoid double-counting the same gap without clear criteria mapping.
A.2.3 — Alignment with other policies
AI work collides with existing rule sets. Auditors look for intentional alignment, not perfect single-document merges.
| Adjacent policy | Typical friction | Probe |
|---|---|---|
| Information security | Model APIs, training data classification, third-party models | Does change/release of models follow security change process? |
| Privacy / data protection | Training on personal data; automated decisions | Are DPIA/privacy assessments linked to AI use cases? |
| HR / acceptable use | Employee monitoring AI; generative AI for work product | Are monitoring and gen-AI uses authorized and disclosed? |
| Procurement | Buying AI SaaS | Do vendor onboarding criteria include AI policy obligations? |
| Quality / safety | Safety-critical AI | Are quality gates and AI policy gates the same release? |
NC example: AI policy encourages “rapid experimentation in production,” while the ISMS change policy requires dual approval for production changes—teams follow the AI slogan; security tickets show unapproved model swaps. Raise against A.2.3 (and potentially operational controls/Clause 8).
A.2.4 — Review of the AI policy
Review shall ensure continuing suitability, adequacy, and effectiveness. Test:
- Defined review frequency
- Event-driven review triggers (new regulation, serious AI incident, M&A, major product line)
- Participants (legal, risk, product, security, domain experts)
- Documented decisions and version control
Scenario: EU AI Act obligations expand for a deployer of high-risk systems; policy still only discusses “internal chatbots.” No out-of-cycle review. Evidence of A.2.4 failure even if the calendar says “reviewed last January” for a cosmetic date stamp.
A.3 Internal Organization
Control objective (intent): Establish accountability within the organization for AI systems and for raising concerns.
Control group at a glance
| Control | Name | What “good” looks like | Weak signals |
|---|---|---|---|
| A.3.2 | AI roles and responsibilities | Defined roles for governance, development, operation, risk/impact, and escalation; people know their authorities | “AI is everyone’s job” with no decision rights; conflicted self-approval of go-live |
| A.3.3 | Reporting of concerns | Known, accessible channels; protection from retaliation; intake → assessment → action trail | Only generic ethics hotline never used for model issues; managers filter all reports |
A.3.2 — AI roles and responsibilities
Map who does what for in-scope AI activities:
| Role type | Examples of accountabilities |
|---|---|
| Governance / AIMS owner | Policy, SoA maintenance, management review inputs |
| System / product owner | Intended use, business risk acceptance, sunset decisions |
| ML / engineering | Design, training, verification support, MLOps |
| Risk / compliance / legal | Risk & impact methods, regulatory interpretation |
| Human oversight roles | Override authority for high-stakes outputs |
| Internal audit | Independent AIMS audit (Clause 9.2)—not operational ownership |
Segregation note: Annex A.3 in ISO 42001 emphasizes roles/responsibilities and concern reporting, not a 27001-style “segregation of duties” control by that name. Still, if one person both builds and solely approves a high-risk model for production, you may find gaps under A.3.2, life-cycle controls (A.6), and risk treatment design—frame findings against actual criteria.
Interview probes:
- Who can authorize production deployment of Model X?
- Who owns residual risk acceptance after impact assessment?
- What happens when product pressure conflicts with risk recommendations?
A.3.3 — Reporting of concerns
Concerns may include bias observations, safety near-misses, unauthorized model use, data misuse, or policy breaches. Test:
- Awareness: Do staff and relevant contractors know the channel?
- Accessibility: Anonymous/confidential options where appropriate
- Independence of handling: Not only the team that wrote the model
- Non-retaliation: Policy + practice
- Linkage to incident management, risk update, and corrective action
Evidence: procedure, portal screenshots, training, at least one handled concern (or a credible test/drill if volume is zero), metrics to management review.
Integrated Audit Walkthrough
Scenario — FinServe ranking model
- Obtain AI policy (A.2.2) and check approval + communication to the credit analytics team.
- Compare AI policy statements on automated decisions with privacy and fair-lending policies (A.2.3).
- Confirm last policy review after a regulator guidance update (A.2.4).
- RACI: product owner vs model risk vs ML lead for go-live (A.3.2).
- Ask two junior analysts how they would report suspected disparate impact (A.3.3); follow one ticket end-to-end.
NC patterns (examples):
| Pattern | Typical criteria |
|---|---|
| Policy exists only as a slide deck without approval/control | A.2.2 / Clause 5.2 |
| Policy never reviewed after material regulatory change | A.2.4 |
| Security policy forbids shadow IT; teams run unsanctioned AI SaaS with leadership praise | A.2.3, A.9, A.10 |
| No named owner for AIMS or for high-risk systems | A.3.2 / Clause 5.3 |
| Concerns must be emailed to the model developer only | A.3.3 |
Trap: Accepting “we follow our Code of Ethics” as a complete AI policy without AI-specific direction. Another trap: org charts that list an “AI Ethics Board” that has never met.
A.2 and A.3 set the governance spine. A.4 asks whether that spine is resourced for real AI systems.
Which set correctly matches ISO/IEC 42001 Annex A.2 controls?
During interviews, staff say the only way to report suspected model bias is to email the lead data scientist who built the model. Which Annex A control is most directly implicated?
What evidence best supports conformity with review of the AI policy (A.2.4)?
An organization’s AI policy encourages “ship experiments to production quickly,” while its information security change policy requires dual approval for production changes. Unapproved model swaps are found in logs. What is the best Annex A framing?