Removing The Drama Of A PCI DSS Assessment

I had to prepare a presentation for a client a while back giving them some tips on how to prepare and get through a PCI assessment as easy as possible.  I thought it might be good to share those thoughts.

Trust But Verify

This famous quote from US President Ronald Reagan is the mantra of a PCI assessment.

The PCI DSS is based on the “trust” that organizations are complying with the PCI DSS.  However self-assessment processes and QSAs are used to “verify” that the organization is, in fact, complying with the PCI DSS.  As a result, the organization being assessed not only has to produce documentation to that effect, but the QSA must also observe that the PCI DSS requirements are being followed.

The net is that, just because you say something is fact, your QSA must substantiate your statements so that they, too, will treat them as fact.  If you remember nothing else but this simple truth, you will understand why a QSA must do what they do.

Scope

If PCI assessments go wrong for any reason, this is probably the primary reason.  It fascinates me that people often profess ignorance of the PCI DSS, yet somehow become experts on the subject when it comes to scoping.

Remember point number one, trust but verify.  Under that premise, the PCI SSC makes a QSA’s primary responsibility to confirm the scope of the PCI assessment as they verify the facts.  As a result, in order to confirm that scope, the QSA must look at everything and then, through investigation and evaluation, determine that the areas you deem out of scope are, in fact, truly out of scope.

Let your QSA ask their questions and conduct their observations without arguing with them about scope.  They are only doing this because they are required to confirm the facts and your fighting with them about scope is only going to making them wonder what you are trying to hide.  The bottom line is that arguing with your QSA about scope only makes your assessment all the more painful and time consuming.

If you truly want to avoid arguing over scoping, get a copy of the Open Source PCI Scoping Toolkit.  Go through your environment and determine the categories of all of your systems and networks.  This is a good annual exercise because you need to prove your scope every year.

Applicability

According to the PCI SSC, there are five PCI DSS requirements that can never, ever be marked as ‘Not Applicable’: 1.2.3, 3.2.1, 3.2.2, 3.2.3 and 11.1.  I have discussed these all before but they deserve another quick discussion here.

Clients will argue ad nauseam that wireless is not implemented or is out of scope and therefore refuse to discuss wireless.  For requirement 1.2.3, a QSA is required to document the procedures they followed to rule wireless in or out of scope.  That of course means the QSA must investigate any wireless networks and evaluate if the controls are rigorous enough to keep wireless out of scope.  For requirement 11.1, the QSA must investigate and evaluate if the organization’s controls surrounding the detection of rogue wireless are appropriate regardless of whether or not the organization has implemented wireless networking.

3.2.1, 3.2.2 and 3.2.3 are all related to the securing of cardholder data when it is stored.  Even if an organization is not storing cardholder data on their systems, a QSA must document the procedures they used to confirm that cardholder data is not stored on the organization’s systems.  This usually involves a review of flat files and database schemas and the running of utilities and queries against those systems and databases looking for cardholder data.

The bottom line is do not argue about something being ‘Not Applicable’ and then hinder the QSA’s investigation to prove it is ‘Not Applicable’.  Do not get me wrong, you need to keep your QSA on point, but remember that QSAs are required to evaluate the situation and then document the process used to determine that a particular requirement is ‘Not Applicable’.  All you do by complicating that investigation is add more time to your assessment and, potentially, cause a requirement to be marked as ‘Not In Place’ instead of ‘Not Applicable’.

Yes, I Did Kind Of Ask That Earlier

Like security, the PCI DSS also works from a ‘defense in depth’ approach.  A lot of the questions QSAs ask are very similar just asked from a different perspective.  The people that develop assessment and audit programs will tell you that this is the most effective way to uncover the level of compliance with a given program.  The reason is that organizations who have not integrated a compliance program into their day-to-day operations will typically provide inconsistent or confusing answers to the similar questions.  Not that this is a perfect technique mind you, but it does work the majority of the time.

Please be patient with your QSA.  They did not write these procedures, but they are required to execute them.

Answer The Question

Most people suck when being questioned, particularly in a legal proceeding, including yours truly.  Lawyers always instruct anyone that will be called to testify in a legal proceeding to take their time, focus on the question being asked and only answer the question being asked.  Never, ever, ever provide any information outside of the question, i.e., do not elaborate.  The trouble is that lawyers know that silence is a vacuum and it is human nature to fill that vacuum with extraneous information.  Hence why they typically have long pauses between questions.

QSAs and auditors tend to operate under the same principle as a lawyer.  People get into trouble when they start talking about things that are outside of the question, out of scope or not relevant to the assessment.  Such responses will at first confuse the QSA for a moment as they try to reconcile your remarks.  But then, the QSA may question whether they truly understand the environment and, possibly, the scope of the assessment.  It is then that they may start quizzing you and your staff as they go back and reconfirm their understanding of the environment.  All of this takes time, time away from the assessment process as you cover old ground while the QSA re-verifies the facts.

The lesson to be learned here is that there is nothing wrong with saying, “I do not know.”  Or “I will have to look into that question and get back to you.”  The worst thing you can do is try and “tap dance” around the question or never really answer the question.  If you do not have the answer, then find out who does have the answer and point the QSA to that person.

Prepare

And finally, the best thing you can do to avoid all of these issues is to walk through the PCI assessment process and requirements with those of your staff that will be interviewed/observed and make sure they understand the questions to be asked and how they should be answered.

If you really want to know what the QSA will ask, why they will ask and the evidence they will require, get a copy of the PCI DSS ROC Reporting Instructions from the PCI SSC Document Library.  The Reporting Instructions document is the “Bible” for QSAs as it documents how they will be assessed in a PCI SSC Quality Assurance review.  Reviewing and understanding this document will go a long way to minimizing the “What do you need that for?” questions that all QSAs encounter.

For each requirement’s tests, the Reporting Instructions will tell you:

• What observations, if any, need to be performed and documented.
• What documents, if any, need to be collected and reviewed and what information needs to be identified in those documents.
• What people, if any, need to be interviewed and about what topic(s).
• What processes, actions taken or states of equipment, if any, need to be observed and documented.
• Whether or not sampling can be used.

Using the Reporting Instructions, you can also gather a lot of the observations ahead of time.  Your QSA will still have to conduct some observations such as that default passwords are not used, that timeouts occur, that change management operates and the like.  But by gathering screen shots and documenting what you used as testing conditions will go a long way to making your assessment go much more smoothly and quickly.

Hopefully this discussion will help you get through your next PCI assessment without all of the associated drama that can come from such an exercise.

Advertisement

Can An ISA Sign Off On A ROC Or SAQ?

This question came up recently on one of the LinkedIn PCI groups and drove a lot of discussion.  However, one of the things that concerned me the most is that no one belonging to this group bothered to submit the question to the PCI SSC to be answered.

When such questions come up, the first thing you should do is go to the PCI SSC Web site’s FAQ page to see if the question has already been answered.  There is an amazing wealth of information contained in the FAQs.

If you search the FAQs and you do not come up with an answer to your questions, then submit your question to the PCI SSC.  Technically, anyone can submit a question to the PCI SSC.  However, if you are a QSA in a QSAC, the person listed in your QSAC listing should be the focal point and should submit all questions you have to the PCI SSC.

Questions are submitted to info@pcisecuritystandards.org.  Expect a few days to a few weeks to get a response.  Simple procedural questions such as whether an ISA can sign a ROC or SAQ like a QSA can get a response in a day or two.  Questions that require the PCI SSC to formulate a position, may take a number of weeks before a response is provided.

So, can an Internal Security Assessor (ISA) sign off on a Report On Compliance (ROC) or Self-Assessment Questionnaire (SAQ)?  The answer provided by Cathy Levie, Senior ISA Program Manager, PCI SSC, is as follows.

“The ISA can sign off as long as their Processor/Acquirer has approved of that. This is not up to the PCI SSC.”

In the future, if you have a question and cannot find an answer, ask the PCI SSC.  When you get your answer, please post the answer to any of the PCI groups on LinkedIn or send them to me so that the rest of the PCI world can benefit from the knowledge.  One of the unfortunate issues the PCI SSC has is that not all questions seem to make it into the FAQs or the FAQs are not updated as quickly.

The 2010 PCI Community Meeting

It is that time of the year.  Time for another get together with the PCI SSC, the card brands, participating organizations and QSAs.  This year’s meetings are in Orlando and Barcelona.  Unfortunately, I am not going to be in attendance due to scheduling conflicts.  Since I will not be able to attend, I thought I would provide a topic for discussion.  I want to get the PCI SSC to repeal their inane Report On Compliance (ROC) report writing standard.  This standard has become onerous and, in the end, has become “make do” work.

To understand this situation, you need a bit of history.  Until last year, the only proof that the PCI SSC and the acquiring banks had to prove a QSA had done their job properly was to read the ROC.  The ROC was required to contain references to all of the documentation, interviews and procedures they had observed to ensure that an organization was complying with the PCI DSS.  As a result, this caused the PCI SSC to develop an extensive grading and scoring spreadsheet that is used to determine if a ROC covers everything it is required to cover.  Each test may have any of the following components.

• Observation;
• Interview;
• Documentation;
• Process/action/state; and
• Network monitoring.

Each of these components may be assessed one to four scoring points depending on the number of occurrences that may be contained in the given test.    A ROC must score better than 75% in possible points to avoid remediation.  But the PCI SSC expects that a ROC should score no lower than 95% of possible points.

The PCI SSC has instructed QSAs that each test in the ROC must be able to stand on its own.  This means that one test is not allowed to reference another test.  As a result, QSAs must replicate of a lot of information throughout the report.  This obviously introduces the potential for errors and omissions in the report as well as making the report unnecessarily long.

To ensure the report writing process is truly questionable, the PCI SSC recommends that QSACs develop pre-written templates so that all of the components get covered for each test.  While a template speeds the report writing process, I would still estimate that the report writing process consumes at least one-third to one-half of a PCI assessment’s budget.  Not only does it take time to write, but it takes a lot of time to proof and to review.

As I stated earlier, last year, the PCI SSC began requiring language in all QSA contracts that grants the PCI SSC the right to examine any QSA’s work papers.  AS a result, one would think that this report writing standard would no longer be needed, but it is still in place.

Because a lot of our clients use hosting services, we get to see a lot of ROCs that have been prepared by other QSAs.  You can really tell those QSAs that have not been through the PCI SSC QA process by the fact that their ROCs are very short and lack detail.  But for those QSAs that have been through the QA process, based on my review of their ROCs, the grading scale seems to have caused QSAs to worry more about how the ROC is written and not necessarily on the actual assessment of the security practices of their client.  A lot of the writing is more about meeting the scoring template and not about the controls.  In some cases, the writing starts you to wonder if the control is really in place.

ROCs can become inordinately long because of the replication of the same information over and over.  During our QA remediation, we were told that the average ROC ran around 180 to 200 pages however I have yet to see one produced by us that is under 250 pages and we seem to average around 350 to 400 pages.  I have heard from some reviewers at acquiring banks that the only worthwhile information in these tomes is anything that is not in place and any compensating controls.  If that is all that is getting read, then what is the point of all of this other information that is being ignored?  The point is that it remains the way that the PCI SSC ensures that QSAs are doing their job.  And as I stated earlier if the writing makes you question if the control is in place, then what is the quality of all of this writing?

Now that the PCI SSC has the right to review a QSA’s work papers, there is no reason to require all of this pointless verbiage in the ROC.  QSAs should be able to have one column for each requirement in the report labeled ‘Status’ and the entry in the column is either ‘In Place’ or ‘Not In Place’.  If something is not in place, then the column next to it, labeled ‘Comments’, should document what is being done to bring a requirement into compliance and when that will occur.

If the PCI SSC is not comfortable with this approach, then maybe they have the wrong organizations as QSACs and they need to get rid of those that cannot conduct the work to professional standards.  This approach works for financial auditors, there is no reason it cannot work here.

Have a good time in Orlando or Barcelona.

Managed Networks And PCI Compliance

Here is a subject that keeps coming up, particularly with organizations that manage networks for merchants.  If I manage an organization’s network, is my organization in-scope for PCI compliance?  The answer is yes, the services you are providing are placing your organization and its relevant services in-scope.

The first response from the network management company is usually, “How can that be, all other telecom companies are out of scope, why not us?”  Quickly followed by, “No other QSA has ever asked us to go through this.”  Remember, the QSA is just the messenger.  Everything stated in this post is from the PCI DSS, the DSS Glossary and other PCI SSC and card brand publications.  This is what the PCI SSC is asking all QSAs to do as part of their PCI assessment work.  If you do not agree, talk to the PCI SSC as they are the only ones that can change the standards.

To answer, “How can that be, all other telecom companies are out of scope, why not us?”

It is very simple. Your organization is not providing just a circuit.  The PCI SSC has been very clear on this.  If all you are providing is a circuit and no other services, then you are out of scope.  The moment your service to a merchant or service provider goes beyond just providing a basic method of transport, you cross into PCI compliance territory.  Basically, the PCI SSC’s interpretation is that if the merchant or service provider has outsourced all or part of a role to your organization, it stands to reason that your organization has assumed that responsibility and, by default, also assumed the relevant PCI compliance responsibility.

But, what if the data is encrypted before it gets to our equipment?  As long as your organization does not have the ability to decrypt the data stream, then your services are out of scope.  However, if the cryptographic process involves your equipment or you manage cryptographic keys, then you are in-scope and must comply with the PCI DSS.

What are your compliance obligations?  Based on my analysis, your organization is involved or responsible for at least the following PCI DSS requirements; 1, 2, 4, 6, 7, 8, 9, 10 and 12.  Here is my high-level take on what you need to be prepared to document, discuss and/or prove you are doing.

• Provide policies, standards and procedures for device management.
• Provide policies, standards and procedures for physical and logical security.
• Provide a copy of your incident response plan.
• Provide access control definitions for groups and roles that manage the devices.
• Provide job descriptions for the personnel that manage the devices.
• Document all protocols/services that are used for managing the devices including a business reason for each of the protocols/services.
• Provide configurations of a sample of physical devices.  Sampling is allowed as long as the service provider can prove that it has implemented a standard process for managing the devices in question.
• Provide documentation that supports that device configurations are properly backed up and secured.
• Provide documentation that supports that device configurations that are running and those that are stored are one in the same.
• Verification that all relevant policies, standards and procedures are followed in configuring new devices.
• Verification that documented protocols/services are the only ones configured on the managed devices.
• Verification that security is properly implemented on all managed devices.
• Verification that appropriate access control systems are implemented on the managed devices.
• Verification that remote access is secure.
• Verification that all user accounts are appropriate managed and controlled.
• Verification that all logging is implemented and logs are reviewed at least daily.
• Verification that log information is properly secured.
• Verification that the time management is properly implemented on each device.
• Verification that some form of critical file monitoring is being performed.
• Verification that there is a formal change management process in place including testing.
• Verification that any cryptographic keys are properly managed and secured.
• Verification that all devices have been appropriately patched and that there is a patch management process in place.
• Verification that appropriate physical security controls are in place.
• Verification that logs are maintained for any backups stored off-site.
• Verification that alerts are responded to as documented in the incident response plan.

Now for the second comment, “No other QSA has ever asked us to go through this.”  If no other QSA has asked you to go through this, shame on them.  This is why the PCI SSC implemented its Quality Assurance program so that all QSAs start doing the same level of work.  This is also why there is such a variance in QSA costs.  We are finding that the QSAs that are the cheapest are the ones that are not being appropriately rigorous with their assessment of an organization against the PCI DSS.  As the PCI SSC takes more QSAs through the QA process and puts them through remediation, things will change and assessment costs will become more consistent.

Non-Compliant ROCs

There really is such a thing, but you rarely ever see or hear of one.  But unlike the Loch Ness Monster or Big Foot, they can and do exist.

There is no reason that an organization cannot file a Report On Compliance (ROC) that is not compliant.  The topic came up again because we have a client that is addressing some issues related to complying with v1.2 of the PCI DSS.  Their remediation efforts will not be done for another five or six months, but their PCI ROC needs to be filed in one month and they do not think they can put in place compensating controls to address the remaining issues.  As a result, there will be a couple of items on their PCI ROC that are in the dreaded ‘Not In Place’ column.

The first thing everyone needs to be aware is that there is nothing in the PCI DSS that says an organization must file a compliant PCI ROC.  It is just that filing a compliant PCI ROC makes for much less work for the acquiring bank and the merchant or service provider involved.  But there are those out there that believe that a merchant or service provider must file a complaint ROC and that is just false.

So, what happens if an organization files a non-compliant PCI ROC?

If an organization needs to file a non-compliant PCI ROC, then they need to be prepared for the additional scrutiny required by their acquiring bank and/or the card brands.  When a merchant or service provider files a non-compliant PCI ROC, the organization that receives the PCI ROC must initiate an effort to track the requirements that are Not In Place.  They need to periodically follow up on the Not In Place requirements and report the status of any Not In Place requirements to the card brands.  The term ‘periodically’ is left to the acquiring bank to determine.  But how often they follow up can be as little as quarterly and as often as weekly.  The most common timeframe seems to be monthly meetings, but your experience will likely vary.  This process is required to continue until all Not In Place requirements are deemed in place.

So, how does the acquiring bank determine that your organization’s Not In Place items are now In Place?  Well that is where things are not so well defined.  What is defined is that the merchant or service provider informs the acquiring bank or card brands during the follow up meeting/call that the Not In Place requirements are now In Place.  What is not well defined is what happens after being informed that requirements are no In Place.  Since there are no procedures documented in the PCI DSS, by the PCI SSC in an FAQ or by the card brands, what happens next varies from acquiring bank to acquiring bank.

In most cases, the acquiring bank requests the merchant or service provider to get their QSA to update the ROC by reflect the changes in the Not In Place requirements.  My Firm’s problem with this approach is that in updating the PCI ROC, we are only looking at those requirements that have been updated from Not In Place to In Place.  We are not re-conducting all of the testing in the PCI ROC.  As a result, we only update those requirements that have changed and we place a disclaimer in the PCI ROC that states what items were updated and when those updates occurred.  We do not update the date of the report as the entire report was not updated.

Our preferred approach is to issue a letter with an attachment that contains the individual requirements that are now In Place.  The letter documents the scope of the re-review and the approach taken to test the updated requirements.  This approach allows for the updating of the PCI ROC, but only those items that changed and does not alter the original PCI ROC that was issued.  In this way, anyone reviewing the original report and the update has a clear understanding of what changed and why.

MasterCard Takes A Giant Step Sideways

As you may recall, MasterCard International revised their Site Data Protection (SDP) program earlier this year to require Level 2 merchants to conduct an on-site assessment of PCI compliance, aka Report On Compliance (ROC).  On December 15, MasterCard released a bombshell on their Level 2 merchants by backing away from the ROC requirement.  However, this change overshadows some other significant changes that you need to be aware.

For most, the big news in the December 15 pronouncement was that, effective immediately, MasterCard has gone back to only requiring Level 2 merchants to fill out a Self-Assessment Questionnaire (SAQ) instead of a ROC.  This was somewhat anticipated after Visa did not change their merchant level reporting requirements accordingly.  Conducting a ROC is now optional.

The original move by MasterCard was to try and level the playing field since MasterCard typically has fewer transactions than Visa at most merchants.  MasterCard was trying to reduce their risk by getting their Level 2 merchants that would likely be Level 1 if the merchant’s Visa transactions were aggregated with their MasterCard transactions to do a ROC instead of an SAQ.

The biggest and probably the best news in my opinion is that, as of June 30, 2011, any Level 1 or Level 2 merchants that want to create their ROC or SAQ using their internal audit staff are now required to have those personnel attend PCI SSC training and become certified in the ROC or SAQ process.  As a QSA that has come into an organization a year or two after companies have conducted their own assessment and created their ROC, I can tell you that without training, internal auditors are not equipped to conduct such a project.  The biggest issue they have is that they do not interpret the PCI DSS correctly because they have not been given the insight that QSAs are given at training.  While this might be a potential threat to my livelihood, I applaud MasterCard for mandating this requirement.

However, there is a twist in the directive.  MasterCard states that if Level 2 merchants do not get their internal audit staffs trained and certified in approved PCI SSC programs, then their SAQ or ROC must be completed by a QSA.  So, while MasterCard backed away from the mandatory ROC for Level 2 merchants, Level 2 merchants either train their internal audit staffs or use a QSA.  So my livelihood may not be as adversely affected as I may have thought.

And finally, as of July 1, 2012, all merchants and service providers that use third party developed software can only use that software if it is PA-DSS compliant. Let us be clear, this is only relevant to third party developed software, not software that is developed in-house.  However, MasterCard seems to have created a potential issue depending on how they define ‘third party’.  I am assuming that MasterCard is referring to third parties such as Micros, Oracle, IBM and similar software vendors that sell point-of-sale (POS) solutions and not the hired consultant that creates an eCommerce Web site for the local donut shop.  However, this definition needs to be clarified by MasterCard so that we are all on the same page.

UPDATE: The PCI SSC’s Web site indicates that they will be offering training to basically anyone willing to pay for it.  The 2010 Training Schedule is supposed to be released on Friday, January 15.  So keep checking their Web site for the training schedule.

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.