Salesforce PII governance, metadata-only

Find your PII. Prove your controls. Never move your data.

Multi-org Salesforce estates hide PII in fields, files, and attachments. The tools built to find it either miss half of what's there or ingest your data to work. Org Warden runs inside every org you have. Values never leave. You get one ledger of where PII lives, who can see it, and what changed.

Find it. Prove it. Fix it.
0
values, records or files that leave the org
1
ledger across every production and sandbox org
3
questions answered: where, who, what changed
Purpose

Three questions your estate can't answer today.

Every quarter, some combination of these three questions lands on the desk of the person responsible for Salesforce PII. Answering them today means spreadsheets, custom Apex, or a six-figure consulting engagement. Org Warden makes them a report you can run before lunch.

fig. 01your estate · metadata plane · what we answer
Your Salesforce estate4 orgs
Production
email · SSN · phone · PDF · case PII
Sandbox 1 · Dev
email · SSN · DOCX
Sandbox 2 · UAT
email · phone · JSON
Full Copy · Perf
email · SSN · phone · PDF · case PII
metadata
counts · classes · telemetry
Org Warden · observer
counts · classes · snapshot hash
no values · no files · no records
Where
PII, cross-org, fields + files
Who
effective access resolved
What
drift since last snapshot

Where is PII in our estate?

Before: Spreadsheets pieced together per org, per quarter, always stale.With Org Warden: One live ledger across every prod and sandbox. Fields, files, attachments, and ContentDocuments.

Who can effectively see it?

Before: Nobody. Access mapping happens in a different tool, or in nobody's tool.With Org Warden: Effective field-level visibility per profile, per permission set, resolved against sharing rules.

What has changed?

Before: Diff two spreadsheets from different quarters. Best of luck.With Org Warden: Drift over correlation-lineage snapshots. New PII field, new access, new file: it shows up as a row with a timestamp.
Why we built it this way

Every category default asks you to move your data first. That is the failure mode Org Warden refuses.

fig. 02ahow it's normally done
Your Salesforce org
records · files · fields
ingestrecords · values · filesboundary
Vendor cloud
your data · copied
  • Data leaves the org. Add another processor to your DPA.
  • Copies age. Findings drift from the source of truth.
  • Security review is about the vendor's environment, not yours.
  • Priced like a platform. Six-figure floor.
fig. 02bhow Org Warden does it
Your Salesforce org
records · files · fields
metadatacounts · classes · telemetryboundary held
Org Warden
metadata ledger
  • Values never leave. No new processor, no new DPA line item.
  • Findings live where the data does. Zero staleness.
  • Security review is about absence, not architecture.
  • Priced per org, predictably, no seat maths.
What you get

An audit-ready ledger. Not a dashboard.

Every finding is a row. Every row references a snapshot hash and the rule that produced it. This is the same evidence you would hand a DPO or a regulator, exportable as CSV or PDF. Audit prep measured in minutes rather than months.

fig. 02cillustrative · one org · no values, ever
RuleFieldRecords with hitsCheck
EMAILContact.Email12,481format only
CREDIT_CARDCase.Description47Luhn
UK_NHS_NUMBERContentVersion.triage_form.docx6MOD 11
PHONELead.MobilePhone3,190format only
Snapshot 7f2c…a19bScanned 2 934 116
From finding to control

You cannot encrypt what you cannot enumerate. A finding is the first time a control has something to bite on.

Security teams are rarely short of controls. Salesforce already ships encryption at rest, field audit history, field-level security, and event monitoring. What is missing is the list to point them at. Encrypting everything is unaffordable and breaks filtering and sorting; encrypting a guess is a control you cannot defend in a review. Once PII is enumerated per field, per file, per org, with the rule and check that found it and a snapshot hash behind it, the mandate becomes writable: these fields, these orgs, this quarter.

01 · you can now
Mandate encryption at rest
Point Shield Platform Encryption at the exact fields that hold PII rather than a subset someone chose three years ago. The rule that fired, the check digit it passed and the snapshot hash give the scope a defensible provenance when procurement asks why these fields and not those.
02 · you can now
Tighten who can read it
The access map states each field's FLS breadth, each object's sharing model and the share table's upper bound, and names the sharing mechanisms it could not read. Restrict FLS or split a permission set with the actual breadth in front of you instead of an admin's recollection of it.
03 · you can now
Monitor where it earns its cost
Field Audit History and event monitoring are priced and performance-costed per field. Enable them on the fields that carry regulated data, and leave the other nine hundred alone.
04 · you can now
Answer a subject request completely
Deletion and access requests can only be honoured against data you know exists, including files, attachments, and ContentDocuments that structured scanners never see. The same ledger scopes the erasure.
To be clearOrg Warden does not apply these controls, and does not need permission to. It produces the scope they are applied to, and the baseline they are measured against. When a new PII field lands outside that scope next quarter, it shows up as a drift row with a timestamp — which is the difference between a control you set once and a control that stays true.
Positioning

The governance layer Salesforce should have built. And nobody has, yet.

Salesforce ships four discrete tools that touch this problem: Data Detect, Data Mask, Shield, Privacy Center. Each works inside one org. Data Detect scans structured fields, so files and attachments (the biggest blind spot) sit outside it. Shield is an org-level product, and not every org in an estate has it. And none of the four maps PII to who can actually see it across the estate.

Third-party alternatives are worse for a different reason. Varonis and Odaseva ingest your data to work, run in the low six figures, and take months to deploy. AppOmni secures the container without looking inside. Blackthorn masks a single org with no discovery loop. Org Warden sits in the gap the rest describe by their absence.

See the full comparison
INV-1
Metadata-only egress
INV-2
Zero write code in production
INV-3
Sandbox-gated writes
INV-7
Tenant-isolated app
Every claim is a testable invariant. Read the security page →
Free baseline scan

Scan one org free. See where your PII lives.

No install-to-buy. You get a Baseline Report (the same artefact paying customers get) for one Salesforce org. Metadata-only, always. Your data never leaves your org.

Work email · we reply within 1 business day
Next argument · 2
How it works. Two packages, one seam.
The Core package installed in your production org contains no DML against customer objects. Not gated. Absent.