DORA compliance and your API gateway: what financial institutions need to implement

Enlarge

The Digital Operational Resilience Act became applicable to EU financial institutions on 17 January 2025. In the months since, platform teams at banks, payment processors, and investment firms have been working through what DORA's ICT risk management requirements mean for individual systems. The API gateway is one of those systems — and the DORA compliance requirements that land on API infrastructure are more specific than most teams expect.

DORA doesn't just require that you have an API gateway. It requires that your gateway gives you documented, auditable ICT risk controls: proof that third-party access is scoped and controlled, that every configuration change is recorded with actor identity, that credentials have defined rotation schedules, and that all of this evidence stays inside your own operational boundary. Most gateways handle traffic. Fewer handle evidence.

Why standard gateways don't close the DORA gap

Kong, Apigee, and AWS API Gateway are competent proxies. They weren't designed around DORA's documentation and audit requirements.

Kong's audit log capability requires the Enterprise tier, and even then the log schema isn't structured for the compliance workflows regulators ask for: who changed the rate limit policy, when, from which IP, and what was the configuration before the change. Apigee's audit data lives in Google Cloud's infrastructure. For firms with EU data residency requirements, or for those subject to DORA's operational resilience expectations around critical ICT systems, that creates a structural problem before you've written a single line of configuration. AWS API Gateway logs to CloudWatch, but CloudWatch log entries don't carry the per-client, per-TPP identity context that makes them useful for third-party risk documentation. You have a log record. You don't have the access control evidence that goes with it.

The architectural problem is that these gateways were built for throughput and developer experience. The compliance evidence layer was added later or delegated to a SIEM. That approach works until a regulator asks for a point-in-time record of which third parties had access to which APIs, with what credentials and what restrictions, over a specific time window. At that point you're assembling evidence across four different systems and hoping the timelines reconcile.

What DORA compliance requires from your API gateway

DORA's ICT risk management chapter (Articles 5-16) creates five concrete obligations that map directly to API gateway configuration:

1. Access documentation: which third parties can call which APIs, under what authentication method, with what restrictions
2. Change auditability: every change to access controls or routing must be recorded with actor identity and timestamp
3. Third-party risk management: each external integration must be individually catalogued, access-controlled, and monitored
4. Credential lifecycle: credentials must have defined rotation schedules with evidence that rotation occurred
5. Operational boundary: audit and configuration data must remain within the firm's own infrastructure

These aren't abstract principles. A DORA supervisory review will ask for specific records: the credential rotation history for a specific TPP over the past year, the change log for a payment API's rate limit policy during a given period, and a current access inventory showing which third parties are active and what they can reach.

How Zerq addresses each requirement

Access documentation: the client and profile model

Zerq's access control model maps directly to DORA's third-party risk requirements. Every API consumer (an application, a service account, or a registered TPP) is represented as a client. Each client has one or more profiles defining how that consumer authenticates and what restrictions apply. Clients are then assigned to specific collections, which are the API products they can reach.

For a TPP registered under PSD2 and subject to DORA third-party risk obligations, the configuration for that client looks like this:

The IP allowlist means credentials issued to FinCorp only function from their registered network range. A compromised certificate still can't be used from an arbitrary endpoint. The collection assignment means this TPP can discover and call only the payment initiation and account information APIs. The payment fraud API, the internal reporting API, anything outside those two collections is invisible to them regardless of credential validity.

A TPP licensed only for account information services gets collection access to account-information only. You can produce this access inventory at any time, for any specific date, from the platform configuration.

Change auditability: the audit log schema

Every configuration change in Zerq creates an entry in the audit log, stored in the customer's own MongoDB instance. Each entry captures the full context of the administrative action:

{
  "timestamp": "2026-04-15T09:23:44.312Z",
  "actor_id": "[email protected]",
  "actor_type": "user",
  "action": "UPDATE",
  "resource_type": "policy",
  "resource_id": "pol_tpp_standard_789",
  "ip_address": "10.20.1.45",
  "user_agent": "Mozilla/5.0 (Management UI)",
  "request_id": "req_audit_abc456",
  "request_body": {
    "rate_limit": { "max_requests": 500, "interval": "1m" }
  },
  "response_status": 200
}

The request_body field carries the new configuration state. Reading the audit event immediately before this one gives the previous state. For a DORA review, this entry alone answers the standard question: who changed the rate limit policy for this TPP, from which workstation, at what time, and what is the new value.

The actor_type field distinguishes between a human user, a service account, and a system action, which is important for separating a planned policy change from an automated operation during an incident. The ip_address and user_agent fields support forensic investigation if a change is unexpected. This structure applies to every create, update, and delete operation across collections, proxies, clients, policies, and credentials.

Setting up auditor access for the compliance team

DORA's separation of duties expectation means the people who review access controls should not be the same people who modify them. Zerq enforces this through an explicit Auditor RBAC role. Setting it up takes minutes:

1. In the management UI, go to Settings > Users
2. Click Invite user and enter the compliance officer's email address
3. Set their role to Auditor
4. The user receives a passwordless magic-link sign-in. No password to manage or rotate, which removes one credential lifecycle problem entirely
5. Once signed in, they see the Audit Logs section in the sidebar with full filter and search access
6. They can filter by actor ID, resource type, action (CREATE, UPDATE, DELETE), date range, or source IP
7. For SIEM integration, they query the audit log API endpoint and forward the structured JSON to Splunk, Elastic SIEM, or Microsoft Sentinel for long-term retention

The Auditor role cannot access Collections, Proxies, Clients, or Policies in any edit mode. They see all changes but can change nothing. The assignment of the Auditor role is itself an audit log event, so the compliance team's access grant is on record with the same actor identity and timestamp as any other configuration change.

Third-party risk monitoring: per-client traffic visibility

DORA requires ongoing monitoring of ICT third-party relationships, not just initial onboarding documentation. Zerq's request logs include client_id and profile_id on every entry. You can filter all traffic to a specific TPP by client ID and produce a usage report for any time window: which endpoints they called, at what volume, and what response codes they received.

If a TPP needs to be suspended pending a risk assessment (DORA Article 28 anticipates exactly this scenario), you set their profile to inactive. All requests from that TPP immediately return 401. The deactivation event appears in the audit log with actor identity and timestamp. When the risk assessment clears, re-activating the profile restores access using the same credential and configuration, with no reconfiguration of the TPP's systems required.

For rate limit policy changes, the standard DORA change management process applies: change is made in the management UI by an authorised user, the audit log records the before and after state, and the compliance team sees it in their next review cycle without needing to request a report from the platform team.

Credential lifecycle: rotation with evidence

DORA's ICT security requirements expect demonstrable credential management practices. When you rotate a TPP's gateway credential:

1. Open the client profile in the management UI
2. Click Rotate credentials
3. Set an expiry period for the new credential; 90 days is a common starting point for regulated TPP access
4. The old token is immediately invalidated across all sessions
5. The new credential is displayed once; copy it for secure out-of-band distribution to the TPP
6. The rotation event is written to the audit log, including the actor ID, timestamp, and the new expiry window

For mTLS profiles, the certificate is validated at the TLS handshake. Certificate replacement follows the same pattern: update the profile, the old certificate stops working, the change appears in the audit log. For organisations running HashiCorp Vault or a comparable secrets manager, Zerq can reference credentials by secret path rather than storing values in the platform configuration. The gateway holds a reference; the actual secret value is fetched at runtime from the customer's Vault instance, and never appears in Zerq's configuration or audit records.

Operational boundary: no external control plane

DORA's operational resilience requirements include maintaining control over critical ICT systems without dependency on third-party platforms. Zerq's deployment model is a single Go binary running in the customer's own infrastructure, deployed on-premises, in a customer-managed cloud region, or fully air-gapped. There is no external control plane. No configuration data, audit records, or request logs leave the customer's environment during normal operation.

All audit and request data are stored in the customer's own MongoDB instance. The management UI, developer portal, and gateway binary all run inside the customer's boundary. If Zerq as a company were to cease operations, the deployed gateway would continue serving traffic without interruption. That's a direct answer to DORA's concentration risk concern: no critical function depends on an external service the firm doesn't control.

DORA readiness checklist for API infrastructure

Before a supervisory review, verify each of these against your gateway configuration:

• Every registered TPP or ICT third party has its own client record with named contact information
• Each client's profile specifies the authentication method, allowed HTTP methods, and IP restrictions that match the contractual and risk agreement
• Collection assignments reflect current contractual scope: a TPP not licensed for a service cannot reach that collection
• Credential rotation has occurred within the last 90 days for every active production profile
• The compliance team has Auditor-role access to the management UI with no edit permissions
• Audit logs are exported to the SIEM on a defined schedule meeting your retention requirement
• All configuration changes in the last audit period have actor IDs traceable to named individuals or service accounts
• The gateway deployment has no runtime dependency on external control planes or cloud-hosted configuration services

This list maps directly to what EBA and national competent authorities examine during DORA supervisory assessments.

What this looks like in practice

A European bank serving registered TPPs under PSD2 and subject to DORA configured Zerq with a separate client for each registered third party. Payment initiation and account information are separate collections. A TPP licensed only for account information cannot call or discover the payment initiation endpoints regardless of credential validity.

Rate limits reflect the TPP's contractual tier: standard registrations get 200 requests per minute, premium-tier partnerships get 500. IP restrictions are configured from each TPP's registered ASN ranges. The compliance team has auditor-only accounts and runs a weekly review of all policy and credential changes using the audit log date-range filter. Monthly, they export the full audit record to their SIEM for five-year retention.

When the national competent authority conducted a supervisory review and requested evidence for a specific three-month window, the platform team produced the complete access record in under an hour: which TPPs were active, what collections they could reach, when credentials were last rotated, and every configuration change affecting their access during the period. The evidence came entirely from Zerq's audit and request logs, stored in the bank's own MongoDB cluster, with no dependency on a third-party log aggregation service. For more on how regulated banks approach this architecture, see Zerq's banking and open banking use case.

Summary

DORA's ICT risk management requirements for API infrastructure come down to four things: documented per-TPP access controls with method and IP restrictions, immutable change history with actor identity, credential lifecycle management with rotation evidence, and audit data that stays inside your own operational boundary. Each requirement maps directly to Zerq's access control model, audit log schema, Auditor RBAC role, and on-premises deployment architecture. The compliance evidence layer isn't a separate tool you add later: it is how the gateway operates from the start.

Zerq is an enterprise API gateway built for regulated industries — one platform for API management, AI agent access, compliance audit, and developer portal, running entirely in your own infrastructure. See how it works or request a demo to walk through your specific requirements.