As per Verizon 2017 Payment Security Report :

  • 100% of organizations that suffered a breach were not compliant with the PCI DSS standard.
  • 55% of organizations achieved PCI DSS compliance at the interim assessment.
  • 13% is the average percentage of controls were not in place for companies failing their interim assessment.

Why is Payment Card Security important?

With the introduction of GDPR, the penalty for any insufficient safety measures will be more severe than ever before for the companies doing business in European Union. Unable to protect the protect personal data, which includes payment card data, will result in a penalty of €20 million (about £17.8 million) or 4% of annual global turnover – whichever is greater. Nearly half of the organizations that store, process or transmit card data are still failing to maintain PCI DSS compliance from year to year. The reasons for such failure could be any of the following:

  • A change to the PCI DSS (the latest version is 3.2), or the interpretation of the PCI DSS.
  • New software/technology that was not implemented with PCI DSS controls in mind.
  • A process or policy that is in need of modification.
  • An organization, personnel or vendor changes.
  • A system that was not tested during the previous assessment.



What is PCI DSS?

Before 2004, major credit card brands such as American Express, MasterCard, Visa, Discover and JSB used to implement their own version of security programme. They collaborated together to create a universally accepted programme to encourage and improve cardholder data security.
As a universal standard, any merchant or service provider that stores, processes or transmits cardholder data is required to comply with this Standard. Organizations that misses the mark to fulfill are ignored by the clients (after all, it’s all about their date), and those that undergo security breach and are found out to be out of compliant are possibly fined.



Where do Merchants like you fall in PCI DSS Levels?

Depending on the number of card transactions a business receives, the PCI DSS compliance requirements vary for merchants. The following merchant levels apply (criteria are from Visa and MasterCard):

  • PCI Level 1 - 6 million + transaction per year.
  • PCI Level 2 - 1 million - 6 million transactions per year.
  • PCI Level 3 - 20,000 - 1 million e-commerce transactions.
  • PCI Level 4 - Fewer than 20,000 e-commerce transactions per year (VISA). All other merchants (MasterCard).

PCI DSS validation requirements for merchants and service providers:

  • Quarterly ASV scanning.
  • Yearly SAQ.
  • Annual on-site QSA audit.

For Merchants:

  • For organizations handling fewer than 6M Visa or MasterCard transactions annually:
    • Quarterly ASV Scanning.
    • Yearly SAQ.
  • For organizations handling more than 6M Visa or MasterCard transactions annually:
    • Quarterly ASV Scanning.
    • Yearly SAQ.
    • Annual on-site QSA audit.

For Service Providers:

  • For organizations processing fewer than 6M Visa or MasterCard transactions annually:
    • Quarterly ASV Scanning.
    • Yearly SAQ.
  • For organizations handling more than 6M Visa or MasterCard transactions annually:
    • Quarterly ASV Scanning.
    • Annual on-site QSA audit.



Audit and RoC

To evaluate an organization’s ability to guard cardholder data, an external security audit is conducted by QSA annually. QSA will submit a formal report to the PCI SSC (Pay).
The audit includes the following:

  • Interviews,
  • Analysis of policies & procedures,
  • Validation of technical controls related to the cardholder environment.

It is mandatory for Level 1 merchants (6 million + transaction per year for an organization) to submit an RoC to authenticate if their required policies, procedures, and technical controls are in place. Level 1 merchants must submit an RoC to their acquiring banks to prove their compliance.

Why conduct an audit?
If any of the following reasons apply, an organization needs to go through an inspection of its compliance with the PCI DSS Standard:

  • If you are a level 1 merchant handling more than six millions of transactions with MasterCard or Visa every year.
  • If you are a merchant handling more than one million with MasterCard and you do not have a PCI DSS- trained internal assessor on staff.
  • If your organization has been breached in the past or show some exceptional risk.
  • If you are a service provider to merchants that can affect the safety of their payment transactions and you have access to large volumes of transactions every year.

Note: The acquiring bank on its own accord such as past breach history or current risk profile, can mandatethe merchant or SO (Service Organisation) to get certified on PCI DSS with a valid ROC and AOC regardless of the amount of payment transactions or any other qualifier.



Self-Assessment Questionnaire (SAQ)

For merchants and service providers at other levels that neither required to undertake an onsite data security assessment nor they have to submit the ROC, they can self-audit using SAQ to self-evaluate their compliance with the PCI DSS and then submit it to PCI SSC/QSA.
The different SAQ types areshown in the table below to help you identify which SAQ best applies to your organization. Detailed descriptions for each SAQ are provided within the applicable SAQ.
Note: Entities should ensure they meet all the requirements for a particular SAQ before using the SAQ. 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 Validation Type Description
A Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS validated third-party service 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 parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.
Applicable only to e-commerce channels.
B Merchants using only:
  • 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 Merchants using only standalone, PTS-approved payment terminals with an IP 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 Internet-based virtual terminal solution that is provided and hosted by a PCI DSS validated third-party service provider. No electronic cardholder data storage.
Not applicable to e-commerce channels.
C Merchants with payment application systems connected to the Internet, no electronic Card-holder data storage.
Not applicable to e-commerce channels.
P2PE-HW Merchants using only hardware payment terminals that are included in and managed via a validated, PCI SSC-listed P2PE solution, with no electronic cardholder data storage.
Not applicable to e-commerce channels.
D SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types.
SAQ D for Service Providers: All service providers defined by a payment brand as eligible to complete a SAQ.

What is the intent of SAQ A-EP?
SAQ A-EP has been developed to differentiate between merchants that have partially outsourced management of their e-commerce transactions, and merchants that have completely outsourced all management of their e-commerce environment (SAQ A merchants).
As with SAQ A, SAQ A-EP merchants do not electronically store, process, or transmit any cardholderdata on their systems or premises, but rely entirely on a third party(s) to handle these functions. All processing of cardholder data is outsourced to a PCI DSS validated third-party payment processor forboth SAQ A and SAQ A-EP.
SAQ A-EP is intended to identify the controls needed to secure merchant web sites that control ormanage the payment transaction, and reduce the likelihood a breach of the web site can be used to compromise cardholder data.


How does SAQ A-EP compare to 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.
NOTE: This table is intended to provide a comparison between SAQ A and SAQ A-EP and does not supersede or replace the eligibility criteria for either SAQ.

  SAQ A
All Cardholder Data Functions Completely Outsourced
SAQ A-EP
Partially Outsourced E-commerce Payment Channel
Applies to: Card-not-present merchants (e-commerce ormail/telephone-order)* E-commerce merchants.
Functions Outsourced All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers. All processing of cardholder data, with the exception of the payment page, is entirely outsourced to a PCI DSS validated third-party payment processor.
Payment Pages All elements of all payment pages delivered to the consumer’s browser originate only and directly from a PCI DSS validated third-party service provider(s). Each element of the payment page(s) delivered to the consumer’s browser originates from either the merchant’s website or a PCI DSScompliant service provider(s).
Third-Party Compliance Merchant confirmed that all third party(s) handling storage, processing, and/or transmission of cardholder data are PCI DSS compliant.
Merchant Systems Merchant does not electronically store, process, or transmit any cardholder data on their systems or premises, but relies entirely on a third party(s) to handle all these functions.
Data Retention Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically.

* Criteria for SAQ A mail/telephone order (MOTO) channels are not included in this comparison.

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 merchant website. Examples of e-commerce implementations addressed by SAQ A include:

  • Imprint machines with no electronic cardholder data storage; and/or
  • Merchant has no access to their website, and the website is entirely hosted and managed by a compliant third-party payment processor.
  • Merchant website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process.
  • Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process.

If any element of a payment page delivered to consumers’ browsers originates from the merchant’swebsite, SAQ A does not apply; however, SAQ A-EP may be applicable. Examples of e-commerceimplementations addressed by SAQ A-EP include:

  • Merchant website creates the payment form, and the payment data is delivered directly from the consumer browser to the payment processor (often referred to as “Direct Post”).
  • Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how 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 terminals that connect to their payment processors via an IP-based connection, from merchants who connect to their payment processor using only dial-out connections (which may meet the criteria ofSAQ 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 forSAQ B-IP.
Other eligibility criteria for SAQ B-IP include that the approved devices are segmented from other systems within the environment, and the devices do not rely on any other device (e.g., computer,mobile phone, tablet, etc.) to connect to the payment processor. Additionally, to be eligible for SAQ BIP, the only permitted transmission of cardholder data is from the PTS-approved device to the payment processor, and the merchant must not store cardholder data in electronic format. SAQ B-IP, like SAQB, is not applicable to e-commerce channels.
Prior to the release of SAQ B-IP, merchants with this type of environment may have needed to complete SAQ C or SAQ D. These merchants may now be eligible to use SAQ B-IP, which may bebetter suited for their particular environment and provides a simpler validation than SAQ C.


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 between SAQ B and SAQ B-IP.
Note: 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.

  SAQ B
Imprint machines or standalone,dial-out terminals.
SAQ B-IP
Standalone, PTS-approved payment terminals with an IP connection.
Applies to: Brick-and-mortar (card-present) or mail/telephone order (card-not-present) merchants.
Payment Terminals Standalone, dial-out terminal (connected via a phone line to the processor). Standalone, PTS-approved point-of interaction (POI) devices (excludes SCRs) connected via IP to the payment processor.
CHD Transmissions CHD is not transmitted over a network (either an internal network or the Internet). Only CHD transmission is via IP from the PTS-approved POI devices to the payment processor.
Merchant Systems Merchant does not does not store cardholder data in electronic format.
Data Retention Merchant retains only paper reports or receipts with cardholder data, and these documents are not received electronically.



Our Approach to assessing your card risks with PCI DSS

Initial study

Initial study of your business to understanding your card processes and environment. This will enable us to confirm that you have a lean and mean PCI scope thereby helping you reduce implementation cost and audit time/cost.

Scope Definition

With the information gathered from the initial study, we can assist your organisation to ensure that the scope boundaries are as per PCI requirements.



VA/PT

Conduct ASV scans, internal Vulnerability Assessment, web app assessment and network penetration testing of the systems in scope.



Pre-assessment

To ensure significant gaps are identified before final audit, our team of process and technical experts shall assess your compliance levels to PCI requirements and provide recommendations for fixing gaps identified.

Recommendation rollout

With the information gathered from the initial study, we can assist your organisation to ensure that the scope boundaries are as per PCI requirements.



Certification

Once all controls are confirmed to be in place, our QSA team shall validate compliance of your organisation and issue certified SAQ / ROC / AOC as applicable.



Deliverable

Why our PCI DSS is much sought after by Corporations worldwide

  • A well designed environment effectively protecting your sensitive card information.
  • Vulnerability scans inline with ASV requirements.
  • Support in system hardening.
  • Training videos and materials with your branding.
  • Certification support.
  • PCI DSS processes and deliverable