How to Export Audit Evidence from Azure API Management and Log Analytics

Treat evidence as a deliverable with requirements

Raw log collection is not evidence. An auditor needs records that are complete for the scope under review, retained for the agreed period, unaltered, reproducible and accessible only to authorized people. Writing these requirements down before touching any configuration prevents most rework.

NIST SP 800-53r5 asks organizations to consider the evidence needed to support control assessments when they select and implement controls. It leaves the event types to be logged and the retention period as organization-defined values, so those decisions are yours to make and document. NIST SP 800-228 gives a useful starting checklist for API telemetry: a timestamp, client ID, request and response status, and an endpoint identifier, along with who called, which method and from what origin.

Use those fields as the acceptance test for the later steps. For every API in audit scope, you should be able to point to a column that answers each one. Where a field is missing, record the gap and the compensating source rather than leaving it for the auditor to discover.

Configure diagnostics to capture audit-relevant events

Azure Monitor diagnostic settings on the API Management instance determine what leaves the service and where it goes. Create a setting that sends the gateway log categories relevant to your audit scope to a dedicated Log Analytics workspace. Keep the workspace separate from general operational workspaces so that access and retention can be set for evidence purposes.

After enabling, map the audit fields to the tables and columns that actually receive data. Check that caller identity, method, origin, endpoint, status and applied policy information appear for every in-scope API, not only for a sample of test calls. Confirm whether request and response bodies are captured at all. In most regulated deployments they are deliberately not stored, and the evidence design should say so explicitly.

Set workspace retention to at least the period you defined earlier. Workspace defaults are operational settings, not audit decisions, so compare them with your requirement and change them where they fall short.

• Scope: List the APIs, products and subscriptions the audit covers.
• Categories: Enable the gateway log categories that carry caller, request and status data.
• Field map: Document which column answers each required field and note gaps.
• Retention: Match workspace retention to the defined evidence period.

Preserve integrity, access control and chain of custody

NIST SP 800-92 notes that retaining logs as evidence can involve different storage and processes, including additional restrictions on access. Treat evidence storage as a separate tier from operational logging.

The controls below support integrity and chain of custody. Their exact configuration options should be checked against your tenant before you rely on them in an audit narrative.

• Least-privilege access: Limit workspace roles and, where available, table-level access to those who must query evidence.
• Restricted evidence storage: Place exports in a dedicated storage account with write-once or immutability settings where supported.
• Configuration change records: Retain the Azure activity log for diagnostic settings, retention and role assignment changes.
• Custody log: Record who exported what, when, with which query, and who received it.
• Periodic review: Audit log management operations and test retrieval of older records.

What gateway logs cannot show, and where enforcement evidence fits

Gateway and workspace telemetry describe traffic that passed through the gateway: who called, which endpoint, what status, and which policy ran. For AI workloads that is necessary but often not sufficient. A gateway record does not by itself show what an agent did with a response, which tools it invoked downstream, or whether sensitive content in a prompt was handled according to policy. Payload capture, if enabled, adds storage and privacy obligations of its own.

NIST SP 500-293 expects audit information at a high level for monitoring and at a level of detail sufficient for forensic analysis. Gateway logs usually serve the first and part of the second. Document this boundary in your evidence package so the auditor sees a stated scope rather than an implied one.

For AI traffic, policy enforced in the execution path (allow, redact, block) can produce evidence at the level of individual interactions and tool calls. Trussed enforces policy at runtime in that path and generates audit-ready evidence from those enforcement decisions. This complements, and does not replace, gateway and workspace logs: the gateway shows the traffic, and runtime enforcement evidence shows what was permitted, changed or stopped within it.