ISO 42001 AI Impact Assessment: A Template an SMB Can Actually Fill
ISO 42001 AI Impact Assessment: A Template an SMB Can Actually Fill
The AI impact assessment is the one artifact ISO 42001:2023 requires that ISO 27001 does not. It is also the one SMBs most often overcomplicate — a 40-page dossier instead of a one-page-per-use-case document an auditor can actually read.
ISO/IEC 42001:2023 clause 6.1.4, reinforced by the operational clause 8.4, requires an AI system impact assessment for AI systems within the scope of the AI management system. Where ISO 27001 clause 6.1.2 asks you to assess information security risks against the CIA triad, ISO 42001 asks you to assess each AI system against its trustworthiness concerns and its impact on people. It is the bridge between the AI risk register and the controls you select — and like the ISO 27001 Statement of Applicability, it is the document the auditor reads first.
This article gives a template structure a one- to three-person IT team can fill per AI use case in an hour, explains what the clauses actually require, and walks through a worked example.
What clause 6.1.4 / 8.4 actually requires
The standard requires the organization to assess the impacts of AI systems on individuals, groups, society, and the organization itself, considering the intended purpose, the context of use, and the trustworthiness concerns that apply. The assessment informs which controls are selected and recorded in the Statement of Applicability. The standard does not mandate a fixed format, a fixed length, or that every trustworthiness concern apply to every system — it mandates that the assessment happen, that it be documented, and that it drive the controls.
That last point is the one that matters for audit: the controls in your SoA should trace back to a concern identified in an impact assessment. A control with no assessment behind it is a control implemented for the checklist, not for the risk.
The template: sections an SMB needs
Use one document per AI use case, with these eight sections. Fewer and you lose the audit trail; more and you stop maintaining it.
| Section | What goes in it | Example |
|---|---|---|
| AI system & purpose | What the system is and what it does | LLM assistant drafting customer-support replies |
| Role in the system | Provider / producer / deployer / user (per clause 4.1) | Deployer — we use a vendor-hosted model |
| Decisions informed or automated | What the output drives, and whether a human acts on it | Drafts replies a human reviews before sending; no automated decisions |
| Stakeholders affected | Who is impacted if it works or fails | Customers (receive replies), support staff (use it), business (reputation) |
| Trustworthiness concerns | Which apply: security, safety, fairness, transparency, data quality, lifecycle quality | Transparency, security, data quality (see below) |
| Impact if it fails or misbehaves | The concrete harm, and its severity | Wrong advice sent to a customer; leakage of PII into a reply |
| Controls applied | The specific controls, per concern, with evidence | Human-in-the-loop review; no PII in prompt; output monitoring |
| Review schedule | When reassessed, and on what trigger | Annually, and on model change or new use case |
The Trustworthiness concerns row does double duty: it is where you decide which of the six concerns actually apply (do not check all six reflexively — that signals you did not assess), and it feeds the control selection. The Controls applied row is what flows into the SoA.
A worked SMB example
A small professional-services firm uses a vendor-hosted LLM to draft first-pass replies to customer support emails. The assessment:
| Section | Entry |
|---|---|
| AI system & purpose | Vendor-hosted LLM that drafts a reply from the customer’s email + the firm’s knowledge base |
| Role | Deployer (we use it; we did not build or train it) |
| Decisions | Informs a reply; a human agent reviews, edits, and sends. No automated action. |
| Stakeholders | Customers, support agents, the firm |
| Trustworthiness concerns | Transparency (customer should know AI assisted); security (PII leakage, prompt injection); data quality (knowledge base accuracy). Fairness: low — not used for decisions about people. Safety: low — advisory text. Lifecycle: vendor manages model updates; we monitor outputs. |
| Impact if it fails | PII leaked into a reply (severity 4); wrong advice sent (severity 3); reputational damage (severity 3) |
| Controls | Human review before send (transparency + safety); PII stripped from prompt input (security, data minimization); prompt-injection defenses per our <a href="/llm-prompt-injection-smb-defense/">prompt injection guide</a>; output monitoring for leakage (security); knowledge-base change log (data quality) |
| Review schedule | Annually; on vendor model change; on any new use case |
This is one page. It names the concerns that genuinely apply, drops the ones that do not (with the reasoning visible), ties each control to a concern, and sets a review trigger. That is a defensible 6.1.4 assessment — and the controls row is the input to the SoA.
Three mistakes to avoid
- **Checking every concern.** An assessment that applies all six trustworthiness concerns to every system tells the auditor you did not assess, you listed. Real assessments exclude concerns with a reason — "fairness: not applicable, the system does not inform decisions about individuals."
- **Controls with no concern.** If a control in your SoA does not trace to a concern in any impact assessment, either the assessment missed it or the control is unjustified. Reconcile the two before the audit.
- **One-and-done.** Clause 8.2 (inherited from the shared structure) requires reassessment at planned intervals or on significant change. A model retrain, a new use case, or a vendor change is a trigger. Set the review date in the assessment and honor it.
How this fits the series
The impact assessment is the AI counterpart to the ISO 27001 risk assessment, and it is the artifact that feeds the integrated SoA described in the joint 27001 + 42001 implementation. The Annex A explainer is where the control objectives you select here live. If you are starting the AI governance work, the ISO 42001 pillar is the entry point.
What to do next
Open a document, copy the eight-section template, and fill it for the AI system your team uses most. Decide which trustworthiness concerns actually apply, write the one-line reasoning for each excluded one, and list the controls per concern. That single page — an hour’s work — is your first compliant 6.1.4 assessment and the input to your SoA. Repeat per use case; most SMBs have fewer than five.
Want a second pass on your AI impact assessments before an audit? Book a 30-min **AI governance gap assessment** — we review each assessment against clause 6.1.4, flag the unjustified controls and the missing concerns, and hand you the corrections. Bilingual EN/FR, no obligation.
Get Your Free Security Readiness Assessment
Map your controls, identify compliance gaps, and secure your systems before the audit.