ISO 42001 for AI startups: when to start and what it costs

ISO 42001 for AI startups: when to start

ISO/IEC 42001 applies to any organization regardless of size, so an AI startup can begin whenever the business needs it. The real decision turns on two questions: who is asking for the certificate, and by when. A customer's RFP deadline, an investor's diligence request or a plan to sell into regulated buyers will set that timing far more than headcount or revenue. Before committing, write down the specific requirement you are answering, the date it bites, and whether a documented governance baseline without certification would satisfy the person asking.

Be precise about roles from the start. ISO does not certify organizations. An external certification body issues the certificate after its own audit, and its accreditation is voluntary. DeployOpen plans, implements and prepares the systems, controls and evidence your team needs for that audit, but it never issues an audit report, attestation or certificate. Your founders or the named AI governance owner remain accountable for the controls. Ask any certification body you shortlist for its quotation and confirm whether it is accredited for ISO/IEC 42001 in your country, since ISO/IEC 42006:2025 sets additional AI-specific requirements for those bodies.

A startup should expect a small team to carry real effort. You will need a statement of applicability under clause 6.1.3 that justifies including or excluding each Annex A control, and a documented AI risk and impact assessment. The three-year certification cycle means fees and audit obligations recur across that period, so ask each body how its quotation is split between the initial audit and later surveillance years. Plan the first year around readiness, not only the audit date, because the evidence has to exist and operate before the certification body looks at it.

What makes a startup's ISO 42001 project heavier or lighter

Six drivers decide how much work an ISO 42001 project creates for an AI startup. Most of them are within the company's control, and the cheapest way to keep the project light is to decide early which products, data and suppliers fall inside the AI management system.

Number of AI systems in scope

Every AI feature a customer can reach is a candidate for the scope, and each one needs its own impact assessment, life cycle records and monitoring evidence. Start by listing the products customers actually buy, then decide whether internal tools or prototypes belong in the scope or are excluded with a written justification in the statement of applicability. Narrowing the scope to the paid product line is usually the single largest lever. Confirm with your certification body how it expects scope boundaries to be described before you commit.

Training models or calling model APIs

A team that trains or fine-tunes its own models owns controls for data sourcing, training data quality, model validation and release decisions, which are the heaviest parts of the Annex A life cycle and data areas. A team that only calls third-party model APIs carries lighter life cycle obligations but must document the model vendor relationship, the prompts and configuration it controls, and how it responds when the vendor changes the model. Decide this before drafting the statement of applicability, because it changes which controls are excluded.

Customer data processed by AI

Personal data and customer content that flow into prompts, training sets, logs or retrieval stores widen the data controls and the impact assessment. Map each data category to the AI feature that uses it and record where it is stored and for how long. Teams that keep customer data out of training and limit retention to what the feature needs will carry a smaller evidence burden. Where personal data is involved, check privacy obligations alongside the standard, since ISO/IEC 42001 does not replace them.

Locations and cloud accounts

Each cloud account, region, office or device fleet that hosts AI workloads adds access reviews, logging, backup and configuration evidence to the audit. A startup with one production account and infrastructure defined as code can show consistent evidence quickly. Several accounts with manual setup, shared credentials or developer laptops holding production data increase both the work and the audit risk. Consolidating accounts before the project starts is often cheaper than documenting the sprawl afterward.

Third-party AI suppliers

Every model provider, labeling service, vector database host or hosted evaluation tool that touches your AI systems needs supplier selection, contract and monitoring records under the third-party controls. Count the suppliers, note which ones process customer data, and collect their security and AI governance documents before the audit. A supplier that holds its own certificate still needs your review of what that certificate covers. Ask your certification body how it expects supplier evidence to be sampled.

Maturity of existing documentation

Written policies, risk registers, change tickets and incident records that already exist shorten the project considerably, but only if they are current and match how the team actually works. Startups often have good engineering practice that lives in chat threads, pull requests and memory. A gap analysis against clauses 4 to 10 and the Annex A controls shows which records must be created and which can be adapted. Confirm during planning how much of that work the implementation partner or the internal team will carry, since this is the main driver of effort.

Start certification now, prepare first, or wait

This table compares three paths for an AI startup: pursuing accredited certification now, running a readiness and gap assessment before deciding, or building the management system informally and deferring certification. Read each row against your own contracts, buyer pressure and runway, and note that the main takeaway is that the first two paths both produce evidence you will need anyway.

Decision factor	Certify now	Readiness assessment first	Build informally, defer certification
Best fit	A signed contract or RFP sets a certification deadline, or enterprise buyers require a certificate	Buyers ask about AI governance but no deadline is fixed, or the team is unsure what scope to certify	Early-stage product with no enterprise buyers and no contractual requirement yet
What it commits the team to	A defined scope, a completed statement of applicability, operating controls with records, an internal audit and management review before stage 2, and a certification body contract	Time from the team to map features unique to AI, draft the statement of applicability and identify gaps, with no obligation to certify afterward	Ongoing internal discipline with no external audit date, which can drift if nobody owns the AI policy and records
Evidence produced	Audit-ready records such as the AI policy, impact assessments, risk treatment decisions, supplier reviews and internal audit results, reviewed by an independent auditor	A gap list and draft evidence set that shows what is missing, useful for planning and for answering customer questions	Internal documents and decision logs that help with questionnaires but carry no independent assessment
Who issues the outcome	An accredited certification body, after stage 1 and stage 2 audits (ISO does not certify organizations)	Nobody external issues an outcome unless you engage an assessor for a separate report	Nobody external; the organization's own statements are the only record
Effect on the three-year cycle	Starts a three-year certification cycle with at least one audit in every calendar year, so annual audit fees recur from the start	Defers the cycle; the readiness work becomes the input to a later certification decision	No certification cycle until you choose to start one
Main risk	Certifying a scope that is too broad or too thin, or running stage 2 before controls have operated long enough to show evidence	Treating the gap assessment as a substitute for implementing controls, or delaying the decision past the point a buyer needs it	Customers or procurement teams reject the answer because no independent evidence exists
What to confirm first	The certification body's quotation, its audit day count, and whether its accreditation covers ISO/IEC 42001	Whether a readiness assessment can be scoped in writing and whether its output is kept independent from the certification body	Which customer questions are likely in the next contract cycle and whether those answers depend on certification

Focus ISO 42001 on the features unique to AI

ISO/IEC 42001 expects an organization to point its governance at the features that make AI different from ordinary software, such as continuous learning and limited transparency or explainability. A model that changes its behavior after deployment, or whose reasoning a team cannot fully trace, can need safeguards that a conventional workflow performing the same task would not. For a startup, the practical first step is to list each AI feature and ask what about it is new: does the model retrain on customer data, does its output drive a decision that is hard to explain, or does a small team rely on a third-party model it cannot inspect? Those answers decide where the controls under A.6 (life cycle), A.7 (data) and A.9 (use) need the most attention.

The introduction describes a risk-based approach: the organization applies the level of control that fits each AI use case, product or service within scope, and balances governance against innovation. A startup needs that balance. Each AI product or internal tool should get a documented risk and impact assessment, and the depth of that work should follow the risk. Confirm the scope boundaries and the expected assessment depth with your certification body before you commit, because its reading of the scope shapes the evidence it will ask for. The statement of applicability under clause 6.1.3 is where the reasoning for each control is recorded.

The following example is illustrative only. A startup has two AI features: a customer-facing ranking model that orders search results and an internal tool that summarizes meeting notes for staff. The team scopes the ranking model heavily, with a full impact assessment, data provenance records for its training data, logging of model changes, and monitoring for drift. The summarization tool gets a lighter assessment covering acceptable use and data handling, with its supplier controls drawn from the vendor's documentation. Both decisions are justified in the statement of applicability, so an auditor can see that the effort follows the risk rather than being uniform.

Which Annex A controls a startup can exclude, and how to justify each

Clause 6.1.3 requires a statement of applicability that lists the controls an organization needs and justifies including or excluding each of the 38 Annex A controls. The cards below cover the exclusion decisions AI startups raise most often, and what an assessor will expect to read and see for each one.

Development life cycle controls after a model API call

A startup that only calls a third-party model through an API still has to decide how much of the A.6 life cycle set applies. The justification should state that the company does not train, fine-tune or host the model, and which parts of design, verification and deployment it still performs on its own prompts, retrieval layer and application code. Evidence usually includes the architecture description, the list of models in use, and the release records for the features that wrap them. Confirm with your certification body how they expect scope to be drawn around the vendor boundary.

Data acquisition when no training data is collected

If the company does not collect or prepare training data, the A.7 acquisition and preparation controls may not apply in the same form, but data handling for prompts, retrieval sources and evaluation sets still does. The justification should describe exactly what data enters the system, where it comes from and whether any of it is retained or used to improve a model. Evidence can include data flow diagrams, retention settings and a short register of data sources. An assessor will test whether the exclusion matches what the system actually does, so re-check the justification whenever a new data source is added.

Third-party supplier controls for model vendors

Controls in A.10 on managing suppliers of AI products and services are rarely excludable for a startup built on external models. The statement of applicability should show how the company selects, reviews and monitors each model provider, and which responsibilities the contract allocates. Evidence includes signed terms, the vendor's documentation on data use and incident notice, and a record of the periodic review. A vendor's certificate alone does not show how the startup itself uses the model, so the justification should address that gap directly.

Impact assessment controls for early products

The A.5 impact assessment controls ask the organization to assess effects on individuals, groups and society. A pre-revenue product with few users may argue for a lighter process, but it should still document the intended use, foreseeable misuse and affected groups. The justification must explain why the scale of the system makes a full assessment disproportionate, and the risk-based approach in the standard allows that reasoning. Evidence includes a completed assessment template, dated review notes and a trigger list for when reassessment is required.

Public sector and regulated use controls

Controls in A.8 on information for interested parties and A.9 on responsible use may apply more widely once customers operate the product in regulated settings. A startup should not exclude them merely because its product is early, since the customer contract often requires the information. The justification should record which user documentation, incident communication and intended-use statements exist. Evidence includes the user documentation set, the customer notice process and a record of the intended purpose stated in contracts.

Written reasons for every exclusion

Each excluded Annex A control needs its own written reason, linked to a named owner and a review date. Blanket exclusions with no reasoning are the most common reason a statement of applicability is questioned in audit. The statement should show that excluded controls were considered, the reason they do not apply to the system in scope, and the trigger that would bring them back into scope. Confirm the format and level of detail your chosen certification body expects before drafting the document.

What certification costs a startup, and who gets paid

This table lists each cost component of an ISO 42001 certification, who is paid for it, whether it is one-time or recurring, and what drives it up or down. Use it to compare written quotes line by line, because the certification body's audit days are the cost most startups cannot estimate from published sources.

Cost component	Who is paid	One-time or recurring	What drives the cost, and what to request in a quote
The standard itself	ISO (sold through its online store)	One-time purchase	ISO/IEC 42001:2023 is sold at CHF 225. Bundles with ISO/IEC 27001:2022 (CHF 340) or ISO/IEC 42005:2025 (CHF 365) each give a 10% discount on separate prices. Confirm current prices on ISO's site before budgeting.
Companion documents	ISO or other publishers	One-time, unless you need updates	Buy only what your statement of applicability and risk method require. Ask whether ISO/IEC 23894:2023 or ISO/IEC 42005:2025 are needed for your scope, and record the reason in your planning file.
Certification body audit fees	Accredited certification body	Recurring across the three-year cycle	Fees follow each body's quotation, because ISO/IEC 42006:2025 sets competence rules but no audit day counts. Ask for stage 1, stage 2, each surveillance audit, recertification, and travel, with the audit days for each stage shown separately.
Implementation partner for readiness and evidence	Consultant or implementation partner	One-time for readiness, plus any retained support	Scope depends on how many AI systems are in scope, how much documentation exists, and how much of the policy and impact assessment work your team writes. Request a fixed-scope deliverables list with the evidence each deliverable produces, and confirm that the partner will not issue the certificate.
Governance and monitoring tooling	Software vendors or open-source hosting in your own cloud	Recurring (hosting, licenses, maintenance)	Costs rise with the number of AI systems, data sources and evidence repositories. Ask which tools produce audit evidence automatically, and which are manual exports.
Internal staff time	Your own team (paid through payroll)	Recurring, mostly in the first cycle	Engineering, product, legal and data owners must review impact assessments, log records and internal audits. Plan named owners and hours per month, and confirm who signs the AI policy.
Internal audit and management review	Internal staff or an outside reviewer	Recurring each year	Clause 9 requires internal audits and management review, which you must run before the certification audit. Ask whether an outside reviewer is needed, and what the review will cost in your planning.
Three-year cycle	Spread across the certification body's fee schedule	Planned across three years	European Accreditation FAQ 51.7 says the cycle is three years and the certificate shows its end date, so fees are usually planned across that period. ISO/IEC 17021-1 requires at least one audit in each calendar year (European Accreditation FAQ 37.12), so budget a yearly audit line, not only a first-year cost.

How a startup moves from scope to certificate

The sequence turns a decision to adopt ISO/IEC 42001 into an independently issued certificate. Each step ends with a document or check the team can point to, so progress is visible before the certification body arrives.

Buy and read the standard
Start by buying ISO/IEC 42001:2023 from ISO or the IEC Webstore and reading it end to end, including Annex A and Annex B. The founder or head of engineering, with someone who owns security or legal, should read clauses 4 to 10 first, since they set what the management system must do. The output is a short internal note listing the clauses, the Annex A controls the team expects to touch, and the questions that need an answer before scoping. The step is done when every owner has read the standard and agreed on those questions.
Define scope and the AI systems within it
Name the organization's AI systems that fall inside the management system, such as a model feature in the product, an internal assistant, or a fine-tuned model used in a customer workflow. Record each system's purpose, the data it touches, who builds it, and who relies on its output. The output is a scope statement and an inventory of AI systems, reviewed against the features unique to AI that the standard asks the team to focus on. The step is complete when the inventory is signed off by the person accountable for the product.
Write the AI policy and risk-based approach
Draft the AI policy that sets management direction, then decide how the team will assess risk and impact for each system so controls match the use case rather than applying every control to everything. Link the policy to any existing security or privacy policies the startup already maintains. The output is an approved AI policy, a risk assessment method, and assigned roles for AI governance. The step is done when leadership has approved the policy and named the people who own each responsibility.
Build the statement of applicability
Work through the Annex A controls and decide, for each one, whether it applies to the scoped systems. Clause 6.1.3 requires the organization to justify including or excluding each control, so a control left out must have a reason tied to the startup's actual role, for example a development control that does not apply to a team that only calls a third-party model. The output is a statement of applicability with a justification for every control. The step is done when the team can explain each exclusion to a reviewer without referring back to a rule of thumb.
Collect evidence and run the internal audit
Gather the records that show each included control operating: impact assessments, model and data documentation, evaluation results, supplier reviews, change records, and access logs. Then run an internal audit against the management system clauses and the statement of applicability to find gaps. The output is an evidence register that maps each control to its records and an internal audit report with corrective actions. The step is complete when the team has closed or formally accepted each finding.
Hold the management review
Leadership reviews the state of the AI management system, including audit findings, changes in AI systems, incidents, and objectives, and decides what to change. The review should be recorded with decisions and owners. The output is minutes that show top management reviewed the system and approved any changes to scope, policy, or controls. The step is done when those minutes exist and the corrective actions from the internal audit have owners and dates.
Complete the stage 1 document review
Select an accredited certification body and agree on the audit plan. In stage 1, the auditor reviews the documented management system, including the scope, AI policy, statement of applicability, and records of the internal audit and management review. The team should expect questions about how each excluded control was justified. The output is the auditor's stage 1 findings, which usually list documentation gaps to fix before stage 2. The step is done when the team has addressed those gaps and the auditor agrees to proceed. Confirm the certification body's stage 1 and stage 2 process and audit days in its written quotation, since the standard does not set them.
Pass the stage 2 implementation review and certificate decision
In stage 2, the auditor tests whether the system operates as documented by sampling evidence, interviewing staff, and checking AI systems against their records. Any nonconformities must be corrected and verified. The certification body then makes an independent certification decision. The output is either an issued certificate that shows the scope and the date the three-year cycle completes, or a list of required actions before a decision. ISO and the startup do not issue the certificate; only the accredited certification body does.

What the three-year audit cycle means for a small team

Under ISO/IEC 17021-1, the certification cycle for an ISO/IEC 42001 certificate runs three years, and the certificate must show the date that cycle completes. The certification body must also carry out at least one audit, which may be a surveillance or recertification audit, in every calendar year of the cycle. For a small team this means the first certificate is not a one-off event. The audit calendar is a standing commitment for three years, and the startup should plan its staffing and budget around that rhythm from the first stage 2 audit onward.

Between audits, the team has to keep the management system running as a working process. That includes internal audits of the AI management system, a management review where leadership looks at AI risks, incidents, objectives and audit findings, and corrective actions that close any nonconformities. The statement of applicability must be updated whenever an AI system changes, such as a new model, a new training data source or a new customer-facing use. A startup that ships quickly should assign one named owner for these records, because stale documentation is one of the first things a surveillance auditor will test.

Fees should be planned across the full cycle, not only the initial audit. Ask each certification body for a quotation that separates the stage 1 and stage 2 audits, the annual surveillance audits, the recertification audit and any additional audit days for a scope change. Audit days are set by each body's own quotation, because ISO/IEC 42006:2025 adds AI-specific requirements for certification bodies but does not set audit time rules. Confirm that the body holds accreditation for ISO/IEC 42001 under its national accreditation body before signing, since accreditation for this scheme is voluntary and the body's scope will show whether it covers AI management systems.

Who does what: the founders, the implementation partner and the certification body

The organization owns its AI management system, and that ownership does not transfer to any outside party. Founders or a named senior lead must approve the AI policy, decide how risk is treated, and sign off on the statement of applicability, which lists the Annex A controls the company needs and justifies including or excluding each one under clause 6.1.3. Clause 5 expects top management to take visible responsibility, and Annex A.3 expects defined AI roles and a route for raising concerns about AI systems. In a small team these roles often sit with the same two or three people, which is acceptable if the assignments are written down.

AI policy: Approve a written AI policy and review it on a schedule the company sets.
Statement of applicability: Decide which Annex A controls apply, and record a reason for every exclusion.
Risk decisions: Accept, reduce or avoid AI risks, and record who made each call.
AI roles: Name owners for model development, data, customer-facing use and incident response under A.3.
Concern channel: Set up a simple way for staff and customers to raise problems with an AI system.

Before engaging any partner, confirm that someone inside the company can explain every control in the statement of applicability without reading it from a consultant's document.

ISO 42001 for startups: questions founders ask before hiring help

Does a startup need ISO 42001 if it only calls third-party AI APIs?

Not automatically, but the standard applies to any organization, regardless of size, that provides or uses products or services that use AI systems. If your product ships a feature that calls a third-party model, you are inside scope, because you provide that feature to customers. Scope follows what you build and sell, not how large the team is. Your statement of applicability then lists the Annex A controls you need and justifies every control you exclude. A company that uses AI only for internal operations usually has a narrower scope, with the responsible use and supplier controls doing most of the work. Confirm with your intended certification body how it reads your role, since a startup wrapping a model vendor's API is both a user and a provider of the feature it ships.

How much internal time does ISO 42001 take a small AI team?

The time depends on how many AI features you ship, how many model vendors you depend on, and how much documentation and information security work already exists. Most of the effort falls into a few areas: an AI policy, impact assessments for each use case under the risk-based approach, supplier records for model vendors, technical documentation, event logging, internal audit and management review. Someone must own the system and make decisions on risk, which usually means a founder, engineering lead or security lead spending recurring time on it. No figure for hours is set by the standard, so ask your certification body and any implementation partner to estimate effort in writing against your specific product list and existing evidence.

Can a small team implement ISO 42001 without outside help?

Yes, a small team can build the management system itself, and the standard does not require a consultant. The practical question is capacity: someone must write the policies, run impact assessments, keep evidence current and prepare for audit while still shipping product. Outside help is optional and is most useful for the first pass, when the team is unsure how to justify exclusions or structure evidence. If you hire help, keep the roles separate. The organization owns its controls, an implementation partner prepares systems and evidence, and only an independent certification body issues the certificate. Avoid any arrangement in which the firm that wrote your system also acts as your certifier.

How does the three-year cycle affect budgeting for a startup?

The certification cycle runs for three years under ISO/IEC 17021-1, and the certificate shows the date the cycle completes, so plan fees across that period rather than only at the first audit. Each calendar year of the cycle must include at least one audit, whether surveillance or recertification, so audit costs recur. One-time costs include readiness work and the initial two-stage audit. Recurring costs include surveillance audits, recertification, internal audit, tool subscriptions, staff time and extra work when you add new AI features that expand scope. Ask the certification body for its quotation covering all three years, including the audit days it plans each year, because the standard does not set those days.

What does a customer mean when it asks for an accredited ISO 42001 certificate?

It means the certificate was issued by a certification body whose accreditation covers ISO/IEC 42001, not only a certificate that looks official. Accreditation is voluntary, and ISO/IEC 42006:2025 adds AI-specific competence requirements for bodies that certify AI management systems. Check the accreditation body's published scope directly. The Global ACI status document for version 3.3 does not list ISO/IEC 42001 as an endorsed sub-scope, unlike ISO/IEC 27001, so do not assume international recognition. Also confirm that the certificate's scope covers the product the customer buys and that the cycle end date is shown.

Can a startup combine ISO 42001 with ISO 27001?

Yes, the two standards share the harmonized structure for clauses 4 to 10, so policy, context, risk assessment, competence, documented information, internal audit and management review can often be run once for both. The AI-specific parts stay separate, including impact assessment, data provenance and the life cycle controls. ISO sells ISO/IEC 42001:2023 with ISO/IEC 27001:2022 as a package for CHF 340, which ISO presents as a 10% discount on the separate prices. Ask your certification body whether it audits both standards together, how that affects audit days and fees, and whether it follows Global ACI's guidance on integrated audits.

What should a startup ask for in an implementation partner's quote?

Ask for a written scope that names the AI products in scope, the Annex A controls in the statement of applicability and the exclusions with their justifications. Request a list of deliverables, such as the policy set, impact assessment templates and the evidence register, along with the tasks the startup must do itself. Confirm what is excluded, who owns each control after handover, and whether certification body fees and audit days are separate line items. Ask about support and retainer terms for changes after certification, and get a written statement of independence from the certification body. DeployOpen does not publish prices and provides a quote from written scope.

How DeployOpen prepares a startup's ISO 42001 evidence

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside a client's own infrastructure. For an AI startup, we help set up the systems and records that ISO 42001 asks to see, while the organization owns its controls and an independent certification body makes the certification decision.

How we scope

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
We help define which AI products, features and environments fall inside the AI management system boundary.
We review the draft statement of applicability with you so each Annex A exclusion has a written justification.
Pricing follows from the written scope, and we do not publish a price list.

How we build

We set up open-source tooling in your own cloud accounts or data centers to keep AI governance records.
We document AI system inventories, impact assessment records and data provenance in formats your team can maintain.
We run security testing of AI applications, APIs and agents so the results can serve as evidence for relevant controls.
We configure logging and event records for AI systems where your architecture supports it, and confirm each setting with your engineers.

How we hand over

You receive documentation, configuration records and runbooks written so your own staff can operate and update them.
We walk your team through where each piece of evidence lives and who is responsible for refreshing it.
We prepare the evidence pack for the independent auditor, but the auditor selects its own samples and issues any report or certificate.
Ownership of AI governance stays inside your organization after handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial scope is complete.
A retainer can keep evidence current between surveillance audits, which must happen in each year of the certification cycle.
Before choosing a certification body, ask each one for its own audit time quotation, since audit days vary by body.
We can support recertification preparation when your three-year cycle approaches, scoped in writing like any other engagement.

ISO 42001 for AI startups: when to start and what to expect