This HALOCK PCI webinar discussed the PCI DSS requirements implemented in March 2025, which encompass fifty-one new requirements listed in order for clarity. The significant changes are stronger security procedures for the storage of sensitive data, multi-factor verification for access to the information of the cardholder, and stronger system account controls. The webinar also emphasized having the latest inventories in place and performing ongoing security reviews in order to comply. Members were invited to interact through the use of the questions and the resources available for additional advice.
TRANSCRIPT
Hello, and thank you for joining us for our third HALOCK PCI, this is the v4 webinar.
Today, we’re gonna take a deep dive into the new four point o DSS requirements that are applicable in March of 2025.
Again, I am Viviana Wesley. I’m a principal consultant on the HALOCK governance compliance and engineering team. I started in IT and have been specializing in information security for over thirteen years.
We’re gonna do a brief introduction to the fifty one new PCI DSS requirements and that will be applicable in March of twenty twenty five, And then we’re gonna review each of those requirements by category to kinda group things together logically and help people think through what additions are coming.
Then we’re gonna talk about some of the considerations for your planning purposes, some things you need should be thinking about now rather than next year so everybody is prepared.
So let’s start with our high level overview of the fifty one PCI DSS requirements that are being introduced as best practices in version four right now, but will be full DSS requirements come March of twenty twenty five.
First, let me explain what that means is when an organization validates compliance in twenty twenty four and they come across one of these new requirements, they can actually mark it nonapplicable because that date has not been reached, and it’s just a best practice.
So any 4.0 validations that are done in twenty twenty four do not have to comply with these requirements yet. That will not be enforced until March of twenty twenty five.
If an organization has this requirement already in place or one of these requirements in place and wants to validate compliance for it, they can through their self assessment questionnaire (SAQ) with a QSA. They just don’t have to in twenty twenty four.
So wanted to make sure that was clear.
As you can see from this list, this is the the we’re starting at the top of the DSS and going down. So the first new DSS requirements that are best practices until March of twenty twenty five are actually in section three. So in sections in section three, we see seven new DSS requirements that will be implemented in full requirements in 2025. Then we get when we get into section four and five, that number starts to shrink a little bit. So in section four, we only have two additional new requirements.
In section five, we have four.
Section six starts on this page, but doesn’t add until the next. And we have a a new section six requirement on this page, but you’ll see that there’s actually three total being added to section six.
Section seven is actually also getting three new requirements.
And section eight tries to take the lead, with seven new requirements being introduced in or in section eight.
Section nine only has one new requirement being added.
Section ten has about four, I believe, once you count the one on the last page and these three. Yes.
Section eleven, it was also getting five new requirements added. And then, section twelve is actually the one that has is leading the charge here. So on this page, we’re gonna see seven new requirements added for section twelve.
On the second part of that list is the rest of those new requirements being added for section twelve. So there’s quite a bit being added to the section twelve requirement section of the DSS.
Then we also have four additional requirements being added for shared hosting providers that are now referred to as multi tenant hosting providers in version four of the data security standard. So those are all in appendix a one.
Since the majority of clients don’t deal with those particular shared hosting multi tenant validation environments, we’re not gonna spend a lot of time on those today. If you have additional questions about those and how they potentially impact your environment, if that’s applicable to you, feel free to reach out, and we can discuss those in more detail.
So let’s dive in. There’s lots to talk about today.
First and foremost, we’re in section three since we’re starting at the top.
We see that there’s quite a bit being added related to cardholder data storage requirements, but it’s not just cardholder data storage requirements. We’re actually seeing the security standards council create new requirements around the storage of sensitive authentication data. So they’re not saying that you can now store sensitive authentication data after authorization, but what they are saying is that if you are storing that information prior to authorization, then you need to make sure that data is being encrypted, protected.
There needs to be strong cryptography used to make sure that that information is being secured properly.
And, last but not least, any organization that is dealing with that sensitive authentication data storage needs to ensure that if that data is being stored prior to authorization, there’s a retention policy associated with that and that that data is removed after it’s no longer needed for business reasons.
So not only are we talking about storing that data prior to authorization, but how we’re protecting it. When they talk about storing that data prior to authorization, there is a frequently asked question document on that, which means which speaks about the difference between volatile memory and writing that information to disk. So you can always go to the council’s website and look up that frequently asked question article about storage. It’ll give you more indication of exactly what they mean by storage here.
That was last updated in December of this past year, so they did update it for four point o.
One of the things to just be aware of is any frequently asked question article on the council’s website, they review on a regular basis when new requirements are released. If it’s still applicable, they’ll leave it out there. If it needs to be updated, they will update it. If it needs to be removed because it’s no longer applicable, they will remove it. So even if the frequently asked question article is from a few years back, the fact that it’s still published and out there means that it’s still applicable.
Next, we talked or they they introduced some additional protections around storage of cardholder data. So now sensitive authentication data, but the pan and any data stored with that pan.
So first and foremost, they added some protections for remote access technologies. So if we are using remote access technologies in the cardholder data environment, if that’s allowed, there needs to now be some technical control that prevents the moving or copying of data onto that removable electronic media.
So it really depends on if you’re allowing that type of media in your cardholder data environment and making sure that there are protections that are preventing that from happening.
Next, in 3.5.1.1 in the table, you will see that they added some requirements around hashing of credit card information.
So in the data security standard, organizations can store cardholder data in a compliant way by using one way hashes, strong cryptography, or truncation.
If you are using hashing, this particular requirement now applies.
Those hash those hashes need to be keyed hashes once we get to March of twenty twenty five. So that is something organizations will have to consider if that’s applicable to them.
Next, they explained that if we’re using disk encryption to protect stored cardholder data, it can only be used on removable electronic media. If you’re using that to protect cardholder data, but it’s not removable electronic media, then you need to also protect that PAN with some other type of secure cryptography, either file level, column level, file level, column level, or field level in the database.
Okay. There are some additions to section four and section five. We I kinda lump these together as new protection related requirements because that’s essentially what they are. They’re trying to protect the environment.
So the first one is related to the transmission of cardholder data over open public networks. And, essentially, what they did is they added a bullet in an existing requirement, and they did this in several different requirements you’ll see today. They specifically call out which bullet they added that’s applicable in March of twenty twenty five, so that’s very clear in the DSS.
So what they added for the transmission of cardholder data over open public networks is making sure that our certificates that are used to protect this information are valid, not expired, or revoked. So need to make sure we have valid certificates. Hopefully, that’s not a major issue for most organizations already.
Then we see a couple additional protections in section five, the anti malware section now.
So for removable electronic media, we need to make sure that there’s anti malware solution implemented. So, again, if that’s allowed in our cardholder data environment, there needs to now be anti malware protections on that media.
And then they also introduced a technology requirement associated with making sure that there are controls in place to detect and protect personnel against phishing attacks.
So now that is part of the section five, anti malware section in the data security standard.
This is separate from adding phishing training into your security awareness training. So they talk about phishing now and the DSS in two separate places. One is a technology control, and another is a training control. So this is the technology control.
Next, then we have a couple automation requirements that were added.
And the reason I see say this as automation requirements is because that’s really the best way to describe these two additions.
Previously in versions of the DSS, when you had web applications that were in scope for compliance, you had the ability to use a web application firewall or web application penetration testing. This was the old six six requirement in the DSS.
That requirement is actually gonna be retired when we get to March of twenty twenty five. And what will happen is a new requirement will take effect that says we need to have an automated technical solution deployed that continuously detects and prevents against web based attacks.
So, essentially, having something like a web application firewall sitting in front of your public facing web applications.
So web application penetration testing will not be an option for meeting that requirement in the DSS.
I tell clients all the time, if you talk to a pen tester, they always recommend still doing that testing because having a tool like a web application firewall (WAF) to prevent those types of attacks does not fix issues in our source code or in our development practices. So we wanna also consider the security of that change.
The other automation addition is something that I would expect most organizations probably now already have just because of the burden it is to do this manually.
But they’re specifically calling out having an automated mechanism to perform audit log reviews when we get to March of twenty twenty five. So if you don’t already have some centralized log management system that’s helping with those log reviews, they’re gonna want to see that some automated process is being used there.
These days, it’s just too hard to stay on top of that stuff manually. There’s just too much log information, and environments are are way too big to make sure that you’re being notified of the things that you need to be notified of or those things are catching your attention. So these automated solutions will help that.
Inventory.
They went all out with inventory in version four. So we still have the in scope inventory requirement. We still have the point of interaction device inventory requirement. We still have the authorized wireless access point inventory requirements. Those all stayed.
They added five additional inventory requirements in in version four. So it’s fairly significant, and these things take time, not only to create, but to find a maintainable sustainable process to make sure that they continue to be maintained on an ongoing basis.
So let’s talk about these because it’s definitely something people need to plan for.
Back to section four. So if an organization has the transmission of cardholder data going over open public networks, there needs to be a inventory of the entity’s trusted keys and certificates that are used to protect that transmission.
So that inventory needs to be created and maintained.
Then organizations now when we get to section six, we’ll see an inventory requirement for all in scope, b scope, and custom software.
So this includes third party software components incorporated into our b scope and custom software and making sure that we’re maintaining that.
The whole purpose of this is to help us with vulnerability and patch management. Right? So it’s kinda hard to know what we need to keep it up to date and patched and vulnerability scanned if we don’t know what we have. But I do know that these application inventories can be timely to pull together. There’s a lot of tools potentially involved in in compiling that information, so it is definitely something that we anticipate may take organizations some time to have a repeatable process for this.
Then in section twelve, we see what they call the cryptographic agility requirement. So, essentially, they say anytime we have cryptographic cipher suites and port protocols used to protect cardholder data, We need to have a documented and reviewed process every twelve months to make sure that what we’re using for our cryptographic cipher suites and protocols are still secure, not reaching end of life or status of obsolete, that there’s not known vulnerabilities and issues out there, and having a documented process to review that on an annual basis.
So a new inventory requirement that comes with a review piece to it. Very similar to the next one in 12.3.4.
This one really, I think, kinda goes to there’s a lot of organizations out there that struggle with making sure that the equipment, the software they have does not reach end of life prior to them having to deal with compliance. Right? There was documentation out there for years about, you know, if I’ve reached end of life, how does that impact me for PCI compliance? And it’s not we’re not getting patches anymore that’s the issue. It’s the vulnerabilities that arise from their from those end of life equipment or software packages that cause us compliance issues.
So, essentially, now they’re saying you need to maintain a list of your hardware and your software, and you need to review that every twelve months to make sure that if something is going to reach end of life, you plan for that, and you can replace that and get off of that before you’re introducing a risk to your organization that you can’t properly manage.
So also another inventory type requirement with a review.
And then the bottom one here is colored in green because it actually you’ll see it in a couple different categories that we talk about today. But as a third party service provider (TPSP), they also are will now once we get to March of twenty five, will need to have a documented description of their cryptographic architecture that’s being maintained. So that would have to include their algorithms, protocols, keys, protection of stored account data, strength and expiration date of that information, preventing the use of cryptographic keys in production and nonproduction environments from being the same. So that’s essentially the key that they added here is making sure that if you’re a third party service provider, the encryption keys you’re using in production, you’re not also using in nonproduction. So they took development and test and removed that verbiage and changed it everywhere in the data security standard to be nonproduction.
So now they’re essentially saying, make sure that those keys aren’t the same because sometimes we don’t pull those nonproduction environments into scope, and so their security might not be as strong as our in scope environment.
New access controls is also a very big area where they added quite a bit of requirements in the DSS version four.
First and foremost, seven two four talks about a biannual user access review process.
PCI has never required this in the past. They’ve slowly gotten to this point, but they have never required that people actually do a type of user access review that they might have to do for other regulations like SOC or something to that effect. So now every six months, all of our PCI user accounts, and this is user accounts and their related access privileges, have to be documented and reviewed. And that does include any third party or vendor accounts. So they want people to include those in that process.
They wanna make sure that that access is still appropriate, that their inappropriate access is addressed. And then management actually acknowledges that the access is appropriate. So there’s also a management approval piece to this.
So, again, this is an ongoing maintenance activity. Every six months, this will be required. So depending on when you validate compliance, you need to keep in mind that this becomes applicable in March twenty twenty five, whether or not you’re validating in March of twenty twenty five. Right? So if your next validate if your validation is in February of twenty twenty five, by the time that you get to February of twenty twenty six, you’ll have to show that you were did this twice. So keep that in mind, please.
Next, we see there are several requirements they added for system and application accounts, and they kind of split them into two different categories. So So let’s talk about that. In 7.2.5, essentially what they’re saying here is any system application account and related access privileges are assigned and managed.
So based on their privileges, they wanna make sure that those privileges for those system and application accounts are appropriate. They wanna make sure that that access is limited to the systems applications and processes that were specifically require that use. So having some process in place to verify that is the case.
Then in 7.2.5.1, a subrequirement of 7.2.5, they go on to say that system and application accounts that require access privileges are reviewed as follows. So this is somewhat in line with what we were talking about in our user access review requirement, but they’re letting this review be on a periodic cadence.
So as we talked about in the past, any periodic cadence requirements in version four of the data security standard will have to be accompanied by a targeted risk analysis (TRA).
We will talk about the targeted risk analysis for those periodic cadence requirements when we get to that portion of our presentation today because it is one of those requirements that is a best practice until March of twenty twenty five.
So when you have a periodic cadence requirement in version four of the DSS, every time you will have to justify that cadence with a targeted risk analysis.
So the system and account, system and application account access review currently is set to periodic.
The user account access review that we talked about at the very first one, that is biannual.
When we get into section eight, we also see some additional requirements related to access controls.
At the very first one that comes up is related to password length. So, essentially, what they’re saying here is they’re finally gonna increase password length. It should be a minimum of twelve characters, unless that is, of course, your system does not support twelve characters, and then all you have to do is eight.
I guess that’s better than seven, so we’ll take it.
And it has to contain both numbers and alphabetic characters, so we’re seeing some strengthening of that.
Then we see that they had an addition in 8.6.1 for system and application accounts again. But keep in mind, in this one, they say for system application accounts that can be used for interactive logins.
So if your system and application accounts cannot be used for interactive logins, this requirement would not apply.
If it can be used for interactive logins, that has to be restricted is a good way to specify what they’re saying in those six bullets. Right? Making sure that that’s limited to only people that need access, that they’re approved, that it’s tracked, that everybody knows what’s going on with that.
Then in 8.6.2, you see an another additional requirement for system and application accounts, again, for ones that can be used for interactive logins.
With those particular accounts, they wanna make sure that those credentials are not hard coded into scripts or application code so that can’t be, that that credential can’t be stolen from those locations.
And then last but not least, passwords and passphrases for system and application accounts have to be protected against misuse.
So for this particular requirement, they talk about changing that password periodically.
Again, periodically means you need to have a targeted risk analysis to justify your cadence.
As you can see, they’re trying to add some flexibility, but they wanna make sure that when they’re you’re at when they are adding flexibility, that it’s done in a way that’s defensible and justified for your particular implementation and environment where it really is reducing that risk appropriately.
Not that anybody’s surprised, but there’s a couple new multifactor authentication requirements.
The very first one says that multifactor authentication needs to be implemented for all access into the cardholder data environment.
So in previous versions of the DSS, it’s always said any remote act or any non console access or remote access by administrative staff, all of those types of things had to be covered. Right?
Well, now they’re saying any access into the cardholder data environment (CDE) has to go through multifactor authentication (MFA).
The reason we included the applicability notes here is because they have done a really nice job of including applicability notes for a lot of the data security standard requirements to help clarify what exactly they’re talking about, where this applies, where this doesn’t apply. So anytime you have questions about exactly what they’re saying, always look at those applicability notes and always look at their guidance in the DSS because it really does provide additional clarification that will be helpful there.
Then they also added a multifactor protection requirement, kind of make sure that if you when you are using multifactor authentication, which everybody should be using by now, that it’s set up and configured in a way that’s actually gonna protect you so that those multifactor systems aren’t susceptible to replay accounts, that there’s at least two different factors actually being asked for and that you actually have to have successful authentication of both of those factors to gain access. So things that, you know, typically would sound pretty standard, but you wanna make sure that if you’re using MFA, it actually is configured in a way to provide you the service you’re expecting. Right? So there’s an additional requirement there to make sure it’s configured in a way that’s actually helping.
Next, we have two new requirements that they’ve introduced for eCommerce payment pages.
So one of the things that I found really interesting in the 4.0 documentation is that there’s a little more context in some cases in the self assessment questionnaire (SAQ) guide, ironically enough. So let me explain what I mean. For this require for these two requirements, you would typically think that this would apply to any payment page and and could apply to any scenario.
The first one in section six talks about making sure that payment page scripts that are loaded and executed in the consumer’s browser are managed.
So having a method to confirm that each script is authorized, having a method to ensure the integrity of each script, and then an inventory of all the scripts with a risk written justification of why it’s necessary in that payment page.
This, I would expect, we would think would apply to all payment pages. Pretty straightforward.
Let’s take a look at the next one. 11.6.1
11.6.1 says we need to make sure that there’s some change in tamper detection mechanism deployed in our payment page environments to make sure that if something changes, people are alerted.
We’re we’re actually verifying that the HTTP headers and the contents of the payment page received by the consumer browser is appropriate.
The mechanism is, received to evaluate those HTTP headers and the payment page. And then this is performed at least every seven days or periodically based on your risk analysis.
Now, again, it just says applies to any payment page. When you look at a self assessment questionnaire type a under version four, you will notice that in the notes and in the SAQ completion guidance, because in those self assessment questionnaires, they’ve now added notes and SAQ completion guidance.
It actually calls out the fact that if you’re using a URL redirect, eleven six one is not applicable to you. It’s only applicable to iframe environments in an SAQ A.
So I would similarly say that we should pay a lot of attention to what’s in the SAQ AEP around that requirement as well.
This is the first time we’ve seen a distinction being made between those two outsourcing mechanisms.
Previously, as far as the SSC is concerned, URL redirects and iframes were seen as the same type of outsourcing scope reduction, risk reduction.
Now we’re seeing there’s a bit of a variety in the self assessment questionnaire documentation to explain that where iframes, you absolutely should be doing change detection mechanisms. They do not expect you to do that through URL redirects. So I found that very interesting, and I wanna make sure people are aware there’s some additional guidance in those FAQ documents that will be helpful.
Next, we see a requirement that’s being added for all organizations. This is something that was previously already being required for third party service providers since version three. So, it might have been version three one.
But, essentially, any critical security control needs to have a process in place to tell people if it fails. So they wanna make sure that employees are aware if a critical security control in your PCI environment fails and that there’s some process documented to follow-up on that. They have a very specific list of examples for network security controls related to PCI.
They added a couple things to that list in version four. So they added audit log review mechanisms because now we’re seeing it’s an automated process they’re asking for and automated security testing tools if used.
So those failures also would need to be reported as part of a critical security control failure.
If one of your critical security controls fails in a calendar year, what they expect you to do is included in that next requirement in ten seven three, where they explain that anytime that happens, that bulleted list is what people should be doing to make sure that they’re restoring the functionality. They understand the risk that was imposed to the organization during that failure. If there’s a root cause that needs to be addressed to prevent that reoccurrence, that that’s looked at, a risk analysis is done. So there’s very specific documentation that’s required for PCI purposes if one of those controls fails.
Like I said, this was previously required for service providers, and so what we will see is that it’s gonna be a retirement again like what they did with the 6.6 web application penetration testing requirement.
After a certain period of time, the old requirements will phase out, and these will be in the new requirements that apply to everybody. Again, that period of time is March of twenty twenty five.
Next, we have a couple new vulnerability scanning requirements. I’m sure everybody can’t wait for these two.
Okay. So first and foremost, something everybody needs to be aware of. If you are not already doing authenticated vulnerability scanning, authenticated vulnerability scanning may find more than your current scanning is doing without authentication.
So be aware. Okay? One of the new requirements is that internal vulnerability scans will have to be authenticated once we get to March of twenty twenty five.
So, again, depending on when you validate compliance, you wanna make sure that this control is in place by March of twenty twenty five because you will be expected to show authenticated vulnerability scans for any quarter after that.
Then they added an additional requirement in here, and the reason that it’s showing up here is because we’re we see it again in a different section, so that’s why it’s highlighted in green. So it’s in two of our categories.
But they previously said you have to address all high risk vulnerabilities from an internal scanning perspective.
Now they’re saying you have to address all other applicable vulnerabilities that are not ranked as higher critical based on your targeted risk analysis.
Right? So whenever we see periodic, we have to think we need to document the the justified cadence for this.
So a targeted risk analysis will need to be developed to say, we’re gonna address all other vulnerabilities from an internal perspective not classified as high in this cadence based on the criticality to the environment, applicability, anything like that. So, again, both of these requirements are gonna be something that’s needs to be in place by March of twenty twenty five. This is an ongoing process technology change.
Because the authenticated scans can find more vulnerabilities than regular internal vulnerability scans can, we highly recommend that this is something you start doing sooner rather than later to ensure that you don’t fall behind that March twenty twenty five deadline.
So I mentioned earlier that there’s a new security awareness training requirement. There’s actually three new security awareness training requirements. One of them is related to phishing.
But there’s a couple others as well. So 12.6.2, they actually want organizations to review their security awareness programs on an annual basis.
So make sure that whatever your security awareness program includes, the training that’s being included, how it’s being addressed, gets reviewed annually to make sure it’s still appropriate for what you’re seeing as risks to your organization.
If you’ve run into situations where people are not following policies or processes, as they should be. Maybe additional training is needed in those areas. So this is really an effort to make sure that your security awareness program is addressing everything it needs to, not only from a compliance perspective, but from a business risk perspective.
Then they wanna make sure that the security awareness program is including phishing and social engineering related attacks.
So if you’re not currently training your staff on phishing or social engineering attacks, that’s something that you’re gonna need to add to your existing security awareness program by the time we get to March of twenty twenty five.
Then we need to make sure that our security awareness training program talks about the acceptable uses of end user messaging or I’m sorry, of end user technologies.
So this is something that wasn’t previously required. The acceptable use policy was previously in section twelve that that has kind of shifted and morphed a bit in version four, but they never previously said that your security awareness training actually has to cover acceptable use of technologies.
So they’ve clearly called that out as a new distinction for that security awareness program, make sure there are acceptable use policies are discussed and people are aware of what those acceptable uses are.
Pretty logical.
Then we see a few new requirements related to incident response.
So one of the things that they do did was update some of their training in the incident response or update some of their verbiage in the incident response requirement at the very top of section twelve ten.
Instead of calling out a breach, they they’re now talking about a security incident.
So there’s some slight verbiage changes there, but the biggest changes are really, what they’re asking us additionally to do.
So the incident response plan currently requires a periodic incident response training requirement.
Have you noticed when I say periodic, you say targeted risk analysis? Okay. Hopefully, we’re we’re getting that theme. So anything that has a periodic cadence, including incident response training, now needs to have a targeted risk analysis associated with it.
Then the security incident response needs to make sure that it’s monitoring and responding to security alerts and security systems. So that was something that was previously included, but they did add a bullet. So it’s another one of those requirements where they added a bullet that’s applicable in March in twenty twenty five.
Related to changes being detected on our our on our payment pages.
So if we detect a change on our payment page, we need to make sure that that potentially has procedures in our incident response plan for how we address that and triggers the plan as necessary.
Then in 12.10.7, the incident response plan (IRP) actually has to have some documented process for the detection of stored cardholder data where it’s found to be outside of approved channels.
So if you’ve worked with me from a PCI compliance perspective, you’ve probably heard me suggest this in the past.
We can’t prevent what people send us, but we can change our reaction and how we address that. Right? So when organizations stopped receiving or wanted to stop receiving credit card information over email or wanted to start stop receiving mail in coupons, Sometimes there were periods of time where people didn’t know that and still would call in or still send that information in. What we’ve always recommended in this case is have some documented process in place to explain how you get rid of that information.
Essentially, what PCI is is explaining now is either you pull that into scope for compliance and make sure everything is compliant or you have some documented process for how you make sure that information is removed, no longer persistent in the environment, employees are trained, the person is communicated back with to explain that this is no longer an approved channel. So just having a way to address that, a documented procedure that people can use if that happens to make sure that people know how to address those types of situations.
If you don’t receive any of this information and that’s never happened in the past, then it might be a more, IT specific procedure document. But if that has happened in previous areas of your business, that might be a good team to sit down with and talk about, you know, how do you find out about this, who do you call, making sure that all of those pieces are known and communicated properly.
Now we see that they’re starting to pick on third party service providers.
There are several new requirements applicable to third party service providers. And I think I said in in the last webinar series that it typically, when we see them introducing things for third party service providers, we start to see them introducing it for everybody else. So we saw that with the critical failure security requirement. Right? That’s been something third party service providers have had to have in place for several years. Now they’re expanding that to all PCI organizations.
So be aware as we see additions again to third party service provider requirements, even if you are not a third party service provider and you are just a merchant, it might give us some clues into where we might see future iterations of the DSS Go.
So the first one we had talked about, this is related to third party service providers documentation around their cryptographic architecture and making sure that, the prevention of the use of those cryptographic keys in nonproduction and production is specifically called out.
Next, we go to section eight for the next third party service provider only requirement.
So, essentially, what they’re saying here is if a third party service provider has passwords or passphrases that are used as the only authentication factor for customer related accounts, and this is the third party service provider’s customer, not consumer, okay, then those passwords would have to be changed at least every ninety days or they would dynamically have to assess real time access needs for that account and determine accordingly if they should get access.
So, essentially, this is for client or third party service providers that have customers that use their environment. Those accounts are the ones that they’re talking about here, not end consumers, not the third party service provider employees themselves.
Next, we see 11.4.7, which is actually a new requirement for multitenant service providers.
So multitenant third party service providers are gonna need to support their customer’s need for external penetration testing.
So you will see a bit of a theme with the next several requirements here. They want third party service providers to support their customers’ needs for compliance.
Something that, unfortunately, we keep hearing has been a struggle for many, many organizations. So I do hope that some of these additions will help alleviate some of that concern.
Next, we see that third party service providers in 11.5.1.1 will need to have intrusion detection and intrusion prevention capabilities to detect, prevent, and alert on covert malware communication channels.
So actually blocking that type of communication, detecting it, preventing it, actually having something in place to restrict that.
Then as another sub requirement to the twelve five two secondtion, third party service providers are going to have to scope their environment every six months.
So there is a new requirement that’s applicable immediately that we talked about on our last webinar that talks about every organization performing a PCI scoping exercise.
So every organization will have to do that, but the first time they validate compliance with the four point o assessment.
Third party service providers, once we get to March of twenty twenty five, we’ll have to start doing that every six months.
And they specifically call out significant changes to the in scope environment as something that would cause them to do that on a six month basis.
Right? So making sure that they’re doing that every six months. And if there’s a significant change in between those, they’d have to do it again.
And then in twelve five three, we see that third party service providers that have a significant change to organizational structure must document their PCI scope impacts.
So if we had significant changes to our organizational structure as a third party service provider, we need to make sure that people understand the accountability and the responsibility they have for PCI compliance. They wanna make sure that another scoping review is done, wanna make sure that those new resources are aware of what responsibilities they have to maintain compliance for the organization and make sure that they’re accountable for that.
Okay. So we’ve talked a little bit, just a little bit, about targeted risk analysis for periodic cadence requirements.
So the targeted risk analysis requirement is actually the bottom one in this table. The 12.3.1 requirement is the one that specifically talks about each PCI requirement that provides flexibility in your cadence with the use of the verb or the use of the description periodically has to be supported by a targeted risk analysis that documents and includes justification for that cadence.
The interesting thing about version four and targeted risk analysis is there are two different types.
The ones dealing with periodic cadence requirements, 12.3.2, is not required until March of twenty twenty five for any of the periodic cadence requirements.
But the list that you’re seeing in that bloated list on that last row is different than the targeted risk analysis that is in the bottom of the data security standard.
So there is another targeted risk analysis and requirement 12.3.2 that’s now on screen that talks about if you want to validate compliance with the customized approach, you have to document a controls matrix and a targeted risk analysis. And they provide appendices in the DSS that provide you with the information that needs to be included in that targeted risk analysis.
That’s about, like, three pages of content in the bottom of the data security standard in appendix d and e.
This targeted risk analysis for periodic cadence requirements is different. There’s different things that are required.
The bullet list you’re seeing on screen is what they require you to include in this one. This is all you have to include for these periodic cadence requirements. However, if you are gonna use the customized approach, that’s when you have to use the one in appendix d and e. So it can be a little confusing. I do think the council is probably gonna put a frequently asked question article about this very topic on the website at some point because it came up in discussion when I got to see a couple of council members last week, and they agreed it was a little confusing.
So I wanna point that out.
The other thing you’re seeing on screen are some of the targeted risk analysis requirements in here. So you’ll you’re seeing the one for, malware, specifically for systems that are not at risk for malware.
So for those components, if you have in scope components that are considered not at risk for malware, you need to have some periodic cadence where you are reviewing if it’s still appropriate to not have malware on those components. Right?
The cadence of that review is now something you have to justify with the targeted risk analysis.
Also in section five, if you’re perform performing periodic scans, now that period of periodic has to be defined and justified by a targeted risk analysis.
Then when we get to section nine, we see the point of interaction device inspections. So it used to be nine nine, now it’s a 9.5.1.
Those inspections, the frequency of those inspections now has to be justified by a targeted risk analysis.
So making sure that especially if you have a lot of different locations where you have point of interaction devices, You wanna make sure that the targeted risk analysis documentation for this takes into account all those different unique scenarios if some have higher risk, situations than others. So definitely something to keep in mind.
And then your periodic log reviews for anything that you’re not doing daily log reviews on. Essentially, if it’s a connected system and it’s not storing, processing, transmitting cardholder data, or providing security controls, or needing to be part of your daily log review, you have the option of doing periodic log reviews, but you need to justify that cadence on the targeted through a targeted risk analysis.
And then, again, we already talked about this one, but the vulnerability scanning requirement for all other vulnerabilities for internal vulnerability scans.
I believe there is one more that I might have missed on this slide. It’s a requirement in in requirements related to incident response.
The incident response training has to be justified. The periodic training has to be justified on a targeted risk analysis as well. So there are six potential DSS requirements that organizations will have to develop targeted risk analysis for to determine if their cadence for those requirements are appropriate, but only if those requirements are applicable to you. So you don’t have to go through that exercise if you’re like, well, I’m not doing this anywhere. This doesn’t apply to me anyway. You can still mark those things as not applicable.
Alright. So that was a summary of all of those requirements. Let’s talk about some of the things that we should be aware of as we are planning to move to four point o.
As I mentioned, there were quite a few technology based new requirements in the DSS.
Some of these may cause organizations to have to invest more in the technology they’re currently using or invest in a solution that they don’t currently have.
So we wanted to make sure that people were aware that there potentially are some additional risks or additional risks to our budget coming with version four requirements.
If we need to increase what we’re using or the technology licenses, how, you know, how much of a solution we’re using, that potentially increases that solution cost to our organization.
So we wanna make sure people are thinking through these. This is a list of those items that could potentially cause organizations to have to increase their spend for PCI compliance in the future.
Things like sensitive authentication data storage, prevention of moving of stored cardholder data to removable media.
If we’re using hashing, making sure those hashes are keyed for production of cardholder data.
If we’re using disk level encryption, make sure making sure that we’re also using field level encryption. So a lot of those are gonna be really dependent on that specific implementation.
Making sure anti malware is is in place for removable media. If you don’t have something like that to address that solution yet, you will need to have something.
Then we’re gonna need to have protections for phishing attacks from a technology perspective as well as making sure that that’s part of our security awareness training, which can also increase our security awareness training cost.
The web application firewall, hopefully, most people already have that, but if you do not already have a web application firewall, that, that will come with a new solution cost.
The page payment page script management.
The majority of clients that I have talked to so far feel that they will have to look at some sort of solution to help aid in that particular requirement and to build that inventory, to manage that inventory.
I haven’t found anybody that feels that they can do this in an effective way manually, so it’s definitely something that I do anticipate organizations will have some additional cost for.
Multifactor authentication (MFA), if it’s not currently expanded everywhere, it will need to be for the cardholder data environment that could potentially come with additional licensing costs. And then the system and application account management, I mean, adding that into the data security standard is a great new addition. I’m really glad to see it in there, but there’s a lot of organizations out there that are still dealing with those types of accounts that have interactive logins. There’s not a lot of management that I have seen around those unless people have made a specific effort to address them. So that might be something where you’ll you’ll see some, authentication management solutions come into play, especially with the the password rotations and things like that.
The automated log reviews, I’m hopeful that most people have those things in place already because it’s just too burdensome to do it otherwise.
The authenticated vulnerability scanning, my understanding is that it’s an additional cost to do authenticated scanning. So something to be aware of, something to look at with your vendor, try to figure out what that additional cost might be.
Making sure that IDS and IPS is used to convert covert used to prevent covert malware communications.
Some some IDS, IPS solutions might have additional costs associated with modules or functionality that you would need to add on to have that.
And then, of course, our change in tamper detection mechanism on payment pages, we expect that organizations will need some sort of tool or mechanism to be able to do that efficiently as well. And like I already mentioned, the security awareness training to cover phishing and social engineering.
And then some process considerations as well. So as we mentioned, there’s quite a few new requirements coming with inventories.
The difficulty with inventories is not only pulling that information together, but keeping it up to date and maintaining it. So having some way to do that in a easy to use process or with tools that are already in place would be really helpful. Otherwise, we’re creating whole new processes that people previously haven’t been managing.
So something to please plan on and and start talking to teams about and figure out what’s gonna be the most sustainable way to do that. That’s gonna apply to the keys and certificates as well as the b scope and custom software. The other one that I think will be somewhat tricky is preparing for the end of vendor support requirement where we have to have hardware and software inventories maintained and reviewed annually, know where when our vendor end of life timelines are, make sure people are aware of that and planning for those changes. So I think these are some great new requirements, but are definitely gonna come with some time needed to put these recurring processes in place.
Then the user access account review. So, organizations that have other regulatory requirements may already be doing this because other regulations already require something like this.
However, if PCI is the only compliance obligation you have, you may not already be doing a user and access account review on a regular basis, so you’ll need to develop a process for that. And then, of course, the system and application account management as well.
From an ongoing maintenance perspective, there’s some additional processes to be aware of. The PCI scoping requirement is definitely one of those. That effort that organizations will have to go through annually before validating is something that will need to be thought through and put some time into as well as making sure that can be maintained on an annual basis.
The targeted risk analysis or customized approach as well as the periodic cadence requirements.
So our next webinar session next week actually is gonna do a deep dive into the TRAs, the targeted risk analyses for PCI that are being required. We’ll talk about the difference in the two scenarios.
We’ll talk about how that can be done in a way that’s gonna protect your organization from a compliance obligations perspective as well as protect your your organization from a business needs perspective.
So looking at how you can do those targeted risk analysis in a DoCRA (Duty of Care Risk Analysis) risk assessment method to help organizations balance that.
And then, of course, the vulnerability management requirements.
It is very typical for us to see that when people switch over to authenticated vulnerability scanning, there’s quite a bit more that they were not previously identifying. So the sooner you can start to get in a cadence where you can do that authenticated scanning, obtain passing results is gonna be really helpful to the organization to make sure that once you reach that March twenty twenty five date, you’re not scrambling to try to address vulnerabilities that have been out there, but you just didn’t know about because you weren’t doing that that authenticated scanning.
As well as making sure that all other vulnerabilities are being addressed in an appropriate time frame, PCI was, was pretty clear for very long that only those high risk internal vulnerabilities had to be addressed. So that’s gonna be a fairly significant add on to the organization.
You wanna keep in mind that whatever cadence and whatever time frame you set up for that, you’re gonna have to be able to meet that. Right?
So it might make sense to, you know, see and test it out before you document what that cadence is and and use that testing of that as part of your targeted risk analysis justification.
How did you get to that cadence? Why is that appropriate?
So quite a bit to think about before we get to March of twenty twenty five.
What questions do people have?
Hi, everyone. I’ve unmuted or I’ve enabled your mic, so you just have to unmute it yourself. Also, I have posted next week’s session in the Q&A section. So if you haven’t already signed up and you would like to, just go to the top and click on q and a, and the link will be there.
Thank you, Rachel.
There’s a lot of information today.
We’ll make sure that everybody has a copy of this presentation deck as well.
You can also find in the summary of changes document on the council’s website that’s a little shorter than the new version of the DSS.
There’s, tables in there that include all those new requirements, but I do encourage organizations to look at the self assessment questionnaires (SAQs) that apply to them under version four because I really was impressed by the additional SAQ completion guidance and notes added into those different self assessment questionnaire questions.
Okay. Well, it looks like we don’t have any questions today unless, Rachel, you saw any comment through your side.
Otherwise, we’ll None so far.
K.
Well, if anybody needs help with this in this, transition, please don’t hesitate to reach out. We’re always happy to help, and we’re we’re just excited to get this information out there and let people start thinking through what they need to be doing before we get to this deadline. So thank you all for joining us today, and we hope to see you on a future webinar series.
