The short answer: routing company data through models does not invent new compliance categories, it concentrates the familiar ones into a single hop. Work six criteria in order — access (CC6), audit (CC7), retention and minimization (CC3, P), encryption (CC6), confidentiality and tenant isolation (C), availability and change management (A, CC8) — and demand evidence for each, not a description. nRouter's own SOC 2 Type II is in progress.

The short answer

The moment your company's data crosses an LLM boundary, two groups start asking the same questions in different vocabularies. Your security team asks "where does this data go and who can read it." Your auditor asks the same thing as CC6.1 through CC6.8. An LLM gateway is where those questions concentrate, because it is the one hop every model call traverses: it holds the credentials, sees the payload, records the spend, and decides who may do what.

That concentration is an advantage during an audit, not a liability — a single control point is far easier to evidence than the same controls scattered across seven services that each call a provider directly. But it only helps if the controls are real. This checklist is written to be worked with a vendor on a call, and it is deliberately blunt about the difference between a control that is enforced today and one that appears in a product roadmap.

This is an engineering checklist, not legal advice. Pair it with your auditor's guidance and your own counsel.

When you need this

Your first enterprise prospect sent a security questionnaire and one section is about AI. It is usually four questions long and every one of them is really about the gateway: what is logged, who can see it, how long it is kept, and how you know one customer cannot reach another's data.

Your own SOC 2 is in scope and someone noticed the LLM calls. A subservice organization in your data path is either carved out or included, and either answer requires you to describe its controls. "We call an API" is not a description.

Legal asked what you retain and nobody had a straight answer. "We log everything, probably forever" is a harmless sentence until it appears in a breach disclosure or a data-subject access request. A written field list with a stated window is the artefact that conversation needs — the field list itself is in What an LLM request log should contain.

What you need first

The vendor's actual attestation status in writing, not a trust-page badge. See the vocabulary in step 1 — the distinction between the three states matters more than any single control below.
Owner or admin access to the account you are evidencing. Several controls are verified by looking at a screen, and members see the relevant pages read-only. Roles: Team Management.
A list of the data classes you actually send. You cannot assess retention in the abstract. If prompts carry customer names, that is a different conversation from prompts that carry document ids.
Your auditor's criteria mapping. The AICPA trust services criteria are the authority; the CC references below are signposts to speed up the conversation, not a substitute for your auditor's own mapping.

Step 1 — Fix the vocabulary before the kickoff call

Three states get collapsed into one word, and the collapse is where bad diligence starts.

State	What it means	What you can rely on
In progress	The controls are implemented; the audit period or report is not complete	The controls, if you verify them yourself
Type I	An auditor attested the design of controls at a point in time	Design only — not that they operated
Type II	An auditor attested that controls operated over a period, typically 3–12 months	Design and operation, for that window

nRouter's SOC 2 Type II is in progress. That is the honest state and it is the one we will say on a call. It means the controls below are what we build and operate against, and it means you should verify the ones that matter to you yourself rather than accepting a report that does not yet exist. Current status is on Trust and Compliance.

Apply the same skepticism in the other direction. A vendor holding a Type II report has evidence that some set of controls operated over some period. Ask which criteria were in scope, when the window closed, and whether the AI-specific data path existed during it. A report predating the feature you care about attests to nothing about that feature.

Step 2 — Access control (CC6): who can do what, and is it enforced

The question behind every CC6 sub-criterion is whether authority is enforced by the system or merely documented in a policy.

Distinct roles with distinct powers. Owner, admin, member and viewer should not be four labels on one permission set. On nRouter, owners and admins can edit or revoke a key and run a rotation; members can create keys; viewers can see keys and usage and change nothing. Verify by logging in as each.
Management authority separated from usage. The credential that creates and deletes keys must not be the credential that makes model calls. On nRouter, customer traffic authenticates with a virtual key and never with the management credential — the reasoning is Virtual keys vs master key.
No provider credentials in your hands. A gateway that asks you to paste a provider key has moved a secret into your estate and your audit scope. nRouter holds the provider credentials; you never handle one. Why that is a deliberate design choice, not a limitation: Why we don't do BYOK.
Secrets displayed once. The full key value appears exactly once, at creation; afterwards the dashboard shows the name and last four characters and there is no reveal control, because the value is not retrievable.
Scope is enforced per credential. Each key is bound to exactly one team and carries an optional model allowlist, an endpoint allowlist and a CIDR allowlist. A denied request is rejected before the key is consumed, so it costs nothing. Field reference: API Key Management.
Credential lifetime is bounded. Keys support an expiry — Never, 30 days, 90 days, or a custom datetime. "Never" is the default and is the wrong choice for a service-to-service credential.
MFA available on privileged accounts.

Step 3 — Audit trail (CC7): can you reconstruct who did what

The gap auditors find here is almost never "there is no audit log". It is that the log covers most mutating actions.

Every privileged mutation is recorded — key created, rotated, revoked; member added, removed, role changed; budget or setting changed. On nRouter, key create / rotate / revoke events record the actor, source IP and timestamp, and each key row links to its own activity. The view is /[organization]/audit; reference: Audit Log.
Attribution is complete and consistent. Actor, action, target, source and timestamp on every entry. An action logged without an actor is an entry that cannot answer the question the log exists for.
Entries are not editable through the product surface. Append-only is the property; the design pattern that gets you there is in Building a tamper-evident audit trail.
Model calls and admin actions are separate stores. Request logs at /[organization]/logs answer "what did this call do"; the audit trail answers "who changed the configuration". Conflating them makes both worse — one is high-volume and short-lived, the other is low-volume and long-lived.
Correlation identifiers reach your side. x-nr-request-id comes back on every response. Store it next to your own trace id, or every incident starts with a timestamp search.

Step 4 — Retention and minimization (CC3, P): what is actually stored

This is the section where vendor answers most often describe a roadmap in the present tense, so read the current state carefully — including ours. If any of the traffic is personal data, the same evidence answers GDPR Article 5, whose data-minimisation and storage-limitation principles are what a field list and a stated window demonstrate.

Ask what is stored, field by field. On nRouter, request logs carry identity (request id, key, organization), shape (model, provider, token counts), outcome (status, latency) and money (settled cost).
Ask specifically whether prompt and completion content is stored — and press on the word "stored". It is the highest-value question here, and the honest answer is usually two answers. On nRouter, content is never written to the request log: the log carries identity, shape, outcome and money, and no prompt or completion text enters it. Separately, a response body may sit for a few minutes in a short-lived serving cache, keyed to your organisation and team, so a byte-identical repeat request skips the provider call. That is a cache and not a record — not queryable, not exported, gone on its own — but it is not nothing, and a vendor who answers this question with a flat "we don't store content" has given you an answer you cannot take to an auditor. Ask for both halves: what is retained for you, and what transits a cache. Full-content logging is a roadmap item; do not build a control narrative around it, and do not let an auditor cite it as an enforced capability.
Then ask whether you can turn the cache off, and whether the answer is observable. A cache you cannot opt out of is a fact about the vendor; a cache you can opt out of per call is a control you can scope to the data classes that need it. On nRouter, caching is off unless it is enabled for the deployment you call; where it is on, you can switch it off for the whole organization in Router Settings, and "nrouter_cache": false in the request body keeps a single call out of it entirely — not served from the cache, not written into it — and the response header reports which of those happened, so compliance with the opt-out is something you can evidence rather than assert. The trade is latency, not money: a cache hit is metered and billed like any other request, so an opted-out call pays only the full provider round trip every time. Decide per data class, not once for the whole account, and write the decision down — an auditor asking why a control exists but is unused wants the reasoning, not the toggle. See Response caching.
Know the retention window and whether you can change it. Request logs are currently retained for 90 days, and that window is not configurable today. If your policy requires a shorter or longer window, that is a gap to raise now rather than discover during fieldwork.
Do not credit an unenforced redaction control. A PII control exists under Localization and is not yet enforced. Treat it as absent until it is, and design around the fact that content is not stored rather than around a redaction step. The engineering trade-offs for when content storage does arrive are in Redacting PII from LLM logs.
Separate financial records from content. Ledger entries are a different class with a different obligation and a different lifetime; they hold amounts and identifiers, not prompts. See How to read your LLM credit ledger.
Count every downstream destination. Log-forwarding callbacks to Langfuse, Datadog, S3, GCS, Slack and custom HTTP endpoints are configurable and verifiable with Test connection; automatic streaming of request logs is in Beta and not yet active. Plan the topology now, and remember that every destination you add is another place data lives, another subservice in your scope, and another processor to paper under GDPR Article 28 — see Set Up LLM Log Callbacks: Datadog, Langfuse, S3, Slack.
A documented deletion path for data-subject requests — the access and erasure duties in GDPR Article 15 and Article 17 are only answerable if you can name every store the data reached.

Step 5 — Encryption, transport and tenant isolation (CC6, C)

TLS on every hop, with no plaintext fallback, between you and the gateway and between the gateway and each provider.
Credentials encrypted at rest, never in plaintext configuration or environment files checked into anything. Encryption in transit and at rest is the worked example in GDPR Article 32, and the control families an auditor will map yours against are catalogued in NIST SP 800-53 Rev. 5.
Security headers on customer-facing surfaces — a content security policy, HSTS, and frame protection.
Isolation enforced below the application, not only in it. The control question is: if application code had a bug tomorrow, would one organization's query return another's rows? The answer has to be no because the data layer refuses, not because the query was written carefully. Scope resolution is described in Org, team, member: scoping keys, budgets, guardrails.
Tenant identity is resolved from the authenticated credential, never from a header, body field or query parameter a caller can set. A gateway that accepts a caller-supplied tenant id has an attribution spoof, and it will show up as somebody else's spend before it shows up as a breach.
Isolation is proven by a test that has failed on purpose. A policy that has never returned zero rows in a deliberate cross-tenant probe is unvalidated, not correct. Ask the vendor to describe the probe, not the policy.
Content controls run inline on the request path. Guardrails — PII detection, regex filters, keyword blocklists, injection detection, custom webhook — run pre-call and post-call, and a blocked request never reaches the provider. The threat classes worth naming in the narrative are the OWASP Top 10 for LLM Applications; prompt injection sits at the top of it. Reference: Guardrails.

Step 6 — Availability and change management (A, CC8)

An upstream outage is survivable. Provider fallback should be configuration, not a redeploy — Provider fallback chains.
Spend safety holds under concurrency. Ask what happens when many requests race the last dollar. A cap that is correct serially and wrong in parallel is not a cap: Reserve-and-settle.
Limits are layered, not a single number. Credits, budgets, rate limits and guardrails are four independent gates with four different failure codes — the four pre-flight gates.
Alerting exists and is bound to a destination somebody reads. Budget thresholds bind to channels under Alerts & Notifications.
Configuration changes are reversible without a deploy. Versioned prompt templates are the canonical example — Server-Side Prompt Templates: Version, Roll Back, A/B Test.
Controls are covered by tests that run before merge, and someone can show you one going red.

Verifying it worked

Evidence, not description. Five checks you can run in an afternoon on your own account.

Prove the role boundary. Log in as a viewer and attempt to revoke a key. The control is real when the attempt fails, not when the documentation says it would.
Prove the audit entry exists. Create a throwaway key, revoke it, then open /[organization]/audit and confirm both events with actor, source IP and timestamp. Screenshot it — that screenshot is your evidence artefact.
Prove the key display rule. Reload the Keys page after creation and confirm the full value is gone and only the name and last four remain.
Prove correlation reaches you. Send one call and capture the headers; the request id must appear both on your side and on the row at /[organization]/logs.

curl -sS -D - -o /dev/null https://api.nrouter.ai/v1/chat/completions \
  -H "Authorization: Bearer $NROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-5.4-mini","messages":[{"role":"user","content":"ping"}]}' \
  | grep -i '^x-nr-'

Prove a gate bites. Attach a $0.01 Total budget to that throwaway key and send two calls; the second returns 429 with key_budget_exceeded. A control you have watched reject a request is evidence. A control you configured is a hypothesis.

What goes wrong

A trust-page badge is treated as a report. Ask for the attestation letter, the criteria in scope and the window. Where the answer is "in progress" — as ours is — the correct response is to verify the individual controls, not to disqualify or to assume.

A roadmap capability is written into a control narrative. This is the failure mode this post exists to prevent. Full-content logging and the Localization PII control are not enforced today, and log-forwarding delivery is in Beta. Citing any of the three as an operating control produces a finding at fieldwork, and it is a finding you created yourself.

Retention is assumed to be configurable. The 90-day window is not adjustable today. If your policy demands 30, that is a gap in your control environment as much as in ours, and it is far cheaper to identify in diligence than in an exception report.

Callbacks are added without extending scope. Every forwarding destination is another processor holding your data. Redaction has to apply before the fan-out; redacting on display while the raw value already sits in a downstream store is theatre.

Isolation is evidenced by a policy listing rather than a probe. A rule that exists and a rule that has ever been exercised are different claims. Ask for the probe, and for what it returned.

Try it

Every control surface referenced here — role separation, per-key scoping and expiry, the audit trail, request logs, guardrails, budgets and rate limits — is available on every plan. Plans vary the platform fee (4% on Pay as you go, 0% on Pro at $50/mo or $500/yr) and the default rate limits, never the feature set, so the compliance posture of a $50/month account and a six-figure one is the same posture. That policy has its own argument in Every Feature on Every Plan: We Charge a Fee, Not a Gate.

Load the $5 minimum — the platform fee rides on top — then work the verification section above against your own organization rather than taking this page's word for any of it. Start at app.nrouter.ai/signup.

Bringing an auditor or a security questionnaire? Trust and Security carry the current posture, Enterprise is the route for a diligence call, and questions get answered in the nRouter community.

Sources

Verified 2026-06-11. Product behaviour, dashboard paths and control states come from nRouter's own documentation; the criteria framework is the AICPA's, and every external reference below was re-checked on 2026-08-23. If something has drifted — and control states do drift, which is why each is dated — email hello@nrouter.ai and we will correct it.

AICPA Trust Services Criteria (the CC / A / C / P references above): aicpa-cima.com
GDPR minimisation and storage limitation, behind step 4: Article 5, with the subject rights that make a deletion path mandatory at Article 15 and Article 17
GDPR processor obligations, behind the callback-scope warning: Article 28
GDPR security of processing, behind step 5: Article 32
NIST SP 800-53 Rev. 5, the control catalogue auditors map CC6 against: csrc.nist.gov
OWASP Top 10 for LLM Applications, the threat list behind the guardrail bullet: owasp.org
Roles, and which role may create, edit or revoke a key: Team Management
Key scoping, expiry, rotation and audit events: API Key Management
Audit-log contents and access: Audit Log
Logging levels, retention and log fields: Observability
Response caching, its tenant-keyed scope and the per-request opt-out: Router Settings
Guardrail types, actions and placement: Guardrails
Current attestation status: nrouter.ai/trust

SOC 2 for an LLM Gateway: The Evidence an Auditor Asks For