File Level Encryption
PCIComplianceHubLast updated
Encryption applied to individual files, columns or database fields rather than to a whole drive. Because the protection travels with the data and decryption is bound to a specific application or user context, file-level encryption keeps working where full-disk encryption stops: an authenticated user or a compromised process on the host does not automatically obtain the plaintext. This is why PCI DSS treats file, column and field-level encryption as a primary way of rendering a stored primary account number unreadable, while placing restrictions on disk-level encryption used for the same purpose.
Applies to. Requirements 3.5.1.2 and 3.5.1.3 name file-, column- and field-level database encryption as the contrast to disk- or partition-level encryption: the restrictions those two requirements impose fall on disk encryption, not on file-level encryption. File-level encryption used to render stored PAN unreadable is assessed under 3.5.1 as strong cryptography with key-management processes, and its keys fall under Requirements 3.6 and 3.7.
Example. A merchant's settlement job writes PAN to a batch file for its acquirer. The application encrypts each file with a data-encrypting key before it lands on disk, so a support engineer with a shell on the server sees only ciphertext, and the key lives in the key management system rather than in the export script. The assessor examines the encryption under 3.5.1 and the key storage form under 3.6.1.2.
Limits. File-level encryption protects the file, not the data once an authorised process has opened it; PAN read into memory, logged, or written to a temporary file is outside its protection. It is not full-disk encryption, which decrypts everything for any authenticated user and which 3.5.1.2 accepts alone only on removable media. The label does not carry the requirement: a file encrypted with a key stored in the same directory, or with a key that never changes, fails 3.6.1 and 3.7.4 regardless of the file-level design.