Annoying Requirements – 9.7.1

There are some requirements that just seem silly and appear to have no real purpose other than to be lightening rods for PCI DSS naysayers as why the PCI DSS is an inconsequential standard.  One of those requirements is 9.7.1 which states, “Classify the media so it can be identified as confidential.”

I think we all understand what the PCI SSC is getting at here.  They want to make sure that all removable media, in particular magnetic tape, is labeled as “classified” so that if any removable media goes missing, people that find any such media know that it is to be treated as confidential and not be released in the public domain.  This is predicated on the idea that people are basically honest and would obey such a labeling and would not investigate further.  However, the people that are the threat could really care less that the media is labeled confidential, that is why they want to get a hold of it.

Then there are the security experts that argue that by labeling something as ‘confidential’ all you are doing is further identifying the media as something that needs to be further examined by a person to see why it is confidential.  After years of conducting social engineering testing, I tend to agree with these experts.  Human nature just begs some people to find out why something is labeled ‘confidential’.  This is why leaving thumb drives or CD-ROMs in parking lots labeled ‘Customer List’ and sending out spam with links to the latest naughty celebrity interview, pictures or video still are very effective social engineering ploys.

The PCI DSS was created with numerous requirements that cover one another such that if one requirement is not performing completely, the other requirements will fill the gap.  In this case, there are a number of other requirements that cover 9.7.1 such as:

  • 3.1 – Keep cardholder data storage to a minimum.
  • 3.2.1 – Do not store the full contents of any track from the magnetic stripe
  • 3.2.2 – Do not store the card-verification code or value (three-digit or four-digit number printed on the front or back of a payment card) used to verify card-not-present transactions.
  • 3.2.3 – Do not store the personal identification number (PIN) or the encrypted PIN block.
  • 3.4 – Render the PAN, at a minimum, unreadable anywhere it is stored (including on portable digital media, backup media, in logs).
  • 9.5 – Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or back-up site, or a commercial storage facility and review the location’s security at least annually.
  • 9.6 – Physically secure all paper and electronic media that contain cardholder data.
  • 9.7.2 – Send the media by secured courier or other delivery method that can be accurately tracked.
  • 9.9 – Maintain strict control over the storage and accessibility of media that contains cardholder data.
  • 9.9.1 – Properly maintain inventory logs of all media and conduct media inventories at least annually.

Even if these other requirements are not met, just what does the PCI SSC and the card brands think a label is going to do?  It does nothing to improve security and ends up as “make do” work for some clerk to label all tapes, CD-ROMs, thumb drives, etc.  The epitome of those Dilbert cartoons from the 1990s that lambasted the ISO 9000 compliance craze.

To comply with this requirement, all I ask my clients to do is to declare all information, at a minimum, as confidential or whatever their second lowest data classification is called.  That way all employees know that, at a minimum, all information they come in contact with is confidential.  As such, they are not to share this information with anyone else unless there is a valid need to know that information for someone to complete their job.  But I do not require them to label removable media as ‘confidential’.

The message to the PCI SSC, get rid of this requirement.  It does nothing to improve anyone’s security.

8 Responses to “Annoying Requirements – 9.7.1”

  1. 1 roma
    November 29, 2016 at 12:24 PM

    If you’re not storing any PAN, does this apply? (Strictly for PCI purposes and not security)

    • December 1, 2016 at 7:40 AM

      No it does not and you would mark it as Not Applicable with the explanation that you do not store any cardholder data (CHD).

      • 3 roma
        December 1, 2016 at 10:01 AM

        This is good! I was told by other QSA’s that answering “Yes” is better than “N/A”. For example, yes we render PAN unreadable anywhere it is stored (even though we do not store PAN). Would love to get your thoughts on that?

      • December 2, 2016 at 6:57 AM

        If you do not store it, then it is ‘Not Applicable’ and the reason you give is that “[Organization Name] does not store PAN. The [QSA/ISA/whomever] reviewed [document name(s)], reviewed the data flows, sampled data base tables, [any other procedures used] and determined that the PAN was not stored.”

        I use Not Applicable all of the time when a requirement is not applicable. All you need to do is explain the process you followed to prove that it is not applicable. As long as that process is well documented, using not applicable is fine.

  2. 5 Jane Aube
    February 9, 2013 at 11:25 AM

    Hi, wondering how you handle the requirement 9.7.2 on College Campus’s. If a department on campus receives credit card data from a donor and that dept. does not process credit cards, how do you handle the transfer to another department on campus? Example: An athletic coach receives a note from a donor via US mail and it contains credit card data to make a gift; what is the appropriate vehicle to transfer this cc data to the Gift Processing Dept. or Cashier’s office?


    • February 9, 2013 at 1:19 PM

      Seal the letter in a secure, tamper-proof security envelope and then put it in an inter-office envelope and send it via the inter-office mail to the correct department.

      If you don’t think the people couriering the mail around campus can be trusted, then have anyone receiving such a letter contact the Finance Department or Cashier’s Office and they will schedule a time to come by and pick it up. The Finance Department or Cashier’s Office needs to tell who will pick up the letter and approximately what time they will pick it up. The department that received the letter needs to identify who will have the letter, their location and their telephone number. If you really want to use bet practices, their should be a log kept that lists the date and time the department was notified their was such a letter and who took the call. The date and time the letter was picked up and by whom and the date and time it was delivered at the department or office and who received the letter. Just make sure everyone understands that, until it is picked up, the letter needs to be stored securely.

      Regardless of what approach you take, make sure that everyone that might come into contact with such a letter is properly trained in the procedures for handling this process and that they understand their responsibilities for ensuring the security of the information.

  3. July 9, 2010 at 4:28 PM

    lol – Changing the label from “confidential” to “do not eat” would do more for security than the current requirement.

  4. June 10, 2010 at 10:00 AM

    Add 12.3 and its sub-requirements to this list. 12.3 evolved from managing modems and wireless access points to “any” user facing technology. The problem here is that the sub-requirements associated with 12.3 get into specifics which focus on a single technology(typically modems) and do not apply to others.

    The concept associated with 12.3 valid. Instruct users what is and is not acceptable to connect to the corporate infrastructure. This is typically located in an acceptable use statement. Given the changes in technology over a short time span , I can relate to the difficulty in writing this requirement. We now have cell phones that can do just about anything, including connecting to a network. USB thumb drives that can hold Gigabits of data and are no larger than a thumb nail, various “i” devices, blogs, instant messaging etc. Users also have access to remote access software which creates an outbound SSL tunnel to facilitate remote access(LogMeIn).

    12.3 is poorly written and seems to have become a dumping ground for vague requirements followed by specific details for a specific technologies. 12.3 should be broken up and/or rewritten to codify specific controls to address risks associated with user actions.
    For example, “Verify a corporate policy exists and is implemented to address(Prohibit!) employees from installing software or hardware which would create an external network connection bypassing corporate firewalls (ie: cellphones, wireless access points, modems, remote access software).

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 )

Google photo

You are commenting using your Google 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 )

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.


May 2010

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

Join 2,386 other followers

%d bloggers like this: