Understanding SAQs PCI DSS v3

Transcript

1 Understanding 3 ersion s for PCI DSS v the SAQ -assessment questionnaires (SAQs) are validation tools intended to assist merchants The PCI DSS self The different SAQ types are of their PCI DSS self and service providers report the results -assessment. nization. shown in the table below to help you identify which SAQ best applies to your orga Detailed descriptions for each SAQ are provided within the applicable SAQ. Entities should ensure they meet all the requirements for a particular SAQ before using the SAQ. Note: Merchants are encouraged to contact their merchant bank (acquirer) or the applicable payment brand(s) to identify the appropriate SAQ based on their eligibility. SAQ Description A commerce or mail/telephone- -present merchants (e- not Card- order) that have fully third -party service validated outsourced all cardholder data functions to PCI DSS providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Not applicable to face- to-face channels. A-EP* E-commerce merchants who outsource all payment processing to PCI DSS validated third directly receive cardholder data but parties, and who have a website(s) that doesn’t that electronic storage, processing, or can impact the security of the payment transaction. No transmission of any cardholder data on the merchant’s systems or premises. Applicable only to e- commerce channels. Merchants using only B : • Imprint machines with no electronic cardholder data storage; and/or • Standalone, dial -out terminals with no electronic cardholder data storage. Not applicable to e- commerce channels. B-IP* -approved payment terminals with an IP Merchants using only standalone, PTS connection to the payment processor, with no electronic cardholder data storage. Not applicable to e- commerce channels. C-VT Merchants who manually enter a single transaction at a time via a keyboard into an -based virtual terminal solution that is provided and hosted by a PCI DSS Internet -party service provider. No electronic cardholder data storage. validated third Not applicable to e- commerce channels. C Merchants with payment application systems connected to the Internet, no electronic cardholder data storage. Not applicable to e- commerce channels. P2PE- HW n and managed via Merchants using only hardware payment terminals that are included i -listed P2PE solution, with no electronic cardholder data storage. a validated, PCI SSC commerce channels. Not applicable to e- D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types. All service providers defined by a payment brand as Service Providers: SAQ D for eligible to complete a SAQ. for * New PCI DSS v3.0 Page 1 The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014- 2015 PCI Security Standards Council, LLC. All Rights Reserved.

2 • 2015 April Understanding SAQs for PCI DSS Version 3 Information Supplement • 3 of the SAQs? What’s new in v ersion 3 to provide version -assessment questionnaire (SAQs) has been updated in The format of the self more guidance and reporting information for each PCI DSS requirement. - A new column titled “Expected Testing” describes the testing activities to be performed during the self The “Special” column een met. a requirement has b assessment, to help the entity determine whether from version 2 has been replaced with two separate columns in version 3: “Yes with CCW” .” These updated response options help entities to more (compensating control worksheet) and “N/A clearly identify which response to use for each requirement. The orientation of the SAQs has changed from portrait to landscape to accommodate these additional columns. There is also additional guidance provided at the beginning of the SAQs to assist with understanding The sections within the SAQ documents have been reorganized, such that how to complete the SAQ. Parts 3 and 4 of the AOC now follow the questionnaire portion of the SAQ. This is to ensure that an entity’s attestation encompasses all elements of the SAQ and AOC. Additional guidance and information about SAQ format is provided in the “Before you Begin” section of each SAQ. How will the SAQ updates impact my organization? With PCI DSS version 3, there are new SAQs as well as updated eligibility criteria for existing SAQs, ions will need to review the eligibility criteria to understand which SAQ may now be right and organizat for them. For example, one of the new SAQs may be better aligned with an organization’s particular environment than the SAQ used previously. Similarly, an organizati on that previously completed one type of SAQ will need to review the criteria for that particular SAQ to determine whether it is still appropriate for their environment. The SAQ updates for version 3 may also mean that a merchant may need to validate addi tional -assessment requirements, which could impact how the merchant approaches their self . Even where the eligibility criteria have not changed for a particular SAQ, the SAQ may include different PCI DSS requirements in version 3 than in version 2. The questions in each SAQ have been updated to reflect changes made to PCI DSS version 3. For example, some complex requirements have been broken down into sub- requirements, and other requirements may have been clarified or extended, ions in the SAQs. resulting in updated quest Merchants should continue to choose an applicable SAQ based upon the defined eligibility criteria for each SAQ, and according to instructions from their acquirer or payment brand(s). Page 2 The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014- 2015 PCI Security Standards Council, LLC. All Rights Reserved.

3 2015 April • Understanding SAQs for PCI DSS Version 3 Information Supplement • What are the new SAQs for PCI DSS version 3? A-EP is a new SAQ for e- SAQ processing commerce merchants who outsource their transaction- service providers, where the merchant website controls functions to PCI DSS compliant third -party To be eligible for this SAQ, how the cardholder data is redirected to the third -party service provider. , or transmit cardholder data on any of their systems or premises. the merchant must not store, process IP is a new SAQ for merchants who process cardholder data only via standalone, PTS - SAQ B- POI) devices that have an IP connection to their payment processor, -of-interaction ( approved point and do not electronically store cardholder data. To be eligible for this SAQ, the merchant must be PTS List of Approved POI Devices using payment terminals that are currently listed on the ( https://www.pcisecuritystandards.org/approved_companies_providers/approved_pin_transaction_sec ). Note that the Secure Card Reader (SCR) class of POI devices does not meet the criteria for urity.php IP is not applicable to SAQ B- SAQ B- IP, and thus merchant using SCRs are not eligible for this SAQ. e-commerce channels. -EP? What is the intent of SAQ A SAQ A- EP has been developed to different iate between merchants that have partially outsourced commerce transactions, and merchants that have completely outsourced all management of their e- commerce environment (SAQ A merchants). management of their e- EP merchants do not electronically store, process, or transmit any cardholder As with SAQ A, SAQ A- data on their systems or premises, but rely entirely on a third party(s) to handle these functions. All party payment processor for processing of cardholder data is outsourced to a PCI DSS validated third- -EP. both SAQ A and SAQ A EP, many e -commerce merchants with web sites that impacted the Prior to the release of SAQ A- security of payment transactions may have felt they were eligible for SAQ A because their web server As a result, these web servers did not have does not store, process , or trans mit cardholder data. sufficient security controls applied to them and have become common targets for attackers as a means to compromise cardholder data. SAQ A- EP is intended to identify the controls needed to secure merchant web sites that control or of the web site can be used to manage the payment transaction, and reduce the likelihood a breach cardholder data. compromise Page 3 The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014- 2015 PCI Security Standards Council, LLC. All Rights Reserved.

4 2015 Information Supplement • Understanding SAQs for PCI DSS Version 3 • April -EP compare to SAQ A? How does SAQ A The following table provides a high- level overview of some of the key similarities and differences between SAQ A and SAQ A -EP. -EP SAQ A SAQ A Partially Outsourced E -commerce All Cardholder Data Functions Completely Outsourced Payment Channel merchants (e- merchants E-commerce Card -not- present commerce or Applies to : mail/telephone- order)* of cardholder data , with the processing is entirely All processing of cardholder data All is entirely exception of the payment page, outsourced to PCI DSS validated third- party Functions outsourced to a PCI DSS validated third- party Outsourced service providers payment processor Each s) delivered payment page( element of the All elements of all payment pages deli vered to and s to the consumer’s browser only originate the consumer’s browser originate from Payment directly from a PCI DSS validated third -party the merchant’s website or a PCI DSS either Pages service provider(s) compliant service provider(s) storage, processing, and/or transmission of Merchant confirmed that all third party(s) handling Third -Party Compliance cardholder data are PCI DSS compliant Merchant does not electronically store, process, or transmit any cardholder data on their systems Merchant or premises, but relies entirely on a third party(s) to handle all these functions Systems Merchant retains only paper reports or receipts with cardholder data, and these documents are not Data Retention received electronically * Criteria for SAQ A mail/telephone order (MOTO) channels are not included in this comparison. -EP and does not This table is intended to provide a comparison between SAQ A and SAQ A supersede or replace the eligibility criteria for either SAQ. The intent of this document is to provide supplemental information. Information provided here Page 4 does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014- 2015 PCI Security Standards Council, LLC. All Rights Reserved.

5 2015 Information Supplement • Understanding SAQs for PCI DSS Version 3 • April What types of e -commerce implementations are eligible for SAQ A -EP vs. SAQ A? To be eligible for SAQ A, e- commerce merchants must meet all eligibility criteria detailed in SAQ A, including that there are no programs or application code that capture payment information on the ddressed by SAQ A include: commerce implementations a merchant website. Examples of e- • Merchant has no access to their website, and the website is entirely hosted and managed by a compliant third -party payment processor party ) to a PCI DSS compliant third- • iFrame Merchant website provides an inline frame ( processor facilitating the payment process. • Merchant website contains a URL link redirecting users from merchant website to a PCI DSS -party processor facilitating the payment process. compliant third originates from the merchant’s If any element of a payment page delivered to consumers’ browsers Examples of e- -EP may be applicable. commerce website, SAQ A does not apply; however, SAQ A include: EP SAQ A- addressed by implementations Merchant website creates the payment f • orm, and the payment data is delivered directly from the consumer browser to the payment processor (often referred to as “ ”). Direct Post (for example, Merchant website loads or delivers script that runs in consumers’ browsers • provides functionality that supports creation of the payment page and/or how JavaScript) and the data is transmitted to the payment processor . What is the intent of SAQ B -IP? SAQ B- IP has been developed to differentiate between merchants using only standalone payment -based connection, from merchants who ter minals that connect to their payment processors via an IP connect to their payment processor using only dial -out connections (which may meet the criteria of SAQ B). To be eligible for SAQ B -IP, merchants must be using payment terminals that have been approved under the PCI PTS program and are listed on the PCI SSC website as approved devices. Note that merchants using the Secure Card Reader (SCR) category of devices are NOT eligible for SAQ B- IP. ia for SAQ B Other eligibility criter -IP include that the approved devices are segmented from other not rely on any other device (e.g., computer, systems within the environment, and the devices do - Additionally, to be mobile phone, tablet, etc.) to connect to the payment processor. eligible for SAQ B -approved device to the payment IP, the only permitted transmission of cardholder data is from the PTS SAQ B- processor, and the merchant must not store cardholder data in electronic format. IP, like SAQ channels. commerce B, is not applicable to e- the release of IP, merchants with this type of environment may have needed to SAQ B- Prior to -IP, which may be These merchants may now be eligible to use SAQ B complete SAQ C or SAQ D. better suited for their particular environment and provides a simpler validation than SAQ C. Page 5 The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014- 2015 PCI Security Standards Council, LLC. All Rights Reserved.

6 2015 April Information Supplement • Understanding SAQs for PCI DSS Version 3 • How does SAQ B -IP compare to SAQ B? The following table provides a high- level overview of some of the key similarities and differences -IP. between SAQ B and SAQ B SAQ B SAQ B -IP Standalone approved payment , PTS- Imprint machines or standalone, terminals with an IP connection dial -out terminals -and- Brick -present) or mortar (card Applies to : mail/telephone order (card- not -present) merchants approved point- PTS- Standalone, of- Standalone, dial- out terminal Payment SCRs) (connected via a phone line to the interaction (POI) devices (excludes Terminals processor) connected via IP to the payment processor Only is not transmitted over a CHD CHD transmission is via IP from the CHD PTS- (either an internal network or network approved POI devices to the payment Transmissions processor the Internet) Merchant Merchant does not does not store cardholder data in electronic format Systems Merchant retains only paper reports or receipts with cardholder data, and these Data Retention documents are not received electronically This table is intended to provide a comparison between SAQ B and SAQ B -IP, and does not supersede or replace the eligibility criteria for either SAQ. Page 6 The intent of this document is to provide supplemental information. Information provided here does not replace or supersede PCI SSC Security Standards or their supporting documents. © 2014- 2015 PCI Security Standards Council, LLC. All Rights Reserved.

Related documents