A.5.5 Assessing societal impacts of AI systems: requirements

What A.5.5 asks for and why auditors look for it

If an auditor, a customer questionnaire or a plan to deploy AI has put Annex A control A.5.5 in front of you, the core requirement is this: document the potential societal impacts of each AI system across its life cycle. The organization must identify and assess effects that reach beyond the people who use or are affected by the system directly, and it must keep a record of that assessment. Auditors look for it because it is the control that shows whether an organization has thought about an AI system's footprint on the wider world, not only on its users. A.5.5 sits alongside two neighbouring controls that are easy to confuse with it. A.5.2 defines the impact assessment process itself: triggers, methods, thresholds and how results feed risk treatment. A.5.4 covers effects on individuals or groups of individuals, such as fairness, bias and transparency concerns for a defined population. A.5.5 asks a different question: what could this system do to society, such as environmental cost, economic displacement, or effects on public interest and democratic processes. Illustrative example: a model that automates parts of a regional hiring market may pass an individual-level fairness review in A.5.4 while still shifting local employment patterns in ways A.5.5 expects the organization to record.

The control is hard for three reasons. Societal effects are diffuse, so they rarely show up in a single metric or a single user complaint. They are hard to measure, so teams need to choose proxies, such as energy use per inference or volume of automated decisions in a sector, and say why those proxies are adequate. They also often sit outside the remit of the engineering or product team that runs the system, which means legal, sustainability, public policy or economics colleagues must contribute. Before committing to a plan, confirm who owns this assessment, which external sources the organization will use, and how often it will be revisited as the system changes. For supporting context, ISO/IEC 42005:2025 is ISO's guidance on AI system impact assessment and covers impacts on society as well as on individuals and groups, so it is a useful reference for structuring the work. A crosswalk published by NIST's AI Resource Center, contributed by Microsoft and not an endorsement by NIST, maps several AI RMF measurement and governance items to B.5.5, the implementation guidance for this control. Use it to check coverage against existing practices, not as a substitute for your own documented assessment. The standard itself is available from ISO's ISO/IEC 42001 page.

Which AI systems and impact areas fall under A.5.5

A.5.5 covers societal impacts of every AI system that falls inside the certified scope, so the scope decision drives how much work the assessment becomes. The cards below cover which systems, data flows, teams and suppliers belong inside the boundary, and how the statement of applicability records the reasoning behind those choices.

In-house models and training pipelines

Models your teams build, fine-tune or retrain are the clearest case for A.5.5, because your organization controls the design choices that shape societal effects. Include training data sources, evaluation datasets and any model that is released or used outside the company. Check whether experimental models that never reach production are in scope, and record the decision in the scope statement so an assessor can see where the boundary sits.

Third-party AI embedded in products

AI supplied by a vendor and built into your product still produces societal effects under your name, so it usually belongs in scope. Document which vendor model or API each feature depends on, what the vendor has disclosed about its training and limitations, and which impact areas you assessed yourself. Where the vendor refuses to share information, record that gap as a risk to be treated rather than leaving the area unassessed.

Internal decision tools

Tools that staff use to rank applicants, prioritize cases, forecast demand or allocate resources can affect the public or employees even when customers never see them. Identify each internal tool that influences decisions with external consequences, and confirm whether its effects on communities, markets or the environment were considered. Low-visibility tools are a common gap because teams often treat them as productivity aids.

Data flows and affected communities

Map each data flow that feeds an AI system and each group the system's outputs reach, including people who never interact with it directly. Societal impacts often fall on communities, sectors or the environment rather than on named users, so the map should list those affected parties. Confirm which categories you consider relevant, such as environmental, economic or public-interest effects, and state why any category is excluded.

Statement of applicability justifications

Clause 6.1.3 requires a statement of applicability that lists the Annex A controls you need and justifies including or excluding each one. For A.5.5, the justification should name the systems and societal categories that triggered the control, or explain why none apply to a given system. An assessor will test whether the exclusion reasoning matches the actual system inventory, so keep the two documents aligned.

Supplier-provided models and shared responsibility

When a supplier provides the model, you still need to decide which societal impacts you can assess yourself and which you must request from the supplier. Write down the contract terms, documentation and assessment inputs you need, and record what the supplier will not provide. Ask the supplier which impact assessment guidance it follows, and confirm whether it covers the deployment context you chose.

How an assessor tests A.5.5

This table walks through how an independent auditor typically examines A.5.5 on societal impacts, the evidence they ask for, and the findings that most often come up. Read each row as a question the assessor will put to your organization before and during the audit.

Test step	What the assessor checks	Where it usually goes wrong
Document review	Whether a societal impact assessment process exists, names the societal areas considered (such as environmental, economic or public-interest effects) and links to the A.5.2 process	The procedure covers only privacy or fairness and never mentions society, environment or the public interest
Sampling of assessments	A selection of AI systems, checked for a completed societal impact assessment with a date, scope, reviewer and recorded conclusions	Assessments exist for a few flagship systems, while smaller or third-party-supplied systems have none
Life cycle coverage	Evidence that societal impacts were considered at design, deployment, operation and retirement, not only once at launch	A single pre-launch document with no revisit at later stages
Interviews with system owners	Whether owners can explain the societal effects they identified, how they were judged and who was consulted	Owners describe the system's purpose but cannot name any societal effect or say where it was recorded
Change tracking	Whether the assessment was revisited after material changes such as a new model version, new data source, expanded user base or new use case	Assessments never get updated after model changes, so the record describes a system that no longer exists
Link to risk treatment	Whether identified societal impacts fed into risk decisions, mitigations, owner sign-off or a documented decision to accept the residual impact	Impacts are listed but no treatment, owner or acceptance decision is recorded
Stakeholder input	Evidence that relevant external or internal stakeholders were considered, with the method and any limits stated	No record of who was considered or why, so the assessment reads as an internal view only

Implementing societal impact assessment step by step

This sequence turns A.5.5 into a repeatable routine: the organization decides which societal effects matter for each AI system, agrees how they will be judged, assesses them at defined life cycle stages, records the results and mitigations, and keeps named owners accountable for reviewing them over time.

Identify relevant societal impact categories
Start by agreeing a category list that fits the organization's AI portfolio, such as environmental footprint, economic effects on workers or markets, public-interest concerns, and effects on democratic processes or access to essential services. Governance, product and legal staff usually draw up the list, with input from the teams that build or operate each system. The output is a category list with a short definition for each category and a note on which systems it applies to. The step is done when the list has been approved by the accountable owner and linked to the AI policy and objectives set under A.2.
Define the assessment method and criteria
Next, write down how each category will be assessed: the questions asked, the information needed, the qualitative or quantitative scales used, and the threshold at which a potential impact must be escalated for treatment. ISO/IEC 42005:2025 offers ISO's guidance on AI system impact assessment, including societal impacts, and is a useful reference when drafting the method. The output is a method note that a reviewer can apply consistently, with its assumptions and limits stated. The step is done when a second reviewer can follow the note and reach the same escalation decision on a sample case.
Set the life cycle stages for assessment
Decide when each AI system is assessed, mapping the trigger points to the life cycle stages used in the organization's AI management processes, such as design, data acquisition, deployment, significant change, and retirement. Societal effects can change as a system is scaled, retrained or put to new uses, so the schedule should include those triggers as well as a periodic review. The output is a stage schedule for each system or system group, recorded alongside the method note. The step is done when every in-scope system has at least one defined assessment point and a named trigger for re-assessment.
Assess each system at its defined stages
The system owner, supported by the people who understand the model, data and deployment context, works through the method for each category at each scheduled point. Evidence can include model cards, data sources, energy and compute records where environmental effects are assessed, operational metrics, and input from affected stakeholders where the method calls for it. The output is a completed assessment for that stage, with the evidence referenced. The step is done when every category has a documented conclusion, including a documented finding of no material impact where that is the result.
Document results and mitigations
Record each assessment in a consistent format: the system and stage, the categories considered, the findings, the severity and likelihood as defined by the method, the mitigations chosen, and any residual impact the organization has accepted. Mitigations should be linked to the risk treatment process and to the controls the organization has selected in its statement of applicability. The output is an assessment record that a later reviewer or auditor can follow without the original author. The step is done when each finding has either a mitigation with an owner or an accepted-risk decision with an approver.
Assign owners and approval authority
Name an accountable owner for each system's societal impact assessment and an approver for accepted residual impacts, separate from the people who built the system where the organization's structure allows. Clarify who maintains the category list and method note, and who decides when escalation to senior management or an external review is needed. The output is a responsibility record that appears in the assessment records and in the organization's AI roles and responsibilities. The step is done when every assessment record shows an owner and approver who hold the authority to act on it.
Set review triggers and keep a review log
Define the events that reopen an assessment, such as a material change in the model or its use, a new deployment market, a complaint or reported incident, or a change in applicable law. Each review should be logged with its date, reason, reviewer, outcome and any changes to the record, so the history of decisions is visible. The output is a review log and a list of trigger conditions that the organization checks at each management review. The step is done when the log shows that triggers have been applied in practice and that the method and category list are revisited when the organization's AI use changes.

Evidence that satisfies A.5.5 and how to keep it current

An assessor testing A.5.5 looks for a record of each societal impact assessment, the method behind it, sign-off by someone accountable, and proof that the assessment was revisited as the system changed. The cards below cover those artifacts and the triggers that keep them current between audits.

Societal impact assessment record per system

Keep one assessment record for each AI system in scope, covering environmental, economic and public-interest effects across its life cycle. The record should name the system, its version, its intended purpose and the stages assessed, such as design, deployment and retirement. Check that each identified societal impact has a stated likelihood, severity and affected party, and that the record can be traced to the system's inventory entry. Reference ISO/IEC 42005:2025 as the impact assessment guidance the record should align with.

Method and category definitions

Document the method used to identify and rate societal impacts, including the impact categories, the scoring scale and the criteria that separate a minor effect from one that requires treatment. Assessors compare results across systems, so the same categories and scale must apply to every assessment. Record who defined the method, when it was last reviewed and how it links to the individual-level assessment in A.5.4 so that overlapping findings are not lost.

Approval and sign-off

Each assessment needs a named approver with authority over the AI system, typically a business owner with input from the AI governance function. The sign-off should state the date, the version assessed and any conditions attached to deployment. Check that the approver is not the only person who prepared the assessment, and that unresolved societal impacts are escalated to a documented decision rather than left open. Confirm the approval roles against the organization's A.3 responsibilities.

Mitigation tracking

Every societal impact that the assessment marks for treatment should appear in a tracker with an owner, a planned action, a status and a closure date. Mitigations might include restricting a use case, adding human review, publishing transparency information or changing the training data. Assessors check whether the tracker matches the assessment and whether accepted residual impacts carry a documented acceptance by the right authority.

Review records after material changes

Keep dated review records showing that the assessment was revisited after a material change, such as a new model version, a retrained model, a new data source or a new deployment region or customer segment. Each review should state whether the earlier conclusions still hold and what was updated. Without these records, an assessment that was accurate at launch can no longer describe the system in operation, which is a common gap in audit findings.

Change triggers tied to model updates

Define in writing which events reopen the societal impact assessment: a model or prompt change, a retraining run, a new use case, expansion to a new market or a shift in the population affected. Connect these triggers to the change management process and the deployment pipeline so a release cannot pass without a check against the trigger list. Test the process by sampling recent releases and confirming that each one either triggered a review or recorded why it did not.

What meeting A.5.5 costs in money and effort

This table breaks down the cost components of documenting societal impact assessments under A.5.5, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. No prices or durations are stated because none are supplied; use the table to build a question list for internal budgeting and for written quotes.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it
Internal engineering and governance time	Staff in AI, product and governance roles who define assessment scope and record results	Both: setup is one-time, upkeep is recurring	Number of AI systems in scope and how often each one changes
Subject-matter input from policy or legal staff	Legal, sustainability, HR or policy staff who judge economic, environmental or public-interest effects	Mostly recurring at each assessment cycle	Breadth of societal areas the organization chooses to consider and the review depth expected
External review of assessment methods	Outside specialists or consultants, if the organization buys independent review	Usually one-time, repeated at major changes	Whether reviewers are needed for high-impact systems and how many stakeholder groups are consulted
Tooling and evidence storage	Open-source tools are free to license, but hosting, storage and staff time to run them are not	Setup one-time, hosting and maintenance recurring	Infrastructure location, retention period for records and logging volume from AI systems
Auditor sampling and fieldwork	The certification body or auditor charges for the audit, not for the organization's own controls	Recurring at each audit cycle	Number of AI systems sampled, number of life cycle stages in evidence and audit scope
Life cycle coverage	Every team that changes an AI system repeats part of the assessment	Recurring	Number of life cycle stages covered and how often models, data or use cases change
Licence spend for self-hosted open source	Self-hosted open-source platforms generally avoid per-seat licence fees for the core tool	Recurring avoided, though support contracts may apply	Whether the organization chooses a commercial support plan or keeps support in-house

Who owns A.5.5 inside and outside the organization

Your organization owns A.5.5. The people who decide which societal effects matter for a given AI system, how those effects are weighed, and whether the system should proceed are employees or accountable managers, not a consultant. Those decisions must be recorded with the names of the people who made them, the date and the basis for the conclusion. The assessment is only as good as the judgment behind it, so the team should include people who understand the system's purpose, its data and its operating context, plus someone with authority to stop or change a deployment.

Scope decisions: Confirm which AI systems fall under the societal assessment and which life cycle stages it covers, from design through retirement.
Impact judgments: Decide which environmental, economic or public-interest effects are material, and document the reasoning behind each conclusion.
Sign-off: Name the accountable approver for each assessment and record the approval before the system is deployed or materially changed.
Review triggers: Set the events that reopen the assessment, such as a new use case, a retraining cycle or a change in the affected population.
Record keeping: Hold the final assessment and its supporting evidence under your own document control.

Check that every assessment names a human approver with authority to act on its findings.

Where organizations fall short on societal impact assessment

Most gaps under A.5.5 come from treating societal impact as a document rather than a living part of the AI management system. The cards below cover the four failure points auditors most often find, and for each one, what closes it. Each fix points to evidence that an assessor can trace from the assessment to the decisions it informed.

Treating impact as a one-off document

A societal impact assessment completed once before launch and filed away does not show that the organization assesses impacts across the life cycle, which is what A.5.5 asks for. Auditors look for a dated record for each assessed AI system, with version history showing reassessment as the system changed. To close this gap, assign an owner for each AI system and schedule reviews tied to the life cycle stages in your own process, then keep every version in your document control system.

Omitting environmental effects

Many assessments cover fairness and privacy but say nothing about energy use, water, hardware lifecycle or emissions from training and inference. Because A.5.5 covers public-interest effects, an assessment without an environmental section is hard to defend. Ask the engineering team for compute and energy estimates for training and serving, and record where those estimates came from and how often they are refreshed.

Ignoring economic and labor effects

Automation of tasks, changes to pricing or access, and concentration of a market around one provider can shift economic outcomes for communities and workers. These effects rarely appear in technical reviews, so the assessment often misses them. Include a short section on who benefits, who bears costs, and which groups depend on the system's outputs, and name the business owner who answers for that section.

No link to risk treatment

An assessment that identifies societal harms but does not connect to the AI risk register leaves those harms unmanaged. Auditors trace findings to a treatment decision, an accepted residual risk with an approver, or a documented reason for no action. For each finding, record the risk entry it feeds, the control or mitigation chosen, and who accepted any remaining risk. The method for this link should match the risk process your organization uses under ISO/IEC 23894 guidance.

No update trigger after model changes

Retraining, a new model version, a new data source, a new use case or a change in deployment population can make an earlier societal assessment inaccurate. Without defined triggers, the assessment describes a system that no longer exists. Write the triggers into change management, such as a model version change, a new market or a new user group, so that a change request cannot close without a check of whether the societal assessment still holds.

Questions buyers ask about A.5.5

How much does it cost to assess societal impacts under A.5.5?

Cost depends on how many AI systems fall in scope, how many societal impact areas the organization must examine, and how much evidence already exists. No public figure applies to every organization, so treat any number you see with caution. The cost has three parts: internal staff time from risk, legal, product and sustainability functions; external help, if you buy it; and the independent audit that follows, which is paid to the certification body. Most of the spend is one-time for the first assessment, then recurs when systems change or the assessment is reviewed. Ask any provider for a written scope listing the systems, impact areas and deliverables, since that scope drives the quote.

How long does it take to implement A.5.5 in an AI management system?

The duration depends on the number of AI systems, whether a societal impact process already exists, and how quickly stakeholders can be consulted. Work usually starts with defining the process and criteria, then assessing each in-scope system across its life cycle, then documenting results and tying them to risk treatment. Organizations that already run an impact assessment process under ISO/IEC 42005:2025 for other purposes typically have a head start. Confirm timelines in writing with any partner, and check which phases depend on your own review and approval cycles.

What does A.5.5 require from our internal team?

The internal team must own the assessment itself. Someone accountable must decide which societal effects matter for each system, such as environmental footprint, economic displacement or effects on public interest, and must accept the residual impacts. Product owners need to describe intended use and foreseeable misuse, and engineering must supply the technical facts behind each claim. Expect sustainability, legal and communications staff to contribute to the review. External partners can draft materials, but they cannot make these judgments for you.

Can we run the A.5.5 societal impact assessment in-house?

Yes, an organization can run A.5.5 in-house if it has people with the right mix of skills and enough independence from the teams building the system. The organization owns its controls, so no outside party is required to perform the assessment. Many teams choose to do the first assessment with help, then take over updates. The honest test is whether your staff can document methods, sources and decisions in a way an independent auditor can follow. Ask any partner to show how their work would transfer to your team before you sign.

How does A.5.5 differ from A.5.4?

A.5.4 covers how an AI system could affect individuals or groups of individuals, including fairness, bias and transparency. A.5.5 looks beyond those people to society as a whole, asking about environmental, economic and public-interest effects across the system's life cycle. The two controls are separate, so each needs its own documented assessment, even though they draw on the same system description. ISO/IEC 42005:2025 covers impacts on society as well as on individuals and groups, so it is a useful reference for both.

Can a consultant or partner certify our A.5.5 results?

No. Certification of an AI management system is issued only by an accredited certification body, and ISO does not certify organizations. A consultant or implementation partner can prepare the process, the documentation and the evidence, and can help you check readiness. However, the partner cannot issue a certificate or an assessment report, and independence matters: the party preparing your evidence should not be the party auditing it. Ask any provider to confirm this boundary in the statement of work.

What evidence should we keep to show A.5.5 is working?

Auditors look for a defined method, a documented assessment per in-scope system, records of who reviewed it and when, and proof that results feed into risk treatment and later decisions. Useful evidence includes assessment records, change logs, stakeholder input notes and tooling outputs such as model evaluation reports. Test the process by checking whether a reviewer can trace one societal impact from the assessment to a control decision. Confirm the exact evidence expectations with your certification body before you start.

How DeployOpen prepares A.5.5 evidence

DeployOpen helps organizations prepare the systems, records and evidence that show how societal impacts of an AI system are assessed and documented across its life cycle. The organization owns its impact assessment and its conclusions, and an independent auditor or certification body issues any report or certificate.

How we scope

Agree in writing which AI systems and life cycle stages fall within the A.5.5 assessment scope before work starts.
Confirm which societal impact categories the organization must consider, such as environmental, economic or public-interest effects.
Identify the internal owners who approve the assessment and the records that will show their review.

How we build

Set up a documented method for recording potential societal impacts and linking them to the wider AI impact assessment process.
Configure logging and monitoring tooling so that operational data can feed reviews of societal effects over time.
Map the assessment steps to ISO/IEC 42005:2025 guidance and test that the records are complete and traceable.

How we hand over

Deliver the written assessment procedure, templates, completed records and the evidence index for the auditor to review.
Document each tool configuration, data source and review decision so the organization can explain its assessment without us.
Walk the internal owners through the records and agree a review schedule they will run after handover.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing of the platforms are available as a retainer.
Ask any quote to state which parts of the assessment remain with the organization and which parts DeployOpen prepares.