A.5.2 AI system impact assessment process: requirements

What A.5.2 asks for and why the process comes before any single assessment

Annex A control A.5.2 asks the organization to establish a process for assessing the potential consequences that an AI system can have for individuals, groups of individuals and societies throughout its life cycle. If an auditor, a customer questionnaire or an internal launch review asks for proof of AI system impact assessment, the answer is a documented, repeatable process that decides when assessments happen, who runs them, how they are judged and what follows from them, not a single completed form. The requirement sits alongside the management system requirements in clauses 6.1.4 and 8.4 of ISO/IEC 42001, and the organization owns it. An implementation partner or auditor can help build and test the process, but neither can decide on the organization's behalf what counts as an acceptable impact.

The process exists because impacts change as a system moves from design to deployment and into operation. A system that was low risk when it screened a narrow set of applications can become high impact when its use expands, its training data changes or a new population is affected. A process with defined triggers (for example, a new use case, a material model change, a new deployment region or a serious incident) catches those shifts. It also sets thresholds that decide when a full assessment is required, when a lighter review is enough and when no assessment is needed, and it records who signs off each outcome. Without those rules, the assessment becomes a one-off document that is out of date after the first release.

This control is usually hard for three reasons: no single function owns it, the triggers are never written down, and the link to risk treatment is left implicit. Legal, product, data science and security teams each assume another team is responsible. Before drafting anything, confirm who owns the process, which events trigger a reassessment, and how a finding feeds the risk register and the treatment decisions under the organization's AI risk process. Ask any consultant or tool vendor to show how their outputs map to those decisions, and keep the answers in the statement of applicability rationale for A.5.2.

Which AI systems, data, teams and suppliers the process must reach

The A.5.2 process only works if it reaches the right systems, changes, teams and suppliers. Scope is set by a handful of decisions that determine how many assessments run, who must join them and what evidence exists when an assessor asks. Get these decisions written down before tooling or templates are chosen.

Systems and changes that trigger assessment

Define in writing which events start an impact assessment: a new AI system, a material change to a model, a change to training or input data, a new use case, or entry into a new market or user population. Set a materiality test so that routine retraining or a prompt wording tweak does not trigger a full assessment, but a change in who the system affects does. Ask the organization to name the owner who decides whether a change is material, and to record that decision. An assessor will test whether triggers are applied in practice, not only whether they exist on paper.

Product and data science teams

Product owners decide intended purpose and user populations, so they must start the assessment before build decisions lock in. Data science teams know the training data, evaluation results and known failure modes, which feed the consequences being assessed. Both groups need a defined handoff point, typically the design review and the pre-release gate, where the assessment is opened, updated and closed. Confirm that each team has a named contact for the process and that their sign-off is recorded in the assessment record.

Procurement and purchased AI

Many AI systems in use are bought rather than built, including AI features inside SaaS products and APIs from model providers. Procurement should route any purchase that embeds AI into the assessment process, and should require the supplier to provide information on intended purpose, training data sources, known limitations and impacts the supplier has assessed. Where the supplier cannot provide this, the organization still owns the assessment of its own deployment context. Confirm how the process handles a vendor that changes its underlying model without notice.

Legal and affected-person input

Legal and privacy teams identify where an assessment overlaps with data protection impact assessments, sector rules or contractual commitments, so the organization avoids running two unconnected reviews. Define when affected people or their representatives are consulted, and who decides that consultation is not needed. The assessment should state the jurisdictions and regulated contexts in scope, so that a deployment in a new market triggers a review of the local obligations. Ask legal to confirm which findings must be escalated to the accountable executive.

Systems already in production

The process must cover AI systems that were deployed before the process existed. Build an inventory of live systems, rank them by the likely severity of consequences, and schedule assessments for the highest-impact systems first. Without this inventory, an assessor will find systems that were never assessed, and the organization cannot show that the process reaches the whole estate. Confirm who maintains the inventory and how new shadow deployments are detected and brought into scope.

Statement of applicability entry for A.5.2

Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the organization considers necessary and justifies each inclusion or exclusion. If A.5.2 is included, the entry should point to the scope decisions above, the owner of the process and the location of the procedure. Excluding A.5.2 is hard to defend for any organization that builds or deploys AI systems that affect people, so the justification must be specific. Record the decision and its approver, and review it when the scope of AI activity changes. Scope decisions shape the workload far more than any tooling choice.

How to set up the impact assessment process step by step

This sequence turns the A.5.2 requirement into a working process: it defines when an assessment is triggered, how it is carried out, who signs it off, and how its findings reach risk treatment and periodic review. Each step closes with an output you can check.

Define triggers and thresholds
Start by writing down the events that require an impact assessment, such as a new AI system, a material change to its purpose, data or model, a new user group, or a decision that affects people's rights or access to services. Add a threshold that sorts systems into those needing a full assessment and those needing a lighter screening. Compliance, product and the AI system owner should agree on the list, and the AI governance lead approves it. The output is a written trigger and threshold procedure that a team can apply without asking for interpretation, with the list of current in-scope systems attached.
Choose the method and template
Select the assessment method and a template that records the intended purpose and context, the affected individuals and groups, the potential benefits and harms, how likely and how severe each harm could be, and the safeguards planned. ISO/IEC 42005:2025 is the related guidance for AI system impact assessment and recommends assessing across the life cycle from design to post-market monitoring, so use it as the reference for the template's scope. Confirm the approach against your own legal and sector obligations. The output is an approved template and a short method note explaining how scores or ratings are assigned and who may override them.
Assign owners and approvers
Name who prepares each assessment, who reviews the technical content, who assesses effects on people and society, and who approves the result. Separate the person who builds the system from the person who approves its impact conclusions where your size allows it, and record escalation routes for assessments that find serious harm. Link these roles to the AI roles and responsibilities already defined in your management system. The output is a responsibility matrix with named roles, deputies and an escalation path, signed off by senior management.
Run a pilot assessment on one real system
Choose one AI system that is in production or close to it and run the full process end to end, using the trigger, template, owners and approvals as written. Record where the template was unclear, where data was missing, and how long the review took. Ask the owners of the pilot system to confirm that the conclusions match how the system actually behaves. Pilot findings should lead to changes in the template or method before the process is rolled out. The output is a completed pilot assessment and a short list of process changes with their owners.
Link results to risk treatment and the AI risk register
Feed each assessment's findings into your AI risk register and into the risk treatment decisions your management system already requires. Every identified harm should map to a risk entry with an owner, a rating, and a treatment choice such as a control, a design change, a restriction on use or a decision not to deploy. Where a risk is accepted, record who accepted it and why. The output is a traceable record that links each impact finding to a risk entry and a treatment decision, which an assessor can follow from the assessment to the register.
Set review points across the life cycle
Define when each assessment must be revisited: at design, before deployment, after a material change, at a set interval for systems in operation, and before retirement. Record the review points in the system's documentation and in your change management process so that changes trigger a review automatically rather than by memory. Confirm the interval with the system owner and governance lead. The output is a review schedule per in-scope system and a change rule that connects engineering changes to impact reassessment.
Run an internal audit of the process
Before relying on the process, have someone independent of its operators test it against your own procedure. The internal auditor should sample completed assessments, check that triggers were applied, that approvals were made by the named roles, that findings reached the risk register, and that review dates were kept. Record nonconformities and corrective actions, and report results to management review. This internal check is distinct from any external certification audit, which only an accredited certification body can perform. The output is an internal audit report with findings, corrective actions and a management review record.

How an assessor tests the AI system impact assessment process

This table sets out how an assessor typically tests the A.5.2 process, what evidence they ask for, and where organizations most often fall short. Read each row as a test step: the approach describes what the assessor does, the evidence column shows what the organization should be ready to produce, and the findings column flags the gaps that come up most often in practice.

Test area	Test approach and evidence requested	Common findings
Process documented and approved	Assessor reads the written impact assessment procedure and checks who approved it, when, and whether it names the AI systems and life cycle stages it covers. Evidence: approved procedure, version history, approval record.	Procedure exists but is a draft, has no owner, or is not linked to the AI policy or risk process.
Triggers fire for AI systems	Assessor samples the AI system inventory and checks whether each system was assessed when a defined trigger occurred, such as a new use case, a model change or a new data source. Evidence: inventory, trigger definitions, assessment records dated against change tickets.	Triggers defined only at launch, so changes after deployment never prompt a reassessment.
Coverage of individuals, groups and societies	Assessor checks that each assessment considers consequences for individuals, groups of individuals and society, not only technical performance. Evidence: assessment templates and completed assessments showing each category addressed.	Assessments address accuracy and security but skip affected groups, or treat societal effects as out of scope without a stated reason.
Methods and thresholds applied	Assessor compares the methods named in the procedure with those used in sampled assessments and checks that stated thresholds drive escalation. Evidence: method guidance, threshold criteria, records of escalation decisions.	Methods are described in general terms, and thresholds exist on paper but are never applied to a recorded decision.
Results feed risk treatment	Assessor traces identified consequences from sampled assessments into the risk register and treatment plans, then checks that owners accepted residual impacts. Evidence: risk register entries, treatment decisions, sign-off by the accountable owner.	Impacts are recorded but do not appear in the risk register, or accepted risks lack an owner or rationale.
Review when systems change	Assessor checks that the process itself is reviewed on a set cycle and after material changes, and that sampled systems were reassessed after changes. Evidence: review records, change log, reassessment dates.	Procedure has not been reviewed since first issue, or reassessments happen informally with no record kept.

Evidence that shows an AI impact assessment process works

An assessor testing A.5.2 looks for a process that is written down, applied to real systems, and connected to decisions. The six artifacts below show each link in that chain, from the rules that trigger an assessment to the risk treatment that follows it. Keep them in one controlled set so that a reviewer can trace a single AI system from its register entry to its assessment and its treatment.

Approved assessment procedure

The procedure states what triggers an assessment, such as a new AI system, a change in model, data source or intended purpose, a new user population, or a material incident. It also sets the thresholds that decide whether a full assessment or a lighter screening applies, and who signs off each outcome. Keep it under document control with a named owner and approval record. Between audits, tie the triggers to the change management process so that a change ticket cannot close without an impact screening decision. Check that the procedure covers the whole life cycle, from design through post-deployment monitoring.

Assessment template and method

The template fixes the questions every assessment must answer: intended purpose and context, affected individuals and groups, likelihood and magnitude of harm, benefits and costs, and known limitations. The method describes how evidence is gathered, who participates, such as legal, data protection and affected-business owners, and how findings are rated. Version the template and record which version each assessment used. Between audits, review the template when a new risk source appears in incidents or monitoring, and confirm that older assessments still reference the version they were completed under.

Register of AI systems with trigger decisions

The register lists every AI system in scope, its owner, its purpose, its life cycle stage and the trigger decision taken at intake or at each change. A blank decision field is a finding, because it means the trigger rules were not applied. Reconcile the register against the asset inventory and cloud accounts to find systems that were never registered. Between audits, require the trigger decision as a mandatory field in the change workflow and run a periodic reconciliation so that the register reflects what is running.

Completed assessments for sampled systems

An assessor will select a sample of systems and ask for the completed assessment for each. A complete record shows the assessment date, the system version assessed, the participants, the identified consequences for individuals, groups and society, and the decisions taken. Confirm that each assessment was completed before deployment, or before the triggering change went live. Between audits, schedule reassessment when the system changes materially and store completed assessments in the same controlled repository as the procedure so that the sampling exercise is quick to run.

Linked risk treatment records

Impact findings should feed the AI risk treatment process. Each significant consequence needs a documented treatment, such as a design change, a human review step, a restriction on use, an added disclosure, or a documented decision to accept the residual impact with an approver. Link every treatment to the assessment finding it addresses and to the controls it changes in the statement of applicability. Between audits, check that open treatments have owners and due dates, and that closed treatments were verified against the original finding.

Review and change logs

Logs show that the process operates over time. They include the dates of procedure reviews, template revisions, reassessments, management review outcomes and corrective actions raised after incidents or monitoring alerts. A log with only approval entries and no revisions can suggest the process is not used. Between audits, record every reassessment trigger that came from production monitoring, such as a drift alert or a complaint, and show the link to the resulting assessment or the reason no reassessment was needed.

What setting up the A.5.2 impact assessment process costs

This table breaks down the cost components of building and running an A.5.2 impact assessment process, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to structure a written quote request, since no fixed prices or durations are published for this work.

Cost component	One-time or recurring	What drives it	How to keep it down
Internal time to design the process	One-time, then periodic revision	Number of AI system types in scope, existing privacy or risk processes to build on, and how many approval stages the design needs	Reuse the existing risk and privacy assessment templates, and define triggers and thresholds before drafting methods
Subject matter reviewers (legal, privacy, product)	Recurring per assessment	Severity of potential impacts, whether personal data or regulated decisions are involved, and how many reviewers must sign off	Set clear escalation criteria so low-impact systems follow a short review path
Ongoing assessment effort per AI system	Recurring, tied to each system and life cycle change	Number of AI systems, frequency of model or data changes, and how often post-deployment monitoring feeds back into the assessment	Trigger reassessments on material changes instead of on a fixed calendar, and keep intended-purpose records current
Tooling and hosting for self-hosted open-source tools	Recurring hosting and administration, plus one-time setup	Licenses are often free, but hosting, backups, access control, upgrades and the admin hours to run them still apply	Choose tools that fit existing infrastructure and count admin time in the quote rather than assuming zero cost
External review or testing	Periodic, by scope	Whether AI behavior is tested for harms such as misinformation, data leakage or unsafe outputs, and how much of the test is repeated after changes	Scope testing to the systems with the highest potential impact and reuse results where the system has not changed
Auditor sampling and evidence requests	Recurring at each audit cycle	Number of assessments the auditor samples, how complete the records are, and whether decisions are traceable to risk treatment	Keep one consistent assessment record per system with dates, approvers and linked treatment actions

Who owns the impact assessment process and what a partner can take on

The organization owns the impact assessment process in full. Ownership is a governance matter, not a document-writing task, so the people who decide when an assessment is required and what it concludes must be named staff with the authority to stop or change an AI system. An assessor will ask who decides, who signs off and what happens when an assessment finds a serious consequence.

Triggers: Define the events that start an assessment, such as a new AI system, a material change in model, data or purpose, or a new user population. The team decides which triggers apply.
Approvals: Name the approvers for each assessment and the level of seniority required before an AI system is deployed or changed.
Assessment decisions: Record whether potential consequences are acceptable, need treatment, or require the system to be withdrawn. These decisions stay with the organization.
Risk treatment links: Confirm how assessment findings feed the risk treatment process and which owner accepts residual consequences.
Resourcing: Assign people with time and competence to run assessments, since the process fails quietly when nobody is accountable.

Check that every trigger, approver and decision role appears by name or title in your own documented procedure.

Where impact assessment processes usually fall short

Most A.5.2 processes exist on paper but fail when an assessment is actually needed. The gaps below share a root cause: the process has no defined triggers, owners or feedback loop, so it depends on someone remembering to run it. Each card names one gap and the concrete fix an assessor will look for.

No defined triggers

Assessments happen only when someone remembers to start one, so a model retrained on new data or a feature released to a new customer group can go live unassessed. Define the events that require an assessment, such as a new AI system, a material change to model, data or purpose, a new deployment context, or a new affected population. Write them into the procedure and tie them to change management, so that a change request cannot close without an impact assessment decision. Ask to see the trigger list and a sample of changes showing how each was classified.

Accuracy without affected groups

Many assessments test model accuracy and stop there, leaving out how errors fall on different people. A model can score well overall and still produce worse outcomes for a specific age band, language group or region. The process should require the assessor to name the affected individuals and groups, the potential harms to each, and the testing used to compare outcomes across them. Check that the record names populations, not only performance metrics.

Results that never reach the risk register

An impact assessment can identify serious consequences that never appear in the organization's risk register, so the risk owner never accepts or treats them. Each identified impact should map to a risk entry with a likelihood, a severity, an owner and a treatment decision, which is how the assessment feeds risk treatment as the standard expects. Ask for one assessment and trace its findings to the register and to the controls that treat them.

A process written once and never reviewed

The procedure is approved at launch and then left alone while models, data sources and user populations change around it. Schedule periodic review of the process itself and re-assessment of existing systems when the life cycle guidance in ISO/IEC 42005:2025 would call for it, including post-deployment monitoring. Record the review date, the reviewer and any changes to templates or thresholds. Ask when the process last changed and what prompted the change.

No named approver

Without a named approver, an assessment is written and filed without anyone with authority accepting the conclusions or the residual impact. Assign a specific role, with the authority to stop or limit a deployment, to sign off each assessment before the system goes live or changes materially. Record the approver's name, role, date and decision in the assessment record. Ask who can block a release on the basis of an impact finding and whether that person has done so.

No evidence of a pilot run

A process that has never been run end to end on a real system often breaks at the first handoff between engineering, risk and the approver. Run the process once on a representative system before relying on it, and keep the output as evidence: the completed template, the stakeholders consulted, the findings and the decisions taken. Treat the pilot as a test of the process, and record what was changed afterward. Ask for the pilot record and the revisions it caused.

How open-source tooling supports impact assessment evidence

A.5.2 is mostly a documented process, so tooling supports the evidence for that process rather than replacing the judgment behind it. The organization still decides what triggers an assessment, which methods apply, where the thresholds sit and how results feed risk treatment. Tools help by keeping the records, test results and operational traces those decisions depend on. Before you build a tool-based evidence set, decide which outputs an assessor will ask to see for each step of the process: the trigger log, the assessment record, the test results and the production behavior of the system.

*CISO Assistant* (AGPL-3.0-only) can track audits and assessments against frameworks, so the impact assessment process can sit alongside the other obligations the organization already manages. Its framework library is broad, but whether its ISO/IEC 42001 content is available in your version, and how complete it is, must be confirmed in the release you plan to run before you rely on it for A.5.2 mapping. Keep your own record of which Annex A controls are in scope, since the statement of applicability under clause 6.1.3 is the organization's document, not the tool's. *garak* (Apache-2.0) probes language models for issues such as hallucination, data leakage, prompt injection, toxicity and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. Those files can feed the testing evidence behind an assessment of a model's foreseeable harms, provided you record which model version, configuration and probe set produced them.

*Langfuse* (MIT) records traces that capture each operation in a request, including LLM calls, retrieval steps, tool executions and custom logic, with timing, inputs, outputs, token usage and metadata. These traces help show how a system behaved in operation, which the assessment must consider as the system changes over its life cycle. Each of these tools must be hosted, access-controlled and configured inside your own environment. Traces and test logs can contain personal data or sensitive prompts, so decide retention, redaction and who can read them before you turn on collection. Confirm each tool's current release, configuration options and licensing terms directly with its project.

Questions buyers ask about the A.5.2 impact assessment process

How much effort does it take to set up an AI impact assessment process?

The effort depends on how many AI systems you run, how many of them touch people or society, and how much of your current risk work you can reuse. A.5.2 asks for a process, not a single document, so the work usually covers defining triggers, choosing assessment methods, setting thresholds for when a full assessment is needed, and linking results to risk treatment. Each cost component is worth separating: internal time from product, legal and security staff, any external advisory fees, and tooling. Ask any provider for a written scope listing the systems covered, the deliverables and the review cycle before you agree a price. ISO/IEC 42005:2025 offers detailed guidance on impact assessment that can shorten design work, though it is guidance and does not replace your own process.

How long does it take to put the A.5.2 process in place?

No supplied source gives a standard duration for this work, so treat any single number you hear as an estimate that needs checking. The timeline depends on the number of AI systems in scope, whether an impact assessment method already exists for privacy or risk work, and how quickly decision-makers can approve thresholds. Ask any provider, including DeployOpen, for a written timeline tied to a written scope before work starts. A sound timeline names the milestones: process design, pilot assessment on one system, review by legal and product owners, and rollout. Your certification body will not set this timeline for you, but it will expect the process to be running and producing records before it audits the control.

Can we run the A.5.2 impact assessment process in-house?

Yes, the organization owns its controls, so an internal team can design and run the process if it has the skills and time. An internal team usually needs people who understand the AI system's purpose and data, people who can judge fairness, safety and societal effects, and someone accountable for approving the outcome. Outside help is typically used to prepare systems and evidence, challenge the method, or build the process faster, while the organization keeps decision rights. An independent auditor or certification body will never design the process for you, and an implementation partner cannot issue any report or certificate. Confirm internal capacity honestly before choosing a route.

What does the process need from our product and legal teams?

Product teams provide the facts that drive an assessment: intended purpose, users, deployment context, foreseeable misuse and the decisions the system influences. Legal and privacy teams review whether the assessment covers obligations such as personal data processing, and they help decide thresholds that trigger a full assessment. Security and engineering teams supply information on data flows, model changes and monitoring. In practice, the process fails when product teams treat it as a late sign-off step. Agree a named owner for each AI system, a review point before launch, and a trigger for reassessment when the system or its context changes. Where your organization already runs data protection impact assessments under GDPR, you can check whether the two processes can share inputs, while keeping their scope and outputs distinct.

How does A.5.2 differ from A.5.4 and A.5.5?

A.5.2 sets up the process for assessing potential consequences of an AI system for individuals, groups and societies across its life cycle. A.5.4 is the assessment of impacts on individuals or groups, including fairness, bias and transparency concerns. A.5.5 is the assessment of societal impacts, such as environmental, economic or public-interest effects. In short, A.5.2 defines how and when assessments happen, while A.5.4 and A.5.5 are the content those assessments must examine. A.5.3 covers recording and retaining the results. Auditors usually check that the process points clearly to both individual and societal assessments, so do not merge them into one undefined activity.

Does the impact assessment process need to be running before certification?

Yes, in practice a certification body will expect the process to be established and in operation before it assesses the control, because an auditor needs records showing the process was applied. Clause 6.1.3 requires a statement of applicability that lists the Annex A controls you include or exclude, with justification. If you include A.5.2, you should be able to show the process, its triggers and at least some completed assessments. ISO does not certify organizations and does not set a minimum period of operation in the supplied material, so ask your chosen certification body what evidence it expects and over what period. Confirm this with the certification body rather than relying on general assumptions.

What will an auditor sample when testing A.5.2?

Auditors typically test the process design first, then check that it operates. Expect requests for the written impact assessment procedure, the defined triggers and thresholds, the methods used, and the link between assessment results and risk treatment decisions. They will then sample individual AI systems and ask for the completed assessments, evidence that triggers fired when expected, and records of approvals and reassessments after changes. Auditors may also interview product owners to confirm they understand the process. Keep dated versions of the procedure and the approval trail, because gaps in those records are common findings. The sampling method is set by the auditor, so confirm it with your certification body.

Is ISO/IEC 42005 required for the A.5.2 process?

No, ISO/IEC 42005 is not required by the supplied material to meet A.5.2. Annex A controls are reference objectives that you implement and justify through your statement of applicability, and ISO/IEC 42005:2025, published 28 May 2025, is guidance on AI system impact assessment. According to ISO, it recommends assessments throughout the life cycle from design to post-market monitoring, updated as needed. Many organizations use it as a practical reference because it describes assessment methods in more depth than the control itself. If you adopt it, record that choice and how you applied it. Your certification body can confirm whether it expects you to reference it.

How DeployOpen scopes and prepares evidence for A.5.2

DeployOpen helps organizations set up the A.5.2 impact assessment process inside their own infrastructure, so triggers, methods, thresholds and risk treatment links are defined and recorded. DeployOpen prepares the systems, controls and evidence; the organization owns its controls, and only an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which AI systems fall within the A.5.2 process and which life cycle stages it covers.
Define the assessment triggers, such as new AI systems, material model changes and new user populations.
Confirm which self-hosted platforms, data sources and owners are included before any work starts.

How we build

Configure the assessment workflow, templates and risk thresholds in the organization's own environment.
Connect assessment outputs to the risk register so that impact findings feed risk treatment decisions.
Test the workflow with a documented sample assessment to confirm the steps and approvals operate as written.

How we hand over

Deliver the process documentation, configuration records and approval steps the organization's assessors will review.
Provide an evidence map showing where each assessment record, trigger log and approval is stored.
Train named owners to run assessments and update them when AI systems or their context change.

How we support

Fixed-scope engagements are agreed in writing, with deliverables and timelines fixed before work begins.
Ongoing support, upgrades and reassessment of the process are available as a retainer.
Ask any implementation partner to confirm in writing which parts of the A.5.2 process remain with the organization.