How a SaaS firm would prepare for ISO/IEC 42001 in six weeks

A US mid-market SaaS firm had an existing SOC 2 Type II report and had been running two production AI features for about a year: an automated reply suggester inside its support product, and a lead scoring and routing layer in its sales module. AI work had always sat in a product roadmap conversation, not a compliance one. That changed inside a single quarter.

Three things arrived at once. An enterprise prospect in financial services sent a 62-question AI vendor assessment during procurement, with a question about ISO/IEC 42001 posture that read "certified, in progress, or planned by date" and offered no fourth option. The board, after reviewing a competitor's annual report that mentioned ISO/IEC 42001 certification, asked when the firm would be ready. And a UK customer with EU operations flagged that under the AI Act implementation timeline, they would need evidence of a managed AI governance system from their vendors by their own next audit cycle.

The firm had six weeks before the enterprise RFP response was due. Six weeks is not a certification window. Nobody certifies in six weeks. But six weeks was enough to be audit-ready in a defensible way: enough to answer the questionnaire honestly, point to an evidence trail that already existed, and give the board a credible path to a Stage 1 audit within the fiscal year. This case study walks through what that six weeks of work actually looked like.

The obvious fix was to write policies. Draft an AI acceptable use policy, an AI governance charter, a risk assessment template. This is where most organizations start and most organizations stop, and it is the wrong instinct because policies are not what an experienced ISO/IEC 42001 auditor spends time on.

What the auditor spends time on is evidence that the AI management system operates. A policy is a one-paragraph starting point: your team has written down how it says it works. The audit tests whether reality matches the policy. That test is almost always done by sampling: show me the risk assessment for this specific AI system; show me the impact assessment for the model that touches customer data; show me the written basis for why this human-in-the-loop step was removed; show me the log entries from the week of October 7th. The policy document is barely consulted. The companion [ISO/IEC 42001 readiness checklist](/blog/iso-42001-readiness-checklist-ai-management-system) lists what the auditor does read.

The firm's second instinct, after policy drafting, was to buy a GRC platform. This is also not where readiness lives. A GRC tool is a filing cabinet. It can store policies, risk registers, and evidence, but if the AI systems themselves do not produce evidence as they run, the tool holds a drawer of past decisions and no current state. The audit will flag the gap. The firm already had this problem with its SOC 2 renewal: AI-touched evidence was being assembled by hand from Slack messages and spreadsheets at audit time, which is the pattern [AI governance before the audit](/blog/ai-governance-before-the-audit) argues against.

The six-week target was never certification. It was to answer three audiences from the same evidence trail. The enterprise questionnaire needed a defensible answer in a week. The board needed a credible six-month path to a Stage 1 audit by the end of the fiscal year. The AI Act timeline needed a mapping that showed where the firm's AI governance work would land against its risk-tier obligations.

Translated into operational terms, four things needed to be true at the end of six weeks. First, a current and continuously maintained AI system inventory, covering both the two production AI features and the AI tools employees used inside their workflow. Second, documented AI risk assessments and AI impact assessments for each of those systems, in version control, with a named person who accepted the residual risk. Third, operational controls on each system that produced evidence as they operated, not evidence assembled after. Fourth, a Statement of Applicability draft against ISO/IEC 42001 Annex A, with every reference control marked in or out and justified.

Those four artifacts answer most of what a Stage 1 audit evaluates, which is a design review of the AI management system. They are also the four artifacts the enterprise questionnaire and the AI Act both ask for in different wording. Readiness, done this way, is the same work done once that pays three audiences at the same time.

The six-week scope held four workstreams running in parallel, with weekly joins to keep them aligned. One workstream owned the AI system inventory and kept it live. One owned the risk and impact assessments and the Statement of Applicability. One owned operational controls on the production AI systems themselves. One owned the evidence pipeline that routed logs, approvals, and overrides from the production systems into a queryable store.

The architecture decision that mattered most was where the inventory and the evidence trail would live. We decided early that both would be code-adjacent rather than tool-adjacent. The inventory sat in the same monorepo as the AI feature code, with a schema check in CI that failed any pull request introducing a model call or an external AI service without a matching inventory entry. The evidence pipeline wrote structured records from the two AI features into a queryable store the compliance team could access read-only.

The policies and the Statement of Applicability lived next to the code too, in a governance directory in the same repository, as versioned markdown. This is not where most governance consultancies would recommend putting them. It is also the only arrangement that stays current when the code changes, because the pull request that changes the AI system is also the pull request that updates the policy, the inventory, and the Statement of Applicability.

Week one was discovery. The inventory workstream pulled every outbound call to an LLM API, every embedding index, and every piece of AI tooling the team ran, from the codebase, from employees' browser extensions, and from vendor contracts. Four systems the firm had not formally listed appeared in that week: a sales-ops copilot a product manager had set up inside a vendor platform, a developer-facing code review assistant the engineering team ran against pull requests, a marketing copywriter in a third tool, and an automated note-taker on the customer success team's calls. None of these had been in anyone's mental model of "our AI." Each was now in the inventory.

Weeks two and three were risk and impact assessments. For each of the six systems now on the inventory, two artifacts were written: a security-focused risk assessment adapted from the firm's existing ISO 27001 methodology, and a separate AI impact assessment covering effect on individuals and groups. The impact assessment is where ISO/IEC 42001 diverges from ISO 27001 the hardest. For the lead scoring feature, that meant documenting what happens when the model under-scores leads from a demographic the training data under-represents, who would notice, how, and what the escalation path was. The output was a plain-English written basis per system, kept with the code.

Weeks four and five were operational controls. For the two production AI features, we added runtime policy checks: input validation on anything crossing into the model, output filtering on anything the model generated that touched a customer, confidence thresholds for human escalation, and override logging whenever a human corrected a model output. We also added rollback testing: a quarterly tested path to disable each AI feature in production in under a minute. The log output from each control routed into the evidence store with a schema stable enough to query a year later.

Week six was the Statement of Applicability and the write-up. The 38 Annex A reference controls, organized across nine control objectives, were walked one by one. Each was marked applicable or not applicable with a one-paragraph justification, cross-referenced to the inventory entry, risk assessment, impact assessment, or runtime control that evidenced it. The result was a document a certification body auditor could read and know where every claim was anchored.

The underlying architecture had four components and no new vendor commitments at the center. The AI system inventory was a typed registry in version control, with each entry carrying the system's purpose, data sources, model vendor and version, decision scope, human oversight step, lifecycle stage, named owner, and references to its risk and impact assessments. A CI check prevented adding or materially changing an AI call path without updating the entry.

The evidence pipeline wrote three event types from each production AI system into a durable store: decision records (what input, what output, what model version, what confidence, what human review flag), approval records (who overrode what and why), and health records (the control checks that ran against each decision and their results). The store was the firm's existing data warehouse with a schema the compliance team could query without engineering support, and retention was set to the longer of seven years or whatever the enterprise contracts eventually required.

The runtime controls lived in the AI features themselves. For the support reply suggester, that meant a classifier that routed any suggestion mentioning account closure, refunds, or legal to a human review queue before the agent saw it. For the lead scoring feature, that meant an audit flag on any lead score within a configurable band around the routing threshold, and a monthly review of override patterns to detect scoring drift. These are not generic guardrails. They were designed from each system's impact assessment and are specific to the harms that system can plausibly cause.

The governance repository completed the picture: policies as markdown, Statement of Applicability as a structured document generated from the inventory and the risk register, management review minutes as commits. The whole AIMS lived in files you could diff. That mattered, because an audit asks for change history and version control gives it for free.

Three parts of the work resisted the first pass and had to be re-done. The first was distinguishing the AI risk assessment from the AI impact assessment. Teams coming from ISO 27001 want to merge them, because 27001's risk assessment feels like it covers the same ground. It does not. The risk assessment asks what can go wrong for the organization. The impact assessment asks what can go wrong for the people the system touches, including people who are not customers. For the lead scoring feature, the risk assessment caught data lineage and prompt injection concerns. The impact assessment caught the harder question: whose leads will be systematically under-scored because of training data shape, and what recourse do they have. The first draft of the impact assessment conflated the two and had to be rewritten.

The second hard part was the Statement of Applicability justifications. Marking a control "not applicable" is where auditors spend the most time, because it is where organizations hide. The firm had initially marked several controls on supplier AI governance as not applicable because it did not build models from scratch. That answer failed the first internal review: every system on the inventory used a vendor LLM, which is third-party AI, which triggers the supplier governance controls. The justifications were rewritten to say applicable with specific vendor due-diligence evidence pointed to.

The third hard part was evidence of model drift and performance monitoring over time. Auditors increasingly ask for this specifically, and six weeks is not long enough to produce a year of monitoring data. The honest answer, and the one that worked, was to show the monitoring system running from a defined start date, with the methodology documented and the first data points visible, and to commit in writing that the Stage 1 audit was being pursued at the point where the monitoring record would be long enough to be meaningful.

A governance system that does not degrade gracefully is a liability. The architecture had two reliability properties that mattered. First, every automated AI decision had a human escalation path triggered by a confidence threshold, an output content check, or a usage-pattern anomaly. The lead scoring feature escalated near-threshold scores. The reply suggester escalated anything mentioning policy-sensitive topics. The escalation path logged the trigger reason so that over time the thresholds could be tuned from evidence.

Second, every system was reversible. A rollback path from the AI version to the non-AI version was defined for each feature and tested quarterly. The rollback was not a disaster-recovery procedure. It was a routine operation, because the single most common question in an AI audit is what happens if the model is wrong, and the only credible answer is a reversible system. Rollback testing produced evidence as a byproduct: a quarterly log entry showing the path exercised in production.

Overrides were a first-class concept, not a bug. When a human corrected an AI output, the correction was logged with the user, the timestamp, the before state, the after state, and a reason code. The log was queried monthly for patterns, because clustered overrides are the earliest signal that model behavior is drifting against reality. This answered a Stage 2 question before it was asked, and it is the pattern [that firm's successful audit](/blog/passed-first-ai-governance-audit) also relied on.

Making the AIMS something the firm could operate past the six weeks took three deliberate productionization choices. The inventory, the risk register, the impact assessments, and the Statement of Applicability were all tied to CI, so a pull request that introduced an AI change could not merge without the governance artifacts also moving. This made drift between code and governance a build failure rather than an audit finding.

Monitoring and alerting routed to the engineering team on-call rotation, not to a compliance inbox. The AI control checks ran continuously, and a failure, say a confidence threshold not firing or an override log missing, was an incident. This matched the engineering team's existing playbooks and prevented AI governance from being parked as someone else's problem.

Change management was explicit: a model vendor change, a prompt change, or a threshold change required a reviewed pull request, an updated inventory entry, and a re-reviewed risk and impact assessment. Not every change needed a full rewrite; most required a diff. The git history became the change log that the Stage 1 audit asked for, and the three-year certificate cycle (with annual surveillance audits at roughly a third of the initial audit effort) would read from the same source.

At the end of six weeks the firm was not certified. It was something more useful in the moment: audit-ready in a defensible way. The enterprise RFP question about ISO/IEC 42001 posture was answered with "AI management system implemented and operating; Stage 1 certification audit scheduled for Q2 next fiscal year," with pointers to specific evidence. The response was accepted and the deal progressed to the next stage without a vendor security exception.

The board question had a credible answer backed by a running system. The Stage 1 audit was not six weeks away, because operational control evidence has to accumulate before an audit can sample it meaningfully, but it was credibly within the fiscal year, and nothing was going to slip because the artifacts were already live.

The AI Act mapping was straightforward because the AI impact assessments had been written in language that the Act's higher-risk obligations could consume. The companion piece on [EU AI Act obligations by risk tier](/blog/eu-ai-act-compliance-obligations-by-risk-tier) walks through the mapping. The sales-ops team's enterprise questionnaire backlog, which had been averaging a week of security engineering time per custom AI question, dropped to answers assembled in hours because the evidence already existed in queryable form.

What the firm owned, at the end of six weeks: a monorepo containing the AI system inventory, the policies, the risk and impact assessments per system, the Statement of Applicability, the governance repository with its management review log, and the runtime control code in the production AI features. The evidence pipeline wrote into the firm's existing data warehouse, under the firm's existing access controls. There were no new vendor contracts and no new tooling with a renewal date.

The firm also owned the operating cadence: the quarterly management review template with required inputs listed, the quarterly rollback-testing script, the monthly override-pattern review template, and the schema check that gated changes to AI systems in CI. These were documents the compliance team and the engineering team already knew how to run.

What Stallwart retained no ownership over: the certificate itself (which no consultancy issues; it is granted only by an accredited certification body after Stage 1 and Stage 2), the risk acceptance (which has to be a named firm employee signing), and the Statement of Applicability justifications (which have to represent the firm's actual position, not ours). Our role was to build the artifacts and the architecture; the firm has to be the firm that runs them.

Three things from this engagement generalize to other mid-market AI governance work. First, the inventory is almost always wider than the firm's mental model of its AI footprint. The two production AI features were known. The four unlisted systems that appeared in week one were the actual exposure, and the pattern has been consistent across every readiness engagement we have run.

Second, the AI impact assessment is the artifact that distinguishes an AI governance program from a security program with AI stickers on it. Teams that have gone through ISO 27001 struggle with impact assessments because the training is wrong: 27001 asks what happens to the organization, 42001 asks what happens to the people the system touches. The second question is harder, the answer is more useful, and the audit will not accept the first in place of it.

Third, the policy layer is a trap in reverse. Teams underestimate how fast they can draft policies and overestimate how long the operational controls take. The actual time proportion is almost exactly inverted. Policies were about ten percent of the six weeks. Operational controls, evidence pipelines, and Statement of Applicability justifications were about seventy percent. Risk and impact assessments were twenty.

If your organization is in the same bind this firm was in, with a near-term AI governance deadline and no AIMS, six weeks is enough to be audit-ready and not enough to be certified. The honest sequence is readiness first, then certification on the timeline the standard actually permits, which is a Stage 1 documentation review, a gap of typically four to twelve weeks, and a Stage 2 operational effectiveness audit on the running system.

If you are earlier in the cycle, the earlier you start the better. The evidence trail is cheaper to produce as a byproduct of operating the AI systems than as a sprint before Stage 1, and the audit itself is less eventful when the artifacts have been living through six months of change rather than six weeks of assembly.

Stallwart does not issue ISO/IEC 42001 certificates. No consultancy does. We build the inventory, the risk and impact assessments, the Statement of Applicability, the runtime controls, and the evidence pipeline a Stage 1 and Stage 2 audit will ask you to produce. If an enterprise RFP, a board question, or an AI Act timeline is pressing, the readiness work is the first move, and the certificate follows the audit cycle on its own schedule.