API Compliance: GDPR, HIPAA, SOC 2 & PCI Guide

Every API that touches a patient record, a card number, or personal data covered by GDPR can fall within the scope of an audit. It makes no difference that the data moved through a REST endpoint instead of a database console. Auditors ask the same questions: who accessed the data, under what authority, and can you prove it?

This guide is about making your own APIs comply with GDPR, HIPAA, SOC 2, and PCI DSS, not about hosted "compliance APIs" that run KYC checks. It covers what each framework requires, the controls they share, and what changes when APIs send regulated data to LLM providers. It sits within the broader API governance program.

What Is API Compliance?​

API compliance is the practice of ensuring your APIs meet the regulatory, industry, and internal-policy requirements that apply to the data they handle. It covers how APIs authenticate callers, limit access, protect data, record activity, and respond to incidents. Where a compliance standard applies to the data, it follows that data into every API that handles it.

The term also names an unrelated product category. A "compliance API" is a third-party service that screens transactions or verifies identities. It is a tool you might use inside a compliant system, not the system itself.

Why API Compliance Is Harder Than It Looks​

Most of these regulatory requirements were written before API-first architecture was common. GDPR talks about controllers and processing, and HIPAA talks about information systems that contain ePHI. Neither mentions gateways, tokens, or OpenAPI specs. Where an obligation applies, it also covers the APIs that carry the regulated data. Your team has to translate legal language into gateway policy, logging configuration, and access rules.

The translation breaks down in predictable places. The OWASP API Security Top 10 lists the patterns that also show up as audit findings:

• Incomplete inventory (API9:2023): You cannot prove controls on an API nobody knows exists. Deprecated versions and forgotten debug endpoints often still return regulated data.
• Weak authentication (API2:2023): Shared service credentials and long-lived static keys make it impossible to say which person or system made a call.
• Misconfiguration (API8:2023): A gateway with a permissive route, a disabled TLS check, or verbose error output can undo controls that look correct on paper.
• Missing monitoring: Logs that exist but capture the wrong fields, or no one reviews, rarely satisfy an auditor.

There is also an ownership gap. Compliance teams own the policy, platform teams own the gateways, and application teams own the code. API compliance holds only when all three work from one set of enforceable rules.

The Frameworks That Matter Most for APIs​

GDPR, HIPAA, SOC 2, and PCI DSS often appear together in enterprise security questionnaires. They are different kinds of obligation, and treating them as interchangeable leaves gaps.

GDPR​

The General Data Protection Regulation governs the processing of personal data of the people in the EU. Determine whether it applies from your organization's establishment, processing activity, role, and territorial reach. It applies to processing in the context of an EU establishment, wherever the processing takes place. For non-EU organizations, Article 3(2) can apply when they offer goods or services to people in the Union or monitor their behavior there. Citizenship or residence alone is not the test. Once GDPR applies, any endpoint that accepts or returns personal data, such as a name, email address, device identifier, or location, is in scope.

Several articles translate directly into API design decisions:

• Lawful basis (Article 6) and data minimization (Article 5). Each endpoint should collect only the fields its documented purpose needs. A profile API that returns full birth dates to a service that only checks age is a minimization problem.
• Data subject rights (Articles 15, 17, and 20). Access, erasure, and portability requests need an operational path. Teams usually expose internal APIs that locate, export, or delete a person's data across systems. The right to erasure is the hardest to implement once data has spread into caches, logs, and downstream services.
• Security of processing (Article 32). The regulation names pseudonymisation and encryption of personal data as examples of appropriate measures.
• International transfers (Chapter V). GDPR does not impose a blanket data residency rule. It restricts transfers outside the EEA unless a mechanism such as an adequacy decision or standard contractual clauses applies. Your API routing and hosting choices determine where data actually flows.

HIPAA​

The Health Insurance Portability and Accountability Act applies to covered entities, such as providers and health plans, and to their business associates. Three rules matter for APIs. The Privacy Rule limits how protected health information (PHI) is used and disclosed. The Security Rule sets safeguards for electronic PHI. The Breach Notification Rule defines who must be told after an incident.

The Security Rule's technical safeguards at 45 CFR 164.312 map closely to API controls. Unique user identification is a required specification. Service identities are not banned, but each access to ePHI must be uniquely attributable and authorized, including the initiating user where relevant. Audit controls must record and examine activity in systems that contain ePHI. Encryption is "addressable," which requires a documented assessment. If it is reasonable and appropriate, implement it. If not, document why and implement an equivalent alternative measure if that is reasonable and appropriate.

Business Associate Agreements (BAAs) are the contractual layer. A vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity, to perform a function or service regulated by HIPAA, is generally a business associate. Narrow exceptions exist, such as the conduit exception for transmission-only services. HHS guidance on cloud services confirms this holds even when the provider only stores encrypted data and holds no key.

SOC 2​

SOC 2 is not a law. It is an attestation report produced by an independent CPA firm under AICPA standards. The examination covers controls relevant to security, availability, processing integrity, confidentiality, or privacy. Security is always in scope. The others are included when the service organization chooses them.

A Type 1 report evaluates control design at a point in time. A Type 2 report also tests whether the controls operated effectively over a review period. That is why enterprise buyers ask vendors for a Type 2 report specifically. It is evidence that access reviews, change management, and logging actually happened, not just that a policy exists.

For API teams, SOC 2 works in both directions. Customers ask for your report, and you ask for the reports of the third parties your APIs depend on.

PCI DSS​

The Payment Card Industry Data Security Standard is a contractual standard from the PCI Security Standards Council. Card brands and acquirers enforce it on any entity that stores, processes, or transmits cardholder data. Version 4.0.1 has been the only active version since v4.0 retired at the end of 2024.

PCI DSS v4.0.1 names APIs directly in its secure software requirements. Requirement 6.2.4 lists attacks on business logic, including manipulation of APIs, among the attack types development practices must prevent or mitigate. Requirement 6.3.2 requires an inventory of bespoke and custom software and the third-party components inside it. For most teams, that inventory has to include internal and partner APIs. Vulnerability scanning remains periodic under Requirement 11.3, and public-facing web applications need an automated technical solution that detects and prevents web-based attacks under Requirement 6.4.2.

The full requirements are in the PCI SSC Document Library. The most effective API control is usually scope reduction. Tokenizing card numbers early can reduce scope by keeping most of your APIs away from primary account numbers. Not seeing a PAN does not by itself take a system out of scope, though. Systems connected to the cardholder data environment, or able to affect its security, can remain in scope.

Comparing the four frameworks​

Common Controls to Map to Your Applicable Requirements​

Four frameworks and five controls. Map each control once at the platform layer, then record which requirement it meets, whether it applies to you, and the evidence you keep.

The four frameworks look different on paper, and their technical demands overlap. They are not identical mandates, though. Applicability, assessment scope, risk-based obligations, and implementation detail differ by framework. Use the controls below as a starting map. For each one, record the specific requirement, whether it applies to you, how you implement it, and the evidence you keep.

• Encryption in transit and at rest: Encrypt regulated data in transit and at rest where your applicable requirements and risk analysis call for it. GDPR names encryption in Article 32. PCI DSS requires strong cryptography for card numbers sent over open, public networks. HIPAA lists it as an addressable safeguard.
• Individual user attribution: Every request that touches regulated data should trace to a specific person or a specific workload identity. HIPAA requires unique user identification. PCI DSS Requirement 8.2.1 requires a unique ID for every user. SOC 2 auditors test logical access against the same principle.
• Audit logging with retention: Record who called which operation, on whose behalf, when, and with what result. PCI DSS Requirement 10.5.1 sets the most specific retention rule. It requires twelve months of audit log history, with the most recent three months immediately available.
• Least-privilege access controls: Scope tokens to the operations and fields a client needs. Use role based access for human users and narrow OAuth scopes for services. Review grants on a schedule.
• A maintained API inventory: Know every API, version, and owner. PCI DSS makes this explicit, and every other framework depends on it implicitly.
• Incident response: Document how you detect, contain, and report an incident. Make sure your logs can answer the questions a regulator will ask inside the notification window.
• Third-party agreements: Every vendor that handles regulated data needs a contract that matches the framework. That means a data processing agreement under GDPR Article 28, a BAA under HIPAA, or service provider terms under PCI DSS Requirement 12.8. Where it supports your own audits, request their SOC 2 reports too.

Individual attribution is a common audit failure, and the cause is often the log format. The first entry below attributes the call to a shared integration account. It tells an auditor only that "something" read a patient record.

{
  "timestamp": "2026-09-14T10:22:31Z",
  "principal": "svc-integration",
  "operation": "GET /patients/48213",
  "status": 200
}

The second entry carries the authenticated workload, the human user it acted for, and a correlation ID that links the call to downstream activity.

{
  "timestamp": "2026-09-14T10:22:31Z",
  "client_id": "claims-portal-prod",
  "subject": "user:[email protected]",
  "scopes": ["patients:read"],
  "operation": "GET /patients/{id}",
  "resource_id": "48213",
  "status": 200,
  "correlation_id": "c7f2a9e4-1b6d-4f0e-9a51-3d8e2f61b0aa"
}

The second format reduces exposed clinical detail and improves attribution. It may still contain PHI or other personal data through the resource identifier and its context. Restrict access to these logs, minimize the fields you record, and apply appropriate encryption and retention controls. The correlation ID can link the call back to a person for anyone who can join it to other systems, so limit who can resolve it.

API Compliance and AI: What Changed​

None of these frameworks has an exemption for AI. When an application sends a prompt containing personal data or PHI to an LLM API, that call is processing regulated data. It is subject to the same rules as any other third-party API call. European regulators have said so directly. The EDPB's Opinion 28/2024 treats the processing of personal data during the deployment of AI models as subject to GDPR.

That has practical consequences for each framework:

• HIPAA: An LLM provider that receives PHI in prompts on behalf of a covered entity or business associate is generally a business associate. You need a signed BAA before the first request, not after the pilot succeeds.
• GDPR: The provider is usually a processor, so you need an Article 28 agreement. If the provider processes prompts outside the EEA, Chapter V transfer rules apply to every call.
• PCI DSS: A card number in a prompt pulls the provider, and potentially the whole AI path, into PCI scope. Keep primary account numbers out of prompts entirely.
• SOC 2: Your auditor may treat the LLM provider as a subservice organization and ask for its SOC 2 report as part of your evidence.

Architecture matters as much as contracts. AI traffic adds an outbound flow that many compliance programs have not mapped yet. Document each direction separately:

• Inbound API traffic: External clients call your APIs through an API gateway. The gateway authenticates the client and enforces policy before the request reaches your backend.
• Outbound AI traffic: Your applications call LLM providers through an AI gateway. The gateway authenticates the application, applies guardrails such as PII masking, and calls the provider with credentials held by the gateway rather than the application.
• Agent tool traffic: AI agents call tools over the Model Context Protocol (MCP). An AI gateway can authenticate the agent and govern which tools it may call.

These flows are independent, and a given application may use only one of them. Map each flow separately. The control plane that configures the gateways does not sit in the request path of either.

Not every team needs a dedicated AI traffic layer on day one. The usual triggers are operational. Prompts carry regulated data, or you use more than one model provider. Finance needs spend attributed by team, or an auditor asks what was sent to which provider. When one of those applies, routing AI traffic through a gateway gives you one place to enforce redaction, attribution, and logging.

How WSO2 Helps You Build and Prove API Compliance​

You can assemble the controls above from several tools. WSO2's approach is to manage API governance, API traffic, and AI traffic from a single control plane in the WSO2 API Platform.

WSO2's own independent audits​

WSO2 publishes its certifications and their scope on its security and compliance page. API Platform SaaS/Cloud is covered by a SOC 2® Type 2 attestation across the Security, Confidentiality, and Availability criteria. It is certified on PCI DSS v4.0.1 through an annual Qualified Security Assessor assessment. It is attested by an independent auditor as HIPAA compliant, and WSO2 signs BAAs on request. WSO2 also holds ISO/IEC 27001:2022 certification for its Digital Operations function and lists GDPR, CCPA, and DORA positions with defined scopes. These attestations cover WSO2's services. Your own APIs still need their own controls.

Governance rules that encode compliance requirements​

In the API Platform, you define rulesets as Spectral YAML rules and attach them to governance policies. A policy applies to every existing and new API proxy in the organization. The default catalog includes WSO2 API design and style guideline rulesets and an OWASP Top 10 ruleset. You can add your own rules, for example to require HTTPS server URLs or a documented security scheme on every operation. Violations currently trigger notifications rather than blocking a change. Because rulesets use Spectral's format, the same rule file can also run in your CI/CD pipeline with the open-source Spectral CLI.

Evidence you can show an auditor​

The Compliance Dashboard reports policy adherence at the organization, project, and component levels. You can also upload your internal compliance documents, such as a data handling standard. AI Compliance Analysis then checks your API definitions against them and reports pass or fail by guideline category. Separately, platform audit logs record administrative operations such as API proxy creation, updates, and deletion. WSO2 retains them for a total of two years. That retention applies to administrative audit logs. It is not a guarantee for request bodies, gateway access logs, or backend data-access logs, so plan retention for those separately.

Guardrails on AI traffic​

The WSO2 AI Gateway routes and governs outbound LLM traffic and governs inbound MCP traffic from AI agents. Its guardrails can detect and mask or redact PII in prompts and responses. You can apply them at the LLM provider level, per LLM proxy, or on MCP proxies. Applications authenticate to the gateway with their own keys, which are separate from the provider credential the gateway uses upstream. You can also attach a masking policy ahead of request logging, so identifying data is masked before it reaches your logs. Plan for one limitation. The PII Masking Regex guardrail matches the patterns you configure, such as email addresses and card numbers. Free-text names don't follow a fixed pattern, so regex alone may miss them. Confirm which guardrail covers them before you rely on it.

Identity for GDPR and HIPAA workflows​

WSO2 API Platform works with identity providers such as Asgardeo, Azure AD, or a custom identity provider. Issue API tokens from the same identity provider your users sign in with. That keeps attribution consistent from login to log line.

The deployment model matters for data residency. You can run the platform fully in WSO2's cloud, in hybrid mode with the gateways (the data plane) in your own data center, or fully self-hosted. Hosting gateways locally gives you control over where they run, and the gateways you host become part of your own compliance scope. Data residency still depends on every configured destination and export path. Map and restrict model calls, logs, telemetry, and other external processing.

Conclusion​

GDPR, HIPAA, SOC 2, and PCI DSS differ in legal force, scope, and the evidence they expect. Underneath they converge on the same technical foundation: encryption, individual-user audit logging, least-privilege access, a maintained API inventory, and documented incident response. That foundation now extends to the LLM APIs your applications call with regulated data.

Build those controls once at the platform layer, map inbound and outbound flows separately, and keep evidence ready. To see how governance, API traffic, and AI traffic fit under one control plane, explore the WSO2 API Platform.

Frequently Asked Questions​

Is SOC 2 a law?​

No. SOC 2 is a voluntary attestation report issued by an independent CPA firm. Customers often require it by contract, but no regulator mandates it.

Does GDPR apply if my company is not in the EU?​

It can. GDPR applies to organizations outside the EU that offer goods or services to people in the EU or monitor their behavior. Where you are headquartered does not settle the question, and neither does where your servers run.

What is the difference between HIPAA and SOC 2?​

HIPAA is a US law that governs protected health information. SOC 2 is an audit report on a service organization's controls. A SOC 2 report can support HIPAA due diligence, but it does not establish HIPAA compliance by itself.

Do I need a BAA before sending PHI to an LLM API?​

In most cases, yes. A provider that receives PHI on behalf of a covered entity or business associate is generally a business associate, so the BAA should be in place before any PHI is sent.

Does using a certified vendor make my APIs compliant?​

No. A vendor's certification covers the vendor's own controls. You remain responsible for how your APIs authenticate callers, limit access, log activity, and protect data.