A change is on the cards

Did you know data contained on credit cards and debit cards issued by schemes such as Visa and MasterCard are one of the easiest types of information for criminals to steal and convert to cash? Disposal of card information when it is no longer required for business purposes is the best way of protecting both your customers and your agency from this type of theft.

The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security, and it applies to all entities involved in payment card processing. The Standard has some quite specific requirements regarding the storage and disposal of credit card details which must be met.

We’ve been hearing that agencies are grappling with how they can meet these requirements and be recordkeeping compliant. To address this, QSA has released a new version of the Transitory Records and Short Term Retention and Disposal Schedule QDAN720^. With guidance from Queensland Treasury who provided clarity on PCI DSS requirements, we’ve developed two new classes for card records.

^Note: Transitory Records and Short Term Retention and Disposal Schedule QDAN720 has been superseded  by the current version of the GRDS.

Why the change?

The table below, taken from the Standard, illustrates commonly used elements of card data, which of these can be stored, and which need to be protected.

Credit card table

As you can see in the table, sensitive authentication data, such as those 3 digit numbers on the back of MasterCard and Visa cards, should never be stored.

It also says that a Primary Account Number (PAN) (the card number), needs to be rendered unreadable when it is stored. Can your system meet that requirement? If not, then you can’t store (capture) this record in your system.

The data that can be stored under the PCI DSS should only be retained if there is a valid legal, business or regulatory need for that data. That’s why under the Transitory Records and Short Term Retention and Disposal Schedule QDAN720, we’ve made the disposal action ‘retain until business use ceases’. This means your agency determines when the card data is no longer required and can destroy it if there is no valid business reason to retain it. For the sensitive authentication data, we’ve directed immediate destruction – as you must not store this data at all.

What about the existing record classes in the GRDS?

There are two existing classes in GRDSv7 specifically associated with card data (4.1.12 and 4.1.13) so we know it may appear we’re duplicating things here, however records covered under the Transitory Records and Short Term Retention and Disposal Schedule QDAN720 don’t have to be captured into an agency’s recordkeeping solution. By having the two new classes in that schedule, we want to make it clear that QSA doesn’t have a requirement for you to capture and store these records!

Of course, if you wish to continue to use the classes in the GRDSv7 for disposal until we release the revised schedule, you can. You just need to ensure you are storing the records in line with the Standard.

What if other information needs to be kept once a transaction is completed?

Where there is a need to keep other parts of the record for a certain period of time after the card transaction has occurred, for example to show payment has been received, orders sent etc., the cardholder data must be stored or redacted in some way, in accordance with the requirements of the PCI DSS.

If this is challenging for you and you’re looking to avoid such storage issues compounding for the future, you might wish to consider introducing new processes such that all new cardholder data received is not captured with other record data. This will mean you can easily dispose of the cardholder data once your business need is met, whilst retaining the other data for its required retention period, thereby being compliant with both the Standard and your recordkeeping obligations.

Irrespective, a documented process relating to the management and capture of records associated with credit card transactions is important to help make it crystal clear for all staff, both exactly what does need to be captured – in order to meet your recordkeeping responsibilities – and what can be disposed of. This will certainly require consultation with those staff who receive, handle and use cardholder data.

If you’ve successfully implemented the PCI DSS within your agency, do you have learnings or tips you’d like to share with your colleagues? If so, leave a comment below, or you can contact us at any time via email, telephone (07) 3037 6630, blog, Twitter, Facebook, Instagram or Flickr.

Anna Morris                                              Karen Ryan

A/Manager, Agency Services               Principal Appraisal Officer


Last updated 27 March 2018

6 thoughts on “A change is on the cards

Add yours

  1. I thought I’d share a very brief summary of some of our learnings in relation to our PCI compliance program. The steps to determine the work packages required to meet compliance with the Standard (PCI DSS) in our case involved determining all of the relevant stakeholders and fully engaging with internal and external SME’s and was driven by the CFO and project board at a strategic level and undertaken by a project team from IT, Finance, Operations, Customer, Legal and Records management.
    The compliance initiatives will to a fair degree depend on the merchant level of your organisation as determined by Payment Card Industry criteria and assessment and validation activities by your Qualified Security Assessor (QSA) if applicable. Retention and security provisions for transactional data will be dependent on the terms of the Merchant Agreement with your service provider and should be detailed in the terms of that agreement. The main issue, not surprisingly, involves ensuring CHD and SAD are not recorded, stored or transmitted in contravention of the Standard and/or merchant agreement.
    At the time of our compliance program the schedules in version 6 of the QDAN did not specify retentions that aligned with the standard or our merchant agreement. This was a source of stress throughout the process. This does raise questions about the role of schedules and ensuring in the future they are flexible enough or otherwise positioned to deal with various sources of retention requirements to avoid such issues arising.
    Another key focus area for us was and is the business processes including but not limited to transaction processing, disputed or cancelled transactions and internal and external form design as well as a fully endorsed and supported financial security and governance program for payment card transactions. Like many information or financial management issues that are often driven by legislation and in a large part determined by risk, attaining compliance with the standard can be a fairly daunting process at times however the financial penalties for non-compliance or data breach are significant, so too the reputational harm that invariably follows any breach.
    If the compliance process is owned and driven by an appropriate C level executive with board or minister backing it is far more likely to be achieved and once there is relatively straightforward to maintain.
    If there is one piece of advice I would give it is to ensure you don’t use your eDRMS for CHD unless irreversibly redacted in line with the provisions of the standard. Our preference is to keep cardholder data in the system that processes the transaction as the PA DSS compliant software will possess the necessary truncation, encryption or masking to secure the data and is far preferable to moving it into an eDRMS in my opinion but either way don’t keep CHD unless absolutely necessary and don’t keep SAD anywhere, ever.

    1. Hello Mike and thank you for your comment.
      Sharing experiences like this really helps other agencies with their implementation of the standard. You have highlighted the key aspects agencies will need to consider when developing their own process and how important it is to do this to ensure the requirements of the standard are met, while balancing recordkeeping compliance.
      GRK Team

  2. Perhaps for the next update of the TRAST a correction to the grammar error on page 3 can be made? “The list of examples are not exhaustive…” should read “The list of examples is not exhaustive…”.

    The current text is effectively saying “The list are not exhaustive…” which is clearly incorrect.

    1. Hi Perry, Thanks for pointing this out. We are reviewing QDAN720 and we have survey out at the moment until 1 April 2016 if it comes back into the GRDS or not.

Leave a Reply

Powered by WordPress.com.

Up ↑

%d bloggers like this: