How to assess whether OpenAI, Anthropic, or AWS themselves are secure enough for your product

Most security content is written from one side of the table. It tells you how to prove your own product is secure enough for your customers. This article flips that. If you are building on OpenAI, Anthropic, AWS, or any other AI infrastructure provider, you are the buyer in that relationship, and you carry the same responsibility to assess them that your own enterprise customers apply to you.

This matters more than most founders realise. If one of your providers has a security failure, your product inherits that risk, and your customers will ask you about it, not the provider. This guide covers how to actually assess whether a provider is secure enough to build on, using the same rigour you would want a buyer to apply to you.

Why this is your responsibility, not theirs

It is tempting to assume that if you are paying a major provider, security is handled. To a significant extent, the underlying infrastructure genuinely is handled well by large, well resourced providers. But responsibility for security in cloud and AI services is shared, not transferred. The provider secures their platform. You remain responsible for how you configure and use it, what data you send them, and whether their security posture is appropriate for what you are building.

If your product suffers a breach because a provider was misconfigured on your end, or because you sent data somewhere you should not have, that responsibility sits with you, not with the provider whose infrastructure you used. Your enterprise customers understand this, which is exactly why sophisticated buyers ask about your sub processors and providers as part of their own review of you.

What to actually check, for any provider

Here is a practical framework you can apply to OpenAI, Anthropic, AWS, or any other provider you are evaluating.

• Their published certifications and audit reports. Major providers publish SOC 2 reports, ISO 27001 certification, and similar attestations. Request or locate their current reports, check the date, and confirm the scope actually covers the service you are using, not just the company in general.
• Their data processing terms. Read their Data Processing Agreement and their published data handling policy. Understand specifically whether your data is used for training, how long it is retained, and what happens to it if you stop using the service.
• Their security and trust documentation. Most large providers publish a security or trust centre with details on their practices, incident history, and architecture. Read it rather than assuming, because the details vary meaningfully between providers and between services from the same provider.
• Data residency and regional options. If you have UK or EU data residency requirements, confirm what regions the provider actually offers and whether using them requires specific configuration on your part, because defaults are often not what you assume.
• Their incident history and disclosure practices. A provider that has had incidents is not automatically a red flag, security incidents happen to everyone eventually. What matters is whether they disclosed clearly, responded quickly, and fixed the underlying cause. A provider with no public transparency about incidents is harder to assess, not necessarily safer.
• Their sub processor list. Large providers use their own vendors and sub processors. Understand who else your data might touch through your provider, because your customers may eventually ask you the same question about your own chain.
• Configuration options they offer versus what you have actually enabled. This is the step founders skip most often. A provider can offer strong security options, enhanced data controls, private networking, dedicated capacity, that do nothing for you unless you configure them. Assess not just what the provider makes possible, but what you have actually turned on.

What this looks like for the three you mentioned

The specific detail changes provider to provider and service to service, and it changes over time as providers update their offerings, so always verify current specifics directly against the provider's own documentation before relying on it. But the shape of the assessment is consistent.

For a model provider like OpenAI or Anthropic, the questions that matter most are around training data use, retention periods, whether enhanced data controls are available and enabled, and what your Data Processing Agreement actually covers for the specific service you use, since terms can differ between a consumer product and an API or enterprise offering.

For infrastructure providers like AWS, the questions shift toward configuration. AWS provides an extensive set of well documented security capabilities, but the well known reality of cloud security is that most cloud related incidents trace back to how a customer configured the service, not a failure in the underlying platform. The provider secures the cloud. You are responsible for security in the cloud, meaning your own configuration, access controls, and architecture. Assessing AWS is less about whether AWS itself is secure, which for the core platform it generally is, and more about whether your own setup on top of it follows recognised best practice.

The questions to ask directly

If you have a direct relationship or sales contact with a provider, do not hesitate to ask them plainly. Reasonable providers expect and welcome these questions from business customers, and their answers, or their absence, tell you something either way.

• Can you share your current SOC 2 report or equivalent audit evidence?
• Is our data used for training, and can this be disabled or is it already excluded by default for our tier of service?
• What is your data retention policy for our specific service, and can it be adjusted?
• Do you offer data residency in the UK or EU, and what do we need to configure to use it?
• Who are your sub processors for this service?
• What is your incident notification process if something affecting our data occurs?

Why this protects you commercially, not just technically

There is a direct payoff for doing this work, beyond simply reducing your own risk. When your enterprise customer's security team asks how you vet your own AI and infrastructure providers, having real answers, drawn from an actual assessment rather than an assumption that a big name equals safe, is exactly the kind of maturity that builds buyer confidence. It shows you understand that security is a chain, and that you have checked every link you control, including the ones that are technically someone else's product.

Conversely, being unable to answer basic questions about your own providers signals the same gap that a hardcoded secret or an unclear data flow does. It suggests security has not been thought through end to end.

The honest takeaway

Building on major, well resourced providers is generally a sound decision, and it would be wrong to suggest otherwise. But sound does not mean automatic. Your responsibility does not end at the point you choose a reputable name. It continues through how you configure what they offer, what you actually enable, and whether you can answer, clearly and specifically, the same kind of questions your own enterprise buyers ask you.

Do that assessment deliberately, keep the evidence, and you turn what could be an unexamined assumption into a genuine strength you can point to when a buyer asks how your AI product handles risk across its entire chain, not just the part you built yourself.