1. SAQ A (29 Testing Requirements)  The merchant accepts only card-not-present (e-commerce or mail/telephone-order) transactions;  All processing of account data is entirely outsourced to PCI DSS compliant third-party service provider (TPSP)/payment processor;  The merchant does not electronically store, process, or transmit any account data on merchant systems or premises, but relies entirely on a TPSP(s) to handle all these functions;  The merchant has reviewed the PCI DSS Attestation of Compliance form(s) for its TPSP(s) and confirmed that TPSP(s) are PCI DSS compliant for the services being used by the merchant; and  Any account data the merchant might retain is on paper (for example, printed reports or receipts), and these documents are not received electronically. Additionally, for e-commerce channels:  All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor. Note: For this SAQ, PCI DSS Requirements that address the protection of computer systems (for example, Requirements 2, 6, 8, and 11) AND requirements that refer to the “cardholder data environment” apply to the following e-commerce merchants:  Those that redirect customers from their website to a TPSP/payment processor for payment processing, and specifically to the merchant web server upon which the redirection mechanism is located.  Those with a website(s) that includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame), and specifically to the merchant web server that includes the embedded payment page/form. These PCI DSS requirements are applicable because the above merchant websites impact how the account data is transmitted, even though the websites themselves do not receive account data.
   1. Goal 1: Build and Maintain a Secure Network and Systems
      1. Requirement 2: Apply Secure Configurations to All System Components
         1. 2.2 System components are configured and managed securely.
            1. Note: For SAQ A, Requirement 2.2.2 applies to e-commerce merchants’ vendor default accounts on webservers 2.2.2 Vendor default accounts are managed as follows: • If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6. • If the vendor default account(s) will not be used, the account is removed or disabled.
   2. Goal 2: Protect Account Data
      1. Requirement 3: Protect Stored Account Data Note: For SAQ A, Requirement 3 applies only to merchants with paper records that include account data (for example, receipts or printed reports).
         1. 3.1 Processes and mechanisms for protecting stored account data are defined and understood.
            1. All security policies and operational procedures that are identified in Requirement 3 are: • Documented. • Kept up to date. • In use. • Known to all affected parties. SAQ Completion Guidance: Selection of any of the In-Place responses for Requirement 3.1.1 means that, if the merchant has paper storage of account data, the merchant has policies and procedures in place that govern merchant activities for Requirement 3. This helps to ensure personnel are aware of and following security policies and documented operational procedures for managing the secure storage of any paper records with account data. If a merchant does not store paper records with account data, mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.
         2. 3.2 Storage of account data is kept to a minimum.
            1. 3.2.1 Account data storage is kept to a minimum through implementation of data retention and disposal policies, procedures, and processes that include at least the following: • Coverage for all locations of stored account data. • Coverage for any sensitive authentication data (SAD) stored prior to completion of authorization. This bullet is a best practice until its effective date; refer to Applicability Notes below for details. • Limiting data storage amount and retention time to that which is required for legal or regulatory, and/or business requirements. • Specific retention requirements for stored account data that defines length of retention period and includes a documented business justification. • Processes for secure deletion or rendering account data unrecoverable when no longer needed per the retention policy. A process for verifying, at least once every three months, that stored account data exceeding the defined retention period has been securely deleted or rendered unrecoverable. Applicability Notes Where account data is stored by a TPSP (for example, in a cloud environment), entities are responsible for working with their service providers to understand how the TPSP meets this requirement for the entity. Considerations include ensuring that all geographic instances of a data element are securely deleted. The bullet above (for coverage of SAD stored prior to completion of authorization) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.2.1 and must be fully considered during a PCI DSS assessment. SAQ Completion Guidance: Selection of any of the In Place responses for Requirement 3.2.1 means that if a merchant stores any paper (for example, receipts or paper reports) that contain account data, the merchant only stores the paper as long as it is needed for business, legal, and/or regulatory reasons and destroys the paper once it is no longer needed. If a merchant never prints or stores any paper containing account data, mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.
   3. Goal 3: Maintain a Vulnerability Management Program
      1. Requirement 6: Develop and Maintain Secure Systems and Software Note: For SAQ A, Requirement 6 applies to webservers that host the page(s) on the merchant’s website(s) that provide the address (the URL) of the TPSP’s payment page/form to the merchant’s customers.
         1. 6.3 Security vulnerabilities are identified and addressed.
            1. 6.3.1 Security vulnerabilities are identified and managed as follows: • New security vulnerabilities are identified using industry-recognized sources for security vulnerability information, including alerts from international and national computer emergency response teams (CERTs). • Vulnerabilities are assigned a risk ranking based on industry best practices and consideration of potential impact. • Risk rankings identify, at a minimum, all vulnerabilities considered to be a high-risk or critical to the environment. • Bullet intentionally left blank for this SAQ. Applicability Notes This requirement is not achieved by, nor is it the same as, vulnerability scans performed for Requirements 11.3.1 and 11.3.2. This requirement is for a process to actively monitor industry sources for vulnerability information and for the entity to determine the risk ranking to be associated with each vulnerability.
            2. All system components are protected from known vulnerabilities by installing applicable security patches/updates as follows: • Critical or high-security patches/updates are installed within one month of release. • Bullet intentionally left blank for this SAQ
         2. 6.4 Public-facing web applications are protected against attacks
            1. 6.4.3 All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows: • A method is implemented to confirm that each script is authorized. • A method is implemented to assure the integrity of each script. • An inventory of all scripts is maintained with written justification as to why each is necessary. Note: For SAQ A, Requirement 6.4.3 applies to a merchant’s website(s) that includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame). Applicability Notes This requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
   4. Goal 4: Implement Strong Access Control Measures
      1. Requirement 8: Identify Users and Authenticate Access to System Components Note: For SAQ A, Requirement 8 applies to merchant web servers that host the page(s) that either 1) redirects customers from the merchant website to a TPSP/payment processor for payment processing (for example, with a URL redirect) or 2) includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame).
         1. 8.2 User identification and related accounts for users and administrators are strictly managed throughout an account’s lifecycle.
            1. 8.2.1 All users are assigned a unique ID before access to system components or cardholder data is allowed.
            2. 8.2.2 Group, shared, or generic accounts, or other shared authentication credentials are only used when necessary on an exception basis, and are managed as follows: • Account use is prevented unless needed for an exceptional circumstance. • Use is limited to the time needed for the exceptional circumstance. • Business justification for use is documented. • Use is explicitly approved by management. • Individual user identity is confirmed before access to an account is granted. • Every action taken is attributable to an individual user.
            3. 8.2.5 Access for terminated users is immediately revoked.
         2. 8.3 Strong authentication for users and administrators is established and managed.
            1. 8.3.1 All user access to system components for users and administrators is authenticated via at least one of the following authentication factors: • Something you know, such as a password or passphrase. • Something you have, such as a token device or smart card. • Something you are, such as a biometric element. This requirement does not supersede multi-factor authentication (MFA) requirements but applies to those in-scope systems not otherwise subject to MFA requirements. A digital certificate is a valid option for “something you have” if it is unique for a particular user.
            2. 8.3.5 If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are set and reset for each user as follows: • Set to a unique value for first-time use and upon reset. • Forced to be changed immediately after the first use.
            3. 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. Applicability Notes This requirement is not intended to apply to: • User accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). • Application or system accounts, which are governed by requirements in section 8.6. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment. Until 31 March 2025, passwords must be a minimum length of seven characters in accordance with PCI DSS v3.2.1 Requirement 8.2.3.
            4. 8.3.7 Individuals are not allowed to submit a new password/passphrase that is the same as any of the last four passwords/passphrases used. Applicability Notes This requirement is not intended to apply to user accounts within point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals).
            5. 8.3.9 If passwords/passphrases are used as the only authentication factor for user access (i.e., in any singlefactor authentication implementation) then either: • Passwords/passphrases are changed at least once every 90 days, OR • The security posture of accounts is dynamically analyzed, and real-time access to resources is automatically determined accordingly. Applicability Notes This requirement applies to in-scope system components that are not in the CDE because these components are not subject to MFA requirements. This requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction (such as IDs used by cashiers on point-of-sale terminals). This requirement does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel.
      2. Requirement 9: Restrict Physical Access to Cardholder Data
         1. 9.4 Media with cardholder data is securely stored, accessed, distributed, and destroyed. Note: For SAQ A, Requirements at 9.4 only apply to merchants with paper records (for example, receipts or printed reports) with account data, including primary account numbers (PANs). AQ Completion Guidance: Selection of any of the In Place responses for Requirements at 9.4 means that the merchant securely stores any paper media with account data, for example by storing the paper in a locked drawer, cabinet, or safe, and that the merchant destroys such paper when no longer needed for business purposes. This includes a written document or policy for employees, so they know how to secure paper with account data and how to destroy the paper when no longer needed. If the merchant never stores any paper with account data, mark this requirement as Not Applicable and complete Appendix C: Explanation of Requirements Noted as Not Applicable.
            1. 9.4.1 All media with cardholder data is physically secured.
            2. 9.4.1.1 Offline media backups with cardholder data are stored in a secure location.
            3. 9.4.2 All media with cardholder data is classified in accordance with the sensitivity of the data.
            4. 9.4.3 Media with cardholder data sent outside the facility is secured as follows: • Bullet intentionally left blank for this SAQ. • Media is sent by secured courier or other delivery method that can be accurately tracked. • Bullet intentionally left blank for this SAQ.
            5. 9.4.4 Management approves all media with cardholder data that is moved outside the facility (including when media is distributed to individuals). Applicability Notes Individuals approving media movements should have the appropriate level of management authority to grant this approval. However, it is not specifically required that such individuals have “manager” as part of their title.
            6. 9.4.6 Hard-copy materials with cardholder data are destroyed when no longer needed for business or legal reasons, as follows: • Materials are cross-cut shredded, incinerated, or pulped so that cardholder data cannot be reconstructed. • Materials are stored in secure storage containers prior to destruction. Applicability Notes These requirements for media destruction when that media is no longer needed for business or legal reasons are separate and distinct from PCI DSS Requirement 3.2.1, which is for securely deleting cardholder data when no longer needed per the entity’s cardholder data retention policies.
   5. Goal 5: Regularly Monitor and Test Networks
      1. Requirement 11: Test Security of Systems and Networks Regularly Note: For SAQ A, Requirement 11 applies to merchant webservers that host the page(s) that either 1) redirects customers from the merchant website to a TPSP/payment processor for payment processing (for example, with a URL redirect) or 2) includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame).
         1. 11.3 External and internal vulnerabilities are regularly identified, prioritized, and addressed.
            1. 11.3.2 External vulnerability scans are performed as follows: • At least once every three months. • By PCI SSC Approved Scanning Vendor (ASV). • Vulnerabilities are resolved and ASV Program Guide requirements for a passing scan are met. • Rescans are performed as needed to confirm that vulnerabilities are resolved per the ASV Program Guide requirements for a passing scan. Applicability Notes For initial PCI DSS compliance, it is not required that four passing scans be completed within 12 months if the assessor verifies: 1) the most recent scan result was a passing scan, 2) the entity has documented policies and procedures requiring scanning at least once every three months, and 3) vulnerabilities noted in the scan results have been corrected as shown in a re-scan(s). However, for subsequent years after the initial PCI DSS assessment, passing scans at least every three months must have occurred. ASV scanning tools can scan a vast array of network types and topologies. Any specifics about the target environment (for example, load balancers, third-party providers, ISPs, specific configurations, protocols in use, scan interference) should be worked out between the ASV and scan customer. Refer to the ASV Program Guide published on the PCI SSC website for scan customer responsibilities, scan preparation, etc.
            2. 11.3.2.1 External vulnerability scans are performed after any significant change as follows: • Vulnerabilities that are scored 4.0 or higher by the CVSS are resolved. • Rescans are conducted as needed. • Scans are performed by qualified personnel and organizational independence of the tester exists (not required to be a QSA or ASV).
            3. PCI SSC List of Approved Scanning Vendors (ASV) Note. This must be carried out by a PCI SSC approved ASV.
         2. 11.6 Unauthorized changes on payment pages are detected and responded to
            1. 11.6.1 A change- and tamper-detection mechanism is deployed as follows: • To alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) to the HTTP headers and the contents of payment pages as received by the consumer browser. • If applicable, examine the targeted risk analysis. • The mechanism is configured to evaluate the received HTTP header and payment page. • The mechanism functions are performed as follows: – At least once every seven days OR – 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). Note: For SAQ A, Requirement 11.6.1 applies to a merchant’s website that includes a TPSP’s/payment processor’s embedded payment page/form (for example, an inline frame or iFrame). Applicability Notes The intention of this requirement is not that an entity installs software in the systems or browsers of its consumers, but rather that the entity uses techniques such as those described under Examples in the PCI DSS Guidance column (of PCI DSS Requirements and Testing Procedures) to prevent and detect unexpected script activities. This requirement is a best practice until 31 March 2025, after which it will be required and must be fully considered during a PCI DSS assessment.
   6. Goal 6: Maintain an Information Security Policy
      1. Requirement 12: Support Information Security with Organizational Policies and Programs Note: Requirement 12 specifies that merchants have information security policies for their personnel, but these policies can be as simple or complex as needed for the size and complexity of the merchant’s operations. The policy document must be provided to all personnel, so they are aware of their responsibilities for protecting payment terminals, any paper documents with account data, etc. If a merchant has no employees, then it is expected that the merchant understands and acknowledges their responsibility for security within their store(s).
         1. 12.8 Risk to information assets associated with third-party service provider (TPSP) relationships is managed. SAQ Completion Guidance: Selection of any of the In Place responses for requirements at 12.8.1 through 12.8.5 means that the merchant has a list of, and agreements with, service providers they share account data with or that could impact the security of the merchant’s cardholder data environment. For example, such agreements would be applicable if a merchant uses a document-retention company to store paper documents that include account data or if a merchant’s vendor accesses merchant systems remotely to perform maintenance.
            1. 12.8.1 A list of all third-party service providers (TPSPs) with which account data is shared or that could affect the security of account data is maintained, including a description for each of the services provided Applicability Notes The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.
            2. 12.8.2 Written agreements with TPSPs are maintained as follows: • Written agreements are maintained with all TPSPs with which account data is shared or that could affect the security of the CDE. • Written agreements include acknowledgments from TPSPs that they are responsible for the security of account data the TPSPs possess or otherwise store, process, or transmit on behalf of the entity, or to the extent that they could impact the security of the entity’s CDE. Applicability Notes The exact wording of an acknowledgment will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgment does not have to include the exact wording provided in this requirement. Evidence that a TPSP is meeting PCI DSS requirements (for example, a PCI DSS Attestation of Compliance (AOC) or a declaration on a company’s website) is not the same as a written agreement specified in this requirement.
            3. 12.8.3 An established process is implemented for engaging TPSPs, including proper due diligence prior to engagement.
            4. 12.8.4 A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months. Applicability Notes Where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity (for example, via a firewall service), the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity.
            5. 12.8.5 Information is maintained about which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.
         2. 12.10 Suspected and confirmed security incidents that could impact the CDE are responded to immediately.
            1. 12.10.1 An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident. The plan includes, but is not limited to: • Roles, responsibilities, and communication and contact strategies in the event of a suspected or confirmed security incident, including notification of payment brands and acquirers, at a minimum. • Incident response procedures with specific containment and mitigation activities for different types of incidents. • Business recovery and continuity procedures. • Data backup processes. • Analysis of legal requirements for reporting compromises. • Coverage and responses of all critical system components. • Reference or inclusion of incident response procedures from the payment brands. SAQ Completion Guidance: Selection of any of the In Place responses for Requirement 12.10.1 means that the merchant has documented an incident response and escalation plan to be used for emergencies, consistent with the size and complexity of the merchant’s operations. For example, such a plan could be a simple document posted in the back office that lists who to call in the event of various situations with an annual review to confirm it is still accurate, but could extend all the way to a full incident response plan including backup “hotsite” facilities and thorough annual testing. This plan should be readily available to all personnel as a resource in an emergency.