Does ISO 42001 apply to a SaaS company that adds AI features built on third-party models?
ISO/IEC 42001 applies to any organization that provides or uses products or services that use AI systems, so a SaaS company that ships AI features is usually in scope as both provider and user. The standard does not exempt a company because it calls a model vendor's API instead of training its own model. If your product now generates text, scores records or recommends actions for customers, a customer or RFP asking for ISO 42001 is asking about your organization, not about the model vendor's. Start by writing down, for each AI feature, who builds the prompts, retrieval logic, guardrails and output handling, who operates the feature, and who sees its results. Those answers decide how much of the standard's scope lands on your team. The scope, the Annex A controls you must include or justify excluding, and the effort involved all follow from how much you build, configure and expose to customers. A company that only wraps a vendor model in its own interface will mostly need the controls on responsible use (A.9), information for users (A.8) and third-party relationships (A.10). A company that fine-tunes models, builds its own evaluation pipelines or stores customer data for model improvement will also need life cycle, data and impact assessment controls. Your statement of applicability under clause 6.1.3 must record each inclusion and exclusion with a reason, so the reasons should match what the product does today. Confirm the feature inventory with engineering before you commit to a scope. Only an accredited certification body issues an ISO 42001 certificate after an audit, and the costs you will carry include internal staff time, evidence preparation, tooling and the audit fee itself. DeployOpen can plan, implement and document the systems and evidence that support your controls, under a written fixed scope, but it does not certify, audit or attest to your conformity. Ask any consultant to show how their work stays separate from the certification body that will audit you.
Which scope decisions change the audit and the bill
Before an auditor samples anything, the company decides what sits inside the AI management system. Each decision below widens or narrows the set of controls, records and systems the team must evidence, so the decisions should be made in writing before the statement of applicability is drafted.
Which AI features fall inside scope
The certified scope must name the AI features that process customer data or affect customer outcomes, such as a summarizer, a classifier or an assistant inside the product. Each feature inside scope needs its own impact assessment, life cycle records, use controls and customer information. A feature left out still has to be explained, and the reason has to hold up when a customer asks why it was excluded. Ask the certification body how it expects a scope boundary to be drawn when features share one model endpoint.
In-house pipelines or vendor-built ones
Fine-tuning, prompt templates, retrieval pipelines and evaluation harnesses built by the SaaS team are development activities. They bring in the life cycle objectives, design records, verification and validation, and data controls of the standard. Using a vendor's hosted feature with only configuration changes generally produces less of this evidence, but the company still has to show how it configured and monitored the feature. Document each build decision as it is made, because reconstructing design records after an audit date is slow and weakens the record.
Which customer data reaches the model
Every data source that flows into prompts, retrieval indexes, fine-tuning sets or logs is a separate data story. The company needs records of acquisition, provenance, quality checks and the basis for using customer content, and privacy obligations apply where personal data is involved. Retrieval indexes that copy tenant documents create retention and deletion questions that auditors ask about. Map each data path before scoping, and confirm whether the model vendor retains prompts or uses them for training under the contract terms.
Self-hosted models or vendor APIs
Running model hosting on the company's own cloud accounts or clusters puts the infrastructure, patching, access control, capacity and model artifact management inside the certified boundary. Calling a third-party API moves much of that operation to the vendor, which shifts the evidence burden to supplier controls and to the vendor's own certificate. The two choices produce different evidence sets, so the scope statement should name which components the company operates and which it only consumes.
Excluded controls and their justification
Clause 6.1.3 requires a statement of applicability that lists the Annex A controls the company includes and justifies each exclusion. A SaaS company that does not train models may exclude some development controls, but it must write why each one does not apply to its role, and the justification must match what the company actually does. An exclusion that contradicts a feature in scope is one of the most common reasons an auditor raises a finding. Review the exclusions whenever a new feature or model vendor is added.
How to allocate responsibilities with model vendors under A.10
Control A.10.2 asks the organization to allocate responsibilities across the AI system life cycle between itself, its partners, suppliers, customers and other third parties. For a SaaS company that calls a third-party model, the split usually runs along the lines of who trains and maintains the model, who designs the prompts, retrieval and output handling, who configures the feature, and who operates it for the customer. Write the split down as a responsibility matrix that names each life cycle stage, the party that holds it and the artifact that proves it. The matrix is an internal record, so it should match what the product actually does rather than what the vendor's marketing says.
- Model training and updates: Record that the vendor owns training data, model versions and change notices, and that the company owns the decision to adopt or pin a version.
- Feature design and prompts: Assign the company ownership of prompt templates, guardrails and output filters, since these shape behavior in its product.
- Deployment and operation: State who runs the inference endpoint, monitors it and responds to incidents.
- Customer configuration: Identify which settings customers can change and which the company locks.
- Retirement: Assign who decides when a model is withdrawn and how customers are moved.
Confirm the matrix with each vendor's documentation, because a vendor's stated scope may differ from your reading of it.
Control A.10.3 asks the organization to set up a process that checks whether services, products or materials obtained from suppliers align with its approach to responsible development and use of AI. For a SaaS company, this means the vendor's terms and practices must be checked against the company's own AI policy before the model goes into production. The process should produce a record of what was checked, by whom and with what result, and it should repeat when the vendor changes terms or models.
- Contract terms to request: Data use limits, notice periods for model changes or deprecations, incident notification, subprocessor lists and audit or evidence rights.
- Vendor evidence to collect: Security and AI governance documents, certificate scope statements, model cards or system documentation, and responses to your questionnaire.
- Data handling confirmation: Written statements on whether customer inputs are used for training, where they are processed and how long they are retained.
- Review records: Dated approval of each vendor against the AI policy, with exceptions and owners named.
- Re-review triggers: Vendor model updates, changes in terms, security incidents and new regulatory obligations.
Ask the vendor which contract clauses apply to your tenant and region, because standard terms and negotiated terms often differ.
Control A.8.2 asks the organization to determine and provide the information users need about the AI system. For a SaaS feature built on a third-party model, the company is the party that customers actually see, so it must pass on what the vendor tells it in a form customers can use. This covers the feature's intended purpose, its known limitations, the data it uses, how outputs should be checked and how to report problems. Information that is only in the vendor's documentation is not enough unless the company has determined that customers can reach it and understand it.
- Intended use and limits: Describe what the feature is for, what it should not be used for and where output quality is known to vary.
- Data and model disclosures: Explain which data the feature sends to the model, which vendor processes it and where it is stored.
- Change notices: Commit to telling customers when the underlying model or its behavior changes in a way that affects them.
- Reporting channel: Give customers a route to report errors, harmful output or suspected misuse.
- Vendor-sourced content: Decide which vendor documentation to reproduce or link, and keep it in step with the vendor's current version.
Check these statements with your legal and product teams before publication, since they become the basis of customer expectations.
Responsibilities also sit with the customer, so the company should state in its contracts which duties it carries and which the customer keeps. Under A.10.2, a customer that configures the feature, supplies its own data or decides how outputs are used holds part of the life cycle. The company should not claim a certificate or vendor assurance covers the customer's own controls, because each organization needs its own assessment. Vendor certificates reduce the evidence the company must gather, but they do not transfer its accountability to the vendor or to the customer.
- Customer-side duties: List the configuration, data and use decisions that rest with the customer and that the company will not control.
- Company-side duties: Set out what the company guarantees about its integration, safeguards and vendor selection.
- Vendor certificate scope: Record what each vendor's certificate covers, its scope statement and the date it was issued, and avoid implying it covers the company's own product.
- Assessment reliance: Note where the company relies on a vendor's certificate in its own assessment and where it runs independent checks.
- Contract alignment: Make sure the customer agreement, the service description and the vendor terms describe the same split.
Illustrative example: a customer that uploads its own documents to the feature holds responsibility for the accuracy of those documents, while the company holds responsibility for how the feature processes them. Ask counsel to review the final wording.
What a model vendor's certificate does and does not cover
A model vendor's ISO/IEC 42001 certificate does not certify your SaaS product. AWS states that customers are not automatically certified to ISO/IEC 42001 by association. Microsoft makes the same point from the other side: customers that need certification for implementations of Microsoft AI systems can use Microsoft's certification as evidence in their own compliance assessment, but they remain responsible for engaging an assessor to evaluate their own controls, processes and implementation. The vendor's certificate covers the vendor's management system within the scope it names. Your feature, your prompts, your data handling, your customer-facing disclosures and your own AI management system are outside that scope and remain yours to certify or evidence.
What the vendor's certificate can do is make your own audit easier, because a certified supplier process gives your assessor a tested control to rely on for the supplier relationship. That benefit depends on the detail. Request the certificate's scope statement and confirm exactly which services, models and regions it names, since a certificate covering a platform does not automatically cover every model endpoint you call. Ask for the vendor's statement of applicability and check which controls it includes and excludes, especially the supplier and information controls that matter to you. Note the date of the audit and ask how the vendor handles changes after it, such as new model versions or retired endpoints. Confirm these points with the vendor directly, and record the answers as supplier evidence under your own A.10.3 process.
Plan for the gap the certificate leaves. Map each vendor-certified claim to the specific feature it supports, then list what remains open: how your product presents AI output to users, what your documentation tells customers about intended use, how you monitor and log the feature, and how you respond to adverse impacts. Those items drive your own impact assessments and information controls, and an assessor will ask for evidence of each one regardless of the vendor's status.
How to scope ISO 42001 for an AI-enabled SaaS product
This sequence turns a set of AI features built on third-party models into a defined scope, a justified statement of applicability and a vendor evidence file that an accredited certification body can review at stage 1.
Inventory AI systems and assign roles
Start by listing every feature in the product that uses AI, including features built on hosted models, embedded vendor APIs and internal tools that shape customer output. For each system, record whether your organization acts as provider (you place the feature on the market under your name), user (you run a vendor's system inside your own service) or both. Assign a named owner for each system and for the AI governance role itself. The output is a dated AI system inventory signed off by the accountable executive, which is the baseline every later step depends on.
Map features to vendors and data flows
For each inventoried system, trace the model vendor, hosting location, sub-processors, the data sent in prompts or training inputs, and the data returned to customers. Include logging, fine-tuning data and any retained outputs. Engineering and privacy staff should review the map together, because data flows often differ from the architecture diagram. The output is a data flow map per system that shows where personal data, customer content and model outputs move, and which party controls each hop.
Write the scope statement
Draft a scope statement that names the products, features, customer-facing AI functions, internal AI tools, organizational units and locations covered by the management system. Be explicit about what is excluded and why, such as a pilot feature that is not offered to customers. The scope must match what the company actually operates and sells, since the certification body will test whether the scope is accurate. The output is a written scope statement approved by management and cross-checked against the inventory and data flow map.
Draft the statement of applicability
Work through the Annex A controls, grouped by objective area, and record for each whether it is implemented, how it is implemented in your environment, or why it is excluded. Clause 6.1.3 requires justification for both inclusion and exclusion. A SaaS company that does not train models will often exclude some development and data preparation controls with a documented reason, while keeping the controls on information for users, responsible use and third-party allocation. The output is a statement of applicability that links each control to an owner, a procedure and the evidence location.
Collect model vendor evidence
For each third-party model or AI service, request the vendor's documentation on its own management system, its published information for customers, its data handling commitments, its security and incident terms and its support for your user obligations. Check whether the vendor holds an ISO/IEC 42001 certificate and read its scope. A vendor certificate can make your own assessment easier, but it does not cover your features, your prompts, your data handling or your configuration. The output is a vendor evidence file per supplier with the document, its date, the scope it covers and the gap it leaves for your own controls.
Close gaps and assemble the evidence package
Document the responsibilities split between your organization and each partner or supplier, including who handles customer notices, who responds to model incidents and who updates the system when a vendor changes a model. Confirm that each control marked as implemented has a procedure, a record and a named owner. Remove unsupported claims from the statement of applicability before it leaves your organization. The output is one evidence package containing the policy, scope statement, inventory, data flow maps, statement of applicability, vendor evidence files and responsibility matrix.
Hand the package to an accredited certification body
Engage an accredited certification body to conduct the stage 1 review, which checks the documented system and its readiness for assessment. Confirm that the body's accreditation covers ISO/IEC 42001 and that it applies ISO/IEC 42006:2025 on top of ISO/IEC 17021-1. Your implementation partner or consultant can prepare the package, but only the certification body issues the certificate. The output is the stage 1 review report from the certification body, which lists findings your team must resolve before stage 2.
What must exist before a certification body will audit
A certification body samples evidence across the management system, not just the Annex A controls. The cards below cover the records a SaaS company adding AI features should have in place and check internally before booking a stage 1 audit, because gaps in these records are where readiness reviews usually stall.
Documented AI policy
The AI policy sets management direction for every AI feature you ship, including the models you call through an API. Check that it names the AI systems in scope, states the commitments leadership has made about responsible use, and carries an owner, an approval date and a review date. Confirm that the policy is communicated to the staff who build, sell and support the AI features, since auditors often ask employees what the policy requires of them.
Named AI roles and responsibilities
Auditors look for named people, not job titles alone, against each AI responsibility: who approves a new model vendor, who owns product risk for an AI feature, and who handles concerns raised about AI output. Check that the roles appear in a current RACI or equivalent record and that the people named know they hold them. Confirm the process for raising concerns about AI systems is written down and has been used or tested at least once.
AI impact assessment records
For each AI feature, keep a dated assessment of its effects on the customers and end users who receive its output, and on society where relevant. Check that each assessment covers the intended use, foreseeable misuse, affected groups and the mitigations applied. ISO/IEC 42005:2025, published 28 May 2025, is the supplied companion guidance for this work and is worth reading before you draft the template.
Vendor register with contracts and reviews
Maintain one register listing every third-party model provider, hosting service and data processor behind an AI feature, with the contract terms covering data use, retention, security and change notice. Check that each entry has evidence of a periodic review, such as a reviewed certificate, report or questionnaire response, dated within your review cycle. Ask each vendor which parts of the AI life cycle they own, so the allocation of responsibilities under A.10.2 is written down rather than assumed.
User-facing AI documentation
Users of an AI feature need documentation that states its intended use, its known limitations, the data it uses and the human oversight expected of them. Check that this information is published or delivered to customers, that it matches what the product does today, and that it is version-controlled alongside each release. Auditors will compare this material against the intended-use statements in your impact assessments and the controls for use in A.9.4.
Internal audit and management review records
The management system must be checked by people independent of the work, and leadership must review it at planned intervals. Keep an internal audit plan, the completed audit reports, the corrective actions raised and the minutes of management review that record decisions on AI risk and objectives. Before booking an audit, confirm that at least one full internal audit cycle has run and that findings were closed with evidence, since an empty or unfinished cycle is a common reason for a stage 1 delay.
Questions SaaS teams ask before scoping ISO 42001
Does a SaaS company have to get ISO 42001 certified?
No. ISO/IEC 42001 applies to any organization, regardless of size, that provides or uses products or services that use AI systems, so a SaaS company adding AI features falls within its scope. Certification is a separate step. The company chooses whether to pursue it, and ISO does not certify organizations. An accredited certification body issues any certificate after an independent audit. Many SaaS companies first meet the standard's requirements, write a statement of applicability under clause 6.1.3, and then decide whether a customer contract or a sales requirement justifies certification. Confirm with the customers or contracts that matter whether they ask for certification, a self-assessment, or evidence of the management system.
Does calling a model vendor's API put my product in scope?
In most cases, yes. A feature built on a third-party model is still an AI-based product or service delivered to your customers, so your organization acts as a provider and the management system applies to it. The standard expects you to manage the relationship with the model vendor. Annex A control A.10.2 asks you to allocate responsibilities across the AI system life cycle between your organization, partners, suppliers, customers and other third parties. Control A.10.3 asks you to ensure that services, products or materials you obtain from suppliers align with your approach to responsible development and use of AI. Your scope statement should name each model vendor, the features that depend on it, and the responsibilities you keep.
Is a model vendor's ISO 42001 certificate enough for customer questionnaires?
No. A vendor's certificate covers the vendor's own management system within the scope stated on that certificate. It does not cover your product, your data handling, your impact assessments or your customer-facing information. AWS states that customers are not automatically certified to ISO/IEC 42001 by association, although AWS's certification may make a customer's own certification easier. Microsoft says customers that need certification for implementations of Microsoft AI systems can use its certification in their compliance assessment but remain responsible for engaging an assessor to evaluate their own controls, processes and implementation. Read the scope statement, confirm which services and regions it names, and use the certificate as supplier evidence rather than as proof of your own compliance.
How much internal effort does ISO 42001 take for a SaaS team?
No figure for this is available from a researched source, so the effort depends on your own environment. The main drivers are the number of AI features and model vendors, whether those features process personal data, how many AI-specific records already exist, and how mature your existing information security management system is. Clauses 4 to 10 need a defined AI policy, roles, a risk and impact assessment process, competence records, documented information, internal audit and management review. Annex A adds controls for data, life cycle, user information and supplier management. Ask any partner for an effort breakdown by role and by control area in the written scope, and confirm which tasks your engineers, product, legal and security staff must carry out internally.
Can an implementation partner handle ISO 42001 alone?
No. An implementation partner can help plan the management system, prepare documents, configure systems that produce evidence and support the internal team through preparation. It cannot issue a certificate, and it should not stand in for the organization's own accountability. The organization owns its AI policy, its controls, its risk decisions and its statement of applicability. An independent certification body must audit the management system before any certificate is issued, and ISO/IEC 42006:2025 sets additional requirements for bodies certifying AI management systems. DeployOpen prepares systems, controls and evidence for compliance assessments and does not issue audit reports, attestations or certifications. Keep the implementation partner and the certification body separate so the audit stays independent.
How does ISO 42001 relate to ISO 27001 and the EU AI Act?
ISO/IEC 42001 uses the harmonized structure shared by ISO management system standards, which makes it compatible with ISO/IEC 27001. Many SaaS companies already run an information security management system, so policy, internal audit and management review processes can often be shared, while AI-specific controls such as impact assessment, AI data quality and life cycle records are added. The EU AI Act is different. The European Commission says ISO/IEC 42001 helps set up an AI management system but does not match the quality management system the Act requires. CEN and CENELEC approved EN 18286 for that purpose, and the Commission cited EN 18286:2026 in the Official Journal on 14 October 2026. Check whether your AI features fall under the Act and which obligations apply before treating the two as interchangeable.
What a fixed-scope engagement covers and hands over
A fixed-scope engagement with DeployOpen gives a SaaS company a written definition of what gets built, configured and documented inside its own infrastructure before any work starts. For an AI feature built on third-party models, that scope should name the systems involved: the AI gateway or service layer that calls model APIs, the logging and monitoring that record prompts, outputs and model versions, the access controls on those components, and the repositories holding the AI policy, the A.10 supplier records and the A.8 user documentation. DeployOpen plans, implements and documents these systems and the evidence they produce in the client's cloud accounts or data centers, and the written scope lists which Annex A controls are in and which are excluded with justification under clause 6.1.3.
Deliverables should be specific enough to test. Ask for a named list of artifacts, such as the statement of applicability draft, the supplier inventory with the responsibility split for each model vendor, configuration exports from the logging and access layers, the impact assessment records, and the runbooks the operations team will follow. Ask who owns each item after handover, which decisions remain with your AI governance owner, and what happens if a dependency such as a vendor's documentation is not available when the work is due. Those answers belong in the statement of work, not in a later email thread.
DeployOpen does not issue audit reports, attestations or certificates. Only an independent certification body accredited for ISO/IEC 42001 can certify your AI management system, and that body must be independent of the firm that helped you prepare. Confirm the certification body's accreditation status and its scope with the body itself before signing, and check the ISO certification guidance at ISO's certification page for how certification works. Plan the certification audit as a separate purchase with its own scope and timing, and treat the engagement deliverables as the evidence the auditor will review, not as proof of certification.
How DeployOpen prepares ISO 42001 evidence for SaaS teams
DeployOpen works with SaaS companies that add AI features built on third-party models and prepares the systems, controls and evidence an ISO 42001 assessment will test. We plan, implement and document inside your own cloud accounts or data centers. Independent certification bodies, not DeployOpen, issue any certificate.
How we scope
- Engagements are fixed-scope, with the AI features, models and vendors in scope agreed in writing before work starts.
- The written scope records your role as provider for your own features and as user of model vendor services.
- The scope lists which Annex A controls apply and which are excluded, with the justification your statement of applicability needs.
How we build
- We implement the supplier and responsibility controls for model vendors, including how life cycle duties are split between you and each vendor.
- We set up open-source tooling that records AI system inventory, model versions, changes and approvals in your environment.
- We run security testing of AI features and agents, and record findings and remediation as assessment evidence.
How we hand over
- You receive the documented AI policy, procedures, records and statement of applicability as deliverables you own.
- We document user information for A.8.2 and intended-use boundaries for A.9.4, so your customers can see how features should be used.
- Handover covers a walkthrough of the evidence so your internal owner can answer an auditor's questions directly.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- A retainer can keep vendor reviews, evidence records and internal audit inputs current as models and suppliers change.
- Your auditor, not DeployOpen, decides whether the evidence meets the standard. Confirm the certification body and its accreditation before you start.
