PCI DSS 3.5.1.2: If disk-level or partition-level encryption
PCI DSS v4.0.1 control 3.5.1.2: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 3.5.
Requirement 3: Protect Stored Account Data › Section 3.5
If disk-level or partition-level encryption (rather than file-, column-, or field-level database encryption) is used to render PAN unreadable, it is implemented only as follows:
- On removable electronic media OR
- If used for non-removable electronic media, PAN is also rendered unreadable via another mechanism that meets Requirement 3.5.1.
Summary
Full-disk encryption only counts on removable media. On a running server you need something else as well.
What the assessor will examine
These are the testing procedures the standard defines for this control. They tell you what evidence to have ready.
| Procedure | |
|---|---|
| 3.5.1.2.a | Examine encryption processes to verify that, if disk-level or partition-level encryption is used to render PAN unreadable, it is implemented only as follows: • On removable electronic media, OR • If used for non-removable electronic media, examine encryption processes used to verify that PAN is also rendered unreadable via another method that meets Requirement 3.5.1. |
| 3.5.1.2.b | Examine configurations and/or vendor documentation and observe encryption processes to verify the system is configured according to vendor documentation the result is that the disk or the partition is rendered unreadable. |
The sharpest point in section 3.5, and the one that surprises people: disk-level encryption does not render PAN unreadable on a running system. The volume is mounted and decrypted while the system runs, so anyone with operating system access reads plaintext, and that is the threat the requirement is about. Disk encryption protects a stolen drive and nothing else. The control therefore permits it as the sole mechanism only on removable electronic media, and on non-removable media requires PAN to be rendered unreadable by another mechanism meeting 3.5.1 as well: file, column or field-level encryption, tokenisation, truncation, or the keyed hash in 3.5.1.1. Entities that have deployed full-disk encryption widely often believe Requirement 3.5 is met, and this control is where that is tested.
What to prepare
- Where disk or partition-level encryption is used, and on what media.
- For non-removable media, the second mechanism and evidence it is applied to the PAN.
- Vendor documentation and configuration for the encryption in use.
- The distinction, written down, between removable and non-removable in your estate.
How to implement it
1. Decide what protects PAN on running systems, separately from disk encryption. Column or field-level encryption, tokenisation or truncation are the mechanisms this control points at.
2. Keep disk encryption anyway. It is the right control for physical loss and for decommissioning, and it satisfies this requirement outright on removable media.
3. Check what your database actually offers. Transparent database encryption is often disk-level in effect, decrypting for any authenticated session, so read the vendor documentation the procedure examines.
4. Prefer removing the PAN. Tokenisation avoids the question entirely, and it is usually the cheaper answer than layering encryption.
Where this commonly fails
- Full-disk encryption presented as meeting 3.5.1 on servers.
- Transparent database encryption assumed to be field-level when it decrypts for every session.
- Removable and non-removable media not distinguished, so the exception is applied too broadly.
- A second mechanism applied to some columns and not to every place PAN is stored.
Related controls
This control refers to 3.5.1.
Others in section 3.5:
| Control | What it requires |
|---|---|
| 3.5.1 | PAN is rendered unreadable anywhere it is stored by using any of the following approaches… |
| 3.5.1.1 | Hashes used to render PAN unreadable (per the first bullet of Requirement 3.5.1) are keyed… |
| 3.5.1.3 | If disk-level or partition-level encryption is used… |
← 3.5.1.1 · All controls · 3.5.1.3 →
Source
The requirement text and testing procedures above are reproduced from PCI DSS v4.0.1 (June 2024), ©2006-2024 PCI Security Standards Council, LLC. All rights reserved. The commentary is our own.
The official standard is authoritative and also contains the Customized Approach Objective, applicability notes and guidance for this control. Download it from the PCI Security Standards Council document library. PCI DSS is a registered standard of the PCI Security Standards Council, LLC, which does not endorse this site. Nothing here is a substitute for advice from a Qualified Security Assessor.