Nothing leaves your account. Not rows, not query text.
Dataring runs in a cloud account you own. It reads metadata and access logs, writes back to your catalog, and applies only what your team has accepted.
Where it runs
Dataring runs inside a cloud account that belongs to you, not to Dataring. It is deployed as a container (a Docker image) on Google Cloud, AWS or Azure. The account, the network and the credentials are yours. Your engineer sets it up in about two hours, on a call with us. Nothing about the deployment requires an account that Dataring controls.
What it reads, and what it never reads
Dataring reads three kinds of information and nothing else.
Reads:
Metadata: the names and structure of your tables, columns, pipelines and schedules, and of your dashboards when you enable BI access.
Access logs: which account read which table and when, and which column where your warehouse records it.
Catalog entries: the descriptions, tags, owners and lineage your catalog already holds.
Never reads:
Row data. Not a sample, not a single column, not a preview.
Query text. Not the SQL, not the parameters, not the result.
Access logs are enough because they record who depends on each table, and what the business depends on is the only thing Dataring needs to know.
Where the boundary is
What access it asks for
Dataring asks for a separate, named scope on each system it touches. Read-only scopes come first. Scopes marked write are the ones your team should review most closely.
Warehouse: any warehouse, strongest on BigQuery
Read-only
A metadata read scope plus read access to the warehouse’s access logs. The exact role names for your warehouse are sent to your engineer before the setup call.
To read the access logs and table metadata that lineage and usage are built from. Never row data, never query text.
Your catalog: yours, or one Dataring deploys in your account if you don’t run one
Read-only
A read-only API credential on your catalog.
To read the entries, lineage and ownership your catalog already holds, so Dataring starts from what your team knows.
Orchestrator: Airflow, Prefect or Dagster
Read-only
A viewer-level role or a read-only API key on your orchestrator. The exact role is sent to your engineer before the setup call.
To read pipeline definitions and schedules for the lineage map.
BI tool: optional
Read-only
Only if you enable it: a read-only credential on a BI tool that exposes audit logs or an access-log API.
To map dashboards and reports as the end of each lineage path.
Your catalog
Write
A token scoped to descriptions, tags, owners, importance and classification. Nothing else in the catalog.
To write descriptions, tags, owners, importance and classification back into the catalog your team already opens, each one after your team accepts it.
Orchestrator
Write: optional
A scope limited to pausing, resuming and rescheduling pipelines, granted only if you want Dataring to apply the schedule, priority and retirement changes your team accepts.
Without it, your team applies accepted changes from the proposal, and the proposal and the decision are still logged.
Warehouse
Write: none
No warehouse write access is requested.
Dataring never writes to your warehouse.
What it can change, and who decides
Every change starts as a proposal that a person on your team accepts or rejects. The actions that exist are:
Descriptions and tags, written into your catalog.
Owners, importance and classification, written into your catalog.
Schedule changes, so a table refreshes as often as the data earns it.
Scheduler priority, so pipelines feeding what matters run first and recover first.
Retirement of a pipeline nobody uses.
Each proposal arrives with the evidence attached: what Dataring found, what it wants to change, and why. A person on your team accepts or rejects it in the console, and Dataring applies what was accepted. Nothing is applied on the agent’s own initiative, and there is no setting that lets it. Retirement is always its own action with its own guardrail. It is never bundled into a schedule change.
Descriptions, tags, owners, importance and classification are written through the catalog write token. Schedule changes, scheduler priority and retirement are applied through the optional orchestrator write scope; without it, your team applies them from the proposal. Either way the proposal, the decision and the change are logged.
Every change is logged with what was done and why. The log is the record your reviewers will ask for, and it holds every proposal, accepted or rejected, and every change applied.
What leaves your account
Row data and query text never leave your account, because Dataring never reads them. What Dataring learns is written into your catalog, which is also inside your account.
Beyond that, one thing crosses: a license check. During normal operation, Dataring sends a small payload to Dataring’s license service containing your license or entitlement ID, your deployment ID and the version number. It contains no row data, no query text, no metadata and no telemetry. The deployment needs it to run, so it cannot be switched off. There is no usage telemetry, no error reporting and no update check.
Support access: no Dataring employee has standing access to your deployment. Access is break-glass only. To allow it, you approve a single session through a support ticket. Dataring’s identity provider issues a temporary credential for that session, and the approval and the session are logged in Dataring’s system. Nothing can be reached without your approval.
Encryption, access and audit
Data at rest in the deployment is encrypted with AES-256, using keys in your cloud provider’s key management service (KMS). The keys are yours; Dataring does not hold them. Data in transit between Dataring and your warehouse, catalog and orchestrator is encrypted with TLS 1.2 or higher.
Sign-in to the Dataring console uses local accounts only. There are three console roles. Admin can do everything, including sign-off and user management. Editor can configure scopes and rules but cannot sign off. Viewer is read-only. Console actions by your users are recorded in the action log inside your account.
The action log lives inside your account, is kept for one year, and can be exported as JSON or CSV. The estate map can be exported the same way.
Certifications: none. Dataring does not hold a SOC 2 report or any other third-party audit today. The mitigation is the deployment model: Dataring runs inside your account, reads only metadata and access logs, holds no keys and has no standing access.
When you stop
Stopping Dataring is your decision, and the exit is yours to control. To uninstall, stop the container, revoke the service accounts and tokens Dataring was granted, and run the cleanup script. The script deletes the storage Dataring used, including the action log, and removes any remaining service accounts. Export the action log and the estate map first if you want to keep them; both export as JSON or CSV into your account.
What is left behind: the descriptions, tags, owners, importance and classification Dataring wrote into your catalog stay there. They are entries in your catalog and belong to you. The map export and the action log export stay wherever you saved them in your account. Nothing else remains.
What is undone: nothing automatically. Every schedule, priority and retirement change Dataring applied is in the action log with the value before it, so each one can be reverted in your orchestrator. Retiring a pipeline only stops it. It never drops a table.
Updates: each update is a new container image. Your team pulls and applies it on its own schedule.
Questions security teams ask
Can Dataring see our data?
No. Dataring reads metadata and access logs. It never reads row data and never reads query text. The access it asks for does not include either.
Can an agent delete a table?
No. Retiring a pipeline only stops the pipeline; it never drops a table. Retirement is a separate action with its own guardrail: Dataring proposes it, a person on your team accepts it, and only then is the pipeline stopped.
Do you need admin access?
No. No role on any system is broader than read-only plus the field-scoped catalog write (descriptions, tags, owners, importance, classification) and the optional orchestrator write listed above, both granted separately by you. Every scope is listed by system, with read-only and write separated.
Who at Dataring can reach our deployment?
Nobody, unless you approve a break-glass session through a support ticket. There is no standing support access. The answer is the same for every customer, and it is written here rather than agreed on a call.
Where is the action log kept?
Inside your account, for one year. It can be exported as JSON or CSV, and every change in it is logged with what was done and why.
What leaves our account during normal operation?
One license check: your license or entitlement ID, deployment ID and version number, sent to Dataring’s license service. The deployment needs it to run. Nothing else leaves, and row data and query text never do.
Does Dataring see which of our reports are regulatory?
Your team tells Dataring which outputs reach a regulator, auditor or customer. Dataring treats those as critical and protects everything upstream of them. It does not read the reports.
What do we need to approve before a POC?
A cloud account you own to run it in, the read-only scopes listed above, a decision on whether to grant the catalog write scope for the POC, and a mutual NDA and DPA signed before the POC starts. Your engineer can connect it in about two hours, on a call with us.
Bring your questionnaire
Send us your security questionnaire before the POC and we will fill it in from the facts on this page. If there is something we cannot answer in writing, we will say so rather than book a call to talk around it.