PCI DSS 12.5.1: An inventory of system components that are in scope for PCI DSS

PCI DSS v4.0.1 control 12.5.1: the requirement in full, the 2 testing procedures an assessor uses to verify it, and the related controls in section 12.5.

Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.5

An inventory of system components that are in scope for PCI DSS, including a description of function/use, is maintained and kept current.

Summary

Keep a current inventory of every system component in scope, saying what each one is for.

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
12.5.1.a Examine the inventory to verify it includes all in-scope system components and a description of function/use for each.
12.5.1.b Interview personnel to verify the inventory is kept current.

The list almost every other control is measured against. 12.5.2 validates the scope this inventory describes; anti-malware coverage at 5.2.1, logging at 10.2.1, patching at 6.3.3 and scanning at 11.3.1 all mean "across the inventory", so a component missing here is invisible to all of them at once. The description of function or use is not decoration: it is what lets an assessor tell whether the coverage decisions made about that component were reasonable.

What to prepare

  • The inventory itself, with a function or use description per entry.
  • Evidence it is current, which usually means the process that adds and removes entries.
  • A reconciliation against something independent: cloud account listings, DNS, the asset agent.

How to implement it

1. Generate it, do not maintain it by hand. A hand-kept spreadsheet is stale within a quarter. Cloud APIs, an agent census or a configuration database gives you an inventory that is current by construction.

2. Reconcile against a second source. The components missing from an inventory are precisely the ones nobody remembered, so the only way to find them is to compare against something that did not come from the same memory.

3. Describe the function properly. "Server" is not a use. "Terminates TLS for the payment page" tells the assessor why it is in scope and what should be true of it.

4. Include the things that are not servers. Network devices, cloud services, containers, SaaS in scope and the endpoints administrators work from are all system components.

Where this commonly fails

  • An inventory that lists production and omits staging systems connected to the CDE.
  • Ephemeral compute absent because it did not exist when the list was written.
  • Function descriptions missing, which is a named element of the requirement.
  • The list current at the last assessment and unmaintained since, which every downstream control inherits.

Others in section 12.5:

Control What it requires
12.5.2 PCI DSS scope is documented and confirmed by the entity at least once every 12 months and upon…
12.5.2.1 Service providers: PCI DSS scope is documented and confirmed by the entity at least once every six months and upon…
12.5.3 Service providers: Significant changes to organizational structure result in a documented (internal) review…

12.4.2.1 · All controls · 12.5.2

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.