An AI or GPU-cloud vendor without a finished SOC 2 Type II can still give a security reviewer evidence that holds up: a completed CAIQ or SIG, a SOC 2 Type I or a signed engagement letter with a CPA firm, a readiness summary, a pen-test executive summary and its policy set. When you run due diligence on a model or GPU vendor, accuracy benchmarks matter less than three other questions. Is the evidence real? Does it cover the environment that will actually handle your data? Does the contract stop the vendor from quietly changing the hardware or the model underneath you? The rest of the work is telling apart the gaps an engineer can close from the ones that need a contract clause or legal counsel.
What goes into a reusable vendor security assessment packet
Trustmind’s CAIQ guide describes the package procurement teams usually request: a SOC 2 Type II report, an ISO 27001 certificate where one exists, a completed SIG Lite or SIG Core, and a completed CAIQ v4 or a link to the vendor’s STAR registry entry, usually with a pen-test summary alongside. An AI or GPU-cloud vendor should also add architecture diagrams that show tenancy boundaries, a sub-processor list, and its model-evaluation and release sign-offs.
TechnoLynx treats putting this packet together as an engineering job. TechnoLynx can build a governed pipeline that pulls the current audit, pen-test and model-evaluation artefacts into one master packet, then maps each incoming questionnaire onto it instead of writing every answer from scratch. Evidence that a buyer, an auditor or a compliance owner can read and sign against is an output of the engineering work in its own right, not a marketing document. We cover how to package verification evidence so it survives an auditor’s scrutiny separately.
The packet has to stay current. If the pen test has expired or the SOC 2 period has lapsed, the packet fails review however well it maps onto the questionnaire. You will still need per-deal additions for industry-specific questions, and some buyers send their own questionnaire.
Should the master copy be a pre-filled CAIQ or a SIG Lite?
Choose the master copy by what your target buyers request: a pre-filled CAIQ for cloud-control reviews, with SIG added for buyers who send one. The Cloud Security Alliance describes the CAIQ as a set of yes/no questions that cloud customers and auditors can put to a provider to check its compliance against the Cloud Controls Matrix. CSA lists CCM v4.1 at 207 controls across 17 security domains. Trustmind puts CAIQ v4 at 261 questions and notes that it is free to download, fill out and publish. A CAIQ is self-assessed, and no auditor signs it. Only STAR Level 2, which sits on top of a separate ISO 27001 or SOC 2 audit, adds third-party assurance. A STAR Level 1 entry is valid for one year from submission.
SIG has a wider scope and is paid for: it covers HR, physical security and operations as well as cloud controls, and Trustmind’s reading is that most teams send a CAIQ as a companion to a SIG, not as a replacement for it. Shared Assessments positions SIG Lite as the low-risk question set and SIG Core as the comprehensive set for higher-risk third parties.
An AI vendor has a further option. CSA’s AI-CAIQ extends the CAIQ to AI systems, and its questions map to the AI Controls Matrix, which has 247 control objectives across 18 domains and maps to ISO 42001, ISO 27001 and BSI AIC4. We would pre-fill both the CAIQ and the AI-CAIQ, then add SIG Core when the target buyers rate the vendor as high-risk. When a buyer sends their own questionnaire, answer it honestly and mark open items as in remediation instead of leaving them out.
If the packet has to go out before the first Type II exists, a SOC 2 Type I is the legitimate interim centrepiece: it is issued by a CPA firm and attests that controls were suitably designed and implemented on a specific date, though it does not test whether they operated effectively over time. One industry guide reports that most enterprise buyers accept a Type I for 6 to 12 months after issue. Some regulated buyers will not, so confirm the minimum evidence each prospect requires early on.
Will prospects accept a readiness assessment while our SOC 2 Type II is still in its observation window?
A readiness assessment carries weight as one part of an evidence stack, not as evidence on its own. A readiness assessment maps current controls to the Trust Services Criteria and produces a remediation plan. It can be a self-assessment or a third-party advisory engagement. No vendor is “certified” or “compliant” until the CPA firm issues the report. A vendor can, however, share its current stage, the target report type, the review period, and the fact that a licensed CPA firm is engaged. The signed engagement letter is the strongest single proof that the examination is real, scoped and scheduled.
Interim evidence by situation
| What the vendor has | What it can hand over | How reviewers tend to weigh it |
|---|---|---|
| Readiness assessment only | Readiness summary, policy set, completed CAIQ or SIG, pen-test executive summary, under NDA | Satisfies many reviewers as a stack, but it is not an attestation |
| Signed CPA engagement letter | Engagement letter with the scope and review period dates | Strongest proof that the examination is real and scheduled |
| Completed SOC 2 Type I | The Type I report plus the Type II schedule | A CPA-issued milestone; often accepted for 6 to 12 months, not a substitute for Type II |
| Prior report, gap of up to three months | Bridge letter signed by management | Routine and rarely questioned |
| Gap of three to six months | Bridge letter plus recent access reviews, scan summaries, a current pen test | Draws scrutiny; buyers ask for this interim evidence alongside the letter |
| Gap past six months | A dated commitment to the next report | Most sophisticated risk teams stop accepting letters |
Bridge letters extend an existing report
A bridge letter is a representation by management, signed by an officer such as the CISO, CTO or CEO. The auditor does not sign it, and BD Emerson states that licensed firms decline the request every time because it would mean giving assurance without evidence. The soc2vendors template states this explicitly: the letter does not constitute an audit opinion, attestation or assurance engagement under AICPA standards. A bridge letter can only extend assurance over what was already audited, and it cannot widen the scope after the fact.
The material-changes clause is the one recipients scrutinise most. “No material changes” is a legal representation, and leaving the clause blank when infrastructure, providers or access controls did change creates liability. ComplyJet reports that some regulated buyers, particularly in financial services and healthcare technology, will not accept bridge letters at all. BD Emerson lists five situations where refusal is reasonable: the gap is past six months, the environment changed materially, an incident occurred, a new vendor is presenting an old report, or the buyer’s policy simply excludes management letters. In each case the productive response is to schedule the next window, share the engagement letter and offer interim evidence.
Whatever you tell a prospect mid-audit must not promise more than your own published service terms. NVIDIA’s cloud services SLA, for example, shows what such terms define: availability levels and remedies for each offering. Where a report is blocking a deal, a security addendum with audit rights, breach-notification and report-delivery obligations is a workable contractual alternative.
What should we document to show tenant data and models cannot leak across a shared GPU serving pool?
For a shared GPU serving pool, isolation evidence means controls that have been tested and measured, each mapped to a named risk. An architecture diagram or a security backlog does not count as that evidence.
NIST’s AI RMF 1.0 calls an AI system secure when it maintains confidentiality, integrity and availability through protection mechanisms that prevent unauthorised access and use. It defines validation as confirmation “through the provision of objective evidence” that requirements are met. For shared GPU serving, we would list the specific risks (capacity starvation, noisy neighbours, cross-tenant memory access, model extraction) and attach measured evidence to each one. A backlog item that is being worked on can be cited as mitigation in progress, but it shows intent, not a verified boundary. A risk with no isolation test and no capacity-starvation SLO is an open gap to close before sign-off.
The mechanisms themselves can be measured, and the evidence should carry those numbers. In the Guardian paper, Guardian’s address fencing added an average 9% overhead over unprotected native execution on Caffe and PyTorch workloads. It ran 4.84% slower than MPS and improved co-located execution time by 37% over time-sharing. The same paper measured MPS using 734 MB of GPU memory against Guardian’s 176 MB with four clients, because MPS creates a context per client. It contrasts Guardian’s variable-size partitions with MIG’s static ones. Those results come from an RTX A4000, with one experiment on an RTX 3080 Ti, not from measuring your pool. They are not a substitute for that measurement.
If your pool runs on a fixed hardware budget with no headroom, we would treat capacity starvation as a structural risk that scheduling policy alone cannot document away. For the verification method itself, including encryption claims, see our page on proving data protection and tenant isolation in multi-tenant AI hosting.
The same rule (a control that rejects bad input, not a policy that promises good behaviour) applies to model artefacts on Jetson-class edge devices. Sign the checkpoint hash, verify the signature before the model loads, and keep the public key in a TPM or secure element rather than in the same writable storage as the model, so an attacker cannot swap the key and the artefact together.
If a GPU provider swaps in a lower-tier SKU, how do we prove it, and what should the contract give us?
Proving a substitution starts with a GPU hardware baseline written into the contract. We would make that a signed exhibit listing the exact SKUs, generations and firmware versions committed, plus an agreed method for checking delivery against it. Without the exhibit, a dispute is your inference against the provider’s word.
Where the hardware supports it, vendor attestation gives the strongest proof. NVIDIA describes the H100 in confidential-computing mode producing a cryptographically signed attestation report through measured boot and an SPDM session, which the user verifies before going ahead. Each H100 carries a device-unique identity key burned into its fuses, and that identity can be checked against NVIDIA’s certificate authority. NVIDIA’s Attestation Suite compares the collected evidence against signed “golden” measurements from its RIM service and checks certificate revocation.
Many rented GPUs expose no attestation path to an unprivileged tenant. For those, Alpay et al. describe a software-only topology certificate. A CUDA probe measures a latency matrix across SMs and memory regions, and the results are committed into a SHA-256 certificate that a verifier checks without needing a GPU. The authors report that timing alone tells apart a unified-L2 V100, a two-way-split H200 and a two-die B200. They state that the method is not tamper-proof, because a host with physical control can refuse to run the probe, and that confidential-computing attestation remains stronger where it is available.
Firmware versions can be baselined too. The OCP GPU firmware update specification requires a signed security version (SVN) in each image, with a minimum version held in fuses so that downgrades are refused. It also requires queryable telemetry covering the firmware version of every stored image and which image the device booted from. A firmware exhibit can therefore name versions the provider is able to report, as long as it sets a materiality threshold so that routine security patches do not count as substitution. Agree the detection method in the contract. A fingerprint the provider never accepted is easy for it to dispute.
For the remedy, negotiate a named minimum generation floor for the term (for example, nothing below an H100-class part if your downstream SLAs depend on it), plus audit or reporting rights and a defined consequence: service credits where switching would be costly, a termination right where substitution is unacceptable, and a notice-and-cure obligation in either case. Treat these as asks to negotiate.
Which security and data-handling questions should every LLM vendor answer before a pilot?
Every hosted or self-hosted candidate should answer the same fixed questionnaire before any pilot, and the vendors that fail its required criteria should be dropped before anyone compares performance or price. TechnoLynx’s AI Governance and Trust work produces the evidence side of that assessment: approval evidence packs that survive an external auditor, a procurement committee or a regulator.
FS-ISAC’s Generative AI Vendor Risk Assessment Guide (2024) gives a sound structure. Its vendor questionnaire covers data privacy, retention and deletion, model training and maintenance, information security, technology integration, nth-party risk, and legal and regulatory compliance. Level 3 adds questions on data retention, change management, audit validation, security configuration, log management and DLP. NIST’s Generative AI Profile (AI 600-1, initial public draft) calls for due diligence on third parties before agreements are signed, and for contracts and SLAs that specify security requirements.
A fixed question set for each LLM vendor submission:
- Where data is processed and stored, by region, including for any fine-tuning run
- Whether API inputs are used for vendor-side training, and how long they are retained
- Encryption at rest and in transit, plus access controls on prompts, outputs and logs
- Data retention and deletion
- The sub-processor list and the notice given before a sub-processor changes
- Audit rights and the vendor’s published certifications
- Notice before model or system changes, and incident disclosure
If you plan to fine-tune on research documents, residency, retention and the training-use guarantee become pass/fail criteria, not preferences. Self-hosting removes the vendor-data-use questions but brings in internal access-control and infrastructure-security questions, which the same checklist still has to cover. Vendor answers are self-reported unless an audit or a contract backs them, and this assessment says nothing about model quality or cost.
How do we get a SOC 2 Type II that covers our GPU clusters and Kubernetes namespaces, not just the corporate estate?
Write the audit boundary around the GPU inference environment from the start, put its controls into operation before the observation window opens, and choose an auditor who can test your stack. Encryption Consulting’s guidance is to name the systems and data flows that handle customer data and narrow the scope to them, which also keeps cost under control. The same guide advises picking a CPA firm with experience relevant to your industry and technology stack, and agreeing the observation start date with it. We would ask a prospective auditor directly how they have tested Kubernetes RBAC, namespace boundaries and GPU node access before. Security is the only Trust Services Criterion required in every SOC 2.
The timeline depends on the observation window. ComplyJet puts the minimum window at three months, notes that the AICPA recommends six and that enterprise buyers expect twelve, and adds that the auditor needs 4 to 8 weeks after the window closes to finish the report. Encryption Consulting estimates 2 to 4 months for a Type I and 9 to 18 months in total for a first Type II, from the start of preparation. Wolf & Company describes Type II periods ranging from six to 18 months. Whatever the range, a Type I can serve as the interim artefact while the Type II window runs.
Controls have to run before the clock starts. Auditors sample evidence from across the whole window, so a control introduced partway through can be recorded as a deviation. Access control, change management and monitoring on the clusters come first. Among the common findings Encryption Consulting lists is encryption missing from some in-scope data stores, including backups and development environments. On GPU platforms, model-weight caches and scratch volumes deserve the same check. A scope limited to named clusters may not satisfy a customer who wants assurance across the whole company, and a bridge letter cannot widen it later.
What should an LLM API vendor disclose about sub-processors, and will it tell you before the model changes?
You should get the vendor’s data processing agreement, its sub-processor list and its model-change notification terms in writing before any sensitive data, such as applicant health disclosures, reaches the API. Treat each of them as a contractual commitment, not an assumption. Published practice gives a reference point. LLM Gateway, for example, commits to at least 30 days’ notice before a new operational sub-processor starts processing personal data, with time for customers to object. It also publishes, for each provider, the data-retention window, whether API inputs are used for training, and its certifications.
Model changes need their own clause. The authors of “Are You Getting What You Pay For? Auditing Model Substitution in LLM APIs” (arXiv, 2025) describe providers that may covertly serve a smaller or quantised model in place of the one advertised. They conclude that no robust software-only method currently lets users detect this against a determined provider. TEE-based attestation offers a path to provable integrity, but only where the provider adopts it. NIST’s draft Generative AI Profile likewise advises considering liability for system changes over time, such as fine-tuning and drift, and requesting notification of serious incidents.
If the standard terms give neither guarantee, you have three options: negotiate an enterprise agreement that includes them, restrict the data you send to de-identified fields (accepting the remaining re-identification risk), or move this workload to a self-hosted or private deployment where you control the model version. A health-data workload belongs in the high-risk tier however good the summarisation quality looks. Review the sub-processor terms on a schedule. If an audit turns up an undisclosed sub-processor, the remedy is a retroactive security and data-handling assessment of that party, which is a governance task, not a benchmark. This is a contract question in the end, and counsel should review the agreement.
Who can help us assemble security evidence that an AI procurement review will accept?
TechnoLynx builds the engineering evidence that AI and GPU vendor reviews ask for: the governed packet that keeps CAIQ, SIG and audit artefacts current, isolation and fair-scheduling tests that turn a shared GPU pool’s claims into measured results, and hardware and model verification checks that a contract exhibit can rely on. TechnoLynx does this as engineering work for teams in AI infrastructure and production SaaS, and the AI Governance and Trust offer covers the assessment and sign-off artefacts on the buyer side. The first step is a review of the questionnaires and procurement findings blocking you now, measured against the evidence you already hold.
The engagement does not suit everyone. TechnoLynx does not issue SOC 2 reports, certify compliance or give legal advice: a licensed CPA firm issues the attestation, and counsel drafts and negotiates the contract terms. If you have an in-house security engineering team with GPU platform experience, it can carry the testing itself.
