How Apache APISIX supports ISO 27001 network security and logging evidence
If the API layer falls within your ISMS scope, Annex A control A.8.20 (networks security) and A.8.15 (logging) will ask you to show auditors where traffic enters, how it is encrypted, who can change the gateway, and whether gateway logs are protected. Apache APISIX can supply much of that evidence, but it does not make your organization compliant. Compliance depends on your information security policy, risk assessment, monitoring operations and the controls around the platform. DeployOpen plans and implements the gateway and prepares systems, configuration and evidence for assessment. DeployOpen does not issue audit reports or certifications. Certification bodies audit against ISO/IEC 27001:2022, and the standard's Annex A contains 93 controls in four themes.
For A.8.20, APISIX helps you define a small number of controlled entry points: routes that exist only where you have approved them, TLS on client-facing listeners, and authentication and access restrictions applied per route through plugins. The Admin API should be reachable only from a dedicated management network, and the default traditional-mode admin port, 9180, should not be exposed beyond it. Plan this separation as a design decision rather than a late hardening task. The gateway does not segment the systems behind it, so backend network controls, firewall rules and the policy that defines them remain your responsibility. Confirm the exact listener and admin settings for your APISIX version before you write them into evidence.
For A.8.15, the gateway produces access and error logs, but auditors will look at whether those logs are complete, protected and reviewed. Decide which fields are recorded, where they are shipped, who can read or delete them, and how long they are kept, and make sure configuration changes to routes and plugins are traceable. Logging that captures payloads may create its own data protection problem, so keep request bodies out of the logs. Auditors commonly sample a few routes, a few days of logs and a few configuration changes, so prepare one traceable example for each. Ask DeployOpen to confirm the sampling approach with your certification body before the assessment starts.
Mapping A.8.20 and A.8.15 to APISIX capabilities and configuration
This table pairs each requirement with the APISIX capability that supports it and the configuration an auditor will expect you to confirm. Read each row as a question to answer for your own deployment, since the standard asks for outcomes and the gateway only provides the controls. The main takeaway is that the evidence depends on how you configure listeners, admin access, TLS and log destinations, not on the product name alone.
| Requirement | APISIX capability | Configuration to confirm |
|---|---|---|
| A.8.20 Networks security: networks and network devices are secured, managed and controlled | Traditional mode separates client traffic on port 9080 from the Admin API on port 9180, and standalone mode removes the etcd-backed Admin API from the data path | Bind the Admin API to a management network only, restrict its source addresses, and record which mode each environment runs |
| A.8.20 Networks security: controlled entry points into systems and applications | Routes define which hosts, paths and methods are reachable, and ip-restriction limits callers by address | Maintain a route inventory and allowlist, and confirm that no route is exposed without an intended upstream and policy |
| A.8.20 Networks security: protection of information in transit at the boundary | TLS termination for HTTPS, HTTP/3 with QUIC support, and gRPC and WebSocket proxying | Approved protocol versions and cipher suites, certificate ownership and renewal, and documented decisions for each listener |
| A.8.20 Networks security: access to the gateway itself is authenticated | openid-connect, jwt-auth, key-auth and other authentication plugins can be applied per route | Which routes require authentication, how consumers are provisioned, and who can change plugin configuration |
| A.8.20 Networks security: managed and controlled configuration | File-driven standalone mode reloads conf/apisix.yaml or conf/apisix.json when the file changes, checked every second | Configuration version control, change approval, and who holds write access to the file or the Admin API |
| A.8.15 Logging: logs of activities, exceptions and faults are produced | Logging plugins send access and error records to external destinations, and observability plugins expose metrics | Which events are logged, log formats, and whether request bodies and sensitive headers are excluded |
| A.8.15 Logging: logs are stored and protected | Logs leave the gateway for external collectors rather than remaining only on the node | Destination access controls, log integrity and retention settings, and whether gateway logs are separated from application logs |
| NIS2 cross-reference, ENISA point 6.7 (network security) | Same capabilities as A.8.20, mapped by ENISA to the network security point of the NIS2 implementing regulation | Use the same evidence set for both frameworks and confirm the mapping against the ENISA table version you rely on |
| NIS2 cross-reference, ENISA point 3.2 (monitoring and logging) | Same capabilities as A.8.15, mapped by ENISA to the monitoring and logging point | Confirm that alerting, review and analysis of gateway logs are documented alongside collection |
Which evidence auditors sample from the gateway and how to keep it
Auditors assessing A.8.20 and A.8.15 rarely accept a single screenshot. They sample records across the surveillance period and test whether the gateway's configuration, access and logs stayed consistent over time. The cards below describe each record, how to produce it, and where to keep it so it can be sampled later.
Route inventory exported from configuration
The route inventory is the list of every entry point the gateway exposes, with upstream targets, plugins and the owner of each route. Export it from the APISIX Admin API or from the declarative configuration file on a fixed schedule, and store each export with a timestamp. Check that every route in the export maps to an approved service, and that no route exists in production that is missing from the inventory.
TLS and certificate configuration records
Keep a record of which listeners serve TLS, which protocol versions and cipher settings are enabled, and which certificates are bound to which hostnames, with expiry dates. Capture the gateway's SSL resources and the TLS settings in config.yaml at each change. Auditors typically check that deprecated protocols are disabled and that certificate renewal happened before expiry. Confirm the exact settings with your security policy and the current APISIX documentation for your release.
Admin API access and change records
The Admin API on port 9180 in traditional mode is the control path for route and plugin changes, so auditors look for who can reach it and what they changed. Record the network paths that can reach the Admin API, the API keys or roles issued to administrators, and the access logs for each call. Confirm that the Admin API is not exposed on the client-facing listener, and that each administrator has a named credential rather than a shared key.
Gateway and access log samples
Gateway access logs and error logs show the requests passing the boundary and the faults the gateway raised. Define which fields are written, where logs are shipped, how long they are retained, and who can read or delete them. Pull dated samples across the surveillance period and confirm that they contain the expected fields, that timestamps are consistent, and that write access is limited to the logging pipeline. Set the retention period with your legal and compliance owners rather than the default.
Configuration change history in version control
Store declarative gateway configuration in a Git repository so every route, plugin and certificate change has an author, a reviewer, a commit and a timestamp. Pair each merged change with its approval ticket. Auditors sample several changes across the period and trace each one back to a request and an approval. Confirm that direct edits to the running gateway are blocked or detected, because edits outside the repository break the link between the change history and the live configuration.
Records showing alerts were reviewed
Logs only support A.8.15 if someone looks at them. Keep records of the alerts raised from gateway events, such as repeated authentication failures, blocked requests or unexpected Admin API calls, along with who reviewed each one and what action followed. Sample these records to confirm reviews happened on the stated schedule. Confirm the alert thresholds and review cadence with the people who own incident response, and document any event that was escalated.
Configuration sequence for a gateway in scope for A.8.20 and A.8.15
This sequence turns an APISIX gateway into a controlled entry point with documented listeners, isolated administration, tested TLS, protected logs and recurring evidence, so that each A.8.20 and A.8.15 claim can be traced to a configuration and a record. The order matters because later steps depend on decisions made earlier, especially the deployment mode and the management network layout.
Confirm deployment mode and listener layout
The security architect and platform team choose traditional, decoupled or standalone mode and document which network segments hold the client listener, the Admin API and the etcd cluster where one is used. In traditional mode, APISIX serves client traffic on port 9080 and the Admin API on port 9180 by default, so the team records which of these are bound to which interface and which firewall rules apply. Confirm each listener and port default against the APISIX deployment modes documentation for the version in use. Done means a diagram and a listener table that the change record can reference.
Isolate the Admin API on a management network
The network team places the Admin API and any control plane components on a management network that only administrators and automation can reach, and blocks client-facing networks from those ports. Admin credentials are replaced from any default values before the gateway receives traffic, and access is limited to named administrative hosts or a bastion. Verify from a client subnet that the Admin port does not respond, and from an administrative host that it does. Keep the test output as evidence of segregation.
Define the route inventory and authentication per route
The API owners and security team list every route the gateway exposes, the upstream it reaches, the data it carries and the authentication plugin that protects it. Each route either has an authentication plugin such as key-auth, jwt-auth or openid-connect, or has a documented reason for being public. Unreviewed catch-all routes are removed. Done means the inventory matches the routes loaded in APISIX, which can be checked by exporting configuration and comparing it with the list. Confirm the exact plugin names and options against the plugin documentation for your version.
Set TLS and certificate handling
The security engineering team defines the approved protocol versions and cipher suites, issues certificates from the organization's chosen authority, and records who owns each certificate and its renewal process. Private keys are stored in a location with restricted access, and the gateway loads certificates only from that controlled source. Test each external listener with a TLS scanner and confirm that weak protocols are refused. The output is a TLS standard, a certificate register and scan results attached to the change record.
Configure access logs and forward them to protected storage
The platform team enables access logging for client and administrative activity, sets the log fields the security team has agreed on, and forwards them to a central store that the gateway operators cannot edit. Review the log format so that request bodies, tokens and personal data are not written into the log. The logging team confirms retention, access controls and integrity protection on the receiving side. Done means a test request appears in the central store with the expected fields and the operators' accounts cannot alter or delete it.
Document configuration change control
The platform owner writes a change procedure that states who may modify routes, plugins, upstreams and Admin API settings, how each change is requested, reviewed and approved, and how it is deployed and rolled back. Gateway configuration is kept in version control where the deployment mode allows, and each production change links to an approved request. Confirm with the team which changes must be reviewed against the route inventory. The output is an approved procedure and a sample change record that shows the full path.
Set up evidence collection on a schedule
The compliance lead assigns an owner to collect the listener table, the route inventory, the TLS scan results, the administrative access list, the log samples and the change records at a fixed interval set by the organization. Each collection is stored in the evidence repository with a date and the name of the collector. Ask your certification body or auditor which samples they expect and how far back they will look, since the cadence is the organization's decision. Done means the first full set has been collected and a reviewer has signed off that it matches the live configuration.
How deployment mode changes the evidence you hold
In traditional mode, the data plane and control plane run together on the same nodes, and configuration is stored in etcd. APISIX serves client traffic on port 9080 and exposes the Admin API on port 9180, so both listeners live on the same host or cluster that handles requests. Evidence about who changed a route usually sits in Admin API calls and etcd state, which means the access path to port 9180 is the first thing to document.
- Configuration location: Routes, consumers and plugin settings are held in etcd, which you must secure and back up as part of the gateway boundary.
- Change records: Admin API writes are not logged as change records by default, so you need to decide how calls are captured, for example through configuration-as-code pipelines or proxy logs in front of port 9180.
- Admin API exposure: Port 9180 is reachable from wherever the gateway node is reachable unless network controls restrict it, so segregation has to be built.
- Easy evidence: A single etcd cluster and one set of listeners make the inventory of endpoints short and simple to show.
- Extra work: Proving that only approved administrators reached port 9180 requires network policy records and access logs.
Confirm with your team how Admin API calls are recorded and who can reach port 9180 from each network segment.
In decoupled mode, the data plane and control plane are separate, and both share one etcd cluster. The control plane is where administrators make changes, while data plane nodes receive configuration and serve traffic. This split can make the admin boundary clearer on paper, but it also means the shared etcd cluster becomes a single point that auditors will ask about.
- Configuration location: Configuration is written through the control plane into the shared etcd cluster, so etcd access controls and backups define the evidence trail.
- Change records: Changes pass through one control plane, which gives a natural place to attach logging, approval records and version history.
- Admin API exposure: The Admin API sits on the control plane, so the data plane nodes that face clients do not need to expose it, which supports a cleaner boundary for network segmentation.
- Easy evidence: Showing that client-facing nodes have no administrative interface is simpler than in traditional mode.
- Extra work: You must show how the shared etcd cluster is secured and how control plane access is restricted, because a compromise there affects every data plane node.
Confirm the exact control plane and etcd network paths with the APISIX deployment modes documentation and your own architecture before writing the boundary description.
In standalone mode, APISIX runs without etcd and reads its configuration from a YAML or JSON file, or receives it through an API. For file-driven operation, APISIX checks conf/apisix.yaml or conf/apisix.json every second and hot-reloads changes without a restart. This makes the configuration file the main evidence object, and version control becomes the natural change record.
- Configuration location: Routes and policies live in
conf/apisix.yamlorconf/apisix.json, so the file itself is the source of truth. - Change records: Committing the file to a version control system with reviewed merges gives a change history that is easy to sample.
- Admin API exposure: The Admin API is not used in file-driven operation, which removes port 9180 as a management surface in that setup, but any API-based configuration path reopens it and must be documented.
- Easy evidence: A reviewed file history and a deployment record for each reload are straightforward to present to an auditor.
- Extra work: Hot reload every second means an unreviewed edit reaches traffic quickly, so you need deployment controls that prevent direct server edits and record who approved each file.
Confirm with your team whether any API configuration path is enabled, because that changes the admin exposure picture entirely.
Questions ISMS owners ask before bringing in an implementation partner
Does an APISIX gateway alone satisfy ISO 27001 A.8.20 networks security?
No. A.8.20 asks that networks and network devices are secured, managed and controlled, and an APISIX gateway is one technical component that can support that control. Auditors will also look at the network design around it, how changes to gateway configuration are approved, how administrative access is restricted, how the gateway is monitored, and whether the risk assessment and statement of applicability explain the decisions. The gateway contributes evidence to the control. It does not close the control by itself.
How much effort does a scoped APISIX compliance configuration take?
No researched figure is available for this, so the effort should be set in a written scope rather than assumed. The main drivers are the number of routes that need controlled entry, the authentication model for each route, how many log destinations must receive gateway logs, and the deployment mode. Traditional, decoupled and standalone modes place the Admin API and etcd differently, which changes the segregation work. Ask any partner to break the estimate down by these drivers and to state which items are one-time build work and which recur, such as certificate renewal and configuration review.
What does the work need from our internal teams?
Your teams supply the decisions and the access that an outside team cannot make alone. Typically this includes the network owner who approves segmentation and ingress rules, the identity team that provides the identity provider and client registrations, the security team that sets logging retention and access review rules, and the platform team that operates the cluster or hosts. Someone must own the statement of applicability entries that reference the gateway. Confirm named owners and their availability during scoping, because delays in those approvals usually extend the schedule more than the technical build does.
Can our own team implement this in-house?
Yes, if your team has the skills and capacity, and many organizations do this work internally. The questions to answer honestly are whether anyone has operated APISIX with etcd or standalone configuration, whether the team can write and review configuration as code, whether it can produce log evidence that an auditor will accept, and whether it has time to run the control after go-live. Compare the internal estimate against a written partner scope, and include the recurring work of reviews, upgrades and evidence collection in both options, since that recurring effort is often what gets underestimated.
Who certifies that our ISMS meets ISO 27001?
An accredited certification body certifies the organization against ISO/IEC 27001, not the gateway vendor, not DeployOpen and not ISO itself. Accredited ISMS certification bodies work to ISO/IEC 17021-1:2015 together with ISO/IEC 27006-1:2024. Under ISO/IEC 17021-1, a certification cycle lasts three years, with at least one audit in every calendar year. DeployOpen prepares systems, configurations and evidence for that assessment but does not issue audit reports or certificates. Check the certificate of any certification body through the IAF CertSearch database that ISO points to.
How does the 2022 control set change what we document for the gateway?
ISO/IEC 27001:2022 reduced Annex A from 114 controls in 14 clauses to 93 controls in four themes, according to IAF MD 26:2023. Eleven controls are new, 24 merge earlier controls and 58 are updated. Each control now has attributes and a purpose rather than group-level objectives. For the gateway, this means the statement of applicability should reference A.8.20 and A.8.15 directly and explain how each control is met, and the mapping from your 2013 references needs to be rechecked. Ask your partner to map each gateway configuration item to the current control wording in your own words.
How long does the gateway compliance work take?
Duration depends on the agreed scope, not on a fixed figure. A narrow scope with a few routes, one identity provider and one log destination takes far less time than a scope covering many services, several environments and multiple log sinks. Timing also depends on how quickly approvals and access are granted, and on whether the gateway must run in parallel with an existing gateway during cutover. Request a schedule with milestones in the written scope, and ask what happens to the timeline if an approval or environment is delayed.
What should we ask for in a written scope before we sign?
A useful written scope lists the in-scope routes and deployment mode, the TLS and certificate design, the segregation of the Admin API and etcd, the authentication model for each route, the log sources and destinations with their protection and retention, and the evidence that will be delivered at the end. It should name the responsibilities split between your team and the partner, the acceptance criteria, and the recurring activities after handover. Ask whether the gateway itself is in scope or only the configuration that supports A.8.20 and A.8.15.
What auditors sample and how to prepare for it
Certification bodies do not review every control in every ISMS each visit. They sample across a cycle, and for an APISIX gateway the practical question is which routes, admin changes and log records they will pick and whether you can trace each one back to a written rule. Accredited bodies operate to ISO/IEC 17021-1:2015 and ISO/IEC 27006-1:2024, and under ISO/IEC 17021-1 a certification cycle lasts three years with at least one audit, surveillance or recertification, in every calendar year. That means the gateway will be examined repeatedly, not once, so evidence needs to stay consistent from one visit to the next. Confirm the audit scope and sampling plan with your certification body early, since their approach to the gateway is their decision, not yours.
Expect a sampled route to be walked from the top down. A typical request is to pick one externally exposed API, then ask for the policy that requires it to be behind the gateway, the route definition and its plugins block showing TLS settings and access restrictions, the Admin API account that last changed it, and the change record approving that change. Then they ask for log lines showing that the route was called, that a denied request was recorded, and that the log was stored where administrators cannot edit it. Your job is to keep the chain intact: each policy statement should point to a named configuration object, each configuration object to an owner and change record, and each log source to a retention location. Test this walk yourself before the auditor arrives, using a route you chose at random.
Prepare the walk as a repeatable pack rather than a one-off demonstration. Export the current gateway configuration from the system of record you use (etcd in traditional or decoupled mode, or the YAML or JSON file in standalone mode), store the export with a date, and keep a record of which Admin API credentials existed in each period. Note where the Admin API listens in your deployment, since the default ports in the deployment modes documentation are a starting point and your network rules should reflect what you actually expose. Decide in advance how you will answer questions about logs that contain client identifiers, and confirm with your auditor how they want to see retention and access evidence rather than assuming a format.
How DeployOpen scopes and delivers ISO 27001 gateway configuration
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Apache APISIX gateways. For ISO 27001 network security and logging, we set up the gateway controls and evidence your ISMS needs, and we leave the certification decision to your accredited certification body.
How we scope
- Written scope lists which APISIX routes, listeners, admin interfaces and log sinks fall under the ISMS boundary.
- We map each gateway control to A.8.20 and A.8.15 and confirm which evidence your auditor will expect.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
How we build
- We deploy APISIX in the deployment mode and infrastructure you choose, with TLS policies and certificate handling set explicitly.
- Admin API access is restricted to a segregated management network, with separate credentials and reviewed allow lists.
- Gateway and etcd logs are forwarded to your protected log store, with access limits and retention settings documented and tested.
How we hand over
- You receive configuration as code, a control-to-evidence register, and runbooks for changes to routes and listeners.
- We test negative cases such as blocked admin access, rejected weak protocols and missing log events, and record the results.
- Handover includes a walkthrough so your team can answer sampling questions from configuration, logs and change records.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover APISIX version reviews, configuration drift checks and periodic log-protection tests.
- Confirm with your certification body which evidence period and sample set they will use before the audit cycle begins.
