AI Vendor Security Attestations: Turning SOC 2, ISO 27001 and CSA STAR Claims Into Usable Procurement Evidence For UK Businesses

AI Trust & Governance

21 July 2026 | By Ashley Marshall

Security badges are useful, but they are not procurement evidence on their own. UK buyers need to turn SOC 2, ISO/IEC 27001 and CSA STAR claims into scoped, current and decision-ready assurance.

Security badges are not the same as procurement evidence

AI vendor due diligence often starts in the wrong place. A supplier sends a trust centre link, the page lists SOC 2 Type 2, ISO/IEC 27001 and perhaps CSA STAR, and the buyer treats the row of badges as if the risk question has been answered. It has not. Those attestations can be valuable, but they only become procurement evidence when you know what service was assessed, when it was assessed, which controls were in scope, which locations and subcontractors were covered, and what responsibilities still sit with your organisation.

The NCSC Cloud Security Principles are a useful starting point because they apply to both cloud platforms and Software-as-a-Service, and they explicitly tell buyers to consider what evidence has been provided to support the provider's statements. That matters for AI procurement because most AI tools are layered services. A chatbot, coding assistant or workflow agent may depend on a SaaS application, a model provider, a vector database, a cloud region, an identity provider and several subprocessors. A certificate on one layer does not automatically assure the whole chain.

The practical shift is to stop asking, "Are you certified?" and start asking, "Which part of the service we are buying does this evidence cover?" A SOC 2 report may be strong evidence for operational controls over a defined system. ISO/IEC 27001 may show an information security management system is in place. CSA STAR may add cloud-specific transparency. None of those automatically prove that prompts, fine-tuning data, retrieval permissions, model updates, admin access, audit logs or deletion workflows meet your requirements.

For UK businesses, especially those handling employee, customer, financial or regulated data, this distinction is not paperwork. It is how procurement turns vendor claims into a defensible decision record. The certificate is the beginning of the evidence conversation, not the end of it.

What SOC 2, ISO/IEC 27001 and CSA STAR actually tell you

SOC 2, ISO/IEC 27001 and CSA STAR answer related but different questions. Treating them as interchangeable is one of the common mistakes in AI supplier review. SOC 2 is an assurance report over controls at a service organisation. The AICPA describes SOC services as reports that provide users with information needed to assess and address risks associated with outsourcing services, and its SOC 2 guide covers controls relevant to security, availability, processing integrity, confidentiality and privacy. For procurement, the key detail is whether you have a Type 2 report that tests operating effectiveness over a period, not just a point-in-time design assessment.

ISO/IEC 27001 is different. The ISO page for ISO/IEC 27001:2022 describes it as the world's best-known standard for information security management systems. It defines requirements for establishing, implementing, maintaining and continually improving an ISMS. ISO also says conformity means an organisation has a system to manage risks related to data it owns or handles. That is valuable, but it is still a management system certificate. Buyers need the certificate, statement of applicability, audit scope and any exclusions before relying on it for a specific AI product.

CSA STAR adds a cloud assurance layer. The CSA STAR programme says Level 1 is a self-assessment using the CAIQ and Cloud Controls Matrix, while Level 2 is a certification or third-party attestation. CSA also states that STAR self-assessments are updated annually, STAR Attestation listings expire after one year unless updated, and STAR Certification certificates follow normal ISO/IEC 27001 protocol and expire after three years unless updated. That gives buyers a freshness check as well as an assurance-level check.

In practice, the useful question is not which badge looks strongest. It is which evidence type best answers the risk you are trying to accept. SOC 2 can be excellent for control operation and exceptions. ISO/IEC 27001 can evidence governance and continual improvement. CSA STAR can show cloud-specific transparency and control mapping. A mature AI procurement review normally needs pieces of all three, plus AI-specific evidence that these traditional frameworks do not fully cover.

Map attestations to the AI workflow, not the vendor brand

The most useful procurement review starts with the workflow. What will the AI system do? Which data will it touch? Will it generate advice, classify records, update CRM fields, search documents, draft regulated communications, write code, approve transactions or trigger follow-up actions? Once those questions are clear, the buyer can map vendor evidence to the actual control points. Without that mapping, an impressive certificate can sit next to a risky deployment pattern without anyone noticing the gap.

The UK government's AI Cyber Security Code of Practice, published by DSIT in January 2025, is helpful here because it gives AI-specific procurement language. It sets out 13 principles across secure design, secure development, secure deployment, secure maintenance and secure end of life. It also says the proposed intervention was endorsed by 80% of respondents to DSIT's 2024 Call for Views, with support for each principle ranging from 83% to 90%. For buyers, the important principle is not the headline support number. It is the practical requirement to document data, models and prompts, secure the supply chain, test and evaluate, monitor behaviour, and dispose of data and models properly.

This is where traditional security attestations need translation. If a vendor's ISO/IEC 27001 certificate covers the corporate ISMS but excludes the new AI product, it is weak evidence for your use case. If a SOC 2 report covers the application but not the subprocessors used for model inference, retrieval or analytics, you need additional evidence. If CSA STAR Level 1 is a self-assessment, it may still be useful, but it should not be treated like an independent audit.

A practical mapping table should include each workflow, data class, integration, model route, region, subprocessor, control question and evidence item. For example, "customer support summaries using personal data" should map to encryption, access control, retention, deletion, prompt logging, human review, incident notification, model change notification and audit export. That table is far more useful than a trust centre screenshot because it shows what the buyer checked and what remains unresolved.

Build an evidence pack that procurement, legal and security can use

A usable evidence pack is not a folder of PDFs. It is a short, structured decision record that tells procurement, legal, security, data protection and the business owner what has been evidenced, what has not, and what conditions are attached to approval. For an AI vendor, the pack should normally include the latest SOC 2 report or bridge letter, ISO/IEC 27001 certificate and scope, CSA STAR registry entry if available, penetration test summary, data processing agreement, subprocessor list, model provider list, data location statement, retention policy, incident response commitments and customer responsibility matrix.

The ICO angle matters whenever personal data is involved. The ICO guidance on AI and data protection was updated on 15 March 2023 and added content on things to consider as part of a DPIA, transparency, lawfulness, accuracy, fairness and Article 22 safeguards. A SOC 2 report does not replace that assessment. It may support it by evidencing controls, but the buyer still has to understand lawful basis, fairness, transparency, data minimisation, retention and whether automated decision-making safeguards are needed.

In practice, procurement can use a simple red, amber and green evidence matrix. Green means the evidence is current, scoped to the service and covers the control question. Amber means the evidence is relevant but incomplete, perhaps because a new AI feature is not yet in the audit period or a bridge letter is needed. Red means the vendor claim does not evidence the risk, such as a parent company certificate that excludes the product being bought. The matrix should include expiry dates and renewal triggers. CSA STAR's one-year expiry for STAR Attestation listings and three-year certificate pattern for STAR Certification gives buyers a concrete example of why freshness should be tracked.

The pack should also capture exceptions and user responsibilities. SOC 2 reports often include complementary user entity controls, meaning the provider's assurance assumes the customer will configure identity, logging, access roles or network settings properly. If the business owner cannot meet those responsibilities, the control is not effective for your deployment, even if the vendor report is clean.

The trust centre counterargument and why it is only half right

The common counterargument is reasonable: good vendors now have trust centres, downloadable reports, automated NDA flows and public status pages. Why slow procurement down with extra questions when the vendor has already done the assurance work? For low-risk tools, that may be enough. If the AI feature is used for public marketing drafts with no personal data, no system access and no operational dependency, a light review may be proportionate. Security assurance should not turn every purchase into a six-week committee process.

The problem is that trust centres are designed for scale, not for your specific risk decision. They show what the vendor is prepared to disclose broadly. They do not automatically prove that your workflow, data class, tenancy, region, add-on, model route, retrieval connector or admin configuration is covered. Microsoft's Azure compliance documentation is a useful named example. Its SOC 2 page says Azure, Dynamics 365 and other Microsoft cloud services undergo independent third-party SOC 2 Type 2 audits, that reports are based on a rolling 12-month audit window, that new reports are issued semi-annually, and that bridge letters are issued during the first week of each quarter. It also points customers to user entity responsibilities in the report. That is strong assurance material, but it still requires the buyer to read the relevant scope and obligations.

The same logic applies to fast-moving AI products from vendors such as Microsoft, Google, OpenAI, Anthropic, Salesforce, ServiceNow and sector-specific SaaS suppliers. A vendor may have an excellent enterprise trust programme while a newly released AI assistant, agent builder, connector or model routing option sits outside the last audit period. That does not mean the vendor is unsafe. It means procurement needs a time-bound answer: is the feature in scope, when will it enter audit scope, what interim controls apply, and what evidence can be provided before renewal?

The balanced position is simple. Trust centres are useful intake channels. They reduce questionnaire fatigue and help buyers collect standard evidence quickly. They become risky when teams treat them as a substitute for scoped review. The buyer's job is not to distrust every vendor claim. It is to connect each claim to the specific decision being made.

Turn the evidence into contract controls and renewal discipline

Procurement evidence is only useful if it changes the buying decision. For AI vendors, that usually means turning the attestation review into contract clauses, onboarding controls and renewal checks. If the SOC 2 report shows relevant complementary user entity controls, assign them to an internal owner before go-live. If ISO/IEC 27001 scope excludes a material AI component, require an interim control statement or roadmap. If CSA STAR evidence is self-assessed, ask whether Level 2 attestation is planned for the cloud service you depend on. If the vendor uses a model provider or subprocessors, require notification of material changes.

The NCSC Guidelines for secure AI system development frame security across secure design, secure development, secure deployment, and secure operation and maintenance. They also stress that AI systems face novel vulnerabilities alongside standard cyber threats, and that security must be a core requirement throughout the lifecycle. For procurement, that means your evidence pack should not die at contract signature. It should feed onboarding, access reviews, logging, monitoring, incident response, change control and exit planning.

A practical UK business rhythm is quarterly for higher-risk AI vendors and annually for lower-risk suppliers. Quarterly review does not need to be heavy. Check whether reports or bridge letters have changed, whether new AI features are being used, whether subprocessors have changed, whether incidents or exceptions have been disclosed, whether the vendor's model or data retention settings have changed, and whether internal user responsibilities are still being met. At renewal, ask what changed since purchase and whether the original evidence still supports the live deployment.

This is where smaller businesses can be more disciplined than large enterprises. A five-page evidence register, updated consistently, is better than a 70-question spreadsheet nobody reads. The aim is not to create ceremony. It is to make sure that the phrase "SOC 2 and ISO certified" can be traced to a real procurement decision, a real workflow, a named owner, a residual risk statement and a renewal date.

Frequently Asked Questions

Is SOC 2 enough for buying an AI vendor?

No. SOC 2 can be strong evidence for controls over a defined service, especially Type 2 reports over an audit period, but it does not automatically cover AI-specific risks such as prompt logging, model routing, data retention, retrieval permissions, fine-tuning data or model change management.

What should UK buyers ask for beyond a SOC 2 report?

Ask for the report scope, audit period, exceptions, bridge letter, complementary user entity controls, subprocessor list, data location statement, retention policy, model provider list, penetration test summary, incident notification terms and confirmation that the AI feature you will use is in scope.

Is ISO/IEC 27001 proof that an AI product is secure?

Not on its own. ISO/IEC 27001 evidences an information security management system. Buyers still need to check whether the certificate covers the relevant product, business unit, hosting environment, AI workflow and supporting suppliers.

How should procurement treat CSA STAR Level 1?

CSA STAR Level 1 is useful transparency because it uses a self-assessment based on the Cloud Controls Matrix and CAIQ. It should not be treated as equivalent to Level 2, which involves certification or third-party attestation.

Do attestations remove the need for a DPIA?

No. If the AI system processes personal data and the risk profile warrants a DPIA, vendor attestations can support the assessment but cannot replace the buyer's UK GDPR accountability, fairness, transparency and data protection analysis.

What is a bridge letter?

A bridge letter is a vendor or auditor communication that helps cover the period between the end of an audit report and the current date. It is useful when a report is relevant but the audit period does not reach the procurement decision date.

How often should AI vendor evidence be refreshed?

Refresh higher-risk AI supplier evidence quarterly and lower-risk supplier evidence at least annually. Also trigger a review when the vendor changes model providers, data regions, subprocessors, retention terms, admin permissions, material features or incident history.

What is the biggest mistake buyers make with vendor trust centres?

The biggest mistake is treating a trust centre badge as scoped assurance. Trust centres are helpful intake channels, but buyers still need to check product scope, date, exclusions, feature coverage, subprocessors, customer responsibilities and unresolved exceptions.