Card-present (face-to-face) Card-present (face-to-face) [If your OST-approved 3rd party vendor IP-connected POS device is being used in compliance with PCI SAQ C requirements, you should only be taking transactions via Card-present or MOTO.] Note: If your organization has a payment channel or process that is not covered by this SAQ, consult your acquirer or payment about validation for the other channels. Part 2b. Description of Payment Card Business How and in what capacity does your business store, process and/or transmit cardholder data? [Fill out per your OST-approved 3rd party vendor.] Part 2c. Locations List types of facilities and a summary of locations (for example, retail outlets, corporate offices, data centers, call centers, etc.) included in the PCI DSS review. Type of facility Number of facilities of this type Location(s) of facility (city, country) Example: Retail outlets 3 Boston, MA, USA Part 2d. Payment Application Does the organization use one or more Payment Applications? [Yes] Yes No Provide the following information regarding the Payment Applications your organization uses: Payment Application Name Version Number Application Vendor Is application PA-DSS Listed? PA-DSS Listing Expiry date (if applicable) [Fill out per your OST-approved 3rd party vendor.] [Fill out per your 3rd party vendor.] [Fill out per your 3rd party vendor.] Yes No [Fill out per your OST-approved 3rd party vendor.] [Fill out per your OST-approved 3rd party vendor.] Yes No Yes No Yes No Yes No Part 2e. Description of Environment
Are security-related wireless vendor defaults changed, if applicable? Review policies and procedures Review vendor documentation Examine system configurations [Should be N/A unless cellular wireless. Wireless connection of OSU’s SAQ C devices is not allowed, with the exception of cellular wireless. If your non-cellular device is connected wirelessly, please work with your IT department to change this connection. For cellular wireless, fill out per your OST-approved 3rd party vendor.] 2.2 Are configuration standards developed for all system components and are they consistent with industry-accepted system hardening standards? Sources of industry-accepted system hardening standards may include, but are not limited to, SysAdmin Audit 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 [Fill out per your OST-approved 3rd party vendor.] Are system configuration standards updated as new vulnerability issues are identified, as defined in Requirement 6.1? Review policies and procedures Interview personnel [Fill out per your OST-approved 3rd party vendor.] Are system configuration standards applied when new systems are configured? Review policies and procedures Interview personnel [Fill out per your OST-approved 3rd party vendor.]
Are common system security parameters settings included in the system configuration standards? Review system configuration standards [Fill out per your OST-approved 3rd party vendor.] Are security parameter settings set appropriately on system components? Examine system components Examine security parameter settings Compare settings to system configuration standards [Fill out per your OST-approved 3rd party vendor.] 2.2.5 Has all unnecessary functionality—such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers—been removed? Examine security parameters on system components [Fill out per your OST-approved 3rd party vendor.] Are enabled functions documented and do they support secure configuration? Review documentation Examine security parameters on system components [Fill out per your OST-approved 3rd party vendor.] Is only documented functionality present on system components? Review documentation Examine security parameters on system components [Fill out per your OST-approved 3rd party vendor.]
2.3 Is non-console administrative access encrypted as follows: Use technologies such as SSH, VPN, or TLS for web-based management and other non-console administrative access. Note: SSL and TLS are not considered strong cryptography and cannot be used as a security control after 30th June, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place. Effective immediately, new implementations must not use SSL or early TLS. POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS may continue using these as a security control after 30th June, 2016. Is all non-console administrative access encrypted with strong cryptography, and is a strong encryption method invoked before the administrator’s password is requested? Examine system components Examine system configurations Observe an administrator log on [Fill out per your OST-approved 3rd vendor.] Are system services and parameter files configured to prevent the use of Telnet and other insecure remote login commands? Examine system components Examine services and files [Fill out per your OST-approved 3rd party vendor.] Is administrator access to web-based management interfaces encrypted with strong cryptography? Examine system components Observe an administrator log on [Fill out per your OST-approved 3rd party vendor.]
For the technology in use, is strong cryptography implemented according to industry best practice and/or vendor recommendations? Examine system components Review vendor documentation Interview personnel [Fill out per your OST-approved 3rd vendor.] For POS POI terminals (and the SSL/TLS termination points to which they connect) using SSL and/or early TLS and for which the entity asserts are not susceptible to any known exploits for those protocols: Is there documentation (for example, vendor documentation, system/network configuration details, etc.) that verifies the devices are not susceptible to any known exploits for SSL/early TLS? Review documentation that verifies POS POI devices are not susceptible to any known exploits for SSL/early TLS\ [Fill out per your OST-approved 3rd vendor.] (f) For all other environments using SSL and/or early TLS: Does the documented Risk Mitigation and Migration Plan include the following? Description of including; what data is being transmitted, types and number of systems that use and/or support SSL/early TLS, type of environment; Risk results and risk reduction controls in Description of processes to monitor for new vulnerabilities associated with SSL/early TLS; Description of change control processes that are implemented to ensure TLS is not implemented into new environments; Overview of migration project plan including target migration completion date no than 30th June 2016. Review Risk Mitigation and Migration Plan [Fill out per your OST-approved 3rd party vendor.]
4.2 (b) Are policies in that state that unprotected PANs are not to be sent via end-user messaging technologies? Review policies and procedures [Review policies in links below. In addition, fill out per your 3rd party vendor.] Maintain a Vulnerability Management Program Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs PCI DSS Question Expected Testing Response (Check one response for each question) Yes Yes with CCW No N/A 5.1 Is anti-virus software deployed on all systems commonly affected by malicious software? Examine system configurations [Fill out per your OST-approved 3rd party vendor.] 5.1.1 Are anti-virus programs capable of detecting, removing, and protecting against all known types of malicious software (for example, viruses, Trojans, worms, spyware, adware, and rootkits)? Review vendor documentation Examine system configurations [Fill out per your OST-approved 3rd vendor.] 5.1. 2 Are periodic evaluations performed to identify and evaluate evolving malware threats in order to confirm whether those systems considered to not be commonly affected by malicious software continue as such? Interview personnel [Fill out per your OST-approved 3rd vendor.] Are all anti-virus mechanisms maintained as follows:
12.8.1 Is a list of service providers maintained? Review policies and procedures Observe processes Review list of service providers [Business Affairs a master list of service providers using information provided by merchants. Please keep a local list as well and inform Business Affairs when service provider changes are made.] 12.8.2 Is a written agreement maintained that includes an acknowledgement that the service providers are responsible for the security of cardholder data the service providers possess or otherwise process, or transmit on behalf of the customer, or to the extent that they could impact the security of the customer’s cardholder data environment? Note: The exact wording of an acknowledgement will depend on the agreement between the two parties, the details of the service being provided, and the responsibilities assigned to each party. The acknowledgement does not have to include the exact wording provided in this requirement. Observe written agreements Review policies and procedures [Ensure you have a written agreement in place for your OST-approved 3rd party vendor.] 12.8.3 Is there an established process for engaging service providers, including proper due diligence prior to engagement? Observe processes Review policies and procedures and supporting documentation
12.8.4 Is a program maintained to monitor service providers’ PCI DSS compliance status at annually? Observe processes Review policies and procedures and supporting documentation [Ensure your OST-approved 3rd vendor is on the Visa Global Registry of Service Providers here with an unexpired ‘VALID THROUGH DATE’ and include this document with your SAQ submission: .] 12.8.5 Is information maintained which PCI DSS requirements are managed by each service provider, and which are managed by the entity? Observe processes Review policies and procedures and supporting documentation [Ensure you have this information documented for your OST-approved 3rd vendor.] 12.10.1 Has an incident response plan been created to be implemented in the of system breach? Review the incident response plan Review incident response plan procedures Does the plan address the following, at a minimum: Roles, responsibilities, and communication and contact strategies in the event of a compromise including notification of the payment brands, at a minimum? Review incident response plan procedures Specific incident response procedures? Review incident response plan procedures