Month 3. Domain 3: Protecting the Crown Jewels
The Summary: What are we actually doing?
If Domain 1 was our fence and Domain 2 was our lock, Domain 3 is the vault. In the chronicles of PCI Castle, this is the art of hiding what needs to be hidden.
We are here to protect Account Data. If by any luck an intruder manages to scale your walls and pick your locks, Domain 3 is the final line of defense that ensures they find nothing but useless, encrypted gibberish.
In our medieval keep, this means:
- Don’t Keep What You Don’t Need: If the King doesn’t need a specific pile of precious metal, we melt it down or give it away to somebody we trust (Data Retention).
- The Invisible Ink: We write our ledgers in a secret code that only the High Alchemist can read (Encryption).
- The Broken Map: We hide the location of the treasure room and ensure no single person has the full set of keys to the door (Key Management).
The objective is to ensure that the “Crown Jewels” – the sensitive data itself – are never left lying in the open, even within your strongest keep. If an enemy spy manages to scale your walls (Domain 1) and pick your locks (Domain 2), they must find only unreadable scrap or empty chests.
You must establish a “Rule of Minimum Presence”: keep only what is vital for the kingdom to function, for a treasure that does not exist cannot be stolen. For the gold you must retain, it must be hidden behind layers of mathematical alchemy (encryption, truncation, or hashing). The keys to these chests must be guarded more fiercely than the gold itself, split among your most trusted key custodians so that no single traitor can unlock the vault alone.
It’s great that you’ve bolted the chest to the floor. Truly. But if you leave the key hanging on a nail next to it, or worse, scribble the combination on the ‘secret’ underside of the lid, you haven’t built a vault; you’ve built a gift-wrapped lunch box for the intruder.
Three Common Pitfalls (Which We Often Encounter)
1. The Hoarder’s Curse: Keeping “Just in Case”
Often, a lord keeps every scroll from the last decade “just in case.” In PCI terms, keeping full PAN or Sensitive Authentication Data (SAD) after authorization is the fastest way to fail an assessment. If you don’t store it, they can’t steal it.
2. The Key Under the Doormat (and the Default KCV)
We frequently find that while the treasure is in a strong box, the key is compromised from the start. A classic example from our field notes: finding a default KCV (Key Check Value) on a production HSM. If your KCV is the vendor’s factory default, you haven’t built a vault; you’ve built a glass case. It means your “Master Key” is likely all zeros or a known test key.
3. The “Almost” Encrypted Ledger
A spy doesn’t need to crack your encryption if they can find the data in your “trash” (logs or debug files). We often see beautiful encryption in the database, but cleartext card numbers floating in a catalina.out log file or a developer’s test_data.csv.
Assessment Tips & Tricks
- Think Beyond DSS: If you use HSMs, get familiar with PCI PIN and PCI P2PE standards now. If you, for example, decide to build a P2PE solution one day but if you don’t have the original tamper-evident bag (TEB) numbers, the courier tracking logs, and the ‘signed-on-receipt’ serial number checks, you cannot prove the device hasn’t been intercepted. In a P2PE audit, if the chain is broken, the device is untrusted – period. You can’t prove the device wasn’t tampered with during transit three years ago. Even if you won’t need those standards in the near future, they give you a better understanding and set higher cryptography and key management security requirements.
- Think three moves ahead: When implementing encryption, don’t just aim for current compliance—aim for longevity. For example, NIST deprecated TDEA (3DES) years ago due to its vulnerability to “Sweet32” attacks. While the payment industry still allows it for legacy support, the sunset is inevitable.
If you are building new environments or updating existing ones, skip the “minimum bar”. Migrate to AES (preferably 256-bit) now. It is significantly more efficient to implement modern ciphers during a planned build than to scramble for a “cryptographic migration” project when the PCI Council officially moves the goalposts. - The “Search & Destroy” Mission: Before your QSA arrives, run a tool to find unencrypted PANs in unexpected places (e.g. Card Recon ot its free alternatives).
- Automation Corner: Use Cloud KMS to handle key rotation if you can afford it. It’s much safer than having a human “Blacksmith” manually rotating keys and potentially seeing the cleartext.
Typical Evidence Required
| PCI DSS Requirement | Evidence Required | Tryggr’s Comment |
| 3.1.1 | Cardholder data retention and disposal policies and procedures | Use common sense when defining CHD retention period. Of course, we must respect the law but if it says “store your transactions for 10 years”. Make sure you delete those transactions after 10 years. |
| 3.1.2 | Role and responsibility definitions | |
| 3.2.1 | Evidence on storage, protection, and secure deletion of CHD/SAD for all data repositories | Make sure you don’t only know where you DO store cardholder data, but where you MAY potentially discover this data: trace files, heap dumps, debug/troubleshooting data, legacy/migration data, backups, emails etc. Various commercial and open-source tools may help you to discover CHD/SAD instances. |
| 3.3.1 | Evidence of non-storage of SAD in non-persistent memory after authorization | If you are not an issuer or supporting issuing services, of course. |
| 3.3.2, 3.3.3 | Evidence of strong cryptography used to protect SAD prior to authorization | |
| 3.4.1 | Evidence proving that PAN masking is in accordance with the requirements, and those who see the full PAN have a justification of their access | Please get familiar with PCI SSC FAQs related to long BINs (more than 6 digits) and difference between truncation and masking. |
| 3.4.2 | Evidence on protection against CHD copy/paste when accessing CHD remotely | This one can be tricky. You need to analyze carefully your remote access technologies and use technical measures if feasible. For example, use Group Policy Objects (GPOs) or RDP Gateway settings to lock down the RDP session, consider Virtual Desktop Infrastructure (VDI) or a Remote Browser Isolation (RBI) for web applications, use DLP solutions. Also, keep in mind that technical controls like GPOs are great, but don’t forget the ‘Analog Hole.’ A screen-shredding policy or VDI is useless if the person at the other end is taking a photo of their monitor with a smartphone. This is where your awareness training (Domain 12) must meet your technical vault. |
| 3.5.1 | Evidence on protection of CHD during storage (hashing, truncation, encryption, tokenization). Details of hashing and encryption algorithms in use and their mode of operation, key length, location, and lifecycle. | |
| 3.5.1.2, 3.5.1.3 | Details of disk-level or partition-level encryption, if in use. | Note that this requirement does not apply to database file-, column-, or field-level encryption (e.g. Oracle TDE). |
| 3.6.1, 3.7.x | Cryptographic key management policies and procedures. | They must cover the entire key lifecycle (generation, cryptoperiod, storage, use, distribution, protection during storage and transmission, replacement at the end of life or in case of suspected or confirmed compromize, dual control etc.) |
| 3.6.1.1 | Cryptographic acrhitecture description, including: Key flows, generation, distribution, and storage diagrams, Key inventory, SCD inventory (HSM, POI, KLD, etc.) Details of cryptographic algorithms in use (key length, mode of operation, TLS cipher suites etc.) | |
| 3.6.1.2 | Key storage evidence (e.g. HSM output or AWS KMS key inventory, storage of printed key components or TR-31/TR-34 key bundles). | |
| 3.6.1.3 | Access settings to cryptographic keys, their components/shares, SCDs, etc. | |
| 3.7.8 | Signed key custodian forms. | This is not just a formality. Key custodians must understand and formally acknowledge that big responsibility they adopt when managing the keys protecting your valuable assets. Neglecting these responsibilities may ruin your business! |
Need assistance?
If you need any help while preparing for your assessment or would like to have quick call about PCI DSS, 3DS, PIN Security, P2PE or DORA compliance, please feel free to reach out to us at Trausta. We’re
always here to ensure a smooth and secure compliance process.
Next Month: Domain 4 – Securing the Messenger’s Path
