PCI DSS v4.0 – finance professionals webinar recording

PCI DSS v4.0 is live and organisations are going to need to make a lot of changes to be compliant with the new standard. So Securious – the South West’s leading cyber security company and a PCI DSS Qualified Security Assessor Company with a team of experienced QSAs – recently held a webinar to help finance professionals familiarise themselves with the changes to PCI DSS. Here is a recording of the session with a transcript below:

Introduction – Tony Harbon, Chief Growth Officer

Good afternoon, everyone. I’m Tony Harbron and I’d like to extend a warm welcome from Securious to all of you attending our PCI DSS v4.0 webinar today. 

There’s a lot to get through, so in just a moment, I’m going to hand over to Pete Woodward who will run through the presentation on PCI DSS v4.0. 

Now, many of you will already know Pete, but for those that don’t, he’s our founder and CEO, and he’s been a PCI Payment Card Industry Qualified Security Assessor (or QSA) for many years. That means Pete is one of only a very small number of people worldwide qualified to perform Payment Card Industry compliance audits and consultancy. So Pete really is ideally placed to help us explain the changes that are coming with PCI DSS v4.0. And in particular, their relevance to people in finance roles that I know many of you here today are. 

So Pete, take it away. 

Welcome (back) – Pete Woodward, Cofounder and CEO

Welcome back to those of you who attended our previous webinar, which we held last year. Since then, we’ve been obviously helping clients achieve compliance with PCI DSS v4.0. And today, I really want to talk a bit more about our actual experiences of implementing PCI DSS V4.0 rather than just talking about some of the principles of the changes, especially in the context of how that may impact or influence some of you finance professionals and how you tackle PCI DSS v4.0. So this should help give you some clear guidance and context for what the changes mean and what you should do. 

So, in today’s session, we’re going to look at:

• How we approach PCI DSS compliance with our existing clients
• Why we now believe that you should aim for compliance with PCI DSS v4.0 as soon as possible
• A quick recap on the transition period from PCI DSS version 3.2.1 to PCI DSS v4.0
• An overview of what’s changing and what those changes might mean to you
• What are some of the immediate changes you need to be aware of
• What are some of the changes that are going to impact finance professionals
• What you should be doing
• Other important things to bear in mind
• And lastly, how we see the market shifting and how we can potentially help out with some of the issues you are having yourselves

How are we approaching PCI DSS v4.0 compliance with our clients?

Over the last year or so since PCI DSS v4.0 came out, we’ve mostly been helping our clients achieve version 3.2.1 (we’ll come on to that transition period in a minute where you’ll understand why we’ve been doing that). We’ve been doing this alongside conducting gap analyses against PCI DSS v4.0, so clients know what changes are actually going to impact them when they move forward. 

But we’ve actually made the decision now to deploy PCI DSS v4.0 to every new PCI engagement and all renewals. We think now the time is right to switch to PCI DSS v4.0 and start working towards implementing the requirements you’ll need going forward. It is quite a big ask, but we’re confident that the changes won’t impact most companies most of the time for now (I’ll cover some of those in a second). 

The key thing to remember with PCI DSS v4.0, is if you don’t have any future-dated requirements in place right now, they’re just going to be marked as not applicable. So although there’s a one or two-year period to get them in place depending on the requirements, basically, if they’re not in place at the moment, they’re marked as not applicable, so don’t worry.

Why are we now deploying PCI DSS V4.0 for all PCI renewals? 

The changes that came with PCI DSS v4.0 are quite wide and quite a step change really from 3.2.1, which has been around since 2018. So it definitely needed a refresher. 

There are a few fundamental changes that have come into place with PCI DSS v4.0. It’s ended up needing a far greater level of due diligence, for example, on your environment, and some of the security measures that are necessary have changed as well. So there are quite a few step changes in terms of how you might tackle PCI against how you’ve been doing it for the last number of years. This is going to be a definite change for you. 

Ultimately, we don’t feel that there are many good reasons for sticking with 3.2.1 now – it feels like an older standard. Now we’re aligning to the new version. And what that represents in best practices is obviously a good thing to move forward and align to. 

So what does it mean for you? 

Well, if your renewal is coming up, we recommend that you should be aiming for PCI DSS v4.0, as I’ve mentioned, rather than 3.2.1 – though there are possibly going to be some minor exceptions there. But on the whole, 99% should go for PCI DSS v4.0.

If your renewal has passed recently, and you are yet to commission a gap analysis against PCI DSS v4.0, now’s a good time just to look at the future requirements and see where you may fall short.

A quick recap on the transition period for PCI DSS v4.0 

So PCI DSS v4.0 was out in draft in early 2022, and we’re in the transition period now. We’ve got until the end of q1 next year – so the 31st of March 2024 – with 3.2.1, which means at the start of April next year, PCI DSS v4.0 will be the only active version of the standard. 

There is still another year after that for some of the future-dated requirements to be in place. So there will be some changes next year, but the longest-standing future-dated changes will need to be implemented by the 1st of April 2025. 

That sounds like a long way off, but as you’ll see in the next few slides, some of the things you may want to be looking at could eat into that – like the time of evaluation etc. And I think everyone knows that 12 months is a short time when you’re trying to source new technologies or put in place new processes. 

What are the changes and what do they mean for you? 

Continuing to meet the security needs of the payment industry 

The ultimate goal of the PCI Data Security Standards Council with PCI DSS v4.0 is to continue to meet the security needs of the payment card industry. They’re expanding some of the multi-factor authentication requirements, they’ve listened to the industry and understood where they should be in terms of best practice. For example, multi-factor authentication is extended beyond administrators or the cardholder data environment to cover all users that access that environment. They’ve also updated password requirements. It was set to require seven characters with at least one uppercase, lowercase and number. They’ve changed that to more complex password requirements, a minimum of 12 characters – though if your system doesn’t support 12 characters then it’s 8. 

They’re also promoting the use of password savers and vaults for saving these longer, more complex passwords. And there are new e-commerce and phishing requirements to address ongoing threats. You’re now looking at alerting and anti-tampering technologies that need to be implemented. 

Pages that, for example, provide payment services through an iframe or redirect on your e-commerce websites now need an alerting mechanism to alert any malicious activity on the script. So there could potentially be some complex technical things you might have to look at in more detail.

Promoting security as a continuous process

The bottom line is, the PCI Council is promoting this new standard of security as a continuous process, which it always has done. But there’s more emphasis on it now. We’ll come on to the assigned roles and responsibilities in a second, but they’re clearly seeing that as a big gap area within the way it’s been reported and the way organisations are tackling their own in-house cardholder data security. They’re pushing you to get those roles and responsibilities nailed down so you’re actually clear on who’s in charge and accountable for your data security. 

There’s added guidance to help people better understand how to implement and maintain security controls. So there’s a lot more emphasis on promoting good practice, and the definition is improved throughout the new standard. There should be a much clearer understanding of what you need to have in place to meet those requirements. 

From our point of view, as assessors, we get new reporting options. So it highlights areas of improvement, providing more transparency for those organisations and staff reading the reports or reviewing them. So a lot more detail goes into the reporting side of the function and it will make it much easier to understand and digest reports. 

Increasing flexibility for organisations using different methods to achieve security objectives

Another good point from our side is the increased flexibility for organisations using different methods to achieve security objectives. So there are a couple of ways you can do this standard version of meeting requirements. 

There’s a customised approach now, which is implemented. So if you’re a longstanding organisation that implements a lot of security risk management around the controls for PCI compliance, then depending on your testing regime and your risk analysis of those controls, you can actually submit a customised approach so you’re not meeting the requirement as it is in black and white, but you are doing more than enough to cover what’s within that control. 

So there’s a whole load of flexibility around how you submit PCI compliance going forward as well. There’s some good practice in here and this is really designed for organisations that have long-established PCI compliance that have being doing it year-on-year. This customised approach wouldn’t be recommended for a new organisation or if it’s your first year doing PCI compliance. This is really around having that embedded risk management and analysis framework within your organisation.

Enhancing validation methods and procedures

They’re also enhancing these validation methods and procedures. There’s a lot more alignment between information reported in a Report on Compliance, or a Self-Assessment Questionnaire, and the information summarised within the Attestation of Compliance. It has vastly improved. 

There are going to be more frequent primary account number data discovery tasks, Approved Scanning Vendor scans are mandated now for E commerce platforms. So we’re having to align to a new requirement from immediate effect where you would do a vulnerability scan on your web presence, check for misconfigurations, and the like. 

There’s also a lot of talk around automated mechanisms and technology solutions that will perform automation, where they feel that human interaction is lacking. A typical example might be when you’re doing daily log checks, there’s an automated function requirement now where you need to automate it or look at automating that mechanism to remove the human error element.

What are some of the immediate changes you need to be aware of?

There are a lot of things to consider – but some of these things won’t be applicable to a lot of organisations. So I’m just highlighting a few of the key changes here, really. Don’t get wrapped up feeling like there’s loads to do. It’s all very specific. 

We’re doing PCI DSS v4.0 from now on, so if you’re running an E-commerce platform, you now need to look at Approved Scanning Vendor scans within your environments or web environment, roles and responsibilities, and also taking responsibility and looking at your trusted third-party service providers having some sort of shared responsibility matrix in place. So you know exactly which party is handling, managing and securing that Card data when it’s in your control and when it’s outside of your control. So there’s a lot of extra consideration for these areas. 

Specific changes relevant to finance professionals 

Internal roles and responsibilities

Now onto the roles and responsibilities. This is really making the governance within your organisation accountable for PCI compliance. Since PCI compliance has been around and implemented, there’s been no organisation that was PCI compliant at the time of a breach, bizarrely. And in the forensic investigations, it’s been found that no-one was really accountable. It might have been a network issue, it could have been an encryption problem, it could have been a reporting mechanism. But nobody was actually accountable for those card breaches. 

So what they’ve really emphasised in PCI DSS v4.0 is assigning and aligning roles, specific to those members of staff that govern the cardholder environment. The network security manager might be accountable for implementing encrypted communication between the third-party service providers in the organisation. 

Finance professionals will need to ensure that contracts are in place and hold up to scrutiny when considering responsibility for the protection of cardholder data. We’ve been in touch and communicated with a lot of our clients about this very requirement. They’re all worried that this is going to change people’s employment contracts, now they’ve taken on more than just their contract’s roles and responsibilities. 

We say it absolutely shouldn’t be a big problem, because we’re not changing job descriptions, despite the additional HR that we have to go through to change this with staff. We’ve had trade unions and all sorts start jumping on this one. But it’s really around understanding what those roles and responsibilities are within the organisation. And then updating documentation. The job description doesn’t change, but the documentation does. 

External roles and responsibilities

Organisations are now responsible for engaging with their third-party security providers and going through a checklist of making sure it’s clear who’s responsible for cardholder data. 

The service providers will be going through PCI DSS v4.0 as well. And they’ll have their own strategy and plans and migration over to PCI DSS v4.0. So in the immediate term between now and the 1st of April next year, there’s likely to be a lot of confusion in the market. So you just have to align to PCI DSS v4.0 and knuckle down and bear with it. 

One of the key things is you might have an established agreement and relationship with your bank or your acquirer, but you really need to enhance that now and start getting under their skin a little bit to understand what the implications are for data security, what are their requirements, what are they looking for, how do we secure our card data, how do we get verification that you’re secure, etc. 

Doing due diligence now is going to probably incorporate a bit more about responsibilities and nailing that down. And we’ve seen already that contracts are changed and manoeuvred to meet these requirements. So there’s a lot of potential extra admin to do from that point of view.

So what should you be doing? 

Start sooner rather than later. I keep saying it’s March now and we’ve got exactly a year before PCI DSS v4.0 is the only live version. So start sooner rather than later, and look at the new standards and how these changes may affect your environment. And also look at where you are now. Many of you will probably have these controls in place anyway. So understand where you are now, and then set up a roadmap, outlining how you’re going to implement some of the required controls. 

Other important things you should bear in mind

You need to consider PCI DSS v4.0 with any technical decision you may need to make over the next year or so. Ask yourself and start asking those suppliers when they’re going to start meeting PCI DSS v4.0’s requirements. 

And if a specific requirement is needed, then they’re going to have to align with that as well. Implementing a new technical platform can take many, many months. And there’s budget involved, there’s integration involved, there’s a whole load of things that you need to bear in mind. So just be mindful of that, as well. Don’t sit back and think, we’re a very small organisation, we only have one payment method. That payment method may have changed, and there may be some new requirements. Check out where you are, and find out that you’re not going to leave yourself unnecessarily exposed when you really do have to do PCI DSS v4.0. 

There might be a new digital solution or software that needs to tick a box for some payment, compliance, etc. Do some research and understand, certainly, if you’re changing systems, or looking at a new CRM system, or a count and pause service or anything like that. Let’s not shy away from the fact that there are some new requirements, and you’ll need to do proper due diligence.

How Securious can help with PCI DSS V4.0

We’re here to help you. We can conduct a transition audit and help you create a plan for your transition. We have a team of experienced QSAs to help you. And we’re here as a resource for any random questions or concerns you might have. 

We can also share with you some of our services that we’re already developing specifically for PCI DSS v4.0, we’re already helping clients with SIEM solutions, anomaly detection, automated log reviews, and things like that. 

We’re happy to deliver a webinar or in-person meeting about any of your concerns that you want to bring to the wider table.

To summarise

Half an hour is really not long enough to tell you about all the little quirky changes that you need to just nip in the bud and get ready for PCI DSS v4.0. 

But to summarise, there is a lot changing, there is plenty to do depending on your size and the payment methods your organisation uses. So act sooner rather than later. And start learning about how those changes are going to impact you. 

And then keep in touch. We’re putting a lot of content out there on LinkedIn and social media and on our website, we’re creating blogs and we’re doing a lot to drill down into some of the key requirements that are going to change and be impactful. So keep an eye on the website and stay in touch. 

Q&A

I would like to understand a company’s PCI exposure if they’re using software such as square etc, that provides controls within their products. Is this enough? Or do we need to do more to comply?

Yeah, it’s quite common for organisations using partners such as Square, Stripe or other providers – and they’re great. They will be PCI compliant. It doesn’t mean that you don’t have to do PCI compliance yourself. It just means that your scope is a lot smaller, because you can say, yes, we use a third-party provider. 

But you have your own compliance to make sure that any third party you’re dealing with or working with etc, is actually compliant themselves. So you need to be asking them, and you need to be ensuring they’ve got a shared responsibilities matrix in place. So for example, Square will say they handle the hardware, the card data, transmission, etc. 

You just need to understand if your clients come to you and say where’s my card data going, who’s handling that and who’s responsible for the security of that, then you’ve got a matrix that can pull up. That’s the third party, that’s what we’re paying them for. 

So don’t think that PCI compliance is going away for you just by outsourcing, it’s a good step and a good move. And I would recommend everyone uses third-party service providers, because that’s what they’re there for. But there is still an onus on you to submit everything and ensure the providers you work with are compliant.

Are there any downsides to going for compliance with PCI DSS v4.0? 

I wouldn’t say downsides, but there are challenges. If you go to PCI DSS v4.0 now, there are the roles and responsibilities and requirements I mentioned earlier that need to be in place. So that’s the first thing you’re going to have to tackle immediately. 

It shouldn’t be such a big job to do. We’ve had lots of organisations already get around some of the grey areas on that. So that shouldn’t be a biggie. If you’re an e-commerce website, you’re going to have to implement ASV scanning (Approved Scanning Vendor scans) on your website. That shouldn’t be a biggie either. 

It hasn’t been applicable before but now it is, which never made sense to us why it’s not applicable in the first place. So they’ve obviously jumped on that and included it now. So there are only a couple of real changes that you need to do from day one by going to PCI DSS v4.0. If you’re not meeting any of the future data requirements, right now, they’ll just be classed as not applicable until they’re forced to be in place. So there’s no downside. I would, I would definitely start looking at PCI DSS v4.0.

What are the implications of the logging and monitoring requirement for PCI DSS V4.0? 

This is a good one, we’ve had lots of talk around logging and monitoring. So the key thing is automation. If you can automate things that are mundane daily tasks then the less human error we’re going to impose. 

By human error, I mean someone missing a log or a security event, and that leading to a breach. Obviously, that’s a big problem, and can have a big impact on organisations. So you should not be conducting daily log checks manually any more. 

There are a lot of automation requirements to come in now, so you should be alerted to anomalies in your environment, rather than having to go looking for them on a daily basis. 

There are a lot of solutions out there in the market that can do that for you. We’ve got solutions that our clients are using already, which is tackling this issue, but it’s really going to be a step change towards automating a lot of what was mundane human interaction points. 

It’s all that alignment to best practice and aligning to that continual assurance type of service. So there’s potentially something technical to have in place, or maybe a tweak of some of your environments dependent on what logs you are required to be looking at and keeping. 

Where can we find the full details of the changes to PCI DSS, is all this information publicly available? 

Here is a link to the PCI Security Standards Council website, which is a great source of information. They have a PCI DSS v4.0 section as well and a blog and some FAQs. I think they even do videos and coffee with a council and all that sort of stuff. So there’s lots and lots of resources on there. They have broken it down into little bite-sized chunks. So you don’t have to sit there and read through a 450-page report to understand what the changes are.

If we haven’t answered your question, or if anything occurs to you, or if you’re worried about anything, please do get in touch, just ping over an email or pick up the phone. We’ll always do our best to put you on the right track. If you have any feedback on the session, we’d really appreciate hearing that also. 

Check out our PCI V4.0 resources page for more articles like this.