.svg){kind=logo}
The questionnaire came in on a Thursday afternoon. The VP of Sales forwarded it to the CISO. The CISO forwarded it to the compliance lead. The compliance lead forwarded it to the engineering lead. The engineering lead replied: 'This is about governance, not code.' The compliance lead replied: 'I know. I don't have these documents.' The questionnaire sat unanswered for eleven days.
That forwarding chain is not a communication failure. It is a documentation failure. Each person in the chain recognized that the questions required artifacts their organization had not built. The questionnaire did not ask about the product. It asked about how the product's AI systems were governed. And nobody in the chain owned that answer.
Enterprise procurement teams at regulated buyers have been refining their AI governance questionnaires since 2023. The questions are no longer asking whether you have responsible AI principles. They are asking for evidence that an AI Management System is operating. Responsible AI principles are table stakes. The questionnaire is testing for what exists behind them.
An enterprise AI governance questionnaire is a vendor due diligence document that tests whether a software vendor operates an AI Management System, not whether they have an AI policy. The two are structurally different. A policy describes governance intent. An AI Management System produces auditable evidence that the intent is operational. Regulated enterprise buyers now distinguish between the two, and their questionnaires are built around that distinction.
We review enterprise AI governance questionnaires as part of readiness sprint engagements. Three structural categories appear in every questionnaire we have seen, regardless of the industry the buyer operates in. Understanding what each category is actually testing changes how you approach the response.
The first category is the one most companies answer reasonably well. Procurement wants to know whether AI governance has a named owner at the leadership level, whether there is a documented process for AI-related decisions, and whether leadership has formally approved the governance program.
Your responsible AI policy satisfies most of this category. The AI ethics charter, the executive sign-off, the governance committee documentation — these exist in most companies that have made any effort toward AI governance. The response is not complete, but it is not empty.
What often fails this category is specificity. Procurement teams do not want to know that AI governance is 'overseen by the CISO and the legal team.' They want to know who specifically owns AI risk assessment, who is responsible for reviewing AI system changes, and who makes the call when an AI system produces an output that requires a governance response. Named owners, not job families.
This is the easiest category to fix. The work is clarification, not construction.
The second category is where most companies hit the wall. Procurement wants AI risk assessments. Not a general AI risk framework. Specific documented assessments tied to the specific AI systems the vendor is deploying.
Under ISO/IEC 42001:2023, Clause 6 requires a documented, repeatable AI risk assessment process with per-system entries: defined inputs, evaluation criteria, risk treatment decisions, and an assigned owner per system. The output is a risk register that shows, for each AI system in scope, what risks were identified, how they were assessed, and what was done about them.
Most companies have not built this register. They have a risk management policy that says AI risks will be assessed. That is not the same as an assessment. The policy describes the intent to run the process. The register shows the process was run.
When procurement receives a policy in response to a question about AI risk assessments, they send a follow-up asking for the per-system documentation. That follow-up is where most deals go into extended holding patterns. The company cannot produce what was not built.
The third category is the most specific and the one that eliminates the most vendors from consideration. Procurement wants to see per-system impact assessments: documented evaluations of each AI system's purpose, operational complexity, data sensitivity, and potential impacts across the system lifecycle.
This maps directly to ISO/IEC 42001 Clause 8.2. An organization with three AI systems in production needs three impact assessments, one per system. Each assessment covers what the system does, who it affects, what data it processes, what happens when it fails or produces harmful outputs, and what controls are in place.
Think of it as a structural inspection report for each AI system. You would not accept a building permit application that cited general safety principles without inspecting the actual building. Enterprise procurement is applying the same logic to AI systems. The general governance framework is the principles. The impact assessment is the inspection report for the specific system.
An organization with no impact assessments cannot answer this category. An organization with assessments for some but not all of its in-scope systems answers it partially, which creates a different problem: procurement can see that the governance program exists but is incomplete.
A complete response to an enterprise AI governance questionnaire is a package, not a set of individual document submissions. It answers all three categories with artifacts, not descriptions of artifacts.
Category One: A named governance accountability table showing the owner of each AI governance function by name and role. A copy of the governance policy with leadership sign-off. A description of the decision-making process for AI system changes and incident responses.
Category Two: The AI risk assessment register with per-system entries. Each entry shows the system assessed, the methodology applied, the risks identified, the treatment decisions made, and when the assessment was last updated. The register itself is evidence that the process ran.
Category Three: The per-system impact assessments. One per AI system in scope. Each covering purpose, complexity, data sensitivity, potential impacts, and the controls in place. These are not short documents, but they do not have to be long ones either. The substance matters more than the length.
Category Four, which appears in more sophisticated questionnaires: evidence of an active audit cycle. Internal audit findings from the past twelve months. Management review records showing the governance program is being monitored at the leadership level. This is Clause 9 of ISO/IEC 42001. Organizations without a functioning internal audit cycle cannot produce this evidence, and sophisticated procurement teams ask for it.
That full package is what ISO/IEC 42001 readiness produces. Not as a response assembled the week the questionnaire arrived. As the operational output of a governance program that was already running.
The most common failure mode is sending the policy in response to questions that require the management system. The second most common failure mode is sending documentation that exists for some AI systems but not others, which tells procurement that the governance program is incomplete. The third is sending documentation that was clearly assembled in response to the questionnaire, not produced by an ongoing process.
Procurement teams see all three patterns regularly. They have developed a working ability to distinguish between a vendor whose governance documentation was produced by a running management system and a vendor whose governance documentation was produced by a consultant the week before the questionnaire response was due.
The difference is specificity. A risk register produced by an actual ongoing process contains entries that reflect the history of those systems: when each was assessed, what changed between assessments, what risk treatment decisions were revised and why. A risk register produced as a questionnaire response has clean, consistent entries with no revision history. The pattern is visible.
The fastest path is not to build every component before the questionnaire arrives. For a company facing an immediate deal, the AI Governance Questionnaire Sprint maps the specific questionnaire against your current documentation baseline, identifies which questions can be answered with existing materials, which gaps require new documentation, and which gaps require process work that cannot be rushed.
The sprint produces a response package for the current deal and a gap list that prioritizes what needs to be built before the next questionnaire. For companies further from a deal and building proactively, the full ISO/IEC 42001 readiness program builds the complete management system so every future questionnaire is a documentation exercise, not a scramble.
InterSec is ISO/IEC 42001:2023 certified. The advisory team built and operated an AIMS under audit conditions before working with clients on theirs. That means the documentation formats, the risk register structures, and the impact assessment templates are derived from real implementation experience, not policy templates.
Enterprise procurement teams are testing for three things: named accountability for AI governance at the leadership level, documented AI risk assessments tied to specific AI systems, and per-system impact assessments for each AI system the vendor deploys. Sophisticated questionnaires also ask for evidence of an active internal audit cycle. A responsible AI policy satisfies the first category partially. It does not produce evidence for the second, third, or fourth.
Most AI governance questionnaire responses fail because vendors send policy documents in response to questions that require management system artifacts. When procurement asks for per-system AI impact assessments and receives a responsible AI policy, they follow up asking for the actual assessments. That follow-up is where deals enter extended holding patterns. The vendor cannot produce what was not built. The deal waits.
ISO/IEC 42001 readiness produces the specific artifacts that answer enterprise AI governance questionnaires: the AI risk assessment register with per-system entries (Clause 6), per-system impact assessments covering purpose, complexity, and data sensitivity (Clause 8.2), and internal audit findings with closure records (Clause 9.2). These documents answer the questionnaire directly and completely rather than describing the intent to have them.
For a company with an active deal, an AI Governance Questionnaire Sprint takes three to eight weeks depending on the current documentation baseline. For companies with existing risk management infrastructure or NIST AI RMF alignment, the sprint can produce a response-ready package in three to five weeks. For companies building from scratch, four to eight weeks is more realistic. Full ISO/IEC 42001 AIMS readiness runs four to eight months.
If an enterprise AI governance questionnaire is stalling a deal right now, the AI Governance Questionnaire Sprint is the right starting point. If you are building proactively before the next questionnaire arrives, the ISO 42001 readiness assessment maps what needs to be built and in what order. Either way, reach out to InterSec to start the conversation.
Expert Cybersecurity Solutions for Federal, State and Commercial Organizations
