Customer-resident data processing
What it means for every row-level operation to run inside your own network, and how a hosted service can still coordinate the work.
Topics
Customer-resident processing and evidence
DataNivra is built around one boundary: rows are processed by an agent inside your environment, and only metadata, aggregates and evidence references reach DataNivra Cloud. These pages explain that boundary, how it is verified, what certification against configured policy gates means and what audit evidence each run leaves behind.
Start here
Go deeper
Zero raw-production-data egress
The precise privacy promise behind DataNivra, how it is enforced in code on both sides of the boundary, and why it is not “zero copy”.
Customer-Resident Architecture
Platform integrity
How a test data platform proves it behaves as configured — verified policies, at-most-once commands, revocable agents and fail-closed defaults.
Dataset certification
What it means to certify a test dataset, which gates it must pass, and why a failed gate must block provisioning rather than warn.
Audit evidence
What evidence a test data programme needs, why audit events should be tamper-evident, and why the evidence files should stay in your environment.
Detecting policy drift in lower environments
Scan registered DEV, QA and UAT environments inside your network for unmasked copies and policy drift - a Preview that reports evidence, never values, and needs a newer agent.
Security
Trust
Research
Customer-resident processing — verify the agent you run
Check a published agent release against its SHA-256 list and confirm the Helm values pin the exact image digest, before the component that touches your data runs in your network.
Platform engineering