Data Access Policies

Production data, controlled at every hop. By architecture

Data Access Policies define who can access what data, where it can go, and in what form, enforced by Tessell's architecture, not by policy documents. Sharing and replicating snapshots, refreshing lower environments, masking sensitive fields - all from one control plane.

Talk to an expertView DAP documentation →
The problem

Every team has a data access policy. The hard part is enforcing it at every hop

Most organizations have put real thought into how production data should be handled. The gap is structural: when data actually moves across regions, into lower environments or between teams, the rules don't automatically travel with it.
Sharing outpaces documentation

Sharing outpaces documentation

Snapshots cross regions, lower environments refresh from production, each sensible in the moment. Over time the sharing landscape is hard to reconstruct, and compliance demands controls informal sharing can't produce.
Masking depends on who runs the script

Masking depends on who runs the script

The masking workflow works most of the time. Exposure lives in the exceptions, when a refresh runs and the script doesn't, sensitive data reaches a dev environment unmasked, with no signal.
Access doesn't revoke itself

Access doesn't revoke itself

When someone changes roles or leaves, the snapshots and clones they could reach don't disappear. Access to production data grows and rarely shrinks, and informal grants go undocumented, an audit nightmare.
How it works

One policy for every artifact in every region.

A Data Access Policy is a structured rule defining what data flows where, who can access it, and in what form. The AM produces the artifacts and DAPs control how your team accesses them.

01 Source artifact
A snapshot, PITR log, sanitized snapshot, or native backup produced by the AM. The DAP doesn't change the artifact, it controls how it moves.
02 Policy definition
Where the data can go (region, subscription), who can access it (user or group), and in what form (as-is, masked, native).
03 Enforcement at every hop
The DAP applies to every snapshot replication, every clone, every refresh, every download. No exceptions.
04 Revocation by design
Delete the policy and the underlying cloud snapshot is deleted from the target region. Access doesn't decay over time, it's removed structurally.
What it does

From the moment data leaves the source, the DAP controls where it goes and who gets it.

A single policy defines the destination, the recipient, and the form and applies that rule to every snapshot, clone, and refresh that follows. No manual scripts, no informal exceptions, no ad-hoc sharing patterns to audit later.

Cross-region sharing

Replicate snapshots across regions inside your own cloud provider, same subscription or different. Cross-region DR built in. Access governed by the policy, not by manual snapshot copy.

  • Single-region or cross-region replication - defined per policy, applied to every snapshot.
  • Cross-subscription support - Oracle supports cross-subscription sharing on AWS and Azure.
  • Continuous replication - secondary regions stay current as new snapshots are produced.
  • Encryption controls - separate encryption key per target subscription, BYOK on AWS and Azure.
Data Management

Four layers of data management, architected into one platform.

Tessell connects protection, access, governance, and activation into a single platform. Managed from one control plane, with no gaps between them.

Protect

Availability Machine

Continuously captures snapshots, transaction logs, and native backups across every database and every engine. The foundation everything else depends on.

How AM works
Access

Dataflix

Turns the AM's output into a self-service catalog. Any team, DBA, developer, QA, can clone, restore, or download from any point in time without filing a ticket.

How Dataflix works
Govern

Data access policies

Governs what data flows where and who can access it, same region, cross-region, or cross-subscription. Masked or as-is. Enforced by architecture, not policy documents.

You are here
Activate

Data ecosystem

Streams live changes from operational databases into data lakes or warehouses for analytics and AI, without separate CDC tooling, or ETL overhead

How Data Ecosystem works
Ready to see how data access policies would work in your environment?

Talk to a Tessell engineer, not a sales rep. Bring your environment, your compliance requirements, your data-sharing patterns. Walk away with a clear picture of what DAPs would change for your team.

Talk to an expert
Frequently Asked
Questions
A Data Access Policy is a structured rule in Tessell that defines what data flows where, who can access it, and in what form. The AM produces the snapshots, logs, and backups. The DAP controls how they're shared across regions, subscriptions, and users.
Same-cloud cross-region replication is supported on AWS, Azure, and GCP. Cross-subscription sharing within the same cloud is supported for Oracle on AWS and Azure. SQL Server cross-subscription clone is not currently supported.
Organizations provide their own masking scripts, uploaded to the Tessell Script Library and versioned. The DAP applies the script at sanitized snapshot creation. The masked snapshot is then available for cloning and refresh through Dataflix, with the production data never reaching the target environment.
Not currently. PITR is only available for as-is sharing, because masking applies at snapshot creation and PITR replays transaction logs after the snapshot. For lower environments, the standard pattern is sanitized snapshots without PITR.
The cloud snapshot in the target region is deleted along with the policy. Access doesn't decay over time, it's removed structurally. Any active clones from that snapshot remain, but no new clones can be created from it.
Every DAP creation, modification, and deletion is logged. Every snapshot share, clone, and refresh is tied to the policy that authorized it. The AM dashboard surfaces DAP count per database, and the data flow visualization shows exactly where each snapshot has been shared in real time.
A policy applies uniformly to its assigned users or groups, same data, same form, same destinations. For different access levels to the same source data, create multiple policies. This keeps the access model auditable and prevents informal exceptions.
Masking scripts are versioned in the Script Library with full revision history. Each version can be published or unpublished, controlling which versions can be referenced in active policies. The DAP records which script version produced each sanitized snapshot, for full auditability.