Flight schools keep two kinds of records: the logbook entries everyone handles carefully, and the quieter pile — admission scans, identity documents, medical certificates, card details — that nobody formally assigned to anyone. When a table like that starts moving between offices, the useful question stops being “is it secure?” and becomes “which hiding technique belongs on which field?” DataSecOps, the practice of guarding information while both the records and their readers keep changing, answers that question at the level where the choice is actually made: the column, the row, the single query. This piece compares the four main shields on evidence rather than brochure copy, because each one carries a different legal weight, a different keeper of keys, and a different set of engine quirks. The scoping comes from the Atlas reference entry on DataSecOps, which also names the platforms quoted below.
One DataSecOps decision comes before any shield
Pick the unit of control first. In this practice, rules attach to the smallest useful unit — a whole row, a single column, or even one query — and they get evaluated at read time, when someone actually asks for the value. That detail matters more than it sounds: a rule evaluated at read time can consider who is asking, from where, and for what purpose. The second decision is where the rule lives. Rules written as versioned files and applied through a pipeline keep a history of who changed what; rules typed into a vendor console by hand keep no such record, which is why console-typed policies show up on every list of anti-patterns. Only after those two choices are settled does it make sense to argue about masking versus tokenisation at all.
Shield one: masking at the moment of reading
A masking policy swaps a live value for a placeholder unless the reader holds the right role. The platform evidence is specific. Snowflake gates its masking, row-access and classification features behind the Enterprise edition or higher, so a school on a lower tier is shopping for a feature it cannot yet switch on. Two engine behaviours deserve memorising. First, the platform allows exactly one policy per data type on any tagged column, so competing rules cannot be stacked on the same field. Second, once a policy attaches to an object it cannot be exchanged for a different one; the only edit allowed is changing the body of the policy that is already there, through SET BODY. In the open-source world, Apache Ranger has offered column masking and row filters since version 0.6. One documented limit rounds this out: Snowflake row policies do not stop inserts, so a rule that hides rows from a reader may still let that reader add rows.
Shield two: tokenisation that keeps the value’s shape
Format-preserving encryption scrambles a value into a stand-in of identical shape — a card number stays number-shaped, an account number stays account-shaped — so downstream systems that validate format keep working. The named implementation in this space is HashiCorp Vault Transform, which uses the FF1 scheme. The decisive property is reversibility: whoever holds the key can recover the original, and nobody else can. That makes key custody the entire security argument. Tokenisation suits fields that must survive round trips through systems with strict format checks — payment references are the standard example — while it wastes effort on fields nobody ever needs back in their original form.
Shield three: pseudonymisation, plus one ruling from Luxembourg
Pseudonymisation replaces direct identifiers with stand-in values while keeping a separate key that could restore the link; European law defines it at Article 4(5) of the GDPR. The Court of Justice closed the argument on 4 September 2025 in its EDPS v SRB judgment (C-413/23 P): for a recipient who genuinely cannot re-identify anyone, pseudonymised records do not count as personal data — but the copy sitting with whoever holds the key remains personal data, without exception. Regulators add a sober footnote: the EDPB’s 2025 draft guidance warns that pseudonymisation on its own falls short of a complete measure in most situations. And one failure mode keeps recurring in the wild: hashing an email address protects nothing, because a deterministic hash can be joined against other lists and guessed for common addresses — at best that is pseudonymisation, not anonymity.
Shield four: de-identification as a measured release decision
De-identification is different in kind: not a setting on a column but a judgement that a dataset, taken whole, no longer singles anybody out. NIST SP 800-188 frames it exactly that way: a judgement made before release, with whatever risk remains measured rather than assumed. The HIPAA Safe Harbor list gives the concrete checklist: eighteen identifier types must go, postcodes collapse to 000 wherever the population is 20,000 or fewer, and every age of 89 or above gets lumped into a single band. The cautionary arithmetic is older than all of this — researchers showed that 87% of Americans are uniquely identifiable from just postcode, gender and date of birth, three fields most teams would wave through as harmless. A dataset that keeps those three is not de-identified, whatever the covering note claims.
The DataSecOps verdict, field by field
Put the four shields side by side and the differences become a set of questions you can ask about any column:
- Can the change be reversed? Masking at read time reverses itself the moment a privileged reader asks; tokenisation reverses only with the key; pseudonymisation reverses for the key holder alone; de-identification does not reverse at all — that is the point.
- Who carries the risk? With masking, the platform enforces and the policy author answers for gaps. With tokenisation and pseudonymisation, the key holder’s copy stays fully personal, per the Luxembourg ruling. With de-identification, the risk is residual and must be measured, not assumed away.
- Does it survive copying? Shield one and two follow the governed object; the moment someone copies a table or rebuilds it with CREATE OR REPLACE, attached tags fall off — an engine behaviour worth assuming rather than discovering.
- What does each suit? Masking for shared operational tables; tokenisation for payment-shaped fields; pseudonymisation for analytics handed to parties who cannot re-identify; de-identification for anything leaving the organisation.
One more distinction closes the comparison. Regulators and analysts group the tooling — Snowflake’s native features, the overlay products — Immuta and Privacera, alongside Commvault’s Satori range since its 2025 acquisition — under Gartner’s “data security platforms” label from the 2025 market guide. A platform category is a shopping aisle, not a legal status; the shields above are what actually decide how a released dataset behaves.
Running the comparison on your own tables
Start from classification, and hold it loosely. Automated scanners — Google’s DLP tooling and Microsoft’s Presidio are the usual names — never reach full accuracy, so a human confirms every IDENTIFIER or SENSITIVE tag before a rule builds on it. Then assign shields column by column, cheapest sufficient option first, and write the reasoning down next to the table so the next person inherits the argument, not just the rule. The habit transfers from paper aviation, where a logbook kept accurate protects a career precisely because entries are attributed, dated and unforgeable in practice; the same instinct powers a disciplined student logbook, and the same care extends to tracking every training hour in the systems that replaced paper. A column-by-column decision log is the digital version of the same discipline: dull, dated, and worth more than any single tool choice on this list.
