AI risk assessment versus AI system impact assessment: the difference between 6.1.2 and 6.1.4

Anyone implementing ISO 42001 encounters two assessment processes that look similar at first glance: the AI risk assessment in clause 6.1.2 and the AI system impact assessment in clause 6.1.4. In practice, we see organizations merging the two into a single document, or skipping the impact assessment because "we already have a risk assessment". Both lead to a nonconformity during a certification audit. The standard treats them as separate processes with their own purpose, their own perspective and their own output. This article explains the difference and shows how to set up both without doing double work.

Two questions, two perspectives

The core difference comes down to the question each process answers. The risk assessment (6.1.2) asks: what risks does the organization and its environment face from the development, provision and use of AI systems, and how large are those risks? The impact assessment (6.1.4) asks: what consequences can this specific AI system have for individuals, groups and society, both under intended use and under reasonably foreseeable misuse?

So the perspective differs. The risk assessment looks broadly at risks within the AIMS scope and weighs likelihood and impact against acceptance criteria. The impact assessment looks outward, per AI system: the applicant screened by a model, the patient triaged by an algorithm, the groups that may be disproportionately affected. Clause 6.1.2 already requires considering risks to individuals and society, but the impact assessment goes deeper and enforces a systematic analysis per system.

What clause 6.1.2 requires

According to the standard, the risk assessment must be a defined, repeatable process. Concretely: documented risk criteria with likelihood and impact scales and risk acceptance thresholds, an approach that produces consistent and comparable results when repeated, and identification of risks around the development, provision and use of AI systems. The impact scales should be broader than financial and reputational alone: ethical, societal and legal dimensions count as well.

In practice, consistency is where this often fails. Different teams assess risks with different yardsticks, so the results are not comparable and prioritization rests on quicksand. A standardized template with a scoring rubric and a calibration session between teams largely solves this. A second common gap: the assessment happens once, at design time, and never again. The standard expects assessments at multiple points in the life cycle, including retraining, new data sources or deployment in a new context. Clause 8.2 repeats this requirement for the operational phase: at planned intervals and upon significant changes.

What clause 6.1.4 requires

The impact assessment is a process for assessing the potential consequences of AI systems for individuals, groups and society. Three elements set it apart from the risk assessment. First, the subject: the focus is not organizational risk but impact on people. Think of discrimination, privacy harm, loss of autonomy, effects on vulnerable groups and broader societal effects. Second, the scope of scenarios: the standard explicitly requires analyzing reasonably foreseeable misuse in addition to intended use. What happens if someone uses the system for a purpose it was not designed for? Third, the follow-through: results must be documented and used in risk treatment, design decisions and the decision whether to put a system into production.

A well-designed assessment is proportionate: the depth grows with the risk level of the system. For an internal tool that summarizes meeting notes, a brief assessment is enough. For a model that pre-selects job applicants, you want a thorough analysis involving legal or ethics expertise.

How the two processes work together

The processes are separate, but not disconnected. The logical order: the impact assessment provides insight, per system, into who can be affected and how severely. Those outcomes feed the risk assessment, where impact on individuals and society is one of the dimensions on which risks are scored. The risk assessment then leads to risk treatment (6.1.3): selecting controls, checking them against Annex A and recording them in the Statement of Applicability and the risk treatment plan.

An example. An organization uses a model for CV pre-selection. The impact assessment identifies that the model may structurally score candidates from certain groups lower due to bias in the training data, and that rejected candidates have no insight into the reason. The risk assessment translates this into scored risks: a discrimination risk with legal and ethical impact, a transparency risk towards candidates and regulators. Risk treatment attaches controls: fairness measurements per group, human review of rejections and information provision to candidates. This is how the whole fits together, and how an auditor can follow the line from impact to risk to control.

Common nonconformities during audits

In audits of these two clauses, we keep seeing the same patterns. There is no separate impact assessment process: the organization considers the technical risk assessment sufficient. The risk criteria only look at organizational impact and leave consequences for individuals and groups out of scope. Foreseeable misuse is not analyzed. Impact assessments are only done for the visibly risky systems, while the standard asks for them for the systems within scope, including internal and seemingly harmless ones. And the results end up in a document folder without influencing design or deployment decisions. That last one may be the most common: the assessment exists, but steers nothing.

Which documents an auditor expects

For 6.1.2: the AI risk assessment methodology and procedure, the risk criteria and acceptance thresholds, completed risk assessments for the systems within scope, templates and scoring rubrics, and records of review and approval. For 6.1.4: the impact assessment procedure, completed assessments per system, templates, records of stakeholder consultation and review, and deployment decisions that demonstrably reference the assessment outcomes. If you can produce both sets and explain how they connect, you are in good shape for a certification audit.

For organizations that also fall under the EU AI Act: the 6.1.4 impact assessment is a good basis for the fundamental rights impact assessment the regulation requires for certain uses of high-risk systems, but the two are not identical. If you want to know where your AI systems fall under the regulation, you can use our self-assessment at /ai-act-check.

Need help setting up your AI risk assessment or impact assessment process? We help organizations with pragmatic ISO 42001 implementations, with templates and working methods that hold up in a certification audit. Contact us for a no-obligation conversation.