In this session of the PCI DSS webinar series, Viviana Wesley delved into the 4.0 PCI DSS requirements. The session covers a comprehensive overview of the fourteen requirements, emphasizing the importance of roles and responsibilities in network security, configuration management, and cardholder data protection. New requirements for critical security controls and a targeted risk analysis for a customized approach are introduced, allowing organizations flexibility in compliance validation. The discussion also highlights the significance of vendor compliance and the implications of the PA DSS expiration. Attendees are encouraged to participate in future webinars for further insights.
TRANSCRIPT
Hello, and thank you for joining us today for our second PCI DSS 4.0 webinar.
Today, we will be taking a deep dive into the new 4.0 PCI DSS requirements that are applicable immediately for any four point o PCI DSS validations.
My name is Viviana Wesley. I’m a principal consultant on the HALOCK governance, compliance, and engineering team. I’m our PCI subject matter expert (SME) as well as a business leader on our governance, compliance, and engineering team. We also provide, expert witness support to offices of attorney generals for breach litigation cases.
I started in IT and transitioned into information security over thirteen years ago.
In our agenda for our webinar today, we will cover a brief introduction.
We will then talk about the fourteen PCI DSS requirements that are applicable immediately for any 4.0 PCI DSS validations.
For each of those requirements, we will review what that requirement is, what the purpose of that requirement is, the impact, and any potential process that needs to be adjusted.
We will also talk about why these requirements are applicable now and address any questions that attendees have.
So as a quick introduction, here is a list of the fourteen PCI DSS requirements that are applicable now in any 4.0 PCI DSS validation.
Thirteen of these requirements are applicable to any organization that validates PCI DSS compliance against 4.0. One requirement is applicable only to PCI DSS service providers when validating against 4.0 for any new assessment.
So let’s dive in.
The first eleven requirements are new roles and responsibility requirements. So every section of the PCI DSS now has a new roles and responsibility requirement associated with that section of the standard.
So first and foremost, network security controls, which is now the term used for building and managing secure networks within scope for PCI DSS compliance, section one of the new of the PCI DSS now has a roles and responsibility requirement.
So any or, any staff that are responsible for configuring, maintaining, managing network security controls need to be specifically called out in policies and procedure documentation.
This includes things like managing our network topology diagrams, managing our data flow diagrams, managing our network traffic restrictions, network change management, the biannual configuration reviews, the configuration files being secured and consistent between active and saved configs, and network security control configuration management.
All of those requirements within section one now need to have our responsibilities and roles defined somewhere in our documentation.
This was not previously required in the DSS. However, this is something that organizations were expected to somewhat understand. There was a roles and responsibility requirement associated with making sure that it’s understood who’s responsible for these things, but it wasn’t called out in a policy procedure standard the way that it is in 4.0.
So organizations are gonna need to ensure that these responsibilities are assigned formally, communicated to staff.
And in the guidance for this new roles and responsibility requirement, they also recommend that you consider having employees acknowledge those responsibilities.
That acknowledgment piece is not currently required in the DSS requirement, but it is in their guidance. So it’s a good practice. It’s a good way to make sure people are aware that this is part of their roles and responsibilities.
Next, we have the same roles and responsibility requirement for section two. So for this section, this is gonna include configuration management for all of the in scope components, component hardening, changing defaults, making sure that new configurations are accounted for, looking at new vulnerabilities, and those configuration hardening guides are addressing those new vulnerabilities.
All of that now needs to be formally defined and documented as part of the day to day responsibilities for those staff so people can understand that that’s something that they need to be responsible for maintaining on a regular basis.
One of the things that we see in all of these purpose, good practice example guidance columns for these new requirements, which the PCI DSS 4.0 documentation has a lot of really good guidance that wasn’t previously included, so people definitely should read that, is that you can use something that’s called a raci matrix to define this. Right? So you can actually have matrices that are defining who’s responsible for all of these things, and it could be for each section independently, or you can have one PCI raci matrix that talks about all of the different responsibilities that are applicable for your PCI environment in one document. You just need to make sure that if you take that approach, every section of the DSS and applicable requirements are being addressed in that documentation.
Again, they have the guidance that it might be a a good idea for you to acknowledge have your employees acknowledge that those roles and responsibilities are something that they are responsible for maintaining.
You’ll see a theme here, and we have one for every section. So when we get to section three, this is talking about the storage of cardholder data, the protections related to that, key management procedures, preventing the moving or copying of credit card data. All of those responsibilities in section three now also have to have defined roles and responsibility procedures.
Same guidance, same thoughts behind you can use the racing matrix to create that for this section or for all of the different sections between section one and section eleven of the DSS.
So a lot of the same language is being used in these roles and responsibility requirements. You’ll notice they don’t call out the individual requirements in that section that have to be addressed. They say anything applicable in that section. So it’s similar to what we’re seeing with what we previously saw with having documentation operational security procedures for that section of the DSS.
Now we have to have those roles and responsibilities defined for every section.
So we see that in requirement three.
We also see it for requirement four.
Related to secure communication controls, valid certificates, inventorying, trusted keys and certificates for the communication transmission of cardholder data over open public networks.
Again, this is gonna be based off applicability to your specific environment.
Also, for section five, which now talks more about malicious software than antivirus software, the verbiage there has changed, but making sure that anti malware protections are defined, the roles and responsibilities for who’s taking care of that is defined, the periodic process that is required now for components that are not at risk to make sure that it’s appropriate to still not have anti malware solutions if that’s applicable.
They also added some additional options for continuous behavioral analysis in section five. All of those roles and responsibilities to have to be defined for section five as well.
When we get to section six, as we have previously seen, this is still related to software, but it has expanded a bit to explicitly call out bespoke and custom software, making sure that we have inventories around that, making sure that somebody is managing our web application firewall.
There are some new requirements about around payment page scripts that are best practices, but the roles and responsibilities associated with that still need to be defined.
Making sure that any of our software is managed, inventoried, and that our development and preproduction processes are defined and controlled in accordance with the data security standard.
Section seven is still about access controls and making sure that people are being assigned access based on least privilege and job classification and function, the roles and responsibilities associated with ensuring that those controls are in place as new accounts are created or access is changed now needs to also be defined in roles and responsibility documentation.
This also includes new requirements related to application and system accounts that have interactive, sessions allowed. So there are some new requirements around that that also need to be defined and taken responsibility for in section seven.
When we get to section eight, we are still talking about authentication controls, making sure that our roles and responsibilities for strong authentication mechanisms are documented, assigned, and maintained.
This includes password complexity, multifactor authentication, system practice requirements until we get to twenty twenty five where those will be full requirements that also need to be defined in our roles and responsibility procedures for section eight.
Section nine still relate to physical access security controls, so we also wanna make sure that those facility, data center, cardholder data environment, sensitive area controls are all defined. They have adjusted some language in section nine to explain the difference between facilities, sensitive areas, in scope, locations.
And so that guidance is within the data security standard, but we need to make sure that those things are defined in our roles and responsibilities as well as our point of interaction device responsibilities, making sure that those physical security media controls are also part of our roles roles and responsibility documentation for section nine.
Section ten is still about logging and monitoring, but we need to make sure that those log reviews, those individuals, those teams that are responsible for those log reviews and follow-up processes are defined. We also need to make sure that whoever is responsible for time synchronization controls is defined in our in our responsibility documentation for section ten as well as some new requirements for all organizations when we get to twenty twenty five around critical security controls and making sure that any, failure in critical security control detection is documented, the process is defined, making sure people are responsible for being aware of that and monitoring that. So even though some of those things are still best practices until we get to twenty twenty five, the roles and responsibilities for everything in that section still has to be defined in our documentation related to PCI for policies and procedures.
Section eleven is still about network testing testing our network security controls or application security controls. Basically, just testing the security controls we have in our environment.
So when we’re documenting those roles and responsibilities, we have to keep in mind that that includes rogue wireless access point detection, vulnerability scans, penetration test, intrusion detection and prevention, file integrity monitoring, and new requirements around reporting changes to any payment pages.
So based on the guidance back from twenty seventeen when the council released some guidance around outsourcing ecommerce sites saying that we need to make sure that we’re protecting those integrations, we need to have roles and responsibilities defined for how we’re going to address that in the future. Again, those are our best practice requirements, which we will talk about in our next webinar series where we do a deep dive into the new fifty one requirements that are best practices until March of twenty twenty five. But those roles and responsibilities have to be thought about. We have to define which teams are gonna be responsible for those things.
Now that we’ve talked about those those eleven requirements that are pretty much the same, but just for each section, there’s three additional requirements that were added in section twelve that we need to discuss.
First is the new targeted risk analysis (TRA) requirement for the customized approach.
So if you remember from our last webinar series, the customized approach is a new method that organizations can use to validate compliance against one of the PCI DSS requirements.
This does not replace our compensating control option if there is a business or a technical constraint preventing somebody from implementing the control as stated. Instead, the customized approach is intended to be used for risk mature organizations that are addressing the control objective, but potentially not the way the DSS states it is done.
You most any organization that validates compliance through an on-site assessment has the opportunity to use the customized approach to validate controls.
That is if the DSS says there’s a customized approach objective. There are a few controls in the DSS 4.0 that are you are not allowed to use the customized approach for. The majority of those controls are in section three, but there’s also the external vulnerability scanning control that also is not allowed to be used through the customized approach.
It should also be noted that if an organization is validating compliance through a self assessment questionnaire, using the customized approach is not an option.
So you will not see this requirement 12.3.2 in any self assessment questionnaire (SAQ) because it’s not an option for people to use that to validate controls in the self assessment questionnaire. That can only be done through an on-site assessment that is then accompanied by a report on compliance (ROC) and attestation of compliance (AOC) associated with that report.
The whole point of the customized approach is to allow that flexibility for an organization to validate compliance for a control that they’re doing in a more risk mature way than the DSS states.
However, to add that flexibility, it’s still a trust but verify mindset.
So the assessed entity, the organization that’s going through the validation has to actually take the time to document a controls matrix to explain how their controls meet the control objective of the original control they’re trying to meet as well as to do a targeted risk analysis to explain how their customized approach controls mitigate the risk associated with not implementing the control the way that it was stated to make sure that we are in fact meeting that control objective as explained.
Because the customized approach is new, the controls matrix requirement is new, the targeted risk analysis for the customized approach is new. The PCI SSC has provided templates for documenting those things. You don’t necessarily have to use their templates, but the things that are included in their templates have to be included in your templates. So we will review that as well.
When an organization is going through a PCI on-site assessment and they are choosing to use a customized approach to validate a DSS control, they document the controls matrix, the targeted risk analysis, and then provide that to the QSA that’s performing the validation.
That QSA is then responsible for creating custom testing procedures to test that customized approach control and verify that it meets the intent of the control objective.
So let’s look a little bit at those templates that I mentioned. These templates are in the back of the PCI DSS 4.0. They’re within appendix d and appendix e.
Within appendix d, you will see that there’s additional guidance and information on using the customized approach. So if you’re considering using the customized approach for any PCI DSS requirement, Please read through that information and that guidance. It is very useful and important to understand.
In appendix e, you will actually find the sample controls matrix templates and the sample targeted risk analysis template.
Like I said, those templates don’t have to necessarily be used, but everything in those templates has to be addressed in the assessed organization’s controls matrix and targeted risk analysis.
Every just like a compensating control worksheet, every DSS requirement that is validated with a customized approach has to have its own controls matrix and its own targeted risk analysis. So we cannot use the same write up for multiple requirements each has to be addressed individually.
So let’s dive into what that template includes, what we need to call out.
First and foremost, you have to list out what is the customized control. Right? So this information, you actually, get this information from the you you specify your identifier, how you wanna refer to your control.
Then the next thing you explain in your template is which PCI DSS requirement number and which customized approach objective are you meeting with this control. So the template starts out with what am I calling my control object or my con my customized control, and then what is the requirement I’m using this control for to address?
Next in the template, we provide the details of the control. So this is where the assessed entity is going to explain the what, the where, the when, the who. So it actually explaining all the details of the controls that you are using to meet that control objective.
It has it does provide also a few more elaborate descriptions within the template so you get a sense of what they’re looking for in here.
Next, we have to talk about how the control objective is being met. So how does your custom control meet the objective that is within the PCI DSS for that specific DSS requirement?
So actually looking at the DSS requirements, summarizing what that control objective is, and then talking about how you’ve tested your control to ensure that it’s meeting that control objective.
So not only do you have to explain what your control is, but you have to explain how you’ve tested it to verify that that control objective is being met.
Then you have to summarize the results of your testing and your targeted risk analysis for that control. So you have to perform a targeted risk analysis and summarize what was found in that targeted risk analysis that led you to believe that you were meeting that control objective.
Then you have to explain how that control is being maintained and how through the maintenance of that control or the oversight that you’ve implemented, you have assurance that that control effectiveness is actually happening. Right? So making sure that that control is effectively reducing your risk as well as meeting your control objective is what they’re looking for in that bottom row there, actually explaining how you’ve come to that conclusion.
So, essentially, defending what you’re saying your control objective is meeting. How how did you make that determination?
And then we get to the targeted risk analysis template. So in the targeted risk analysis template, this template is only used for customized approach requirements. So please keep that in mind. There are two places within the PCI DSS 4.0 where they talk about targeted risk analysis.
Those are two different requirements.
What is required in each is actually different. The targeted risk analysis for the customized approach is this template.
There is another targeted risk analysis requirement for periodic controls and what they’re asking for, and they’re slightly different. So we will talk about that more next week when we dive into those best practice requirements that are not necessarily full requirements until March of twenty twenty five.
In the targeted risk analysis template for the customized approach, first, you start out with the same thing. Identify the PCI DSS requirement that you are meeting. Identify the objective of that PCI DSS requirement as written in the data security standard, then we get to describing the mischief that our requirement was designed to prevent. So here, we’re explaining what the mischief is. If you attended our webinar last week, we spent a little time talking about mischief.
There is some guidance inside of the DSS to explain what mischief is.
The easiest way for us to really explain it to organizations is the mischief is the opposite of the control objective.
So if your control objective is for malware not to run on in scope systems, the mischief is that malware ran on in scope systems.
After you explain what that mischief is and how your how, how that objective is being met, then you have to explain your proposed solution.
So, again, citing that customized control identifier that we talked about in the last append in the last template so that what whatever you called your customized control.
Then when parts of the requirement as written will change in the proposed solution.
So if there’s something that’s going to be adjusted or is gonna be different than what was in the data security standard, you wanna make sure you’re calling that out. Right? So this is talking about, you know, the difference between the defined approach and the customized approach and how they’re why kind of why you’re using the customized approach rather than the defined approach.
Right? So a good example here is organizations that use continuous vulnerability management.
Rather than having the ability to obtain a passing vulnerability scan every quarter, those organizations that have a continuous vulnerability management solution that’s constantly checking for vulnerabilities and then also remediating those vulnerabilities automatically, it might be more difficult for that organization to obtain passing vulnerability scans every quarter because that status changes potentially minute to minute.
But they’re actually being more proactive because it’s a continuous process that’s automatically addressing those vulnerabilities.
So that’s kind of what they’re looking for in section two point two here is how is your use of the customized approach different from the defined approach, and does that potentially change, in your proposed solution?
And then how is your proposed solution preventing the mischief? So how are you managing your mischief?
Section three of the targeted risk analysis template talks about making sure that we’re thinking about the likelihood of mischief occurring and how your customized approach controls impact the likelihood of that mischief occurring. So would would the mischief potentially occur more frequently if there’s no change in that likelihood or if it’s less likely to happen, that’s what they’re looking for here. They want to see the likelihood of mischief occurring and how your customized control impacts that likelihood.
So there’s different information that’s being asked for here in this section to talk about that.
K?
Next in section twelve, we have a new requirement for scoping.
So PCI DSS scoping is one of the trickiest things that I think anybody has to deal with for this standard.
Not only do we have to take into account the who is the merchant on record and if we have a third party service provider involved, but then we also have to take into account our entire business. The PCI DSS applies to any potential receiving of full credit card information no matter what acceptance channel that comes through. And so now organizations, as soon as they validate compliance to four point o, they’re going going to have to show that they are doing an internal scoping exercise to confirm their scope prior to an assessor walking in the door and asking for scope validation materials like topology diagrams, data flows, inventories, third party service provider (TPSP) documentation.
This requirement is actually asking for the assessed entity to do that review prior to us coming into the door and being able to show us documented results of those scoping exercises.
The you will notice that this particular requirement is fairly long.
When it was cut and put into a presentation, like, you’ll notice in the guidance column, it’s continued on the next page. They have a lot of really good guidance and information information within that column to explain what potential things you might wanna consider or look at when you are doing a scoping exercise within your organization.
Essentially, you wanna make sure that there’s no new initiative or new business process that wasn’t previously part of your scope, depending on the type of organization and how controlled, payment processing is, how streamlined it is, which you know, how new implementations get set up. Organizations might have to talk to multiple departments and verify that there was no new initiative related to payments that went into place between last year’s validation and this year’s validation.
Ideally, that information should be already identified as part of change management processes.
Ideally, our IT teams and our information security and compliance leaders are part of those discussions to identify any potential scope changes prior to a validation.
So we’re really hoping that a lot of organizations are already taking steps to verify their scope on a regular basis.
And so, hopefully, this isn’t gonna be a big effort for most organizations. It’s gonna be more of a formalization of a process or ongoing processes that are are already in place to identify potential scope changes and ensure that they are included in your PCI cardholder data environment scoping.
Now there’s also a possibility that somebody will come across something during their scoping exercise that they don’t want to pull into scope or they don’t want to in include in their cardholder data environment because it was an unapproved method.
And so there’s an always another option. Right? Instead of pulling something into scope, organizations can also consider changing business processes or technologies to actually eliminate that.
One of the things that we’ll talk about next week is there is a new incident response procedure that will be asked for once we get to March of twenty twenty five that has a documented process if somebody or if somebody identifies the cardholder data in a unapproved channel or an unapproved method or something happened where all of a sudden we have car credit card data in this process that previously never had it. So there will be a documented process come twenty twenty five where organizations will have to explain how to address that. Again, either you pull it into scope and you make sure all of the controls are in place that need to be in place, or you potentially change your business process or your technology to remove that from scope and eliminate it as, a vector that cardholder data can enter.
Of course, we can’t always prevent what people send to us. And so that’s also a good idea to have that documented process if you receive data in a way that you do not approve, how the organization can eliminate that so it doesn’t need to impact somebody’s compliance scope.
And then last but not least, there’s a new requirement in 4.0 for PCI DSS service providers.
I was just at a conference, where this was a unfortunate theme that we heard where compliant PCI DSS organizations are struggling to get the information that they need from their PCI DSS service providers, either because the PCI DSS service provider doesn’t think that they are a service provider or they’re not sharing the level of information that’s necessary for organizations to confirm that they are compliant for the services being provided.
I believe this has been a running theme in our payment industry for several years. I would say that the PCI SSC has really been working hard to eliminate this from being a problem really ever since the target breach. They’ve done, they’ve made updates to the PCI service provider definitions. They provided additional guidance, additional frequently asked questions on the on the topics.
But even this week, we’re still hearing that this is a significant issue in this space.
Unfortunately, a lot of times, people think that if a third party service provider is not storing, processing, or transmitting credit card data, they are not a PCI service provider, and that’s not true. If an organization is providing a service to another organization that could impact the security of that organization’s environment, they are a PCI service provider.
We just need to understand exactly what services are being provided, who’s responsible for what.
One of the things that I often tell clients about is if you’re struggling to determine if an organization is a third party service provider to your organization, a way that I like to think about it is if that third party service provider was breached, would that put the bad actor in a better position to then impact the security of your environment?
If that answer is yes, then they are likely a PCI DSS service provider. That doesn’t necessarily mean their entire environment’s in scope. However, the people, the processes, the technologies that they use to provide that service to you is where their scope is.
If they stop maintaining the technology the way that they need to, if their processes break down, if their people are not educated in in how to secure information and how to secure those services, then potentially, an in the incident in their environment, if that could impact your environment, that’s when they fall into the PCI service provider category.
So what we’re seeing in twelve nine is another attempt of the PCI Security Standards Council to help organizations that are trying to get PCI DSS compliance information from their third parties to receive that information.
So we are hoping that we do see this trend start to stop. There was even questions at the conference that I was at if the PCI SSC would ever consider changing the definition of service providers to not start with store, process, or transmit cardholder data Because the PCI data security standard is really applicable when an organization is dealing with cardholder data, and it’s so crucial to this standard and to how this is enforced, there’s a good chance that change won’t be made. But it is definitely something that the SSC is aware of that this is an issue in the industry, and they definitely are doing what they can to help alleviate some of those questions. So we might see additional frequently asked questions, articles pop up on the website at any time with additional information about, is somebody a PCI service provider to me? How do I make that determination?
How can I help them understand the the impact of security that they will have to my environment?
So this is definitely something that I am glad to see in the DSS. I’m also glad that this is a new now requirement rather than something that’s new in twenty twenty five.
It it’s definitely a step in the right direction, but we know that we still have some strides to make there.
So why are these specific requirements applicable right away? And luckily, I got a chance to actually hear two SSC members talk about that this week.
One of the reasons that they explained that these requirements are applicable for PCI DSS 4.0 validations right now is because they expected most organizations already have these things in place. They didn’t think that these would be huge undertakings for organizations.
So the thought process with the roles and responsibility requirements, well, we need to have security and operational procedures and policies for every section of the DSS defined.
Okay. So we have those those information security operational procedures defined. We should also be able to easily explain who’s responsible for all of those things.
Somehow in the organization, we should probably already know that. We most likely already do. So it should just be a matter of formalizing those roles and responsibilities and shouldn’t be very time consuming.
Related to scoping. Again, organizations should be this information ideally before an assessor walks in the door. We all know that things get very busy and and that may become difficult for organizations to do, and so potentially they’re doing it as part of their validation processes now. So there definitely will have to be some formalization to that scoping exercise that previously wasn’t required. But, again, the PCI SSC is hoping that organizations are already doing things along that line to confirm their scope before validation time.
And then for third party service providers, we would have all hoped that they would be providing their clients information about their compliance and their responsibilities already. So, again, it’s something that the council was really hopeful that organizations are already doing. They do not expect these fourteen things to take organizations a lot of time, money, or effort to put in place. It’s more formalizing things that we expect and hope organizations were already doing.
Alright.
So at this point in time, I’m going to turn it over to our attendees and see what questions they might have.
Just to note that you are all on mute. So if you wanted to speak, you have to unmute yourself first.
Thank you, Rachel.
I have a feeling more people might have more questions about the fifty one requirements due by March of twenty twenty five.
These fourteen should now be pretty heavy lifts for people. So and we are hopeful that the fourteen new now immediately for any 4.0 validation are pretty straightforward.
And I will go back to the summary slide just in case anybody had any specifics they wanted to call out, but just can’t think of them off the top of their head.
But as you see, the first eleven are very, very similar roles and responsibilities for those sections, then the three additional requirements in section twelve.
Yes. Jalen.
See if I can unmute you.
Hi, Viv. This is, Jason and Jalen from Ultra Camp. Thank you so much for doing this. We’ve really been enjoying it.
We work with a lot of, you know, we have a lot of clients that do, the PCI DSS self questionnaire, and a lot of them are using, SAQ A.
I know a lot of these requirements are for, you know, the service providers and stuff.
Are there particular things with these new PCI DSS requirements that, would be specific to, to those a people filling out the a that we can just maybe start getting people prepared and and understanding what they’re what they’re gonna need to do as they transition to 4.0?
Absolutely. That’s a that’s a great question.
So that was one of the things that I was curious about as well when four point o came out. And in my copious free time, I decided to we well, we decided to do a comparison between the self assessment questionnaires that were in version 3.2.1 and the self assessment questionnaires (SAQs) that are in version four. And so there are some additions to just about every self assessment questionnaire.
And Cindy or Rachel will have to correct me, but I believe our last webinar in our five webinar series is the self assessment questionnaire comparisons.
So we did absolutely that. We literally had them both up up side by side and said, which which ones are brand new?
Literally, almost everything was touched between version three two one and four. If a requirement was not moved, it was at least updated or some verbiage was changed.
However, what we initially what we called out in these self assessment questionnaire comparisons were the requirements that were being added that were not previously in three two one. So we do have that information that will be the topic of our webinar on June first.
And after that webinar, we will be happy to provide any of the attendees that, those specific requirements and the specific guidance for each of those because there are some additions they will be making.
Some of that actually includes external vulnerability schemes for SAQ A merchants as well as some payment page script protections that we previously did not have in the DSS.
Excellent. Thank you so much.
Absolutely. Can somebody unmute Scott?
Can you hear me now?
Yes, sir.
Yeah. Hi. My name is Scott Brinker, senior manager of cybersecurity at College of Micro Pathologist. And I have a you know, Jalen mentioned the, self-assessment questionnaire. We actually haven’t done that yet, but we’re considering doing that just to give us some extra visibility into our, I guess, defining our risks when it comes to our payment card industry data. But does do you recommend that self assessment questionnaire just to give us our own kind of insight visibility into those risks? And does it cover vendor, you know we actually perform a lot of our, payment card processing through other third parties.
So does the self assessment questionnaire cover those third party entities as well?
Yeah. That’s a great question, Scott. So there’s, there’s a couple pieces to your answer that I will kinda split up in my response. So there are nine self assessment questionnaire types.
Eight of those are for merchants, and only one is for third party service providers.
There’s essentially, third party service providers are only allowed to validate compliance through a self assessment questionnaire type d for service providers.
Because there’s requirements in the data security standard that are just for PCI service providers, they actually carve out their whole separate self assessment questionnaire.
I will say that during the development of 4.0, the PCI security standards council floated the idea of no longer letting third party service providers do self assessment questionnaires. They literally were gonna remove that self assessment questionnaire type. There was quite a bit of pushback in the industry, so they left it in. However, they’re not making it easy.
Yeah. The self assessment questionnaire for third party service providers will actually require those third party service providers to do a write up for each requirement.
So it’s no longer a yes, no question. It’s no longer a check the box. When they check the box, they then have to explain how they determined that they were in compliance with that requirement.
So they’re essentially trying to make it more and more difficult for third parties to self assess is what I’m getting from that.
Each of the other self assessment questionnaire types have specific conditions or what they call eligibility criteria for you to be able to use that self assessment questionnaire type.
I don’t remember if they released a new self assessment questionnaire instruction guide, but I do know for four point o. But I do know that, the self assessment questionnaire types did not change between three two one and four. So we have the same types we have on the current version as in the new version, and there is an instruction guide document that they created for three two one that explains when you can use each of the self assessment questionnaires.
There there’s a variety of requirements that are applicable in them. So when you’re outsourcing to a third party service provider, but you are still the merchant on record, you do still have a reporting obligation for compliance because you’re the merchant on record and the way that PCI is enforced is by contract.
So in scenarios where you’re outsourcing all payment processing, storage, transmission to third parties, you may be able to use a self assessment questionnaire type a.
If the way that you integrate to that third party or the the services you use, do not allow you to say you are eligible for each of the eligibility criteria in that self assessment questionnaire type, then that type might not be applicable to you. So, Scott, we can always have follow-up discussions and and kinda dive into your specific scenarios because I know that people don’t like to hear this from QSAs, but it kind of depends on on what technology you’re using, what your payment processing is specifically, and how that would be applicable for your compliance validation.
Got got it. Thank you. That was helpful.
Absolutely.
Does anyone else have any questions today they would like to discuss?
Okay.
Well, in that case, if you do come across an oh, yep. I see a hand raised.
So your mic should be allowed, but you may have to, click a button to enable it. Can you hear me now?
Yes, ma’am.
Okay. So I I put the question in chat, but, basically, it is if we have a a payment application, a P-ADSS validated, it’s a preexisting installation, you know, because all of those are expired.
Yes.
But we’re still using it, and we it uses hashed pan.
It but it does not meet the keyed hash.
Okay.
Like, how would we address that?
Okay. So as you so eloquently pointed out and correctly pointed out, the PA DSS did expire. That expired actually in October of twenty twenty two.
I don’t know. Theresa, were you able to join our webinar last week?
No. I wasn’t able to.
To actually pull up a slide from that webinar series just to illustrate what we’re discussing specifically.
Okay.
So as you pointed out, the PA DSS has expired. It’s actually been replaced with two other standards.
The PCI Security Standards Council likes to keep themselves busy. They now have fifteen standards under their, under their organization. So there are two additional standards that replace the PA DSS. They are called the secure software life cycle standard and the secure software standard.
Depending on what your application is and who your vendor is, they might already be looking at certifying under one of these certifications with the PCI SSC.
First and foremost, I would always go back to your vendor and say, hey. Now that PA DSS has expired, are you are you gonna go down one of these roads? If so, we need to understand what the timing is and what that implications are to our organization.
One of the things to keep in mind, and and this this was the case with PA DSS, and it will also be the case with the secure software, a CLC standard, and then secure software standard.
Using a validated PA DSS application or a validated secure software application can enable can help enable your compliance, but it doesn’t automatically make you compliant, and it’s not required for you to be compliant.
So you can be compliant outside of that certification, but you will have to address potential requirements that are applicable to your organization.
As you mentioned, the key hashing requirement is something that your vendor is not currently addressing.
That key hatching requirement is a best practice requirement until March of twenty twenty five.
So they have a little time to make sure that they their application supports that need for their p a for their PCI customers.
But my best recommendation to you at this point is to go back to that vendor and say, I know that PA DSS has expired. I know that it’s been replaced with two other certifications from the PCI security standards council.
Please give me some information on how you plan to support your customer’s PCI compliance moving forward. And they’ll they’ll help you determine, are they aware of this? Are they already working on this?
You know? Are they already down this path, and they already have a timeline for addressing these requirements? So it’s really hard for us to specifically tell, but the best route is to go back to that vendor. And then if the responses you get back from that vendor are not ideal or not what you would expect or want, feel free to reach out. We’re always happy to help support you and facilitate discussions and further information there. But there are two additional standards they might be eligible to get your application certified under in the future.
These standards are out there. There are software solutions that are already certified under them, so it’s not like they expired PA DSS without having a replacement.
Does that help?
Thank you. Yeah.
Anyone else have any questions they’d like to discuss today?
Okay.
Well, as, previously with the case with our other webinar series, the recording will be available as well as materials that, we’ve created for this presentation so organizations can review those materials. And please, again, if if you run into situations where you need some QSA assistance, please don’t hesitate to reach out. We know that these transitions can be confusing and, can come with lots of questions as we start to look at addressing those specific requirements. So we’re happy to see that, you can join us. Thank you for your time.
So we’re happy to see that, you can join us. Thank you for your time. We do have additional webinars coming up.
Next week will be a deep dive into the fifty one best practice requirements that are, best practices until March of twenty twenty five.
Then we will talk in more detail about targeted risk analysis all for the customized approach as well as for the periodic cadence requirements that are in PCI DSS 4.0. And then last but not least, we will do that SAQ comparison on June first to give organizations an understanding of what’s changed between all of those SAQ types with the exception of d, of course, because that’s everything.
Thank you all so much for your time today. We hope you enjoyed our informational webinar series so far, and we hope to see you again in a future session.
Thanks, Smith.
Absolutely.
