PCI DSS 12.3.4: Hardware and software technologies in use are reviewed at least once every 12 months
PCI DSS v4.0.1 control 12.3.4: the requirement in full, the 1 testing procedure an assessor uses to verify it, and the related controls in section 12.3.
Requirement 12: Support Information Security with Organizational Policies and Programs › Section 12.3
Hardware and software technologies in use are reviewed at least once every 12 months, including at least the following:
- Analysis that the technologies continue to receive security fixes from vendors promptly.
- Analysis that the technologies continue to support (and do not preclude) the entity’s PCI DSS compliance.
- Documentation of any industry announcements or trends related to a technology, such as when a vendor has announced “end of life” plans for a technology.
- Documentation of a plan, approved by senior management, to remediate outdated technologies, including those for which vendors have announced “end of life” plans.
Summary
Once a year, look at the technologies you run and ask whether they are still supported, still let you comply, and still have a future.
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.3.4 | Examine documentation for the review of hardware and software technologies in use and interview personnel to verify that the review is in accordance with all elements specified in this requirement. |
The obsolescence control, and it is broader than a patch review. Four elements, and the first two are different questions. Do the technologies still receive security fixes from vendors promptly, which is about the vendor. Do they still support and not preclude PCI DSS compliance, which is about you: a platform that cannot do multi-factor authentication, or cannot log what 10.2.1 needs, precludes compliance while remaining perfectly supported. The third element asks for documentation of industry announcements or trends, end-of-life notices in particular, and the fourth for a remediation plan approved by senior management, which is the element that makes this control bite: a review producing a list nobody has funded is not a plan. Note that 3.6.1.1 explicitly maintains its cryptographic device inventory to support this control, so for service providers the two are written together.
What to prepare
- The technology inventory the review runs against.
- Vendor support status and end-of-life dates per technology.
- The analysis against PCI DSS capability, which is separate from support status.
- The remediation plan, with evidence of senior management approval.
How to implement it
1. Ask the compliance question separately from the support question. They have different answers, and a supported technology that cannot meet a requirement is the case the second element exists for.
2. Record end-of-life dates as they are announced, not at review time. The third element is about tracking announcements, and an annual scramble to find them produces a worse answer than a running list.
3. Get the plan approved, not just written. Senior management approval is a named element, and it is what turns a known problem into a funded one.
4. Reuse the inventories you already have. 6.3.2 covers software components and 3.6.1.1 covers cryptographic devices, both of which feed this review.
Where this commonly fails
- A patch-currency review offered as this control, which answers neither of the first two elements.
- End-of-life technologies known about informally with nothing documented.
- A remediation list with no senior management approval, so the fourth element is unmet.
- The compliance-capability analysis skipped, since it is the element that has no vendor to ask.
Related controls
Others in section 12.3:
| Control | What it requires |
|---|---|
| 12.3.1 | For each PCI DSS requirement that specifies completion of a targeted risk analysis… |
| 12.3.2 | A targeted risk analysis is performed for each PCI DSS requirement that the entity meets… |
| 12.3.3 | Cryptographic cipher suites and protocols in use are documented and reviewed at least once… |
← 12.3.3 · All controls · 12.4.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.