BLOG HOME > PCI > Performing an SAQ C version 4.0 Merchant Self-Assessment

Performing an SAQ C version 4.0 Merchant Self-Assessment


Get Started with PCI Compliance

Start Here

The Payment Card Industry Data Security Standard (PCI DSS) includes a list of security requirements designed to protect cardholder data transmitted or stored in a merchant environment. The Self-Assessment Questionnaires (SAQs) were created to simplify PCI DSS compliance for small merchants. Each SAQ is designed for a specific type of payment environment and includes a mix of controls specifically suited for that specific environment.  Small merchants who support card-present payments using traditional Point-of-Sale deployments configured not to store cardholder data may find they meet all of the eligibility criteria (see Part 2h of the SAQ C) for validating their PCI DSS compliance using this simplified form. 

Merchants using the SAQ C to validate their PCI DSS compliance should be aware of changes that were introduced into this questionnaire during the publication of the SAQ C version 4.0. In this blog we will review these newly added requirements to the SAQ C. 

New Future-Dated Requirements

Future-dated requirements added to PCI DSS version 4.0 are considered best practice until March 31, 2025. Entities are not required to validate compliance to these requirements until that date. 

Depending upon the size and complexity of your environment, it may take considerable effort to implement some of these new requirements. It is recommended that SAQ C Merchants begin now to plan for the implementation of the following new requirements:

4.2.1 Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. 

While some elements of Requirement 4.2.1 are not new to the SAQ C, the requirement to ensure certificates used to protect cardholder data during transmission are not expired or revoked has been newly added and merchants will need to have a process in place to address this requirement prior to 3/31/2025. The frequency of periodic evaluations of system components identified as not at risk for malware is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1.

The overall risk assessment required by PCI DSS v3.2.1 has been replaced with targeted risk assessments. For Requirement, merchants who have identified systems in their CDE as not being commonly affected by malware must perform a targeted risk assessment to define the frequency at which the merchant will reassess the finding of non-applicability for malware protection. This is considered a best practice until 3/31/2025. If periodic malware scans are performed to meet Requirement 5.3.2, the frequency of scans is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1. 

If a combination of real-time scanning and periodic malware scans are used to protect CDE systems from the threat of malware (as opposed to performing continuous behavioral analysis of systems or processes), a merchant must perform a targeted risk assessment to determine the frequency of malware scans. This is considered a best practice until 3/31/2025.

5.3.3 For removable electronic media, the anti-malware solution(s):

  • Performs automatic scans of when the media is inserted, connected, or logically mounted,


  • Performs continuous behavioral analysis of systems or processes when the media is inserted, connected, or logically mounted.

Requirement 5.3.3 can be considered an evolving requirement for malware prevention. Malware protection in place in the environment should be configured to either automatically scan removable electronic media (USB drives, external hard drives, SSD memory cards, etc.) when mounted or the malware solution should be continuously performing behavioral analysis to provide automatic malware protection for these connected media types. This is considered a best practice until 3/31/2025.

5.4.1 Processes and automated mechanisms are in place to detect and protect personnel against phishing attacks.

Phishing attacks are becoming more prevalent and more sophisticated in recent years. While employee training is critical to preventing successful phishing attacks from negatively affecting the security of a merchant’s environment, technical controls should be added to provide more layers of protection against these attacks. For requirement 5.4.1, it is recommended that merchants implement a combination of approaches to prevent spoofing attacks. Anti-fishing tactics include anti-spoofing technologies (domain-based message authentication, domain keys identified mail, and sender policy framework) and phishing email blocking or link scrubbing technologies. 

This is considered a best practice until 3/31/2025.

7.2.4 All user accounts and related access privileges, including third-party/vendor accounts, are reviewed as follows:

  • At least once every six months.

  • To ensure user accounts and access remain appropriate based on job function.

  • Any inappropriate access is addressed.

  • Management acknowledges that access remains appropriate. 

In order to show evidence of compliance for this requirement you will want to show that a bi-annual user account and access privileges review happens and has management acknowledgement or signoff. It may work well to pair this up with a bi-annual firewall ruleset review or rotate quarterly between a firewall review and a user access privilege review. 

This is considered a best practice until 3/31/2025.

7.2.5 All application and system accounts and related access privileges are assigned and managed as follows:

  • Based on the least privileges necessary for the operability of the system or application.

  • Access is limited to the systems, applications, or processes that specifically require their use.

In order to show evidence of compliance for 7.2.5 you will need to confirm the application and system accounts only have the access and privileges necessary for their function. If you give an account access to more than is needed or privileges more than is used you will run the risk of a compromised application or system account being accessed and doing things they shouldn’t. 

This is considered a best practice until 3/31/2025.

8.3.6 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they meet the following minimum level of complexity:

  • A minimum length of 12 characters (or IF the system does not support 12 characters, a minimum length of eight characters).

  • Contain both numeric and alphabetic characters.

Requirement 8.3.6 is an evolving PCI DSS requirement. In version 3.2.1, passwords were required to be at least 7 characters in length consisting of a mix of numeric and alphabetic characters. Beginning on March 31, 2025, the password length requirement is increased to 12 characters in most instances while the password complexity requirement remains unchanged. 

8.4.2 MFA is implemented for all access into the CDE.

In requirement 8.4.2, multi-factor authentication is required for all access into the CDE. However, this requirement does not apply to application or system accounts performing automated functions or user accounts on POI terminals that have access to only one card number at a time to facilitate a single transaction. MFA is required for both access into the CDE and for remote access originating outside the entity’s network that could access or impact the CDE (requirement 8.4.3).

8.5.1 Multi-factor authentication (MFA) systems are configured to prevent misuse.

Multi-factor authentication solutions need to be implemented securely and cannot be susceptible to replay attacks, user permission bypass (unless authorized and documented), have to use two different types of factors, and success of all authentication factors is required before access is granted.

8.6.1  If accounts used by systems or applications can be used for interactive login, they are managed as follows:

  • Interactive use is prevented unless needed for an exceptional circumstance. 

  • Interactive use is limited to the time needed for the exceptional circumstance.

  • Business justification for interactive use is documented.

  • Interactive use is explicitly approved by management.

  • Individual user identity is confirmed before access to account is granted.

  • Every action taken is attributable to an individual user.

Interactive login is a method of authentication that is typically used by a human user account, and not a system or application account. These accounts often come with local admin privileges and even some domain privileges that could allow these accounts access to other systems. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and all relate to controls for application and system accounts.

8.6.2  Passwords/passphrases for any application and system accounts that can be used for interactive login are not hard coded in scripts, configuration/property files, or bespoke and custom source code.

Interactive login is a method of authentication that is typically used by a human user account, and not a system or application account. If you hard code the authentication credentials or include them in a configuration file or custom source code then anyone who has access to that code or configuration file can then obtain the interactive login credentials and possibly gain local admin privileges and privileges across the domain. Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and all relate to controls for application and system accounts.

8.6.3  Passwords/passphrases for any application and system accounts are protected against misuse as follows:

  • Passwords/passphrases are changed periodically (at the frequency defined in the entity’s targeted risk analysis, which is performed according to all elements specified in Requirement 12.3.1) and upon suspicion or confirmation of compromise. 

  • Passwords/passphrases are constructed with sufficient complexity appropriate for how frequently the entity changes the passwords/passphrases.

It’s common for application and system accounts to be overlooked and forgotten. To show evidence of compliance for this requirement you will need to perform a risk assessment (NIST 800-30 would suffice) and make sure that it includes the risk posed by not changing or infrequently changing an application or system account or not having sufficient complexity for that password. After the risk assessment has been performed you will also need to show the policy created to address the application and system account password risks.  Requirements 8.6.1, 8.6.2, 8.6.3, 7.2.5 and all relate to controls for application and system accounts.  Automated mechanisms are used to perform audit log reviews (at least once daily). The frequency of periodic log reviews for all other system components (not defined in requirement 10.4.1) is defined in the entity’s targeted risk analysis, which is performed according to all elements specified in requirement 12.3.1.

Because of the vast amounts of logging data collected it becomes almost impossible to manually review it and so PCI is requiring you to use an automated solution that scans through the logs and looks for anomalies or issues. To show evidence of compliance for you will need to assess the risk of the frequency in which periodic reviews for all other systems not defined in 10.4.1 are considered, and create a documented policy and procedure to address that risk.

12.3.1  Each PCI DSS requirement that provides flexibility for how frequently it is performed has been included in your documented risk assessment, and should include:

  • Identification of the assets being protected.

  • Identification of the threat(s) that the requirement is protecting against.

  • Identification of factors that contribute to the likelihood and/or impact of a threat being realized.

  • Resulting analysis that determines, and includes justification for, how frequently the requirement must be performed to minimize the likelihood of the threat being realized.

  • Review of each targeted risk analysis at least once every 12 months to determine whether the results are still valid or if an updated risk analysis is needed.

  • Performance of updated risk analysis when needed, as determined by the annual review.

A good way to satisfy this requirement is to do a NIST 800-30 risk assessment and include the threat events posed by the PCI requirements throughout the report, along with a baseline of threat events provided in the NIST 800-30 guidance document and any threat events that have or could occur to your environment based on the people, processes and technologies used. The risk assessment should include a spreadsheet of threat events and their corresponding risk determination. The risk assessment should have management signoff and have CDE-wide (ideally organization-wide) contribution and should be a living document that is periodically updated. Ideally the risk assessment document would be used to justify security control expenditures and to prioritize mitigation and risk-treatment efforts. A rigorous risk assessment and resulting documentation would satisfy the risk aspects of requirements: 1.2.6, 2.2.5, 5.2.3,,, 6.3.1, 6.3.3,, 8.6.3,,, 11.3.1,,, 11.4.1, 11.4.4, 11.6.1, 12.3.1, 12.7.1, 12.8,, A2.1.2, and Appendix B: Compensating Controls Worksheet (4. Identified Risk). Security awareness training includes awareness of threats and vulnerabilities that could impact the security of the CDE, including but not limited to:

  • Phishing and related attacks.

  • Social engineering.

As discussed in requirement 5.4.1 above, companies should be taking a defense-in-depth approach to prevent phishing and other social engineering-related attacks. To be compliant with requirement, a merchant’s security awareness training program needs to include education on how to detect, react to, and report phishing and social engineering attempts. It is also recommended that members of the merchant’s incident response team are made aware of how to properly respond to notifications of these types of attacks against the organization. 

Get Started with PCI Compliance

Start Here

Evolving Existing Requirements

In addition to newly added requirements, several existing PCI DSS requirements were enhanced. These enhanced/evolving requirements include the following:

Requirements 2.1.1, 3.1.1, 5.1.1, 6.1.1, 8.1.1, 9.1.1, 10.1.1 

All security policies and operational procedures for said requirements are:

  • Documented.

  • Kept up to date.

  • In use.

  • Known to all affected parties.

Well-documented security policies and procedures can help merchants maintain a PCI DSS-compliant environment if employees working in the environment are aware of policies and procedures that apply to their job responsibilities. PCI DSS Requirements 1.1.1, 2.1.1, 3.1.1, … 12.1.1  focus on ensuring policies related to these sections are up to date and are distributed to affected parties. 

For example, for Requirement 3, a merchant should have a defined data retention policy that prohibits any electronic storage of cardholder data within the merchant environment and defines data retention and data destruction procedures for any physical media containing cardholder data. 

Requirement 6.2.1 Bespoke and custom software are developed securely, as follows:

  • Based on industry standards and/or best practices for secure development. 

Prior to PCI DSS v4.0, secure software development requirements had not been included in the SAQ C. For Requirement 6.2.1, if a merchant develops software used in their payment environment, a software development life cycle policy based on industry standards and best practices must be in place. Policies and procedures should guide the developers and security engineers in meeting Requirements 6.2.2,, and 6.2.4 discussed below. 

Requirement 6.2.2 Software development personnel working on bespoke and custom software are trained at least once every 12 months as follows: 

  • On software security relevant to their job function and development languages.

  • Including secure software design and secure coding techniques.

  • Including, if security testing tools are used, how to use the tools for detecting vulnerabilities in software. 

Merchants who develop custom or bespoke software in their CDE need to ensure their developers receive training annually. This training should be relevant to their job functions and languages used and include secure code design and coding techniques. Online or in-house training can be used to meet this requirement. If manual code reviews are performed for bespoke and custom software prior to release to production, code changes are:

  • Reviewed by individuals other than the originating code author, and who are knowledgeable about code-review techniques and secure coding practices.

  • Reviewed and approved by management prior to release.

Merchants who develop custom or bespoke software in their CDE must ensure a process is in place to have all code changes reviewed by someone, other than the original author, who is knowledgeable about secure coding principles. It is recommended that review checklists or other tools be used to guide the peer review process to ensure code changes are not introducing new vulnerabilities into the CDE. In addition to performing code reviews, management review and approval prior to deploying code into the production environment must be documented. 

6.2.4 Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software, including but not limited to the following:

  • Injection attacks, including SQL, LDAP, XPath, or other command, parameter, object, fault, or injection-type flaws.

  • Attacks on data and data structures, including attempts to manipulate buffers, pointers, input data, or shared data.

  • Attacks on cryptography usage, including attempts to exploit weak, insecure, or inappropriate cryptographic implementations, algorithms, cipher suites, or modes of operation.

  • Attacks on business logic, including attempts to abuse or bypass application features and functionalities through the manipulation of APIs, communication protocols and channels, client-side functionality, or other system/application functions and resources. This includes cross-site scripting (XSS) and cross-site request forgery (CSRF).

  • Attacks on access control mechanisms, including attempts to bypass or abuse identification, authentication, or authorization mechanisms, or attempts to exploit weaknesses in the implementation of such mechanisms.

  • Attacks via any “high-risk” vulnerabilities identified in the vulnerability identification process, as defined in Requirement 6.3.1. 

It is important that developers understand techniques to prevent common software attacks and vulnerabilities from being introduced into their code base. This begins with ensuring secure coding practices are included in the SDLC and in annual developer training. The peer review process should include steps to look for these common vulnerabilities that may have been inadvertently introduced in code changes. Several code scanning tools are available to search for these common software attacks and can be incorporated in the code review and deployment process. 

6.5.1 Changes to all system components in the production environment are made according to established procedures that include: 

  • Reason for, and description of, the change. 

  • Documentation of security impact. 

  • Documented change approval by authorized parties.

  • Testing to verify that the change does not adversely impact system security.

  • For bespoke and custom software changes, all updates are tested for compliance with Requirement 6.2.4 before being deployed into production.

  • Procedures to address failures and return to a secure state. 

While the SAQ C in version 3.2.1 did require merchants to document significant changes to their CDE to ensure continued compliance with all applicable PCI DSS requirements, in version 4.0 the SAQ C requires merchants to have change management policies and procedures in place to review, approve, and document changes to all system components in the CDE. Change control tickets should capture the reason for the change, the security impact, approval by authorized parties (peer review, management, etc.), security testing performed, and rollback procedures.  

8.2.4 Addition, deletion, and modification of user IDs, authentication factors, and other identifier objects are managed as follows:

  • Authorized with the appropriate approval.

  • Implemented with only the privileges specified on the documented approval.

Note: This requirement applies to all user accounts, including employees, contractors, consultants, temporary workers, and third-party vendors.

To meet this requirement merchants will need to have a documented account provisioning process that would capture authorized approval for any new or modified user account in the cardholder data environment and the privileges associated with the account. 

8.2.5 Access for terminated users is immediately revoked.

If an employee with access to the merchant’s cardholder data environment is terminated or their job role is changed in such a way that access to the CDE is no longer required, their account must be disabled or removed. This should be included as part of the merchants user account provisioning and removal policy mentioned above. 

8.2.6 Inactive user accounts are removed or disabled within 90 days of inactivity.

User accounts in the CDE must be disabled or removed if they are not used for more than 90 days. It is recommended that this be an automated process.

8.3.2 Strong cryptography is used to render all authentication factors unreadable during transmission and storage on all system components.

User authentication credentials used in the CDE must be strongly encrypted or hashed during transmission and storage. Unencrypted remote access methods, like Telnet or HTTP, should not be used when authenticating to systems in the CDE. Strong cryptography or encryption must be in place to protect the passwords during storage. Disabling legacy password hashing protocols like the Windows LAN Manager hash and using NTLMv2 on Windows systems and SHA512 for Linux can help to meet this requirement. 

8.3.3 User identity is verified before modifying any authentication factor.

If a merchant supports a non-face-to-face password reset process, this process must include steps to verify the user’s identity prior to resetting their password.

10.3 Audit logs are protected from destruction and unauthorized modifications.

Audit logs must be protected from unauthorized modification or destruction by ensuring read access is limited to those with a job-related need. Protections are in place to prevent individuals from modifying audit log data. Log files need to be promptly backed up to a secure log server and FIM or file change detection mechanisms need to be in place to ensure that existing log data cannot be modified without generating an alert. 

10.6 Time-synchronization mechanisms support consistent time settings across all systems.

Systems within the CDE need to be configured to synchronize their clocks with one or more designated time servers to ensure time-stamped log data is useful. Only the designated time server should be receiving time information from an external source. Time received from external sources must be based on international atomic time or UTC. If more than one designated time server is in use, these servers must be configured to peer with one another to keep accurate time. 

Access to time configuration on CDE systems must be limited to personnel with a business need. Any changes to time settings on critical systems must be logged, monitored, and reviewed. 

12.10.3 Specific personnel are designated to be available on a 24/7 basis to respond to suspected or confirmed security incidents.

While an incident response plan was required in version 3.2.1, the SAQ C has added the sub requirement that says a merchant must have personnel available 24/7 to respond to suspected or confirmed security incidents. 


Version 3.2.1 of the PCI DSS will be retired on March 31, 2024. After that date, merchants performing self-assessments will be required to use version 4.0 of the Self-Assessment Questionnaires. 

The SAQ C has seen some substantial changes in version 4.0. There are a number of future-dated requirements that merchants will need to address prior to March 31, 2025 and several existing PCI requirements were added to the SAQ C that were not included under v3.2.1. These existing requirements that were newly added to the SAQ C must be in place when performing an SAQ C assessment of the merchant environment. 

Join Thousands of Security Professionals and Subscribe