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.

Advertisement