Doesn't storing the expiration date and last 4 digits potentially violate PCI compliance?

I would think this would be a major issue with this module. I went into it thinking that it DID push all the data to Authorize.net. To my surprise it doesn't. I'm with Chris in thinking that the whole purpose of CIM is to not store any CC data in our databases and push all the data to Authorize.net. Figured I'd bump this up to major priority for who ever takes over the module or just to let people know.

Here's the "Protect stored cardholder data" section from Security Metrics PCI Self Assessment Questionnaire. I hope this helps!

• 3.1 Are data retention and disposal policies and procedures
• implemented as follows:
• 3.1.a Are data retention and disposal policies and procedures
• implemented and do they include specific requirements for
• retention of cardholder data as required for business, legal,
• and/or regulatory purposes?
• 3.1.b Do policies and procedures include provisions for the secure
• disposal of data when no longer needed for legal, regulatory,
• or business reasons, including disposal of cardholder data?
• 3.1.c Do policies and procedures include coverage for all storage
• of cardholder data?
• 3.1.d Do processes and procedures include at least one of the
• following?
• * A programmatic process (automatic or manual) to remove,
• at least quarterly, stored cardholder data that exceeds
• requirements defined in the data retention policy
• * Requirements for a review, conducted at least quarterly, to
• verify that stored cardholder data does not exceed
• requirements defined in the data retention policy.
• 3.1.e Does all stored cardholder data meet the requirements
• defined in the data retention policy?
• 3.2.a For issuers and/or companies that support issuing services
• and store sensitive authentication data, is there is a business
• justification for the storage of sensitive authentication data,
• and is that the data is secured?
• 3.2.b For all other entities, if sensitive authentication data is
• received and deleted, are processes in place to securely delete
• the data to verify that the data is unrecoverable?
• 3.2.c Do all systems adhere to the following requirements
• regarding non-storage of sensitive authentication data after
• authorization .even if encrypted):
• 3.2.1 The full contents of any track from the magnetic stripe
• (located on the back of a card, equivalent data contained on
• a chip, or elsewhere) are not stored under any circumstance?
• 3.2.2 The card verification code or value (three-digit or four-digit
• number printed on the front or back of a payment card) is
• not stored under any circumstance?
• 3.2.3 The personal identification number (PIN) or the encrypted
• PIN block are not stored under any circumstance?
• PCI S elf-As s es sment Ques tionnaire D 2.0
• 5 of 24 Generated 27.Oct.2011 As ans wered by
• 3.3 Is the PAN masked when displayed (the first six and last four
• digits are the maximum number of digits to be displayed)?
• 3.4 Is PAN rendered unreadable anywhere it is stored (including
• data repositories, portable digital media, backup media, and
• in audit logs), by using any of the following approaches?
• 3.4.1 If disk encryption (rather than file- or column-level database
• encryption) is used, is access managed as follows:
• 3.4.1.a Is logical access to encrypted file systems managed
• independently of native operating system access control
• mechanisms (for example, by not using local user account
• databases)?
• 3.4.1.b Are cryptographic keys stored securely (for example, stored
• on removable media that is adequately protected with strong
• access controls)?
• 3.4.1.c Is cardholder data on removable media encrypted wherever
• stored?
• Note: If disk encryption is not used to encrypt removable
• media, the data stored on this media will need to be rendered
• unreadable through some other method.
• 3.5 Are any keys used to secure cardholder data protected
• against disclosure and misuse as follows:
• 3.5.1 Is access to cryptographic keys restricted to the fewest
• number of custodians necessary?
• 3.5.2.a Are keys stored in encrypted format and are key-encrypting
• keys stored separately from data-encrypting keys?
• 3.5.2.b Are cryptographic keys stored in the fewest possible locations
• and forms?
• 3.6.a Are all key-management processes and procedures fully
• documented and implemented for cryptographic keys used for
• encryption of cardholder data?
• 3.6.b For service providers only: If keys are shared with customers
• for transmission or storage of cardholder data, is
• documentation provided to customers that includes guidance
• on how to securely transmit, store and update customer's
• keys, in accordance with requirements 3.6.1 through 3.6.8
• below?
• 3.6.c Are key-management processes and procedures implemented
• to require the following:
• 3.6.1 Do cryptographic key procedures include the generation of
• strong cryptographic keys?
• PCI S elf-As s es sment Ques tionnaire D 2.0
• 6 of 24 Generated 27.Oct.2011 As ans wered by
• 3.6.2 Do cryptographic key procedures include secure
• cryptographic key distribution?
• 3.6.3 Do cryptographic key procedures include secure
• cryptographic key storage?
• 3.6.4 Do cryptographic key procedures include cryptographic key
• changes for keys that have reached the end of their defined
• cryptoperiod (for example, after a defined period of time has
• passed and/or after a certain amount of cipher-text has been
• produced by a given key), as defined by the associated
• application vendor or key owner, and based on industry best
• practices and guidelines (for example, NIST Special
• Publication 800-57)?
• 3.6.5.a Do cryptographic key procedures include retirement or
• replacement (for example, archiving, destruction, and/or
• revocation) of cryptographic keys when the integrity of the
• key has been weakened (for example, departure of an
• employee with knowledge of a clear-text key)?
• 3.6.5.b Do cryptographic key procedures include replacement of
• known or suspected compromised keys?
• 3.6.5.c If retired or replaced cryptographic keys are retained, are
• these keys only used for decryption/verification purposes (not
• used for encryption operations)?
• 3.6.6 Do cryptographic key procedures include split knowledge and
• dual control of cryptographic keys (for example, requiring
• two or three people, each knowing only their own key
• component, to reconstruct the whole key), for manual cleartext
• key-management operations?
• 3.6.7 Do cryptographic key procedures include the prevention of
• unauthorized substitution of cryptographic keys?
• 3.6.8 Are cryptographic key custodians required to formally
• acknowledge (in writing or electronically) that they
• understand and accept their key-custodian responsibilities?

These three sections are pertinent: ("PAN" stands for Primary Account Number)

3.2.2 The card verification code or value (three-digit or four-digit
number printed on the front or back of a payment card) is
not stored under any circumstance?

3.3 Is the PAN masked when displayed (the first six and last four
digits are the maximum number of digits to be displayed)?

3.4 Is PAN rendered unreadable anywhere it is stored (including
data repositories, portable digital media, backup media, and
in audit logs), by using any of the following approaches?

So, while it's acceptable for the last 4 digits of the card to be stored, it's a violation to store the CVV code. IIRC Authorize stores this along with the card number in their secure server, so there's no real reason for us to store it locally. I don't think it's a violation to store the expiry date, though. My preferred option is to only store the tokens locally and have everything get pulled via the API upon request, but perhaps that's not the most performant way of doing it.

If I can find time (a bounty would help!) I can potentially write a patch that fixes this.