Document Changes Date PCI DSS Version SAQ Revision Description October 2008 1.2 To align content with new PCI DSS v1.2 and to implement minor changes noted since original v1.1. October 2010 2.0 To align content with new PCI DSS v2.0 requirements and testing procedures. February 2014 3.0 To align content with PCI DSS v3.0 requirements and testing procedures and incorporate additional response options. April 2015 3.1 Updated to with PCI DSS v3.1. For details of PCI DSS changes, see PCI DSS – Summary of Changes from PCI DSS Version 3.0 to 3.1. July 2015 3.1 1.1 Updated to remove references to “best practices” prior to June 30, 2015, and remove the PCI DSS v2 reporting option for Requirement 11.3. April 2016 3.2 1.0 Updated to with PCI DSS v3.2. For details of PCI DSS changes, see PCI DSS – Summary of Changes from PCI DSS Version 3.1 to 3.2. Table of Contents
Is firmware on wireless devices updated to support strong encryption for authentication and transmission over wireless networks? Review policies and procedures Review vendor documentation Examine system configurations Are other security-related wireless vendor defaults changed, if applicable? Review policies and procedures Review vendor documentation Examine system configurations 2.2 Are configuration standards developed for all system components and are they consistent with system hardening standards? Sources of industry-accepted system hardening standards may include, but are not limited to, SysAdmin Network Security (SANS) Institute, National Institute of Standards Technology (NIST), International Organization for Standardization (ISO), and Center for Internet Security (CIS). Review system configuration standards Review industry-accepted hardening standards Review policies and procedures Interview personnel Are system configuration standards updated as new vulnerability issues are identified, as defined in Requirement 6.1? Review policies and procedures Interview personnel Are system configuration standards applied when new systems are configured? Review policies and procedures Interview personnel
6.5.7 Do coding techniques address cross-site scripting (XSS) vulnerabilities? Examine policies and procedures Interview responsible personnel 6.5.8 Do coding techniques address improper access control such as insecure direct object references, failure to restrict URL access, directory traversal, and failure to restrict user access to functions? Examine policies and procedures Interview responsible personnel 6.5.9 Do coding techniques address cross-site request forgery (CSRF)? Examine policies and procedures Interview responsible personnel 6.5.10 Do coding techniques address broken authentication and session management? Examine policies and procedures Interview responsible personnel
8.1.3 Is access for any terminated users immediately deactivated or removed? Review password procedures Examine terminated users accounts Review current access lists Observe returned physical authentication devices 8.1.4 Are inactive user accounts either removed or disabled within 90 days? Review password procedures Observe user accounts 8.1.5 Are accounts used by third parties to access, support, or maintain system components via remote access enabled only during the time period needed and disabled when not in use? Review password procedures Interview personnel Observe processes Are third party remote access accounts monitored when in use? Interview personnel Observe processes 8.1.6 Are repeated access attempts limited by locking out the user ID after no more than six attempts? Review password procedures Examine system configuration settings This testing procedure applies only to service providers. 8.1.7 Once a user account is locked out, is the lockout duration set to a minimum of 30 minutes or until an administrator enables the user ID? Review password procedures Examine system configuration settings 8.1.8 If a session has been idle for more than 15 minutes, are users required to re-authenticate (for example, re-enter the password) to re-activate the terminal or session? Review password procedures Examine system configuration settings
8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, and certificates, etc.), is the use of these mechanisms assigned as follows? Authentication mechanisms must be assigned to an individual account and not shared among multiple accounts Physical and/or logical controls must be in to ensure only the intended account can use that mechanism to gain access Review policies and procedures Interview personnel Examine system configuration settings and/or physical controls 8.7 Is all access to any database containing cardholder data (including access by applications, administrators, and all other users) restricted as follows: Is all user access to, user queries of, and user actions on (for example, move, copy, delete), the database through programmatic methods only (for example, through stored procedures)? Review database authentication policies and procedures Examine database and application configuration settings Is user direct access to or queries to of databases restricted to database administrators? Review database authentication policies and procedures Examine database access control settings Examine database application configuration settings Are application IDs only able to be used by the applications (and not by individual users or other processes)? Review database authentication policies and procedures Examine database access control settings Examine database application configuration settings
9.1.3 Is physical access to wireless access points, gateways, handheld devices, networking/communications hardware, and telecommunication lines restricted? Review policies and procedures Interview personnel Observe devices 9.2 Are procedures developed to easily distinguish between onsite personnel and visitors, which include: Identifying onsite personnel and visitors (for example, assigning badges), Changing access requirements, and Revoking terminated onsite personnel and expired visitor identification (such as ID badges) For the purposes of Requirement 9, “onsite personnel” refers to full-time and part-time employees, temporary employees, contractors and consultants who are physically present on the entity’s premises. A “visitor” refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the facility for a short duration, usually not more than one day. Review policies and procedures Interview personnel Observe identification methods (e.g. badges) Observe visitor processes Do identification methods (such as ID badges) clearly identify visitors and easily distinguish between onsite personnel and visitors? Observe identification methods Is access to the badge system limited to authorized personnel? Observe physical controls and access controls for the badge system
9.3 Is physical access to sensitive areas controlled for onsite personnel, as follows: Is access authorized and based on individual job function? Is access revoked immediately upon termination Upon termination, are all physical access mechanisms, such as keys, access cards, etc., returned or disabled? Interview personnel Examine access control lists Observe onsite personnel Compare lists of terminated employees to access control lists 9.4 Is visitor identification and access handled as follows: 9.4.1 Are visitors authorized before entering, and escorted at all times within, areas where cardholder data is processed or maintained? Review policies and procedures Observe visitor processes including how access is controlled Interview personnel Observe visitors and badge use 9.4.2 Are visitors identified and a badge or other identification that visibly distinguishes the visitors from onsite personnel? Observe badge use of personnel and visitors Examine identification Do visitor badges or other identification expire? Observe process Examine identification 9.4.3 Are visitors asked to surrender the badge or other identification before leaving the facility or at the date of expiration? Observe processes Observe visitors leaving facility 9.4.4 Is a visitor log in use to record physical access to the facility as well as for computer rooms and data centers where cardholder data is stored or transmitted? Review policies and procedures Examine the visitor log Observe visitor processes Examine log retention Does the visitor log contain the visitor’s name, the firm represented, and the onsite personnel authorizing physical access? Review policies and procedures Examine the visitor log
Is the visitor log retained for at least three months? Review policies and procedures Examine visitor log retention 9.5 Are all media physically secured (including but not limited to computers, removable electronic media, paper receipts, paper reports, and faxes)? For purposes of Requirement 9, “media” refers to all paper and electronic media containing cardholder data. Review policies and procedures for physically securing media Interview personnel 9.5.1 Is the location where media back-ups are stored reviewed at least annually to confirm storage is secure? Review policies and procedures for reviewing offsite media locations Interview security personnel 9.6 Is strict control maintained over the internal or external distribution of any kind of media? Review policies and procedures for distribution of media Do controls include the following: 9.6.1 Is media classified so the sensitivity of the data can be determined? Review policies and procedures for media classification Interview security personnel 9.6.2 Is media sent by secured courier or other delivery method that can be accurately tracked? Interview personnel Examine media distribution tracking logs and documentation 9.6.3 Is management approval obtained prior to moving the media (especially when media is distributed to individuals)? Interview personnel Examine media distribution tracking logs and documentation 9.7 Is strict control maintained over the storage and accessibility of media? Review policies and procedures 9.7.1 Are inventory logs of all media properly maintained? Examine inventory logs
(b) Have personnel at locations received training, and are they aware of procedures to detect and report attempted tampering or replacement of devices? Interview personnel at POS locations 9.10 Are security policies and operational procedures for restricting physical access to cardholder data: Documented In use Known to all affected parties? Examine security policies and operational procedures Interview personnel Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data PCI DSS Question Expected Testing Response (Check one response for each question) Yes Yes with CCW No N/A Not Tested 10.1 Are audit trails enabled and active for system components? Observe processes Interview system administrator Is access to system components linked to individual users? Observe processes Interview system administrator 10.2 Are automated audit trails implemented for all system components to reconstruct the following events:
10.6.1 Are written policies and procedures defined for reviewing the following at least daily, either manually or via log tools? All security events Logs of all system components that store, process, or transmit CHD and/or SAD Logs of all critical system components Logs of all servers and system components that perform security functions (for example, firewalls, intrusion-detection systems (IDS/IPS), authentication servers, e-commerce redirection servers, etc.) Review security policies and procedures Are the above logs and security events reviewed at least daily? Observe processes Interview personnel 10.6.2 Are written policies and procedures defined for reviewing logs of all other system components periodically—either manually or via log on the organization’s policies and risk management strategy? Review security policies and procedures Are reviews of all system components performed in accordance with organization’s policies and risk management strategy? Review risk assessment documentation Interview personnel 10.6.3 Are written policies and procedures defined for following up on exceptions and anomalies identified during the review process? Review security policies and procedures Is follow up to exceptions and anomalies performed? Observe processes Interview personnel 10.7 Are audit log retention policies and procedures in place and do they require that logs are retained for at least one year, with a minimum of three months immediately available for analysis (for example, online, archived, or restorable from backup)? Review security policies and procedures
Appendix D: Explanation of Requirements Not Tested If the “Not Tested” column was checked in the questionnaire, use this worksheet to explain why the related requirement was not reviewed as part of the assessment. Requirement Describe which part(s) of the requirement was not tested Describe why requirements were not tested Examples: Requirement 12 Requirement 12.2 was the only requirement tested. All other requirements from Requirement 12 were excluded. This assessment only covers requirements in Milestone 1 of the Prioritized Approach. Requirements 1-8, 10-12 Only Requirement 9 was reviewed for this assessment. All other requirements were excluded. Company is a physical hosting provider and only physical security controls were considered for this assessment.
No evidence of full track data, CAV2, CVC2, CID, or CVV2 data, or PIN data storage after transaction authorization was found on ANY system reviewed during this assessment. ASV scans are being completed by the PCI SSC Approved Scanning Vendor (ASV Name) Part 3b. Merchant Attestation Signature of Merchant Executive Officer Date: Merchant Executive Officer Name: Title: Part 3c. Qualified Security Assessor (QSA) Acknowledgement (if applicable) If a QSA was involved or assisted with this assessment, describe the role performed: Signature of Duly Authorized Officer of QSA Company Date: Duly Authorized Officer Name: QSA Company: Part 3d. Internal Security Assessor (ISA) Involvement (if applicable) If an ISA(s) was involved or assisted with this assessment, identify the ISA personnel and describe the role performed: Part 4. Action Plan for Non-Compliant Requirements Select the appropriate response for “Compliant to PCI DSS Requirements” for each requirement. If you answer “No” to any of the requirements, you may be required to provide the date your Company expects to be compliant with the requirement and a description of the actions being taken to meet the requirement. Check with your acquirer or the payment brand(s) before completing Part 4. PCI DSS Requirement Description of Requirement Compliant to PCI DSS Requirements (Select One) Remediation Date and Actions (If “NO” selected for any Requirement) YES NO 1 Install and maintain a firewall configuration to protect cardholder data 2 Do not use vendor-supplied defaults for system passwords and other security parameters
3 Protect stored cardholder data 4 Encrypt transmission of cardholder data across open, public networks 5 Protect all systems against malware and regularly update software or programs 6 Develop and maintain secure systems and applications 7 Restrict access to cardholder data by business need to know 8 Identify and authenticate access to system components 9 Restrict physical access to cardholder data 10 Track and monitor all access to network resources and cardholder data 11 Regularly test security systems and processes 12 Maintain a policy that addresses information security for all personnel Appendix A2 Additional PCI DSS Requirements for Entities using SSL/early TLS