AI impact assessment: one programme for ISO/IEC 42001, ISO/IEC 42005 and the assessments regulators ask for

What is an AI impact assessment?

An AI impact assessment is a structured look at the consequences an AI system could have for the individuals it reaches, for groups of people and for society, set against the benefits it is meant to bring. Its subject is the person who is scored, screened, advised or monitored, not the organisation that runs the system.

In the ISO family the term has a precise home. ISO/IEC 42001:2023 requires an AI system impact assessment process in clause 6.1.4 and its repetition in clause 8.4; that is what a certification body audits. ISO/IEC 42005:2025, published in May 2025 by the joint ISO and IEC subcommittee for artificial intelligence, gives guidance on how to set up and document such assessments. Nobody is certified against it.

This guide covers how the ISO requirement relates to other assessments, how deep each one goes and how to run assessment as a programme. For the step-by-step method and a worked example of one system, read AI system impact assessment, with ISO/IEC 42005; for what the guidance standard itself contains, see the ISO/IEC 42005 page.

Requirement, guidance and regulation: which assessment is which

"Impact assessment" is used loosely, and projects stall when a team assumes one document satisfies every request. The table is a planning map, not legal advice; your legal advisers confirm what each law demands.

One date matters for EU planning. Under the amended timetable of the EU AI Act, the obligations for high-risk systems listed in Annex III, which include Article 27, apply from 2 December 2027. The Act and ISO/IEC 42001 are compared in ISO/IEC 42001 and the EU AI Act: what the certificate does not give.

Deciding how deep each assessment goes

Assessing every chatbot with the rigour of a credit-scoring model exhausts system owners; treating them all lightly misses the system that matters. ISO/IEC 42005 addresses this in its process guidance, which includes establishing thresholds for sensitive uses, restricted uses and impact scales. ISO/IEC 42001 still expects an assessment for each system in scope, but the depth can follow the stakes.

Sterling's recommended approach is a short screening for every system, followed by one of three routes. The tiers below are our recommendation, not wording from either standard.

Test the signals on a few real systems first: if two assessors tier the same system differently, the criteria are too vague.

One evidence base, several assessments

Most of what these assessments need is the same: what the system does and for whom, its data and model, where it operates, who is affected and what could go wrong. ISO/IEC 42005 lists these areas in its guidance on documenting an assessment, and one of its informative annexes addresses aligning the AI system impact assessment with other assessments.

The practical design is one system record, with a short module for each duty that differs:

• For ISO/IEC 42001, the module carries each significant impact into the AI risk assessment, where it is treated alongside the organisation's own risks. Clause 6.1.4 requires that link.
• For the GDPR, the module covers necessity and proportionality of the personal data processing and seeks the data protection officer's advice, as Article 35 requires.
• For the EU AI Act, where Article 27 applies, the module frames impacts in fundamental rights terms and prepares the notification to the authority. The Act states that the fundamental rights assessment complements a data protection impact assessment rather than replacing it.

The system owner maintains the shared record; privacy, legal and the AIMS lead each own their module, and a change to the record triggers a check of each module.

Running assessment as a programme, not a project

ISO/IEC 42005 treats timing, responsibilities, approval and monitoring and review as parts of the process, and recommends assessment across the life cycle from design to monitoring in service. ISO/IEC 42001 makes the same point in audit terms: clause 8.4 requires reassessment at planned intervals and when significant changes are proposed or occur. A programme that works usually has five features.

An inventory that stays current

Procurement and change processes should add new systems before they go live, including features vendors switch on inside existing software. The scope guide covers how the inventory relates to the certificate.

Entry points in the life cycle

Screen at the idea stage, complete the assessment before deployment, and reassess on change.

Assessments for bought systems

Using a vendor's model does not remove the duty to assess its consequences in your setting. Much of the evidence comes from the supplier, so ask for it in the contract, under the Annex A controls for allocating responsibilities and for suppliers.

A portfolio view for management

Top management should see, at each management review, how many systems sit in each tier, which assessments are overdue, which impacts remain open and what was decided about restricted uses. The management review guide sets out the inputs and the record.

Internal audit that tests the programme

Sample systems, compare each assessment with how the system actually runs and check that changes triggered reassessment; see the internal audit guide.

AI impact assessment: questions buyers ask