A GenAI vendor security review need not be a new puzzle every time. One published GenAI vendor questionnaire groups its questions into categories including data privacy, model training, information security, nth-party risk and legal compliance. A vendor selling to several enterprises should build one reusable, procurement-grade evidence pack, map it once to SOC 2 and ISO/IEC 42001, back it with a traceability record of release decisions, and keep the sub-processor disclosure as a separate, versioned document.
TechnoLynx offers the AI Readiness Scorecard as its assessment offer on this path.
What a GenAI vendor security review covers, and what the reviewer wants to see
A GenAI vendor risk assessment workbook for financial institutions splits its vendor questionnaire into seven categories: general discovery; data privacy, retention and deletion; model training, validation and maintenance; information security; technology integration; nth-party risk; and legal, regulatory and compliance. A checklist for bank assessments covers similar ground and adds AI-specific security testing and commitments to notify the buyer of model changes.
The key question is not whether you have an AI policy. Guidance from NHIMG frames the real question as whether the vendor can show how customer data is handled at each stage, from prompt ingestion through storage, retrieval, logging and output generation. The same guidance names the most common failure as assuming that “no training” means “no risk”, when data can still leak through logs, prompt history, retrieval indexes or cross-environment access. Its decision rule is concrete: where the AI feature can process sensitive customer data, require a documented data-flow map and a testable retention and access model before broad use.
Version 10 of Microsoft’s Supplier Data Protection Requirements, implemented on 23 September 2024, added a Section K of 18 AI requirements. Microsoft stated it would issue no new purchase orders, and allow no data processing by vendors using AI, until those vendors met Section K and completed an independent assessment where applicable. Under its Supplier Security and Privacy Assurance programme, work for a new supplier cannot start until the compliance cycle is complete.
How do buyers run a vendor risk assessment on a GenAI supplier?
Published onboarding checklists cover steps like these, from risk classification through to ongoing monitoring. Knowing that order tells you what to have ready, and when.
| Step | What the buyer does | Evidence it asks of the vendor |
|---|---|---|
| 1. Risk tiering | Assigns the vendor a tier by data sensitivity, system access and regulatory context; the tier sets the depth of diligence | A clear statement of what data the product touches and where it flows |
| 2. Questionnaire | Sends a questionnaire scaled to risk; FS-ISAC’s workbook offers three cumulative due-diligence levels | Completed answers, each backed by a document rather than an assertion |
| 3. Attestation review | Checks SOC 2 Type II for exceptions, asks for a bridge letter if the report is over twelve months old, confirms certificate scope | SOC 2 Type II report, bridge letter, ISO certificates with scope statements |
| 4. Subservice check | Where a SOC 2 report uses the carve-out method, requests the cloud host’s or model provider’s own report | Sub-processor list naming the model provider and host |
| 5. Contract | Turns answers into terms: no-train commitment, model-change notice, sub-processor disclosure, audit rights | DPA, security addendum, flow-down to sub-processors |
| 6. Go-live sign-off | Records every diligence step and document; that record is the buyer’s evidence for SOC 2 CC9.2 | Nothing new, if steps 1 to 5 were complete |
| 7. Reassessment | Re-reviews at renewal, on model provider or sub-processor changes, new data connections and incidents | Updated documentation and change notices |
Step 7 matters for GenAI because AI products change quickly. A vendor’s behaviour can change after signing through model version updates and sub-processor model swaps, so a one-time onboarding review does not cover the risk that the deployed model is not the one evaluated.
Is there a standard GenAI security questionnaire we can pre-fill?
Three published templates are worth pre-filling against. The Cloud Security Alliance’s AI-CAIQ is a set of questions mapped to its AI Controls Matrix, intended for self-assessment or third-party vendor evaluation. That matrix holds 247 control objectives across 18 security domains and maps to ISO 42001, ISO 27001 and BSI AIC4. Since 23 October 2025, CSA’s STAR for AI Level 1 lets a vendor publish its AI-CAIQ self-assessment to the STAR Registry.
The second is a workbook for financial institutions, customisable to each institution’s risk appetite. The third is a checklist mapped to EU AI Act Articles 25 and 26, ISO 42001 supplier controls and standard third-party risk workflows.
A sound approach is to treat the AI-CAIQ as the master answer set, because its mapping to ISO 42001 means one set of answers feeds the framework mapping as well, then derive FS-ISAC and bespoke questionnaires from it. A published self-assessment also gives a buyer something to check before the first call.
Which frameworks should a GenAI evidence pack map to: SOC 2, ISO 42001, or both?
Both, kept distinct and cross-mapped, because they prove different things.
SOC 2 proves controls operated
The SOC 2 Trust Services Criteria are the AICPA’s control criteria: 33 Common Criteria, CC1 to CC9, that every SOC 2 report covers, plus optional criteria for availability, processing integrity, confidentiality and privacy. Two criteria bear on model releases and suppliers. CC8.1 requires changes to infrastructure, data, software and procedures to be authorised, documented, tested and approved, and auditors usually sample changes and look for a ticket, an approval and test evidence for each. CC9.2 covers assessing and managing vendor risk through a vendor inventory, scheduled assessments and contract security terms.
SOC 2 does not verify AI governance. Knowlee’s 2026 comparison notes that it does not assess whether training data was collected lawfully, whether an AI inventory with risk classification exists, or whether AI impact assessments were done.
What ISO/IEC 42001 adds
ISO/IEC 42001, published in December 2023, is a certifiable management-system standard for AI. Its Annex A lists 38 reference controls in nine areas; using all of them is not mandatory, and the organisation records which apply in a Statement of Applicability produced by its risk treatment. The requirement that most separates it from a security standard is the AI system impact assessment: clause 6.1.4 sets the process, and clause 8.4 requires it to be performed at planned intervals and on material change, with results retained. Certification runs through a Stage 1 documentation review and a Stage 2 operational audit, and the certificate lasts three years with annual surveillance audits.
Buyers do accept it as a shortcut: Microsoft accepts ISO 42001 certification in lieu of an independent assessment against its AI requirements, and requires it outright for suppliers delivering AI services that involve “sensitive use”. ISO 42001 has limits, though. Certification shows a conforming management system; it does not establish EU AI Act conformity for a given high-risk system until harmonised standards under Article 40 are published. Nor does it say anything about the specific system a buyer is procuring, its logging or its contract terms.
Mapping once, answering many
A 2026 arXiv paper on unifying AI governance frameworks argues that organisations can run a single control library and evidence base while respecting each framework’s distinct obligations. Its output is one cross-framework control register that can be shown, with suitable framing, to a certification auditor, a counterparty checking NIST alignment and an EU market-surveillance authority. CSA’s control-by-control mapping of the AI Controls Matrix to ISO/IEC 42001, with pointers to ISO/IEC 27001 and 27002, helps spot governance gaps and gives one reference across them.
What goes in a reusable GenAI evidence pack
This table is the pack, component by component, with the limit a reviewer will apply to each.
| Component | What it shows | Maps to | What it does not prove |
|---|---|---|---|
| SOC 2 Type II report plus bridge letter | Specific controls operated over a period, including failures | SOC 2 CC1 to CC9 | AI governance or training-data practice |
| ISO 27001 certificate and Statement of Applicability | An audited security management system, within a stated scope | ISO 27001 Annex A | That the product in question is in scope, unless the scope says so |
| ISO 42001 certificate, status, or a written description of how model changes are evaluated and outputs tested before release | AI governance, risk and impact assessment | ISO 42001 Annex A, AI-CAIQ | EU AI Act conformity for a given system |
| Model documentation and lineage record | Model details, data provenance, evaluation data, underlying foundation models and versions | ISO 42001 data and lifecycle controls | Anything about versions it was not updated for |
| Release-decision record | What changed, the test results, who approved | SOC 2 CC8.1 | More than the release process actually captured |
| Data-flow map with retention and access model | The path from prompt to output and where data persists | Buyer data-privacy section | Implementation, unless backed by operational controls |
| Standard terms on retention and model training | The commitments the vendor will sign | Contract step of the buyer’s review | The buyer’s own deployment controls |
Worked example: a pack as a buyer reads it
One published example of a real-world pack contains a SOC 2 Type II report covering 1 January to 31 December 2025 for security and availability, with an unqualified opinion and two exceptions, both in change management and both with fixes described. Alongside it sit an ISO/IEC 27001:2022 certificate valid to 2028 and scoped to the product platform, no ISO 42001 certificate but a two-page description of how model updates are tested, and a sub-processor list naming a cloud host and a model provider, both carved out of the SOC 2 report.
A reviewer reads three things from that. The change-management exceptions point at CC8.1, so the release-decision record is where the vendor answers the obvious follow-up. The carve-outs mean the buyer must fetch the host’s and model provider’s own reports, which large model providers offer through trust portals. The model-testing note stands in for ISO 42001 and will be read more sceptically than a certificate. Sending all of it in one request matters, because the same source notes that piecemeal requests take weeks.
Release-decision traceability is what static documents cannot supply
NIST AI 600-1 suggests setting minimum performance and assurance thresholds as part of go/no-go deployment approval, and sharing pre-deployment test results with those who hold release approval authority. An audit-trail guide from Openlayer lists model versioning records (every change to weights, architecture, hyperparameters and training data) as a core record category, and warns that a model card describing the current version but not the one running during an incident six months ago is useless as evidence.
A bank-focused checklist says to verify contractual notice of model version changes, with a window long enough for the buyer to revalidate before the change reaches production.
Teams without data lineage, evaluation rationale or deployment sign-offs cannot reconstruct a conformity trail after the fact. Producing those records from pipeline artefacts in the first place is covered in our piece on generating defensible evidence packs for regulatory and procurement review, which goes into the generation mechanics this page leaves out.
Why the sub-processor and data-flow disclosure is a separate artefact
The DPA, not a certification, is the legal instrument that creates binding commitments on sub-processor controls. Under GDPR Article 28(3)(d), the contract must bar sub-processors without the controller’s prior specific or general written authorisation, require notice of intended changes with a chance to object, and impose the same obligations on each sub-processor. GDPR does not define the notice period; Scrut’s 2026 guide notes many DPAs set it at 30 days. When a product sends customer data to an LLM API, that provider is a sub-processor and belongs on the list.
Three reasons argue for keeping it apart from the security pack. Every DPA and privacy notice should reference one authoritative, versioned and timestamped list. That list records each sub-processor’s name, location and nature of processing, and a change to it triggers a notice-and-objection workflow. Buyers vet sub-processor lists during procurement, and a stale disclosure can stall a deal.
Healthcare buyers add a layer: a vendor handling Protected Health Information for a HIPAA-covered entity needs a Business Associate Agreement. Before assuming the whole product falls under that regime, check which data flows actually carry regulated data.
Which compliance requirements apply to the vendor itself
Processing personal data of EU data subjects for a controller makes a DPA mandatory under GDPR Article 28. Article 28 also requires the contract to oblige the processor to allow and contribute to audits by the controller or its appointed auditor. SOC 2 and ISO certifications verify the vendor’s internal practice, while the DPA creates the binding commitments.
When the full pack is worth building, and what keeps it current
If many enterprise reviews are in the pipeline, build the pack now and map it once; if a single deal is in view, a lighter one-off response may be the better use of time. A workable build order is:
- Scope: inventory internal, customer-facing and third-party AI, and match the scope to the services buyers procure.
- Pull in existing SOC 2 and ISO 27001 evidence and check that their scope covers the product.
- Generate the model documentation, lineage and release-decision records from the pipeline.
- Answer the AI-CAIQ, whose questions map through the AI Controls Matrix to ISO 42001.
- Publish the versioned sub-processor list and data-flow map.
Keep it current on the same triggers buyers use for reassessment: renewals, major feature changes, model provider changes, sub-processor updates and security incidents. Framework mappings need the same care, since the ISO 42001 certification ecosystem is still maturing.
Two limits stay with any reusable pack. The financial-sector workbook is not a universal solution; it is designed to be customised to each institution’s risk appetite. And the pack holds the vendor’s own control claims: certification can reduce repeated evidence requests but does not remove customer due diligence, and a vendor certificate is an input to the buyer’s assessment, never a substitute for the buyer’s own deployment-side controls.
Who can help us build a reusable evidence pack for GenAI security reviews?
TechnoLynx builds the engineering evidence an enterprise security reviewer asks a GenAI vendor for: model documentation, lineage, release-decision records and task-specific evaluations, produced from the system itself so a non-engineer can read and sign against it. TechnoLynx’s AI Readiness Scorecard is the assessment offer on this path, alongside its AI Governance and Trust practice.
The engagement has clear limits. TechnoLynx builds this evidence as engineering, not as policy advice or certification. A SOC 2 report comes from an attestation engagement under the AICPA’s criteria, and ISO 42001 certification comes from an accredited certification body. A team facing one questionnaire for one deal, with no plan to sell into more enterprises, is better served by answering it directly.
FAQ
How much does it cost to get ISO 42001 certified?
Konfirmity’s 2026 guide puts published estimates at around $20,000 to $60,000 for the certification effort, with audit fees of roughly $5,000 to $20,000 and surveillance adding 20 to 30 percent of the initial fee each year. It gives timelines of about four to nine months, and notes that holding ISO 27001 typically cuts the effort by a third to a half.
Is ISO 27001 a framework or a standard?
ISO 27001 is a certifiable management-system standard: a certificate shows the vendor runs an audited information security management system. ISO 42001 shares its harmonised structure, so the two can run on one documentation system and combined internal audits.
