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.


3 Responses to “Non-Compliant ROCs”

  1. 1 Visitor
    March 26, 2013 at 6:16 PM

    Hi there,

    I have a question regarding the reporting requirements for non-compliant RoCs and what is acceptable by the council.

    What I’d like to know is if the RoC reporting instructions need to be followed for the not in place requirements?

    From my own research and after speaking to a number of QSAs, there seem to be two approaches that are being taken to document non-compliant RoCs.

    Approach 1:

    For requirement which are not in place, only document how we ascertained that the control was not in place, but are not going to follow every testing procedure of the reporting guidelines (e.g. conducting interviews AND observing documentation AND checking configurations) for that same control. This on the basis that once we gather evidence that a control is not in place, there is little to no value in following the rest of the testing procedure for that same control.

    Consider the following example:

    Say for a requirement X , we need to sample a number of systems and then check the system configuration, interview administrators and review documentation to ascertain whether the control is in place.

    After interviews with the administrators we determine that there is no documentation available and that the procedure is not being performed.

    In such a case we would not need to go and sample systems, to then check the configurations.

    We would therefore record the following in the not in-place column:
    ” Verified through interviews with John Doe, System Administrator, that xyz process/procedure is not being currently performed. Also verified, through interviews with the Security Manager, Jane Doe, that no policy and/or documentation was maintained. No system components were therefore sampled as THE CUSTOMER was found to be non-compliant for the reasons stated above.”

    Approach 2:

    This approach is to simply follow all the reporting instructions for both, the in place and not in place controls.

    I personally am in favour of Approach 1 as this can save you precious time that you can then use to provide the customer with further guidance and help them build a ‘roadmap to compliance’, etc (better value for money for the customer). However, I’m not sure if this approach is acceptable by the council.

    I am just look for your opinion on the matter and understand that this should not be mistaken as the council’s approach.

    Thank you in advance.

  2. 2 derra
    February 7, 2010 at 3:23 AM

    Make sure that you bundle the original+new update for the “next years assessment” that you do 1 year from the original and not from the new updated one.

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


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.


February 2010
« Jan   Mar »

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

Join 1,941 other followers


%d bloggers like this: