PCI DSS on data platforms: keeping card data out of your lakehouse

Analytics teams want transaction data, and transaction data often arrives with card numbers attached. Load those primary account numbers (PANs) into a lakehouse and PCI DSS scope can expand to the platform, its pipelines and everyone with access. The cleaner answer is usually to make sure card numbers never arrive.

Not legal advice. Confirm scope and controls with your Qualified Security Assessor.

What counts as card data

PCI DSS v4.0.1 separates account data into two kinds:

• Cardholder data: the PAN, plus cardholder name, expiration date and service code when stored with it.
• Sensitive authentication data: full track data, card verification codes (CVV and similar), PINs and PIN blocks. This must not be stored after authorization, even encrypted.

For a data platform, the PAN is the field that matters. Without it, name and expiry alone are not cardholder data under the standard.

The recommended pattern: tokenize before ingestion

1. The payment system or gateway tokenizes the PAN at the point of capture, using a tokenization service or your payment provider’s tokens.
2. Pipelines carry only tokens, plus truncated values (for example the last four digits) if analysts need them.
3. The data platform cannot detokenize. The vault and keys sit with the payment environment, not the analytics team.

Tokens still support analytics: count repeat customers, join transactions to the same card, detect fraud patterns. What they cannot do is leak a usable card number. Your assessor decides scope, but this is the pattern that usually keeps a lakehouse out of the cardholder data environment.

Watch the side doors: raw landing zones, log files, support ticket exports and free-text fields where customers type card numbers. Scan for PAN patterns in ingested data and quarantine anything found.

If the platform must store card numbers

Some fraud, disputes or reconciliation workloads genuinely need PANs. Then the platform is in scope and Requirement 3 (protect stored account data) applies in full. Key points for data teams:

• Make PANs unreadable wherever stored (requirement 3.5.1), using strong cryptography with key management, truncation, index tokens, or one-way hashes.
• Hashes must be keyed (requirement 3.5.1.1, mandatory since 31 March 2025): a keyed cryptographic hash of the entire PAN, such as an HMAC, with the key managed like any other cryptographic key. Plain hashes are not enough because card numbers are easy to brute-force.
• Do not combine hashed and truncated versions of the same PAN in a way that lets someone reconstruct it.
• Limit retention: keep account data only as long as needed, and delete it on a defined schedule.
• Restrict and log access: role-based access, display masking (show at most the first six and last four digits unless there is a business need), and logs of every access.

Column masking, row access policies and audit logs on Databricks, Snowflake or Fabric help with the last two, but they do not replace encryption or tokenization of the stored values.

A checklist for data teams

1. Find every place card numbers enter the data estate, including logs and free text.
2. Tokenize at the source; keep the vault and keys out of the analytics environment.
3. Scan landing zones for PAN patterns and alert on any hit.
4. Never ingest sensitive authentication data.
5. If PANs must be stored: keyed hashes or strong encryption, managed keys, masking, logging and retention limits.
6. Agree the platform’s scope with your Qualified Security Assessor and document it.

The short version

Keep card numbers out of the data platform: tokenize before ingestion, carry only tokens and last-four digits, and scan for PANs that slip through. If you must store them, PCI DSS Requirement 3 applies, including keyed hashes since 31 March 2025. Our data quality and governance service helps design these controls.

Related: Databricks vs Snowflake for financial services, DORA for bank data platforms, what is data lineage and our financial services page.

Sources

• PCI DSS v4.0.1 and supporting documents, PCI Security Standards Council document library