The new PCI DSS v4.0 Targeted Risk Analysis (TRA) allows a more adaptable, risk-driven approach to security. Instead of adhering to prescriptive controls, organizations can assess a select set of requirements based on their own risk profile, environment, and business requirements.
This shift will transform security strategy by calling on organizations to:
- Rank threats and controls according to business impact and likelihood
- Connects security decisions with an organization’s legal duty of care and risk tolerance
- Take a more agile, evidence-driven security stance that responds quickly to emerging threats
Lastly, TRA empowers organizations to justify their security decisions without ever having to make a compromise on compliance—yielding smarter, defendable, and business-led cybersecurity initiatives.
Our webinar shows how the Duty of Care Risk Analysis (DoCRA) approach enhances your security program. DoCRA offers a principled, quantifiable, and legally defensible way of conducting PCI DSS Targeted Risk Analyses. Viviana Wesley, PCI QSA, ISO 27001 Auditor, CISM and Todd Becker, PCI QSA, ISO 27001 will showcase that by combining business goals with duty of care and regulator demands, businesses can make informed, risk-informed choices that will comply with PCI v4.0 demands and help achieve reasonable security.
TRANSCRIPT
Hello, and thank you for joining us for HALOCK’s fourth PCI DSS v4.0 webinar.
Today, we’ll be talking about how to do targeted risk analyses that are found in PCI DSS 4.0 using a Duty of Care Risk Analysis (DoCRA) method.
My name again is Viviana Wesley. I’m a principal consultant on the HALOCK Governance Compliance and #ngineering team. I’ve been with the organization for over thirteen years and have been specializing in information security since then.
I’m joined today by Todd Becker.
Good morning, everyone.
I’m also a principal consultant with HALOCK, similarly working in our governance and compliance practice, and have had over ten years of information security and twenty five twenty eight plus years of information technology. And both Viv and I have been working as expert witnesses with state offices of attorneys for multi-district litigation matters, which is pertinent for for today’s conversation.
Absolutely. Thank you for joining.
No problem.
Today, we’re gonna cover a few different topics. So first, we’re gonna start with an introduction, start to understand exactly what’s being introduced in PCI DSS 4.0. What do they mean by Targeted Risk Analyses (TRA)? We’ll look at the two different types of targeted risk analyses that are being introduced in 4.0, as well as understanding the differences between those two methods.
And then we’re gonna transition into why would you use a Duty of Care Risk Analysis (DoCRA) method when you’re doing these targeted risk analyses, why is it important to consider that, and also talking about how we would actually model those things out, what to think about when you’re looking at these particular requirements, the targeted risk analysis, and how to protect your organization in a Duty of Care Risk Analysis method.
So let’s dive in.
First and foremost, PCI DSS 4.0 talks about Targeted Risk Analyses and multiple requirements.
However, when they are talking about targeted risk analysis, they’re actually describing two different risk analysis methods.
The first risk analysis method is for periodic cadence requirements. These are cadence requirements that must be done when there is a periodic requirement.
So several requirements in the PCI DSS 4.0 explain that organizations can implement a control or can utilize a control on a periodic cadence. For those particular requirements, the organization must justify why that cadence is appropriate for their particular environment.
The items that are required in this targeted risk analysis are described in a bullet list within that requirement, so we will look specifically at that.
Then they also introduce a targeted risk analysis when validating compliance with the customized approach.
The customized approach is a new way that organizations can validate compliance with particular requirements by meeting the control objective rather than the defined testing procedures that are specified in the data security standard.
But how to do that targeted risk analysis is different than the one we just described with cadence requirements.
There are two appendices that are actually dedicated to the customized approach targeted risk analysis in PCI DSS 4.0. The first appendix in appendix d talks about why would you use the customized approach, what is it intended for, how to use it. And appendix e provides templates, sample templates for a controls matrix and a customized approach targeted risk analysis. So we’ll look at the difference of the details between both of those and talk about when you use which one.
So let’s start with the cadence requirement targeted risk analysis.
Like I mentioned, there are several requirements in the DSS now nine that when you get to version 4.0, call out a periodic cadence.
And then they essentially, what these requirements explain is if this is applicable to your environment, you can still do this on a periodic basis, but you have to define what that periodic basis is and why it’s appropriate for your organization.
So for every periodic requirement that is applicable to the organization, a corresponding targeted risk analysis justifying that cadence is going to be required.
That targeted risk analysis has to talk about the assets being protected, those threats that you’re protecting against. It also needs to consider factors that contribute to the likelihood or the impact of that threat being realized.
That resulting analysis should include the justification for the frequency of your control.
And as I mentioned, this has to be documented for any applicable periodic cadence requirement. So though they are adding flexibility by allowing you to keep this periodic, you need to justify and document why that flexibility is appropriate.
So the assessed entity has to complete that targeted risk analysis at least annually and then verify and review that annually, determine if a new risk analysis is needed or if that cadence is still appropriate.
They also have a lot of additional guidance and, recommendations within the text of v4.0 now. So the guidance is included in the text of the data security standard, and they explain in that good practice that even though they are removing the enterprise level risk assessment from the PCI DSS standard, it is still a recommendation to perform a enterprise level risk analysis to ensure that you’re doing what you should be doing for your organization from a risk perspective. So they’re leaving it in the recommendations and the good practice guidance, but it’s not a separate requirement.
So I mentioned that there are nine DSS requirements that now require a targeted risk analysis for that periodic cadence justification.
This list is of those nine requirements. You will notice in all of those requirements, they actually refer back to that 12.3.1 control.
So it ties those two things together.
We see a variety of different controls being being listed in here. Things like making sure that if your organization is using components that are not commonly at risk for malware, if you are not using anti-malware on those machines, you need to have a targeted risk analysis to justify how frequently you make that determination.
Also, if you are doing periodic anti malware scans, you need to have a targeted risk analysis to justify how frequently those scans should be running.
Then in section seven, we see a targeted risk analysis being required for the cadence of user account access reviews. So this is a new requirement that’s being added, but the cadence of that review is something that you can document and justify based on the applicability to your environment.
Then in section eight, we see that there’s an addition to application and system accounts and how frequently those passwords are changed based off of your targeted risk analysis periodic cadence requirement.
Then in section nine, we previously saw a lot of this information be in the guidance of these requirements. But now when you’re looking at point of interaction devices and doing those device inspections, the frequency of those device have to be based off of your targeted risk analysis cadence for this particular requirement and this particular control. So all of the things that they put in guidance and said, base this off of your risk assessment, now a full requirement for a targeted risk analysis.
Then when we get to section ten, we see a control around the periodic log reviews. So if you have in scope components that are not part of your daily log reviews, maybe you have connected systems that you’ve justified a less frequent log review on, that now has to be justified through a targeted risk analysis.
Then when we get into section eleven, we see that they’ve included a new requirement to address all other applicable vulnerabilities for internal vulnerability scans.
So previously, internal vulnerability scans said you had to address all high risk vulnerabilities.
Now in version four, it says high and critical vulnerabilities must be addressed within a ninety day period so you can achieve a passing result.
But if you have other applicable vulnerabilities, those now need to be addressed based off of your targeted risk analysis.
Then when we get also at the bottom of section eleven is the requirement for tamper protection, mechanisms being deployed and making sure that the frequency of those reviews that the tamper protection or change mechanism or file integrity monitoring tool is is verifying that changes are not occurring, that frequency should be based on a targeted risk analysis.
And then last but not least, incident response training.
Periodic incident response training now has to be defined based on your targeted risk analysis. So how often should you be training your incident response team on your incident response plan (IRP), making sure that people are aware of what they should be doing should be based on your targeted risk analysis? So nine potential new targeted risk analysis requirements just for periodic cadence requirements.
So no matter what, everybody’s gonna have to do some sort of targeted risk analysis when you get to PCI DSS 4.0. Even if you’re not using the customized approach, you’ll have to do a targeted risk analysis for one of these particular requirements.
Customized approach. Okay. So as we mentioned in one of our first webinars, PCI 4.0 is introducing a new way to validate compliance controls.
In the data security standard, every requirement now has a customized approach column or field added for it. If you can use the customized approach to meet that control objective, then they provide a control objective for that particular control. And that’s what you’re trying to satisfy when it comes to your PCI compliance for that particular requirement.
This approach is intended for much risk mature organizations.
This is not a replacement for compensated controls.
This cannot be used when you’re validating compliances through a self assessment questionnaire (SAQ).
So the only organizations that can use the customized approach for validating requirements are ones that go through an on-site assessment with the QSA.
You will not even see the customized approach objective in the self assessment questionnaires because it can’t be used with them. So if you are an organization that validates compliance through an on-site assessment with the QSA, you have the option of using the customized approach to meet a control objective.
To do that, though, just like everything else, when we add flexibility in PCI, we add some additional trusted verification steps. Right? So if you want to use the customized approach as an organization, you have to document what’s called a controls matrix.
That controls matrix basically explains the control that you have, how it meets the control objective, how it’s reducing the risk appropriately.
You provide that controls matrix as well as a targeted risk analysis that you do for the customized approach to a QSA.
That QSA reviews that information and creates custom testing procedures, and that’s how that control gets validated.
So to overly complicate this, they have created lots of different guidance and appendices around this. So we’re gonna dive through those details, look at the specifics, and figure out exactly what needs to be included.
Like I mentioned, this is the second type of targeted risk analysis in PCI 4.0. So all of those cadence requirements we just talked about, this does not apply to those. This is a separate thing that you would potentially do.
Okay.
So this customized approach targeted risk analysis requirement is right under the other targeted risk analysis requirement in section twelve. It’s requirement 12.3.2, and there’s definitely a difference. So the instead of having the bullet list of what needs to be included in your targeted risk analysis, they actually reference the appendices. They reference appendix d. They reference appendix e because those are where all of the content that should be going into that customized approaches. So we’ll look through those details as well.
Just like we mentioned before, whenever we add flexibility to something, we need to have some way to verify what we’re actually adding flexibility for. Right? So the organization that is being assessed is responsible for documenting that control of me that controls matrix and performing that targeted risk analysis before a QSA walks in to validate the environment.
Those results, that documentation should be provided to the QSA during the validation so the QSA can then create testing procedures to then test those controls.
Part of the process of documenting your controls matrix and the targeted risk analysis used for the customized approach is to verify the control is effective for your organization to actually test the control themselves, and then a QSA comes in and does additional testing. So that’s why they want the assessed entity to go through that exercise themselves to make sure that they’re comfortable that that control is meeting the objective before an assessor comes in and verifies that as well.
Okay. One of the things Todd and I have had lots of conversations about is mischief.
There’s a new term in the PCI DSS related to targeted risk analysis for when it comes to mischief.
And in appendix d, you will see some explanation around this as well as in the in the matrices and in the templates that they provide for the controls matrix and the targeted risk analysis.
Essentially, what they’re saying is mischief is the occurrence of something negative happening. So if the control objective is that malicious software doesn’t execute, the mischief is that malicious software executed.
Right? So the intent is that people understand when there’s a control objective, the mischief happens if that control objective is not being met. It’s kind of like the opposite of the control objective.
The targeted risk analysis template has five different parts to it that basically are asking you to explain your control, your proposed solution, think about the likelihood of the mischief occurring, and what how your control has potentially changed the impact or likelihood of that occurring.
And then, of course, approval and review because you wanna make sure that whoever’s got accountability and responsibility for PCI compliance is also involved in this procedure, approves this documentation, approves the approach you’re using, and is part of that annual review process as well.
So let’s start looking at some of those supporting templates that I mentioned at the back of the data security standard.
So appendix d and appendix c is definitely something that is good reading for all organizations even if you are not using an on-site assessment or you’re still validating with an SAQ. I think it’s very helpful to understand the context in here and how they’re asking people to think about risk as it relates to compliance.
The very first thing is identifying the PCI DSS requirement and the control objective. So you actually get to name your custom control something, and then you list out what PCI DSS requirement that control is intended to address. So you list the requirement number, the objective number, or the objective description.
You will see that it it does allow you to have more than one requirement listed in here and one more than one objective listed in here.
Because a control matrix could describe a control that’s used to address multiple DSS requirements. So that’s why they’re allowing you to have more than one listed in the controls matrix template.
Next, in part two of the controls matrix template, they want us to explain the what, where, when, who. So what is the control? Where is it deployed? How do we know it’s working? And who’s got an accountability and responsibility for maintaining that and following up if it’s not working?
So really thinking about not just the control, but the responsibility and accountability of that control.
In part, in the next part here, we see that we all then have to describe how that control objective is being met.
Right? So how does your control meet the customized objective that the DSS put in the requirement that we’re trying to address?
What testing have you performed to verify that the control is effective and demonstrates that that risk is being reduced appropriately. And then they want you to describe the results of the targeted risk analysis that you’ve done to have that conclusion. So what did you see that made you believe that that was sufficient?
And then the entity has to describe how you are going to maintain measures and metrics to ensure the control is effective, to ensure that it’s it’s gonna be maintained on an ongoing basis. So how do you know if this stops working? Right? If this control fails, if if somebody stops following up on a certain process, would you know? How do we know it’s being maintained?
So very similar to the types of things we think about whenever we’re thinking about compliance and oversight.
Then we see the targeted risk analysis templates. So this is after the control matrix template. As part of the customized approach, you have to do both a controls matrix and a targeted risk analysis.
The targeted risk analysis template also includes information about which PCI DSS requirement this applies to. So the requirement as written, defining the objective of the requirement. Those things are both listed in the DSS.
Describing the mischief of the requirement that it’s designed to prevent, again, kind of the opposite of the objective, and then describing your proposed solution. So that next step is what was that control matrix identifier name that we had up in the other template?
What are the parts of the requirement as written that will change because of your proposed solution? So what is different about your solution than what’s actually in the DSS requirement?
How is your proposed solution gonna prevent the mischief of that control objective?
So how will you prevent preventing that bad thing from occurring?
And then likelihood and impact analysis.
So analyzing the changes to the likelihood of the mischief occurring is very important here.
Basically, what we’re trying to say here is when you’ve implemented a safeguard to reduce the risk of, of a risk being realized to your organization, how do you know that that risk is actually being reduced? What is the likelihood of that risk occurring now because of the control you’ve implemented? It’s the same thought process we typically go through on on risk analysis no matter if we’re looking at PCI or not. Right? So you still want to be able to describe the reasons that mischief may still occur. So if if something bad could still happen, what is that, and how could that happen? And how does that potentially change the likelihood?
Does your control actually make it less likely for that mischief to occur? Are you doing something that’s above and beyond what PCI is already requiring?
Keep in mind, some of our requirements have specific cadences. Right? So if we’re doing something more frequently than that cadence is requiring, the likelihood of that mischief happening may be may be going down. So they’re trying to really understand what’s at play with the change in control from what’s written to what you’ve implemented.
And then provide the reasoning that your change to the likelihood of mischief occurred once that customization is in place. Right? So if the likelihood changed, how? Why? Why do you believe that likelihood changed? So they’re trying to get you to explain how your control is impacting that likelihood.
Next, we talk about the specific impacts sections. Right? So this is, four one is something new. PCI has never done this before, but it makes sense when you think about it from a risk perspective.
Right? They’re curious how much credit card information data is actually at risk here. How much pan information are we talking about? Right?
So it really depends on which particular PCI DSS control are we referring to, which components are we referring to, how much access do they have to credit card information.
And then explaining how the description of your customized control directly will either reduce the number of individual pans that are at risk or allow for you to have notification of compromised pans more quickly.
So now they’re saying, how does your control actually reduce the impact to your compliance obligations? Right?
They’re trying to ask and get you to think about if I am implementing this safeguard, is it actually reducing that risk sufficiently? Is it actually making less data susceptible, or is it making our response time, greater rather than more or more timely rather than greater?
And then last but not least, risk approval and review.
Just like everything else, we wanna make sure that upper management knows what they’re taking accountability for, knows what risks the organization has, is aware, is part of the review process, and it’s included if a new risk analysis needs to be conducted.
So you’ll see here that, you know, making sure that the that control will reduce the risk or allow that quicker notification is ex is extremely important to the council because that’s exactly what that PCI data security standard is intact intended to protect. It’s intended to protect that consumer cardholder data, but we’ve never specifically called out how much data is at risk in previous DSS requirements. So this is definitely a new addition for them.
Okay.
With all of that said, unfortunately, Todd and I have come to realize over the years that might not be enough, especially when an organization has potentially suffered a data breach.
Todd, do you wanna jump in?
Sure. Thanks, Viv.
So what Viv has just kind of run us through is PCI’s approach in increasing risk analysis and risk utilization and meeting some of the objectives of the DSS. Right? And we all know that the DSS is very targeted in what it’s trying to protect. It’s trying to protect cardholder data.
Right? That is the the main goal of the DSS. Your system could be totally offline and inaccessible to anybody. And in the DSS eyes, in in the council’s eyes, that’d be fine.
It’s protecting all the information. It’s totally unavailable, and there’s nothing that that could be compromised with that. From a business and an operations point of view, that’s not so good for you and your organizations. Right?
So there are aspects that the DSS isn’t necessarily thinking about when its controls were written and how it’s approaching its protection of information because it’s really focused on this very specific type of information.
And what we have seen is through the litigation work that we’ve done is organizations who put a heavy reliance on, I’ve got my PCI DSS certification, therefore, I’m good, and everything is protected.
And what we’ve seen is that’s not necessarily the case, that there are other pieces of information that may be compromised even if you’re protecting your cardholder data. And so as we start looking at how risk is being integrated into PCI requirements, we wanna start thinking about risk organizationally as we consider these PCI specific requirements and PCI specific options for documenting, an approach and targeted risk analysis. We wanna make sure that maybe we’re thinking a little bit broader beyond PCI. So if we go to the next slide yep.
So things that we have come across in our work with clients who have gone through some sort of a breach, and these are things we’ve heard of. Right? I said it before. We were validated as PCI DSS compliance, so we’re protected from breach litigation.
That’s just not necessarily true.
We were validated as PCI DSS compliant, and so the PFI report should show that.
We have never seen a PCI related breach where the PFI report showed that every single control in the domain of PCI DSS was in place and operating functionally at the time of the breach.
And that makes sense. Because if all the controls were working and operational, you wouldn’t have a breach of PCI data, but it happens. Right? And maintaining and keeping PCI up and running is a is a challenge. And so there are certainly opportunities for controls to not be in effect at some point in time in between your validations.
And then the other statement here proving proving that we are PCI DSS compliant is all we have to do. And, again, for protection of cardholder data only, maybe.
But many of the cases that we get brought into are organizations that lose information that is other than cardholder data. Right? So your cardholder data is certainly one piece of information that you need to protect. But anybody who has cardholder data also likely has other PII related to those customers or resources related to the transaction that they have cardholder data for. So your cardholder data may be very well protected, but there may be other data that is associated with the very well protected cardholder data that is not as well protected.
And so you need to come up with a reasonable security around all of your information data not just the PCI data.
With breaches, what we have found from working with many organizations, we’re going through this process, whether it’s on the back end and we’re talking about the litigation at kind of the end of the process after the breach has been identified and quantified. And we could be at the very beginning where people are getting notifications and trying to figure out, is there an issue with their sensitive information? And to this point, you know, things usually start small. Right? And they usually start in areas of the organization that are not necessarily as obvious. So you have small starting, things, phishing campaigns, things like that that give somebody a foot into the environment.
And oftentimes, people may be spending a long time from a malicious actor’s point of view taking time in the environment just to learn their way around, figuring out what they can do without really setting off alarms.
And it often takes a long time for an organization to realize that they’ve actually had a compromise in their environment, quite often more than two hundred days, to recognize that something was going on in their environment.
There’s also this concept of of less secure environments. Right? So we all potentially know from a PCI point of view the concepts of segmentation and making sure that you identify and protect the card data environment (CDE) and the surrounding, assets that support the CDE.
And this is why many times with PCI based organizations, they see that the breaches start somewhere else. They start in an area of the organization that maybe they haven’t focused as much on from a security point of view, and that’s where somebody gets in. And then they do the reconnaissance and figure out ways to escalate privileges and move laterally within the environment to get into a more, sensitive area.
Certainly something that we heard about with Target. Right?
And and it’s not uncommon in many of the breaches that we participate in investigations for.
And then we do still have the evolving, capabilities of the malicious actors and, and the technologies that they’re taking advantage of. Right? And point of sale POS fraud has made its changes, and is transitioning more towards memory scraping, malware, and eCommerce fraud. I mean, eCommerce fraud is something that, you know, will continue to grow, and and we’ve we’re starting to see PCI evolving to try and recognize that and make greater protections in that arena, where, you know, certainly, HALOCK from a QSA point of view for years has been telling our clients that are validating with an eCommerce environment that has a lesser, stringent set of requirements like an SAQ A, or an AEP, and and recommending that our clients still do penetration testing and vulnerability scanning of their, you know, environment that maybe is just handing off to a third party.
Right? If you have a redirect or, an embedded iframe to a third party, PCI in the version three of PCI basically let you off the hook in your environment and and took away a lot of the requirements that were related to protecting that environment because all of the capturing of the cardholder data was happening somewhere else. But that leaves an opening for man in the middle (MiTM) style attacks, and and so eCommerce fraud in that perspective is something that we’ve seen continuing to grow, and we see the the new version of PCI becoming a little bit more diligent in in trying to protect some of that information.
But what we see in our investigations from a litigation point of view and is that all lawyers are basically looking for lawyers and judges, right, are looking for basically the same type of information, and they think very differently about information security than your typical information security practitioner does. Right? The lawyers and the judges don’t really care about the technologies.
They ultimately are coming down to a question of, did you have an ability to foresee what was gonna happen, and could you have prevented it? And so they look at the PFI reports and the DSS ROCs and the service provider documentation, And they’ve seen enough of this documentation that they can certainly tell the difference between an organization who is doing due diligence in their environment and protecting things and has a real interest in security versus somebody who has found a QSA who’s kind of going through the motions and giving them a validation that may or may not be really representative of the security of the environment.
The lawyers are looking for risk assessments, and risk assessments are not something that are unique to as requirements to PCI. Right? All legislation, all regulatory mandates now include some aspect of requiring risk assessments and and applying reasonable security.
And so there’s been some evolutions. And what does that mean? In years past, that’s been pretty openly interpreted. But there have been some developments now that that HALOCK has participated in that have helped to set a baseline for what a risk assessment could be looking for and how it should be going about determining what’s reasonable security.
And this is kind of where we’re taking this concept of the targeted risk analysis and making sure that we wanna look beyond just the narrow focus maybe of what, PCI is looking for something a little bit broader that incorporates any of the information that you have in your environment and is taking that into consideration when trying to weigh that likelihood versus the impacts and how you may reduce the risks related to any of these items that we’re trying to analyze with the targeted risk analysis.
When I mentioned, before that the lawyers, you know, have seen enough of this, the judges have seen enough of this to understand where real due diligence is being done.
Your PFI reports that happen at the time of a breach are often going to highlight where you’ve fallen down. Right? And if you have we all know that from a PCI point of view, validation occurs once a year. Right?
So there’s only one point in time during the year that somebody’s actually coming and looking at all the controls and the status of your environment. And with few exceptions, you know, ongoing vulnerability scan evidence that you’re providing from things you’ve done incrementally between validations, there’s not a lot of evidence that you’re asked to provide during a during a validation that says, I’ve been doing this over time. You’re mostly providing evidence of I have things in place at the time somebody’s coming to ask. And the PFIs often highlight where some of those controls fall down in between validations.
And so the PFI may point to a number of things that were not in place at the time of the breach, but you may have a validation that shows that at the time of the validation, it was shown to be evident. And all this is doing is highlighting the fact that you have gaps in the consistency of the application of your controls.
The PCI compliance, you know, requires this ongoing maintenance of all the controls.
And so having a process that identifies that your controls are continuously effective is something that can greatly increase your ability to reduce liability at the time that an investigation may occur.
And so we can go to the yep. Next slide. So what we’re what we’re really talking about here, in relation to the targeted risk analysis is a concept of reasonable security.
When they were asking us to think about and consider how risk may be impacted, how the impact to you as an organization, may drive what you do for your remediation or for your control, PCI, again, is focused very hard very significantly and very directly on the cardholder data. What we wanna do is make sure that we’re using this concept of, reasonableness to can we go back a slide, please?
Reasonableness to identify what within our organization, we should be considering when we’re defining these controls. And we mentioned before that that concept of reasonable was something that didn’t really have a good definition before. And within the last couple of years, an organization called the Sedona Conference, which is a kind of a think tank entity that provides guidance andthought leadership for the legal community, has put together a documentation documented report called the Commentary on a Reasonable Security Test, which basically formalizes a legal definition of how you determine what a reasonable control is.
And simplified, it’s that the burden of the control should not be greater than the benefit it provides. And so when we start doing targeted risk analysis, we need to be thinking about what are we trying to protect, in this instance, the cardholder data, and what things are we doing, offering to do in order to protect that. And and that the things we’re offering to do can’t outweigh the value of protecting that data to start. And so lawyers and judges look at this as kind of a balancing between the right side is the obligations, is you what our duty is to protect information.
And that’s what PCI is calling out. Right? Protect that cardholder data. Protect going beyond that, what lawyers and and judges and litigators are looking at is what other public obligations did you have, protecting the safety of people, protecting the PII that people have that you may have in going beyond the the card deal cardholder data that you have.
HIPAA talks about protected health information. Right? These are all aspects of your obligations, and you need to be you need to be able to come up with a way to balance protecting of that information with the left side of this chart, which is showing mission and objectives. Mission and objectives is your reasons for being in business.
What do you provide to your customers, and how could that be impacted by putting in stringent controls?
What are your objectives as an organization? Maybe the way to protect information, that is being presented with a PCI control is so overly burdensome from a cost point of view that you’re not able to function and achieve your business goals. And so if you can use your risk analysis to document that, to illustrate why this approach was not reasonable for us as an organization, so we’re putting together a customized approach that presents a different way. Here’s a different way we’re going about trying to achieve that control objective that does meet our business objectives and meets our public duty obligations.
So that’s the concept that we’re looking at, here in this this slide, this balancing aspect. And that’s if you find yourself in front of a judge or in front of a lawyer, justifying your position at the time of a breach, that’s what you’re gonna wanna be able to demonstrate is that you were you were aware of what risks there were to to different parties, to yourselves, and to to the people you’re protecting, but you took into it that into account when deriving the controls that you put in place.
So when we look at the what this makes us think about moving forward and how PCI DSS version four can benefit from this is the risk analysis that that Viv has highlighted. We’re all these different places that are talking about targeted risk analysis. We don’t want to just focus our targeted risk analysis on protection of that cardholder data, But we want to expand how we’re thinking about that targeted risk analysis to include this duty of care concept, this ability to strike that balance between all of the protections that we need to offer ourselves and our interested parties as well as the impacts that may cause to us in getting to that level of protection.
And so we want to use the the look at that those targeted risk analysis examples from that perspective and figure out how can we take all of that information into account when we’re when we’re thinking about building out that targeted risk analysis, whether it’s for the periodic controls or whether it’s for a customized approach. So we wanna use those controls and that concept of duty of care or mission objectives and obligations to shape how we document the impacts and the likelihoods in the targeted risk analysis.
So we’re gonna jump Yeah.
Go ahead. So as as you were explaining, Todd, we have two targeted risk analysis. One for periodic cadence requirements, one from customized approach requirements.
So Todd and I thought it would be helpful to talk through modeling of a Duty of Care Risk Analysis Targeted Risk Analysis for PCI for both of those. So we’ll talk through that with with you all.
So let’s start with the cadence one, Todd. We had talked about, you know, the fact that in the in the cadence targeted risk analysis requirement, that third bullet that we highlighted basically identify the factors that contribute to the likelihood or impact of the threat being realized.
That is really where an organization would be looking at the impact of their mission, their objectives, and their obligations to protect that cardholder data. So that is really where we’re seeing that organizations would be calling out those different impacts to consider, is this safeguard appropriate?
Is the frequency of this safeguard appropriate?
If I don’t do it this frequently, am I increasing the risk to my organization?
And How can Yeah.
Go ahead.
I was gonna say and on the flip side, if I do it daily or weekly, is it creating a burden to me as an organization for meeting my objectives or meeting our mission? Or is implementing a control or operating a control so frequently that it keeps me from doing my business, something that we need to also present and consider. So you need to figure out where that balance is between ability to operate your organization’s operations balanced with the protection of information they’re looking for in these periodic cadences.
Yeah. And going back to something that you had mentioned when you were talking about the breach and litigation experience, I mean, I think that’s something that we’ve been hearing for years and years and have also seen for years and years. The ongoing maintenance is one of the more difficult things that organizations have to do when it comes to compliance, especially when PCI is so very granular about making sure that those things are done on that cadence.
A lot of organizations, I think, fall down in the ongoing maintenance activities because the controls they’ve implemented, the processes they’ve implemented are too difficult.
And and we’ve seen it time and time again where if somebody creates a process that is too hard for an employee to do or it takes them much, much longer than it previously did or it’s just what they think is burdensome, that process is gonna break. People are gonna stop doing it. People are gonna find ways around it. And so we wanna make sure that that’s something that people are considering when they’re thinking about these periodic cadence requirements is there there definitely is a right balance for every organization based on their business, their culture, the actual use cases in their environment.
But as well as thinking about protecting that data, you also have to think about your business objectives and missions. Because if we’re telling employees, you have to do all of these things before you can even log into your machine, and that causes them to lose, like, thirty minutes a day, and now they can’t achieve other objectives, then it’s it’s not gonna work.
And this this is something that, you know, certainly, we’ve seen organizations struggle with in the past with some of the more structured requirements. So the benefit of may moving to this targeted risk analysis is that allows the organization to define and customize what’s appropriate for them. And I think about the POI device inspections. If you think about an organization who maybe has three different flavors of POI devices in their environment. They may have one that’s very public facing that is exposed to external entities and external resources all the time. And then they may have other POI devices maybe that support the same sales process, but they’re in a call center and they’re in a targeted secured location.
And then you may have a third device that maybe your mobile devices that are taken out to the field, but it only happens once a year or twice a year. And having one requirement that says I’m going to inspect all of my devices on a monthly basis may be burdensome for those call center that you know, you may have a lot of devices in that call center. Is it reasonable or appropriate that you’re inspecting those devices every month? Maybe you have the opportunity now to make that case to say, well, I’m gonna do my call center related devices on a quarterly basis, and I’m gonna do my retail public facing retail devices on a weekly basis or on a monthly basis, and I’m gonna do my mobile devices on an ad hoc basis whenever they’re used.
And, otherwise, they’re sitting in a locked box. And this will now give you that ability to justify that balance between what type of exposure a device has and how much effort it takes to actually conduct the in investigations balanced with the risk it presents to you as an organization. And so you’re looking at that combination of things to present that risk aspect. And when we look back to that to that balance, that scale showing the balance between mission, objectives, and obligations, that’s what you you wanna be considering in your head is, how do we strike a balance between those?
And we now have the ability to potentially come up with a varying cadence within the environment depending on your specific situation.
Yeah. And one that may change as your environment changes, or you may determine a cadence, try it out, and realize that that’s not gonna work well for you. So, I mean, this is where this this ongoing concept of having these risk discussions and risk analysis always will come up. Don’t put it on paper once and never look at it again. I like the fact that they specifically called out an annual review to determine if a new risk analysis is necessary. I think that’s always a good idea to look at, but, really, organizations should be looking at these anytime there’s a potential change as well.
Okay. So let’s talk a little bit about the customized approach considerations.
As far as the customized approach goes, they in their template, they do a very nice job of highlighting your obligations. They make you think about how many credit card numbers you’re potentially exposing in that particular control, And then they ask you to specifically think about how your control would potentially reduce the risk of those individual cards that are being compromised or would increase your notification process.
And so they’ve they’ve basically said, this is the obligation we want you to meet. But where in here do we think about our our organization and our business needs and our objectives as well?
Right? The entity question. You know? So the entity still needs to be considering what’s important to them. What’s the entity’s mission? What’s the entity’s objectives? And so even though they don’t specifically give you an a way to do that in their targeted risk analysis template for the customized approach, in this section where we talk about the impacts and the liability and or I’m sorry, impacts and likelihood, we need to consider the impact to ourselves as well.
Right? We need to consider if that control objective is reasonable to maintain on an ongoing basis, if it’s sustainable, if you can have good metrics to know that it’s effective.
Right? The intent of the customized approach is a little different too because it’s it’s intended for risk mature organizations. It’s not intended for somebody to use this as a replacement for compensating control.
If you have a business or a technical constraint still preventing you from implementing the control as stated, you still use a compensating control. It’s not the customized approach. The customized approach is if you’re doing something more than what the DSS is saying, but you can also meet that control objective.
So in that sense, the risk-mature organizations as they state should make sure that whatever risk assessment methodology they are using, not only is looking at the obligations that the organization has to protect, but also is considering the impact to their business mission and business objectives and as well as the pan data that’s being exposed.
So I think with with both of these examples, you know, there’s there’s an extent to which things need to be documented to meet PCI DSS 4.0. Right? And and there are specific requirements as to what the DSS what the council is looking for to be captured in this documentation.
But I think what we’re saying is that you need to have expanded thinking outside of what you’re capturing in the ROC and in this documentation that will help you to justify both to your QSA, who’s coming along and reviewing this information, but to any litigator or regulatory entity who may be looking at information, but also to your own internal business.
Because, again, one of the things that either of these approaches are doing are allowing you to tailor an approach for security and controls that’s unique to your organization and should be balanced with what your organizational objectives are. And so the documentation that’s required here is really targeted at how are you proving it’s gonna protect the cardholder data. But what we’re suggesting is that as part of coming up with that with that documentation, there are other aspects for you to consider and potentially document outside of your rock, outside of your controls matrix in a risk register that is now no longer required but is still a best practice recommendation.
Right? Putting this information into a risk register, documenting the conversations and the thoughts you had holistically about your new targeted risk analysis, and then you cherry pick the information from that risk assessment that you’re having to put into the rock documentation itself. But making sure that you go through that broader exercises of exercise of considering your mission and objectives as well as other obligations you have. Again, PCI is very narrowly focused on cardholder data.
There is other, you know, many instances. What we’re talking about here where there is cardholder data, there is associated other data with that that, information in your systems. And so as we’re talking about how we adjust or protect certain pieces of data in the environment, we wanna be looking at the surrounding data, the associated data that’s with that and figuring out from a liability point of view, from a risk point of view, it should we be considering more than just what PCI is looking to protect? Because certainly, you can find a situation where even if you’re found to have been appropriate in the controls you applied for protecting cardholder data, a state’s attorney may not care about your protection of PCI cardholder data only because you may have also exposed a bunch of data about constituents in their states.
And you have exposed personal information about those resources. And so while you may be found to not be liable, related to the protection of the cardholder data, you may be found that you did not sufficiently protect the personal information of those associated, customers. And so that’s something that, you know, again, for organizations that have built their security programs around PCI compliance, Often, this is a an aspect that they run into is that they’ve had a narrow focus on where they’ve targeted their security program and having it just focused on what PCI is specifically designed to to care about.
And as organizations that have taken that approach start to mature and start looking at how do I build security beyond PCI, this is one of the first areas that comes up and and making sure that you are protecting all aspects of your sensitive information, which may also entail IP. Right? It’s not just PII that we’re talking about. It’s not just cardholder data that we’re talking about. We could talk could be talking about information that’s unique and sensitive to you as an organization. And each of those types of information should be getting the same level of diligence and consideration in in the protections.
But PCI is certainly providing a mechanism to think about things from a risk point of view. And what we’re suggesting is make sure you’re taking into account your own requirements and obligations and your responsibilities to others beyond, the counsel and and credit card data in evaluating risk analysis of your controls.
Yeah. We’re we’re seeing this more and more in breach litigation cases. More and more states are understanding what reasonable security means as far as The Sedona’s Conference reasonable security test definition goes. We’re seeing this end up in injunctive reliefs from breached organization settlement cases. So it is getting more and more widespread. And so we do want organizations to understand if they’re dealing with only a PCI DSS compliance obligation, compliance itself is not enough. You really need to be looking at a risk from a holistic point of view.
Address your compliance needs absolutely, but also make sure you’re looking at your mission objectives, as an organization to make sure that what you’re implementing for your obligations is actually gonna work long term. And continue to have those conversations and use that same risk analysis method to analyze any potential safeguards to reduce risks, make sure that those safeguards are not too burdensome and reducing risks appropriately to ensure that they’re sufficient to protect you.
So we we definitely are glad to see that PCI DSS is emphasizing risk more and more.
That’s, moving the right direction. We are glad to see that they’re including control objectives to help people understand exactly what the intent of controls are, but we want to make sure that organizations know that they to properly protect themselves, reasonable security through risk assessment methodologies that are looking at the impacts to their organization as well as their obligations is really what’s necessary to protect you.
So with all of that information, what questions do you all have?
And I will say that, HALOCK, we specialize in PCI, but we also specialize in risk and Duty of Care Risk Analysis (D0CRA). So these are things we are consistently working on working with clients to help implement. So there if there are if over the next year as you’re working through targeted risk analysis, you need help, and you don’t know how to do this to protect yourself, please don’t hesitate to reach out because Todd and I and the rest of the team are always happy to help.
But if anybody does have questions, we are happy to address them today as well.
I’ve enabled all of your mics. You just have to unmute yourself if you actually have a question. Otherwise, you can go to the Q&A, tab at the top, and you can write your question down there, which we can address later.
Thank you, Rachel. Did you have something to add? Sorry.
Nope. Yeah. I was just preparing to answer a question if necessary.
Alright. Well, if anybody has questions, please don’t hesitate to reach out. Todd and I, our information will be in the webinar deck as well. So, we appreciate you taking the time today. We know targeted risk analysis will be a topic for much discussion over the next year, so we do anticipate lots of conversations and lots of materials being released around that as well.
We do appreciate your time today, and we hope that you join us next week for our last PCI DSS webinar series where we compare the different SAQ types from 3.2.1 to 4.0.
Alright. Thank you, everybody.
