Compare LLM gateways for SOC 2, HIPAA and GDPR (2026)

In November 2026, Portkey lists SOC 2 Type 2 and custom BAAs on Enterprise, LiteLLM is SOC 2 Type II audited, and Requesty holds SOC 2 Type I with its Type II audit period under way. To compare LLM gateways for SOC 2, HIPAA and GDPR, test those statements against the agreements, retention settings and records for your own workflow.

Compare the evidence by gateway

This table records published evidence in November 2026. Use it to build your document request list before reviewing the route your own data will take.

For SOC 2, collect the report for the service you intend to use. For healthcare workflows, map every party that receives protected health information (PHI) and establish which business associate agreements (BAAs) apply. Portkey's Enterprise listing gives you a starting point; the agreement and the configuration carrying your traffic are the documents to examine.

For GDPR, Requesty's data processing agreement (DPA) and sub-processor list cover the gateway portion of the data flow. Add the selected model and its processing location to the same review.

BAA status by model provider

A gateway agreement covers one part of the workflow. For each route, identify the model provider and the contracting parties, then confirm a signed BAA covers that service and that your account uses an eligible configuration. A route existing in the gateway does not mean an agreement covers it. Claude bought through a third-party cloud provider, for example, falls under that cloud provider's BAA rather than Anthropic's.

An API organization admin can accept OpenAI's Business Associate and Healthcare Addendum in the API Platform. OpenAI's instructions say accepting the agreement alone does not make an application HIPAA compliant.

Anthropic says its Covered Models require 30-day data retention. They are unavailable with zero data retention enabled unless Anthropic has expressly authorized it for the organization, so check the terms for your chosen model and route.

Separate content retention from audit evidence

A prompt can contain sensitive information, so decide what to retain before approving a workflow. On Requesty's self-serve plans, content logging is on by default: prompts and outputs are retained for up to 30 days, encrypted in the EU. You can turn logging off per API key.

Organization-wide zero data retention is available on written request. It overrides content logging for existing and future keys and disables gateway caching. Requesty does not store prompt and output content, while usage metadata including model, token counts, cost and latency is still recorded, according to the compliance report documentation.

Content retention, log retention and retention of exported audit evidence each need their own policy. Check all three against the gateway settings and the evidence you plan to keep.

The HHS Security Rule requires policies, procedures and required records of actions and assessments to be kept for six years from creation or from when they were last in effect, whichever is later. That requirement applies to required documentation; it is not a blanket six-year rule for every log.

Requesty's content retention is up to 30 days on self-serve plans, and its compliance reports cover periods of 7, 30 or 90 days. Reports are generated on demand, and Requesty does not store a report archive. Schedule downloads at intervals no longer than 90 days so the periods join up without gaps. Archive both the PDF and the verifiable JSON for your documentation retention period, including the six-year period where HIPAA-required documentation applies.

Build a record of the workflow

The record has to show which policy was in force and what traffic passed through it. Requesty's Compliance page compares current policy with observed traffic and lets admins investigate guardrail violations and configuration changes. The compliance report covers chat completion traffic.

Audit-log records describe individual activity, while compliance-report counts aggregate provider requests. Portkey's audit-log documentation lists timestamp, user, action, resource and response status among its fields.

Use Requesty's Enterprise audit log to establish when a policy changed; the compliance report snapshot shows the configuration at report time. For more on comparing audit logs, see our enterprise AI gateway comparison.

Count fallback requests separately

Suppose one user request falls back across three providers. Requesty's compliance traffic count can include up to three provider requests for that one user request, according to the report documentation.

If it reaches all three providers, that is 1 user request x 3 providers = 3 provider requests in the compliance count. When comparing application totals with the compliance report, use provider requests as the report's unit. Otherwise, a higher report count could look like extra user traffic.

Check the route before sending sensitive data

The gateway's region and the model's inference region are separate settings. Requesty's privacy policy says the Frankfurt endpoint governs Requesty's own processing, while the selected model determines where inference happens.

For an EU workflow, Requesty's EU routing documentation gives bedrock/claude-sonnet-5-5@eu-central-1 as an EU model example. An organization admin can restrict serving regions to the EU under Compliance, so requests must use an allowed regional endpoint. Limiting Approved Models to EU models also causes requests for non-approved models to be rejected.

Requesty can require zero-data-retention models for the whole organization. Its models endpoint returns fields for data retention, retention days, training use and privacy comments per model. Keep the selected model's data handling alongside the gateway policy in your review; our guide to using GPT and Claude in Europe covers the routing choices in more detail.

For a comparison of regional controls, see EU AI gateways compared.

Choose a masking mode before relying on it

Requesty's guardrails scan request content for PII and secrets before it reaches the provider. Each scanner can be set to Disabled, Report or Mask, and changing a policy creates an audit-log event.

The mode changes what the provider receives. Report mode forwards the original content; Mask mode masks PII and secrets in the request. Requesty does not scan model responses for newly generated sensitive data.

Prepare the evidence package

Start with one workflow and trace its path from the application through the gateway to the selected model. Then collect the documents and settings for that path.

For a Requesty deployment, an admin can start on the Compliance page, select a reporting period and generate the evidence report covering chat completion traffic. Then pair the archived reports with the applicable agreements and policy-change history before sending them to your reviewer.