Secure analytics for data that cannot move
Most analytics platforms begin by copying records into a store they run. When a residency rule or a contract forbids that copy, four approaches remain. This note compares them the way a security review will.
Ingestion is the first step of almost every analytics platform: records leave the systems of record for a warehouse, a lake or a vendor store, and the analysis runs there. For most data that design is sensible. It fails when a regulator, a customer contract or a data residency rule says the records stay where they are.
Four approaches when the records must stay put
Teams in that position usually pick one of the approaches below. Each trades the analysis you can run against the evidence you can hand a reviewer.
| Approach | What is copied | Who runs compute | What the review covers | Fits when |
|---|---|---|---|---|
| Central copy, approved by exception | Raw records, into the analytics platform | The platform owner | The second store: pipelines, retention, access | Policy allows the copy after review |
| De-identified extract | Masked or aggregated records | The platform owner | Masking method and re-identification risk | The question still works on masked data |
| Local tools at each site | Results, reconciled by hand | Each site separately | Every tool on its own terms | One or two sites that rarely change |
| Execution beside the source (KEZEL) | No records; one encrypted instruction enters | Your team, as one agent | Agent runtime, credentials, policy file, egress | Records cannot be copied and the questions change often |
If policy already permits the copy, a warehouse your team runs is the shorter path, and we would say so in a pilot conversation. Where that warehouse is Snowflake, BigQuery or Redshift inside your boundary, KEZEL connects to it there instead of replacing it.
How KEZEL runs the analysis beside the source
KEZEL places an agent beside the databases your team operates. The control plane builds a plan from schema metadata and the question asked. The agent opens its own TLS 1.3 connection, pulls the encrypted instruction and executes it locally. Raw records and computed results remain in your approved environment.
Policy is applied in the plan itself, as row filters, column masks and minimum cohort sizes. Dashboards and APIs read the result inside the same environment through the policy gate. The audit ledger records the question, the policy decision, the reader and the timestamp, and lineage traces each published figure back to its source tables.
There is a cost. Your team supplies the compute, operates the agent and still reviews its runtime and credentials. What goes away is the second store, along with the pipelines and retention rules that came with it.
Questions to ask any secure analytics platform
Four answers separate these approaches within one meeting:
- Where does the computation run relative to the records?
- What crosses the boundary, in which direction, and which side opens the connection?
- Where are results stored, and where are they read?
- What would an auditor receive for a single query?
KEZEL's answers are in the due-diligence section of the platform page, and the analytics module shows sample outputs with their masks and lineage. Show us the data you are not allowed to move. That's the workload we should discuss: book a pilot conversation.
Written by the KEZEL team at DBTEZ.All articlesBook a demo