Amazon Bedrock on AWS: security, compliance and which financial firms use it

Note: general recommendations only, not professional advice and not security advice. Before you connect customer data, talk to a security professional and to your compliance officer. The full text is at the end.

Checked on November 2, 2026 against official AWS documentation and AWS case study pages.

Every factual claim here links to the AWS page it was taken from. AWS updates these pages often. Before you decide anything, open the link and check that the wording has not changed.

Who this is for

For teams at fintech companies, banks, lenders, insurers and other financial organizations that are thinking about running language models through Amazon Bedrock. CTOs, security staff, compliance officers and product managers.

You don't need to be a developer to read it. To carry out the steps you need access to your organization's AWS account, or someone who manages it, and about an hour to read and run a first check.

It does not cover pricing, comparisons with other cloud providers, or local regulation. Questions about local regulation go to your compliance function.

The problem in three lines

The team wants to connect a language model to support calls, credit documents or fraud investigations. The compliance officer asks where the data goes, who sees it, and whether anyone trains a model on it. The answers are spread across dozens of documentation pages, FAQs and compliance lists, in wording that is easy to read as stronger than it is.

This playbook collects what AWS says about itself, with a link for every sentence, and separates what AWS is responsible for from what stays with you.

What Amazon Bedrock is

According to the AWS documentation, Amazon Bedrock is a fully managed service that provides access to foundation models from leading AI companies, for building and scaling generative AI applications.

The documentation mentions more than 100 foundation models from different providers, including Amazon, Anthropic, DeepSeek, Moonshot AI, MiniMax, OpenAI and xAI. In the standard description AWS adds to its case study pages, the service is described as offering these models through a single API.

One point to keep in mind from the start: the AWS shared responsibility model applies to data protection in Bedrock. The official page says AWS is responsible for protecting the infrastructure that runs its services, and customer responsibility is determined by the services the customer selects. Some of the protections AWS offers only work if you configure them. The six steps below are about exactly that part.

The method in 6 steps

Step 1: Encryption and keys in KMS

What to do: Make sure data is encrypted in transit and at rest, and decide which resources should use an encryption key of your own.

How:

• According to the AWS FAQ, your data in Bedrock is always encrypted in transit and at rest, and you can optionally encrypt it with your own keys.
• Customer content processed by Bedrock is encrypted and stored at rest in the Region where you use the service.
• For communication with AWS, AWS requires TLS 1.2 and recommends TLS 1.3. Check that your libraries and servers don't try to connect with an older version.
• For key management, the documentation points to AWS Key Management Service (KMS). The encryption page lists which resources you can encrypt with your own key, for example custom models from customization jobs, agents, data source ingestion jobs for knowledge bases, and model evaluation jobs.
• You can encrypt agents with your own key when you create them, in the console or with the customerEncryptionKeyArn field in the CreateAgent call. Decide on this before you create the agent.

Common mistake: Setting your own KMS key on one resource and assuming everything else is covered. Go through the resource list on the encryption page and write down, for each one, which key encrypts it and who may use that key.

Step 2: A private network with a VPC endpoint and PrivateLink

What to do: Connect your systems to Bedrock privately, without going over the public internet, and limit what is allowed through that connection.

How:

• According to the documentation, you can use AWS PrivateLink to create a private connection between your VPC and Bedrock, without an internet gateway, NAT device, VPN connection or Direct Connect connection. Instances in the VPC don't need public IP addresses.
• The FAQ puts it this way: private connectivity from your VPC to Bedrock without exposing your data to internet traffic.
• Create an interface endpoint and attach an endpoint policy to it. The default endpoint policy allows full access to Bedrock through the endpoint, and to restrict it you attach a custom policy.
• The documentation has an example policy that allows only bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream. It is shown in the example below.

Common mistake: Creating the endpoint and leaving the default policy on it. The connection is private, but every Bedrock action is still allowed through it.

Step 3: Data use, model training and model provider access

What to do: Write down in the project's risk register what AWS says about data use, including the caveat about storage for abuse detection, and set your retention settings.

How:

• According to the FAQ, AWS and the third-party model providers will not use any inputs to or outputs from Bedrock to train Amazon Nova, Amazon Titan or any third-party models.
• Also there: your content is not used to improve the base models and is not shared with any model providers.
• The documentation explains the mechanism: in each Region there is a Model Deployment Account per model provider, owned and operated by the Bedrock service team. Model providers have no access to those accounts, so they have no access to Bedrock logs or to customer prompts and completions.
• The caveat: the abuse detection page says that in certain limited circumstances AWS may also store or review model inputs or outputs. This applies to specific models listed on that page, not to every model. For most OpenAI models, classifier-flagged traffic is retained for up to 30 days for automated offline abuse detection. For Anthropic Claude Fable 5 and Claude Fable 5.1, all traffic is retained for up to 30 days, and classifier-flagged traffic may be subject to human review by AWS. Retained inputs and outputs are stored and processed by AWS and are not shared with third-party model providers.
• You are in control: Bedrock gives you explicit control over whether the prompts and outputs from your inference requests are retained. Read the page, check the setting in every Region you use, and check whether the model you chose is on the abuse detection retention list.
• For another layer on the content itself, Amazon Bedrock Guardrails provides configurable safeguards. AWS gives a banking example there: an application that blocks user queries or model responses about seeking or providing illegal investment advice.

Common mistake: Writing "Bedrock does not store prompts" in the risk register with no qualification. The accurate wording: AWS and the model providers don't train on inputs and outputs, the model providers don't receive them, but for specific models listed on the abuse detection page AWS may keep them for up to 30 days (for most OpenAI models, classifier-flagged traffic; for Claude Fable 5 and 5.1, all traffic), and you control the retention settings.

Step 4: Regions and cross-Region inference

What to do: Decide which Region you work in, and whether a request may be processed in another Region.

How:

• With cross-Region inference you choose a profile tied to a geography (such as US or EU) or a global profile. With a geographic profile Bedrock selects a commercial AWS Region within that geography, and with a global profile it selects a commercial AWS Region.
• With a geographic profile, requests to a profile tied to a geography (such as US, EU, and APAC) stay within that geography. Your prompts and outputs might move outside your source Region, and to the extent data is stored for abuse detection, it is stored in the destination Region.
• All data sent between Regions stays on the AWS network and does not cross the public internet, and it is encrypted in transit.
• When you have data residency requirements, AWS recommends geographic cross-Region inference.
• To see where a request was actually processed: CloudTrail logs all cross-Region inference requests in your source Region, in the additionalEventData.inferenceRegion field.
• If your organization blocks unused Regions with SCPs, you must allow all destination Regions of the geographic profile, or add an inference profile exception.

Common mistake: Picking a global profile because it "just works", without checking your organization's data residency requirements. Document this decision and get it approved by compliance.

Step 5: IAM permissions

What to do: Give each application permission only for the actions and models it needs.

How:

• The starting point: by default, users and roles have no permission to create or modify Bedrock resources, and an IAM administrator has to create policies that grant it.
• The policy examples page has an example that allows bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on one provisioned model, and an example that denies inference on a specific foundation model, which can also be used as an SCP across the organization. The example below combines the structure of the first with the resource format of the second.
• If you use cross-Region inference profiles, the documentation suggests using the bedrock:InferenceProfileArn condition to limit the exception to specific inference profiles.

Common mistake: Granting bedrock:* on all resources "just for development" and forgetting to narrow it before production. Start narrow and widen only when there is a need.

Step 6: Logs with CloudTrail and model invocation logging

What to do: Make sure there is a record of who called which model and when, and decide whether to also keep the content of requests and responses.

How:

• Bedrock is integrated with AWS CloudTrail, and CloudTrail captures all Bedrock API calls as events.
• The InvokeModel, InvokeModelWithResponseStream, Converse and ConverseStream calls are logged as management events.
• To keep request and response data there is model invocation logging. Supported destinations are Amazon CloudWatch Logs and Amazon S3, and only in the same account and Region.
• Model invocation logging is disabled by default. Once it is enabled, logs are stored until the logging configuration is deleted.

Common mistake: Turning on model invocation logging and forgetting that the logs now hold customer data. The bucket or log group needs encryption, narrow permissions and a deletion policy, just like the original system. And the reverse: if you decide not to keep content, write down the decision and the reason.

Compliance and standards

According to the FAQ, Bedrock is in scope for common compliance standards such as FedRAMP Moderate, SOC and ISO, it is HIPAA eligible, and customers can use Bedrock in compliance with GDPR.

The detail by program, as it appears on the Services in Scope pages and other official AWS pages:

Three notes on the table:

• Most rows show Bedrock with excludes Amazon Bedrock Marketplace. If you use models from Marketplace, check them separately.
• The ISO list also appears in the Bedrock FAQ. We found CSA STAR only on the combined ISO and CSA STAR certification page, not as a separate listing.
• HIPAA eligible means the service is eligible for workloads involving electronic Protected Health Information (ePHI). It does not mean your system meets HIPAA.

Where the reports are. You download third-party audit reports through AWS Artifact, a self-service portal with on-demand access to AWS compliance reports. That is what you send to compliance or to an auditor, not a screenshot of a table.

AWS compliance does not make your system compliant. Your compliance responsibility is determined by the sensitivity of your data, your company's compliance objectives, and applicable laws and regulations. AWS covers the infrastructure under the shared responsibility model. The settings from the six steps, your processes, permissions and documentation are on you.

Financial organizations that report their use publicly

These are financial organizations that AWS has published a case study about, describing their use of Bedrock. The description here is shortened and based only on what the page says.

Keep in mind: these are pages AWS wrote and published. They describe the use as presented at the time of publication, and they don't list all of the organizations' security settings. They show that financial organizations chose the service. They don't replace your own review.

One-page checklist

Encryption

• At least TLS 1.2 on every connection to AWS
• A list of Bedrock resources, and for each one: which KMS key encrypts it
• A key policy that limits who can use the key

Network

• An interface endpoint through PrivateLink
• A custom endpoint policy, not the default
• The servers that call Bedrock have no public IP address

Data

• In the risk register: no training on inputs and outputs, no sharing with model providers
• In the risk register: whether the model you chose is on the abuse detection retention list (up to 30 days), and what is retained for it
• The data retention setting checked in every Region
• Guardrails configured for the use case

Regions

• A primary Region chosen and documented
• A documented decision on cross-Region inference: none, geographic or global
• SCPs updated if you block Regions

IAM

• Each application has its own role
• Permission only for the inference actions and the models in use
• No bedrock:* in production

Logs

• CloudTrail on and retained
• A documented decision on model invocation logging
• If enabled: an encrypted destination, narrow permissions and a deletion policy

Compliance

• The relevant reports downloaded from AWS Artifact
• Checked that the programs your organization needs list Bedrock, and that you are not relying on Marketplace

Questions for compliance before you connect customer data

• Which types of data may be sent to the model, and which must be masked first?
• Is the model we chose on the abuse detection retention list? If so, is retention of up to 30 days acceptable to us, or should we pick another model?
• May a request be processed outside the primary Region?
• How long do we keep logs that hold content, and who may read them?
• Who approves a change to permissions or to the model?
• Do we need to update customers, the privacy policy or a regulator?

Full example: North Wallet (a fictional organization)

North Wallet is a fictional fintech with about 40 employees that runs a payments app. The support team wants an automatic summary of each ticket, so the next agent doesn't have to read the whole history. The data includes names, phone numbers and transaction descriptions.

Here is how the team goes through the six steps.

Step 1, encryption. The team checks that every internal service connects with TLS 1.2 or later. It creates a dedicated KMS key for the project and sets a key policy so only the application role and the security role can use it. At first there are no agents and no knowledge base, but the decision is written down: if they are added, they will be encrypted with the same key at creation.

Step 2, network. The summary server sits in a private subnet with no public address. The team creates an interface endpoint for Bedrock and attaches a policy that allows inference only. The default policy is replaced before the server sends its first request.

Step 3, data. Before sending to the model, the server replaces phone numbers and card numbers with fixed placeholders. The team reads the abuse detection page and checks whether the chosen model is on the list of models where AWS may store inputs and outputs. It checks the data retention settings in the Region and adds a Guardrail with a sensitive information filter. All of this goes into the risk register, including the caveat, in AWS's own words.

Step 4, Regions. The team picks one Region in Europe. Compliance approves cross-Region inference only with an EU geographic profile, if one exists for the chosen model, and not with a global profile. The organization's SCP is updated to allow the profile's destination Regions.

Step 5, IAM. The summary server has its own IAM role, with permission for bedrock:InvokeModel and bedrock:InvokeModelWithResponseStream on one model only. It has no permission to create agents, change logging settings or reach other models.

Step 6, logs. CloudTrail is already on in the account. The team turns on model invocation logging to a dedicated S3 bucket, encrypted with the same KMS key, with access for the security team only and automatic deletion after 90 days. The 90 days is North Wallet's decision, not AWS's.

Compliance. The compliance officer downloads the SOC 2 report and the ISO 27001 certificate from AWS Artifact and adds them to the vendor file. The file says plainly: the reports cover AWS's infrastructure. North Wallet's own settings are checked separately, in an internal review before go-live and once a quarter after that.

The result. After two weeks there is a pilot with ten agents. Compliance has one page that explains where the data goes, who can see it, how long it is kept, and how to check that. Every line on it links to AWS documentation or to a setting in the account.

Disclaimer

This content is general recommendations only, not professional, legal, accounting or tax advice, and not security advice. Every organization is different, and every financial organization has its own requirements. You are responsible for checking that it fits your situation, and for checking the settings, policies and code before you use them.

The information about AWS and Amazon Bedrock was checked on November 2, 2026 against the linked pages, and it may change. Compliance lists, available models and data retention rules are updated. Check the official documentation before any decision. The mention of financial organizations is based on pages AWS published, and is not an endorsement of any service or vendor.

Before you connect customer data to Bedrock or to any other AI service, consult a security professional and your compliance officer or compliance function.

The content, templates and code are provided as is, with no warranty that they fit a particular purpose or are free of errors. Gindi Innovation and Aviad Gindi are not liable for any damage, direct or indirect, arising from using them or relying on them, including output from AI tools. Use is subject to the site terms.