Wednesday, August 27, 2014

Announcing: The 2015 PCI DSS Workshop

PCI DSS Workshop 2015
April 20 - 22, 2015  
(Dates corrected)
Green Valley Ranch Resort, Spa and Casino
Henderson, NV (Las Vegas metro area)
The Treasury Institute for Higher Education is facilitating its annual PCI DSS Workshop. This program is geared toward business, financial, or IT manager responsible for PCI-DSS. The workshop will once again explore the unique PCI compliance challenges facing Higher Education institutions. As well as offer a deeper understanding of PCI, how institutions can achieve and maintain compliance, and the opportunity to make valuable new contacts with peers at other institutions facing the same challenges.

Please note that attendance at this program is
limited to representatives from colleges and universities only.

Tuesday, August 12, 2014

Higher Ed PCI Listserv

If you are a subscriber to the Payment Card Industry Compliance Discussion listserv, please be aware that there will be a change to the list address coming this week. You should see an announcement from the list in your Inbox soon.

You may need to change your anti-spam filters to keep the messages coming without interruption.


Wednesday, August 6, 2014

Who Should Drive PCI DSS Compliance?

[This is our second guest post from Joe Tinucci, Assistant Treasurer of the University of Colorado. --gaw]

Whenever I talk to my colleagues around the country about who in their organization is responsible for managing PCI DSS compliance, I usually get two different answers -- either the technical security side of the organization or the business side.  Of course, the merchant is the responsible entity as far as the acquiring bank or the payment card associations are concerned but when there are multiple merchants in the organization there needs to be someone coordinating / managing the compliance effort.  So, who is in a better position to drive / manage the compliance effort?  (Or, as we say around here, who is responsible for herding the cats?)

There are good arguments for letting the technical security people drive the process:

  • They are closer to the actual technology used to process transactions at the merchant level.
  • They understand the security techniques used to secure the transactions (blinking lights and all).
  • They control the infrastructure through which transactions are processed (network, firewalls, phone lines, PCs, and so forth) -- or they have direct links to the people who control it.
  • They understand the techno-speak language in which the PCI DSS / PA-DSS is written, and, in particular, understand the objectives behind each of the standard's requirements.
  • PCI DSS compliance is a security thing and that is what they are paid to do.

You can probably add other reasons why PCI DSS compliance belongs on the technical side.

On the other hand, I feel that there are good arguments for making the business side of the house responsible for driving PCI DSS compliance:

  • They control the money, including funding for those parts of the security process that might need outsourcing (penetration testing, ASV scans, QSA assistance, and so forth).  And, in the event that remediation is required, they are generally the ones who have to figure out where to find the money, often on an emergency basis.
  • They already deal with multiple other compliance regimes in a lot of other areas; that experience can be directly applied to the PCI DSS compliance process.
  • The business side of the organization is already doing risk assessments in other areas and so can assist with the critical but non-technical aspects of PCI DSS risk assessments (in areas such as phishing, social engineering, broken processes, etc.).
  • They are already managing business risk trade-offs in other areas of the organization (particularly in treasury) and can apply that expertise to PCI DSS compliance -- particularly with respect to accepting risk or implementing compensating controls.
  • Treasury, in particular, speaks that really strange language that only bankers speak (ACH? settlement? OFAC? credits and debits?) and they manage the organization's relationship with the Acquiring Bank.  It is really that relationship that is driving the organization’s PCI DSS compliance efforts.  In addition, if a merchant account needs to be cut off, it is the business side that needs to work with the Acquirer to close out the merchant account.
  • They understand the larger context of the business and how all the moving parts, including payment acceptance, fit together.
  • They understand good business practices and procedures that should be in place in every merchant environment.

It is this last point that really convinces me that the business side (most likely Treasury) should be driving the compliance process.  God bless the technical security staff but they will secure whatever they are asked to secure -- including horrible business practices that should never have been allowed in the first place.

In reality, of course, neither side can have a successful compliance process without the other; it is a complex dance between partners with the goal of making each and every merchant secure through both best business practices and best technical security implementations.

Your thoughts on the issue?

Joe Tinucci is the Assistant Treasurer at the University of Colorado, where he manages the University's banking relationships.  As part of that job, he also drives the PCI DSS compliance process for approximately 160 card-accepting merchants across diverse card-acceptance environments in four campuses.  Joe can be reached at (303) 837-2185 or