PCI DSS 2.2.3: Primary functions requiring different security levels
PCI DSS v4.0.1 control 2.2.3: the requirement in full, the 3 testing procedures an assessor uses to verify it, and the related controls in section 2.2.
Requirement 2: Apply Secure Configurations to All System Components › Section 2.2
Primary functions requiring different security levels are managed as follows:
- Only one primary function exists on a system component, OR
- Primary functions with differing security levels that exist on the same system component are isolated from each other, OR
- Primary functions with differing security levels on the same system component are all secured to the level required by the function with the highest security need.
Summary
Do not let functions with different security needs share a machine, unless they are isolated from each other or everything on it is secured to the highest need.
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 | |
|---|---|
| 2.2.3.a | Examine system configuration standards to verify they include managing primary functions requiring different security levels as specified in this requirement. |
| 2.2.3.b | Examine system configurations to verify that primary functions requiring different security levels are managed per one of the ways specified in this requirement. |
| 2.2.3.c | Where virtualization technologies are used, examine the system configurations to verify that system functions requiring different security levels are managed in one of the following ways: • Functions with differing security needs do not co-exist on the same system component. • Functions with differing security needs that exist on the same system component are isolated from each other. • Functions with differing security needs on the same system component are all secured to the level required by the function with the highest security need. |
Three alternatives, and only one has to be true: one primary function per component, or isolation between functions of differing security levels, or everything secured to the level of the most demanding function. That structure is what people miss: the control is often read as "one function per server", which is only the first option. Its consequence is the one worth planning around: the third option means a low-sensitivity function sharing a machine with a payment function inherits every requirement that payment function carries.
What to prepare
- A component inventory naming the primary functions on each, and which of the three options applies.
- Evidence of the isolation where option two is claimed: virtualisation, containers with separated privileges, or separate address spaces.
- The hardening applied where option three is claimed, showing it is at the highest level present.
How to implement it
1. Decide the option per component and record it. An assessor tests whichever you claim, and claiming nothing means claiming the first, which is the hardest to be true.
2. Watch what accumulates. Machines rarely start with mixed functions; a monitoring agent, a build runner or a support tool arrives later. The inventory is what makes that visible.
3. Remember containers share a kernel. They are acceptable isolation for many purposes, but the claim needs to be made deliberately, with the privilege separation described, rather than assumed from the word "container".
4. Prefer separation to levelling up. Option three is legitimate and expensive: it drags every requirement of the highest function across everything else on the box.
Where this commonly fails
- Reading the control as "one function per system" and treating a shared machine as an automatic finding, when isolation or levelling up are equally valid.
- Claiming isolation without being able to describe the mechanism.
- A general-purpose management or monitoring agent on a payment system, unconsidered.
- Option three claimed and only partly delivered, so the lower-sensitivity function is hardened less than the highest need.
Related controls
Others in section 2.2:
| Control | What it requires |
|---|---|
| 2.2.1 | Configuration standards are developed, implemented, and maintained… |
| 2.2.2 | Vendor default accounts… |
| 2.2.4 | Only necessary services, protocols, daemons, and functions are enabled… |
| 2.2.5 | If any insecure services, protocols, or daemons are present… |
| 2.2.6 | System security parameters are configured to prevent misuse |
| 2.2.7 | All non-console administrative access is encrypted using strong cryptography |
← 2.2.2 · All controls · 2.2.4 →
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.