How to Audit Whether a Document Processing API Truly Retains Zero Data or Only Claims To

A document processing API offers genuine zero data retention only when its contracts and architecture rule out persistent storage across the agreed data path. This audit separates systems that cannot retain document content by design from systems that merely promise to delete it later. SOC 2 and ISO 27001 certifications do not prove ZDR, and a GDPR agreement must spell out the retention commitment.

Why "zero data retention" needs a definition before it can be audited

“Zero data retention” often names four different policies. No training use means the provider may still store prompts for a period it sets. No storage after the response means the prompt and completion exist only while the request runs. A bounded review window means the provider keeps prompts for a stated time before deleting them, while storage until opt-out means it keeps them until the customer asks it to stop. These are not interchangeable promises.

For this audit, genuine ZDR means content is processed in volatile memory, never written to persistent storage, and discarded when the session ends. Deletion later does not meet that definition. The audit rests on three pillars, which are a precise scope, a binding contract, and technical evidence that the system follows it. Default behavior across API providers is storage rather than ephemerality, so default terms cannot stand in for an explicit ZDR commitment.

Where the data path actually branches — and why a single ZDR toggle does not cover it

A document request passes through more than the extraction service. An API gateway receives it, a queue may hold it, and an observability stack may record what happened. Databases and support tools also need to be checked. A provider-side ZDR setting governs only the storage within its scope. The audit therefore starts with the route.

Sub-processors are a common escape hatch from that scope. Processing location is not necessarily storage location, and inference may route globally unless a region is specified. The buyer needs to know where each sub-processor handles content and where it can persist. Otherwise, a promise about one service leaves the next hop unexamined.

Endpoint exclusions create another branch in the audit. Persistent conversation history, files APIs, batch queues, and deferred completions may be excluded even when ZDR is enabled for the account. Batch processing needs its own test because asynchronous submissions may be kept under a failsafe time-to-live before the job finishes. A defensible deployment inventories every copy and marks each hop as either processing in memory and discarding, or explicitly outside ZDR coverage.

What the contracts must say before any technical audit begins

A web page is not a binding audit baseline. A signed MSA or Data Processing Addendum can be, provided it includes the commitment and audit rights. GDPR Article 28(3)(a) requires processing on the controller’s documented instructions, so retention purposes and periods belong in those instructions. Article 28(3)(g) requires deletion or return of personal data at the controller’s choice when service ends. Article 28(3)(h) requires the information needed to show that the rules are being followed and allows audits, including inspections.

For a vendor questionnaire, the first question is whether the provider stores prompts or document content, for what stated purpose, and for how long. The second asks which categories the commitment covers, including request bodies, response bodies, derived metadata, usage records, and logs. The answer for each category must be clear and in writing. The third asks what documented instruction disables default retention and whether that instruction appears in the DPA or exists only as a console toggle. A technical test cannot resolve a contract that leaves these categories undefined.

GDPR Article 25(2) includes the storage period within its data-protection-by-default obligation. GDPR allows case-by-case agreements without always requiring ZDR, and an undocumented opt-in switch is not enough to demonstrate how storage limits are built into the system. The buyer needs the written instruction and the controls that implement it.

The technical tests that distinguish architecture from assertion

The first test follows the document through the system. Create a canary payload with a unique synthetic marker and no real personal data, then send it through every production route in scope. Search authorized logs, traces, queues, databases, support tools, and exports for that marker. An ephemeral route passes when no content remains after processing. An approved stateful route must expire the marker as documented, a result that verifies its retention policy.

Next, ask for a syscall audit trail from load tests that use strace -e trace=write,openat. The evidence should show that proxy processes make no disk writes while handling as many requests as they would in real use. Idle behavior is not enough to pass. A disk write from those processes fails this test and requires investigation against the in-memory-only claim. This test covers the observed processes, so it does not replace checks of the other hops.

Then inspect memory before and after processing. Take heap snapshots around sample requests that contain tagged canary values, then search later snapshots and on-disk artifacts for those strings. The canary should be absent after processing ends. Finding it fails the claimed immediate cleanup. This distinguishes a system that avoids disk storage from one that also discards content from memory when its work is done.

Search production log volumes for personal-data patterns and inspect support tooling and observability dashboards for request or response content. A passing implementation records operational metadata such as timestamps, session identifiers, token counts, latency, and policy enforcement outcomes without recording the payload. Content in a log is still retained content.

Finally, verify the pipeline’s operating rules against those observations. All transformations, including declarative mapping and normalization, must run in volatile memory, with payload data wiped immediately after the HTTP response is sent. Redis, Memcached, and database tables must not receive payloads for pagination or rate limiting. Failed-request queues must be stateless and store metadata only. API logs may capture status codes, latency, and endpoint URLs, but request and response bodies must be actively stripped. A violation of any rule fails that part of the claimed ZDR scope, even if the main extraction path passes.

The audit trail problem: how ZDR shifts logging obligations to the buyer

Genuine ZDR hands audit-trail responsibility back to the buyer. Once the provider discards prompts and completions, it cannot produce that content later for a compliance review. The buyer’s client-side infrastructure must record whatever the law or its own policy requires. The provider handles its retention commitment, while the buyer designs the record needed to account for its own use.

A metadata-only trail records timestamps, session identifiers, token counts, latency, policy enforcement outcomes, and anomaly flags. It excludes prompts, responses, and derived document values. Such a trail proves that processing happened under stated controls without reproducing what was processed. It can support SOC 2 and GDPR audit requirements. Even though it preserves genuine data ephemerality, it should not be taken as meeting all HIPAA audit requirements.

The buyer must therefore decide what to log before turning on ZDR. For invoices, payslips, or bank statements, that means identifying the audit obligations attached to the document type rather than adopting one logging rule for every workload. Where applicable obligations require full prompts and completions, the buyer must confirm that its own infrastructure captures them. That creates buyer-side retention, even if the provider retains nothing. The distinction needs to remain explicit so that a provider-side ZDR claim is not mistaken for end-to-end ephemerality.

What compliance certifications do and do not verify about data retention

SOC 2 evaluates service controls. It does not establish that a particular data category is never persisted. ISO 27001 certification is not a substitute for that evidence either. A provider can hold both certifications while retaining content for a bounded review window, routing inference globally, or lacking a workable data-subject rights process. The relevant certification scope may also leave out sub-processors.

The first question for the security team is what the reports actually cover. Request the SOC 2 Type II report and examine logical access controls under CC6.1 and change management, which are relevant to how ZDR controls are protected and changed. Read the ISO 27001 scope statement for the specific service being purchased. Coverage of one part of the infrastructure does not establish coverage of the document pipeline.

Second, check whether the GDPR DPA names sub-processors, specifies residency, and expressly includes the Article 28(3)(h) audit right. The third asks what technical evidence the provider will share, including executive summaries of penetration tests or third-party architecture reviews. These provide more visibility than badge images alone. For mortgage, healthcare, payroll, and insurance workloads, the decision turns on whether the evidence covers the endpoint and document type in use. The DPA must then commit the provider to ZDR for that same scope.

How to evaluate a document processing API's ZDR claims specifically

A PDF text layer may hold hidden text that gets into logs even when the visual rendering is discarded. Uploads with more than one page may pass through a staging bucket or batch queue before extraction starts. Those intermediate copies need their own scope decision. Confidence scores and extracted field values also need scrutiny because deleting the source document does not establish that its derived outputs were deleted.

The evaluation should follow the document from upload through staging, extraction, and delivery. Ask which steps fall under ZDR, then run the canary through every production route, including batch and asynchronous paths. Confirm that the DPA names sub-processors and specifies residency for the fields being processed. Then check that confidence scores and extracted outputs receive the same retention treatment as the raw document.

Extraction quality signals can support this review, but they answer different questions. Field-level confidence scores traceable to source pixels provide bounding-box provenance for extracted values. A signed per-field accuracy SLA with financial consequences gives the provider a contractual reason to invest in validation. Neither feature alone proves that the source document or its values disappear after processing.

Deployment options also need to match the agreed boundary. On-premise or single-tenant options are relevant for sensitive document types, while EU and US deployment options need explicit residency terms in the DPA. A console location setting is not the contract. The audit still needs to establish which sub-processors, if any, remain in the chosen data path. Ask for a metadata-only audit log that proves processing occurred without reproducing document content.

The final buying decision should state in writing whether ZDR is on by default or is an option, and whether it requires a separate paid arrangement. The best basis for choosing a provider is a signed scope that matches the actual endpoints, with tests that pass on all those routes. The buyer must decide separately how to handle retention for anything left out of that scope.