A.10.3 Suppliers: requirements and evidence

What ISO 42001 A.10.3 asks of AI suppliers

If your organization buys AI models, datasets, APIs or AI platforms, control A.10.3 asks you to run a defined supplier process that confirms those purchases fit your approach to responsible AI development and use. It is a process you own, not a one-time vendor questionnaire. It sits apart from A.10.2, which splits life cycle responsibilities between your organization and its partners, and from A.10.4, which deals with customer expectations. A.10.3 is about what comes into your environment from outside and how you keep checking it. An AI component from a supplier can carry bias, data protection, security or licensing risk that your own teams never reviewed. A pretrained model may have been trained on data you cannot trace, a third-party API may log prompts you assumed stayed private, and an open model may carry a license that forbids your intended use. Each of these risks lands on your organization, whether or not the supplier disclosed it.

The control is hard to satisfy for two reasons. First, suppliers rarely share the documentation you need. Model cards, training data summaries, evaluation results and incident histories are often incomplete, marketed rather than factual, or withheld as proprietary. Your process should define the minimum information you require before a purchase, and treat a refusal to provide it as a finding that needs a decision. Second, the process cannot stop at signature. Model versions change, suppliers update terms, subprocessors shift and vulnerabilities appear after go-live. Plan contract terms that require notice of material changes, audit or evidence rights, and exit conditions, and then assign an owner to review each supplier on a set cadence. Confirm with your legal and procurement teams which clauses your standard terms already cover, and confirm with each supplier what it will actually provide.

Which AI suppliers fall under ISO 42001 A.10.3

Whether a supplier falls under A.10.3 depends on what it provides, which AI system it touches and which business units rely on it. The decisions below change the work the most, and each one should be recorded in the statement of applicability required by clause 6.1.3, which must justify including or excluding this control.

Foundation model API providers

Hosted model APIs are often the largest supplier category, and they are usually in scope whenever a product or internal workflow sends data to them or depends on their outputs. Check which model versions and endpoints are called, whether the provider retains prompts or outputs, and whether it changes models without notice. Each provider used by a system in the AIMS should have a documented due diligence record and a contract that describes model change notice and data handling. Scope is simpler when calls go through one gateway that is already inventoried.

Fine-tuning and model hosting vendors

A vendor that fine-tunes, hosts or serves a model you own brings in both model artifacts and runtime infrastructure, so its scope extends beyond a simple API. Record who holds the weights, where training runs, how model versions are promoted, and who can access logs. Because this supplier sits close to the system's operation, its monitoring obligations are usually heavier than those of a pure API provider. Confirm the split of responsibilities in the contract before work starts.

Dataset and data labeling vendors

Third-party training, evaluation and labeling data enters the AI system through a different path than code or models, so it is easy to leave out of scope. Treat any vendor that supplies or annotates data used by an in-scope system as a supplier in scope for A.10.3, and check provenance, licensing and personal data handling. Link each dataset supplier to the systems that consume its data, so that removing a dataset also shows which systems are affected.

MLOps, AI platform and cloud AI services

Platforms that run pipelines, registries, vector stores or managed AI services can be shared by many teams, which makes scope decisions harder. A platform is in scope when it stores, processes or deploys components of an AIMS system, even if the business unit that buys it sits outside the AIMS. Record which platform features are used, since a service used only for unrelated analytics may be excluded with a documented justification. Open-source components inside a managed platform should be traced too.

Touching an AIMS system as the scope test

The most useful test is whether a supplier touches a system inside the AI management system. A supplier that supplies, processes or influences an in-scope system is in scope, and a supplier with no such connection can be excluded with a recorded reason. Review the test whenever a new system enters the AIMS or a supplier starts a new service. Inventories that tie each supplier to system identifiers make this test repeatable at audit time.

Business units that depend on suppliers

Scope also follows dependencies inside the organization. A business unit that uses a supplier-provided AI feature in a decision process brings that supplier into scope even when IT did not procure it, and shadow purchases are a common gap. Ask each business unit to list the AI tools it uses and the outputs it relies on, then compare that list with procurement records. Document the outcome in the statement of applicability, including any exclusion and its justification.

How an assessor tests the supplier process

This table compares what an assessor typically reviews for A.10.3 Suppliers, what evidence they request, and where supplier processes most often fall short. Read each row as a question the assessor will ask, then check whether your records answer it before the audit starts.

Test area	What the assessor does	Evidence requested	Common findings
Documented supplier process	Reads the procedure that governs how AI-related suppliers are selected, assessed and monitored, and checks it against the organization's AI policy.	Approved supplier process, its owner, revision history, and the link to the responsible AI approach.	Process exists but covers only traditional IT vendors, not model, dataset or AI platform providers.
Sampling of AI suppliers	Selects suppliers from the AI inventory and traces each one through onboarding, use and review. Confirm the sampling approach with the certification body.	AI inventory listing each supplier, the AI systems that depend on it, and its current status.	Inventory omits suppliers of embedded models, open-weight models or third-party APIs.
Due diligence records	Checks that the assessment before onboarding covered responsible AI concerns such as data handling, transparency, safety and intended use.	Completed questionnaires, assessment outcomes, risk ratings and the named approver for each supplier.	Records are generic security questionnaires with no AI-specific questions or no documented decision.
Contract terms	Reviews whether agreements address the AI-specific commitments the organization relies on, such as data use, change notice and incident communication.	Signed contracts or order terms, the clauses relied on, and any negotiated exceptions.	Contracts are silent on model changes, training use of organization data or audit rights.
Ongoing monitoring	Looks for evidence that supplier performance and AI-related risks are reviewed after onboarding, not only at signing.	Periodic review records, performance or incident reports from suppliers, and actions taken on findings.	Reviews are scheduled but not performed, or reviews do not reflect changes in the supplier's models.
Link to statement of applicability	Confirms that A.10.3 is included or excluded in the statement of applicability with a justification that matches what the organization does.	Statement of applicability entry for A.10.3 and the justification text.	Control is marked applicable with no supporting records, or excluded without a sound reason.
Link to AI risk assessment	Checks that supplier-related risks appear in the risk assessment and that treatment decisions reference those risks.	Risk register entries for third-party AI components and the treatment plan for each.	Supplier risks are listed in the risk register but no owner or treatment is recorded.

Steps to build a supplier process that passes A.10.3

This sequence takes an organization from an unknown set of AI suppliers to a documented, monitored supplier process that an assessor can trace from policy to contract to review record. Each step ends with an artifact the organization can show during a certification audit.

Inventory every AI-related supplier
Start by listing every external party that provides something the organization uses in its AI systems: foundation or fine-tuned models, training and evaluation datasets, labeling services, AI platforms and APIs, hosting providers, and component libraries. For each entry, record what is supplied, which internal AI system depends on it, the data it touches, and the named internal owner. Include suppliers that the organization pays indirectly through a product or cloud marketplace. The step is complete when the register is reviewed by the owners of the AI systems and a gap check against procurement records and accounts payable finds no unlisted supplier. The output is a supplier register that an assessor can compare against the organization's AI system inventory.
Define due diligence criteria from the AI policy
Translate the organization's AI policy and its AI risk and impact assessment results into a written due diligence checklist. Criteria typically cover how the supplier develops and documents its AI, its approach to data provenance and quality, its security practices, its handling of personal data, its vulnerability and incident processes, and whether its use terms fit the intended purpose of the system. Set a tier for each supplier based on the risk the assessment identified, so high-impact suppliers receive deeper review. The step is complete when the criteria are approved by the accountable owner for AI governance. The output is the approved checklist, the risk tier for each supplier, and the completed questionnaire or evidence for each.
Run supplier due diligence and record the decision
Assess each supplier against the checklist using the evidence the supplier provides, such as model cards, data sheets, security reports, certifications it holds, and its published terms. Where evidence is missing or unclear, record the gap and either obtain it or document the risk acceptance by an authorized person. Confirm which party is responsible for each life cycle activity so the split can later be recorded under A.10.2. The step is complete when each supplier has a signed or approved decision to onboard, onboard with conditions, or reject. The output is the decision record with the evidence reviewed, the approver and the date. Confirm with each supplier which certifications it holds and their scope, because an assessor will ask whether the claimed evidence matches the service used.
Agree contract terms that carry the requirements
Turn the due diligence findings into contract terms. Standard clauses to consider cover technical and model documentation, advance notice of material changes to models, data sources, or hosting location, data handling and retention limits, incident notification and cooperation, the right to audit or receive independent assurance reports, and the supplier's obligations for vulnerability disclosure. Legal and the AI governance owner should review the terms against the conditions set in the decision record. The step is complete when the signed contract or order form contains the agreed terms, or the exceptions are recorded with a risk acceptance. The output is the executed contract, a clause map linking each requirement to its section, and any exception record. Ask counsel to confirm the terms against the organization's own legal obligations, since this page does not provide legal advice.
Onboard suppliers into a monitoring plan
Before the supplier is used in production, set up the monitoring activities that match its risk tier. Activities can include tracking component versions and known vulnerabilities through a software bill of materials, reviewing model or service release notes for changes, running acceptance tests on the supplier's output, and checking that the supplier's incident and change notices reach the named owner. Assign a review date for each supplier and a trigger list, such as a model version change, a security incident at the supplier, or a change in data location. The step is complete when the monitoring plan is approved and the supplier is connected to the owner's review calendar. The output is the monitoring plan per supplier and the first baseline record, such as the software inventory or test results at onboarding.
Monitor suppliers and record each review
Carry out the monitoring plan at the set intervals and whenever a trigger occurs. Reviews should compare the supplier's current evidence with the baseline, check open vulnerabilities and license changes in the supplier's components, re-run acceptance or AI security tests where the model or its inputs changed, and confirm the contract terms are still being met, including notification of changes. Record each review with the findings, the actions and the person who closed each action. Where a supplier no longer meets the criteria, start the exit or replacement process and record the decision. The step is complete when every review has a dated record with an owner. The output is the review log that shows the supplier process operating over time, which is the evidence most assessors ask to see first.
Feed supplier findings into management review and risk
Bring the supplier results into the organization's AI management system governance. Add supplier risks, recurring findings and unresolved gaps to the AI risk register, and update the risk treatment for any changed rating. Summarize supplier performance, incidents and exceptions for the management review meeting, and record decisions and assigned actions. Adjust the supplier criteria or contract templates when repeated findings show a gap in the policy. The step is complete when the management review minutes show the supplier topics, and the risk register reflects the current supplier position. The output is the meeting minutes, the updated risk register entries and the revised criteria or templates, with version history. This closes the loop so the process improves continually, which is the purpose of the management system.

Supplier evidence that passes an ISO 42001 audit

An assessor testing A.10.3 Suppliers wants to see one connected body of records, not a folder of unrelated documents. The core artifacts are a supplier register linked to the organization's AI system inventory, so every model, dataset, API or AI platform in use traces to a named supplier and to the internal system it supports. Each supplier entry should carry completed due diligence records with a dated reviewer sign-off, showing what was checked (the supplier's documentation on training data, intended use, known limitations, security practices and responsible AI commitments), who reviewed it, and when. Contract clauses matter as much as the questionnaire. Look for terms that require the supplier to provide AI system documentation, to notify the organization before material changes such as a new model version, retraining or a change of data handling, and to supply information needed for incident investigation. Ask counsel and procurement to confirm these terms exist in signed agreements, not only in standard terms pages.

Assessors also check that findings led to action. Monitoring logs should record periodic reviews of supplier performance, vulnerability and incident notices, and changes reported by the supplier, with the outcome of each review. Records of decisions to continue, restrict or exit a supplier close the loop: a restriction should name the conditions imposed, and an exit should show how the organization replaced or retired the dependency. Inconsistency is the most common weakness. If the register lists a model version that the monitoring log does not mention, or a supplier was reviewed after its contract renewed, the assessor will ask why. Before audit, cross-check the register, inventory, contracts and logs for one sample supplier and confirm that the dates and versions agree.

To keep this evidence current between audits, define review triggers in the supplier procedure. Typical triggers include a supplier announcing a new model version or a change in training data, a material security advisory, a change in the supplier's ownership or hosting location, a new use case for an existing supplier, and a contract renewal. Each trigger should create a dated review record. Open-source tooling can supply some of the monitoring inputs. OWASP Dependency-Track can track components, known vulnerabilities and license risk from CycloneDX SBOMs, and Trivy can generate or scan SBOMs for software dependencies, while garak can test a language model supplied by a third party for behaviors such as prompt injection and data leakage, with its JSONL reports retained as evidence. Confirm with your certification body which records it will sample and how long it expects them to span.

What ISO 42001 A.10.3 supplier controls cost

This table lists the cost components of running the A.10.3 supplier process, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No prices or durations were supplied, so use the quote questions in the final rows to compare offers on the same scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives cost up or down	How to keep it down
Tooling or licenses	Tool vendor or the organization's own staff; self-hosted open-source tools carry no license fee	Recurring for commercial platforms, often one-time setup plus upkeep for open source	Number of suppliers and AI components tracked; commercial seat or asset-based pricing; hosting capacity	Use self-hosted open-source tools such as OWASP Dependency-Track (Apache-2.0) for SBOM tracking, and confirm license terms of each tool before adoption
Engineering time for inventory and SBOM work	Internal platform or ML engineers, or an implementation partner under a fixed-scope agreement	One-time for the first full inventory, recurring for updates when suppliers or models change	Count of AI components per supplier, depth of dependency data available from suppliers, and how many systems use the same supplier	Generate SBOMs in build pipelines with tools such as Trivy (Apache-2.0), and require suppliers to provide machine-readable inventories at onboarding
Legal time for contract terms	In-house counsel or outside counsel, billed by the hour or by fixed fee	One-time per contract, with recurring review at renewal	Negotiation leverage with the supplier, number of standard templates, and how many suppliers are critical	Maintain a standard AI supplier clause set covering disclosure, change notice and data use, and reserve negotiated terms for high-risk suppliers
Due diligence on high-risk suppliers	Internal risk team or external reviewers, sometimes the supplier's own assessment documents	One-time at selection, recurring at reassessment	Risk tier of the AI use, depth of supplier documentation, and whether the supplier answers questionnaires consistently	Tier suppliers by impact and data sensitivity so deep review is limited to high-risk suppliers
Ongoing monitoring and testing	Internal security or AI teams; specialist testers if external testing is used	Recurring	Frequency of model or version changes, and whether the organization runs its own probes against supplied models	Automate scheduled checks, and use open-source probes such as garak (Apache-2.0) on models where the organization has permission to test
Evidence upkeep	Internal compliance or GRC staff, or a GRC platform if one is licensed	Recurring, with a spike before each assessment	Number of suppliers with records to maintain, and whether records are kept in one place	Keep one supplier register linked to contracts, SBOMs and review dates, and assign an owner for each supplier
External review of high-risk suppliers	External assessors or specialist firms engaged by the organization	Usually one-time per engagement, sometimes recurring	Number of high-risk suppliers, scope of review, and whether reports from suppliers can be reused	Accept current independent reports from suppliers where they cover the same scope, and limit fresh reviews to gaps
Auditor sampling	External certification body, paid for the audit by the organization	Recurring at each audit cycle	Number of suppliers the auditor samples, and how easily records can be produced	Prepare a sample-ready file for each supplier so the auditor can test without long searches. Ask the certification body for its sampling approach before the audit.
Quote questions to ask	Vendors, consultants and certification bodies	Applies to every quote	Unclear scope creates change orders and hidden recurring fees	Ask for the written scope, what is one-time versus recurring, the license terms of any tool, which evidence is delivered, and the assumed number of suppliers and AI components

Open-source tools that support supplier evidence

A.10.3 expects evidence that third-party AI components fit your responsible AI approach. The four tools below produce some of that evidence from component inventories, vulnerability data, model probing and framework mapping, and each one covers a different part of the supplier record.

OWASP Dependency-Track

Dependency-Track consumes and produces CycloneDX SBOMs and VEX, so you can keep a running inventory of the libraries, models wrappers and packages your AI products pull in from suppliers. It flags components with known vulnerabilities, outdated or modified components and license risk, and tracks license use by component using SPDX license IDs. For A.10.3, check whether suppliers can deliver SBOMs in CycloneDX format, since the inventory is only as complete as the files you receive. Confirm that each supplier component maps to a named owner and approved license.

Trivy for component scanning

Trivy identifies the OS packages and software dependencies in a target and can produce them as a software bill of materials. It can also scan existing SBOMs, which helps when a supplier provides an inventory and you need to check it against what is actually deployed. For A.10.3, this gives you a way to test supplier-delivered artifacts instead of accepting their documentation at face value. Confirm which package ecosystems your AI stack uses, because coverage depends on what Trivy can read in your images and environments.

garak for model probing

garak probes language models for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation, plus a hit log of attempts that found a vulnerability. For A.10.3, these reports give you test evidence for a third-party model before and after you adopt it or change its version. Probing does not establish that a model is fit for your use case, so define the acceptance criteria and the test prompts yourself and confirm that garak covers the model type you plan to evaluate.

CISO Assistant for framework mapping

CISO Assistant ships more than 200 frameworks, including ISO 27001, NIST CSF, SOC 2, PCI DSS, NIS2, DORA and GDPR, and runs audits and compliance assessments against them with automatic mapping between frameworks. It can hold your A.10.3 supplier records, due diligence results and assessment answers in one place so that each supplier review is traceable to the control it supports. Because it is licensed under AGPL-3.0-only, confirm the license terms with your legal team before you modify or host it for others. Confirm also that the framework content you need is present in the version you deploy.

Who owns the supplier process, and what a partner can take on

Your organization owns the A.10.3 supplier process. Accountability for responsible AI sits with named people inside the company, and no outside party can accept the risk of a supplier on your behalf. Decisions about which models, datasets and AI platforms you bring in, and on what terms, belong to your own governance and leadership.

Supplier decisions: Approve or reject each model, dataset and AI platform against your documented responsible AI approach, and record the reasoning.
Contract signing: Your authorized signatories agree the terms, including data use, change notification, audit rights and exit provisions.
Risk acceptance: Name who accepts residual supplier risk, at what level, and when that acceptance is reviewed.
Ongoing monitoring: Assign an internal owner to review supplier changes, incidents and performance on a set schedule.
Records: Keep the decision log, signed agreements and risk acceptances where an assessor can find them.

Before relying on this split, confirm that each decision has a named owner in your RACI chart and that the owner has the authority and time to exercise it.

Where supplier controls usually fall short

Supplier controls under A.10.3 tend to fail in the same few places: the inventory is incomplete, reviews go stale, contracts are silent, monitoring leaves no trace, and findings never reach risk decisions. Each card names one gap and the action that closes it, so the process can be shown to work in an assessment rather than only written down.

Shadow AI suppliers missing

AI models, APIs and SaaS features often arrive through team-level sign-ups, browser plug-ins or embedded vendor features that never pass procurement. These suppliers are absent from the supplier register, so no due diligence or contract review applies to them. Close the gap by pairing a supplier register with a periodic sweep of expense records, identity provider application logs and network egress to AI endpoints, then routing every new find through the same intake form. Confirm which of your existing tools can produce those logs.

Due diligence done once

Teams often assess a model or AI platform at purchase and never revisit it, even when the provider changes weights, training data, hosting region or sub-processors. A later version can carry different risks from the one that was approved. Set triggers for re-review, such as a major version change, a change of sub-processor, a new data category or a material incident reported by the supplier, and record the date and reviewer for each re-assessment.

Contracts silent on AI

Standard software terms often say nothing about how a supplier develops or changes its AI, what documentation it will provide, or how much notice it gives before a material change. Without those terms, the organization cannot ask for evidence it needs for its own A.10.3 process or for customer questionnaires. Add clauses covering model documentation, change notification windows, incident notice, data use for training, and the right to request audit evidence. Ask legal counsel to confirm the wording.

Monitoring without records

A policy may say that suppliers are monitored, yet no dated review, performance result or exception note exists to show it happened. Assessors look for evidence that monitoring ran and what it found. Assign an owner for each critical supplier, define the review frequency and the metrics checked, and store each review as a dated record with a decision. Dependency and vulnerability scan outputs for supplied components can serve as part of that record.

Findings cut off from risk decisions

Supplier issues are sometimes logged in a vendor tool and never reach the AI risk register or the management review agenda. As a result, a supplier that repeatedly fails a control keeps its access, and leadership never decides whether to accept the risk. Add a standing field in the supplier record that links each open finding to a risk entry, and include unresolved supplier findings as a fixed item in management review minutes, with the decision taken on each.

Questions buyers ask about A.10.3 supplier controls

How much effort does the supplier process take for a small team?

For a small team, the effort depends mostly on how many AI suppliers you use and how deeply each one touches personal data or customer-facing decisions. A typical starting point is one supplier register, one due diligence questionnaire, one standard contract addendum and a named owner who reviews each supplier on a fixed cycle. Costs are mainly staff time, which recurs as suppliers change terms, release new models or drop features. Ask any consultant to quote the work by supplier count, data sensitivity and the number of existing contracts that need amending. No duration or fee is supplied for this work, so confirm both against your own inventory before committing.

Can we run the A.10.3 supplier process in-house?

Yes, an organization can run the A.10.3 process in-house, provided it has a clear owner, written criteria and records that show the process operates. The control asks you to establish a process so that products, services and materials from suppliers, such as models, datasets and AI platforms, fit your approach to responsible AI. Nothing in the standard requires an outside firm. Outside help usually makes sense when no one on staff has time to maintain the register, when contracts need deep review, or when you need a readiness check before an assessment. Whichever route you choose, the organization owns the controls and the evidence.

What does the supplier process need from legal and engineering staff?

Legal staff need to define the minimum contract terms for AI suppliers, such as disclosure of model changes, data use restrictions, incident notification, audit or evidence rights and exit conditions. Engineering staff need to maintain an inventory of AI components, including models, datasets, APIs and hosted platforms, and to record versions and known risks. The two groups also need to agree who approves a new supplier and what happens when a supplier fails review. Expect the work to be recurring: each new model, plug-in or data feed is a new supplier entry. Some organizations track component inventories with an SBOM tool such as OWASP Dependency-Track to keep engineering records current.

How long does it take to put a supplier process in place?

No duration is supplied for this work, so treat any single number you hear with caution. The time depends on how many AI suppliers you already use, whether contracts already contain AI-relevant terms, how mature your asset inventory is, and how many approvals your organization requires. Organizations with few suppliers and existing vendor management usually move faster than those discovering AI tools in use across many teams. Ask for a milestone plan that separates inventory, criteria, contract changes and first monitoring cycle, and confirm the dates against your own environment before accepting them.

Can an implementation partner certify our supplier process?

No. An implementation partner can help design, document and test the supplier process and prepare the evidence, but it cannot certify it. Only an independent certification body can issue an ISO/IEC 42001 certificate, and ISO itself does not certify organizations. DeployOpen prepares systems, controls and evidence for assessments, and it does not issue audit reports, attestations or certifications. Keep the implementation work separate from the audit so the certification body can review your process independently. Ask any partner to state in writing which parts of the work it performs and which parts the organization and the auditor own.

What if a foundation model provider refuses detailed documentation?

Start by stating what evidence you need and why, then check what the provider already publishes, such as model cards, security documentation, data handling terms and change notices. If the provider still declines, treat that as a risk decision rather than a paperwork gap. Options include contracting for specific commitments, restricting the model to lower-risk uses, adding your own testing and monitoring, or choosing a different supplier. You can test some model behavior yourself with tools such as garak, which probes language models for prompt injection, data leakage and other failure modes and writes a report of attempts. Record the decision, the residual risk and who accepted it.

Which AI supplier risks should we monitor after onboarding?

Monitoring should cover changes that alter risk after a contract is signed. The main areas are model version and behavior changes, new data uses or retention terms, security incidents at the supplier, changes in ownership or subprocessors, and licensing changes for models or datasets. Set a review cadence for each supplier based on its data sensitivity and business impact, and trigger an extra review when a material change is announced. Keep the monitoring record in the same register as the due diligence file so an assessor can follow each supplier from onboarding to today.

How DeployOpen prepares supplier controls and evidence

DeployOpen plans and builds the technical side of A.10.3 Suppliers inside your own infrastructure: the supplier inventory, the open-source tooling that tracks third-party components and AI model risk, and the records an assessor will ask to see. Your organization owns its supplier decisions and contracts, and only an independent auditor or certification body can issue an assessment result or certificate.

How we scope

We agree a written scope listing which AI suppliers, models, datasets and platforms the A.10.3 process covers.
We confirm which supplier evidence your organization already holds and which records are missing before work starts.
We document the scope, deliverables and timeline in writing, with the roles of your staff, DeployOpen and the auditor stated.

How we build

We deploy self-hosted tooling such as Dependency-Track and Trivy to inventory third-party software components and their SBOMs.
We set up model probing with garak so supplier models can be tested for issues before and after adoption.
We configure CISO Assistant to hold supplier criteria, review records and mappings to other frameworks your organization uses.

How we hand over

We deliver the configured systems, runbooks and a record of each supplier review step for your own staff to operate.
We provide documentation that maps each supplier evidence item to the A.10.3 process and to the controls it supports.
We walk your compliance and engineering teams through the evidence so they can answer assessor questions themselves.

How we support

We can support ongoing supplier monitoring, tool upgrades and periodic re-testing under a retainer agreed in writing.
We help you prepare for the auditor's questions, while the auditor independently tests the evidence.
We ask you to confirm supplier contract terms and due diligence decisions with your legal and procurement teams.

A.10.3 Suppliers