Problem solve Get help with specific problems with your technologies, process and projects.

Using a QSA to write up a PCI DSS report on compliance (ROC)

Depending on your enterprise, it may or may not be necessary to utilize a QSA. In this security management expert response, learn how to determine your enterprise's level of compliance, whether to utilize a QSA and where to submit the necessary forms.

Would QSAs normally write up a PCI DSS report on compliance (ROC) and submit it to all issuing card brands? If...

not, to whom does the ROC get submitted? Also, if we do not utilize a QSA, what is the easiest procedure to complete the ROC and whom should we submit it to? Is there a standard ROC template? We are currently a Level 3 merchant.

Engaging a QSA and undergoing a formal PCI DSS assessment tends to be more applicable to Level 1 and 2 merchants. The requirements for Level 3 merchants are a bit different, in that a company is only required to self-certify its environment and conduct a quarterly scan.

Though I can't say that doing more rather than less security is a bad thing; if a company does undergo an assessment, the QSA needs to prepare a report on compliance (ROC), which is essentially an independent validation that the merchant is in compliance with PCI DSS. It is based upon the PCI Security Standards Council's standard template, which is available on its website. The merchant submits the ROC to the various payment processors. The QSA does not submit it to either the PCI Security Standards Council or the payment card brands: That's the responsibility of the merchant. In fact, not only should the ROC should be submitted, but also proof that quarterly scans are being conducted.

If the company chooses to self-assess, then it should fill out the "Self-Assessment Questionnaire" and submit that along with quarterly scan results to the merchant's payment processor. To make sure the merchant is in full compliance, it wouldn't hurt to build the entire ROC, though it's likely overkill for a Level 3 merchant.

More information:

This was last published in October 2008

Dig Deeper on IT security audits and audit frameworks