Skip to content

Data Protection

Your Manifest says which fields need protecting. This page covers how they actually get protected when a request doesn't qualify for unprotected access.

eXate supports a broad set of data protection techniques, grouped into three categories, plus support for bringing your own PETs. Which one you pick for a given Attribute depends on what the protected value needs to do afterward: does it need to stay reversible for an authorised process later, does it just need to look realistic for testing, or does it only need to be safely unreadable.

Cryptography

Reversible or format-preserving techniques based on cryptographic algorithms, documented in detail under Cryptographic PETs:

Perturbation

  • Synthetic Data: High-fidelity statistical replication of datasets.
  • Noise Addition
  • Microaggregation

Non-Perturbation

Techniques that redact, mask, or suppress data rather than statistically altering it, documented in detail under Non-Cryptographic PETs:

  • Mask
  • Format Preserving Masking
  • Local Suppression
  • Record Suppression

List: Substitute Values for Masking

When a masking PET replaces a real value, it draws the replacement from a List, a reusable lookup table, so the same input always maps to the same output, regardless of which system or user is requesting it. For example, "Alice" is always substituted with "Jane," and "Peter" is always substituted with "Bob," everywhere that substitution is applied. This is what makes masked data usable in testing and analytics: relationships between records stay consistent even though the values themselves are fake. See Deterministic Masking and SnapshotDate for how the consistency itself is controlled.

A List has a second, unrelated use too: as an access control list checked during Policy evaluation, for example matching a requester's value against an allowed or blocked set. Which behaviour a given List has depends on how it's referenced, against a Policy for access control, or against an Attribute's PET configuration for substitution.

Access it via Central Services → Data Management → List. Click "+" and fill in:

  • Name: name of the list
  • Data Type: the type of the data
  • Use Validator: No, or Custom
  • Description: description of the list
  • Lookup Values

Click the pencil icon on any list to edit it.

Bring Your Own PET

eXate provides a flexible framework supporting custom privacy enhancing techniques, for organisations with existing algorithms or techniques they need to keep using rather than replace. Custom PETs are written in Java.

Data Exfiltration Protection

The PETs above protect data while it's being accessed through eXate. This section covers a related but broader guardrail: what happens once data leaves the application entirely, downloaded, extracted, or queried directly through a database or analytics tool.

The challenge: strong access controls inside an application don't prevent a user from extracting or downloading data once they're authorised to see it, which creates risk of data leaving approved jurisdictions, unauthorised sharing, insider threats, and loss of control generally. Sensitive data may also be reached through APIs, direct database queries, analytics platforms, or JDBC connections, channels where consistent protection is harder to maintain once data has left the originating system.

The eXate approach: extend protection beyond the application layer using dynamic tokenisation, access-aware protection, and controlled encrypted storage, so protection follows the data rather than stopping at the application boundary.

  • API Protection: sensitive fields in API responses (PII, financial data, customer identifiers) can be dynamically tokenised or masked before reaching the requesting system, so downstream integrations don't receive raw values unless explicitly authorised.
  • Database and JDBC Access Protection: direct database queries or analytics tools using JDBC-style connectivity can have protection applied at the access layer itself, tokenising or masking sensitive columns in real time based on user permissions, so analysts and reporting tools keep working while exposure is minimised.
  • Controlled Data Extraction: when a user does export or extract data, the application can restrict where the resulting files can be saved, preventing datasets from landing on local desktops, external drives, or unmanaged storage.
  • Forced Encrypted Storage: extracted data lands only on a pre-approved encrypted store, decryptable only through a secure virtual mount (a FUSE-based filesystem mounted via CSI), so it stays encrypted at rest and inaccessible outside the authorised environment.
  • Environment-Bound Decryption: data only decrypts within the authorised environment (a controlled workstation, secure virtual desktop, or managed analytics environment). Copied or moved elsewhere, it stays encrypted and unusable.

Together, tokenisation at the access layer and encrypted storage at the extraction layer meaningfully reduce the risk of sensitive data leaving controlled infrastructure altogether, supporting data localisation compliance, regulated-industry requirements, and protection against insider exfiltration.

Sections

What's next

Attributes, Countries, Claims, Policies, Manifests, and PETs cover the core "protect the data" journey. From here:

  • Filter Expressions add row-level restrictions on top of the column-level protection covered so far.
  • Vault is where the underlying configuration and database connections for all of the above are managed.
  • Admin covers who's allowed to manage the eXate tenancy itself, a separate concern from who's allowed to see the data.