In practice the decision of which sensitive data protection technique to use runs on convenience. Someone asks whether the field should be encrypted or tokenized, the option the current tooling makes easiest wins, and the choice gets recorded as done. The techniques end up being treated as interchangeable flavors of the same control, differing mainly in implementation effort. They are not, and the differences don't show up in the compliance checklist. They show up months later in the pipeline that breaks, the join that silently fails or the breach report that turns on where a key was.

The question that sorts them has nothing to do with algorithm strength: After the transformation, what does it take to get the original value back?

Three things follow from the answer:

1. What has to be compromised for an attacker to recover the data

2. Whether that recovery happens offline, out of sight or through a live system that logs and can be shut off 

3. Whether you can revoke the path afterward 

Every sensitive data protection technique has a different answer to that one question.

By mechanism, protection techniques fall into four families: 

1. Reversible encryption: a key recovers the value (e.g. probabilistic encryption) 

2. Substitution: a surrogate replaces the value (e.g. tokenization)

3. Access-level controls: the value stays intact (e.g. dynamic masking) 

4. Irreversible removal: no path back to the plaintext (e.g. redaction)  

The image below shows which bucket each protection technique falls into, but this mapping alone cannot make the decision. Hashing and tokenization share the substitution family and answer the recovery question in opposite ways, never and conditionally.

This classification tells you what a technique is. It does not tell you what it takes to get the value back, which is the focus of this post. The rest of this post focuses only on the top 5 sensitive data protection techniques organizations use in production: tokenization, various flavors of encryption and good ‘ol redaction.

Tokenization vs encryption vs redaction, sorted by recovery path

The recovery question asks what it takes to get a value back. Usability asks what still works while the value is away and it splits between format-preserving and deterministic approaches.

• Format preservation keeps the protected values flowing through schemas, type checks and pipelines. A 16-digit credit card number still has 16 digits in the same structure, but uses different numbers. 

• Determinism keeps them relating. Equal values stay recognizable as equal, so joins run, duplicates collapse and entities match without anyone recovering anything. 

The five sensitive data techniques in the table below differ on both of these, with determinism being the quieter one—easy to lose without noticing until a join goes wrong.

See the table below for an example of what the same value looks like under each technique and how that impacts downstream systems.

Redaction: no recovery path, on purpose

Let’s start at the far end. Redaction destroys the value at write time: no key, no lookup, no derivation and no way back for anyone, including you. That's exactly right when the value is genuinely finished, like the card number on a receipt or the SSN in a support screenshot.

This is also true for static masking, where a realistic fake replaces the plaintext, but not dynamic masking where the read-time control hides parts of an intact value from particular roles. Dynamic masking destroys nothing, the value is still there and usually protected some other way. Dynamic masking returns near the end of this article as a layer rather than a choice. 

The risk in redaction sits on the usability side: redacting a field that future analytics or machine learning (ML) training workloads will need to join on. The value is gone, nothing will throw an error and the results downstream will be quietly wrong. Before redacting anything, ask whether any team will need the value again (not just this one) and also ask the owners of the downstream use cases.

Probabilistic encryption: the key recovers it and structure pays for it

AES-GCM is an advanced encryption algorithm used widely for probabilistic encryption. It is the workhorse, and for data at rest and in motion, it's the correct default. Its recovery path is clean: Ciphertext plus key yields plaintext, offline, for whoever holds both. 

Two clarifications: 

1. Field protection lives almost entirely in symmetric encryption, one key for both directions, because it is fast enough for row-level work and its keys are small. Asymmetric encryption, the public and private kind, earns its keep protecting keys in transit and signing things, not columns. 

2. In production, the key rarely sits next to the data. The common pattern is envelope encryption: Data is encrypted under a data key and the data key is wrapped by a master key inside a managed Key Management Service (KMS). So, the key actually has layers. The algorithm's recovery is offline, but a KMS-held master key turns every unwrap into a logged service call that can be denied. 

The randomness that makes AES-GCM non-deterministic is also not a mystery. It’s a nonce, a fresh random value drawn for every encryption and stored beside the ciphertext. Same plaintext tomorrow, new nonce, unrelated ciphertext. The mode also authenticates: A tag computed over the ciphertext means a flipped bit gets caught at decrypt instead of silently accepted, a property that will matter again later on in this post. 

The cost is structural. Probabilistic encryption turns a 16-digit account number into a variable-length binary blob that fails the CHAR(16) column, the Luhn check and every join against another system's copy of the field. That forces a choice between rewriting every downstream consumer, or decrypting early and broadly. In practice, the second usually wins, which gradually reintroduces the plaintext the encryption was meant to remove. 

None of that makes AES-GCM weak. It means a technique that destroys structure gets worked around and the workaround is where the exposure comes back.

Format-preserving encryption (FPE): same path, structure survives

FPE exists to remove that workaround. Standardized in NIST SP 800-38G as the FF1 and FF3-1 modes, it encrypts a value into the same alphabet and length as the input: 16 digits in, 16 digits out. Schemas hold and pipelines run unmodified. On the recovery axis it sits exactly where AES-GCM sits: the key recovers the value, offline. One trade rides along with the format of 16 digits leaving no room for an authentication tag. FPE lacks built-in integrity validation, any correctly formatted input will decrypt into a valid plaintext. The surrounding system must compensate for the in-band tamper protections that standard algorithms like AES-GCM include by default.

One caveat before deployment. Because the ciphertext space is exactly as small as the plaintext space, FPE on a very short field has a much smaller security margin than AES on arbitrary binary. FF3 was revised to FF3-1 after published attacks on tweak handling. The tweak is a second input to the cipher, varying the mapping per context without changing the key. Use the current mode and treat the domain size and tweak design as decisions, not defaults.

Deterministic encryption: joins, priced in frequency

Deterministic encryption, with AES-SIV as the standardized construction, always maps the same input to the same output under a given key. Set it next to the probabilistic AES-GCM and the cleanest A/B in this article appears. 

• AES-SIV: same keys, same custody, same recovery path and same blob output. 

• AES-GCM: same keys, same custody, same recovery path, different nonce and blob output per encryption. 

The single toggle of determinism decides whether the protected data can be operated on at all:

• Turn it on and equal ciphertexts mean equal plaintexts, so joins, dedupes and group-bys run against the protected form. 

• Turn it off and every occurrence is a stranger to every other. 

That toggle is the entire appeal and the entire price of the deterministic approach. 

It even has a mechanism: the nonce. Probabilistic encryption draws one at random. Deterministic encryption synthesizes it from the plaintext itself. This is exactly what makes equal inputs collide on purpose, and the synthetic value doubles as the authentication tag, so determinism here keeps tamper detection. 

Determinism isn’t free. Equal plaintexts producing equal ciphertexts means the frequency distribution of the data survives into the protected form and a low-cardinality field can be attacked by frequency alone, no key required. Deterministic encryption is a reasonable trade when equality matching is a hard requirement and the field is high-cardinality (e.g. an email address or an account number). 

Tokenization: recovery becomes conditional and logged

Everything above shares one property: recovery is a function of key possession. Tokenization is where that changes. 

• In a vaulted tokenization system, recovery is a lookup against a live system, which means it can be logged, throttled, rate-limited and shut off. 

• In a vaultless tokenization system, recovering the original data relies on strict policy rather than a database lookup. The client must interface with the tokenization service and pass authorization checks to detokenize specific fields from approved environments. Every request is permanently logged.

Redaction vs encryption vs tokenization side by side 

The table below compares all the techniques against each other, with the fourth column doing the sorting.

Replaying the theft

An attacker exfiltrates a protected customer table. What happens next depends entirely on which technique protected it.

• Redaction: The attacker holds what a receipt shows and there is nothing to pursue. 

• Probabilistic encryption: The attacker holds unreadable blobs and the situation is a race on key custody alone. One detail here is under-appreciated: Rotating keys after the theft protects future writes, not the copy already outside, so the stolen data stays exactly as safe as the key that encrypted it, forever. 

• FPE: The blobs become well-formed values, which reveal structure and that a very small field can be searched offline. 

• Deterministic encryption: Even with no key at all, frequency work on a low-cardinality field starts the same afternoon because equal values sit in the stolen table as equal ciphertexts.

• Tokenization: This is where the attacker changes their strategy. Because stolen tokens are useless on their own, the theft must be followed by a secondary compromise. If you use a vaulted architecture, the attacker must query your live system, exposing themselves to logging, rate-limiting and revocation. If you use a vaultless platform, the tokens remain inert until the attacker manages to breach your access policies and hijack the algorithm itself.

Choosing the right data protection by field

The decision on how to protect your sensitive data runs as three questions in order. Speed is deliberately not one of them. At field level, every technique is fast enough that the recovery and usability answers should decide.

1. Will this value ever be needed again, by anyone, for anything? If genuinely no, and the downstream owners agree, redact it and be done.

2. Does anything downstream need the field's format, type or joins? If not, AES-GCM is the default and the default is usually right.

3. If structure has to survive, decide who should be able to get the value back and under what control. If key holders recovering it offline is acceptable, format-preserving encryption fits. If recovery should be limited to specific roles, under policy with an audit trail, that's what a tokenization platform is for.

The framework, applied in an example

The table below displays the framework run across one realistic example. Let’s consider how to best protect the different fields of a customer information table in a payments business.

Six fields, four different answers and one honest question mark. That spread is what a deliberate pass looks like. A table protected with a single technique across every column usually means the decision was made once, by whichever option the tooling made easy.

The techniques compose

The framework reads as a choice of one, and production estates rarely work that way. Disk and transport encryption sit under everything as a baseline, regardless of what happens per field. 

Tokenization protects the specific fields whose values travel and join. Dynamic masking, the read-time control from earlier, sits on top as a presentation rule, revealing only what a role should see of a value that is tokenized underneath. The per-field decision this article describes happens in the middle of that stack and it is the layer where the choice genuinely varies.

Conclusion

One question sorted everything here: What does it take to get the value back? 

• Redaction: You don’t get the value back. 

• Encryption: You need a key to get the value back. 

• Tokenization: You need the algorithm plus a policy that says yes, on the record, to get the value back. 

The right answer changes field by field because the twin question changes field by field. What has to keep working while the value is away? A card number joining three systems and a status flag with five possible values are different problems. A table protected uniformly is usually protected by default rather than by decision. Choose it per field, on purpose, and it holds.

Databolt lets you do just that. Its vaultless tokenization platform provides robust data security without sacrificing the data utility required to innovate. To see how that lands on your own data, book time with the Databolt team.