In 2027, the first wave of mid-market certifications against ISO/IEC 42001:2023 — the international standard for AI management systems — will begin landing. Most audit firms standing up AI assurance practices are pricing these engagements as "ISO 27001 plus 30 percent."
That's wrong. The actual complexity drivers in an ISO 42001 audit are different from 27001, and getting the scope wrong creates audit risk that no margin can repair.
This guide is for partners and senior managers at audit firms standing up an AI assurance practice. It walks through how to scope an ISO 42001 engagement, the five questions that determine its complexity, the hidden drivers that wreck engagement margins, and what defensible pricing should look like.
This is Part 2 of a four-part series. Part 1 set up the mid-market demand picture for 2027. Part 3 walks through evidence sampling discipline. Part 4 covers the 2027-2030 AI audit market and how firms will differentiate.
Why ISO 42001 scoping is harder than ISO 27001
ISO 27001 sets a relatively bounded scope. The information security management system is generally co-extensive with the organization's IT environment, and the audit firm has reasonably stable models for estimating effort: counting in-scope systems, mapping data flows, sampling controls.
ISO 42001 is different. The standard is structured the same way — same harmonized backbone, similar Annex A control catalogue — but the unit of audit is more variable. The scope of an AI management system can range from "we have one ML feature in our product" to "we have dozens of agentic systems across multiple business units, several of which are customer-facing." The effort delta between those two scenarios is an order of magnitude. Pricing them similarly is a path to either losing the bid or losing money on delivery.
There are also requirements in ISO 42001 that don't have direct 27001 analogues:
- The AI system impact assessment (Annex A) — a distinct exercise from risk assessment, requiring evaluation of what the AI does to affected parties.
- Information for affected parties (Annex A) — the per-decision explanation requirement that materializes when AI affects individuals.
- Third-party model governance (Annex A) — the requirement to evaluate and document foundation-model dependencies that the standard does not allow you to offload to the model provider.
Each of these adds work that ISO 27001 templates won't capture. Scoping ISO 42001 well, therefore, requires answering questions that ISO 27001 didn't force.
Five scoping questions that determine engagement complexity
1. How many AI use cases are in scope?
The first scoping question is not "how many AI systems do you have?" It is "how many AI use cases do you operate?"
A single deployed model can serve multiple use cases (a fraud-detection model used in both customer onboarding and recurring transactions). A single use case can involve multiple deployed models (an agentic customer support workflow may invoke a classifier, an LLM, a retriever, and a safety filter). The unit of audit is the use case, not the model.
Defensible scoping starts with a use case inventory: every AI-supported business process, the inputs it consumes, the outputs it produces, the people or systems affected by those outputs. Engagement complexity scales with this count.
A practical rule of thumb: a 100-person company with one in-scope use case is a different engagement than a 100-person company with eight. Pricing them off head count produces engagement-margin disasters.
2. What's the deployment pattern?
The deployment pattern drives the depth of technical audit work required.
- Traditional ML deployments (single model, batch or real-time inference, deterministic given inputs) map most closely to existing audit models. Each use case is one or two systems to walk through.
- Single foundation model deployments (an LLM invoked via API, with prompt templating) add foundation-model governance work but remain bounded.
- Compound or agentic deployments (multiple models, tools, retrievers, conditional flow per decision) multiply audit effort. A single use case may involve a dozen instrumented components, each with its own version history, change records, and evaluation artifacts.
A scoping conversation that doesn't surface the deployment pattern produces estimates that are off by 50% or more.
3. Are there foundation-model dependencies?
ISO 42001 requires third-party governance regardless of whether the third party is a SOC 2-certified SaaS vendor or a foundation-model API. But the audit burden differs.
For foundation models, the audit firm needs to verify that the client has:
- Evaluated the model (not just accepted the vendor's SOC 2)
- Captured records of the evaluation
- Monitored model behavior over time — foundation-model providers change underlying model behavior with each API update, and the client's risk acceptance must keep pace
- Documented contractual terms specifically addressing AI use
None of this work has a clean ISO 27001 analogue. Surfacing it during scoping prevents it from becoming an unbilled scope creep item during delivery.
4. Are there affected-party requirements?
The standard requires that AI systems making decisions affecting people produce information explaining those decisions to the affected parties. This is heaviest in B2C contexts — credit, hiring, insurance, content moderation — but also applies in B2B contexts where the AI affects end users (an HR SaaS product that screens candidates on behalf of its customers' hiring teams, for example).
The affected-party requirement drives the depth of evidence the auditor will need to sample. A use case that affects no individuals can be audited at the system level. A use case that affects individuals requires per-decision evidence: a sample of specific decisions, with the records of how those decisions were produced, available for the auditor to walk through.
Many B2B clients assume their AI doesn't affect individuals because their customers aren't individuals. But their customers' employees and end users frequently are. Scoping this dimension out without explicit client acknowledgment is one of the more common scoping mistakes — and one of the more expensive ones to discover mid-engagement.
5. Is this a readiness assessment or a certification audit?
Readiness assessments and Stage 1/Stage 2 certification audits have different effort profiles. A readiness assessment can be scoped tighter — the auditor's role is to identify gaps and recommend remediation, not to issue an opinion. A Stage 2 certification audit requires sufficient evidence to support certification, which generally means more sampling, longer fieldwork, and more documentation of audit procedures.
Most firms standing up AI assurance practices in 2026 are leading with readiness assessments. The transition to Stage 2 audits will demand more rigor and should be priced accordingly. A readiness engagement that grandfathers into a Stage 2 audit without re-scoping is a margin compression event for the firm.
The hidden complexity drivers
Three complexity drivers tend to materialize during fieldwork that are easy to miss during scoping.
Dynamic prompts and runtime configuration
Many production AI systems compose prompts dynamically from runtime context — user input, retrieved documents, system state. The prompt that runs at audit time is rarely the prompt that was reviewed at deployment. Auditors need to sample actual production prompts, not template prompts, to verify operation. This requires capture infrastructure most clients don't yet have.
Vendor opacity for foundation-model internals
The client's evidence of foundation-model governance ends at the API boundary. Auditors should expect to evaluate the client's foundation-model risk acceptance, not the foundation model itself. This is a different kind of audit work than auditing a client-owned model; firms that haven't anticipated it may struggle to write defensible audit procedures.
Affected-party evidence retention
Many production AI systems do not retain per-decision evidence at audit-relevant time scales. The auditor's evidence sample may need to be pulled from short-retention observability platforms (LangSmith, Langfuse, Datadog) or application logs, not from systems designed for audit retention. Surfacing this during scoping allows the engagement to include either an evidence-extraction phase or a recommendation for the client to build retention before Stage 2.
Pricing math
Public benchmarks for ISO 42001 audit pricing in 2026 are scarce. The following framework is based on conversations with practitioners across mid-market audit firms standing up AI assurance practices.
Base pricing anchor
Use the firm's existing ISO 27001 day rate and effort estimate as the anchor. For a mid-market client with one to three in-scope AI use cases, traditional ML deployment pattern, no foundation-model dependencies, and no affected-party requirements — the simplest possible ISO 42001 scope — the effort is comparable to a comparable ISO 27001 engagement plus 15-25% for AI-specific work.
Multipliers by complexity dimension
Each scoping question above acts as a multiplier on the base effort:
These multipliers compose. An ISO 42001 certification audit for a mid-market client with five compound-AI use cases serving consumers, with two foundation-model vendors, might land at 4–6× the cost of a comparable ISO 27001 audit. Firms pricing this engagement at "ISO 27001 + 30%" will lose money or under-deliver.
Pricing posture in the early years
In 2026-2027, scarcity favors premium pricing. Firms with credible AI assurance practices can price at the top of their day-rate band. By 2028-2029, as more firms develop practices, pricing pressure will increase — but firms with mature methodology, established evidence procedures, and industry specialization can defend margin against latecomer competition.
This pricing trajectory is covered in more depth in Part 4 of this series.
Engagement letter considerations
Scope language to include
- A definition of "AI use case" the client and auditor agree on
- An enumeration of in-scope use cases by name
- A statement that foundation-model governance is in scope (or carved out, if the client elects to address it in a future engagement)
- A statement that affected-party explanation evidence is in scope (or that the engagement is limited to system-level evidence)
- Provisions for compound-AI complexity: that the auditor's evidence procedures may need to extend to per-decision sampling if the deployment patterns require it
Common scope creep risks
- Mid-engagement discovery of additional AI use cases not surfaced during scoping (the engineering team's "oh, we also use AI for that")
- Mid-engagement discovery of foundation-model dependencies not surfaced during scoping
- Mid-engagement discovery of inadequate evidence retention, requiring either remediation (client side) or expanded evidence-extraction procedures (auditor side)
Exit clauses
For Stage 1/Stage 2 engagements, an exit clause for technical infeasibility — where the client's AI infrastructure cannot produce evidence the auditor can sample — protects the firm from issuing an opinion it cannot support. The exit clause should reference specific evidence-production capabilities, not vague qualitative criteria.
Common scoping mistakes
Including too much
The instinct to scope broadly to maximize fees can backfire. Wide scope means more findings, more delivery time, and more risk of issuing an opinion the client disputes. Tighter, defensible scope tends to deliver better margins and stronger client relationships.
Excluding foundation-model governance
A scope that excludes foundation-model governance because "it's the vendor's problem" misses a substantive ISO 42001 requirement. The standard makes the operator responsible. Scoping the requirement out — without explicit client acknowledgment — risks an audit opinion that doesn't actually attest to what the client believes it attests to.
Missing the affected-parties dimension
B2B clients often assume their AI doesn't affect individuals. A scoping conversation that doesn't surface this dimension can produce an audit opinion that omits a material requirement.
Treating compound AI like traditional ML
Agentic use cases require different audit procedures and produce different evidence demands. A scoping exercise that doesn't differentiate them creates effort estimates that are systematically wrong.
Conclusion
ISO 42001 audits cost more than ISO 27001 audits because the unit of audit is more variable, the technical work is deeper, and the requirements that have no 27001 analogue — impact assessment, affected parties, third-party model governance — demand real procedural time. Scoping well sets up an engagement that delivers within margin. Scoping poorly creates audit risk that no markup can repair.
In Part 3 of this series, we'll walk through what to actually sample once the engagement is scoped: the evidence procedures, the sampling discipline, and the common findings to expect in the 2027-era AI assurance audit.
Build the evidence layer your engagements will demand
ISO 42001 engagement margins live or die on evidence access — and most mid-market clients in 2026 don't yet produce evidence at the granularity the standard implies. vCISO Lite is the integrated platform that sits between your client's AI infrastructure and your audit opinion: structured evidence collection, controls linkage, and retention discipline that turns "we can't sample that" into "here's the sampling worksheet."
If you're scoping ISO 42001 engagements for the 2027 wave, or building the readiness practice that feeds into Stage 2, visit vcisolite.com to learn more and get started.
Where this matters next
Platform: Published Pricing — vCISO Lite's transparent rate card as the anchor for benchmarking ISO 42001 audit scope + pricing conversations.
Platform: APRI (AI-Powered Risk Intelligence) — the MCP surface that a well-scoped 42001 audit would test against.
Where this matters next
The First AI Audits Hit in 2027. Most Mid-Market Companies Will Fail Them. — In 18 months, a new generation of audit opinions will start landing in mid-market boardrooms
EU AI Act Article 12: What AI Logging Requirements Mean for Audit Firms and Their Clients — EU AI Act Article 12 is already applicable to high-risk AI systems newly placed on the EU market
The 2027-2030 AI Audit Market: How Assurance Firms Will Differentiate — By 2030, the firms that started early will have shaped how AI assurance is delivered
How often is your compliance AI actually right? — Every vendor pitching an 'AI compliance agent' makes the same promise — set it loose on your controls and it will attest while…