APISIX and GDPR Article 32 security for APIs

How Apache APISIX supports GDPR security of processing for APIs

When an API exposes personal data, the controller must show that its security is appropriate to the risk under Article 32 of the GDPR. At the gateway, APISIX can carry several of the measures that Article 32(1)(a) and the related controls depend on: TLS for data in transit, client authentication and access restriction through plugins such as openid-connect, jwt-auth and key-auth, pseudonymisation of identifiers in logs, and structured access logging. The GDPR requires no audit, attestation or certificate, so what the gateway provides is configuration and evidence: versioned route and plugin definitions, TLS settings, consumer and role design, and log records that show who accessed which route and when. Certification under Article 42 is voluntary and does not reduce the controller's responsibility, so the gateway supports the controller's own risk assessment rather than standing in for it.

The gateway does not cover most of what makes processing lawful or safe. Data minimization inside upstream services, the legal basis for each API, the content of responses returned by the application, and transfers to third countries under Chapter V are decisions made by the controller and the application team. Breach detection and notification under Articles 33 and 34 depend on monitoring and an incident process that sit outside the gateway configuration. Where APISIX runs on a cloud provider's infrastructure outside the EEA, or where a vendor can be compelled to disclose data, the transfer analysis is still required. Confirm with your legal and privacy team which of these obligations sit with the API owners before you scope the gateway work.

Before you start, decide which API fields count as personal data, which routes carry them, and which log fields must be masked or omitted. Then ask the implementation team to show how the gateway will enforce TLS versions and certificate handling, how consumers are authorized per route, and where access logs are stored, retained and restricted. Confirm the exact logging and masking options for your APISIX version against its documentation, since plugin behavior is version-specific. A short written mapping from each Article 32 measure to a configuration item and an evidence artifact will make both the internal review and any supervisory authority request easier to answer.

Mapping GDPR Article 32 requirements to APISIX capabilities

This table compares each relevant GDPR requirement with the APISIX capability that can support it and the setting you must confirm in your own environment. Read each row as a question to answer with evidence, not as a claim that the plugin satisfies the article by itself. The main takeaway is that APISIX supplies controls, while the controller remains responsible for choosing, configuring and proving them.

Requirement	APISIX capability	Configuration to set and confirm
Article 32(1): security appropriate to the risk	HTTPS listeners on port 9443 for client traffic, with authentication plugins such as openid-connect, key-auth and jwt-auth on routes that expose personal data	Document a risk assessment per API, map each route to a risk level, and confirm which authentication plugin each route uses in your configuration
Article 32(1)(a): encryption of personal data	TLS termination at the gateway and TLS handling for upstream connections, with HTTP/3 and QUIC available in the current project	Set approved TLS protocol versions and cipher suites, enable TLS to upstream services, and confirm the setting in a test environment before release
Article 32(1)(a): pseudonymisation	Transformation plugins and custom plugins written in Lua or supported plugin runners can replace identifiers before requests reach backends	Decide which identifiers are pseudonymised, keep the mapping key outside the gateway, and document the key custody and access rules
Article 32(2): unauthorised access and disclosure	Access restriction plugins such as ip-restriction, consumer-based key checks, and the openid-connect plugin with token introspection	Restrict admin routes to management networks, set per-consumer scopes, and test that unauthenticated and out-of-scope requests are rejected
Article 32(2): alteration and loss of logs	Logging plugins for forwarding access records to external log systems, and the gateway's own error logs	Ship logs to a protected store with restricted write and delete rights, confirm retention, and exclude request bodies and personal identifiers unless needed
Article 30: records of processing for API logs	Access logs can show which consumer called which route, which is the data a record of processing typically references	Record the log purpose, fields collected, retention period and recipients in your records, and confirm each logged field against that entry
Article 32(1): regular testing and evaluation	Configuration is file-driven or stored in etcd, so changes can be reviewed, versioned and tested before deployment	Define a test plan for gateway configuration changes and confirm who approves changes that affect personal data routes

Where encryption and access control belong at the gateway

Under Article 32(1)(a), encryption and pseudonymisation are named among the appropriate measures, and an APISIX gateway gives the controller one place to enforce them for every externally reachable API. TLS can be terminated at APISIX on port 9080 for client traffic, and the upstream connection can be encrypted so that personal data is not sent in the clear between the gateway and the services behind it. The openid-connect plugin can handle authorization code, client credentials and token introspection flows against an identity provider such as Keycloak, Microsoft Entra ID or Okta, so identity checks sit at the boundary instead of being rebuilt in each service. Authentication, TLS and rate controls are configured per route, which means the controller must be able to show, for each route, which control applies and why.

Any route without authentication needs a documented justification tied to the processing it serves, such as a public health endpoint or a static asset. Review the route inventory against the records of processing so that every route carrying personal data has a named access rule. Confirm the TLS protocol versions, cipher suites and certificate handling against your own security policy and the current APISIX documentation, because defaults can change between releases and the policy should be checked at each upgrade.

The Admin API on port 9180 is the most sensitive interface in the gateway, because anyone who reaches it can change routes, plugins and credentials. Restrict it to a management network, require strong credentials and TLS, and keep it out of the client-facing listener so that a route misconfiguration cannot expose it. Treat this as a separate control with its own evidence, documented alongside the gateway configuration. Work with your privacy and security teams to confirm which of these settings the controller relies on for Article 32, since the regulation requires measures to be appropriate to the risk and the gateway is only one part of that assessment.

Minimizing personal data in API access logs

Access logs often become the largest unplanned store of personal data in an API estate, because every request line can carry an identifier. The cards below separate the decisions the controller owns from the APISIX settings and upstream changes that carry them out, so that Article 32 measures and the records of processing describe the same system.

Decide which request fields are logged

The controller decides which fields an access log needs for security, troubleshooting and capacity work, and which fields it does not. In APISIX, the access_log_format setting in the nginx_config section of config.yaml defines the fields written, so a field left out of the format is not recorded at all. Check the format against a list of fields approved by the data protection and security owners, and test it with real sample traffic before go-live.

Keep identifiers out of URLs and bodies

Query strings are written to access logs by default, so an email address or national identifier placed in a query parameter ends up in every log line and in any shared log copy. The fix usually sits upstream: the API design should move identifiers into path segments that are pseudonymous or into request headers that are not logged. Review route definitions and client integrations for identifiers in the query string, and confirm that request bodies are never written to access logs.

Pseudonymise client identifiers before logging

Where logs must correlate requests from one client, the controller can replace a direct identifier, such as a user ID or account number, with a keyed hash or token before it is written. The EDPB pseudonymisation guidelines explain that data stays personal data while the additional information needed to re-identify it is held separately. In APISIX, a custom plugin or a serverless plugin can compute the value, and the key must be stored in a secrets manager with its own access controls, not in the gateway configuration.

Set and enforce log retention

The controller sets how long each log class is kept and why, and the storage platform must enforce that period rather than relying on manual clean-up. Access logs that hold pseudonymised identifiers still need a defined period tied to the purpose, such as incident investigation or capacity planning. Ask the log platform team to confirm the deletion job, its schedule, and whether backups and archives follow the same period.

Restrict who can read gateway logs

Access logs remain personal data even when reduced, so read access should follow the same need-to-know model as other production data. Limit access to the operations and security roles that need it, record who queries the logs, and keep the log store separate from application databases. Confirm that the APISIX Admin API and its credentials cannot be used to change log destinations silently, since a changed destination can redirect logs to an unapproved system.

Separate security logs from payload logs

Security monitoring needs evidence of authentication failures, blocked requests and configuration changes, but it rarely needs request payloads. Keeping security events in a separate stream from detailed payload or debug logs lets the controller give a narrow group access to security events and keep payload capture off by default. Confirm with the security team which events must be forwarded to the SIEM, and confirm that debug logging is disabled in production configurations.

EU-hosted gateways and third-country access

When the controller runs APISIX in an EU data center on its own infrastructure, the gateway processes personal data inside the EEA. The main transfer question shifts to who else can reach the data. EDPB Guidelines 05/2021 (version 2.0) state that remote access from a third country is a transfer, even when the person only views data on a screen for support or administration. Article 44 therefore still applies to every support path, and the gateway's location alone does not settle the question.

Admin and support access: Record which staff, vendors or follow-the-sun teams outside the EEA can open the Admin API, the dashboard, the logs or the etcd cluster, and whether that access displays personal data.
Break-glass accounts: Confirm how emergency access is granted, logged and revoked, and whether it can be used from outside the EEA.
Backups and replicas: Check that etcd snapshots, log archives and disaster recovery sites stay in the EEA or are covered by a documented transfer basis.
Monitoring and telemetry: Confirm that metrics, traces and error reports sent to external SaaS tools do not carry request payloads or identifiers outside the EEA.
Ports 9080 and 9180: Keep the Admin API on port 9180 on a segregated management network, and limit client traffic on port 9080 to approved sources.

Ask your counsel and data protection officer to document the transfer analysis for each of these paths, not only for the hosting location.

Configuring the gateway for Article 32 evidence

This sequence turns an APISIX gateway into a controlled, documented layer for personal data: each API is classified, each route gets the protection its data requires, and the configuration and logs are kept in a form you can show a supervisory authority. Most of the work is design and verification, and the output is a versioned configuration that matches your records of processing.

Classify APIs by personal data sensitivity
Your data protection lead and the API owners list every API exposed through the gateway and record which personal data each one carries, such as identifiers, contact details, financial data, health data or employee records. Each API receives a sensitivity level that drives the controls in later steps. The step is complete when every route in the gateway inventory has an owner, a data category and a sensitivity level, and the list is signed off by the data protection lead. Gaps found here are cheaper to fix before any route is written.
Map routes to authentication and encryption requirements
The security architect converts each sensitivity level into concrete requirements: which routes need authentication, which need mutual TLS to upstream services, and which may only be reached from specific network segments. Plugin choices such as openid-connect, jwt-auth or key-auth follow from this map, and the identity provider design is confirmed with the team that runs it. The output is a route matrix that lists each route, its authentication method, its transport requirements and the Article 32 measure it supports. Confirm the TLS protocol and cipher policy with your cryptography owner, because it is set outside APISIX configuration as well.
Choose the deployment mode and restrict the Admin API
The platform team selects traditional, decoupled or standalone mode based on how the environment is operated. The choice decides where configuration lives: in traditional and decoupled modes, route and plugin state sits in the shared etcd cluster, while in standalone mode it is held in conf/apisix.yaml or conf/apisix.json and changed through files or the Admin API. In traditional mode, the Admin API listens on port 9180 and client traffic on port 9080, so access to 9180 is restricted to administrative networks and named operators. The step is complete when the network policy blocks the Admin API from client-facing segments and a test request from an unauthorized host fails.
Configure log fields and retention
The logging owner defines which fields the gateway writes to access logs. The default aim is to record what is needed to investigate access, such as timestamp, route identifier, consumer identifier, response status and source address, and to leave request and response bodies and query strings out unless a documented need exists. Retention periods are set by the controller in line with its records of processing and legal retention duties. The output is a log field specification and a retention schedule, and a sample of live log lines shows no field that the specification excludes.
Enable masking or pseudonymisation where needed
For routes where personal data must appear in logs or in upstream headers, the developer applies masking or pseudonymisation at the gateway. Pseudonymised identifiers must be kept separate from the means to re-identify them, a point EDPB Guidelines 01/2025 on Pseudonymisation addresses, so the key or mapping is stored under a different access regime from the logs. The step is complete when test requests show masked values in the log output, the re-identification key is confirmed to be outside the log platform's access scope, and the team has recorded which fields are masked and why.
Test controls against the route matrix
The security tester runs requests against each route to confirm the controls in the matrix: unauthenticated calls are rejected, transport uses the approved protocols, the Admin API is unreachable from client networks, and the log lines match the field specification. Failures are recorded with a fix and a retest. The output is a test report that maps each route to its evidence, which the controller can keep alongside the records of processing. Testing shows that controls work as designed, but it does not produce an audit opinion, so keep the report as internal evidence.
Export configuration as versioned files
The platform team exports the gateway configuration to files kept in version control, so each change has an author, a review and a history. In standalone mode, conf/apisix.yaml or conf/apisix.json is the configuration itself and is picked up by the gateway within a second of a change; in other modes the exported configuration is produced from the running state and checked against the repository. Changes to security-relevant routes go through the same review as application code. The step is complete when a restored copy of the repository reproduces the tested route matrix, and that copy is stored in a location the platform team controls.

Evidence a controller can show a supervisory authority

A supervisory authority will look for proof that security measures existed, were chosen for the risk, and stayed in place. The artifacts below are the records an APISIX gateway can produce, and they connect the technical configuration to the controller's documented decisions. They support the controller's own risk assessment but cannot replace it.

Versioned gateway configuration

Keep routes, upstreams, consumers and plugin settings in a version-controlled repository, whether they are applied through the Admin API or as a file in standalone mode. Each release should map to a commit, so you can show what the gateway enforced on a given date. Check that the repository holds no secrets in plain text and that deployed state matches the reviewed state.

TLS policy records

Record the protocol versions, cipher suites, certificate sources and key lengths in use on each listener, and the date each setting was reviewed. Store the certificate inventory with owners and expiry dates. Ask your security team to confirm the approved policy before you write it down, since the gateway defaults can change between releases.

Authentication and access restriction per route

Export the authentication plugin, consumer list and IP or rate restrictions attached to each route, and mark which routes are public. This shows that personal data endpoints are not reachable without authentication and that access follows a documented need. Review the export on each change, because a single route added without a plugin can expose records.

Log field specifications and retention records

Write a specification that lists each access log field, whether it contains personal data, how it is masked or pseudonymized, and where it is stored. Pair it with retention settings and deletion logs that show old logs were removed on schedule. Auditors often check whether query strings, headers and bodies were excluded from logs.

Article 30 entries for API logs

Add an entry to your records of processing for the API logs, covering purposes, categories of data subjects and data, recipients, transfers and retention periods. Article 30 applies to controllers and processors alike, so processors should keep their own records. Confirm that the entry names the actual log destinations, including any third-country hosting.

Configuration change records

Link every gateway change to a ticket, an approver, a test result and a deployment time. These records show that security settings were not altered without review and that incidents can be traced to a change. Keep them for as long as your evidence policy requires, and confirm that the retention period is set by your own legal and audit requirements.

Questions buyers ask about GDPR API security with APISIX

What does a GDPR API security implementation with APISIX cost?

No fixed figure can be given here, because the cost follows from the written scope rather than from a price list. The main cost components are the planning work (API inventory, data classification and hosting decision), the gateway build (routes, identity integration, field masking and log redaction), testing, and the hosting infrastructure you pay for directly. APISIX itself is licensed under the Apache License 2.0, so there is no license fee for the gateway software. Costs rise with the number of APIs, the number of identity providers, and how many data flows need custom plugin work. Ask any partner for a quote that separates one-time build effort from recurring support, upgrades and testing, and that lists which items are your responsibility.

How long does it take to secure APIs at the gateway for GDPR?

Duration depends mainly on the size of the API estate and how well it is documented. An organization with a complete API inventory and a classification of the personal data each endpoint handles can move much faster than one that must first discover what its APIs do. Other drivers include how many routes need encryption and access control changes, whether a single identity provider already exists, whether the gateway is new or replaces an existing one, and how long your change management and approval cycles take. Ask for a timeline tied to named deliverables and to the number of routes in scope, and confirm which parts depend on your teams, such as data owner sign-off and hosting decisions.

What must our organization provide before the gateway work starts?

The controller usually needs to supply four inputs. First, an API inventory listing every externally and internally reachable endpoint, its owner and its purpose. Second, a data classification that states which endpoints carry personal data, which categories of data they carry and how sensitive each category is. Third, an identity provider that will authenticate users and services, such as an existing OpenID Connect or SAML system. Fourth, a documented hosting decision that states where the gateway, its logs and its configuration will run and who can access them. Without these, the gateway team cannot set appropriate access rules, masking or log retention, so ask any partner to confirm these inputs in the written scope.

Can our internal platform team implement APISIX for GDPR security by itself?

Often yes, if the team already runs production gateways or Kubernetes ingress, understands TLS and OAuth or OpenID Connect, and has time for the documentation work that Article 30 and Article 32 require. APISIX provides the building blocks, including the openid-connect plugin, several authentication plugins and the ability to write custom plugins. The harder parts are usually the data classification, the decisions about what to mask or drop from logs, and the records of processing that connect technical settings to business purposes. Your team should assess its capacity for those parts, including testing and ongoing upgrades, before deciding whether to build internally, use a partner, or split the work.

Do we need a GDPR certification or an audit report for the API layer?

No. The GDPR does not require an audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. What the regulation expects is that you can show appropriate technical and organisational measures for the risk, and keep records that support that position. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, if your organization chooses to pursue them.

Does APISIX alone make our API estate GDPR compliant?

No. APISIX is a tool that can enforce some security measures that Article 32 describes, such as encryption in transit, authentication and access control, and it can help limit personal data in logs. It does not decide your lawful basis, data minimization policy, retention periods, data subject request handling or breach response, and it cannot fix insecure backend services or poorly designed data models. Compliance depends on your processes, the controls in your backend systems, your contracts with processors and your transfer assessments. Treat the gateway as one measure within a documented risk assessment, and confirm with your data protection officer or legal counsel which obligations apply to your organization.

What should we check in APISIX logs to avoid storing personal data unnecessarily?

Start by listing every field the access log writes, including request URIs, query strings, headers, client IP addresses and any consumer identifiers. Query strings and path parameters often carry email addresses, account numbers or tokens, so they are the most common source of unintended personal data. Check which log plugins or log format variables are enabled, confirm where logs are shipped, and decide retention periods that match your documented purpose. Masking or dropping fields should be tested against sample traffic, because a rule that works in staging can miss a new endpoint. Record each decision in the records of processing so the reasoning is available to an assessor.

What pseudonymised logs still count as personal data

Pseudonymised API log entries are still personal data. Under the definition in Article 4 of the GDPR, data that can be attributed to a natural person using additional information remains personal data, and EDPB Guidelines 01/2025 on Pseudonymisation take the same position. Replacing a client IP address, bearer token fragment or user identifier with a keyed hash in the APISIX access log lowers the risk to individuals, which supports the Article 32 measures discussed above, but it does not take the log out of scope. The processing record, the lawful basis, the retention period and the data subject rights position for those logs all still apply.

The practical consequence is that minimization at the gateway is a risk control, not an exit from the GDPR. If the APISIX log format keeps a remote_addr field, a consumer_name or a hashed X-Consumer-Username, the records of processing should list those fields and their purpose, and the retention schedule should set how long they are kept. Confirm with your DPO who holds the key or secret used for keyed pseudonymisation, where that key is stored, who can rotate it, and whether rotation breaks the ability to link older entries to the same person. A key that sits on the same host as the log store weakens the pseudonymisation a great deal.

Ask your DPO to decide, in writing, whether the pseudonymised logs will be treated as personal data for access requests, erasure requests and breach assessment. Most teams should assume they are. The decision also determines whether the logs can be shared with a managed logging or SIEM provider without a separate transfer assessment, since a processor that can see the key may receive personal data even when the stored value looks anonymous.

How DeployOpen scopes and delivers GDPR-aligned API gateway configuration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Apache APISIX. For GDPR security of processing on the API layer, we turn the gateway configuration into a written scope, build it in your environments, and hand over the evidence your controllers and processors need.

How we scope

We list the APIs, routes and data classes in scope, including which carry personal data and which do not.
We agree the encryption, access control and log-field decisions in writing before any configuration work starts.
Engagements are fixed-scope, with deliverables and timelines agreed in writing and a quote that follows from that scope.

How we build

We configure TLS, client authentication and route-level access controls on APISIX in your chosen deployment mode.
We set up log formats and field masking so access logs hold only the identifiers your records of processing justify.
We test the configuration against the agreed scope, confirming that the gateway behaves as the written design says.

How we hand over

We document the gateway configuration, the data flow, the retention settings and the reasoning behind each control.
We provide a records-of-processing entry template for API logs, for your data protection team to complete and approve.
We walk your platform and security teams through the configuration so they can operate and change it under your own change process.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
We can review the configuration when APISIX releases change defaults, such as TLS or plugin behavior.
We can re-test masking and access controls after new routes or data fields are added, against the agreed scope.

Apache APISIX and GDPR security of processing for APIs