Over the last few weeks we have been having a number of conversations with clients about PCI DSS 4.0.1; specifically, where and how we could help them with being more compliant.

Firstly, let’s take a look at what PCI DSS 4.0 is.

The PCI Security Standards Council’s guideline document (Link in the comments below) states that:

“The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance payment account data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. While specifically designed to focus on environments with payment account data, PCI DSS can also be used to protect against threats and secure other elements in the payment ecosystem. “

The guidelines were originally released by the PCI Security Standards Council in 2008 and have undergone a number of upgrades / refinements since then. The current version is PCI DSS 4.0.1 and it was released in June 2024 At its heart the standard has 6 primary principles:

• Build and Maintain a Secure Network and Systems
• Protect Account Data
• Maintain a Vulnerability Management Program
• Implement Strong Access Control Measures
• Regularly Monitor and Test Networks
• Maintain an Information Security Policy

The level of requirement you need to comply with is based on the total annual number of transactions accepted by your organisation and is categorised from Level 1 to 4. Levels 1 and 2 have a requirement for a compliance assessment to be conducted by an external auditor. Levels 3 and 4 state that the assessment can be conducted internally. All 4 levels have a requirement for quarterly Vulnerability Assessments using an Approved Scanning Vendor (ASV)tool.

We strongly recommend checking with your organisation’s bank as to what they require.

But do I have to be PCI DSS compliant? We hear you ask.

That’s a great question, according to the PCI DSS Guidelines :

“PCI DSS is intended for all entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data and/or sensitive authentication data. This includes all entities involved in payment account processing —including merchants, processors, acquirers, issuers, and other service providers.”

In other words - If your entity takes, stores, or processes credit card payments then “yes”, you do have to be PCI compliant. Again, we recommend checking with your bank as to what they require of you to be compliant.

With the continual increase in Cyber Crime, there have been a number of changes to the standard over the last couple of years. A lot of the changes are about providing further clarification to the standard, staff education about their responsibilities, and the addition of a customised approach for implementing and validating PCI DSS.

So, how can we help?

Firstly, let’s talk about what we do not do. We are not PCI DSS auditors, nor do we provide Gap analyses. There are a lot of other companies in the industry who do this and do it well.

At Pākiki Security, we specialise in the technical side of security. What we can do is test internal network segmentation/segregation, conduct penetration testing of solutions, and conduct regular (the standard recommends quarterly) Vulnerability Assessments using a PCI DSS approved scanning vendor (ASV), refer to page 279 of the PCI DSS guide in the comments below.

As tempting as it was, this post was not written with the assistance of any AI tools. It was however written using the PCI Security Standards Council’s guideline document (Link in the comments below) and various New Zealand based banks PCI DSS guidelines.

Feel free to get in touch if you would like to sit down and have a chat about IT Security.