Procurement and Contract Negotiation

Most enterprises reach procurement with the technical route already chosen. Chapters two through five have walked the CTO through the architecture of each provider. Chapter eight has documented the controls. Chapter nine has established governance. But procurement is where technical choices meet regulatory constraints and contractual reality. Anthropic's documentation is clear about what you get on each route. What vendors publish and what they will actually commit to in a contract are often different things. This chapter walks the CTO and procurement team through the contract negotiation lifecycle for Claude deployment. Unlike the technical chapters which explain architecture, and the control chapters which set governance, this chapter is action-oriented. It names what must be in the contract, what you ask the account manager, where gaps exist between provider documentation and enforceable commitments, and how to escalate when a vendor refuses a required term.

Procurement shapes deployment viability more than technology does. You can have the right technical architecture. You can have solid governance. But if your contract does not reserve the audit rights you need, or does not define sub-processor disclosure requirements, or does not guarantee data residency, the deployment will not satisfy your compliance obligations. This chapter turns governance intent into contractual language.

The Data Processing Agreement checklist

When you deploy Claude on any route other than air-gapped internal infrastructure, a data processor is involved. Under GDPR Article 28, the controller must use processors providing sufficient guarantees to implement appropriate technical and organisational measures, ensuring compliance with GDPR and protecting data subjects' rights. UK ICO guidance makes clear that the contract must make available to the controller all information necessary to demonstrate compliance, and must allow for audits, including inspections, by the controller or a third-party auditor.

Five items are non-negotiable in any DPA. First, processor obligations must be explicit. The processor cannot process personal data except on the controller's instructions. Any processing outside those instructions requires controller authorisation. Second, sub-processor approval and transparency are mandatory. Processors cannot engage additional processors without prior written authorisation from the controller. Where general authorisation is given, the processor must inform the controller of any intended changes and give the controller the chance to object. Third, audit rights must be reserved. Controllers must be able to inspect the processor's infrastructure, request SOC 2 reports, and potentially engage third-party auditors on their behalf. Fourth, data subject rights support is required. If a data subject requests erasure, the processor must cooperate with deletion. If they request access to their data, the processor must assist the controller in responding. Fifth, breach notification windows must be specified. If the processor discovers a data breach, they must notify the controller within a defined timeframe so the controller can meet its own regulatory notification obligations.

These five items are not vendor options. They are regulatory requirements. If a vendor refuses any of them, the contract is not GDPR-compliant, and your organisation cannot sign it.

Processor obligations and sub-processor disclosures

When you use Anthropic directly, Anthropic is the processor. When you use Bedrock, Vertex, Foundry, or any data-platform route, the cloud provider is the primary processor and Anthropic becomes a sub-processor. The distinction matters for the contract chain.

For direct Anthropic deployment, the contract must state that Anthropic processes data only on your instruction, does not use data to improve their base models, does not retain conversation data after your engagement ends, and will delete data on request. These are the core processor obligations. Anthropic's current standard terms cover some of these. Others require negotiation or custom rider clauses. Before proceeding, request the current Data Processing Agreement template and ask your account manager which items above are already covered in standard terms and which require custom drafting.

When you use AWS Bedrock, the processor chain looks like this: you are the controller, AWS is the primary processor, and Anthropic is a sub-processor running within AWS infrastructure. AWS's standard Business Associate Agreements or Data Processing Agreements must explicitly name Bedrock and explicitly name Anthropic as a sub-processor. Do not assume AWS's DPA automatically covers Claude. AWS adds services to their processor agreements as amendments. Request a written confirmation from AWS that their current DPA covers Claude inference and names Anthropic. If Anthropic is not listed as a sub-processor in AWS's DPA addendum, request that AWS add Anthropic explicitly.

The same pattern applies to Azure Foundry (Microsoft is the primary processor, Anthropic is the sub-processor) and Google Vertex (Google is the primary processor, Anthropic is the sub-processor). In each case, verify in writing that the cloud provider's DPA or BAA covers the specific service you are using and names Anthropic in the sub-processor schedule.

Sub-processor lists are not published by Anthropic, AWS, Azure, or Google with the same cadence or transparency. Anthropic's sub-processor disclosure is not publicly available. AWS publishes a sub-processor list but does not itemise which sub-processors are used by specific services. Azure and Google follow similar patterns. Require in your contract that the provider notify you of sub-processor changes within 30 days and provide a current list on request. This is standard GDPR language, but vendors sometimes resist it. Do not accept a contract that does not commit to 30-day notification of sub-processor changes. Document the requirement explicitly.

SLAs and the gaps

A Service Level Agreement defines uptime commitments, performance targets, and service credits for failure. SLAs are distinct from security commitments. An SLA answers the question "what happens if the service is unavailable". A security commitment answers "is my data encrypted in transit". You need both.

AWS Bedrock publishes SLAs through AWS's standard terms. Uptime commitments are typically 99.99% across AWS regions. Google Vertex publishes SLAs. Microsoft Azure publishes SLAs, and Claude on Foundry inherits those SLAs. Data platform routes like Snowflake Cortex inherit Snowflake's published SLAs.

The gap: Cowork 3P on direct Anthropic does not yet have published SLAs. As of 2026-04-22, Anthropic has not committed to published uptime guarantees for Cowork 3P deployments. This is a material gap if your service-level requirements depend on Anthropic committing to a specific uptime percentage. Ask your account manager what SLA commitment is available before signing. If Anthropic is willing to commit to an SLA, get it in writing in the contract. If Anthropic offers only best-efforts language with no specific uptime percentage, document that explicitly in the contract so your organisation understands what you are purchasing. Do not assume an unstated SLA commitment exists.

Audit rights and the compliance matrix

Audit rights are the operational muscles behind the DPA. The contract must reserve your right to inspect infrastructure, request audit reports, and engage third-party auditors. Specifically, you need four things. First, the right to request SOC 2 Type II reports from the vendor. SOC 2 Type II audits cover a full year of operation and verify that the vendor's controls are operating effectively. Second, the right to engage a third-party auditor to conduct an on-site inspection of infrastructure relevant to your deployment. Third, the right to request audit evidence on specific topics: data encryption, access controls, incident response procedures, sub-processor management, and data location verification. Fourth, frequency and scope terms. How often can you request audits (annual, every two years)? What topics are in scope? Can you request a limited audit focused on specific risks, or must you audit the entire vendor infrastructure?

Cloud providers typically publish SOC 2 Type II reports. AWS, Azure, and Google make SOC 2 reports available to customers with non-disclosure agreements. Anthropic's current audit status is not publicly documented. Before signing with direct Anthropic, ask directly whether SOC 2 Type II audit evidence is available and what the process is for requesting it. The answer determines what audit rights you can actually exercise.

For organisations using Bedrock, Vertex, or Foundry, your audit rights extend through the cloud provider. The cloud provider grants you audit rights. You then need the cloud provider to grant those rights to cover Anthropic-specific infrastructure. This may not be automatic. Request in writing that your audit rights extend to cover Anthropic's infrastructure within the cloud provider's environment.

For regulated deployments (HIPAA, GDPR at scale, financial services), audit rights are not optional. Reserve them in the contract even if you do not plan to exercise them immediately. If you do not reserve the right now, you will not have it later.

Enterprise Discount Programme pricing

Enterprise Discount Programme pricing is negotiated, not published. Anthropic, AWS, Azure, and Google all have EDP offerings that provide volume discounts for committed spending or specific contract terms. The rates vary by commitment volume, contract period, region, and model version. What you should ask for and what you will actually get depend on your leverage, your volume, and your alternative options.

When you request an EDP quote, ask for these components. First, per-token rates for each model you intend to use (Opus, Sonnet, Haiku, Mythos if applicable). Specify whether you want on-demand rates, batch-processing rates, or both. Second, the volume commitment (how many tokens per month or per year triggers the discount). Third, upfront payment terms (pay-as-you-go, monthly commitment, annual prepaid, or hybrid). Fourth, regional pricing variance (does the rate change if you deploy in different regions?). Fifth, contract term (one year, three years, or custom). Sixth, any other modifiers (discounts for multi-year commitments, discounts for specific use cases, minimum commit requirements).

Do not assume published pricing applies to your deployment. Published pricing is typically list price. Actual enterprise contracts rarely pay list price. For cloud providers, published EDP discounts apply. For Anthropic direct, pricing is not published at all. Request a quote explicitly, and get the quote in writing before committing to volume or timeframe.

Liability, indemnification, and termination

Standard limitation-of-liability clauses cap the vendor's liability to the fees paid in the preceding 12 months. This is typical of SaaS contracts. What this means in practice: if Claude fails and costs you EUR10M in lost business, your recovery from Anthropic or your cloud provider is capped at the fees you paid them that year. This may be EUR50K. The gap between the loss and the recovery is your organisation's liability.

Indemnification clauses define who pays if the vendor's service violates a law. If Anthropic's infrastructure is compromised and your data is disclosed, does Anthropic indemnify you against the cost of notifying regulators and affected individuals? Does Anthropic cover the regulatory fines? Standard vendor terms typically do not. Anthropic's standard terms probably do not cover indemnification for GDPR fines or HIPAA breaches. This is a negotiation point for regulated deployments. Get explicit written commitment on indemnification for breaches caused by vendor negligence.

Termination clauses matter more than most CTOs realise. Most SaaS contracts allow the vendor to terminate for convenience with 30 or 60 days notice. This means Anthropic or your cloud provider can end the service relationship with little warning. If that happens, you need a data retrieval window. The contract must state how long the vendor will keep your data available after termination. Standard terms often say 30 days. For organisations with significant deployment at scale, 30 days may not be enough time to export conversation history and re-architect to a different vendor. Negotiate for 90 days minimum. Specify what data is included in the retrieval period (conversation history, audit logs, metadata). Specify what format the data is provided in (JSON, CSV, raw export).

For cloud provider routes (Bedrock, Vertex, Foundry), you have two termination relationships. One with the cloud provider, one with Anthropic (as a sub-processor). The cloud provider's termination clause applies to the service. Anthropic's termination clause applies to their sub-processing relationship. If Anthropic terminates their sub-processing relationship, the cloud provider must find an alternative or terminate the service to you. Get clarity on this dependency in writing.

RFP structure and compliance certification

When you request proposals from AI inference vendors, structure the RFP to ask for specific compliance artefacts and contractual terms. Name what you need in writing so vendors know the requirements before they spend time on a proposal.

First, request current compliance certifications. Ask for SOC 2 Type II audit reports (or timelines for completion if not yet available). Ask for ISO 27001 certification. Ask for FedRAMP High authorisation if you are a US federal agency or contractor. Ask for HIPAA BAA if you handle patient data. These are not optional for regulated deployments. If a vendor has not obtained these certifications, ask what their timeline is. If they have no timeline, that is a risk signal.

Second, request a data residency statement. Specify the regions where you intend to deploy (eu-west-1, us-east-1, ap-southeast-1, etc.). Ask the vendor to confirm in writing that customer data remains in those regions and is not processed outside them for any purpose. Some vendors (like Azure Foundry with Global Standard deployment) process data outside the specified region for operational purposes. Get this in writing so your organisation understands what residency means in the contract.

Third, request a current sub-processor list. Ask the vendor to commit to notifying you within 30 days of any sub-processor changes. Ask for a timeline for providing updated sub-processor lists (quarterly, monthly, on request).

Fourth, request DPA or BAA templates specific to your jurisdiction and regulatory framework. If you operate in the EU, request a GDPR-compliant DPA. If you operate in the UK, request UK GDPR terms. If you handle HIPAA data, request a BAA. If you operate in Switzerland, request Swiss FADP-compliant terms. Many vendors have standard templates. Request them and review with your legal counsel before engaging in detailed negotiations.

Fifth, ask for specific contractual clauses relevant to your deployment. If you need data encryption with customer-managed keys, ask whether the vendor supports it. If you need audit rights beyond SOC 2 (e.g., annual on-site inspections), specify the scope. If you need vendor commitment to support specific security controls, name them.

If a vendor has not obtained a required certification, ask explicitly what their timeline is. If they have no timeline, escalate the risk to your procurement team and your legal counsel. Do not wait until contract negotiation to discover these gaps.

Multi-jurisdiction complexity

Compliance interpretation is jurisdiction-specific. GDPR applies in the EU. UK GDPR applies in the UK (with some differences from EU GDPR). HIPAA cloud-computing guidance applies to US covered entities handling patient data. APRA CPS 234 applies to Australian financial institutions. MAS Guidelines on Outsourcing (Banks) 2023 apply to Singapore-regulated entities. Note that Notice 655 has been cancelled and superseded by Notice FSM-N06 (effective 10 May 2024), and the 2016 Outsourcing Guidelines have been replaced by the 2023 (Banks) and 2024 (non-Banks) versions. Each framework has different processor requirements, audit expectations, and data transfer rules.

If your organisation operates in multiple jurisdictions, each with different regulatory requirements, the contract must reflect those differences. A GDPR DPA for EU data is not sufficient if you also process UK data. You need a separate UK addendum to your DPA that complies with UK GDPR specifically. If you handle HIPAA data, you need a BAA separate from the DPA. If you operate in Australia, you need attestation that the vendor meets APRA CPS 234 third-party risk requirements.

International data transfers add complexity. If you are in the EU and your vendor is in the US, the transfer must be lawful under GDPR. Verify whether the vendor is registered under the EU-US Data Privacy Framework. If they are, transfers are lawful. If they are not, you must execute Standard Contractual Clauses and implement supplementary measures to comply with Schrems II requirements. This is not automatic. Verify DPF certification status in writing before signing.

UK data transfers out of the UK require separate legal mechanisms (UK SCCs, UK adequacy decisions, or UK binding corporate rules). Do not assume an EU DPA covers UK data. Request UK-specific terms if you process UK personal data.

HIPAA BAAs must be jurisdiction-specific. The BAA itself is federal US law, but the vendor's implementation may vary. Request the BAA template specific to your region and review with your legal counsel before negotiating.

Jurisdiction-specific contracts add months to procurement timelines. If you operate in multiple jurisdictions with different regulatory regimes, plan for extended legal review. Start procurement conversations early.

Escalation paths when negotiation stalls

When a vendor refuses a required term, you have four options. First, escalate to the vendor's account manager and explain the business impact. Account managers have more flexibility than contract templates suggest. A refused term that is critical to your deployment is worth escalating. Give the account manager a chance to escalate internally to their legal or contracts team.

Second, request a custom exception. Vendors often have standard terms that they will waive for specific customers. If you need 90-day data retrieval but the standard is 30 days, ask for a custom exception in writing. Vendors approve custom exceptions more often than you might expect, particularly if you are a significant customer or a multi-year commitment is at stake.

Third, document the risk. If the vendor refuses a required term, do not accept the contract without executive acknowledgment that your organisation is accepting the risk. Write a brief (one page) explaining what term you requested, what the vendor refused, and what the business impact of the refusal is. Get your CTO, General Counsel, and CFO to sign off on the documented risk. This protects you if something goes wrong after signature.

Fourth, walk away. Some vendors will not move on required terms. If the vendor refuses a non-negotiable requirement and will not escalate, you may need to select a different vendor. This is a legitimate outcome. A contract that does not provide the legal and technical coverage you need is worse than no contract at all.

Red lines that should cause you to exit negotiation: a vendor that refuses any DPA or BAA, a vendor that refuses audit rights entirely, a vendor that refuses to disclose sub-processors, a vendor that refuses to commit to any data residency statement. These are not negotiable items. If a vendor refuses all four, they are not suitable for regulated deployment.

Primary sources

• GDPR-info.eu. GDPR Article 28 — Responsibility of the processor. Retrieved 22 April 2026.
• UK Information Commissioner's Office. Contracts and liabilities between controllers and processors. Retrieved 22 April 2026.
• HHS Office for Civil Rights. HIPAA and Cloud Computing. Retrieved 22 April 2026.
• European Data Protection Board. EDPB Guidelines on Processor Binding Corporate Rules. Retrieved 22 April 2026.
• Monetary Authority of Singapore. Guidelines on Outsourcing. Retrieved 22 April 2026.
• Australian Prudential Regulation Authority. CPS 234 — Information Security. Retrieved 22 April 2026.

Nothing in this article is legal advice. It names regulatory frameworks and describes what each framework requires for enterprise AI deployment. Compliance interpretation for your specific regulatory context, jurisdiction, and client contracts must be reviewed with qualified legal counsel. Verify current vendor documentation and regulatory guidance at the sources listed above before making a procurement decision.