Recently, CardConnect and HALOCK held a live Q&A on PCI compliance. The interactive session drew a large crowd of participants who openly and honestly asked their toughest PCI questions with complete anonymity.
Hosts Viviana Wesley, HALOCK’s Managing Consultant, and Mark Cuneo, one of CardConnect’s own PCI Payments Professionals, each drew on over 16-years of practical information security experience to help participants successfully navigate through PCI governance, risk and compliance issues.
In case you missed it, we’ve recorded the session and are serving it up podcast-style, below, so you can catch up on the biggest PCI issues affecting professionals today. Also, included below is a sampling of questions asked during the webinar and resources referenced in response. We encourage you to check ‘em out.
Questions from Audience. Answers Provided by the Experts.
Question: Is there a single document outlining the requirements for PCI compliance?
Answer: Yes, to date, PCI DSS v3.2 contains the latest requirements, testing procedure and guidance for each requirement. Download it by visiting the PCI Security Council's library.
Question: What does AOC stand for?
Answer: AOC stands for Attestation of Compliance. The PCI Glossary of Terms is linked here and is a very helpful resource for similar questions.
Question: eProcurement platforms, the platform encrypts PCard data with the purchase order transmission via their network sent to the supplier, but does not encrypt the expiration date. I have two questions: I understand that both PCI combined with federal FACTA, the expiration date must also be masked. Who is responsible to ensure that the supplier receiving the PO is PCI DSS/FACTA compliant? Us or the eProcurement platform? The supplier would be the merchant to whom we are paying via card - it is our card.
Answer: Our understanding from Visa in past years is that PCards are not in-scope for the entity that has issued them, but they are in-scope for the merchants where the credit cards are used. From a security perspective, it is a good idea to protect these cards the same as consumer credit cards, but from a compliance perspective, it is likely not required. The PCI SSC has an old Frequently Asked Question on this topic from 2009 that states that one should confirm this with the payment brand. Check it out here for more information.
Question: If an email system is cloud based such as Gmail or Office365, how would you make it PCI compliant
Answer: If your email system is being used to store, process or transmit cardholder data, then it is in-scope for compliance. If it is outsourced to a third-party service provider, like Google or Microsoft, who is hosting and managing that cloud infrastructure then that organization is a PCI Service Provider to the organization. There are two ways to deal with third party service providers, as explained on page 12 of the PCI DSS:
As far as we know, neither Google nor Microsoft have PCI Compliant cloud email offerings at this time.
Question: We have customers who regularly email us credit card information in non-encrypted emails. How does this impact us?
Answer: This brings your email system and any connected systems into scope for compliance. We highly recommend that this business process be changed since the email messages are not encrypted (which would be required if it were to continue) and since it is very difficult if not impossible to reduce your scope with your email system in-scope for compliance.
If this business process can be changed, and this still occurred from time to time, you would then see this as an unintended channel for receiving cardholder data and need to do the following:
The PCI SSC has a Frequently Asked Question article on dealing with accidentally receiving cardholder data through an unintended channel that goes into a bit more detail as well. Check it out here.
Question: If your third-party providers have a SOC 1 or SSAE 16 Report, does this minimize your requirements
Answer: No, the only documentation recognized for PCI DSS validation are the official documents from the PCI SSC website. The PCI SSC has a Frequently Asked Question article on this topic. You can view it here.
Question: At what point should your company have an ISA? We are currently using tokenization and P2PE with CardConnect.
Answer: First we should explain the difference between an ISA and QSA.
QSA is the acronym for ‘Qualified Security Assessor’. QSAs are qualified by PCI SSC to perform PCI DSS onsite assessments for any merchant or service provider.
ISA is the acronym for ‘Internal Security Assessor’. ISAs are qualified by the PCI SSC to perform PCI DSS assessments for their own company. The company also needs to be certified as an ISA company.
Validation of PCI DSS Compliance is based on annual credit card transactions volumes that determine an organization's merchant or service provider level. These levels and validation requirements are defined and maintained by the card brands. Links to the security and compliance resources of each card brand can be found here:
To determine if an organization can validate compliance with an ISA rather than a QSA, they should ask their acquiring bank, as they are the entities responsible for ensuring their merchants are compliant and what compliance validation paperwork they require.
Question: Some of our customers send in their CC details through phone. How do we ensure PCI compliance in this situation?
Answer: There is not one single way to ensure compliance for this one credit card acceptance channel. The organization needs to look at the entire channel to determine all of the system components that would need to come into scope for compliance and then address all applicable requirements for all in-scope components to meet PCI DSS compliance. Please keep in mind with all types of credit card acceptance channels, the organization can and should always consider scope reduction techniques.
When it comes to reducing the scope of PCI DSS compliance, organizations have several options that should be considered. These options are not mutually exclusive and can be combined to address PCI DSS compliance obligations and/or reduce the environment that the PCI DSS requirements apply to. All credit card acceptance channels need to be considered when reducing scope. Currently, organizations that have PCI DSS compliance obligations can reduce scope in the following ways: