A.5.4 AI system impact on individuals: requirements and evidence

What A.5.4 asks for and why individual impact is hard to get right

Control A.5.4, Assessing AI system impact on individuals or groups of individuals, asks the organization to assess and document how an AI system could affect people, either one person at a time or as a group sharing a characteristic, and to keep that assessment current across the system's life cycle. A compliance lead facing an assessor needs to show three things: that the assessment covers the affected people, that it addresses fairness, bias and transparency concerns, and that the record reflects how the system is actually used today. The control sits under the impact assessment objective in Annex A, alongside A.5.2 (the assessment process), A.5.3 (documentation) and A.5.5 (societal impacts). Your first decision is to define who counts as affected: applicants, patients, employees, customers, or people who are scored or ranked without ever using the product. Write that list down before you write any analysis.

The control names fairness, bias and transparency because these are where individual harm usually appears. Fairness asks whether outcomes differ across groups that should be treated alike. Bias asks where the training data, features, labels or deployment context push results in one direction. Transparency asks whether the people affected can understand that AI is involved and why a decision was reached. The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, contributed by Microsoft, links the Measure and Map functions of the NIST AI RMF to B.5.4, including fairness and bias evaluation and transparency and accountability risks. Use it as a starting checklist, not as proof of conformance, and confirm its current wording on the NIST AI Resource Center site before citing it. ISO/IEC 42005:2025 gives more detailed guidance on how AI systems may affect individuals, groups and society.

The hard part is timing. Teams often run one impact assessment before launch, file it, and never revisit it, even though the model is retrained, the data source changes, a new customer segment starts using the feature, or a regulator's expectations shift. An assessor will ask whether the assessment was triggered by those changes and whether the individual-level findings were updated. Build explicit review triggers into the A.5.2 process so that a model change, a new use case or a complaint reopens the A.5.4 record. Distinguish this from A.5.5: societal effects such as environmental or public-interest consequences belong in that separate assessment, so keep individual findings tied to identifiable people or defined groups.

Which AI systems, populations and teams fall within A.5.4 scope

A.5.4 work is only as complete as its scope. The decisions below determine which systems get assessed, which people the assessment must consider, who supplies the inputs, and how exclusions are justified in the scoping statement that clause 6.1.3 requires.

AI systems and use cases in scope

Start from an inventory of every AI system the organization develops, provides or uses, then assess each intended use separately. The same model can affect a marketing audience in one workflow and a loan applicant in another, so record each use case with its purpose and decision influence. Check that the inventory includes systems in pilot, shadow or vendor-run use, since those are the ones most often missing from an assessment.

Affected individuals and groups

For each use case, list who the output reaches: customers, applicants, patients, employees, students or members of the public. Include people who are not users but are scored, ranked or described by the system. Note groups that may be treated differently because of protected characteristics, language, disability or access to digital channels, since fairness and bias concerns depend on these groups.

Teams that own assessment inputs

Assign named owners for the inputs the assessment depends on. Product defines intended purpose and user journeys, data teams supply training and input data profiles, legal and privacy staff identify rights-related effects, and HR is needed where systems affect staff. Without written ownership, the assessment often stalls at the point where a decision about affected groups is required.

Third-party and embedded models

Decide whether the organization can assess a model it does not build. Where a supplier provides a model or an AI feature inside a product, request the supplier's documented intended purpose, known limitations and test results, then assess the impact of your deployment context. Record where supplier information is insufficient, because that gap is a finding in its own right and feeds the supplier controls in A.10.

Scoping statement and exclusions

Clause 6.1.3 requires a statement of applicability that lists the necessary Annex A controls and justifies including or excluding each one. For A.5.4, the statement should say which systems are assessed and why any system is excluded, such as a purely internal tool with no effect on people. Ask the auditor early how they expect exclusion reasons to be recorded, because weak justifications are a common source of findings.

Scope changes and re-triggers

Scope is not fixed at the start of the program. A new use case, a changed population, a retrained model or a supplier model update can move a system into or out of scope. Define the triggers that reopen scoping, assign an owner to review the inventory on each change, and keep dated versions of the scoping statement so that an auditor can see how the scope evolved.

How an assessor tests A.5.4 and what they ask to see

This table compares what an assessor does, what they ask the organization to produce and the findings they most often record for A.5.4. Read each row as a test step, then check whether your own impact assessment records can answer the matching evidence request before the assessor arrives.

Test area	Evidence the assessor asks for	Common findings
Sampling of AI systems	The inventory of AI systems in scope, the rule used to decide which systems need an individual impact assessment, and a sample selected from that population	Inventory omits internally built or embedded AI features, so those systems are never sampled
Tracing to intended use and affected groups	For each sampled system, the stated intended purpose, the user populations and the groups of individuals the assessment identifies as affected	Assessment describes the model but not the decision it informs, so affected groups such as applicants or patients are missing
Consideration of fairness and bias	Records showing which groups were examined, the metrics or review methods used, the results and the decisions taken on any disparities found	Fairness is named as a topic but no test results, groups or thresholds are recorded
Consideration of transparency	Evidence that the assessment looked at how affected individuals learn about the system, explanations provided and the channels for questions or objections	Transparency is treated as a documentation task with no link to what users are told in practice
Traceability to system changes	Version history showing when the assessment was last reviewed and the change log for model, data, prompt or deployment updates since then	Assessment predates a model change, a new training dataset or a new user group, and nobody recorded a re-review
Linkage to risk treatment	Risk register entries or treatment actions that come from the individual impact findings, with owners and status	Findings are recorded but no treatment or accepted-risk decision exists for them
Approval and ownership	Named approver, date of approval and the role responsible for keeping the assessment current	Approval is signed by the team that built the system, with no independent review recorded

Implementing A.5.4 step by step, with the output of each step

This sequence turns A.5.4 into a repeatable assessment that identifies who an AI system could affect, tests fairness and transparency, records foreseeable misuse and ends in a signed approval record that the organization can show an auditor.

Identify affected individuals and groups
The AI system owner, with product, legal and domain experts, lists every category of person the system touches: direct users, people who are scored or decided about, bystanders and groups who may be treated differently by the model's outputs. Include people outside the customer relationship when the system's outputs reach them. The output is a stakeholder register with one entry per individual or group, the reason it is affected and the system function that affects it. Confirm the register is complete when a reviewer outside the build team can name at least one group that is not already listed and the team has decided whether to add it.
Define the life-cycle stages to assess
Map the stages where the system could affect people, from data collection and training through validation, deployment, operation, monitoring and retirement. For each stage, record what the system does, who has access and which decisions depend on its output. The output is a life-cycle map that links each stage to the impacts identified in the previous step. The check is that every stage has either an assigned impact question or a documented reason it does not affect people, so the assessment does not skip the stages where problems usually appear.
Evaluate fairness and bias with defined measures
Choose the fairness and bias measures before testing, record why each one fits the use case and state the thresholds that count as acceptable. Run tests on representative data for each group in the register, including subgroups where the outcome matters most, and document the data sources, sample sizes and known gaps. The output is a test record with the measure, the population, the result per group and the decision taken on any gap. The check is that the thresholds and measures were fixed before results were seen, which is the point an assessor will probe.
Assess transparency to users and affected people
Determine what each affected group needs to know about the system: that AI is involved, what it decides or recommends, the main factors that influence outcomes, its known limitations and how to contest a result or request human review. Write these statements in plain language and check them against what the system does in practice. The output is a transparency statement for each audience, with a note on where it is shown. The check is that a person from the affected group, or a delegate who represents them, can explain back what the system does and how to challenge it.
Record foreseeable misuse and adverse effects
Work through how the system could be used beyond its intended purpose, whether by users, operators or people who gain access to outputs, and what harm that could cause to each group. Include misuse that results from model errors, such as false positives, and misuse that results from deliberate attempts to manipulate outputs. Where security or adversarial testing supports this step, record the test scope, the attempts made and the vulnerabilities found. The output is a misuse register entry for each scenario with its likelihood, the affected group, the planned control and the owner. The check is that every entry links to a control or to a documented acceptance decision.
Define triggers for reassessment
Set the events that require the assessment to be repeated or updated, such as a change in model version, training data, intended use, affected population, deployment market, or a serious incident or complaint about an outcome. Also set a scheduled review point defined by the organization, and state who monitors each trigger. The output is a trigger list with the owner and the action each trigger requires. Confirm the triggers are tied to monitoring data that the organization already collects, so a trigger can actually fire.
Assign approval and record the decision
The accountable executive, not the team that built the system, reviews the stakeholder register, test results, transparency statements, misuse register and trigger list. The approver records whether the residual impacts are accepted, which conditions apply and which open actions must close before release. The output is a signed approval record with the version of the system assessed, the date, the named approver and the open actions with owners. The check is that the approval can be traced back to each earlier output, which is the evidence an independent auditor will ask to see when testing A.5.4.

Fairness, bias and transparency evidence that holds up under review

Fairness, bias and transparency concerns only become evidence when the organization converts each one into a testable question before the system goes live and again whenever it changes. Under A.5.4, the impact assessment should name the groups the system could affect, such as applicants, patients, employees or customers in a given segment, and state which comparisons will show whether outcomes differ across them. For each comparison, the record should give the fairness or error metric chosen, the threshold that counts as a concern, the reason that metric suits this use case, and the people who approved both. A metric chosen without a stated reason is the first thing a reviewer will question. Confirm with your legal and domain experts which protected or sensitive attributes apply in your jurisdiction and sector, because the assessment cannot test groups it never defined.

Review is where the evidence either holds or falls apart. Keep the raw test outputs, the data slice used for each comparison, the model or prompt version tested, and the dated sign-off by a named reviewer who can stop a release. Record what happened when a threshold was crossed: the mitigation applied, the residual risk accepted, and who accepted it. Transparency needs the same discipline. Compare every explanation given to affected people, including notices, adverse decision reasons and help-page text, against what the system actually does in production logs. If the notice says a factor is considered and the logs show it is not, the assessment has found a defect, not a wording issue. The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk, a mapping supplied by NIST's AI Resource Center and contributed by Microsoft, links fairness and bias evaluation and transparency and accountability risks to B.5.4. NIST states that posting the crosswalk is not an endorsement, so use it as a reference point for your own mapping rather than as proof of conformity.

Evidence artifacts that satisfy A.5.4 and how to keep them current

An assessor testing A.5.4 looks for a documented, system-specific record of how the AI system could affect people, and proof that the record was acted on. The six artifacts below connect that record to the test results, notices, change history and sign-offs that show the assessment stays accurate after launch.

Individual impact assessment record per system

Each AI system in scope needs its own record of how it could affect individuals or groups across its life cycle, including the intended purpose, foreseeable misuse, decisions it informs and the people it touches. Assessors check that the record names concrete harms, such as a wrongly declined application or a misclassified customer, and links each harm to a mitigation or an accepted residual risk. Confirm that the record is dated, versioned and tied to the system's inventory entry so it cannot drift from the system it describes.

Affected-group register

A register lists the individuals and groups the system affects, the way each group is exposed, and the data attributes used to identify or compare them. Assessors use it to confirm that the fairness testing in the impact assessment covers the groups most likely to be harmed, not only the groups the team found easiest to measure. Review the register whenever the user population, geography or input data changes, and record who approved each change.

Fairness and bias test results with configuration

Test output alone is weak evidence. Keep the metric definitions, dataset version, group definitions, thresholds, model or prompt version and the exact test configuration used for each run, so the result can be reproduced. Assessors look for a stated acceptance threshold and a record of what happened when a group fell below it. Open-source evaluation runs can be stored with their configuration files, and the reader should confirm which metrics their chosen tool produces before relying on them.

Transparency notices and user documentation

Users and affected individuals need notices that explain when AI is involved, what the system does, its known limitations and how to contest an outcome. Keep each published version with its effective date and the impact assessment finding it addresses. Assessors compare the notice against the assessment to confirm that known transparency risks were disclosed. Check that the notice in production matches the approved version, since a stale notice is a common gap.

Reassessment triggers and change log

Define the events that force a new or updated assessment, such as a new model version, a new user group, a new data source, a material performance drop or a complaint pattern. Record each change with the trigger, the reassessment date and the outcome. Connect these triggers to the organization's change management process so that a model release cannot reach production without passing the impact check. Assessors often sample recent changes to test whether the trigger rules are followed in practice.

Approval sign-offs

Each impact assessment and each material update needs a named approver with the authority to accept the residual risk, along with the date and the version approved. Keep the approval separate from the person who built the system so the review is independent. Assessors check that sign-offs cover the current version, not a predecessor, and that any accepted risk has an owner and a review date. Confirm the approval workflow records who signed and what they reviewed.

What meeting A.5.4 costs in money and effort

This table compares the cost components of meeting A.5.4, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to build a quote request, since no figures are supplied for these components and each depends on your own AI systems and environment.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendors for commercial impact assessment or fairness tools, if used	Often recurring (subscription or licence renewal)	Number of AI systems in scope; open-source tools can remove licence spend but still need hosting and staff time
Engineering time for fairness testing	Internal data science and engineering staff, or an implementation partner on a fixed-scope basis	Initial build is one-time; test runs recur with each model change	Number of affected groups tested, model change frequency, and availability of representative evaluation data
Evidence upkeep	Internal owners who record assessment results, transparency notes and approvals	Recurring across the AI system life cycle	Number of AI systems, how often impact assessments are reviewed, and retention rules for records
External review or testing	Independent reviewers, red teams or testing firms, engaged by the organization	Usually periodic or per engagement	Sensitivity of the use case, regulatory exposure, and whether affected groups are tested directly
Auditor sampling	The independent certification body, paid by the organization under its audit agreement	Recurs at each audit cycle	Number of AI systems sampled, quality of records, and whether evidence is traceable from assessment to decision
Remediation of findings	Internal teams, and any partner engaged to change models, data or user information	One-time per finding, but may recur if issues repeat	Severity of bias or transparency gaps found, and how early testing catches them before release

Who owns A.5.4 inside, what a partner prepares, and what the auditor tests

Your organization owns the A.5.4 assessment itself. Your people decide which AI systems are in scope, which individuals or groups could be affected, how serious each potential impact is, and whether the residual impact is acceptable. These are judgments about your products, your customers and your legal exposure, and no outside party can make them on your behalf.

Affected-group judgments: Your product, legal and domain owners identify the groups of individuals a system touches, including those outside your direct customer base.
Fairness and transparency conclusions: Your accountable owner decides what counts as an unacceptable bias or an unclear explanation for each use case.
Approvals and sign-off: Named managers approve the assessment, accept residual impacts and record who made each decision.
Life cycle updates: Your teams decide when a change in data, model, purpose or user population triggers a reassessment.
Ownership of the record: Your organization keeps the assessment current and answers questions about it.

Before accepting any outside help, confirm that your own accountable owner can explain each affected-group judgment and each approved conclusion without referring to a consultant.

Common gaps in individual impact assessments and how to close them

Most A.5.4 findings come from assessments that were written once, scoped loosely and never tied to a named owner. The cards below cover the gaps we see most often, and each ends with the action that closes it. Work through them against your own inventory of AI systems before an assessor does.

Assessed once, never updated

An impact assessment written at launch describes a system that has since changed its model, data, prompts or user population. A.5.4 asks for impacts across the whole life cycle, so a static document no longer reflects the system. Check whether each material change, such as a model swap, new training data or a new deployment context, triggers a reassessment, and whether the assessment carries a review date tied to those triggers.

No defined affected groups

Assessments that say the system affects 'users' or 'customers' cannot show that the people most exposed were considered. Name the individuals and groups affected directly and indirectly, including people who are assessed by the system but never use it. For each group, record the decisions the system influences and the harm that would matter most to that group. Illustrative example: a résumé screening tool affects applicants, hiring managers and applicants' referees differently.

Fairness tested on aggregate data only

A single overall accuracy or error rate can hide large gaps between subgroups. The assessment should state which protected or relevant characteristics were examined, which metrics were used for each, and how small subgroups were handled. Confirm that the test data represents the population in production, and record the thresholds that would trigger investigation or stop deployment. Relying on one headline number is the gap assessors question most often.

Transparency statements that drift from behavior

Public and user-facing descriptions of what the system does often lag behind what it actually does after updates. A disclosure that says a decision is reviewed by a person, when most outputs go through without review, misleads the people it is meant to inform. Compare each transparency statement against logged behavior and configuration at each review, and record who checks the match. Under A.8 the same statements also feed documentation for users.

No named owner or approver

When nobody is accountable for the assessment, it stays in a shared folder and nobody acts on its findings. Assign one owner who maintains the assessment and one approver with authority to accept residual impacts or halt the system. Record both names, their decision rights and the date of each approval. Link this to the roles and responsibilities defined for AI in A.3 so the assessment has an accountable person rather than a team name.

Third-party models assessed as internal

Organizations often assess a vendor's model as though they built and trained it, which misses impacts that depend on training data, updates the vendor pushes and terms that limit what the buyer can test. Request the vendor's documentation about intended use, known limitations and evaluation results, then test the system in your own deployment context. Record which impacts you can verify yourself and which you are accepting on the vendor's evidence. Confirm contractual rights to receive model change notices.

Questions buyers ask about A.5.4 cost, effort and outside help

How much effort does A.5.4 take to assess?

No researched figure exists for the effort, so the answer depends on drivers you can measure in your own environment. Effort rises with the number of AI systems in scope, the number of distinct groups of individuals each system touches, the sensitivity of the data and decisions involved, and the number of life cycle stages you must cover, from design and data preparation through deployment, operation and change. The first assessment carries most of the one-time work: defining the method, identifying affected groups and running the initial fairness, bias and transparency reviews. Reassessment recurs whenever the system, its data, its user population or its purpose changes enough to alter the analysis. Ask any internal lead or partner to break their estimate into these drivers and to state the assumptions behind each one, including how many stakeholder interviews and test cycles are included. Confirm expected timing with the certification body you plan to use, since its audit schedule and evidence expectations shape the work.

Can one team run the A.5.4 assessment in-house?

Often yes, if the team includes the right roles. One team can usually run the assessment when it has the following people, each named and given time for the full life cycle:

Someone who owns the system's purpose and decision logic
A data scientist or engineer who can explain model behavior, training data and evaluation results
A privacy or legal lead who understands the individuals affected and the obligations that apply to them
Someone who can speak for affected people through user research, complaint data or structured consultation

Gaps are the usual failure point. A team that can test for bias but cannot describe who is affected will produce a weak record. Before committing, map each role to a person, check their available time, and decide who signs the result. Many teams bring in outside help for method design and a first pass, then keep the recurring reassessment in-house.

What does a partner do for A.5.4, and what must stay internal?

A partner can prepare the assessment method, templates, test plans and evidence structure, and can run technical checks such as fairness, bias and transparency evaluations where the written scope includes them. DeployOpen, for example, plans and implements self-hosted open-source platforms, runs security testing including AI systems, and prepares systems and evidence for assessments. It does not issue audit reports or certificates. Several decisions must stay with the organization: choosing which groups of individuals are in scope, judging whether a foreseeable impact is acceptable, selecting mitigations, accepting residual risk, approving the record and owning its updates. An independent certification body then tests the result separately. Put this division of tasks into the written scope, naming each deliverable and its owner, so nobody assumes a decision was made by someone else.

How does A.5.4 differ from A.5.5?

A.5.4 covers potential impacts on individuals or groups of individuals, such as unfair treatment of a particular population, decisions people cannot understand or contest, or errors that fall harder on one group. A.5.5 covers societal-level effects, such as environmental, economic or public-interest consequences that reach beyond the people who use the system. Both run across the life cycle and both draw on the same assessment process in A.5.2, but they ask different questions and often need different evidence and stakeholders. For example, in an illustrative case, a system that screens loan applicants may need a fairness analysis by applicant group under A.5.4 and a separate look at wider lending effects under A.5.5. Keep the two assessments distinct in the records so each can be reviewed on its own. ISO/IEC 42005:2025 provides guidance on assessing how AI systems may affect individuals, groups and society, and is a natural next read for the method.

Can one impact assessment cover several AI systems at once?

It can, provided the grouping is justified and no material impact is lost. Systems that share a purpose, a user population, a data source and a decision path may be assessed together, but the record should name each system, state its version, and show that its foreseeable applications were examined individually. Grouping breaks down when systems differ in ways that change who is affected, such as one system giving advice to staff and another making automated decisions about customers. Document the grouping rationale in the process definition from A.5.2 and in the record from A.5.3 so the decision to group is visible to a reviewer. Confirm the approach with your certification body before you build the program on it, because its expectations for the statement of applicability and for sampling determine how much evidence each system needs. Expect to reassess a grouped assessment when any included system changes materially.

What will an auditor ask first about A.5.4?

Auditors usually start with the record. They will ask to see the documented assessment for a specific system and check whether it identifies the groups of individuals affected, the impacts considered, and how fairness, bias and transparency were evaluated. Expect questions such as:

Which individuals or groups were identified, and why these groups?
What testing or evaluation produced the fairness and bias findings?
What information was given to affected people about how the system works?
Who approved the assessment, when, and when was it last updated?
How do the findings feed risk treatment and the AI policy?

Auditors then sample. They pick one or more systems and trace each claim back to evidence. Logs, test outputs and version histories make that trace short. Gather them before the audit starts, and confirm with your certification body which evidence formats it accepts.

What should a quote for A.5.4 outside help include?

A quote should follow from a written scope, not from a generic package. Ask for:

The systems, life cycle stages and affected groups covered
Each deliverable, its format and the person who owns it
Which parts are one-time (method design, the first assessment, initial test runs) and which recur (reassessment after material change, periodic review, retainer support)
Assumptions about stakeholder access, data availability and test environments
Exclusions, including tasks the organization must do itself

Also confirm that independent audit fees are paid to the auditor and are separate from implementation work. DeployOpen works to fixed scopes agreed in writing before work starts and does not publish a price list, so its quote will show these components. Review each quote line by line to see what it includes and what it leaves to your team.

How DeployOpen prepares A.5.4 evidence in your environment

DeployOpen plans, implements and documents the technical side of A.5.4 inside your own infrastructure, so the impact assessment for individuals or groups sits on records your team owns. We prepare systems and evidence; your organization owns the controls and the assessment decisions, and an independent auditor or certification body issues any report or certificate.

How we scope

Engagements are fixed-scope, with the individuals and groups, life cycle stages and AI systems covered agreed in writing before work starts.
The written scope states which fairness, bias and transparency concerns the evidence must address for each in-scope system.
Scope also names who in your organization approves each assessment, so ownership is settled before any tooling is configured.

How we build

We configure self-hosted logging and tracing so model inputs, outputs and metadata needed for impact review are retained in your environment.
We set up test harnesses that run bias and fairness evaluations on defined datasets and store results with version references.
We document the assessment templates, thresholds and review triggers that your team will use across the system's life cycle.

How we hand over

You receive documented assessment records, test reports and configuration notes in formats your assessors can review directly.
Handover includes a short walkthrough so your staff can run the assessment process and update records without us.
We deliver an evidence index mapping each A.5.4 artifact to its location, owner and retention setting, for your statement of applicability.

How we support

Ongoing support, upgrades and continuous testing of AI systems are available as retainers, separate from the initial fixed-scope work.
Retainers can refresh impact assessments when a system changes materially, such as a new model version or a new user population.
Before any external assessment, confirm with your auditor which evidence formats and sampling they expect for A.5.4.