AI system impact assessment

An AI system impact assessment is a documented, repeatable evaluation of how a specific AI system could affect individuals and society, including harms from intended use and reasonably foreseeable misuse. To operationalize ISO/IEC 42001 Clause 6.1.4, you need a defined assessment process, clear ownership, consistent scoring, and retained evidence showing you ran the assessment before deployment and after meaningful change.

Key takeaways:

• ISO/IEC 42001 requires you to plan, conduct, and document AI impact assessments, not just discuss risks informally.
• Your assessment must cover intended use and reasonably foreseeable misuse, with concrete harm scenarios and mitigations.
• Auditors will look for traceability from assessment findings to design controls, deployment decisions, and ongoing monitoring.

Compliance teams often treat “impact assessment” as a policy memo. ISO/IEC 42001 Clause 6.1.4 expects an operational process you can run on demand, attach to release gates, and defend in an audit. The required output is more than a risk register entry. It is a structured assessment that identifies how an AI system could impact individuals and society, including potential harms arising from intended use and reasonably foreseeable misuse. (ISO/IEC 42001:2023 Artificial intelligence — Management system)

This requirement matters most when your organization deploys AI into customer journeys, employee decisions, safety-relevant workflows, or any context where errors, bias, or misuse can create real-world harm. It also applies when you buy AI from a third party and configure or integrate it in ways that shape outcomes. In practice, the impact assessment is the control that forces a cross-functional review: product, engineering, security, privacy, legal, and the business owner all have to align on what can go wrong, who could be harmed, and what you will do about it.

This page gives you requirement-level implementation guidance: who owns it, how to run it step-by-step, what evidence to retain, what auditors ask, and how to stand up the process quickly without turning it into a months-long research project.

Regulatory text

Excerpt (requirement): “The organization shall plan, conduct and document AI system impact assessments that identify how AI systems could impact individuals and society, including potential harms from intended use and reasonably foreseeable misuse.” (ISO/IEC 42001:2023 Artificial intelligence — Management system)

Operator interpretation (what this means in practice):

• Plan: Define and approve a standard method (scope, roles, triggers, templates, approval path). You should be able to show the process existed before the assessment was performed.
• Conduct: Run the assessment for each in-scope AI system and do it at the right time (pre-deployment and after meaningful change).
• Document: Produce durable records: the system description, impact analysis, misuse analysis, mitigations, and sign-offs.
• Identify impacts on individuals and society: Go beyond internal business risk. Include end-user harm, affected non-users, and broader societal effects where plausible (for example, discriminatory outcomes, manipulation, erosion of trust, or unsafe recommendations).
• Intended use and reasonably foreseeable misuse: You must document both how the system is meant to be used and how it could predictably be misused or fail in real settings.

Plain-English requirement (what you’re being asked to prove)

You must be able to prove three things for each AI system:

1. You systematically looked for potential harms, not just security issues or model performance issues.
2. You considered predictable misuse and failure modes, not only your happy-path user story.
3. You acted on what you found (mitigated, limited scope, added human review, improved monitoring, or decided not to deploy).

Who it applies to

Entity scope: Organizations that provide, build, configure, deploy, or use AI systems. (ISO/IEC 42001:2023 Artificial intelligence — Management system)

Operational contexts that typically trigger assessments:

• AI outputs influence decisions about people (eligibility, access, prioritization, discipline, hiring, pricing, claims handling).
• AI generates customer-facing content (advice, medical/financial guidance, instructions, or persuasive messaging).
• AI supports safety-relevant decisions (industrial operations, transportation, cybersecurity response, fraud interdiction with customer impact).
• AI processes personal data or sensitive attributes, even indirectly.
• AI is sourced from a third party but you configure prompts, rules, thresholds, fine-tuning, retrieval sources, or downstream automation.

What you actually need to do (step-by-step)

1) Define the impact assessment procedure (process design)

Create a procedure that answers:

• Scope: Which systems count as “AI systems” in your program; include models, agents, decisioning services, and embedded AI features.
• Triggers: New AI system, major model change, new data source, new use case, expansion to new user populations, automation of previously human decisions, or incident trends.
• Roles: System owner, product owner, ML/engineering lead, privacy, security, legal/compliance, and an approving authority (risk committee or delegated approver).
• Release gate: Where the assessment sits in SDLC or change management. If it is optional, auditors will treat it as nonconforming.

Practical tip: If you need speed, start with a single template and an approval gate tied to production access. You can mature scoring later.

2) Build an AI system profile (one-page factual baseline)

Document:

• Purpose and intended use, including what the system is not approved to do.
• Users and affected parties (customers, employees, applicants, patients, bystanders).
• Inputs (data categories, sources, provenance) and outputs (decisions, scores, text, recommendations).
• Deployment context (channels, geographies, languages, accessibility needs).
• Human-in-the-loop points and fallback procedures.

This profile becomes your audit anchor. Without it, “impact” becomes subjective.

3) Identify impact areas and harm scenarios (individual + societal)

Run a structured workshop (or async review) to generate harms in categories such as:

• Fairness and discrimination: unequal error rates, proxy attributes, exclusion.
• Privacy: unintended disclosure, inference, memorization, data leakage through outputs.
• Safety and well-being: harmful advice, overreliance, self-harm content, unsafe instructions.
• Economic harm: wrongful denial, pricing anomalies, fraud false positives that block access.
• Autonomy and manipulation: dark-pattern personalization, persuasion, deceptive outputs.
• Access and inclusion: language bias, disability barriers, digital divide effects.

For each scenario, write:

• Who could be harmed and how.
• Severity if it occurs, plus plausible frequency drivers (scale, automation level, exposure).
• Existing controls and control gaps.

4) Analyze “reasonably foreseeable misuse”

Document misuse cases you can predict without assuming an adversary is omniscient, for example:

• Users prompt the system for disallowed content.
• Staff use outputs outside intended scope (“rubber-stamping” decisions).
• Attackers attempt data extraction, prompt injection, or model evasion.
• Customers treat probabilistic outputs as guaranteed facts.

Tie misuse to mitigations: guardrails, rate limits, authentication, logging, content filters, training, UX friction, or policy enforcement.

5) Decide and record mitigations, then map to requirements and controls

For each material harm scenario:

• Define mitigation actions (design changes, policy constraints, monitoring, human review).
• Assign an owner and due dates tied to release criteria (for example, “must be complete before production” vs “post-launch improvement”).
• Set acceptance criteria (what evidence proves mitigation exists).

You want traceability: impact finding → mitigation → implemented control → monitoring.

6) Approve, store, and operationalize (make it a living record)

• Obtain formal approval from the accountable risk owner.
• Store the assessment in a controlled repository with versioning.
• Link it to change tickets, model cards, DPIAs (if applicable), and incident records.
• Re-run on meaningful change and after incidents that reveal new harms.

Daydream fit (where it naturally helps): Daydream can standardize intake, route reviews to the right approvers, and maintain an evidence-ready record set across AI systems so you can answer “show me all assessments for deployed models” without manual chasing.

Required evidence and artifacts to retain

Auditors typically want records that prove both execution and decision quality. Retain:

• Approved impact assessment procedure (with roles, triggers, and gate).
• Completed impact assessment per AI system (template output).
• AI system profile (purpose, inputs/outputs, context, constraints).
• Misuse analysis with documented mitigations.
• Meeting notes or decision logs showing cross-functional review.
• Approval record (who approved, date, conditions).
• Links to implemented controls: guardrails, monitoring dashboards, test results, red-team or abuse testing summaries (if you have them).
• Change management linkages: model version, release identifier, rollback plan.
• Incident and complaint linkage: evidence that issues feed back into reassessment.

Common exam/audit questions and hangups

Expect questions like:

• “Show me your impact assessments for AI systems currently in production.”
• “How do you define ‘reasonably foreseeable misuse’ and who signs off?”
• “What triggers a reassessment and how do you ensure it happens?”
• “How did assessment findings change the design or deployment decision?”
• “How do you ensure third-party AI services are assessed in your context of use?”

Hangups that create findings:

• No documented method (only ad hoc documents).
• Assessments performed after launch.
• Misuse not addressed, or treated as purely “security testing.”
• Findings have no owners, deadlines, or closure evidence.

Frequent implementation mistakes (and how to avoid them)

1. Template-only compliance
   Avoid writing generic harms without system-specific details. Force concrete scenarios tied to inputs, users, and deployment channels.

2. Ignoring downstream automation
   If AI outputs feed a rules engine or auto-action, assess the combined system impact, not just the model.

3. No decision record
   Auditors look for accountability. Record who accepted residual risk and why.

4. Treating third-party AI as exempt
   If you configure, integrate, or rely on outputs, you still need an assessment for your use case.

5. Forgetting reassessment triggers
   Write triggers into change management: new model version, new training data, new user group, new geography, or a material incident.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes. Operationally, weak impact assessments increase the likelihood of avoidable harms, customer complaints, and internal control failures, which then become audit issues and governance escalations.

Practical execution plan (30/60/90-day)

You asked for speed, but ISO/IEC 42001 does not require a specific timeline. Use these phases as a pragmatic rollout sequence.

First phase (immediate): Stand up the minimum viable assessment

• Approve a single impact assessment template and procedure.
• Define in-scope AI systems and owners; build an inventory view.
• Make the assessment a release gate for new production deployments.
• Run assessments for the highest-impact in-production systems first.

Second phase (near-term): Make it consistent and auditable

• Add scoring criteria for severity/likelihood and a clear materiality threshold.
• Define standard misuse libraries and red-flag scenarios by use case (customer-facing genAI, decisioning, monitoring).
• Establish a central repository and versioning rules.
• Train reviewers on how to write harm scenarios and mitigations that are testable.

Third phase (ongoing): Close the loop with monitoring and change management

• Connect assessments to incidents, complaints, and performance monitoring.
• Add reassessment triggers to change control workflows.
• Trend recurring harm themes and push them into design standards.
• Periodically sample assessments for quality and completeness (second-line review).

Frequently Asked Questions

Do we need an AI impact assessment for every model experiment?

Scope it to AI systems that are deployed or ready for deployment, plus high-risk pilots. Track experiments in your inventory, and require a full impact assessment when the system will affect real users, real decisions, or production data.

What counts as “reasonably foreseeable misuse”?

Misuse that a practical reviewer can anticipate based on the system’s function, users, and environment (for example, prompt injection attempts, overreliance, or using outputs outside intended scope). Document the misuse cases you considered and why they are plausible.

How is this different from a privacy impact assessment or DPIA?

An AI system impact assessment covers broader harms to individuals and society, not only personal data processing. If you already run DPIAs, reuse shared inputs (data flows, recipients, retention), but keep distinct sections for AI-specific harms and misuse.

We buy an AI tool from a third party. Can we rely on their documentation?

You can reuse third-party documentation as inputs, but you still need an assessment for your specific configuration, data, users, and downstream automation. Your context of use changes impact.

Who should approve the assessment?

The accountable business owner for the AI system should approve residual risk, with compliance/legal/privacy/security providing review and conditions. Document the approval and any “must-fix-before-launch” items.

What evidence is strongest in an audit?

A complete assessment tied to a release record, with clear mitigations that were implemented and tested, plus a sign-off trail. Auditors also respond well to traceability from findings to controls and to post-launch monitoring.