Skip to main content
Commerce Security Authority
Category: PCI DSS Compliance

System Components

Also known as: System Component, In-Scope System Components
Simply put

System components are the individual technology building blocks that make up a computer system, such as hardware, software, and firmware. In a payment security context, this term is used to describe the pieces of an environment that may need to be assessed for compliance. Which specific components are considered part of a payment environment depends on how the environment is designed and connected.

Formal definition

A system component is a discrete, identifiable information technology asset that serves as a building block of a system and may include hardware, software, and firmware (per NIST's general definition). Within PCI DSS, the term is applied to the network devices, servers, computing devices, virtualization components, and applications that are included in or connected to the cardholder data environment, and it is central to scoping decisions; the specific inclusion or exclusion of any component depends on its role in storing, processing, or transmitting cardholder data or otherwise affecting the security of that data. Practitioners should note that the evidence provided here supplies only a general IT definition of the term, so the precise PCI DSS treatment, categorization, and applicable requirements should be confirmed against the current published PCI DSS standard, since requirement wording and scoping guidance differ between versions.

Why it matters

The concept of system components sits at the heart of PCI DSS scoping, because the components that store, process, or transmit cardholder data — or that can otherwise affect the security of that data — are the ones subject to assessment. Getting this identification right determines the boundary of the cardholder data environment and, by extension, which controls apply and where. An overly narrow view can leave connected or security-affecting components unassessed and exposed, while an overly broad view can burden an assessment with assets that add little to the actual risk picture.

Because a system component may be hardware, software, or firmware, the term spans a wide range of assets — network devices, servers, computing devices, virtualization components, and applications — and each must be evaluated for its role in the environment. The correct treatment of any given component is not fixed by its label but by how it is designed, deployed, and connected. This is why scoping is a deliberate exercise rather than an inventory formality: two organizations running similar technology can arrive at very different in-scope sets depending on segmentation and connectivity.

Practitioners should be careful to confirm the precise PCI DSS treatment, categorization, and applicable requirements against the current published standard, since requirement wording and scoping guidance differ between versions. The evidence available here provides a general IT definition of the term rather than a version-specific PCI DSS rule, so any specific requirement mapping should be validated rather than assumed.

Who it's relevant to

Compliance officers and QSAs
Those responsible for defining and validating PCI DSS scope depend on an accurate identification of system components to draw the assessment boundary. Determining which network devices, servers, computing devices, virtualization components, and applications are in scope shapes the entire compliance effort, and categorization should be confirmed against the current published standard.
Security engineers and architects
Teams that design and connect environments influence which components fall in scope through segmentation and connectivity decisions. Because inclusion depends on a component's role in storing, processing, or transmitting cardholder data — or affecting its security — architecture choices directly affect the assessable footprint.
Merchant risk and payment operations teams
Organizations building or maintaining payment environments need to understand that a system component may be hardware, software, or firmware, and that the in-scope set reflects how their specific environment is designed rather than a fixed list. This informs planning for assessments and ongoing control maintenance.

Inside System Components

Network components
Devices that transmit, route, or segment traffic, such as firewalls, switches, routers, wireless access points, network appliances, and other security devices. When these carry or could affect cardholder data or sensitive authentication data, they typically fall within the scope of PCI DSS.
Servers
Systems providing services within the environment, which may include web, application, database, authentication, mail, proxy, Network Time Protocol (NTP), and Domain Name System (DNS) servers. Their inclusion in scope depends on whether they store, process, or transmit account data or can affect the security of the cardholder data environment (CDE).
Applications
All purchased and custom software, including internal and external (for example, internet-facing) applications, that interact with account data or the CDE. The security of payment applications may also be addressed by separate standards such as PA-DSS or the PCI Software Security Framework, which are distinct from PCI DSS.
Virtualization and cloud components
Virtual machines, hypervisors, virtual switches and routers, virtual appliances, and cloud-based infrastructure that support or connect to the CDE. These are treated as system components and are assessed based on their role and connectivity relative to account data.
Endpoints and other devices
Workstations, terminals, point-of-interaction (POI) devices, and similar components that connect to or could affect the CDE. Note that PIN entry devices and related controls may also be governed by separate standards such as PCI PIN and PCI P2PE.
Connected-to and security-impacting systems
Systems that are not in the CDE itself but connect to it or could affect its security, such as administrative or management systems, name resolution, and authentication services. These are commonly considered in scope because a compromise could impact the security of account data.

Common questions

Answers to the questions practitioners most commonly ask about System Components.

Does 'system components' only mean the servers and databases that store cardholder data?
No. This is a common misconception. System components include far more than data stores. The term covers any network component, server, or application included in or connected to the cardholder data environment, as well as systems that could affect the security of that environment. This can include systems that provide security services, segmentation, or supporting functions, even when they never directly store, process, or transmit cardholder data. Confirm the specific definition against the current published PCI DSS, as wording is refined between versions.
If a system only touches sensitive authentication data during authorization and never stores it, is it excluded from being a system component?
No. Whether a system stores, processes, or transmits cardholder data or sensitive authentication data, it can be a system component in scope. Sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs or PIN blocks must not be retained after authorization, even encrypted, but systems that process or transmit that data during authorization are still relevant to scope. Absence of storage does not by itself remove a system from consideration; scope depends on the system's role and connectivity, validated against the current standard.
How do I determine which systems in my environment qualify as system components?
Start by identifying every system that stores, processes, or transmits cardholder data or sensitive authentication data, then trace connectivity and dependencies to find systems that could affect the security of that environment, including security, segmentation, and supporting systems. Document data flows and network paths, and validate the boundary through testing rather than assumption. The determination is implementation-specific and should be confirmed against the definitions and requirements in the current published PCI DSS version.
Can network segmentation reduce the number of system components in scope?
Segmentation is intended to isolate the cardholder data environment from other networks so that out-of-scope systems cannot affect the security of in-scope systems. When implemented and validated effectively, it may reduce the set of systems considered system components for the assessment. However, its scope-reducing effect depends on the implementation and on validation, not on the label alone. Segmentation that is misconfigured or unverified may not achieve the intended isolation, so its effectiveness should be tested.
Do connected security tools, such as logging or authentication servers, count as system components?
Systems that provide security services to the cardholder data environment, or that are connected to it, can be system components because they may affect the security of that environment. Examples often discussed include authentication, logging, monitoring, and administrative access systems. Their inclusion depends on their role and connectivity within your specific architecture. Confirm treatment against the current published standard and the assessor's scoping determination.
How does classifying a system as a system component affect the controls I must apply to it?
Once a system is identified as an in-scope system component, applicable PCI DSS requirements are expected to apply to it, subject to the system's function and the wording of the current standard. Requirement numbering and applicability differ between versions, so map controls to systems using the current published PCI DSS rather than assuming fixed requirement numbers. Some controls will apply broadly across components, while others depend on the specific role a component plays.

Common misconceptions

Only systems that directly store the primary account number (PAN) are system components in scope.
System components include devices and software that store, process, or transmit account data, as well as systems that are connected to or could affect the security of the cardholder data environment. Scope is determined by role and connectivity, not solely by whether a system holds the PAN. Note that sensitive authentication data (such as full track data, CAV2/CVC2/CVV2/CID, and PINs/PIN blocks) must not be stored after authorization even when encrypted, while some cardholder data may be stored under defined controls.
Encrypting or tokenizing account data automatically removes a system component from scope.
Encryption, tokenization, truncation, masking, and hashing transform or reduce data differently, and their effect on scope depends on implementation and validation rather than the label alone. A system may remain in scope if it can access the data or the means to recover it, or if it can affect the security of the CDE. Scope reduction should be confirmed through proper validation.
Requirements applying to system components are fixed and identical across all versions of the standard.
Requirement numbering and wording differ between versions of PCI DSS. Practitioners should confirm the applicable requirements against the current published standard rather than assuming a fixed requirement number, and should not conflate PCI DSS with separate standards such as PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, or PCI 3DS.

Best practices

Maintain a current, complete inventory of system components, including network devices, servers, applications, virtual and cloud components, and endpoints, and document each component's role relative to account data.
Classify components by whether they store, process, or transmit account data, or are connected to or could affect the security of the CDE, and reassess scope when the environment changes.
Use network segmentation to help reduce the number of in-scope system components, and validate that segmentation controls are effective rather than assuming they isolate the CDE.
Verify that sensitive authentication data is not retained on any system component after authorization, even in encrypted form, and confirm that stored cardholder data is protected under defined controls.
When relying on tokenization, encryption, truncation, masking, or hashing to reduce scope, validate the implementation and confirm which components can access or recover the underlying data rather than relying on the label.
Confirm applicable controls and requirement wording against the current published version of the standard, and identify when a component is governed by a separate standard such as PCI PIN, PCI P2PE, or the PCI Software Security Framework.