By Tim Cranny
Panoptic Security Inc.
Editor's Note: This series began Aug. 10, 2009, in issue 10:08:01 of The Green Sheet. All articles in the series are now archived online. To access them, search for "Digging into PCI" (without the quote marks) using the Fast Finder search engine located just below the GS logo on our home page, www.greensheet.com. A list of all 11 articles (Requirements 5 and 6 were addressed in one article) will appear.
This final installment of a multipart series drills down on the last of the 12 requirements of the Payment Card Industry (PCI) Data Security Standard (DSS). In this article, I will talk about what the issues are, what merchants need to do, and what their ISO, bank or processor can do to help them.
The idea behind Requirement 12 is simple: security is a continual, often complicated process, and there is no chance of getting it right if implemented in a disorganized, ad-hoc manner. Having clear, formal objectives (policies) and plans on how to get there (procedures) creates success.
Requirement 12 lays out the basic areas that a merchant's security policy should address and makes sure the right general framework of procedures is in place and the right roles and responsibilities are properly assigned.
This framework of policies and procedures provides coherency for all the other requirements. It forms the foundation of everything else because merchants need to know what is expected of them before they sit down to construct their policy framework. It lays out the general high-level objectives (the what), while the other 11 requirements flesh out the details and specifics (the how, where and when).
Requirement 12 is not concerned with the technical details inherent in other parts of PCI. This makes it less scary but also introduces the risk that merchants will think it is too abstract to matter. Ignoring its importance would be a mistake, however. "Wasting time" on policies and procedures is like a hunter "wasting time" aiming the rifle before firing or a carpenter "wasting time" measuring the wood before cutting.
Another challenge with Requirement 12 is its high-level approach, which takes merchants away from the comfort of specificity. The PCI DSS is unusual for a modern security standard in its level of detail; most of the time it removes the need for judgment calls by effectively leaning over the merchant's shoulder and saying, "Do this, then this, then this, and don't do that." This hand-holding goes away to some degree in Requirement 12, and merchants who don't know much about security can easily feel lost.
For this reason, Requirement 12 is one of those dangerous sections that can generate horrific (but often hidden) support costs for ISOs and other portfolio owners if approached with a low-cost, low-feature solution.
Unlike many other parts of PCI, you can't avoid Requirement 12, nor does it make much sense to even try. However, complying with Requirement 12 doesn't have to be complicated and time-consuming; merchants with simple and relatively low-risk environments can make their policy and procedure frameworks simple as well.
Merchants need to do the following:
The policy should not be technology-specific: it is more about what, not how.
A crisis is a bad time to start thinking about what your response ought to be. Clear, accessible guidelines should already exist for people to follow.
With all of these issues, merchants should recognize that it is better to actually put together a simple set of policies and procedures than never get around to creating the ultimate, most highly detailed version possible.
Merchants can't implement Requirement 12 by applying some hardware or software solution; they need expert assistance. ISOs can either provide this assistance directly or partner with someone who can.
The company providing this assistance must have the capability to craft merchant-customized security policies and other content-rich documents and help the merchant decide which parts of the requirement are relevant to the merchant's business.
ISOs that can provide this in-house or through partnership can turn PCI from an expense and inconvenience into a means of securing merchant loyalty.
I hope you have found the guidance provided in this series to be helpful. If you have questions about the issues I've addressed or suggestions for further areas of PCI compliance you would like me to delve into in the future, please do not hesitate to contact me.
Dr. Tim Cranny is an internationally recognized security and compliance expert and is Chief Executive Officer of Panoptic Security Inc. (www.panopticsecurity.com). He speaks and writes frequently for the national and international press on compliance and technology issues. Contact him at tim.cranny@panopticsecurity or 801-599 3454.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
