06
Sep
09

Reliance On Other QSA’s Work

This is an issue that is an under discussed problem that I believe needs to be clarified by the PCI SSC before we all get into some real trouble.

The amount of outsourcing and use of third parties to perform critical business functions is extremely high, such that there are very few organizations these days that perform all of their business functions in-house.  Whether it is the outsourcing of support and maintenance of servers and networks, to contracted call centers, there are all sorts of outside organizations that will manage and take care of non-core competency business functions.  Unfortunately, a lot of these third parties end up in-scope for PCI compliance because of the fact that they come into contact with cardholder data in some form.  For a lot of these third parties, the fact that they are in-scope for PCI compliance will come as a surprise.  As a result, these third parties will have to either endure PCI assessment after assessment or have their own PCI ROC created.

So, what is the problem with these third party PCI ROCs?  There are no rules governing how to use them, when to use them, and if to use them.  As a result, some QSAs will not accept them, some QSAs will accept them, but with conditions, and some QSAs blindly trust them without any sort of scrutiny.  I would like to put forth some suggestions I have for rules regarding third parties and their PCI compliance reporting requirements.

The biggest problem we have to resolve, in my opinion, is with the ROC process itself.  ROCs are a view of an organization’s compliance with the PCI DSS as of a point in time – as of the ROC’s reporting date.  This is troublesome because other reports on an organization’s control environment, such as those reports created for Sarbanes Oxley (SOX) or a Statement on Auditing Standards (SAS) 70, cover a given period of time, typically 12 months.  As a result, there is a question of how does a QSA rely on a report that only gives assurance as of a particular date when the QSA needs assurance as of a date further down the road?  In the long term, I would suggest that the PCI SSC needs to make the ROC assessment process a review of controls over a period of time, preferably a 12 month time period.  In the near term, I would like to suggest that a third party’s ROC report be used to determine the level of additional testing that needs to be performed to give the QSA a level of understanding and comfort that the third party is truly in compliance with the PCI DSS.  In addition, if the ROC is dated more than six months earlier than the organization’s ROC reporting date, the level of testing should be higher than if the report is less than three months old.

The next problem with this situation is that a QSA has the option to not accept a ROC as evidence of an organization’s compliance with the PCI DSS.  I would suggest that while this option still is available, that a QSA needs to document in detail why they chose not to accept the ROC report rather than just allow them to blindly say that they did not accept it.  That said a QSA should also not just blindly trust a ROC either.  A QSA needs to determine how much additional testing to conduct to ensure that the third party is still in compliance.  That testing needs to be tempered by the age of the ROC (the older the more testing should be performed), the services covered by the ROC (if a service is not covered, it needs to be assessed accordingly), and the sampling discussion in the Executive Summary (determination of whether or not the third party’s QSA did the necessary testing).  Use of any third party’s ROC should be documented in the Executive Summary so that all reviewers understand that there was reliance on another QSA’s work.

Of course, all of this is predicated on the fact that all third parties will issue a ROC prepared by a QSA for all their services used by their PCI compliance customers.  I would suggest a ROC be the only acceptable report for a number of reasons.  Since the third party will not necessarily know which of their customers are considered a Level 1 merchant or service provider and which are some other level, a ROC just makes sense.  A Self Assessment Questionnaire (SAQ) is not acceptable because it does not have the same level of detail needed to respond to the testing required in the ROC.  It is possible to summarize from a ROC to an SAQ, but almost impossible to go from an SAQ to a ROC’s level of detail without going back to the third party for additional information and clarification.  The purpose of this process is, after all, to minimize the impact on the third party by all of its customers that are conducting their own PCI compliance process.

Finally, there is the issue of the age of a third party’s ROC.  Obviously, if the ROC is more than 12 months old, there are going to be concerns about the relevance of the report to your assessment.  This is also a problem with SOX and SAS 70 reports.  As a result, there are already possible solutions to this situation.  Auditors that produce the SOX and SAS 70 reports can issue an interim letter regarding the status of the organization’s compliance.  This process could be used for ROCs that have not yet been accepted by the card brands.  Such a letter would document any potential compliance issues with the ROC by requirement so that your organization’s ROC can take into account any compliance issues with the third party.

There needs to be much more discussion about this issue amongst the QSAs, Participating Organizations, PCI SSC and the card brands.  However, until those discussions occur, I would like to suggest that in the interim we operate from my suggestions.

Advertisements

3 Responses to “Reliance On Other QSA’s Work”


  1. September 30, 2009 at 6:10 PM

    Your site was extremely interesting, especially since I was searching for thoughts on this subject last Thursday.

  2. September 8, 2009 at 9:49 AM

    Our experience has been mixed as well and I could not agree with you more. The PCI SSC has generally ignored IT service providers. Appendix A is inadequate to deal with the highly variable services available from third parties. We really need an entire supplement to provide guidance around both the acceptance of third party ROCs and the corresponding liability chain. The liability issue is what will actually drive the auditing practice. Third party ROCs will become very popular if it moves the liability to the third party assessor.

    If there is a breach in a system supported by a third party ROC, where does the liability rest?

    With more states making PCI DSS compliance into law, the stakes could get very high for a third party IT service provider with many PCI DSS compliant clients relying on their ROC.

    Right now the QSAs are taking on the liability even when a third party ROC is in play, which is why there is such a variance in how IT service providers are being treated. Ironically, it is the larger shops that are more accepting of third party ROCs and the smaller shops that do not. Maybe it is easier for a QSA with a large organization behind them to handle the liability.

    Ed Welsh
    Director Security
    http://www.gsihosting.com


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

September 2009
M T W T F S S
« Aug   Oct »
 123456
78910111213
14151617181920
21222324252627
282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,883 other followers


%d bloggers like this: