PCI DSS Compliance Advice for the Security Practitioner

the background

The implementation of a PCI DSS compliance program can seem like a no-brainer to the Seasoned Security Person™ who's been saddled with (or taken on!) such a challenge. That may very well be the case, but there are some caveats which have little to do with the technical aspects of security. I hope the below will serve to save someone the (ahem) "novelty of discovery".

Note that this list will change over time as my experience with DSS compliance programs evolves.

the starting premises

You are an IT person participating in a payment card merchant's PCI DSS compliance program.
This merchant is eligible for self-assessment.
You (think you) know what you're doing already. ;-)
These are my personal opinions and do not detail any employer's or client's Official Stance on any of the matters discussed herein.
None of this should be construed as legal advice, as I am not a lawyer.
You assume any and all risk/liability for your use of this advice. Reading this advice does not make you my client. Signing a contract and paying me money makes you my client. :-)

the bullet list

If you don't already draw a distinction between "security" (protecting the data) and "compliance" (following the rules), you might want to meditate on that for a moment. You will achieve quite a bit of the former as a result of your compliance efforts, but your contract for accepting credit cards obliges you to the latter.
Committing to a PCI DSS compliance program is basically committing to a rigid regimen of best security practices. On the face of it, this may seem great, but if you're an experienced infosec pro expecting some latitude to interpret the requirements to suit your company's culture, procedures, and workflows, you'll need to get seriously creative...or gird for continuous, institutionalized disappointment. You may be tempted to seek comfort in the Compensating Control; I'm led to believe this is fraught with peril and should not be relied-upon.
The PCI DSS is a set of prescriptions for addressing business risk. Don't let the technical nature of many of those prescriptions fool your Expectation-Havers and Purse-String-Holders into thinking that compliance is an IT matter. A PCI DSS compliance program should be owned and driven by someone with an understanding of– and the authority to compel changes to business practices and workflows, with IT doing their bidding. (Technical changes you make as an IT person will be grudgingly tolerated. The moment you start telling, e.g., the finance people they've gotta lock their fax machine in a closet and clean that closet themselves because the custodial staff can no longer have access; and, oh, by the way, the administrative assistant needs to shred phone orders immediately; no, not after he finishes his lunch, right now; etc., you're likely to find yourself on the receiving end of The Look, if not worse.)
This thing is a serious exercise in Teaching to the Test. Your acquiring bank is responsible for enforcing DSS compliance, but your QSA* is Your Personal Inquisitor: if you have a choice, find one whose opinions you respect and with whom you can argue in a friendly fashion (i.e., not someone resembling this auditor) and make sure the acquiring bank approves. A QSA's interpretation is the one that matters, where the interpretation of requirements is under debate. The same applies, to a lesser extent, to your ASV (provided you have a choice).
* If your organization is a self-assessment-eligible merchant, you don't need a QSA (strictly speaking), but it can be helpful to know what the "right" answer at times when the way is not well-lit.
Don't let your Expectation-Havers develop the expectation that you'll be able to "set it and forget it". This is a marathon, not a sprint. Scratch that: It's a lifestyle. There have been continuous monitoring/maintenance requirements in at least the last three releases of the DSS. The SSC seems to have realized that merchants were sprucing things up and "checking the boxes" once per year, then returning to Business As Usual for the rest of the time. Again, best security practices may have long indicated the folly of this choice, but compliance rules now demand consistent adherence.
Further to the "set it and forget it" mindset: Be aware that the DSS has a three-year life cycle. Requirements will evolve.
As far as I can tell, to expect this process to be run by a committee (of stakeholders) is to elect the Path of Pain. Stakeholders must necessarily have a voice, but you might be able to balance that with actually accomplishing something if the committee is led by someone — a unitary, fair-minded, business-oriented someone invested with the authority (and budget) to issue edicts that begin with, "Thou shalt..." (It helps if this person is one of the aforementioned Purse-String-Holders. Also, this is somewhat theoretical, as my principal PCI engagement only operated under this model for the first ~year of our compliance effort — during which there was Rapid Progress — and has since been relegated to...designing camels.) We'll file this under "Executive Buy-in".
Again, as far as I can tell: The first round is the toughest. After that, maintaining compliance should be a matter of minor course corrections (for people/processes/systems that have fallen off the wagon) and incremental changes (to accommodate the evolution of the standard).

in conclusion...

So, there you have it. Your technical chops may be top-notch, but unless you consider the non-technical aspects of such a compliance program (buy-in, funding, governance), you're likely to find yourself in the weeds. Symptoms include, but are not limited to: elevated blood pressure, rash, spirit voices demanding that you do unspeakable things, sleep-writing letters of resignation, etc.

—grimm