I Wonder If My Card Issuer Has A ROC?

A 403 Labs QSA, PCI Columnist Walt Conway has worked in payments and technology for more than 30 years, 10 of them with Visa.

The PCI Council's Frequently Asked Questions (FAQ) #5391 states that "PCI-DSS applies to any entity that stores, processes or transmits cardholder data and any such entity is expected to comply with PCI-DSS, including issuers." Because that is the case, I wonder if my card issuer has validated its compliance with a Report on Compliance (ROC) prepared by a QSA. In addition to being retailers or service providers, everyone reading this column is a cardholder, so we all have a stake in this issue.

That FAQ continues: "At their discretion, payment card brands may require issuers to validate PCI-DSS compliance." This part makes me wonder how I can find out if my issuer is compliant, because I don't see any list of PCI-assessed issuers on the card brands' Web sites.

Let me make it clear: I do not believe card issuers should be ordered to validate PCI compliance. Rather, I believe issuers should voluntarily validate their compliance. And they should do it for three reasons: It is smart; it probably won't be that difficult; and, most importantly, it is the right thing to do.

I also want to be fair to issuers. The cardholder data belongs to them (or at least to their cardholders). They do not force retailers to retain the data, so issuers are well within their rights to demand retailers protect cardholder data if they keep data that doesn't belong to them.

The question is, because issuers demand retailers and service providers be PCI compliant, should they not practice the same discipline, go through the same process and lead the way by complying with the same guidelines to protect cardholder data? Let's look at each of the three reasons I think issuers should want to ensure they are PCI compliant.

Complying with PCI is smart because it can reduce issuer fraud losses. My monthly card statement displays my primary account number (PAN) prominently on the top of the page. On each subsequent page, the full PAN is in the header even when there are no transactions on that page. The tear-off payment slip has the PAN as well, and my issuer even instructs me to write the PAN on my check (fat chance).

My card issuer has exposed my PAN, expiry date, statement date and address to anyone who steals my incoming mail, intercepts my return payment or goes through my recycling (I live in California, after all) if I don't shred the blank last page. If my card is compromised, I imagine the issuer will have to eat that fraud. Plus, my PAN now is worth more on the black market because it comes with the additional billing information.

PCI Requirement 3.3 says to mask the PAN when it is displayed, which in the issuer's case would seem to include cardholder statements. Maybe as a cardholder I should not worry because I have, effectively, zero liability for my credit card. Nevertheless, I am going to be seriously inconvenienced if my PAN is compromised. And besides, I really don't need to have my full PAN printed on the statement. The card is in my wallet. The last four digits will do nicely. PCI Requirement 4.2 says not to send an unencrypted PAN "via end-user messaging technologies." Unfortunately, many issuers ignore this requirement, too.

I have clients who receive E-mails and faxes from issuers (and acquirers, too!) with clear-text PANs as part of the dispute resolution process. Many issuers transmit bulk PANs as part of their purchasing card and corporate travel card reporting. The recipients tell me they are frustrated because Requirement 4.2 binds them, but the issuer seems to be able to ignore PCI while potentially expanding the recipient's PCI scope. This sense of unfairness carries over and informs their view of PCI in general, and that is unfortunate.

A second reason issuers should validate their PCI compliance is because it may not be that hard. Issuers already have some very serious security requirements that go a long way toward meeting or exceeding what is required by PCI. My guess is that they could validate without too much bother. Some cost would be necessary to re-format cardholder statements. Plus, meeting Requirement 7 (restricting access to cardholder data based on business need-to-know) will mean additional documentation, given the number of people involved in resolving disputes and questions. Similarly, issuers would need to pass vulnerability scans and penetration tests (Requirement 11).

Possibly the biggest challenge will be with the issuers' Web sites. As a cardholder, I want to know that my issuer complies at least with Requirements 6.5 and 6.6, so my information is protected. Seeing the little lock in the corner of my browser is nice, but I really would feel better knowing the Web site was both developed securely and protected by either a code review or a Web-application firewall.

Lastly, issuers should have a ROC because, well, it is the right thing to do. I don't see any headlines about card issuers being hacked or suffering a data breach. Nevertheless, it seems only fair that if issuers demand PCI compliance from retailers, they should follow the same practices. The best leaders I know all lead by example.

Sometimes I find myself wishing PCI were more like an exercise class. In an aerobics or spinning class, the instructor asks you to do some difficult things. But she is right there doing the same exercises with you. Wouldn't it be great if the card issuers who developed PCI-DSS also went through the same exercise and validated themselves as compliant just like retailers have to do?

This simple act would add more credibility to the Standards and the PCI Council than any fine, penalty or press release I can imagine. Even a self-assessment would be a positive step. And as a compliant issuer, they may even gain a competitive advantage by demonstrating to their cardholders that they value the relationship and will do everything to protect their cardholders' financial information.

What do you think? I'd like to hear your thoughts. Either leave a comment or E-mail me at [email protected].