	PCI DSS v3.2.1	PCI DSS v4.0
Requirement and Testing Procedures	Section 2.1: Changing Defaults and Removing Unnecessary Accounts Before installing a system on the network, it’s crucial to change all vendor-supplied defaults and disable or remove any unnecessary default accounts. This applies to all default passwords, including those used by operating systems, security software, application and system accounts, point-of-sale (POS) terminals, payment applications, and Simple Network Management Protocol (SNMP) community strings, among others. • 2.1.a: Select a sample of system components. With the assistance of a system administrator, try to log into the devices and applications using the default vendor-supplied accounts and passwords. The goal is to confirm that all default passwords have been changed. This includes passwords on operating systems, security software, application and system accounts, POS terminals, and SNMP community strings. Vendor manuals and online sources can be used to find vendor-supplied accounts and passwords. •2.1.b: For the chosen sample of system components, verify that all unnecessary default accounts have been removed or disabled. This includes accounts used by operating systems, security software, applications, systems, POS terminals, SNMP, and so on. • 2.1.c: Conduct interviews with personnel and review supporting documentation to confirm the following: - All vendor defaults, including default passwords on operating systems, security software, application and system accounts, POS terminals, SNMP community strings, and so on, are changed before a system is installed on the network. - Unnecessary default accounts, including those used by operating systems, security software, applications, systems, POS terminals, SNMP, and so on, are removed or disabled before a system is installed on the network.	Section 2.2.2: Management of Vendor Default Accounts Vendor default accounts are managed in the following ways: - If the vendor default account(s) will be used, the default password is changed as per Requirement 8.3.6. - If the vendor default account(s) will not be used, the account is removed or disabled. • 2.2.2.a: Review the system configuration standards to ensure they include the management of vendor default accounts in accordance with all elements specified in this requirement. • 2.2.2.b: Examine the vendor documentation and observe a system administrator logging on using vendor default accounts. This is to verify that accounts are implemented in accordance with all elements specified in this requirement. • 2.2.2.c: Review the configuration files and conduct interviews with personnel to confirm that all vendor default accounts that will not be used are removed or disabled.
Requirement and Testing Procedures	2.2.1 The principle here is to assign only a single primary function to each server. This is done to avoid the coexistence of functions that demand different security levels on the same server. For instance, web servers, database servers, and DNS should each be implemented on their own separate servers. • 2.2.1.a Choose a sample of system components. Then, examine the configurations of these systems to confirm that each server is dedicated to just one primary function. • 2.2.1.b In cases where virtualization technologies are employed, scrutinize the configurations of the system to ensure that each virtual system component or device is assigned only one primary function. This ensures that even in a virtualized environment, each function is isolated in its own virtual system component or device.	2.2.3 The management of primary functions that require different security levels is handled in one of the following ways: - A system component contains only a single primary function, OR, - If primary functions with varying security levels exist on the same system component, they are isolated from each other, OR, - If primary functions with varying security levels exist on the same system component, they are all secured to the level required by the function with the highest security need. • 2.2.3.a Inspect the standards for system configuration to confirm that they include the management of primary functions that require different security levels, as specified in this requirement. • 2.2.3.b Examine the configurations of the system to verify that primary functions requiring different security levels are managed in one of the ways specified in this requirement. • 2.2.3.c If virtualization technologies are in use, review the configurations of the system to ensure that system functions requiring different security levels are managed in one of the following ways: o Functions with differing security needs do not coexist on the same system component. o Functions with differing security needs that exist on the same system component are isolated from each other. o 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.
Requirement and Testing Procedures	2.2.2 The guideline here is to activate only those services, protocols, daemons, etc., that are essential for the system’s function. • 2.2.2.a Choose a sample of system components. Inspect the enabled system services, daemons, and protocols on these components to ensure that only necessary services or protocols are activated. • 2.2.2.b Identify any insecure services, daemons, or protocols that are enabled. Interview relevant personnel to confirm that these are justified as per the documented configuration standards. 2.2.5 The directive is to eliminate all superfluous functionality, such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers. • 2.2.5.a Select a sample of system components. Inspect their configurations to ensure that all unnecessary functionality, such as scripts, drivers, features, subsystems, file systems, etc., has been removed. • 2.2.5.b Review the documentation and security parameters to confirm that the enabled functions are documented and support a secure configuration. • 2.2.5.c Examine the documentation and security parameters to ensure that only the functionality documented is present on the sampled system components. This helps maintain a clean and secure system environment.	2.2.4 Ensure only essential services, protocols, daemons, and functions are active, and disable or remove all non-essential ones. • 2.2.4.a Check system configuration standards to confirm that necessary services, protocols, and daemons are identified and recorded. • 2.2.4.b Review system configurations to ensure: - All non-essential functionality is disabled or removed. - Only the functionality required and documented in the configuration standards is active.
Requirement and Testing Procedures	2.2.3 Enforce the application of extra security measures for any necessary services, protocols, or daemons that are deemed to be insecure. • Carry out an inspection of the configuration settings to ensure that security features have been properly documented and implemented for all services, daemons, or protocols that are identified as insecure.	2.2.5 In the event of any insecure services, protocols, or daemons being present: - A business justification is documented. - Additional security measures are documented and put into effect that mitigate the risk of using insecure services, protocols, or daemons. • 2.2.5.a If any insecure services, protocols, or daemons are present, review the system configuration standards and conduct interviews with personnel to ensure they are managed and implemented in line with all the elements specified in this requirement. • 2.2.5.b If any insecure services, protocols, or daemons are present, inspect the configuration settings to confirm that additional security measures are in place to reduce the risk of using insecure services, daemons, and protocols.
Requirement and Testing Procedures	2.1.1 For wireless environments that are connected to the cardholder data environment or that transmit cardholder data, ensure that ALL wireless vendor defaults are altered at the time of installation. This includes, but is not limited to, default wireless encryption keys, passwords, and SNMP community strings. • 2.1.1.a Conduct interviews with the responsible personnel and review the supporting documentation to confirm that: -> The encryption keys were altered from their default settings at the time of installation. -> The encryption keys are changed whenever anyone with knowledge of the keys leaves the company or changes their position. • 2.1.1.b Interview the personnel and review the policies and procedures to confirm that: -> The default SNMP community strings are required to be changed upon installation. -> The default passwords/passphrases on access points are required to be changed upon installation. • 2.1.1.c Review the vendor documentation and log into the wireless devices, with the assistance of the system administrator, to confirm that: -> The default SNMP community strings are not in use. -> The default passwords/passphrases on access points are not in use. • 2.1.1.d Review the vendor documentation and observe the wireless configuration settings to confirm that the firmware on wireless devices is updated to support strong encryption for: -> Authentication over wireless networks. -> Transmission over wireless networks. • 2.1.1.e Review the vendor documentation and observe the wireless configuration settings to confirm that other security-related wireless vendor defaults were changed, if applicable.	2.3.1 For wireless environments that are connected to the CDE or that transmit account data, ensure that all wireless vendor defaults are either altered at the time of installation or confirmed to be secure. This includes, but is not limited to: -> Default wireless encryption keys. -> Passwords on wireless access points. -> SNMP defaults. -> Any other security-related wireless vendor defaults. • 2.3.1.a Review the policies and procedures and conduct interviews with responsible personnel to confirm that processes are in place to either change wireless vendor defaults upon installation or to confirm them to be secure, in accordance with all elements of this requirement. • 2.3.1.b Review the vendor documentation and observe a system administrator logging into wireless devices to confirm that: -> SNMP defaults are not in use. -> Default passwords/passphrases on wireless access points are not in use. • 2.3.1.c Review the vendor documentation and wireless configuration settings to confirm that other security-related wireless vendor defaults were changed, if applicable. 2.3.2 For wireless environments that are connected to the CDE or that transmit account data, ensure that wireless encryption keys are changed under the following circumstances: -> Whenever personnel with knowledge of the key leave the company or change roles. -> Whenever a key is suspected of or known to be compromised. • Conduct interviews with responsible personnel and review the key-management documentation to confirm that wireless encryption keys are changed in accordance with all elements specified in this requirement.
Requirement and Testing Procedures	2.4 Ensure the maintenance of an inventory of system components that fall within the scope of PCI DSS. • 2.4.a Conduct a review of the system inventory to confirm that a list of hardware and software components is maintained and that it includes a description of the function or use for each component. • 2.4.b Carry out interviews with personnel to confirm that the documented inventory is regularly updated and kept current.	12.5.1 Maintain an inventory of system components that are within the scope for PCI DSS, ensuring it includes a description of function or use and is regularly updated. • 12.5.1.a Review the inventory to confirm that it includes all system components within the scope of PCI DSS and a description of the function or use for each component. • 12.5.1.b Conduct interviews with personnel to confirm that the inventory is regularly updated and kept current.

PCI DSS v3.2.1	PCI DSS v4.0	Specification of Requirements
	5.1.2 The tasks and duties associated with Requirement 5 are clearly defined, allocated, and comprehended. -> 5.1.2.a Review the written records to confirm that the roles and duties associated with Requirement 5 are clearly defined and allocated. -> 5.1.2.b Conduct interviews with staff responsible for Requirement 5 to ensure that the roles and duties are allocated as per the documentation and are comprehended.	An updated mandate for roles and responsibilities has been introduced. This mandate is to be implemented with immediate effect for all v4.0 evaluations.
5.1.2 For systems that are typically not susceptible to malicious software, carry out regular assessments to detect and assess emerging malware threats. This is to ascertain whether these systems continue to not necessitate anti-virus software. Conduct discussions with staff to ensure that they are monitoring and assessing emerging malware threats for systems that are generally not prone to malicious software. This is to confirm whether these systems persist in not needing anti-virus software.	5.2.3 System components that are not susceptible to malware undergo regular evaluations, which include the following: -> A documented inventory of all system components that are not susceptible to malware. -> Identification and assessment of emerging malware threats for these system components. -> Verification whether these system components continue to not need anti-malware protection. 5.2.3.a Review documented policies and procedures to confirm that a process is established for regular evaluations of any system components that are not susceptible to malware, encompassing all elements specified in this requirement. 5.2.3.b Conduct discussions with staff to confirm that the evaluations encompass all elements specified in this requirement. 5.2.3.c Review the list of system components identified as not susceptible to malware and compare it with the system components without an anti-malware solution deployed as per Requirement 5.2.1 to confirm that the system components align for both requirements.	Refined the requirement by shifting the emphasis to ‘system components that are not susceptible to malware.
	New Requirement in PCI DSS v4.0: 5.2.3.1 The regularity of evaluations for system components deemed not susceptible to malware is determined by the entity’s focused risk analysis, which is conducted in line with all elements outlined in Requirement 12.3.1. -> 5.2.3.1.a Review the entity’s focused risk analysis for the regularity of evaluations of system components deemed not susceptible to malware to confirm that the risk analysis was conducted in line with all elements outlined in Requirement 12.3.1. -> 5.2.3.1.b Review the documented outcomes of regular evaluations of system components deemed not susceptible to malware and conduct discussions with staff to confirm that evaluations are conducted at the regularity defined in the entity’s focused risk analysis performed for this requirement.	New stipulation to establish the regularity of evaluations for system components not susceptible to malware in the entity’s focused risk analysis. This stipulation is considered a best practice until March 31, 2025.
5.2 Ensure that all anti-virus mechanisms are upheld as follows: -> They are kept up to date, -> They carry out regular scans -> They produce audit logs which are preserved as per PCI DSS Requirement 10.7. 5.2.a Review policies and procedures to confirm that it is mandatory for anti-virus software and definitions to be kept current. 5.2.b Inspect anti-virus configurations, including the primary installation of the software to confirm that anti-virus mechanisms are: -> Set up to perform automatic updates, and -> Configured to carry out regular scans. 5.2.c Review a selection of system components, including all operating system types typically affected by malicious software, to confirm that: The anti-virus software and definitions are up-to-date. Regular scans are carried out. 5.2.d Inspect anti-virus configurations, including the primary installation of the software and a selection of system components, to confirm that: -> Anti-virus software log generation is activated, and -> Logs are preserved in line with PCI DSS Requirement 10.7.	5.3.1 The anti-malware solution(s) is consistently updated through automatic updates. 5.3.1.a Inspect the configurations of the anti-malware solution(s), including any primary installation of the software, to confirm the solution is set up to carry out automatic updates. 5.3.1.b Review system components and logs, to verify that the anti-malware solution(s) and definitions are up-to-date and have been deployed promptly. 5.3.2 The anti-malware solution(s): -> Conducts regular scans and active or real-time scans. OR -> Carries out continuous behavioral analysis of systems or processes. 5.3.2.a Review the configurations of the anti-malware solution(s), including any primary installation of the software, to confirm the solution(s) is set up to perform at least one of the elements specified in this requirement. 5.3.2.b Inspect system components, including all operating system types identified as susceptible to malware, to confirm the solution(s) is activated in line with at least one of the elements specified in this requirement. 5.3.2.c Review logs and scan results to confirm that the solution(s) is activated in line with at least one of the elements specified in this requirement. 5.3.4 Audit logs for the anti-malware solution(s) are activated and preserved in line with Requirement 10.5.1. Inspect the configurations of the anti-malware solution(s) to confirm logs are activated and preserved in line with Requirement 10.5.1.	Divided a single requirement into three distinct parts, each focusing on a specific area: -> Ensuring the malware solution is consistently updated through automatic updates, -> Conducting regular scans and active or real-time scans (with an added alternative for continuous behavioral analysis), -> Producing audit logs by the malware solution.
	New Requirement in PCI DSS v4.0: 5.3.2.1 If regular malware scans are conducted to fulfill Requirement 5.3.2, the regularity of scans is determined in the entity’s focused risk analysis, which is carried out in line with all elements outlined in Requirement 12.3.1. -> 5.3.2.1.a Review the entity’s focused risk analysis for the regularity of regular malware scans to confirm that the risk analysis was conducted in line with all elements outlined in Requirement 12.3.1. -> 5.3.2.1.b Inspect the documented outcomes of regular malware scans and conduct discussions with staff to confirm that scans are carried out at the regularity defined in the entity’s focused risk analysis performed for this requirement.	New requirement to establish the regularity of regular malware scans in the entity’s focused risk analysis. This stipulation is considered a best practice until March 31, 2025.
	New Requirement in PCI DSS v4.0: 5.4.1 Procedures and automated systems are established to identify and safeguard staff from phishing attacks. -> Inspect the implemented procedures and scrutinize the systems to confirm that controls are established to identify and safeguard staff from phishing attacks.	New requirement to identify and safeguard staff from phishing attacks. This stipulation is considered a best practice until March 31, 2025.
	New Requirement in PCI DSS v4.0: 5.3.3 For detachable electronic media, the anti-malware solution(s): -> Conducts automatic scans when the media is inserted, connected, or logically mounted, OR -> Carries out continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted. 5.3.3.a Review the configurations of the anti-malware solution(s) to confirm that, for detachable electronic media, the solution is set up to perform at least one of the elements outlined in this requirement. 5.3.3.b Inspect system components with detachable electronic media connected to confirm that the solution(s) is activated in line with at least one of the elements as outlined in this requirement. 5.3.3.c Review logs and scan results to confirm that the solution(s) is activated in line with at least one of the elements outlined in this requirement.	New requirement for an anti-malware solution for detachable electronic media. This stipulation is considered a best practice until March 31, 2025.

Compliance & Governance

Turnkey Solutions

Technical Assessment

IT Audit & Advisory

Regulatory Compliance

IT Audit & Advisory

Compliance & Governance

Turnkey Solutions

Technical Assessment

IT Audit & Advisory

Regulatory Compliance

IT Audit & Advisory

Guide on Cybersecurity Maturity Model Certification (CMMC 2.0)

What is CMMC Compliance?

What is CMMC 2.0?

CMMC 2.0 vs CMMC 1.0

Who needs to be CMMC Certified?

CMMC 2.0 Model

CMMC 2.0 Model In a Glance

3 Levels of CMMC 2.0

Foundational Level 1

Advanced Level 2

Expert Level 3

NIST 800-171 14 Domains Covered in CMMC 2.0

Getting Started with CMMC Compliance

Services

About Us

CONTACT US

Contact Us