A.10.4 Customers: requirements and evidence

What A.10.4 Customers asks for in ISO 42001

A.10.4 asks the organization to make sure its responsible approach to developing and using AI systems takes the expectations and needs of its customers into account. If a customer questionnaire or contract asks how AI is governed for their data or outcomes, this control is the one that should let you answer from evidence rather than from memory. The risk it addresses is AI behavior that customers did not expect and cannot oversee: a support assistant that answers outside the approved scope, a scoring feature that changes outcomes without notice, or a model update that alters results a customer has built a process around. A.10.4 sits in the A.10 group with A.10.2 Allocating responsibilities and A.10.3 Suppliers, which together cover AI across organizational boundaries.

This is hard because customer needs are rarely recorded as AI requirements. They surface in sales calls, support tickets, security reviews, renewal negotiations and contract redlines, and each team holds a different piece. A practical first step is to list where customer AI expectations already arrive, then decide which of them become documented requirements, which become contractual commitments, and which are declined with a recorded reason. Ticketing, wiki and knowledge base tools can hold that trail, but the organization decides what counts as a requirement and who signs off on it. The text of the control is not quoted here, and the choice of how to meet it belongs to the organization, not to a consultant or auditor.

Confirm with your own customers and contracts which AI-related commitments are already in place, since an assessor will test whether those commitments match what the AI system actually does. Ask your implementation partner, if you use one, to prepare the intake records and review routine, but keep ownership of the commitments with your legal and product owners. An independent certification body, not the partner, is the party that decides whether the evidence meets the standard. The ISO/IEC 42001:2023 entry on the ISO site is the next read for the full structure of the Annex A controls.

Which customers, contracts and AI systems fall in scope for A.10.4

A.10.4 applies wherever customers shape how the organization develops or uses AI. The decisions below determine which customer groups, AI systems, contract terms and feedback channels the control reaches, and each one should be recorded with its justification in the statement of applicability under clause 6.1.3.

Customer groups that count

Decide whether enterprise buyers, consumers, and internal business units acting as customers are in scope. Internal units that request AI features from a central team are customers in practice, even without an invoice. For each group, record who speaks for it, what expectations it has about AI behavior, and whether those expectations reach the development team. A group left out of the scope statement is also the group most likely to raise an unexpected complaint later.

AI systems customers touch

List every AI system that a customer interacts with directly, receives output from, or relies on for a decision. Internal tools that never reach a customer usually sit under other controls, so the boundary matters. Confirm which systems are provided by the organization, which are supplied by third parties and embedded, and which are customer-configured. Customer-configured systems often need clearer documentation of what the organization is responsible for.

Contract clauses with AI commitments

Review master agreements, order forms, data processing terms, and service descriptions for statements about AI behavior, accuracy, human oversight, data use for model training, or change notices. Any such clause is a commitment that A.10.4 expects the organization to meet, so each one needs an owner and an evidence source. Clauses that promise outcomes the management system cannot verify are a scoping risk worth escalating before signature.

Feedback channels in use

Identify every route through which customer input reaches the organization: support tickets, email, account reviews, user research, bug reports, and contract escalations. Scope the channels that carry AI-related feedback, not only the ones labeled as AI feedback. The control depends on feedback being recorded, triaged, and fed back into design decisions, so a channel that is monitored but never logged is outside what an assessor can test.

Scoping drives the workload

Scoping choices change the amount of work more than any tool choice. Adding a customer segment or an AI feature multiplies the contract reviews, feedback sources, and records an assessor will sample. Narrowing scope too far creates a different risk, because an exclusion must be justified in the statement of applicability and an assessor may challenge it. Ask any implementation partner to price the scope as written, then test it against actual contracts and channels.

How an assessor tests whether customer expectations shape AI practice

This table follows an assessor's path through A.10.4 Customers, from a customer need captured at the start to the design, contract and monitoring records that show it changed AI practice. Read each row as a question the assessor asks and the records that answer it. The main takeaway is that the auditor samples the organization's own records and reports on them, so customer input must leave a traceable trail in systems the organization already runs.

Assessor step	What the assessor samples	Common finding
Trace requirement capture	Requirement log or register entries for AI features, with the customer source, date and owner for each item	Customer needs exist only in sales notes, call summaries or email threads and never reach a controlled record
Check contractual commitments	Customer contracts, order forms and AI-specific clauses on intended use, data handling, human oversight and change notice	AI commitments are promised in proposals but absent from the signed agreement or the service description
Follow feedback to a decision	Feedback tickets with category, triage outcome and the linked design or backlog item	Feedback is logged and closed without a recorded decision, so no link to a design change exists
Review adjudication	Records showing who weighed conflicting customer inputs and why some were accepted or declined	Requests from one large customer override others with no documented rationale or review
Test design change records	Change tickets, design decision records or model release notes that cite the originating customer input	Changes are shipped but the customer origin is not recorded, so the assessor cannot confirm influence
Review post-deployment feedback	Monitoring reports and customer-facing issue reviews showing user input feeding later updates	Post-deployment complaints are handled by support alone and never reach product or AI owners
Confirm ownership and boundaries	Role assignments and the statement that the organization, not a consultant, owns the process and records	Evidence was assembled by an outside party and staff cannot explain or maintain it

How to implement customer requirements capture for AI, step by step

This sequence turns customer expectations about AI into a governed register, traceable design decisions, contract commitments and post-release feedback that an auditor can follow from end to end.

Identify customer groups and their AI expectations
List every customer group that buys, configures, relies on or is affected by your AI features, including enterprise buyers, end users, regulated customers and internal business units that consume AI outputs. For each group, gather expectations from sales notes, security questionnaires, support tickets, procurement reviews and contract redlines, and record who is responsible for each source. The step is done when each group has a named owner and a list of stated expectations that trace back to a documented source. Expect the auditor to ask how you chose these groups and whether the list is reviewed as the product changes.
Record requirements in one register
Consolidate every captured expectation into a single requirements register with a unique identifier, the customer group, the source, the wording as received, your interpretation, the status and the accountable owner. Keep the register in a controlled location with version history so changes to a requirement are visible. Tools such as XWiki keep page versions with who changed what and when, and GLPI or Zammad can hold the request records that feed the register. The step is done when every requirement has an identifier and an owner and the register has an approval record. Ask an auditor to pick a requirement and follow it from source to decision.
Map each requirement to a design or deployment decision
For each requirement in the register, record the design, data, testing or deployment decision that addresses it, or record a documented reason for not addressing it. This is where customer expectations meet the impact assessment and life cycle controls in Annex A, so link each entry to the relevant risk or impact record and to any open residual risk. Review mappings with product, engineering and the people accountable for AI governance. The step is done when each requirement shows a decision, an owner and a verification method. Auditors commonly sample this mapping to test whether customer input changed anything.
Put AI commitments into contracts and product documentation
Translate the requirements you have accepted into contract terms, service descriptions and customer-facing documentation. Legal and product owners should confirm which AI commitments appear in master agreements, order forms, data processing terms, acceptable use terms and user documentation, and which limits, such as intended purpose or excluded uses, are stated plainly. Compare each commitment with the register so no promise exists that the organization cannot evidence. The step is done when every accepted requirement that customers rely on has a matching contract clause or document section, and the template versions are retained. Ask the reader to confirm the wording with counsel, since contract terms are a legal matter outside this control.
Collect and adjudicate feedback after release
Set up channels for customers to report AI behavior, errors, complaints and new expectations, such as support tickets, in-product feedback and account reviews. Route each item into the requirements register, and record an adjudication decision for every item: accepted, rejected with reasons, deferred or referred to an impact assessment. Track changes to design or documentation that result from feedback, and close the loop by informing the customer where appropriate. The step is done when feedback records show intake, adjudication, the outcome and any resulting change. Helpdesk platforms such as Zammad or GLPI's Assistance module can provide this ticket trail, subject to your own configuration and retention settings.

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

Auditors look for a traceable path from what customers asked for to what the organization built, promised and monitored. The cards below cover six records that show that path, each with a review cadence and an owner so the evidence stays accurate between audits. The organization owns these records; an independent auditor decides whether they are sufficient.

Customer requirements register

A register listing each customer expectation or need about AI behavior, with its source (contract, questionnaire, support ticket, account review or regulator letter) and the date it was captured. Each entry should name the product or AI feature it affects. Review the register at least quarterly and when a major customer renews, and assign a product owner to confirm that open entries still reflect what customers have asked for.

Contract templates with AI commitments

Master agreements, order forms and data processing terms that state what the organization commits to on AI use, such as human oversight, data use limits, model change notice and performance boundaries. Check that each commitment matches what engineering actually delivers. Legal should review templates on a fixed cadence and after any change in AI features, with a named contract owner tracking which customers signed which version.

Adjudicated feedback records

For each piece of customer feedback, a record of the decision: accepted, rejected or deferred, the reasoning, and who made the call. Rejections matter as much as acceptances, because they show that feedback was weighed rather than ignored. Adjudicate new items at a set intake meeting, and have the product owner close each record with a rationale the customer can be told about.

Design and change records linking feedback to decisions

Tickets, design documents and change requests that trace an accepted piece of feedback to the specific model, prompt, workflow or configuration change it caused. Versioned wiki pages and ticket histories help here because they show what changed, when and by whom. Sample a set of accepted feedback items each quarter and confirm that each one reaches a completed change or a documented reason it did not.

Post-deployment monitoring summaries with user input

Periodic summaries that combine production metrics with user reports, complaints and error feedback about the AI system. Each summary should state which issues were raised, how many were resolved, and which were passed back into the requirements register. Assign an operations owner to issue the summary monthly for high-impact systems, and record any threshold that triggers an unscheduled review.

Review minutes and action logs

Minutes from governance and product review meetings that show customer expectations were discussed, decisions were taken, and open actions were tracked to closure. Minutes should cite the register entries and feedback records they address. The governance chair should circulate minutes within an agreed period and carry unresolved actions forward until someone closes them, so a reviewer can see the loop operating across cycles.

What meeting A.10.4 costs in money and effort

This table breaks down the cost components of meeting A.10.4 Customers, showing who is paid for each, whether the cost is one-time or recurring, and what moves it up or down. No figures are given because none are supplied, so use the right-hand column to structure requests for quotes and internal budget estimates.

Cost component	Who is paid or who spends time	One-time or recurring, and main cost drivers
Tooling or licenses	Software vendor or internal IT	Recurring if a commercial helpdesk or wiki is licensed. Self-hosted open-source options such as GLPI, Zammad, XWiki or BookStack can remove license spend, but hosting, patching and administration remain. Ask for license terms and the cost of hosting in your own environment.
Engineering and product time to build the register and design links	Internal engineers, product owners, or an implementation partner under a written scope	One-time to build the customer requirements register and trace it to design records, then recurring as products change. Drivers: number of customer groups, number of AI features, and how many design records must be linked.
Legal time to draft AI contract clauses	Internal counsel or outside contract lawyers	One-time for template clauses, recurring for negotiated contracts. Drivers: contract volume, number of customer segments, and how often AI terms are negotiated. Ask counsel to state which clauses are standard and which need case-by-case review.
Support or customer success time to run feedback collection	Support staff, customer success managers, or product researchers	Recurring. Drivers: feedback volume, ticket channels in use, and whether feedback is triaged by hand or routed through a ticket system with defined categories. Ask how feedback is adjudicated before it reaches design.
Evidence upkeep	Compliance lead, product owners and system administrators	Recurring. Drivers: release frequency, number of customer commitments tracked, and how often documentation is reviewed. Version-controlled wikis and ticket histories reduce manual collation, but someone must still keep them current.
External review	Independent reviewer, consultant or implementation partner	Optional and recurring if used. Scope the review in writing: which customer requirements, which contracts and which feedback records. Ask for deliverables, not an opinion on certification.
Auditor sampling	Independent certification body, paid by the organization	Recurring at each audit cycle. Drivers: the number of records the auditor samples, how well evidence is indexed, and how many customer commitments are in scope. Ask the certification body to confirm its sampling approach in writing before engagement.

Which self-hosted open-source tools can hold A.10.4 evidence

A.10.4 is tested by records of what customers asked for, what was agreed and what came back after release. The four tools below can each hold one part of that trail, from ticket intake to page history and access control. None of them decides whether the organization meets the control, so each card names what the reader must confirm before relying on it.

Customer tickets with GLPI

GLPI's Assistance module lets users create, follow and process tickets, problems and changes under ITIL practices, with statistics and a Kanban view. For A.10.4, a ticket can hold a customer's requirement, the response, and any change request raised from it. Confirm that ticket categories separate customer feature requests from incidents, and that closed tickets keep their full history for the period your assessor will sample. Confirm that GLPI is the system of record for customer requests, not a parallel spreadsheet.

Customer communication in Zammad

Zammad brings customer messages from email, chat, telephone and social media into one ticket system. This matters for A.10.4 because customer expectations often arrive through informal channels, and an assessor will ask whether those expectations reached the people who design and release AI features. Check that each channel creates a ticket, that agents tag AI-related requests, and that retention rules for customer correspondence match your contracts and privacy obligations.

Versioned requirement pages in XWiki

XWiki keeps every change to a page under version control, recording what changed, when and by whom, and lets users compare any two versions and roll back. Use it for customer requirement specifications, AI feature commitments and feedback summaries so that the state of a commitment at any past date can be shown. Confirm that approvals are recorded in the page itself or in a linked system, because version history alone does not prove who signed off.

Access control in BookStack

BookStack assigns user abilities through roles, and permissions can be overridden per role at shelf, book, chapter or page level. For A.10.4, this lets a customer-facing commitment book be readable by account managers and editable only by product owners. Confirm that the role design reflects who may accept customer requirements and who may change contractual commitments, and review those assignments on a schedule you can evidence.

Who owns A.10.4 and what an implementation partner can take on

Your organization owns A.10.4. Customer expectations are an input to your responsible AI approach, so the people who understand those customers must decide which requirements are accepted, how they are written into contracts, and how conflicting feedback is resolved. Those decisions cannot be delegated to a tool or a partner, because the organization is accountable to its customers and to its own governance body for them.

Requirements capture: Product, account and security leads decide which customer AI expectations become requirements, and record the source of each one.
Contract clauses: Legal and product owners agree the AI-related commitments made in contracts, such as intended use, human oversight, and notice of material changes.
Adjudication decisions: A named owner decides which feedback is incorporated, deferred or declined, and gives the reason.
AI governance sign-off: The accountable governance function approves the customer-facing commitments before they go live.
Ongoing ownership: Someone internal reviews the register regularly and remains the contact when an auditor asks why a decision was made.

Before relying on any partner work, confirm that each decision in your records has a named internal owner and a date.

Where organizations usually fall short on customer expectations

Customer expectations for AI rarely fail in one place. They drift from sales promises into contracts, from support tickets into engineering backlogs, and from monitoring dashboards into nothing at all. The cards below name the gaps we see most often under A.10.4 Customers and the closing step that closes each one.

Customer needs held only in notes

Requirements a customer states during sales calls or support escalations often live in a CRM note or a single person's inbox. When the product team later builds or changes an AI feature, nobody can show which customer need it was meant to address. Close the gap by recording each stated need as a numbered requirement in a controlled register, with the source, date and owner, and by linking each requirement to the design item that answers it.

AI commitments missing from contracts

Sales material may promise human review, data handling limits or accuracy testing that the master agreement and order forms never mention. A.10.4 expects the organization's responsible approach to reflect what customers actually need, and a commitment that exists only in a slide deck is hard to defend. Close the gap by having legal and the AI governance owner review a standard AI addendum, then compare each commitment against the product's documented controls before signature.

Feedback logged but never adjudicated

Support tickets and survey comments pile up with no decision attached. Assessors look for evidence that feedback was weighed, accepted, deferred or rejected, with reasons. Without that record, the organization cannot show it considered customer input at all. Close the gap by setting a fortnightly triage meeting with a named decision owner, and recording each item's disposition and rationale in the ticket.

No link from feedback to design

Even when feedback is triaged, the accepted items may never reach the backlog, the risk assessment or the test plan. The customer then sees the same complaint in the next release. Close the gap by requiring each accepted item to carry a reference to the change request, the impact assessment update and the verification result that addresses it, so the trail runs from feedback to design decision.

Monitoring that ignores user input

Dashboards track model accuracy, latency and uptime, but not the cases where customers report wrong, unfair or unsafe outputs. Post-deployment monitoring that excludes user input misses the signals most likely to show a gap in expectations. Close the gap by adding a defined channel for user-reported AI issues to the monitoring plan, with thresholds that trigger review and a named reviewer.

Records that hide who decided

When a customer request is accepted, deferred or declined, the file often shows the outcome but not the approver, the date or the reasoning. Auditors and customers both ask who made each call. Close the gap by using an approval workflow with role-based permissions and version history, so every decision on a customer requirement shows who made it, when and why.

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

How much effort does A.10.4 take compared with the other A.10 controls?

A.10.4 is usually lighter on technical build work than A.10.3 Suppliers, but its effort depends on how many customers you serve, how varied their AI expectations are, and how many contracts already make AI commitments. A.10.2 Allocating responsibilities is a one-time mapping exercise, while A.10.3 requires ongoing supplier due diligence and monitoring. A.10.4 sits in between because the work is mostly process: capturing customer requirements, writing down the commitments you make, and running a feedback loop that gets reviewed. The main drivers are the number of distinct customer segments, the volume of inbound questionnaires and feedback, and whether requirements currently live in sales emails rather than a single register. Ask any provider to break the effort down by these drivers in a written scope.

Can a small company meet A.10.4 without outside help?

Yes, a small company can often meet A.10.4 internally, provided one person owns the customer requirements register, the contract templates reflect the AI commitments you actually make, and feedback is reviewed on a set schedule. Outside help is usually most useful for designing the process once, setting up the tooling, and checking that the evidence will hold up at an independent audit. Your organization owns the controls and the commitments. An implementation partner can prepare systems and records, but only an independent certification body issues a certificate. If you go it alone, read the Annex B implementation guidance closely and keep your evidence trail consistent.

What does the customer-facing team need to contribute to A.10.4?

The customer-facing team, including account managers, sales engineers and support staff, is the main source of the evidence A.10.4 expects. They need to log customer AI requirements, questions and complaints in a shared system, flag when a customer asks for something the product cannot yet do, and tell the product and compliance owners when a contract includes AI-specific wording. They also need a clear rule for what must be escalated and to whom. Expect some training time at the start and a recurring task of tagging and closing items. Without this discipline, requirements disappear into individual inboxes, and an assessor will find it hard to show that customer needs shaped the AI system.

How long does A.10.4 take to implement?

No duration is supplied for this control, so treat any timeline you receive as provisional until it is tied to a written scope. The schedule is driven by how mature your current customer feedback process is, how many customer segments and contract templates need review, whether an AI management system already exists to hook into, and how quickly your internal owners can make decisions. Ask the provider to list the assumptions behind the timeline and what would move it. Also confirm whether the timeline covers implementation only or includes the period of collecting operating evidence before an assessment, because an auditor generally needs that record to exist.

Do tools alone satisfy A.10.4, or does the process need to exist first?

Tools alone do not satisfy A.10.4. A helpdesk, wiki or ticketing system only holds evidence; it cannot decide what your responsible approach to AI should consider. The organization must first define how customer expectations are captured, which commitments go into contracts, who reviews feedback, and how the results change the design or use of AI systems. Once that process is defined, tools make it repeatable and auditable. For example, an illustrative setup might route customer AI requests into a ticketing system, record decisions in a version-controlled wiki, and keep contract commitments in a template library. The process decides the outcome; the tooling only proves it happened.

Can the same customer records serve ISO 27001 and customer security questionnaires?

Often yes, but only where the records are scoped and labeled clearly. A single ticket history of customer requests, complaints and decisions can support A.10.4 evidence, while the same system can also show how security questions from customers were answered for ISO/IEC 27001. Customer questionnaires usually ask for the same underlying facts, such as who reviews requests and how commitments are kept. Build one register with fields that map to each framework, and keep a short cross-reference document that your auditors can follow. Avoid copying answers across frameworks without checking them, since each assessor will test the wording of its own control.

How DeployOpen works on this

DeployOpen helps organizations prepare the systems, records and customer-facing evidence that A.10.4 Customers asks for, inside the client's own infrastructure. The organization still owns its AI commitments and customer relationships, and an independent certification body makes any certification decision.

How we scope

Agree in writing which customer groups, contract types and AI features fall within the A.10.4 scope
List the feedback channels, such as support tickets, customer reviews and advisory input, that the scope will include
Confirm with the client which existing contract and questionnaire commitments must be reflected in the evidence
Engagements are fixed-scope, so deliverables and timelines are agreed before work starts

How we build

Configure a helpdesk or ticketing system to capture AI-related customer requirements, complaints and concerns with a clear audit trail
Set up a documented process that routes adjudicated customer feedback to the teams that own AI design and use decisions
Build a versioned knowledge base for customer-facing AI commitments, so changes are traceable to who made them and when
Test that ticket categories, roles and permissions match the responsibilities the organization has assigned

How we hand over

Deliver configuration documentation, process descriptions and sample records that show how customer expectations were captured and acted on
Provide a mapping of each deliverable to the evidence an assessor would ask to see for A.10.4, for the client to review
Train named client staff to run the feedback loop, review tickets and maintain the knowledge base after handover
Confirm with the client and its certification body which records they will accept as evidence before finalizing the package

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope work ends
Retainers can cover updates to the feedback workflow when new customer requirements or AI features are introduced
Ask any implementation partner to state in writing what it will not do, including issuing audit reports or certificates