Use cases

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.

Use case

Lower environments drift. Someone restores a production backup into QA "just for a day", an ETL job copies a table before its masking step, a masked dataset lands in the wrong schema, or a masking policy is replaced while the old copies stay deployed. None of this shows up in the request history, because none of it went through a request. DataNivra's Compliance Guard is a Preview that looks for this kind of drift on a schedule: it scans the lower environments you register, inside your network, and reports what it found as evidence that never contains a record value. It is implemented and tested end to end, and it becomes usable once your agent runs a release that supports it.

The name describes the problem it watches for, not an outcome it promises. The guard detects policy drift and indicators of sensitive data; it does not certify, attest or assure compliance with any regulation, and a scan that finds nothing is not proof that nothing is there. (Where DataNivra certifies a dataset, that means it passed configured policy gates; the guard adds no certification of its own.)

How a scan works

You register an existing environment (for example a QA database) together with a guard policy and a reference to a read-only scan credential. The policy is an ordinary DataNivra policy with versions, review and approval by a second person. It states, per environment tier, which sensitivity classes may appear in tables DataNivra did not provision and whether provisioned copies must carry masking evidence. It also sets the scan cadence, a budget (how many tables, how many rows per table, and a deadline), a daily scan cap and which severities raise a notification.

  • The scan runs on your agent. A scan is a job sent only to agents that advertise the scan capability, with a signed job authorization. The agent resolves the credential in its own secret provider, reads bounded samples and runs the same classification engine used for dataset builds. DataNivra Cloud never connects to the environment.
  • What it looks for. Sensitive classes the policy does not allow in an unmanaged table; values that the high-precision residual detectors match in a column with no sensitive classification; copies without their masking marker, or with a marker that names another policy; masking-policy versions that were superseded after a copy was provisioned; tables that DataNivra did not provision; and structure changes against an accepted baseline.
  • What comes back. Reason codes, severities, sensitivity classes, keyed opaque references to tables and columns, and bucketed counts. Table and column names are included only when they pass the same egress name checks as every other report; otherwise they are withheld. The control plane re-checks every report before storing it.
  • Incomplete is never clean. If a scan hits its budget, its deadline or a read failure, it is reported as incomplete. An incomplete scan never resolves a finding and is never shown as a clean result.

Where you can use it

  • Console. Compliance Guard pages list guarded environments, scans and findings, with triage actions and a trend chart; the dashboard shows open findings by severity.
  • Triage with accountability. Findings can be acknowledged, marked as false positives or suppressed. A suppression always has an owner, a reason and an end date at most 90 days ahead; when it ends, the finding reopens. A resolved finding that is seen again reopens too.
  • CLI and API. datanivra guard registers environments, requests scans and triages findings. guard scan request --wait --fail-on HIGH exits with a distinct code when open findings reach the threshold or when the scan was incomplete, so a pipeline can stop before tests run against a drifted environment.
  • Notifications. Webhook, Slack-compatible and e-mail channels receive events that carry identifiers, reason codes, severities and counts only - never table or column names. Webhook and Slack destinations are stored as secret references.
  • Remediation guidance and audit evidence. Each reason code has published guidance, and the audit evidence export includes a Compliance Guard section with guarded environments, scans, findings and suppressions.

These behaviours are covered by engine, agent, control-plane and console tests, by an adversarial suite that tries hostile names and cross-tenant access, and by an end-to-end test on the real control plane, agent and engine that plants synthetic canary values in a guarded database and confirms that none of them reaches any control-plane response, table row, log, notification or export.

What it does not do

  • It needs a newer agent. Published agent releases do not include the scan handler yet; until a release that does is deployed, scans stay queued and nothing is scanned.
  • It samples. Each table is read up to the row budget, so a rare value outside the sample is missed. A clean scan means no evidence was found in the sample, not that the environment is free of personal data.
  • Detection is deliberately narrow. The residual detectors look for validated payment-card numbers and IBANs, e-mail addresses and the dashed US social security number format. Names, phone numbers, postal addresses and free-text personal data are not detected by them.
  • Two kinds of environment. PostgreSQL databases and directories of Parquet files are supported. Other file formats in a directory are not read, and other database engines cannot be guarded yet.
  • It trusts recorded provenance. A copy that DataNivra provisioned under an approved masking policy is treated as masked; the guard does not re-mask it or repeat its certification.
  • It never changes your environment. The guard does not mask, move or delete anything. Removing a copy stays a person's decision through the audited teardown path.
  • It does not replace an access review, a data-protection assessment or an audit. It produces evidence that such reviews can use.

Next steps

Read how data discovery and classification finds sensitive columns, how customer-resident processing keeps rows inside your network, and what audit evidence each run leaves behind. To try the product itself, start free with the synthetic sandbox.