ISO/IEC 42001 by industry
ISO 42001 for software companies: governing the AI in your product, your models and your model suppliers
Clause by clause: ISO/IEC 42001:2023 requirements: every clause explained →
What changes when the organisation is a SaaS, platform or API company shipping AI features: why customers ask, which AI systems and roles belong in scope, where auditors sample in a fast release cycle, and how the AIMS sits beside SOC 2, ISO/IEC 27001 and the EU AI Act.
Key points
- Software companies usually meet ISO/IEC 42001 through a customer's AI due-diligence questionnaire, sent once an AI feature ships inside a product they already use.
- The scope is set per AI system and per role: the models you train, the AI features you ship to customers, and the third-party foundation models you call through an API.
- Auditors sample hardest where software differs from other sectors: release gates for model changes, monitoring for drift, the provenance of training data and the terms agreed with model suppliers.
- A company already running ISO/IEC 27001 or a SOC 2 programme can extend the same policies, risk method and evidence calendar rather than build a second system.
Why software companies are asked for ISO/IEC 42001
The question now arrives at renewal. A customer's third-party risk team adds an AI section to its vendor review: which features use AI, whose model sits underneath, whether customer content trains it and who is accountable when a feature misbehaves. For a SaaS, platform or API business, a certificate from an accredited body answers the governance part with one document the reviewer can check.
Three kinds of customer drive it: regulated buyers such as banks and insurers, who must show their supervisors how they oversee vendor AI; enterprises with an internal AI policy that applies to every supplier; and other software companies whose product now depends on your AI feature or API.
What sets this sector apart is the rate of change. Models are retrained, prompts revised, and a supplier's new foundation model version can shift a shipped feature without a line of your own code changing. An AIMS that works here is built into the release process, not written beside it. For what the standard itself asks, see the ISO/IEC 42001 requirements guide.
What sits inside the scope for a software company
Start with an inventory: every AI feature customers use, every model you train or fine-tune, every internal AI tool touching customer data or code, and every external model you call. For each, record your role: developing the model, providing a feature built on someone else's, or using AI internally. Engineers often shorten this to provider and deployer; the scope statement should say which applies, because the controls and evidence differ.
A third-party foundation model stays in scope even though you did not train it: you choose it, configure it, decide what data it sees and test its outputs. The supplier's own governance sits outside your certificate; your selection, testing and monitoring of it sit inside.
Three scope mistakes recur: naming only the flagship AI feature while other products call the same model; omitting the pipeline that prepares training and evaluation data; and excluding internal coding assistants that see customer code. The general rules are in the ISO/IEC 42001 scope guide.
Where the requirements bite for technology and software
| Requirement area | What it means in a software company | Evidence the auditor samples |
|---|---|---|
| AI system life cycle (Annex A.6): verification, validation and deployment | A model or prompt change reaches customers only after it passes defined tests, like any other release | Evaluation results against acceptance criteria, release gate approvals, rollback records, technical documentation |
| Operation and monitoring (A.6.2.6) with reassessment on change (8.2, 8.4) | Drift and unexpected outputs in production are detected; a significant change triggers fresh risk and impact assessments | Alert thresholds, event logs, incident tickets, reassessments dated after model or supplier changes |
| Data for AI systems (A.7): acquisition, quality and provenance | You can show where training and evaluation data came from, your rights over it and how it was checked | Data source register, licence or contract terms, customer opt-out handling, quality checks, dataset version history |
| Third-party and customer relationships (A.10) | Responsibilities between you, your model suppliers and your customers are allocated and written down | Assessments of model suppliers, API and data-use terms, customer contract clauses |
| Information for interested parties (A.8) | Customers know which features use AI, what they are intended for, their limits and how incidents are reported | In-app notices, intended-use statements per feature, incident communication records |
The nine control groups are covered in ISO/IEC 42001 Annex A: the 38 controls explained, and the impact assessment method in AI system impact assessment, with ISO/IEC 42005.
Working alongside SOC 2, ISO/IEC 27001 and the EU AI Act
Many software companies pursuing ISO/IEC 42001 already hold ISO/IEC 27001 certification or a SOC 2 report, so access control, change management, supplier review and internal audit already run; the AIMS adds the AI policy, the AI risk and impact assessments, the Annex A controls and life-cycle records. One risk register and one audit programme can serve all of them; see ISO/IEC 27001 to ISO/IEC 42001: extending an ISMS into an AIMS.
Where training or customer data is personal data, ISO/IEC 27701 gives the privacy management system that sits beside the AIMS. EU customers will also ask about the EU AI Act. ISO/IEC 42001 is not a harmonised standard under the Act and gives no presumption of conformity, though the governance it builds is useful groundwork; the detail is in ISO/IEC 42001 and the EU AI Act: what the certificate does not give.
What a software engagement looks like
Duration depends less on headcount than on the number of AI systems in scope, whether a management system already runs, how far model evaluation is automated and when the first customer needs the certificate. Each AI feature's product owner, the data science lead, platform engineering, security, legal and the owner of supplier contracts must be involved. With Design™, Sterling guides your teams to build and own the AIMS; with Drive™, Sterling carries more of the documentation, assessments and readiness testing so product teams keep shipping.
How Sterling works with technology and software companies
AI governance that runs through your release process.
Our expert and experienced consultants build the AI inventory with your teams, run the risk and impact assessments, tie reassessment to your release gates, and keep the evidence in Effivity, included with the engagement at no additional cost. Sterling does not certify; an independent, accredited certification body audits and decides. We ensure successful certification for our clients.
Book a free discovery callISO/IEC 42001 for technology and software: questions buyers ask
We build on a third-party foundation model through an API. Can we still get ISO/IEC 42001 certified?
Yes. The certificate covers how you select, configure, test and monitor that model in your product, not the supplier's development of it; the evidence is your supplier assessment, evaluations and monitoring.
Does every model update need a new AI impact assessment?
No, only significant changes, plus planned intervals. Define in advance what counts as significant, such as a new model version, use or dataset, and record each decision.
Can we use customer data to train our models under ISO/IEC 42001?
The standard does not forbid it, but you must show the data's source, your rights over it and how it was checked; your contracts decide what is permitted.
Will ISO/IEC 42001 certification answer our customers' AI questionnaires?
It answers much of the governance section. Product-specific questions, such as which model a feature uses or where data is processed, still need an answer library consistent with your AIMS records.
ISO/IEC 42001 by industry
Every guide in the ISO/IEC 42001 series is written for one question and links back to the hub for the whole picture.
- ISO/IEC 42001 for banking and financial services
- ISO/IEC 42001 for BPO and shared services
- ISO/IEC 42001 for healthcare
- ISO/IEC 42001 for HR and staffing
- ISO/IEC 42001 for professional services
- ISO/IEC 42001 for retail and e-commerce
- ISO 42001 Stage 1 and Stage 2 audit
- ISO 42001 for start-ups and small AI teams
- ISO 42001 surveillance audit and recertification
- ISO/IEC 42001 for technology and software
- ISO 42001 certification in the Philippines
- ISO 42001 certification in the UAE and GCC
- ISO 42001 certification in the UK
Keep exploring
Explore more about ISO/IEC 42001
Watch a video on how to implement ISO 42001 here.
Watch a video on ISO 42001 requirements here.
ISO/IEC 42001 resources
Services for ISO/IEC 42001
Talk to a consultant
Plan an ISO/IEC 42001 programme that runs through your release process.
Tell us your goals, locations and target date. We’ll help you define the scope, timeline and next steps.
hello@sterling-grc.com+1 201 263 4443 (global headquarters) · your nearest office and its number are at the top of this page
What would you like to achieve?
Choose a starting point. The enquiry form takes about a minute.
Book my free discovery callContinue to the enquiry form to share your details. Please do not include passwords, sensitive personal information or confidential files. A Sterling consultant replies within one working day. Privacy notice