Data Masking

Protect sensitive data during export by applying masking transformations. Data masking allows you to export data for development, testing, or analytics while obscuring personally identifiable information (PII) and other sensitive fields. Essential for GDPR, HIPAA, and SOC 2 compliance.

Why Data Masking?

Data masking is critical for several scenarios:

• Development & Testing - Use realistic data without exposing real customer information
• Analytics & Reporting - Share data with analysts while protecting PII
• Third-Party Sharing - Provide data to vendors without compliance risks
• Regulatory Compliance - Meet GDPR, HIPAA, CCPA, SOC 2 requirements
• Data Breach Prevention - Limit exposure if non-production data is compromised

Masking Techniques

VisuaLeaf ships with seven built-in masking techniques. Pick per field, per export — and mix techniques within a single job when different columns need different treatment.

Technique	Description	Input	Output
partial	Reveal the first / last N characters and mask the rest. Preserves format recognition.	john@example.com	j***@e***.com
hash	Deterministic SHA-256 hash. Same input always produces the same output, so joins and referential integrity survive.	john@example.com	a8f5f167f44f4964...
fake	Faker-style realistic replacement (names, addresses, phones, emails, companies). Great for demo and QA data.	John Smith	Jane Wilson
null	Write a literal NULL in place of the value. Good for optional fields the target system doesn't need.	secret123	null
truncate	Drop the field entirely from the exported document. Nothing is written — the safest option for high-risk fields.	ssn: "123-45-6789"	(field removed)
redact	Replace with a solid mask. No information about the original value survives.	password!	********
randomize	Replace with a random value of the same type and length. Different every run — use when you need uniqueness but not repeatability.	555-123-4567	872-410-3391

Deterministic vs. non-deterministic: hash is the only deterministic technique — the same input always yields the same output. Use it whenever you need masked data to still join across collections or across export runs. Use randomize or fake when you specifically want the output to change each run.

Field-Level Masking Policies

Masking is expressed as a JSON policy attached to each export job. Every field can pick one technique and, optionally, a condition that decides when to apply it. Policies run inside VisuaLeaf on the exported records — your MongoDB collections are never modified.

Example 1: Email PII with hash-consistent joins

You need to export users and orders to a data-warehouse for analytics. Real emails must never leave production, but the analytics team still needs to join a user's orders.customerEmail back to users.email. hash is the right pick — deterministic SHA-256 gives you the same opaque token in both collections.

{
  "collection": "users",
  "fields": {
    "email":     { "technique": "hash" },
    "firstName": { "technique": "fake" },
    "lastName":  { "technique": "fake" },
    "phone":     { "technique": "partial", "keepFirst": 0, "keepLast": 4 },
    "ssn":       { "technique": "truncate" },
    "password":  { "technique": "truncate" }
  }
}

Same policy applied to orders.customerEmail:

{
  "collection": "orders",
  "fields": {
    "customerEmail": { "technique": "hash" }
  }
}

Result: an analyst can still JOIN users u ON u.email = o.customerEmail in the warehouse, but neither table contains a real address.

Example 2: Conditional masking (mask if country != "US")

GDPR requires stronger handling for EU customers. Apply fake masking only when a document's country field is anything other than the US — US records ship as-is for the US analytics team.

{
  "collection": "customers",
  "fields": {
    "email":     {
      "technique": "hash",
      "when":      { "country": { "$ne": "US" } }
    },
    "firstName": {
      "technique": "fake",
      "when":      { "country": { "$ne": "US" } }
    },
    "lastName":  {
      "technique": "fake",
      "when":      { "country": { "$ne": "US" } }
    },
    "address":   {
      "technique": "redact",
      "when":      { "country": { "$ne": "US" } }
    }
  }
}

The when clause accepts standard MongoDB match expressions, so you can layer arbitrary conditions (data classification tags, environment, role, etc.).

Applying Masks

Apply masking through the field transformation editor. Select a field, open the transformation panel, and choose or write your masking logic.

Email Masking

Partially mask emails to hide the full address while preserving format recognition.

Phone & SSN Masking

Reveal only the last 4 digits for phone numbers and SSNs - enough for identification, safe for compliance.

Credit Card Masking

Standard PCI-compliant masking showing only the last 4 digits.

Name & Address Masking

Generate fake but realistic names, or redact addresses while keeping city/state for geographic analysis.

Field Recommendations

Common PII fields and recommended masking strategies.

Field Type	Sensitivity	Recommended Technique	Example Output
Email	High	partial or hash	j***@e***.com
Phone	High	partial (last 4)	***-***-1234
SSN	Critical	partial (last 4) or hash	***-**-6789
Credit Card	Critical	partial (last 4)	****-****-****-1234
Name	Medium	fake	Jane Wilson
Address	Medium	fake or redact	******** or fake address
Birthdate	Medium	randomize or partial (year only)	1990-01-01 or randomized date
IP Address	Medium	randomize or hash	203.0.113.42
Password	Critical	truncate (drop field)	(field removed)
API Keys	Critical	truncate (drop field)	(field removed)

Consistent Masking (Join Integrity)

For data that needs referential integrity — user IDs or emails that appear in multiple collections, foreign keys, tenant IDs — use the hash technique. Because SHA-256 is deterministic, the same input always produces the same masked output. A join that worked in production still works after export.

Example: users.email and orders.customerEmail both hash to the same 64-character token, so the analytics warehouse can still join the two tables without ever seeing a real address.

Conditional Masking

Every field policy accepts an optional when clause, which is evaluated as a MongoDB match expression against the document being exported. Use it to:

• Mask only EU customers for GDPR: { "country": { "$ne": "US" } }
• Skip admin accounts: { "role": { "$ne": "admin" } }
• Apply stricter masking to production-tagged data: { "classification": "restricted" }
• Combine conditions: { "$and": [{ "country": "DE" }, { "isMinor": true }] }

Excluding Fields

For highly sensitive fields like passwords and API keys, exclude them entirely rather than masking.

• Disable field - Uncheck the field in field mapping to exclude it from export
• Projection - Use MongoDB projection to never fetch sensitive fields

Pro Tips

1. Test with preview - Always preview masked data before running the full export to verify masking works correctly.
2. Use consistent hashing - When you need referential integrity across collections, use crypto.sha256() for deterministic masking.
3. Document your masks - Keep a record of which fields are masked and how, for audit and compliance purposes.
4. Exclude rather than mask - For passwords, API keys, and tokens, exclude them entirely instead of masking.
5. Consider data utility - Choose masking that preserves data usefulness (e.g., keep domain for emails, keep format for testing).
6. Save as template - Save your export job with masking as a template for consistent use across environments.
7. Validate output - After masking, verify no PII leaked through edge cases (nulls, empty strings, unusual formats).

Related Features

• Export/Import Data - Full guide to creating export jobs with field mapping
• SQL Migration - Export masked data to SQL databases
• Task Manager - Schedule automated masked exports