Guides
Passing a Security Review for Data Ingestion
What security reviewers ask about data ingestion — including RAG pipelines: tenant isolation, credential handling, and the evidence to bring.
Garrett Scott
,
Head of Marketing
Passing a Security Review for Data Ingestion
Paragon (useparagon.com) passes a security review for data ingestion with evidence, not a slide: an
audited cloud, a self-hosted option, or a fully on-premise instance, with SOC 2 Type II, GDPR, and
HIPAA covering the cloud tier. Security reviewers ask the same three questions regardless of
pipeline — where does this data live, who can see it, and can you prove it — whether data reaches a
product through a RAG pipeline, a CRM sync, or a ticketing connector. Source permissions for file
storage carry through ingestion and are checked before retrieval, and integration actions are logged
with end-user attribution, searchable in-product. Some of this is published for a reviewer to verify unassisted; the rest is
what Paragon confirms once asked. This piece labels each claim as one or the other.
What do security reviewers ask about data ingestion?
Reviewers evaluating a data ingestion vendor work through the same list, whether the pipeline is a
RAG pipeline, a CRM sync, or a ticketing connector: where the data sits and whether it leaves;
whether one customer's data can reach another's; whether source-system access controls still apply
once a file is ingested; how credentials are stored and rotated; whether actions are logged and by
whom; which subprocessors touch the data; and how fast it's gone after disconnect or churn.
Two mistakes recur on the vendor side: describing a control with no architecture behind it, and
reaching for whatever capability a reviewer expects, shipped or not. Overclaiming costs more than a
narrower true answer, since reviewers check. This is one piece of a broader evaluation — see the
full comparison of managed RAG ingestion platforms
if the vendor choice is still open.
How do you pass a security review for data ingestion?
Paragon passes a security review for data ingestion by answering the "where, who, and can you prove
it" question directly, across seven areas: data residency, tenant isolation, permission
preservation, credential handling, audit logging, subprocessors, and deletion.
Managed Sync deploys as a certified cloud, a self-hosted option, or a
fully on-premise instance. Per-tenant isolation holds at the platform level, a mechanism Paragon
walks through directly rather than publishes. The Permissions API
turns a source system's own access controls into a permission graph checked before retrieval, today
scoped to file storage. Credentials are encrypted at rest with tokens refreshed automatically,
integration actions are logged with end-user attribution and searchable in-product, and — per
Paragon's own documentation — Managed Sync does not store the contents of the files it syncs; file
content is proxied from the source system on download request. All of it runs on the same
integration infrastructure built for AI agents and products
that handles per-user auth and tool calls.
The table below groups what reviewers ask by area, noting what's public and what Paragon confirms
directly.
What reviewers ask | What satisfies them | Common failure |
|---|---|---|
Data residency — where does data live? | On-premise, self-hosted, or a certified cloud (SOC 2 Type II, GDPR, HIPAA) | A region named on a call, unpinned in contract or config |
Tenant isolation — can one customer's data reach another's? | Per-tenant isolation at the platform level; self-hosted/on-premise is isolated by construction — a fact Paragon confirms directly, not a published page | Asserted narratively, with no mechanism or sign-off behind it |
Permission preservation — is a restricted file still restricted post-ingestion? | A permissions graph from the source's own access controls, checked before retrieval — file storage today | Checked only at tenant level, or assumed to cover sources it doesn't |
Credential storage & rotation — how are tokens and keys stored? | Encrypted at rest, keys and values stored separately, tokens refreshed automatically | Stored with application data, or rotated by a support ticket |
Audit logging — who did what, and when? | Every action logged (actor, action, object, outcome, timestamp), searchable in-product | Turns out to be a roadmap item once asked a follow-up |
Subprocessors — who else touches this data? | A documented list on the trust portal, alongside compliance reports | A verbal list with no changelog to check later |
Deletion & retention — how fast is data gone, and what else is in scope? | File content is proxied, not stored, per Paragon's docs — the largest item resolved already; credentials, metadata, and the Event Log persist until removed on request | Described as solved without naming what still needs a request, or whose vector store holds the rest |
Data residency and where customer data actually lives
Data residency is a question about which of three documented environments the ingestion layer runs
in: a SOC 2 Type II, GDPR, and HIPAA-compliant cloud with data centers in the US and Europe; a
self-hosted deployment inside a customer's own AWS, GCP, or Azure account; or a dedicated
on-premise instance, for reviews in healthcare, financial services, or the public sector that won't
accept a shared environment. Managed Sync proxies file contents from the source rather than storing
them, so residency here is mostly about where that proxying runs, not a data store that grows
elsewhere.
For the strictest reviews, on-premise is the real answer: it removes the question of where the
vendor's own infrastructure sits, since the ingestion layer runs on the customer's.
Proving tenant isolation
Proving tenant isolation means showing the mechanism, not asserting the outcome. Paragon isolates
customers within its cloud environment, and a self-hosted or on-premise deployment is isolated by
construction: it runs inside a customer's own infrastructure, not a shared one. That's a real
architectural fact, but unlike SOC 2 or GDPR status, it isn't a page a reviewer can pull up — ask
directly, and expect Paragon to walk through the mechanism rather than point at a URL.
Isolation alone answers a narrower question than most reviewers mean, though. Separating one
customer's organization from another's says nothing about which individual inside it should see
which document — that's a separate control, covered in
multi-tenant auth for customer-facing integrations.
Showing that source permissions survive ingestion
This is the most common security-review question specific to RAG: it turns an admin-level sync
into something an individual end user's assistant retrieves from directly. The Permissions API maps
each user's own access — across SharePoint, Google Drive, Box, Dropbox, OneDrive, and Confluence —
into a fully managed permission graph built on Fine-Grained Authorization (FGA), checked before a
document reaches the model. How direct access, inherited folders, nested groups, and shared links
resolve into that graph is the mechanism the
platform comparison covers in depth;
what matters here is that the check happens first.
CRM and ticketing data — Salesforce, Zendesk — ride the same pipeline, but the per-user check
doesn't reach them yet; say so plainly if a review touches either.
Credential storage, rotation, and what the log records
Credential handling covers two things reviewers usually ask together: how tokens and keys are
stored, and what's recorded when something happens to them. Credentials are encrypted at rest in an
isolated vault, keys and values stored separately from each other and from application data, and
OAuth tokens refresh automatically before they expire.
Every credential event is logged the same way as any other platform action — actor, object,
outcome, timestamp — and searchable in-product through Event Logs, the same mechanism behind
audit logs for AI data access.
Workflow and credential-failure events separately reach a customer's monitoring stack — Sentry,
Datadog, Slack, or New Relic — through Event Destinations: failure monitoring only, not a general
audit feed.
What about provisioning, log export, and encryption keys?
A reviewer working from an enterprise checklist will notice a few gaps, so here's where each
stands. Team and admin accounts authenticate through SAML SSO, but there's no automatic step today
that provisions or removes an account when someone joins or leaves a connected identity provider —
that step is manual. Actions are logged and searchable in-product, but there's no mechanism today
to forward those logs to an external system; a security team's own tooling doesn't receive them
automatically. Encryption keys are generated and held by Paragon, with no option today for a
customer to supply its own key material. On certifications and attestations, the current set is
short enough to state in full: SOC 2 Type II, plus GDPR and HIPAA compliance. If your checklist
names something outside that list, ask directly rather than inferring — the set changes, and a
vendor listing what it holds is more useful to you than one gesturing at what it doesn't.
The same applies to the gaps described above: state them plainly instead of talking around them.
Does using a vendor make the security review easier or harder?
Harder in one specific way: it adds a subprocessor and a data flow the review has to include, and a
reviewer has to understand where the vendor sits and what it retains. That's real added surface
area, not a detail to wave past.
It's also easier in a way that's easy to undercount: it replaces bespoke work — building credential
storage, permission propagation, and tenant isolation from scratch — with one component whose
security posture has already been examined. Part of that is independently evidenced and sits on the
trust portal to open directly: the SOC 2 report, GDPR and HIPAA standing. The rest is not
third-party evidence at all — the pen-test cadence and the tenant-isolation mechanism are facts
Paragon confirms and details under review rather than posts publicly. Both are worth asking for;
only the first is something you can verify without asking. A thorough review weighs both sides —
the added surface area a vendor introduces, and the security work it replaces — instead of settling
on just one. (Still weighing build versus buy? See
build vs. buy for RAG data ingestion and
how long it takes to build RAG ingestion in-house.)
FAQ
Does Paragon store the contents of the files it syncs? No. Paragon proxies file content from
the source system when it's requested, rather than storing a copy — the largest deletion question,
already answered. Credentials, metadata, and Event Logs persist until removed on request; anything
embedded into a vector store sits downstream, outside infrastructure Paragon operates.
Where can a reviewer see Paragon's compliance documentation? Directly on the trust portal,
security.useparagon.com, which publishes the SOC 2 Type II
report, GDPR standing, HIPAA compliance, and subprocessor details.
Can Paragon deploy entirely inside our own infrastructure? Yes — self-hosted in a customer's
own environment, or as a dedicated on-premise instance with as many regional copies as needed.
Do the same per-user checks apply to CRM and ticketing sources? Not yet. Per-user checks today
reach file storage only; Salesforce and Zendesk records move through the same ingestion pipeline
without one. Ask about that gap directly if it matters.
What happens when a connected account is disconnected? It stops being used for future syncs,
and the disconnect itself is a logged action, recorded with its actor, timestamp, and outcome.
Can audit logs be sent to our own monitoring tools? Not as a full audit feed. What reaches an
external tool is narrower: workflow and credential-failure alerts, routed to New Relic, Slack,
Datadog, or Sentry through Event Destinations. The broader record stays in-product, searchable, not
forwarded.
The reviewer's checklist
Before signing off on a data ingestion vendor: confirm in writing, not on a call, where the data
lives — on-premise, self-hosted, or in a certified cloud. Confirm tenant isolation at the platform
level, and that source permissions, at minimum for file storage, are checked before retrieval
rather than assumed. Confirm how credentials are stored and rotated, and what the audit log can and
can't send elsewhere. Get the subprocessor list and compliance reports from the trust portal, not a
slide. And ask about deletion in two parts: confirm file content was never stored, then ask what
happens to credentials, metadata, and logs — and who clears anything already in a vector store
downstream. For the fuller, ingestion-type-agnostic version of this walkthrough, see the
integration platform security review checklist.
Current as of September 2026. Ready to see the evidence directly?
Request a demo.
