What Regulators Actually Ask When They Audit Your API Platform

Audit preparation for API platforms is often done reactively: a questionnaire arrives, engineers scramble to pull evidence, and the process reveals gaps that require either remediation or uncomfortable explanations. The better approach is to understand the questions before the audit arrives — and to design your platform so the answers are already in your observable, queryable infrastructure.

This post organises the most common regulator and auditor questions about API platforms into categories, explains what technical evidence is typically required, and maps each question to the specific platform capability that generates that evidence.

Category 1: Access control and identity

These questions appear in nearly every audit framework. They are the foundation of API platform governance.

"How do you control which partners and applications have access to which APIs?"

What the auditor wants: Evidence that access is governed by a documented policy, enforced by a technical control, and not simply a matter of trust or convention.

Evidence required: A documented access control model showing that access is granted per-client, per-product, with explicit scope. Demonstration that a client attempting to call an endpoint outside their granted scope receives a 403 response.

Platform capability: Zerq's access profiles bind a client credential to a specific set of API products with explicit scope. Access is enforced at the gateway layer, not at the application layer. A client outside their scope is rejected before the upstream service is called.

"Who has administrative access to your API platform, and how is that controlled?"

What the auditor wants: Evidence that the management plane has RBAC, that admin access is granted on a need-to-know basis, and that changes made by admins are logged.

Evidence required: A list of active users with their roles. Evidence that viewer-role users cannot make configuration changes. Audit records showing management actions attributed to specific user identities.

Platform capability: Zerq's RBAC model has distinct roles (viewer, editor, administrator). Role assignments are in the platform's user management. Every management action — by any role — produces an audit record with the actor's identity and role at the time of the action.

"How do you handle partner offboarding? What happens to their API access when a partnership ends?"

What the auditor wants: Evidence that access is revoked promptly and completely when a relationship ends — not left active in a system that no one reviews.

Evidence required: A documented offboarding procedure. Evidence that revoked credentials stop working immediately. Audit record of the revocation action.

Platform capability: Credential revocation in Zerq takes effect immediately — a revoked credential is rejected at the next gateway request, within one token validation TTL. The revocation action is in the audit log with the timestamp and the actor who performed it.

Category 2: Audit trail and logging

"Show us all access to [specific API or data resource] during this period."

This is the most common forensic question in compliance audits. The period might be a quarter, a specific incident window, or the last 12 months.

Evidence required: A filterable audit log that can produce a list of: which client identities called which endpoints, when, with what authentication, and what responses they received. The log must be complete — no gaps for AI-initiated calls, script-initiated calls, or off-hours access.

Platform capability: Zerq's gateway audit log records every API call with: client identity, endpoint, HTTP method, response status, timestamp, and session correlation ID. The log is in your MongoDB instance, queryable with standard tooling. AI agent calls appear in the same log as human-interactive calls.

"What controls do you have over who can read or modify the audit log?"

What the auditor wants: Evidence that the audit log is protected from tampering — particularly by administrators who might want to conceal their own actions.

Evidence required: Access controls on the audit log storage. Documentation of the retention policy. Evidence that log records cannot be deleted by platform admins.

Platform capability: Zerq's audit data is in your MongoDB instance. MongoDB's access controls can be configured to grant platform service accounts write access to the audit collection while restricting delete operations. Your DBA team applies the same controls they apply to other compliance-relevant data.

"How long do you retain audit logs, and can you demonstrate access to historical records?"

Evidence required: A documented retention policy. A demonstration query retrieving records from the retention period.

Platform capability: Retention is controlled by your MongoDB storage capacity and your retention configuration. There is no vendor-side data expiry — records remain as long as your MongoDB instance retains them.

Category 3: Credential and secret management

"How are API credentials issued, managed, and rotated?"

What the auditor wants: Evidence that credentials have a lifecycle — they are issued with an owner, they are rotated on a schedule, and they are revoked when no longer needed. Evidence that there is no class of "forgotten" credentials with indefinite validity.

Evidence required: A credential inventory showing all active credentials with: owner, issue date, expiry date, and last-used date. Evidence of a rotation procedure. Records of credentials revoked in the review period.

Platform capability: Zerq's client credential management tracks all active credentials with their associated client records and access profiles. Credentials can be issued with explicit expiry. The audit log records issuance, rotation, and revocation events with timestamps and actor identity.

"How are upstream API credentials and secrets managed? Are they stored in plain text?"

What the auditor wants: Evidence that credentials used by the platform to call upstream services are encrypted at rest and are not accessible to anyone who can read the platform's configuration files.

Evidence required: Documentation of credential storage and encryption. Evidence that credentials are not in source control or unencrypted config files.

Platform capability: Zerq encrypts credentials at rest in MongoDB. Integration with Vault or a secrets manager allows upstream credentials to be fetched dynamically at runtime, never stored in environment variables or config files.

Category 4: Data residency and privacy

"Where is your API platform's configuration and audit data stored? Does it leave our jurisdiction?"

This question is particularly common in EU/GDPR contexts, financial services under national banking regulation, and government contracts with data sovereignty requirements.

Evidence required: Documentation of where data is stored, who has access to it, and whether it is transmitted to third-party services.

Platform capability: Zerq's configuration and audit data is in your MongoDB instance, in the region and jurisdiction you choose. There is no Zerq-operated SaaS control plane that your data passes through. You can demonstrate data residency by showing the MongoDB connection string pointing to an in-jurisdiction instance.

"Does your API platform use any third-party SaaS services that process our data?"

What the auditor wants: A complete list of subprocessors and a data flow map showing what data each subprocessor receives.

Evidence required: A documented subprocessor list. Data processing agreements with each subprocessor. A data flow map.

Platform capability: Zerq's data plane and management plane run in your environment. The only third-party services that process your data are the ones you choose to integrate (your IdP, your MongoDB provider, your LLM provider for Copilot). There is no mandatory Zerq-operated SaaS in the data path.

Category 5: AI and automation governance

These questions are increasingly appearing in audits as AI agents become common in enterprise environments. For EU AI Act compliance, they will be mandatory for high-risk AI system deployments.

"When AI agents make API calls, how do you ensure those calls are authorised and audited?"

Evidence required: Evidence that AI agent credentials are governed by the same RBAC and audit controls as human-initiated API calls. A sample audit record showing an AI agent call with identity, scope, and timestamp.

Platform capability: AI agent traffic in Zerq goes through the same gateway, the same access profile enforcement, and the same audit log as human-driven API calls. There is no separate AI-access path that bypasses controls.

"Can you demonstrate that your AI systems cannot take actions beyond their authorised scope?"

Evidence required: A demonstration that a request from an AI agent to an endpoint outside its granted scope is rejected. Documentation of how scope is defined and enforced.

Platform capability: AI agent credentials are bound to access profiles with explicit endpoint scope. An agent attempting to call an endpoint outside its scope receives a 403 at the gateway layer, before the upstream service is called. This can be demonstrated live in a test environment.

"How do you detect and respond to anomalous AI agent behaviour?"

Evidence required: Documentation of monitoring controls. Evidence of alerting when agent behaviour deviates from baseline. A sample incident response for anomalous agent activity.

Platform capability: Zerq's AI-assisted anomaly detection identifies deviations from established call patterns per client — including AI agents. Alerts are triggered when call volume, error rate, or endpoint coverage changes anomalously. Rate limits provide a hard ceiling on agent call volume regardless of behaviour.

Preparation principle: evidence before the questionnaire

The common pattern in all of these questions is that they require queryable, documented evidence — not assertions. "We believe our audit log is complete" is not a satisfying answer. "Here is a query that returns the complete audit record for client X during Q2" is.

Design your API platform so that audit evidence is a query, not a project. The evidence should be in your MongoDB instance, accessible through standard tooling, in a format that your compliance team can present without engineering involvement.

The questionnaire will arrive. The platform that produces evidence on demand passes audits faster and with fewer findings than the platform that requires manual assembly.

This post covers the most common audit questions. Specific regulatory frameworks (FCA, OCC, BaFin, FINRA, etc.) may have additional requirements. This is not legal advice — work with your compliance counsel on your specific regulatory obligations.

See Zerq's security and compliance capabilities and architecture for the full technical foundation, or request a demo to walk through audit preparation specific to your regulatory framework.