Case: Twelve Months to a 42001 Certificate at a 900-Person SaaS Firm
An enterprise customer’s procurement demand starts the clock: a gap analysis that shrank 40% to 15%, a scoping fight, four versions of the SoA, a stage 1 near-miss, and two minors at stage 2 — with honest numbers throughout.
A composite teaching case: realistic fiction assembled from well-documented public patterns — not a real engagement.
The setup. Marloway is a composite: a 900-person B2B SaaS company selling a customer-support platform, with three AI features that actually matter commercially — ticket triage and routing, drafted replies for human agents, and conversation summarisation with QA scoring. Solid compliance hygiene for its size: ISO/IEC 27001 certified, annual SOC 2 Type II, a four-person GRC team inside security.
The trigger was a contract, not a conviction. Marloway’s largest prospect — a European bank, a ~$2.1M ARR expansion — sent an AI due-diligence questionnaire with 148 questions, and its procurement team put a line in the MSA: ISO/IEC 42001 certification within 12 months, or a termination right. The CTO became executive sponsor the day that redline arrived. Every 42001 story needs a sponsor with something to lose; a deal number works better than a values statement, and it is worth being honest about that.
The plan was straightforward on a slide: gap analysis in month 1, build for six months, internal audit and management review, stage 1 around month 9, stage 2 by month 11, certificate before the contractual deadline. Almost none of it happened on schedule.
The gap analysis — the 40% that was 15%. The GRC lead’s opening estimate, repeated to the exec team, was that the 27001 ISMS gave them ‘about 40% of 42001 for free’ — both are Harmonized Structure management systems, clauses 4–10 rhyme, and the document-control, internal-audit, and management-review machinery already existed. A 15-day consultant engagement mapped every 42001 clause and all ~38 Annex A controls against existing evidence. The honest number was closer to 15%.
What transferred: the management-system skeleton — document control, the internal audit function, management review cadence, supplier-management process shape, competence and awareness plumbing. What did not: essentially everything with ‘AI’ in it. There was no AI policy, no determination of the organisation’s role (provider? producer? user? — Marloway turned out to be all three for different systems), no AI risk assessment distinct from enterprise security risk, no impact assessments at all, no lifecycle documentation standard for models, no data-provenance records for fine-tuning sets, and supplier contracts that said nothing about model change notification. The 27001 machinery could carry those things. It contained none of them.
| Area | What we assumed | What held up |
|---|---|---|
Clauses 4–10 machinery | ‘Same Harmonized Structure — mostly done.’ | The process shells reused cleanly (doc control, internal audit, management review). Every shell still had to be filled with AI-specific content: context, role determination, AI objectives. |
Risk assessment | ‘Extend the ISMS risk register with an AI category.’ | Partially. The method transferred; the risk sources did not — fairness, transparency, automation level, ML-specific failure modes had no home in a confidentiality-integrity-availability register. |
Impact assessments (A.5) | ‘Our DPIAs cover this.’ | No. DPIAs covered personal-data processing for two features; 42001 wants system impact assessment on individuals, groups, and societies. Nothing existed. This became the internal-audit finding later. |
AI lifecycle documentation (A.6) | ‘Engineering has design docs.’ | Design docs existed for services, not models: no documented verification and validation criteria, no deployment gates for model changes, no event-log spec for AI decisions. |
Data for AI (A.7) | ‘Data governance is mature.’ | For production data, yes. For training and fine-tuning data — acquisition records, quality criteria, provenance — nothing. ‘We don’t train models’ turned out to be false: two features used fine-tunes. |
Suppliers (A.10) | ‘Vendor management is SOC 2-tested.’ | The process ran; the content was wrong. Model-provider contracts had no AI-specific clauses — this became one of the two stage 2 minors. |
The scoping fight. Three meetings, one memo, and the only genuinely political episode of the programme. Sales wanted the certificate to say Marloway, Inc. — the whole company — because that is the logo slide procurement teams like. The GRC lead wanted the smallest defensible scope. Engineering leadership wanted whichever option created the least process for teams not shipping AI. The certification body, consulted early (worth doing — scope statements are negotiable before contract, awkward after), pointed out that under ISO/IEC 42006 auditors are expected to be precise about scope wording, so vagueness would not survive anyway.
The deciding move was asking the customer. One call with the bank’s procurement team established that a certificate scoped to ‘the design, development, and operation of the AI capabilities of the Marloway platform’ satisfied the MSA clause. Weeks of internal argument, resolved by twenty minutes of asking the party the exercise was for.
Whole company
The logo option. Every department in scope, every process auditable. Cost: AI-awareness training, role determination, and audit sampling across 900 people, most of whom never touch a model. Rejected when the consultant priced the extra audit days and the GRC lead priced the extra evidence surface — roughly double, for no additional customer value.
AI platform org + features (chosen)
The AI platform group (61 people) plus the three customer-facing AI features, with documented interfaces to corporate functions — HR supplies competence records, security supplies the ISMS controls, legal supplies contract review. The interfaces matter: an auditor will follow a dependency out of scope far enough to check the interface is real (they sampled HR training records through exactly this door).
Single flagship feature
Certify ticket triage only — smallest possible surface, fastest path. Rejected because the bank used all three features, and because a scope that gerrymanders around your own products invites exactly the procurement follow-up questions the certificate exists to end.
The SoA that went through four versions. The Statement of Applicability — the document declaring which of the ~38 Annex A controls apply, with justifications for inclusion and exclusion — became the programme’s honesty meter. Its version history is the case study in miniature:
v0.1 — the template (month 2)
Downloaded skeleton, every control marked applicable, justifications copy-pasted from control titles. Produced in a week, worth nothing. Its one virtue: it existed, so people could start disagreeing with it.
v0.2 — the consultant cut (month 4)
Real applicability decisions. Several controls excluded with the justification ‘Marloway does not train models’ — including data-provenance and training-data-quality controls under A.7. Nobody had yet asked engineering whether that sentence was true.
v0.3 — after internal audit (month 8)
Internal audit tested justifications against evidence and found the A.7 exclusions rested on a false premise: two features used fine-tuned models, and fine-tuning data is training data. Controls re-included; provenance records built retroactively for both fine-tuning sets — two painful weeks of git-archaeology and S3 forensics.
v0.4 — after stage 1 (month 10)
The stage 1 auditor challenged two remaining exclusions and, more usefully, the pattern: justifications described intentions (‘will be addressed by…’) rather than facts. Final version: every inclusion pointing at named evidence, every exclusion stating a present-tense fact about the business. This is the version that should have existed at v0.2, and everyone knew it.
The internal audit that earned its keep. Clause 9.2 requires internal audit before certification, and Marloway’s was real rather than ceremonial — mostly because the ISMS internal auditor, borrowed from security, treated the AIMS with the scepticism of someone who had seen paper systems fail. Her headline finding: the three AI impact assessments were templates wearing costumes. Same risk list, same mitigations, whole paragraphs identical across all three features; one still referred to a product name retired in 2024. They had been produced by one person in an afternoon to make a checklist go green.
The rework was three half-day workshops, one per feature, with product, engineering, support operations, and legal in the room. And the process — annoyingly, for everyone who had called it bureaucracy — caught something real: the QA-scoring feature was being used by at least one customer to feed performance reviews of their human support agents. An employment-adjacent use of a feature designed for coaching, with impacts on people who were not Marloway’s users and had never been considered. Product added contractual use restrictions and an in-product disclosure; the impact assessment stopped being a form and became the reason the exercise existed.
Stage 1 — the near-miss. The certification body (accredited for 42001, with ISO/IEC 42006:2025 governing its audit-team competence) ran stage 1 in month 10: a readiness review of documentation, scope, and whether the management system was actually operating. The documentation passed. The operating history nearly didn’t: policies approved five weeks earlier, one management review ever held, internal audit closed eleven days before the auditor arrived, and several controls whose only evidence was the procedure describing them. The stage 1 report listed six areas of concern, all variations on one sentence: documented, but not yet demonstrably operating.
A certification-body auditor cannot certify a system that has not run. Marloway pushed stage 2 back seven weeks — eating most of the contractual buffer — to accumulate operating evidence: a second management review with real decisions minuted, incident and change records flowing through the new AI lifecycle gates, monitoring dashboards with weeks of history, training completions logged. Nothing new was built in those seven weeks. The system simply ran, observably. That is what stage 2 buys evidence of.
Stage 2 — two minors. Month 12, five auditor-days: interviews across the platform org, evidence sampling against the SoA, and the traceable thread auditors love — pick a model change, follow it from risk assessment through approval, deployment, monitoring, and the event log. Marloway’s thread held. Two minor nonconformities:
- Training records (clause 7.2 / A.4 competence). AI-specific training had been assigned to all 34 in-scope engineers; completion evidence existed for 29. Five gaps, including one team lead. Minor because the process existed and mostly ran — nonconformity because ‘mostly’ is not a conformity state.
- Supplier clause gaps (A.10). Marloway’s own supplier policy required AI-specific provisions — including notification of material model changes — in model-provider contracts. Two of four such contracts, both predating the AIMS, lacked them. The auditor’s point was precise: the nonconformity was not the vendors’ paperwork but Marloway failing its own stated control.
Corrective-action plans were accepted within 30 days (training completions closed in two weeks; the contracts fixed at renewal with interim risk acceptance signed by the CTO), and the certificate issued — scoped, as negotiated, to the AI capabilities of the platform. Eleven days before the MSA deadline.
| Item | Cost | Notes |
|---|---|---|
Programme lead | ~0.8 FTE × 12 months | A senior GRC manager, near full-time from month 3. The single biggest success factor and the single biggest key-person risk (see below). |
GRC / compliance support | ~0.5 FTE-year | Evidence wrangling, SoA drafting, audit logistics, training administration. |
Engineering time | ~0.6–0.9 FTE-year, spread thin | Lifecycle documentation, event logging, provenance reconstruction, workshop attendance — spread across ~40 engineers, which is why nobody budgeted it and everybody felt it. |
Consultancy | 30–35 days · $80k–$120k | Gap analysis, SoA reviews, pre-stage-1 readiness check. Worth it for the first certification; the goal is to not need them for surveillance. |
Certification body | $30k–$45k initial (stage 1 + 2) | Plus $12k–$18k/yr surveillance and a recertification audit in year 3. Scope drives audit days; audit days drive fees. |
Tooling | $10k–$20k incremental | Modules on the existing GRC platform plus evidence-automation glue. No dedicated AIMS product was purchased; the spreadsheet era lasted longer than anyone admits. |
Total | ~$130k–$200k cash + ~2 FTE-years internal | Over 12 months. The internal time is the real cost and the one most estimates omit. |
What the certificate changed — and didn’t. The bank signed; the $2.1M expansion closed with the certificate attached as an MSA exhibit. In the following two quarters, sales cited it in eleven enterprise deals, and the GRC team estimated it now pre-answers roughly two-thirds of a typical AI due-diligence questionnaire — the large customers still send the remaining third, plus their own security addenda, because procurement teams trust their questions more than anyone’s certificate. It moved deals; it did not end diligence.
Two things broke after the champagne. In month 14, a voice-support feature shipped outside the certified scope — nobody on the product team thought to ask, because scope lived in a PDF, not in the launch checklist. The first surveillance audit flagged it as an observation and the scope-extension paperwork consumed a quarter. And in month 16 the programme lead resigned; the AIMS visibly wobbled for two months — evidence collection slipped, one management review nearly skipped — until the clause 9.3 management-review cadence itself forced the gap onto the exec agenda and a successor was named. A management system you cannot lose one person from is a person, not a system; Marloway learned that the standard had been right about why management reviews exist.