Clicky

Header graphic for print
InfoLawGroup privacy. security. technology. media. advertising. intellectual property.

FAQ on Washington State’s PCI Law

Posted in Payment Card Breach Laws

On March 22, 2010, Washington state became the third state to incorporate the Payment Card Industry Data Security Standard ("PCI") into law (the other two are Nevada and Minnesota). The Washington House and Senate have passed HB 1149 by substantial margins, and it has now been signed into law by the governor. HB 1149 amends Washington’s breach notice law (and borrows some of its definitions). Similar to Minnesota’s Plastic Card Security Act, HB 1149 provides issuing banks a legal mechanism to collect the costs to reissue payment cards after a payment card security breach. This blogpost summarizes HB 1149 in "FAQ" format and looks at its potential impact.

What is the overall stated purpose of HB 1149?

The introduction paragraph frames the purpose of the law in terms of protection consumers from identity theft due and fraud to data breaches of credit card data. To achieve this lofty goal, the law provides issuing banks the ability to seek reimbursement of reissuance costs in the wake of payment card data security breach. By providing this remedy, the drafters of the bill hope to encourage issuing banks to reissue cards, thereby reducing the incidence of identity theft and associated costs to consumers.

What organizations does HB 1149 apply to?

Moving past the introduction, the law provides a series of definitions related to payment card processing and data breaches. The law applies to “business(es),” “processors” and “vendors” (herein referred to as “Regulated Entities”). Businesses essentially refer to merchants that process more than six million payment cards annually, and who provide, offer or sell goods or services to residents of Washington. Processors are companies that process or transmit “account information” on behalf of another. Vendors are entities that manufacture and sell software or equipment designed to process, transmit or store account information that the vendor does not own.

Analysis: For each of these categories it is not necessary for the organization to physically reside in Washington state. To qualify as a “business “ the organization must merely offer or sell goods or services to Washington residents. Companies with an Internet website would arguably fall into that category. The definitions of “processor” or “vendor” do not even mention Washington residency as a limitation. As such, HB 1149 is likely to have reach beyond the borders of Washington State.

What kind of information does HB 1149 regulate?

HB 1149 imposes certain obligations with respect to “account information,” which is defined as follows:

Account information" means: (i) The full, unencrypted 2 magnetic stripe of a credit card or debit card; (ii) the full, unencrypted account information contained on an identification device as defined under RCW 19.300.010; or (iii) the unencrypted primary account number on a credit card or debit card or identification device, plus any of the following if not encrypted: Cardholder name, expiration date, or service code.

Analysis: Subsections (i) and (iii) mainly deal with various unencrypted cardholder data. Subsection (ii) however refers to unencrypted account information on “identification devices”, defined as "an item that uses radio frequency identification technology or facial recognition technology". An example might include a RFID tag. Identification devices are not obviously related to PCI and do not quite seem to fit into the overall theme of the law..

What data security obligations does HB 1149 impose on Regulated Entities?

Technically HB 1149 does not impose any obligations on Regulated Entities. Rather, the law works as a mechanism to transfer risk of loss between Regulated Entities and issuing banks in the event of a payment card breach involving Washington residents.  Think of it as "sword and shield law":  it gives issuing banks a sword to collect reissuance costs they otherwise might not be able to collect and provides companies a shield to avoid liability for such costs.

Section 2., paragraph (3)(a) indicates that if a processor or business fails to take reasonable care to guard against unauthorized access to account information, and that failure is the proximate cause of a breach, then the processor can be liable to issuing banks for costs to reissuing impacted payment cards. Section 2., paragraph (b) indicates that Vendors can be liable for damages caused by their negligence, but only if the claim is not limited or foreclosed by another provision of law or by contract to which the financial institution is party. However, as discussed further below, organizations that fall into HB 1149’s “safe harbor” will not be liable for reissuance costs (even if they did fail to take reasonable care or acted negligently).

Analysis: While there is no explicit/positive requirement for organizations to take reasonable care, companies that fail to do so may be liable to pay for reissuance costs after a breach. Contrast this against Nevada’s PCI law which imposed an affirmative obligation to be compliant with PCI for companies that accept payment cards.

What constitutes a “breach” under HB 1149?

HB 1149 borrows the definition for breach from Washington state’s breach notice law. As such breach has the same definition as “breach of the security of the system,” which is defined as follows:

unauthorized acquisition of computerized data that compromises the security, confidentiality, or integrity of personal information maintained by the person or business. Good faith acquisition of personal information by an employee or agent of the person or business for the purposes of the person or business is not a breach of the security of the system when the personal information is not used or subject to further unauthorized disclosure.

As you can see this definition references the term “personal information,” which is also a defined term under Washington’s breach notice law. Without repeating the entire definition, for information to be considered “personal information” it must include the first name/first initial and last name in combination with other data such as social security number or Washington driver’s license number. In addition, personal information includes first name/first initial and last name in combination with “account number or credit or debit card number, in combination with any required security code, access code, or password that would permit access to an individual’s financial account.”

Analysis. There may be a lack of consistency between the definition of “account information” and “personal information” such that it may be possible to have a compromise of “account information” without there being any "personal information" compromised. If that were the case then there would be no “breach” under HB 1149 and its provisions would not appear to apply. For example, the unencrypted PAN of a payment card plus an expiration date would constitute “account information” under HB 1149, but is not “personal information” as defined under Washington’s breach notice law. As such, if there was unauthorized access to such account information it would not constitute a “breach” since no personal information was implicated, and therefore HB 1149 would not apply (even if card reissuance was necessary).

How does PCI come into play under HB 1149?

Under HB 1149 the certification of PCI compliance is part of HB 1149’s “safe harbor.” In other words, under certain circumstances, even if a company failed to take reasonable care or acted negligently in protecting “account information” (as referenced in Section 3. of HB 1149) issuing banks will not be able to recover their reissuance costs.

How does the HB 1149 “Safe Harbor” work?

It appears that if a Regulated Entity satisfies the requirements of Section 2.(2) it will not be liable if it runs afoul of the reasonable care/negligence aspects of Section 2.(3). There are two ways to achieve safe harbor. First, Regulated Entities shall not be liable under HB 1149 if the account information at issue was encrypted at the time of the breach. Second, a Regulated Entity shall not be liable if it was certified as PCI complaint at the time of the breach. Under HB 1149, a Regulated Entity is considered compliant if it was validated by an annual security assessment as long as an assessment took place no more than one year prior to the time of the breach.

Analysis of Encryption Safe Harbor: The encryption safe harbor option seems odd in light of the definition of “account information.” Account information as defined under HB 1149 is by definition “unencrypted.” Thus, if the information described in the definition of account information was encrypted at the time of the breach, it would not constiute “account information” as defined. In other words, this safe harbor is completely circular and redundant.

Analysis of the PCI Safe Harbor: The PCI Safe Harbor is very interesting because it plays into and recognizes the difference between “PCI compliance” and PCI validation/certification. To make a long story short, a company can certify or validate that it is PCI compliant simply by filling out some paperwork. However, that company could be completely wrong and not actually compliant with the PCI standard. The PCI Safe Harbor in HB 1149 does not appear to care whether a Regulated Entity is actually PCI compliant. It appears that the paperwork will do. In fact, Section 2.(2) specifically indicates the following:

For the purposes of this subsection (2), a processor, business, or vendor’s security assessment of compliance is nonrevocable. The nonrevocability of a processor, business, or vendor’s security assessment of compliance is only for the purpose of determining a processor, business, or vendor’s liability under this subsection (2).

What this appears to state is that, as long as the Regulated Entity has done a security assessment and certified/validated it (e.g. filled out and turned in required PCI paperwork in the form of a self-assessment questionnaire or report on compliance), its assessment is “nonrevocable” even if it was incorrect. At least this is one reading of this language (and I would love to hear other theories on this reference).

What kind of encryption is required for the encryption safe harbor?

HB 1149 defines “encrypted” as follows:

(f) "Encrypted" means enciphered or encoded using standards reasonable for the breached business or processor taking into account the business or processor’s size and the number of transactions processed annually.

Analysis: The “taking into account” language is extremely odd in the context of describing encryption. It is unclear how a processor’s size or transaction volume would impact its encryption requirements. Typically the key factors for encryption are the key length (e.g. number of bits), encryption algorithm and key management.  What is unclear is whether companies of smaller size and lower transactions are allowed to use “weak encryption,” and if so, that would seem to undermine the purpose of the statute (again, I would love to hear from readers on what they think the “taking into account” qualification might mean to them).

When would this law come into effect?

HB 1149 takes effect on July 1, 2010. It would only apply to breaches taking place on or after July 1, 2010.

What happens if more than one entity was at fault for a breach?

According to Section 2.(6), the trier of fact (a judge or a jury) is responsible for determining the percentage of total fault that is attributable to every entity that was the proximate cause of a claimant’s damages.

Analysis: Again a strange provision. One wonders what percentage of fault would be applied to the person/entity that actually stole the payment card data (or whether that would even be part of the analysis).
 

  • http://blog.subjunctive.com Jim Graves

    I agree that the PCI DSS safe harbor seems to make an assessment of compliance irrevocable. And the statute does not require that assessments be performed by third parties, so the self-assessment questionnaires completed by smaller merchants might qualify as their annual assessments. That would be unfortunate—merchants should not be able to pick up a shield merely by asserting their own compliance.
    My take on the irrevocability of compliance is that it’s a direct shot at the PCI Security Standards Council’s practice of revoking a company’s PCI DSS compliance after a breach. The SSC’s logic is that because PCI DSS guarantees security, anyone who was breached must not have been in compliance with PCI DSS. That sort of circular logic would have prevented anyone from claiming a safe harbor for complying with PCI DSS, and I think it makes sense for HB 1149 to have ruled it out.

  • http://blog.subjunctive.com Jim Graves

    I just noticed that HB 1149′s definition of”business” is limited to those that process more than six million payment card transactions per year. That means the only merchants that should be subject to the law are the “Tier 1″ merchants, who are required to have annual PCI DSS assessments performed by external QSAs. Therefore self-assessment questionnaires aren’t an issue.

  • David Navetta

    Jim, I think it would still be possible for “vendors” and “processors” to do SAQs since there is not a minimum annual card transaction limit associated with either.
    Also, on the issue of certification/validation versus compliance, note that issuing banks would still have other remedies available. In particular the payment card rules and regulations. While they might not make an issuing bank 100% whole, they would allow for some recovery.
    Thanks much for posting a comment. Truly appreciated.

  • http://www.merchantaccountblog.com Jestep

    I think the safe-harbor element of any of these regulations is the most important. While many would argue that it undermines the idea of PCI, it the retroactive claw-back that we see when a company is breached undermines is even more. The sheer fact that compliant companies are claimed non-compliant by default in being breached is simply insane.
    I think it has the potential to create ambiguity in the validity of PCI overall, but this is something that should be addressed by the steps and requirement of PCI and state laws. If merchants falsely represent their compliance, by SAQ or not, they should be held accountable.
    Anyway, great overview on the situation. If the “Tier 1″ merchants fact is true and goes un-modified, this law is essentially worthless, but I expect that many states are going to be adopting similar laws, and Washington and this are paving the way for those. Hopefully, they realize that passing a law for 10 companies in the US is a little wasteful.

  • http://www.conciseconsulting.com Marcus

    I am actualy a trained QSA and information security assessor.
    This law is a mess. Additionally, your analysis has a few inconsistencies.
    First, the law includes in its definition of account information “track 2 data” Under the PCI DSS, this data can not be stored, encrypted or not. Any business storing such track 2 data would be non-compliant/and would not be able to validate.
    Secondly, it defines a “business” as an entity that processes over 6 million credit cards. This would make them a Level 1 Merchant, and would require that they hire a certified QSA to conduct a Report on Compliance (ROC) in order to validate their compliance. So, no business under this law would be submitting a Self-Assessment Questionnairre (SAQ), so your distinction between validation and compliance is not accurate. Merchants that go through a the process of getting a ROC are (with exceptions) usually actually compliant.
    The key is timing. PCI DSS validation is a “point in time” compliance review. A business can be compliance on the day it validates, but if it were to change something in its credit card data environment (CDE), it would no longer be compliant.

  • David Navetta

    Marcus, agreed that the law, as drafted, leaves something to be desired. This often happens with infosec laws (especially those that are crafted via compromise between two powerful lobbies — banking and retail).
    On your first point, I understand your issue. However, technically it is possible for a merchant to validate PCI compliance (say on January 1, 2010) and then later during the year (before its next PCI assessment) change its systems in a manner that allows Track 2 data to be stored. It is also possible of course, to have the QSA or merchant make a mistake in their assessment and somehow miss the fact that Track 2 data was being stored (or had been stored previously). I will give you that with diligent QSAs/merchants these scenarios are less likely.
    On your second point, two responses. First, it is possible for a merchant to process 6 million cards annually and not be considered Level 1. For Visa, level 1 is defined as merchants that process over six million VISA transactions annually. Mastercard refers to six million MASTERCARD transactions. As such, you could have a merchant processing 3.5 VISA transactions (Level 2) and 3.5 MASTERCARD transactions annually (Level 2), or 7 million total, and they would be subject to the Washington law even if they did a SAQ.
    I also note that this law applies to “processors” and “vendors” and neither definition refers to a minimum number of cards transacted annually (e.g. this law could apply to Level 2 service providers that do self-assessments)
    I also disagree with your point on validation versus compliance. The law clearly only requires validation, and as you admit, even QSAs can get it wrong. Look at some of the big breaches and you will note that QSAs were involved. Moreover, as you know card processing environments can change and become non-compliant. So even if the QSA got it right on Day One, by Day 364, the merchant may not be compliant.