This is the third of a six-part blog series about PCI compliance.
Last week, we discussed how to determine and minimize the scope of PCI compliance. This week, we’ll review and explain PCI validation and reporting requirements. And, you can always refer to part one of the series for a glossary of PCI-related terms.
First, you should know that each payment brand (for example, Visa or MasterCard) sets and has its own specific PCI validation and reporting requirements. For your business, your specific validation and reporting requirements are tied to your “merchant level,” which is determined by your merchant bank and is largely based on transaction volume.
The two primary types of PCI compliance validation reports are an annual on-site assessment performed by a Qualified Security Assessor (QSA) and documented in a Report on Compliance – a ROC – or an annual self-assessment performed by the merchant and documented in a Self-Assessment Questionnaire – an SAQ.
So, what’s the difference between a ROC and an SAQ, and who needs to complete them?
ROC: Report on Compliance
ROCs record the results of an on-site PCI DSS assessment and are most often required for “Level 1” merchants. A Level 1 merchant typically processes a large volume of credit card transactions (at least several million annually). Each payment brand has different guidelines for determining merchant levels, but if one payment brand has deemed you are Level 1, others will likely regard you as Level 1 as well.
Refer to all the major payment brands (Visa, MasterCard, American Express, Discover, and JCB) to learn how they determine the merchant level and to review their validation and reporting requirements.
SAQ: Self-Assessment Questionnaire
Not all merchants are in the Level 1 tier, thus, not all merchants need to undergo on-site PCI DSS assessments, with the results recorded in a ROC. For other merchants in Level 2, 3, and 4 tiers, SAQs exists as an additional PCI compliance validation tool that businesses can complete on their own and provide to their bank.
There are several different SAQs, tailored for the different types of payment-card-processing environments typically used by Level 2, 3, and 4 merchants. For example, there are separate SAQs for card-not-present merchants (e.g., e-commerce) who have fully outsourced all cardholder data functions, or for merchants who only use imprint machines or have standalone, dial-out credit card terminals.
While every merchant must comply with all of the applicable PCI DSS requirements to fulfill compliance, the different SAQs have been tailored to include only those requirements applicable to the particular environment defined for that SAQ. Some SAQs only include a portion of the full PCI DSS requirements, while SAQ “D” includes all of the PCI DSS requirements.
Determining Which SAQ to Use
Your merchant bank will always be able to tell you which path to take for your business. Whichever SAQ your bank tells you to use, you should work on completing it. However, when completing the SAQ, if you identify PCI DSS requirements applicable to your environment, but they’re not covered in the SAQ you are using, you might not be using the right report for your environment.
The PCI SSC also provides helpful resources, such as the chart on the last page of the PCI DSS SAQ Instructions and Guidelines, to help you determine which SAQ is right for you.
What Carson & SAINT Can Do for You
It’s critical that your business fulfills its annual PCI reporting requirements; to guarantee your reports are completed timely and properly, it makes business sense to partner with an industry expert. Carson Inc. has completed the PCI Security Standards Council QSA qualification process and can provide PCI assessments in accordance with the PCI DSS. With this qualification, Carson Inc. is poised to help your company manage data security risks, evaluate the security of your systems, and ensure total compliance. We’ll prepare the documentation required by the major payment brands and help your organization meet the specific reporting requirements for PCI DSS compliance.
0 Comments