PCI DSS SAQ Comparison from PCI DSS v3.2.1 to PCI DSS v4.0

Presented by Viviana Wesley, PCI QSA, ISO 27001 Auditor, CISM

Key differences between PCI DSS SAQs v3.2.1 and v4.0 lie in their approach toward compliance, flexibility, and clarity of security goals:

• PCI DSS v4.0 SAQs aim at a goal-based approach, and companies can use customized implementations if they can achieve the stated security goals, as opposed to v3.2.1, which was prescriptive.
• v4.0 introduces updated requirements to address modern threats (e.g., enhanced authentication, advanced encryption requirements), and fits better with evolving security practices.
• Format and terminology have been enhanced in v4.0 SAQs for improved clarity, and some SAQs now have additional controls previously lacking, such as vulnerability management of redirects or scripts.

In short, v4.0 has a more flexible, risk-based, and outcomes-driven approach as compared with v3.2.1’s somewhat checklist-oriented approach.

TRANSCRIPT

Hello, and thank you for joining us for our last PCI DSS 4.0 webinar.

Today, we’re gonna be do covering the SAQ comparisons from version 3.2.1 to version 4.0.

Again, my name is Viviana Wesley. I’m a principal consultant with HALOCK Security Labs.

I’ve been our PCI subject matter expert for several years, and I also serve as an expert witness for state offices of attorney generals and multi district litigation matters. I started in nineteen and have been in information security for over thirteen years.

For our agenda today, we’re gonna have a quick introduction, then we’re gonna go through the SAQ comparisons and guidance by each SAQ type. And then there’s a summary at the end, and we’ve, of course, left some time for questions as well.

So let’s first start about talking about the transition timeline.

What what we often refer to as a PCI transition timeline is typically a a two to three year timeline. When they release new versions of the data security standard, then we are, looking at a period of time to transition to the new version and then even a longer period of time for some of those future data requirements.

So currently, we’re still on version three two one of the data security standard. By March of next year, all organizations are gonna need to validate against version 4.0 of the data security standard. And then by March of twenty twenty five, every organization will have to make sure that all of those future data requirements are in place. So let’s do a quick version four requirements overview. As we’ve discussed in previous, webinar series, there’s a total of sixty four new requirements, fifty three of which of those are applicable to all entities, whether you’re a merchant or a service provider.

There are eleven new requirements only applicable to service providers.

Thirteen of the sixty four requirements are applicable or effective immediately for all organizations for 4.0 validations.

There’s one new requirement that’s applicable only for third party service providers (TPSPs) when they are validating against 4.0 right away.

And then there’s fifty one of those sixty four requirements that are not effective until March of twenty twenty five. So that does give us time to implement those new controls.

Most of the existing PCI DSS requirements were updated or moved or removed or added additional guidance as part of this version release. So no matter what, please make sure that you take a look at those DSS requirement details. There’s a lot more information in v4.0 of the data security standard that there ever was, more guidance, more good practices, examples, more clarification information to help people understand what they’re really looking for.

We’ve discussed this in previous webinars, but now with the new version 4.0, there are eleven new roles and responsibility requirements. So every section one through eleven now have a new roles and responsibility requirement effective immediately. So that’s something organizations will have to look at right away.

Also, one of the things to keep a note and keep in mind is the SAQ types for four point o have not changed. So we still have the nine SAQ types we had before.

Today, when we are doing our overview of comparisons, we’re comparing every SAQ type except the SAQ d because that’s essentially everything in the DSS for merchants or service providers. So we’re not doing that full comparison, but every other SAQ type we will go through today.

The SAQs now include additional guidance related to applicability and SAQ completion, which I found very, very helpful, and we’ll talk about some nuances we’ve identified in there in that guidance as well.

Like I mentioned, we are gonna go through the seven different SAQ comparisons that we’ve completed.

We’re gonna go through those alphabetically. So we’ll start with the a and go all the way to P2PE. And then because there’s so much guidance now in the self assessment questionnaire documents themselves, we highly recommend that every organization look through those documents, read the self assessment questionnaire, make sure that they understand that additional guidance, that additional information. And then if you have additional questions related to controls or requirements you’re seeing in those SAQs, please go back to the PCI DSS itself and read that in the DSS.

As I said, they’ve added a lot of context around guidance, support, examples, so it’s very helpful.

Okay. Let’s dive in with the SAQ A.

The first requirement we see that was introduced or added to this SAQ type is requirement three one one. So I mentioned that there’s a new roles and responsibility requirement. One of the other things they did is for every section one through eleven, they moved the requirement that was at the bottom of the DSS for each of those sections that said make sure security policies and operational procedures for that section are documented and used known to affected parties. They push that requirement to the top of each section, and they added a bullet point. That bullet point is kept up to date.

So, essentially, what they’re saying is the documentation that you submit for PCI has to has to be kept up to date. You have to be able to show that you’re reviewing that and keeping it up to date. If you don’t have a change to that document in the past year, you have to at least show that a review had occurred so you can make sure that it’s still updated. Right?

So if you’re already doing this, great, you’re set. Now you also have to keep in mind where this requirement is being asked of. Right? So this requirement is in section three.

This is related to cardholder data storage. If you are not storing cardholder data in the environment, excuse me, especially for an SAQ A eCommerce outsourced environment, then this requirement might still be not applicable to you. Right? So you don’t necessarily need a data retention policy if you’re not storing cardholder data.

You’re not necessarily going to have security policies and operational procedures for requirement three if that’s not applicable to you. So really what you should be doing is determine if it’s applicable, then make sure you have the right documentation in place, and then make sure it’s being kept up to date.

Next, we’re seeing there was an additional requirement in section three as well for SAQ A’s, and this is related to account data storage being kept to a minimum through the implementation of data retention and disposal policies and procedures.

So this, again, is based on if you are actually storing cardholder data. What they did add is that bullet that’s in orange, that’s a best practice until March of twenty twenty five. And essentially what that bullet says is if you are storing sensitive authentication data prior to the completion of authorization, then you have to have a data retention policy, disposal policy procedure around how you’re dealing with that. So, again, this is really going to relate to if that is something that your organization is doing, if that is applicable to you. If it is not applicable to you, you probably have some documentation that says do not store this information. That should still be sufficient.

So, hopefully, not much of an impact there to SAQ A merchants.

Next in the SAQ A, we see an addition of the security vulnerabilities being identified. So, essentially, this is previously this was previously a requirement in the DSS. This was this used to be requirement six point one where they said make sure that you’re staying on top of emerging vulnerabilities and that you have a risk ranking process, that you’re getting information from reputable outside sources, that you’re taking that information and determining what that risk ranking is based on your organization and then determining how you’re gonna remediate that.

This particular requirement was added to this SAQ type to ensure that this is being addressed for outsource ecommerce environments. So if you take a look at that middle column in this table, this is straight from the self assessment questionnaire. Like I mentioned, the self assessment questionnaires have now a quite a few SAQ completion guidance columns or notes and comments that they’ve added. So they explain that for an SAQ A, requirement six applies to web servers that host the pages on the merchant’s website that provide the address, the URL, of the third party service provider’s (TPSP) payment page form to the merchant’s customer.

So they’re specifically explaining that this requirement applies to that web server in the merchant’s environment that’s integrating to that third party service provider.

Next, we see a couple more additions and requirements in in section six and section eight.

So in section six, this is a a new requirement in SAQ A’s as well. This is, a best practice requirement until we get to March of twenty twenty five, and it essentially says that all payment page scripts that are loaded and executed in the customer’s browser are managed as follows.

So what they’re saying is that there needs to be a method in place to confirm that each script is authorized, to assure that the integrity of the script is being maintained, and to inventory all the scripts for any of your payment pages with written justifications as to why it’s necessary.

In the applicability in the SAQ completion notes, they explain that this requirement applies to all scripts loaded from the entity’s environment and scripts loaded from third and fourth parties.

Then in the SAQ completion guidance, they explain that this applies to pages on the merchant’s website that provides the address from the third party payment page form to the merchant’s customer.

I have seen some articles out there already that are saying, oh, payment page scripts should be the third party’s responsibility, not the merchants. And this, again, is why I’m very glad that the PCI Security Standards Council has added this additional completion guidance because I think it’s very helpful to help organizations really understand what their intent here is. So this particular requirement is in line with what they’ve been trying to say since twenty seventeen. Right? Organizations need to make sure that when you’re integrating to a third party service provider, you’re making sure that that integration is maintained, is authorized, that only loading page payment pages that are being, verified and the integrity is correct and it’s necessary. Right?

Since this is a best practice requirement until March of 2025, this is something organizations should start planning for. This is also something organizations should talk to the third party service providers about to understand where that responsibility split will be. As we noted in the applicability notes under the requirement, they’re saying that this applies to your merchant scripts as well as third and fourth parties. So there might be a shared responsibility that organizations have with their third party service providers for the 6.4.3 requirement.

Excuse me. I’m a little sick today, so please bear with me. In section eight, we see the first new addition in here that basically explains that now if passwords and passphrases are used as authentication factors to meet a three one, They need to be set to a unique value upon the first time, upon resets, and forced to change immediately. So, essentially, what they’re saying is on the merchant web servers, the web servers that are hosting the integrations to your third party payment providers, that we have to have some additional authentication password complexity controls.

So this particular requirement is related to resetting people’s passwords or setting up new accounts on those servers and making sure that that password is set to a unique value the first time and is forced to be changed immediately after that. So they’re adding additional password complexity requirements for the merchant’s web servers. So that’s definitely something you want to be aware of, want to make sure that process is in place.

There’s a couple additional requirements and or a few additional requirements in section eight in the SAQ A we need to talk about.

The next one is related to password complexity. So they are increasing password complexity for PCI compliance, in in a kind of a strategic way. Right? So, essentially, they’re saying the minimum length of passwords should be at least twelve characters, or if the system does not support twelve characters, then you have to go to a minimum length of eight characters. So not much stronger than the seven characters we previously had. It needs to contain both numbers and alphabetic characters.

It does explain that this is not intended to apply to point of sale terminals, user accounts on point of sale terminals that only facilitate one card transaction at a time.

And then it also explains that this is a best practice requirement until we get to March of 2025. So we do have some additional time to plan for this particular requirement.

In the SAQ completion guidance, it explains that this applies to the merchant’s web server that’s hosting that integration. So, again, they’re telling you exactly where this requirement applies.

For eight three seven, they explained that individuals are not allowed to submit a password or passphrase that’s the same as any of the last four. So they didn’t change the password history requirement in DSS from version three two one to four, but they did add it to this s a to this SAQ type. So now merchants’ web servers that are hosting integration to third party service providers need to make sure that they are using a password history setting of at least four for any users that have access to that component.

The last requirement in section eight that SAQ A talks about is the one that deals with only having one potent potential authentication factor for user access.

If that is the case, then password passphrases have to be changed at least every ninety days, or the security posture of the account needs to be dynamically analyzed and real time access to resources is automatically determined. So essentially, they’re they’re kind of describing zero trust. K? So they’re saying for the web server that’s hosting the integration to your third party service provider, we need to make sure that we have a password change requirement that is every ninety days or using some sort of dynamic analysis to make sure that act that access is authorized properly.

They again have some applicability notes. They’re very helpful here to explain that this is, this requirement applies to in scope components that are not in the CDE because those components are not subject to MFA requirements. So it’s kind of an interesting statement. Right?

This requirement is not intended to apply to user accounts on point of sale terminals where you’re taking one transaction at a time, and this requirement does not apply to service provider customer accounts, but does apply to accounts for service provider personnel.

I think the SAQ completion guidance does a better job of kind of explaining what they’re looking for here. They do explain in there that this is intended to apply to the merchants’ web servers that host the integration to the third party service provider. So you are seeing a lot of that guidance be really helpful here.

Then in the SAQ A, they also added a requirement in section nine related to offline media backups.

So if there are any offline media backups that contain cardholder data, you wanna make sure those are stored in a secure location.

They do explain in the notes that this requirement only applies to merchants with paper records, for example, receipts or printed reports with account data, including the primary account number. Now the reason for that is if you’re storing cardholder data, you’re not eligible to use this SAQ type. So there’s no you know, you shouldn’t be doing that.

But at the same time, they are saying if you are storing those paper records or if you’re storing those removable media data with backups, then you do have to make sure that you’re storing those in a secure location. So you need to make sure if this is applicable to your organization, you have those controls in place.

They do have some additional SAQ completion guidance that they also do explain that if you never store any paper with account data, then you can mark this requirement non applicable and then explain that down below in the appendix of the self assessment questionnaire type. So it’s really all dependent on whether or not any storage of cardholder data exists in your environment.

Then in section eleven, we see a new requirement for SAQ As that was not previously asked for at all.

So this one may be slightly significant for some organizations.

External vulnerability scans will be required for organizations that are outsourcing to third party service providers.

Historically, merchants with outsourced ecommerce sites were not required to conduct external vulnerability scans.

So one of the things that organizations should be thinking about is it what exactly is my outsourcing that allows me to use this SAQ type? Because keep in mind, an SAQ A can be used for an organization that is wholly outsourcing their PCI compliance to a third party service provider or outsourcing their ecommerce environment through a URL redirect or an iframe.

So in some cases, this may apply to servers that are hosting those third party integrations for ecommerce outsourcing.

In other cases, organizations might not have this requirement be applicable to them because there’s nothing in their PCI DSS environment in the wholly outsourcing their environment to other other parties.

So you really need to make sure that you understand what that third party service provider relationship is, what that responsibility split is. They also have quite a bit of explicability notes in this one. I think that’s why there’s not so much SAQ completion guidance with this particular requirement.

In the applicability notes, they explain that if this is your first PCI compliance validation, you are not required to have all four passing scans. You can just do one. However, after your initial validation, you are required to have a passing passing vulnerability scan at least every three months.

In case you did not know, the PCI DSS v4.0 now has a table in the front of it that talks about all the timelines.

So when they say every three months, they really mean every three months, they’re talking ninety to ninety two days apart. They want that window to be that tight.

And then they also explain that an ASV needs to be used for the scanning because it’s external vulnerability scanning.

Since this is not a new emerging requirement, this is a new applicable right now requirement, this is something that organizations will have to make sure is in place for their first PCI DSS validation under four point o. So you should definitely start planning on this if it is applicable to your organization sooner rather than later.

Then along the same lines, if there’s a significant change to your PCI environment, you would have to do an external vulnerability scan after that significant change occurs. Right? So, again, historically, this was not included. This was not required, and so you want to make sure that this process exists.

If you drastically change your outsourcing or drastically change something with your PCI environment, you’re gonna have to do an external vulnerability scan if there’s still components in scope for your PCI environment. If you’re fully outsourcing your environment, again, this might not be applicable to you. So it’s really just dependent on exactly how your environment is set up, what your outsourcing is.

Next in the SAQ A, we see the additional requirement around payment pages and making sure that tamper and change detection is being used to ensure that that auth that integration is not being changed without authorization.

So back in twenty seventeen when the council released the best practice guidance for outsourced ecommerce environments, they made a recommendation in there that said you wanna make sure that those integrations don’t change. You need to have some sort of process in place to make sure that there are no unauthorized changes to those integrations.

Now this is going to be a full requirement in March of 2025, so it’s not a applicable right now requirement. It’s one of those things that they’ve pushed out until twenty twenty five, but it is something organizations should be planning for.

They do have additional applicability notes and SAQ completion guidance here.

The thing that I found to be quite interesting is in the top note for this particular item in the SAQ A, it explains that this applies to merchants that include a third party payment provider’s inline frame or iframe payment form on your website.

Then in the SAQ completion guidance, at the bottom of this requirement, they explain if a merchant is using a URL redirect, where the merchant hosts the page on their web server that provides the address, the URL of the merchant’s payment page form, to the merchant customer, the merchant marks this requirement as not applicable.

This is the first time I’ve seen them make a very distinct a a big distinguishment between the iframe and URL redirect in integrations.

They’re essentially saying, if you’re using an iframe, this is applicable. If you’re using a URL redirect, you don’t have to do this.

So something to be aware of, they’re they are seeing a difference between those two integrations, and it’s it does sound to me like they’re recommending URL if URL redirects versus iframes for ecommerce outsourcing.

Again, this is a requirement that is not applicable fully until March of twenty twenty five, so people do have some time to prepare for this. But it is something that our organization has been recommending to cost to our clients since their guidance came out in twenty seventeen. So this is hopefully something organizations are already considering or doing.

Alright. So that was SAQ A changes. Let’s talk about the SAQ AEP.

In the SAQ AEP, there was quite a bit more that changed.

We’re seeing several new requirements that were added to section one or and section two of the DSS.

First and foremost, like I mentioned before in the SAQ A for section three, they moved that security policies and operational procedures requirement to the top of the section. So now that is the first requirement in section one. They added a bullet to say keep those documents up to date.

They didn’t add any additional SAQ guidance in in their SAQ documents on that one.

Then they added additional requirements around configuration standards and how we’re managing our configurations for our network security controls.

So the firewalls and routers was replaced with the term network security controls throughout the DSS.

So anytime you see the acronym NSC, that’s what it stands for. Network security controls.

Essentially, that’s any sort of networking control that is providing the type of security restrictions and traffic restrictions like firewalls and routers typically previously have in the past. Now that we have a broader range of technology, they wanted to make sure that their terminology aligned with that better.

So we are seeing some additional requirements around making sure that the configuration standards for network security control rule rule sets are defined, implemented, and maintained.

Also, that configuration files for for NSCs are secured from unauthorized access and kept consistent with active network configurations.

So in in one two eight, they actually kind of replaced that requirement a bit and and broadened it. Right? So they they basically instead of saying just make sure your router rule set or router configuration files are, synchronized, now they’re saying the full configuration of any of your network security controls are synchronized and consistent with your active configurations and secured from unauthorized access.

Then they, then they also added system components that store cardholder data are not directly accessible from untrusted networks.

So, essentially, if you have any cardholder data storage in your environment and you are able to use an SAQ AAP for validation, you need to make sure that where that storage is is on an internal not an internal component, not something that’s accessible from the public. K?

Now there is applicability notes for both of these requirements. They give you a little more guidance in there in the SAQ, so definitely read through those as well.

Then we also see the addition of security controls being implemented on any computing device. So they they took the one point four requirement and adjusted it a bit. So including company and employee owned device, they connect both to untrusted networks and the cardholder data environment. So instead of saying employee owned in mobile, now they’re saying company and employee owned. They can connect to both untrusted and your cardholder data environment. So they’re kinda just broadening that verbiage a bit to make sure it’s very clear what they’re intending there.

They wanna make sure that the the configurations are defined to prevent threats from being introduced into the network. The the security controls are actively running and not alterable by users.

If your organization has a laptop that’s in scope for PCI compliance, this requirement likely applies, so please take a look at that.

Next, we see several additions to section two of the DSS in SAQ AEP.

So, again, they took that security policies and operational procedures for section two and moved it to the top of section two and added the kept up to date bullet. So any security policies and operational procedures that you have for section two of the DSS need to need to make sure they are kept up to date and need to make sure that this is being addressed as part of your PCI compliance.

This was previously not included in the SSAQ type. You should have been requested to have this documentation, and there would have been other requirements in section two that would have required you to have this documentation.

But this particular two five requirement was not in the three two one SAQs.

Then they also added the non console administrative access is encrypted using strong cryptography.

So the applicability note that was added is trying to help organizations ensure that the organization is also applying this control to browser based interfaces and APIs.

So you’ll see that that addition in the applicability note there. So this was previously part of this SAQ type, but they did expand that a bit to make sure that we’re including those browser based interfaces and API interfaces.

And next in the SAQ A, we see the security policies and operational procedures requirement for section three. Again, that was added. And so if you have any storage of cardholder data, then this potentially would be applicable because you would need to have security policies and operational procedures for requirements in section three.

They do, of course, explain that this applies only to merchants with paper records that include account data because you shouldn’t be storing cardholder data and still be able to use this SAQ type to validate compliance.

They do also explain in the SAQ completion guidance that if you are selecting in place for this, that means that you do have paper storage of account data and that your policies and procedures govern how you’re protecting that. Then they go on to explain that if you’re not storing paper records of account data, then you can mark this not applicable.

So it’s, again, dependent on if you are storing cardholder data.

Then in section three, they talk about, again, about the same addition we saw in the SAQ A.

If you are storing cardholder data, you need to make sure it’s kept to a minimum, have data retention policies, disposal procedures, and they added that bullet for the coverage of any sensitive authentication data that’s stored prior to completion of authorization.

Again, there’s quite a bit of applicability notes and SAQ completion guidance that they added to this SAQ for this particular requirement as well.

They explained that where account data is stored by a third party service provider, for example, in a cloud environment, the entity is responsible for working with the service provider to understand how your third party service provider is meeting requirements for you, and considerations include ensuring that all geographic instances of data elements are securely deleted.

Then they go on to explain that it it it again means that if you’re storing any paper records that contain account data, the merchant is only storing it for business reasons no and no longer than is necessary.

But if you’re not storing any paper records containing cardholder data, you can mark this as nonapplicable.

So it’s really kind of, again, dependent on whether you’re storing credit card information at all.

Next in the SAQ AAP, we see a couple additions to section four.

So, again, they added the security policies and operational procedures for section four, bumped it up to the top, and added the kept up to date piece of it. So any documentation that you create for section four to make sure that your any any transmission of cardholder data over open public networks is secured means that this particular requirement may be applicable to you.

There is some additional section four guidance in there. They do explain for an SAQ AEP, requirement four applies to merchants when sending payment related data to the third party service providers.

Then they also explained that marking this requirement in place means the merchant has policies and procedures in place to govern your activities as it relates to requirement four.

If you’re working with a third party service provider and you don’t govern that communication, they do, then I would expect that your third party service provider should be showing that in a PCI responsibility matrix.

So one of the things that I’m you’re probably gonna hear me say a couple times today is you’re if you’re working with a third party service provider, you’re definitely gonna need to understand where that responsibility split is when you get to v4.0 of the data security standard. There might be some things that they’re taking on for you or they’re expecting you to take on, and you wanna make sure you know what their what that split is before you get to March of twenty twenty four and March of 2025.

Then they added the strong cryptography and security protocols being implemented as follows to safeguard PAN transmission over open public networks.

So there is a new bullet in this requirement. It got moved, and then that new bullet was added. Essentially, the new bullet says that any certificates that are used to safeguard pan transmission over open public networks have to be valid, not expired, or revoked.

This is a best practice until March of 2025, but, hopefully, everybody’s already addressing this in a pretty standard way.

And then there’s quite a bit of, applicability notes here as well.

They attempted to help explain where self signed certs may be acceptable.

If it’s issued by an internal CA within the organization, the certificate author is confirmed, the certificate is verified via hash or signature and is not expired.

If however, if the self signed certificate has the same DN field by for issued by and issued to, that is not considered to be acceptable. So it’s a very small sliver of self signed search that they’re saying are potentially acceptable for this particular requirement. So definitely look into this, figure out if that’s your responsibility, if it’s your third parties, and and see what you might need to do there. Keep in mind that second bullet is just a best practice until March of 2025.

Excuse me.

We see several additions to section five as well in the SAQ AAP.

First, that security policies and operational procedures got bumped to the top, had the kept up to date addition there. So if any of section five is applicable to your organization, that requirement is gonna be applicable to you.

Then we see several additions, related to how anti malware is used and and the frequency of, the frequency of anti malware scanning and, security controls. So in three two one of the data security standard, there was a requirement that said for any commonly affected, components by malicious software, you need to have anti malware deployed.

Essentially, they said they replace commonly affected with not at or at risk, so then they have a requirement now that says for not at risk components, make sure that you do a periodic evaluation to determine if malware is still not necessary.

Well, if you’ve listened to any of our past webinars, we’ve talked about the fact that there are now targeted risk analyses (TRA) that are required for any requirement in the DSS that has a periodic cadence.

This is what you’re seeing in five two three one.

Essentially, what they’re saying is if you do have components in your in scope environment that are not at risk from, malware software and you’ve determined that you’re not gonna use anti malware solutions on there, the frequency of that evaluation now needs to be justified by a targeted risk analysis.

So first you need to determine if this applies to you. If it does, then you need to document a targeted risk analysis to determine what is the appropriate frequency for that cadence.

Very similarly, in the next requirement five three two one, if periodic malware scans are performed. So for the anti malware solutions that are deployed, they said you can scan on a periodic basis or do continuous behavioral scanning now in four point o. So if you choose to go the periodic scanning route, then the frequency of those scans has to be defined and justified by a targeted risk analysis.

You’ll notice in both five point two three one five point three two one, they point you to another requirement. They point you to requirement twelve point three one that is the targeted risk analysis that they’re requiring for periodic cadence requirements. There’s actually two types of targeted risk analyses being introduced in version four point zero, but they are both called targeted risk analysis, so it can be a little confusing.

Those requirements are twelve point three one and twelve point three two.

Then in section five, we see another addition to the SAQ AAP for removable electronic media.

So if there are if there is removable electronic media in your environment that stores cardholder data, now you need to have anti malware that is being used for that particular media. So, again, you need to make sure if this is applicable to your organization, then you’ll need to address it if it is.

And then last in section five, we see that there needs to be a process and an automated mechanism in place to detect and protect personnel against phishing attacks.

So if you do not already have controls in place to prevent phishing attacks, please start looking into this with your email or an anti spam provider.

It it’s one of those things that there are lots of different ways that you can do this.

The guidance column in the actual DSS has some good information on specifically what they’re talking about, what types of controls on your mail transfer agents or your anti spam agents that you can be implementing to do this.

In the applicability notes, they make a very clear distinction between this requirement and the security awareness training requirement related to phishing. This is not a training requirement. This is a technical control they’re asking for. So they want to make sure that you have some sort of automated mechanism in place to detect and protect against phishing attacks. So these are settings on your email servers, things like that.

Alright. So moving into section six, Again, they added the information security policies and operational procedures for section six need to be added into this SAQ.

They added the kept up to date bullet, so making sure that that documentation is kept up to date. So if you have any requirements in your SAQ AEP environment in section six that are applicable, then those those security policies and operational procedures would be used for this particular 6.1.1 requirement.

And there are a few more. These are the last three section six updates to the AEP. So the first one is making sure that we have an inventory of be spoke and custom software and third party software components incorporated into these bespoke and custom software and that that’s maintained to facilitate vulnerability and patch management information.

So, essentially, what they’re saying is you have to do patching. You have to stay on top of emerging vulnerabilities and do a risk ranking.

How can you really do that without having an inventory of what you’re actually using? Right? So that’s why they’re adding this inventory requirement of what you’re actually using to help facilitate your patching and your vulnerability management processes.

This is a best practice until March of 2025, but it it is something that organizations might need to start sooner rather than later as we all know that depending on how large an organization is or how many components they have, this could be a a bit of a barrier to document.

Next, we see the addition of 6.4.2.

So the 6.4.2 requirement is essentially what the 6.6 requirement used to be with an adjustment.

So, essentially, what they’re saying here is for public facing web applications, an automated technical solution is deployed that continuously detects and prevents web based attacks.

So previously, in version three two one of the DSS, the 6.6 requirement said for public facing web applications, you can either do web application penetration testing or use a automated technical solution like a web application firewall to prevent, web based attacks.

They’re removing the or.

So in March of twenty twenty five, if you take a look at the applicability notes, this requirement is going to replace the six four one requirement. The six four one requirement is essentially what that 6.6 requirement used to be.

So once we get to March of twenty twenty five, they’re saying everybody that has a public facing web application that has to protect it in an SAQ AEP environment or other environments have to be using some automated solution to do it. So they’re essentially pushing everybody to some sort of web application firewall in blocking mode by March of twenty twenty five.

Then, again, we’re seeing the payment page script requirement being added to the SAQ AEP.

So essentially saying that making sure that any payment page scripts that are loaded and executed in the consumer’s browser are managed, making sure that there’s a method to confirm the script, to make sure the integrity of the script is valid, and to inventory the scripts. Again, this is for this is a best practice until March of twenty twenty five.

They do explain that this applies to scripts loaded from your organization as well as third and fourth parties, and then it applies to payment pages provided from the merchant’s website to the consumer’s browser.

So, again, this is this is in line with their guidance from twenty seventeen, but now it’s a full requirement.

And this is something that really organizations should start planning for much sooner rather than later because there’s the inventorying of those scripts, the authorization, the integrity of those scripts. That’s something that’s gonna take a little bit of time to set up a good process that you’re gonna be able to maintain and be able to sustain.

You may wanna talk to your third party service providers and see what they’re gonna be doing for this, see if they have any recommendations for your particular implementation.

So there’s a lot of different ways to do this, but I don’t envision manual is gonna be a good option. I envision that there’s gonna be some sort of tool or solution that you might need to look at to have a a consistent way to manage these payment page scripts, so please be aware.

Oh, went went too far.

In section seven, we see two additions in the SAQ A.

All user accounts related to access privileges, including third party vendor accounts, need to be reviewed. So a lot of regulations out there have a user access review requirement. PCI never has, so they are introducing one. This is a best practice until March of twenty twenty five, but what they’re saying is at least every six months, you need to review all your user accounts and privileges, fix any inappropriate access, and have management acknowledge that access remains appropriate.

So this is definitely a process change that some organizations may not currently be doing. So definitely something you want to start looking into, start thinking through, make sure this is gonna be a repeatable sustainable process.

Also, because this is a best practice in until March of twenty twenty five, you also have to think through when you validate compliance and when this becomes a full requirement.

When this becomes a full requirement in March of twenty twenty five, they’re expecting that you have this in place in March of twenty twenty five, whether you’re validating compliance that March or that December. So if you validate compliance that December, you would be expected to show that you’ve done this twice. Right?

So it really kind of depends on where you are, or and and it might not be December, but it is you wanna make sure that these things are in place by March of twenty twenty five. You don’t wanna start looking at these in March of 2025. K?

For 7.2.5, we see that they’re adding application and system account controls into this SAQ type. So any application and system accounts and related access privileges need to be assigned and managed. So they wanna make sure any application and system account privileges are the least necessary for the application or system to function, and that access is limited specifically required for that use. Right? So we are gonna see a couple more additions to requirements related to application and system accounts in section eight that we’ll be talking about, but please be aware that if you are using application or system accounts on your in scope environment, there’s some additional controls you’re gonna have to put in place before we get to March twenty twenty five.

When we get into section eight, we see again that they added the security policies and operational procedures requirement in here and added the kept up to date bullet, so making sure that documentation is being kept up to date.

And then in 8.3.6, if passwords and passphrases are used as an authentication factor, then we’re we’re expanding that password length requirement, again, up to twelve characters. Unless it your component does not support it, then you can use eight characters, making sure we have both numeric and alphabetic characters.

And, again, this is a best practice until March of 2025.

This is not intended, again, to apply to point of sale terminal accounts that can only facilitate one, one, excuse me, one transaction at a time.

Alright.

Next in section eight for an SAQ A, we see the password and passphrases when they are used as the only authentication factor for user access, then the password passphrase should be changed every ninety days, and the security or the security posture of the account is dynamically analyzed. So, again, they’re kind of referring to zero trust there.

And they do explain some additional content in the applicability notes there.

And then this is a change from the old ninety day password rotation requirement to allow some flexibility for zero trust. So we really have to determine applicability and if something needs to be adjusted to meet compliance.

Then you’re seeing the new MFA requirement being added to this self assessment questionnaire type. So in an SEQ AEP, you have the new eight four two DSS requirement that says multifactor authentication is implemented for all access into the CDE.

The applicability notes here are quite lengthy.

So, essentially, what they’re doing here is they’re extending the multifactor authentication requirement for all access into the cardholder data environment. So read through those applicability notes. This is one of those requirements you probably wanna look straight at the data security standard for because there is quite a bit of information, not only in the applicability notes, but also in the guidance column in the data security standard that talks about this. They do include some information about how you can set up your multifactor authentication, when it would apply in those scenarios. So definitely read through that, but this is something that organizations will probably need to adjust in an SAQ AEP type environment to make sure that this is addressed. Again, this is by March of twenty twenty five that this needs to be in place.

Next in the SAQ AEP, we see that the multifactor authentication system needs to be needs to have some good controls in place. So they essentially wanna make sure that your MFA system is not susceptible to authentication factors are used, and this is success of all authentication factors is required before granting access. So some typical kind of straightforward best practice security stuff, but there’s a it’s an actual requirement when we get to four point o. This is still a best practice until March of twenty twenty five. But if this is not something you’re currently doing, it’s definitely something we should be doing and should have been doing the whole time, so please start looking into that one as well.

And then as I mentioned, there’s a couple additional requirements to application and system accounts. So in eight six one, if accounts used by system or applications can also be used for interactive logins, then you have additional things you need to do to manage those accounts. The interactive use needs to be prevented unless necessary for exceptional circumstance.

Interactive use is limited to the time needed.

Business justification is documented.

It’s explicitly approved by manager management.

The individual user identity is confirmed prior to granting access, and then every action is attributed to an individual user. So they’re really putting a lot of emphasis and controls around the use of those system and application accounts if they’re you if they’re allowed to be used for interactive logins. So you need to determine if any of those accounts exist in your environment and then figure out if if they do, are we doing these things, or what processes do we need to put in place for that? Again, this is a best practice since on March of 2025.

In 8.6.2, we see an additional control for passwords and passphrases for application and system accounts that can be used for interactive login, making sure they are not hard coded into scripts, configuration, property files, or custom source code.

So I don’t know if you have noticed, but over the years, there has been several breaches that have come out that some sort of default credential or weak password was used on a system or application account, and that’s what caused the incident. I suspect that’s why we’re seeing, an order five new requirements in the PCI DSS four point o specifically related to system and application accounts.

Previously, it was just user accounts that the data security standard, dealt with. Now we’re seeing those additions as well.

And then in eight six three, passwords passphrases for any application system accounts are protected against misuse.

So now in eight six three, they’re saying we should be changing those passwords on some frequency, but there’s a keyword in here, periodically. Right?

So anytime we see periodic in four point o, that means we need to have a targeted risk analysis to explain why our frequency is justified and appropriate for our environment.

Then you also need to make sure that those passwords and passphrases are constructed with sufficient complex complexity appropriate for how frequently the entity changes the passwords.

So they’re saying that the complexity now ties to the frequency based on your targeted risk analysis for your periodic cadence. So they’re really putting the onus back on the organization to determine what’s appropriate, but you need to be able to justify that, do a targeted risk analysis (TRA) to explain that.

Then in the SAQ AEP, we see automated mechanisms being required for to perform audit log reviews.

So previously in the DSS, they said you can use log harvesting, parsing, or alerting tools to do daily log reviews. Now they’re gonna require some automated mechanism be used for those audit log reviews.

There’s just there’s just too much log information out there to not have some automated solution to help you kind of filter out the noise and focus on what’s important.

This is a best practice until March of twenty twenty five. But if you’re not already looking or you’re not already using some automated mechanism, you should start looking at that.

And then, in the PCI DSS version three two one and version four, there is still the requirement to say, do daily log reviews for this bulleted list of components.

Then they say, if you are doing periodic log reviews for all other components, then you gotta determine that frequency based on a targeted risk analysis. So first, you have to determine, does this apply to you? Are we doing daily log reviews for everything that’s in scope, or are we going to have some components that are in scope that are maybe in the connected systems category that we’re not doing daily log reviews on, we’ve decided that we can do periodic log reviews on those. If that’s the case, then you’ll need to develop a targeted risk analysis for the justification of that cadence.

Next in 11.6.1 is the addition of the tamper change detection mechanism for the outsource mechanism to your third party service provider. So this is, again, for organizations that are outsourcing to a third party service provider. They wanna make sure that you have some mechanism in place to ensure that that outsourcing does not change.

So, again, please make sure you look at the details of those requirements, determine that applicability, and put some controls in place to make sure that there’s no changes there without authorization.

Next in the SAQ AEP, we see some additions to requirements in section twelve.

First and foremost, the responsibility for information security is formally assigned to a chief security information security officer or other information security knowledgeable member of executive management.

So this particular requirement, this responsibility requirement was merged and kind of clarified the responsibilities of it. So there was no additional guidance, but, essentially, they’re kind of combining a couple requirements from twelve five, and they moved it. So it is different from what you previously saw in your SAQ AEP.

And then in 12.3.1, this is where we see the actual requirement for the targeted risk analysis for cadence requirements.

So, essentially, each PCI requirement that provides flexibility, uses the term periodic, and how often you can do something needs to have a justified targeted risk analysis documented.

And those six bullets is what they’re looking at having included in those particular targeted risk analyses. Like I mentioned, there’s two targeted risk analyses in PCI DSS.

The second targeted risk analysis is for customized approach.

If you’re gonna validate a requirement with the customized approach, you’re not allowed to do that with any SAQ type. You can only use the customized approach if you’re doing an on-site assessment with a QSA or an ISA.

So there’s no reason for them to include the other targeted risk analysis requirement, the twelve three two requirement, in any SAQ type because it’s not allowed to be done. So this is the only targeted risk analysis requirement you’ll see in any SAQ type that you will review for four point zero.

In twelve six three one, we see that there’s an additional security awareness training requirement, related to phishing and social engineering. So as we mentioned earlier, they’re asking for a technical control to prevent phishing attacks.

Now you’re seeing the security awareness training requirement for phishing. So this is something that’s going to be a requirement March of twenty twenty five. If you’re not already doing security awareness training that includes phishing or social engineering training, please start looking at adding that module. It’s it’s something every organization, whether they’re PCI obligated or not, should be doing.

Alright. So that was the SAQ a, SAQ AEP. So before I go dive into the SAQ b, I do wanna mention I did not cover every single requirement in those SAQ types. All I’m covering are the things that have been added or changed.

So this these are what came out of the comparisons of those two. If there was a requirement that was previously in an SAQ type and it’s still in the SAQ type, it is not in our list, and that’s intentional. Okay? So you’ll see at the end that I recommend everybody go read the SAQs that are applicable to their organization.

Okay. So the SAQ b starts with the first new addition being the three one one requirement. Security policies and operational procedures for any storage of cardholder data are documented in use, known to affected parties, and now kept up to date. So determine if this is applicable. Make sure that you have your documentation updated if it is applicable.

And then they also added some applicability notes to this particular requirement in the SAQ B and explained that it only applies to merchants with paper records that include account data.

So any in place response for requirement three one one means that the merchant has paper storage of cardholder data and that you have documentation that governs that. If you do not store paper records with account data, then you can mark this not applicable.

And then the next one is interesting. They actually removed a requirement from the SAQB.

So in the SAQ B, we previously had the requirement to make sure that there’s no clear text pan ever being transmitted over end user messaging technology.

That was actually removed from this SAQ type in version four.

The rest of the requirements in the SAQ B under version four are the same as what was included.

However, there’s no longer wording that’s a question. They’re actually using the DSS text now.

So you want to make sure that you look at the new SAQ types because your verbiage may be slightly different than what you were previously using.

What they had done for years is to try to make self assessment questionnaires easier. Instead of using the data security standard text, they reworded it and made it into a question. Well, that’s been eliminated. So now all of the self assessment questionnaires are using the data security standard text. So you definitely need to take a look at those self assessment questionnaire requirements and make sure that your documentation still properly aligns.

That was a quick one. One slide for the b.

So let’s move on to the SAQ BIP.

For the SAQ BIP, you’ll notice again they added the three point one one requirement. So if there is any paper storage or cardholder data, this is gonna be applicable. You need to make sure that that documentation is kept up to date.

All section four requirements in the SAQ BIP have been removed from this SAQ type. So previously, they had a requirement for four one, four one one, and four two in the BIP that has all been removed. I suspect the reason for that is because you’re not supposed to have access to that cardholder data, that most organizations don’t control the communication from their environment back to their payment provider when they’re using a stand alone terminal.

So, you know, I found it interesting that those were removed, and I thought we should note those.

Then we see just a couple more requirements that were added to the BIP, not not something hugely significant because these are potentially things that are either applicable and were applicable or are not applicable.

So any requirement in section eight, if that was applicable to your environment in the BIP, if any one of those was marked previously as in place, then you potentially have some security policies and operational procedures for that particular section of the data security standard. So now that requirement is being added to this SAQ type and you need to make sure that documentation is kept up to date.

The SAQ Completion Guidance explains that if you’re marking this as in place, it means that you have policies and procedures in place to govern merchant activities for this section of the DSS.

Then in requirement nine, we see a very similar addition, right? So if you have any requirements in section nine that are applicable to your organization, then you’re going to need to make sure any security policies or operational procedures related to those are documented in use known to affected parties and kept up to date.

And then again, the rest of the SAQ BIP is the requirements in there are the same that were included in version three two one. However, they’re not worded as questions anymore. Now they’re using the DSS text, so, again, you need to go back, take a look at the saqbip four point o document, review the verbiage that they’re using that’s now the DSS rather than those requirements, and make sure your documentation still aligns.

And that’s it for the BIP.

Okay. So let’s move on to the SAQ C.

First and foremost, we’re seeing a a couple additional requirements related to those security policies and operational procedures.

I’m not exactly why sure why some of those requirements were previously left out of the DSS. It always made sense to me to include those because if any one requirement in a section is applicable to an organization, then you’re gonna have those documents anyway. So there are requirements in section two that are are asked about in the SAQ C. So, essentially, what they’re saying is now any of your security policies and operational procedures for that requirement need to be documented and used, known to affected parties, and kept up to date.

Same thing with section three of the data security standard. But when we get to three one one, they do have some additional notes and SAQ completion guidance. So they do explain that this only applies to merchants with paper records that include account data.

And that if you do not have any paper records containing cardholder data, you can mark that as not applicable.

This was not previously included in this SEQ type, but is now being added in.

Excuse me. I got pretty far without eating water and being sick.

Alright. In section four, we see that they added four two one in the SAQ C.

So strong cryptography and security protocols are implemented to safeguard pan transmission over open public networks.

So this is again making sure that that communication that we have for cardholder data over open public networks is secured.

They did add an additional bullet. The certificates used to safeguard that pan data over transmission are confirmed as valid, not expired, or revoked. So that bullet is a best practice until March of twenty twenty five.

I like the applicability notes for this one. I think they’re quite interesting.

They explain that there could be occurrences where an entity receives card holder data unsolicited via an insecure communication channel that was not intended for the purpose of receiving sensitive data.

In this situation, the entity can choose to either include that channel in the scope of their cardholder data environment and secure it or implement measures to prevent that channel from being used for cardholder data.

A self signed certificate may be acceptable, so this is where they talk about that self signed cert might be okay, but it really depends on how you’re doing it and if that DN issued by an issue to field are not the same.

So organizations that use certificates to safeguard PAN during transmission over open public networks will have to ensure that this is in place.

If your third party service provider, like an SAQ C is typically for an organization that has a payment application in their environment that’s sending cardholder data through that payment application, if your third party service provider that you’re using that application from is somehow managing that communication, then this might not apply to you. So it really depends on each environment’s implementation there.

Then in section five, we see the addition of the security policies and operational procedures for anti malware being added and making sure that the that documentation is being kept up to date.

Then very similar to the other SAQ types, we’re seeing the same types of additions to, section five as well. So five two three one, the frequency of those periodic evaluations for not at risk components for malware needs to be determined by a targeted risk analysis.

The anti malware solution is either performing periodic scans, real time scans, or continuous behavioral analysis that is five point three point two.

If periodic scans are are being conducted in five three two one, then that needs to be based off a targeted risk analysis.

Now the five two three one five three two one, those two requirements are best practices until March of 2025.

And then lastly, in section five on this slide, we see that for removable electronic media, the anti malware solution needs to perform automatic scans when the media is inserted or connected or performs that continuous behavioral analysis for removable electronic media. So, again, it really determines if this is applicable to your organization. If it is, then you need to make sure that that’s in place before we get to March of 2025.

Then in five four one, we need to make sure we have processes and automated mechanisms in place to detect and protect against phishing attacks, so this was also added to the SAQ C.

Again, this is a best practice until we get to March of 2025. So if you do not already have controls in place to prevent phishing attacks, please start discussing this with your email or anti spam providers to help make sure that you’re ready for this one.

Next, in section six, we see an addition of 6.2.1 where bespoke and custom software is developed securely.

So they just kind of pared this down to based on industry standards and or best practices for secure development. They removed bullet points intentionally from that SAQ.

Then in the notes, they explained that this applies to merchants with bespoke software or custom software. If the merchant does not have such software, then you can mark this as nonapplicable, and they did include in parentheses when they’re talking about bespoke software, they’re saying developed for the entity specifications by a third party or custom software developed by an entity. So essentially, if somebody developed software for you or if you developed your own software, then this is where they would expect that this would apply for your particular environment.

Then in the applicability notes, then they go on to say, this applies to all software developed for or by the entity for the entity’s own use.

This does not apply to third party software.

So these were not previously included in an SAQ type. They’re being added for b scope b scope and custom software that is in scope for PCI compliance.

Something that everybody should keep in mind is the PA DSS was retired last year in October, So if you were using an application that was PA DSS validated, please talk to that third party service provider and see if they are going down the secure software framework route or the secure SDLC route to see if you can lean on any of their certifications and future validations.

Okay.

Next in the SAQ C, we see six two two or software development personnel are that are working on b scope and custom software need to be trained at least once every twelve months. So they need to make sure that your software development staff is being trained.

This was not previously included in this SAQ type, so this might be something that you’re gonna have to implement that you previously were not doing.

This is not a best practice until March of 2025. This is something that they expect organizations will have in place by the time that they’re doing their first PCI DSS 4.0 validation.

Then in six two three one, they say if custom if manual code reviews are performed for bespoke and custom software prior to release, then you need to make sure that that’s reviewed by an individual other than the originating code author who is knowledgeable about code review techniques and secure coding practices and reviewed and approved by management prior to release.

So, again, this is something that was not previously included in this SAQ type. It is being included now. It is something that you need to be aware of and start looking into if it’s not already a process you are using. Hopefully, it is. One of the things I heard from council members a few weeks back is that the requirements that they are making applicable immediately rather than requirements that they’re giving people time until March of 2025 for are things that they expect are gonna be easy implementations or things that people are already doing. So that’s why they’re not giving people extra time for some of these. So if you need that extra time, please start looking into these controls now.

In the SAQ C, we also see the addition of 6.2.4,

where software engineering techniques and methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities.

So in version three two one of the DSS, they basically had the OWASP top ten as ten requirements.

They took that OWASP top ten ten requirements and they moved it into one requirement that’s now six two four.

So none of these software development requirements were previously in this SAQ type. They are now being added in.

They do explain that this does not apply to third party software. This applies to your software developed by your organization or developed for your organization by somebody else.

And essentially they’re saying that you need to protect that software against injection attacks, attacks on data and data structures, attacks on cryptographic usage, attacks on business logic, attacks on access control mechanisms, and attacks via any high risk vulnerabilities identified in your risk ranking process in six three one.

Then in the SAQ C, we see the addition of changes to all system components in the production environment being made according to established procedures.

So, essentially, what this is is a change control, change management requirements. These were not previously included in the SAQ C.

Now they will be. I think the SAQ C probably had the most additions that we saw. The AEP and the C are probably tied there, but there are several new processes and controls that are going to be required for organizations that are change control requirement has several things that they’re looking forward to include in your change management tickets and your change management documentation, and then when we get to section seven, we see that all user accounts related to access privileges are reviewed. So again we’re adding the user account review requirement into the SAQ C now, making sure that those account reviews are happening every six months. That process needs to be in place by March of 2025, And then any application and system accounts related and related access are also managed and reviewed to make sure that’s only least privilege necessary and access is limited and restricted.

So these are new requirements in four point o. These are things that are best practices until March of 2025, but it could take some time to implement, and it is something that is being asked you’re being asked to do for the first time. So you definitely wanna make sure you understand how this applies to your environment and start looking at setting up processes to get this in place.

Next, we have several new additions to the SAQ C in section eight.

So first and foremost excuse me.

The security policies and operational procedures that you use for section eight need to be documented and used, known to affected parties, and kept up to date. So they added documentation requirement into the SAQ C as well.

Then they added several requirements around password complexity user access. So first, they wanna make sure that any terminated user access is immediately revoked.

They wanna make sure that any inactive user accounts are removed or disabled in ninety days of inactivity.

So this is not, people that have left the organization. This is people that have accounts that for some reason have not logged in in ninety days. They wanna make sure that those accounts are removed or disabled. They’re not just sitting there, dormant.

Then eight in 8.3.2, they wanna make sure strong cryptography is used to render all authentication factors unreadable during transmission and storage.

So these are all requirements that were in three two one but were never included in this saq type previously.

Then making sure that user identity is verified before modifying user authentication factors. So this is part of, like, password resets or things like that, making sure that as part of that process, that user identification is verified.

Then if a password passphrase is used as authentication factors to meet the authentication requirement, then we’re seeing the password length increase requirement being added in the SAQ C.

So making sure that organizations are using a minimum length of twelve characters. If they can’t support it, then eight characters and both numeric and alphabetic characters.

This is a best practice until March of twenty twenty five, but you definitely want to make sure that, your organization is prepared for that change. Sometimes the communication is the part that takes the longest. Right?

In eight three nine, if passwords or passphrases are used for authentication factors, then the password passphrase needs to be changed every ninety days or the security posture of the account is dynamically analyzed. So, essentially, they’re allowing some flexibility for zero trust to be used here. You gotta determine applicability and if anything needs to be adjusted for you to meet compliance, but you might already be in compliance with this, hopefully.

Then we see in the SAQ C, they also added the MFA is implemented for all access into the cardholder data environment.

So, they did add this requirement to the SAQ C type, questionnaire, you essentially need to determine based on your PCI in scope environment if currently all access into the cardholder data environment is going through multifactor authentication or if there is any access that previously did not have or require multifactor.

Now if you remember back to three two one, multifactor authentication requirements apply to remote and nonconsole access. So now they’re saying all access into the cardholder data environment.

Again, the applicability notes and the information that’s in the actual data security standard for this requirement are very helpful, so I highly recommend going to read that.

Alright.

Next, we have the multifactor protection requirement. So multifactor authentication systems should not be susceptible to replay attacks, should not be able to be bypassed, confirmation that at least two different factors are used, and that, success of authentication factors is required prior to accessing your environment.

So this was, previously not in the DSS at all and so they are giving people until March of twenty twenty five to implement this. Hopefully this is something that your solution is already doing.

If not, please determine what’s necessary to have those controls in place.

And then we see, a couple additions to the system and application accounts again. So eight six one says if accounts used by system or applications can be used for interactive login, we have to manage those. So, again, this was not in the SAQ C. This is a new requirement of 4.0, so it is one that’s a best practice until March of twenty twenty five. So you need to determine if there are any system and application accounts that are in scope for your environment.

If so, that have interactive logins. If so, this requirement would apply, as well as the next.

Making sure that those account credentials are not hard coded into scripts, configuration files, bespoke, or custom software code.

Next in section eight, making sure the password and passphrases for application and system accounts are protected against misuse.

So changing those on some periodic basis that you determine based on your targeted risk analysis and then making sure passwords and passphrases are constructed with sufficient complexity appropriate for how frequently you are changing that password. So they’re really trying to tie those two things together there. Again, this is a best practice until March of 2025 because it is a new requirement.

We did not see any new requirements that were added to section nine of the DSS for an SAQ C, so we’re gonna hop over to section ten.

So in section ten, the security policies and operational procedures requirement was added, making sure that it’s documented in use known to affected parties and kept up to date, as well as making sure that we have an automated mechanism to perform audit law reviews.

Again, this because this is a new requirement, it is a best practice until March of twenty twenty five be when it will be a full requirement.

Then as we spoke about previously, if you have any components that are not part of your current daily log review process, if they are part of the all other system components and you are doing periodic log reviews on those components, you need to justify that periodic cadence with a targeted risk analysis.

In SAQ C, in section ten, we also see that they added some time synchronization requirements.

So the the overall system clocks and times are synchronized using a synchronization technology requirement was added. This is not a best practice until March of twenty twenty five. This is applicable immediately for any four point o validations that are using an SAQC.

So if you are not currently using time synchronization on your in scope environment for an SAQ C, you will need to do so before you validate compliance against 4.0.

And then along those same lines, there’s a couple additional time synchronization requirements. So the first one being systems are configured to the correct and consistent time.

All those bullets in there are basically what they’re defining as consistent and correct time. So having one or more designated time server, only the designated time server receives time from the external sources. Time received from external sources are based on UTC or, atomic time. The designated time server accepts time updates only from that specific industry accepted external source.

When there’s more than one time server that those are peering to each other and that the internal systems receive time only from the designated time servers. So if you weren’t previously using NTP or time synchronization in your in scope environment, that is something you will need to do prior to validating compliance against version four. So it’s not March twenty twenty five. It’s next year we’re talking.

Time synchronization settings are protected as follows, so making sure that access to time data is restricted only to the people that need it and that any changes to those time settings are logged, monitored, and reviewed.

Next in SAQ C, we see some additions to section twelve.

So we talked about the targeted risk analysis for periodic cadence requirements.

We again are seeing that this is coming up in the SAQ C.

And, again, it’s because some of those periodic cadence requirements are now in the SAQ C. So because they’re adding those requirements, they’re also adding this requirement to make sure that we’re covered. Even though each of those individual requirements actually call out this requirement and say base your justification on this, they also added a separate requirement just for this to make sure that that’s being addressed.

Then in twelve six three one, the security awareness training requirement around phishing and social engineering is also being added to the SAQ C.

So though this is a best practice until March of 2025, hopefully, most organizations are already doing phishing and social engineering training. If not, please start looking into that sooner rather than later. It’s not just a compliance requirement, but it’s it’s something that everybody should be doing by now.

In twelve ten three, we see that, people need to be designated to be available on a twenty four by seven basis to respond to suspected or confirmed security incidents.

So for some reason, this particular incident response requirement was not previously included in this SAQ type. They didn’t provide any additional guidance in the SAQ documentation, but they did add it in, and it’s not a best practice because it was previously a DSS requirement, so so they just included it.

The rest of the requirements in the SAQ C are the same that were included in 3.2.1, but, again, the verbiage changed, so you definitely do need go back to the SAQ C four point o, compare it to what you currently have for your documentation, and make sure everything still aligns, especially since now they’re using the data security standard text rather than the questions they previously used.

Alright.

Two more to go, folks.

SAQ CVT.

So in the SAQ CVT, we see two additional requirements being added for policies and procedures at the very beginning. Right? So for, configuration harming, for system component, the harming, and requirement two, we’re seeing the security policies and operational procedures for that section being documented in use known to affected parties and being kept up to date.

So this was added. It was the previous two five requirement. For some reason, it previously wasn’t in the SAQ CBT, but there were other section two requirements included. So you’ll definitely want to make sure you have that addressed and that that documentation is kept up to date.

Same thing with section three. So same requirement being added to section three, making sure our security policies and operational procedures for section three are applied or are are documented in use, known to affected parties, and kept up to date.

And then we see that there’s SAQ completion guidance in here. In the notes, they explain that requirement three only applies to merchants with paper records.

So, again, we we expect that only paper records are what’s being stored for the CBT environment.

And then they go on to explain that if you are not storing any paper records, you can mark this as not applicable.

Two of the section four requirements in the CBT were removed again. So they removed the four one and four two requirements from this SAQ type when we get to four point o, probably because they realized that people don’t control that. All their third parties do.

Also in the SAQ CBT, we see the addition for anti malware protections.

So the first one being the anti malware solution can perform periodic scans or active real time scans or performs continuous behavioral analysis.

So this requirement was expanded to add the option for continuous behavioral analysis.

They didn’t add any additional guidance in the SAQ, but they do want to make sure that this is in place for a CVT environment.

And then if there’s any removable electronic media that is used in your PCI environment, you want to make sure that your anti malware solution is performing automatic scans when that’s inserted, connected, or logically mounted, or performs continuous behavioral analysis.

And then, again, the processes and automated mechanisms in place to detect and protect personnel against phishing attacks.

So this requirement and the one I previously spoke about with the removable electronic media, both best practices until March of twenty twenty five. But if we’re not currently doing that, we should look into it sooner rather than later.

Next in the SAQ CBT, we see three additional requirements being added to section eight.

Again, the security policies and operational procedures being documented and used known to affected parties and kept up to date, so making sure that any of the documentation for section eight is addressed here and being kept up to date.

Then eight two four was added to to make sure that any addition, deletion, or modification of user IDs and authentication factors and other identifier objects are authorized with appropriate approval and implemented with only the privileges specified in the document of approval.

So this requirement was actually created by combining a couple DSS requirements from version 3.2.1.

This is something that most organizations hopefully already have, some sort of documented account creation process including permissions and approval.

If you do not already have a process that is being used like that for your PCI environment as it relates to an SAQ CVT validation, please make sure that’s being addressed and that exists for any users that have access to your PCI and scope environment.

In the applicability note, it also explains that this applies to all user accounts, including employees, contractors, consultants, temporary workers, and third party vendors. But keep in mind that’s all of those accounts for your PCI and scope environment for the SAQ CVT. So it’s not across your entire organization. It’s for your PCI scope.

For eight three six, if password passphrases are used as authentication factors, then they need to be the password passphrase needs to be at least twelve characters long or eight if your components still support it and support both number and alphabetic characters.

Again, this is a best practice until March of 2025.

We’re finally increasing our password security or password complexity requirements in PCI, but there’s still a little room for improvement, I suspect.

So if you have for your in scope components, you wanna make sure that you are able to address this. If your component cannot support that twelve characters, I would keep documentation to explain that that’s not supported so you can justify using the minimum length of eight characters by March of twenty twenty five. So that’s probably the first step is go figure out which components this applies to and what they support.

Then in section nine, we see the addition of the security policies and operational procedures being documented in use known to affected parties and kept up to date again. So any requirements that were applicable to you in section nine, any documentation you use for those requirements, that’s the documentation they’re talking about here.

There was in in version three two one of the data security standard, there was a requirement in section eleven around segmentation penetration testing.

That was actually removed from this SAQ type.

So that requirement is no longer in this SAQ type, and that was the only section eleven requirement in this saq type.

So something to be aware of. They’re no longer requiring that once you are validating against version four point o.

Then in section twelve, the security awareness training, including phishing related attacks and social engineering is being added to this SAQ type as well. So, again, if you’re not currently doing that training, please add it to your roster.

And then last but not least, of course, there was a lot of changes to the verbiage and the SAQ CVT. All the other requirements that were included were also included in version 3.2.1, but because there was such drastic wording changes, please go back and read the SAQ CVT. Make sure your documentation still aligns with the new verbiage they are using.

Alright. Last one.

SAQ P2PE.

First and foremost, they added security policies and operational procedures to section three.

So in the notes and the SAQ completion guidance, because we’re talking about an SAQ P2PE, this should only apply to merchants with paper records, right? There should be no storage of cardholder data. So if there are any paper records in your environment, there will be requirements in section three that will be applicable in SAQP to PE. Now you’ll also want to make sure your documentation is kept up to date.

And then they also added the data retention and disposal requirement in the SAQ P2PE. So if you are storing any cardholder data on paper records and using an SAQ P2PE, then you need to have a defined data retention and disposal policy and procedures that make sure that you’re covering any storage of cardholder data and any potential storage of sensitive authentication data prior to authorization before March of twenty twenty five, and then making sure that there’s an automated process to clean that up once every three months if you are storing that information.

Next, in the SAQ P2PE, we see the addition of the security policies and operational procedures for section nine.

Section nine is definitely applicable to anybody that’s using, an SAQ P2PE just from the device inspection perspective or any paper storage that you have that is related to paper or paper media with cardholder data on it. So I wanna make sure that that documentation is being kept up to date and use known to affected parties, and it explains in the SAQ completion guidance when you’re writing in place for this particular requirement. That means you have documentation that governs how paper media with cardholder data is secured and how your POI devices are protected.

Then again, the rest of the requirements in an SAQ P2PE under version four are the same requirements that were included in three two one. The numbers have shifted. The verbiage has shifted. So please go back and read the SAQ P2PE. Make sure that your documentation still aligns with the verbiage in the new SAQ type.

Alright. So here’s a quick summary before we get to any questions.

Each SAQ has has had several changes. So as I had mentioned, there’s a lot more guidance and a lot more verbiage in the SAQs than they ever have had in the past. Even prior to getting to the actual SAQ attestations or the SAQ requirements in the summary and introductions of the SAQs, they have more information on the eligibility.

Please about how something impacts your direct organization.

And then because I suspect the audience for this webinar are mostly merchants or potentially human service providers that are validating compliance through an SAQ if you are validating your compliance through a portal that your financial institution has given you access to.

Please be aware that over the years as I’ve worked through many of these PCI transitions, I’ve seen that some portal providers actually switch to the new version of the DSS before the retirement of the old version.

So keep an eye on communications from your financial institution, from your portal provider about any upcoming changes to version four of the DSS.

From my experience, they give they typically give people a heads up to say, hey. We’re gonna be switching to this version on this date.

But three two one does not expire until March of twenty twenty four. If your portal provider moves you to four point o prior and you’re not ready to validate against March of twenty twenty four, you will have to go verify that you can do a paper version of your SAQ and upload it to the portal. From the financial institution’s perspective, that should still be sufficient because it is still a valid version until the end of March of twenty twenty four.

And then also, any organization that is outsourcing to third party service providers are going to need to have some sort of communication with those third party service providers to determine applicability of some of these new requirements.

Third party service providers are should and PCI merchants should have documentation about the PCI responsibility split between them and third party service providers.

Typically, I’ve seen that most third party service providers want to maintain that documentation and own that and then provide it to people as needed.

It’s extremely important to understand what that responsibility split is when you get to version four so you know exactly what your responsibilities will be.

I’m not saying that every third party service provider will have those answers yet. They may not. They might not have had an opportunity to work on it yet.

But by the time that we approach the end of this year, the beginning of next year, I would expect that the most third party service providers should be able to talk to their clients about what they expect that responsibility split to be or to have updated four point o PCI responsibility matrices they can share.

So keep that in mind, especially if you’re using third party service providers. That responsibility split is gonna be very important to understand before you get to version four.

Okay, team. What questions do we have?

Viv, there is a question in the Q&A. I’m not sure if you can read it.

I actually cannot see the Q&A. Would you mind reading it?

Okay. So it says it’s quite a it’s quite a mouthful. Our university has several merchant departments with accounts that all roll up to the university’s main chain merchant account. Thus, we attest with an SAQ d. However, my question is, if we were to separately attest our merchant departments on an SAQ a, b, IP, c, or P2PE, then would we answer not applicable to any sub requirements that are subject only to SAQD merchants?

Yeah. That’s that’s a great question.

Yes. I I mean so here’s the thing.

When you look at an SAQ D for merchants, it’s everything in the data security standard that is applicable to a merchant environment.

The SAQ a, the SAQ BIP, c, CBT, P2PE, AEP, all of them have pulled certain requirements out.

So the other SAQ types only ask some of the DSS requirements. So you’re if if you go the other route where you are validating by each SAQ type, you would not have to go mark those other requirements as not applicable. They shouldn’t even be in those SAQs.

So by comparison’s sake, let’s talk a little bit about, like, an SAQ A versus an SAQ D.

In the SAQ D, you probably have about and and the count is different depending on how you count, and I don’t I don’t promise to know the exact numbers. But in version four, let’s say you have two hundred and fifty two requirements in the SAQ D.

In the SAQ A, you’d have twenty seven.

So there’s no marking of those other requirements not applicable because they’re not even in the saq type.

So it would likely be easier to validate compliance by those different saq types than doing it all under one and marking all of those different nuances not applicable, as long as your financial institution is okay with that.

So we can give you support, guidance, recommendations. We can help facilitate conversations. We can validate organizations for PCI compliance, but we’re just the messengers.

We don’t make the rules. The authority in this case is the PCI Security Standards Council. The people who enforce this are the acquiring banks. So the acquiring banks are responsible for making sure that their merchants are maintaining PCI DSS compliance, and the way that they’re doing that is essentially up to the acquiring bank to make that determination. The acquiring bank then reports that merchant status back to the card brands. So whenever we run into a question like this, yes, it’s definitely possible, but what I recommend is working with your QSA to facilitate that discussion with your financial institution to make sure that you have this right support and guidance and that you’re communicating with them before you’re making an assumption that that’s sufficient.

Any other questions?

All of your mics have been enabled, by the way. So if you need to speak, you just have to, unmute your own mic.

Thank you, Rachel.

Alright. Well, the SAQ comparison stuff was a lot of fun for us to do just because it it’s always interesting to me to see how they’re shifting things, but it is a little overwhelming as well, especially when you have multiple SAQ types that you’re validating against. So if you have questions, if you need support, please know that QSAs are out here to help you, and our jobs are not to police people. Our jobs are to partner with you, help you understand what the impact to your organization is, and help make sure that you can maintain compliance to secure payment information for everybody involved.

We really appreciate you taking the time to join us for our PCI DSS 4.0 webinars.

We’ve had a pleasure sharing our knowledge and information with everybody that’s joined.

Thank you. Have a great day.