PCI DSS 6.5.6: Test data and test accounts are removed from system components before the system goes into
PCI DSS v4.0.1 control 6.5.6: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 6.5.
Requirement 6: Develop and Maintain Secure Systems and Software › Section 6.5
Test data and test accounts are removed from system components before the system goes into production.
Summary
Take the test data and test accounts out before the system goes live.
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 | |
|---|---|
| 6.5.6.a | Examine policies and procedures to verify that processes are defined for removal of test data and test accounts from system components before the system goes into production. |
| 6.5.6.b | Observe testing processes for both off-the-shelf software and in-house applications, and interview personnel to verify test data and test accounts are removed before a system goes into production. |
| 6.5.6.c | Examine data and accounts for recently installed or updated off-the-shelf software and in-house applications to verify there is no test data or test accounts on systems in production. |
Short and frequently overlooked, and the procedures make its scope wider than it first reads. 6.5.6.b observes testing processes for both off-the-shelf software and in-house applications, and 6.5.6.c examines data and accounts for recently installed or updated software. So this is not only about your own test fixtures: the default and demonstration accounts that ship with purchased software are test accounts, and an update can reintroduce them. The reason it matters is direct: test accounts tend to have weak, well-known credentials and broad rights, they are created outside the identity lifecycle so 8.2.4 never saw them, and they will not appear in an access review that works from the approved list.
What to prepare
- The documented removal step in the release process.
- Evidence of the check for recent installations and updates.
- A review of accounts on recently deployed systems.
- Vendor documentation listing default accounts for purchased software.
How to implement it
1. Make removal a gate, not a task. A release checklist item is forgotten under pressure; a check that fails the deployment is not.
2. Ask vendors what ships enabled. Default and demonstration accounts are documented, and knowing the list turns this into a specific check rather than a search.
3. Re-check after updates. 6.5.6.c names recently updated software, because an update can restore what a hardening step removed.
4. Search for the data as well as the accounts. Test records left in a production database are the half most often overlooked, since the accounts are what people think of.
Where this commonly fails
- Vendor default accounts left enabled, because the control is read as being about in-house test fixtures.
- Accounts removed at go-live and reintroduced by a later update.
- Test data left in production tables while test accounts were cleaned up.
- Removal as a checklist item with no evidence it was performed.
Related controls
Others in section 6.5:
| Control | What it requires |
|---|---|
| 6.5.1 | Changes to all system components in the production environment are made according… |
| 6.5.2 | Upon completion of a significant change, all applicable PCI DSS requirements are confirmed… |
| 6.5.3 | Pre-production environments are separated from production environments and the separation… |
| 6.5.4 | Roles and functions are separated between production and pre-production environments to provide… |
| 6.5.5 | Live PANs are not used in pre-production environments… |
← 6.5.5 · All controls · 7.1.1 →
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.