Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: A PCI 4.0 Interview (Part 1)
Quick Take
On this special Two-Part episode of Compliance Unfiltered, the CU guys are proud to welcome Steve Levinson, VP of Risk & Security, and Sherri Collis, Director of PCI Services of Online Business Systems, to chat about PCI 4.0.
Online has been a friend of TCT and formidable name in the PCI space for many years. In Part 1 of 2, Steve and Sherri share their insights on some of the key structural changes to PCI 4.0, a targeted risk analysis overview, and will cover the new requirements for 4.0.
Curious about the implications of those changes? Wondering what timelines you can expect? Steve and Sherri have you covered their as well.
And don’t forget to check back next week for part 2 of our PCI 4.0 conversation with Sherri Collis and Steve Levinson of Online Business Systems!
Remember to follow us on LinkedIn and Twitter!
Read Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s so hard to keep organized, and it requires a ton of expertise in order to survive the entire process. Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less. Now, here’s your host, Todd Coshow, with Adam Goslin.
Well, welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside a man who will shine your compliance silver. Mr. Adam Goslin, how the heck are you, sir? Silver shining, I got a new talent. The title talent, however you want to say it. We’re excited to have you along. We’ll be performing this podcast in a two-part series, so feel free to subscribe to the pod on your favorite podcast entity of choice, and you will have the easy ability to get part two next week.
Well, Compliance Unfiltered has the distinct pleasure of welcoming some long-time friends of TCT to the podcast from Online Business Systems to talk to us about PCI DSS version for Mr. Steve Levinson and Mr. Sherri Collis of Online. Steve is the VP of Risk and Security, and Sherri is the Director of PCI Services. Thank you both for joining us today. Good to be here. Thank you for having us. Absolutely.
So, tell us about some of the key structural changes that we can look at when talking about FORA. Certainly. I can lead off here. First and foremost, we’ve been in the PCI arena since the beginning, and obviously it’s gone through many iterations and gyrations over the years. And I would say by far the largest amount of changes are this iteration that we are going through when we go from 3.2.1 to 4.0. So some of the key changes here would be first the numbering scheme. So a lot of us QSAs or people who are just dealing with PCI on the other side of the permanent brain damage in the sense that we all pretty much have had the PCI DSS memorized. And all of a sudden now with this new version, the required numbers are going to be a little bit different. It’ll still be the digital dozen. So at least we can take solace in the fact that it hasn’t changed that dramatically. But a lot of the sub elements are now no longer what we’ve come to know and love over the years. So that’ll be one thing to get used to. And I don’t know if you guys have any thoughts or comments on that where I talk about the other larger change. Oh no just other than I’m absolutely with you on the pain level there. You know it takes so long to commit those things to memory and it’s like I’ll be sitting on a call and you know somebody’s like oh yeah so uh you know we want to talk about the you know internal scanning and I’m like oh it’s 11 2 you know etc and we’re going to be able to throw that out the window for probably about nine months thank you. Yeah for a little while. Yeah. And then the other one, so in the past we were able to kind of sometimes when need be color outside of the lines through the art of compensating controls. Well what’s happened now and I’d like to commonly call it is where we’re going there are no roads is the fact that now there will be this thing optional of course called the customized approach. So in a way though I think it’s a really great thing because let’s face it technology evolves faster than policies procedures and even standards like the PCI DSS and you know let’s face it the word cloud was never in the DSS until 4.0 even though it’s been out there forever.
So what’s good about the customized approach is that it allows for, for entities that need to go through it to be a bit more flexible while trying to you know meet the spirits of PCI and doing the right things but maybe doing it in ways that haven’t been done before.
So, but it will you know as with anything it’ll take a lot of legwork, it’s not necessarily recommended for you know smaller companies or companies that aren’t as far along in their security journey because there’s a lot of legwork involved and we’ll talk through that a bit more in the future as well. Yeah I can imagine that’ll be more geared to the you know the larger scale organizations type of thing. I was of a similar notion which was the smaller organizations probably aren’t going to want to head that route.
So, very, very cool. So what are some of the broad changes though? Boy, I tell ya, there’s a terminology change that really does make a difference. So one of the things that the council never did before was really define what they believe is significant change, but now they have. And for their significant change, they’re really defining it as new hardware, software, network equipment added to the CDE or replacement of major upgrades of hardware and software in the CDE, lower storage of account data changes, boundary of the CDE or scope of the assessment. That also is considered a significant change and underlying supporting infrastructure of the CDE. They’re considering that a significant change. and any changes to third-party vendors and service providers that support your CDE. Those are all considered significant changes. And as we go through some of the requirements in our next segment, you will see that they are requiring you to do specific activities based on this definition of significant change. So that’s going to be quite a large deal. I’m glad, I’m actually glad to see that they’ve done that, Sherri, because it was always very, I don’t know, you know, amorphous, right? Significant change. Yeah, everybody gets to say, well, let’s roll the dice. Is this going to be a significant change or not? The way I’ve always kind of framed that up, though, in layman’s terms, and it kind of applies across the board is a lot of times, especially talking with clients, I’d say, okay, well, tell you what, what’s the worst that could happen if this didn’t go the way you thought it was? And if they get the scratch in their heads and go, oh, then you know it’s significant. Yeah, exactly. Yeah. And another thing that they have really defined is our time period changes. So it used to be you could do a quarterly scan at any point in time between in a quarter. So you could actually do a scan in month one of quarter one, and do a next vulnerability scan in the third month of the second quarter, which actually gives you six months between. So I think some people were probably gaming the system. So the council has yes, so the council has now said quarterly is every 90 to 92 days or the same day every third month, biannually every 180 to 184 days or the same day every six months. So those kinds of changes are really going to affect a lot of those things that you’re going to see. you have to do regular maintenance on such as vulnerability scans because you’re now going to have to tie it to this exact time period. It holds people that much more accountable.
Well, I got a question for you guys. So I get the spirit of what they’re trying to do because yeah, I mean, I’d seen the same thing, right? I have a quarterly vulnerability scan where they basically fire one off at the tail end of their compliance Q1 and whip another one in at the beginning of compliance Q2. And in fact, they’re basically doing scanning twice a year on the book. So I get where they’re going with this, but like what happened, do you guys, they articulated what happens with, what happens if my scan blows up or I wasn’t able to run a scan or whatnot, AKA, I didn’t run it between 90 and 92 days, you know each quarter like do we turn into pumpkins or We go to peace guy jail or what? Here’s the here’s the thoughts it’s sharing. Yeah, we’ve had these conversations for many moons and, and part of it. I think depends on a The approach and you know, are you taking a hardliner? It has to be done then which I don’t think reflects reality All right, taking your business pragmatic approach. But so if you miss it by your day or two is it the end of the world no, let’s just say because we’ve all worked with clients in the past that had stuff happen. Maybe it blew up Maybe you know the dog ate their homework, maybe somebody left the company and they can’t show that they had a scan from nine months ago, right? Right and You know, I’ve seen some QSA companies say hey Sorry, you can’t be compliant for another three months because you missed your scan nine months ago. Well, that’s silly, you can’t change the past. So what’ll happen then and again, I think this is back to taking the you know risk-based pragmatic approach is okay. Well first and foremost do we have a clean scan right now? Obviously, you need to have one right now secondly, okay why did you miss the scan nine months ago? Let’s figure out the root cause so that we can refine any of those underlying Processes so the likelihood of it happening again is minimal Yeah, and so I think you know, really that’s what we’re looking for spiritually. I’m sorry I don’t know if you’ve had some other things to add to that well, the one thing I will add is that they have this new thing called areas of improvement and they have realized that you can’t do a compensating control for something that didn’t happen in the past but we’re going to have to be writing it onto a sheet called areas of improvement and That has to be signed off by your senior management in your company, so if you are ending up not doing some of your compliance activities in the time frame that they’re supposed to,to where we can’t write up a compensating control. We do have to report on it, get the report and have it signed by executive management. So you could look at that as a couple ways. You could look at it as, oh, we really need some extra people. So this will help us to point out to our senior management that we don’t have enough people to do this, or we need a tool to do this, or it could also look like you’ve got plenty of people and you’ve got plenty of tools, so you’re not doing your job. So there’s two different ways you can look at that. So, you know, that’s going to be one of the fallouts from that. Well, you know, it’s a much better fallout than in place with remediation, which, thank God.
Oh, yeah. I agree. Hey, Sherri, this is one you can go throw into, like, the PCI suggestion box. I just, I don’t know. This is just the way my brain works. I went and I looked at their little grid of, you know, what does it mean monthly in their every 30 to 31 days?
I’m sitting there going, well, what happens in February? So, eh, maybe I’ll throw that in the suggestion box. Anyway. That’s awesome. Yeah, you got a little short in month in February. Yeah. All right. What else you got, Sherry? Well, and periodically, so one of the things that they’ve done now is they have defined some of the things that have to be done for regular maintenance throughout the year.
But some, they just say that you have to do them periodically. And what their expectation is, is that you will look at those specific requirements and say, ah, they didn’t define a periodicity. So we have to do what we call a targeted risk assessment to determine how frequently that particular activity should occur within the organization. So there are a few of those that you will have to actually learn to do targeted risk assessments and do that. They’ve also defined that weekly is once every seven days. Daily is every day. Every day of the 365 days a year, and then promptly is as soon as possible. But I would say the ones that are really, oh, and the ones that are really going to be, I think a problem are going to be the quarterly scans and potentially the firewall rule set reviews that you have to do every six months or every 180 to 184 days. I am sure the industry is going to be in for a lot of fun with all the time periods. Oh, absolutely.
Okay. And so passing off of the time period changes, what about targeted risk analysis? Ah, yes, that one is a very interesting one.
Steve, do you want to talk about the targeted risk and I can address a few of the ones that are required? Sure. I mean, so target risk, you know, I guess if I frame it up at a high level, is you have to kind of explain your methodology. A lot of times we’ll frame this up with our clients this way. We’ll say, just imagine if we had to get in front of a jury and when I say we, it’s a loss, plus our clients, because we’re in this together really. We had to get in front of a jury and we had to explain our logic as to why the blah, blah, blah. The blah, blah, blah could be why the periodicity between this and that to inspect something or how we took a risk-based approach to something else. We better base. our decision on some sound logic. We can’t just shoot from the hip. Now, mind you, this is stuff we’ve been saying for quite some time now, long before 4.0, probably for the better part, 15 years. But this kind of just takes it to the next level where we really need to prove our work and not just say it.
Sherri, you might want to even give a couple more examples on that. Yeah, so there are customized approaches. If you do one of those, you’re going to have to do a targeted risk assessment for each one of those. If you have systems that are not considered in scope of your assessment, you have to review system components that are not, or excuse me, that are, I skipped down to another one that are not part of your CDE, but you do need to be looking at them, the logs from time to time. Another one is you have to do review of systems that are not at risk for malware. So if you have some Linux and Mac systems that you had previously considered not at risk and don’t have anti-malware on them, you’re now going to have to do a targeted risk assessment to determine how frequently you need to reevaluate whether you need to have antivirus on systems where you don’t. You’ll also have to look for application and system accounts and the related privileges that you give. So if you have those accounts, you’re going to have to make sure that they have the least privilege as they need, and you’re going to have to look and determine how frequently you have to change the passwords for those particular accounts. And a big thing of interest there. So what sorts of privileges the various accounts have. And again, this has been a best practice forever, but if you think about a lot of developers, a lot of companies got lazy, and when they… create system accounts, for example, they’ll just give them administrative access. They don’t have to really work on having to, it should be in, basically they’ll give all sorts of entities, you know, that, you know, that system account ID, which could in turn, you know, open up a can of worms. So, so one of the changes with 4.0, beyond just reviewing these accounts periodically, is to ensure that the amount of rights that they are granted align with what that entity ought to be doing. So, for a lot of these entities, a lot of these companies as well, rather than having 20 different things, use that same system account that has quasi administrative privileges, you may need to create 20 different system accounts that each one could do what it’s supposed to do from, you know, from an application level ID. You know, in the industry, there’s been a lot of a lot of scuttlebutt about, you know, about, you know, the, the efficacy of, you know, mandatory thou shalt change thine passwords every so many days because, you know, it actually diminishes the security of the security because human beings don’t typically make randos,or scrambled passwords and whatnot. So, yeah, I don’t know. We’ll see. I’m sharing additional things that fall into that kind of targeted risk analysis. Sure. The frequency of your inspections of POI devices. So if you have point of sale, point of interaction devices in your environment, you’ll have to do a targeted risk assessment to determine how frequently you need to do those device inspections. Another one is, and this one’s a big one, you’re now going to have to address all risks, not just higher critical for your internal vulnerability scans. So you have to do a targeted risk assessment, not for the ones that are higher critical, but for those that are low or medium, you’ve got to determine how frequently you will do that. And your assessor will be looking at how frequently, you know, are you, did you define it and are you following it? Yeah, that’s good because I’ve seen a lot of, we’ll call it a lot of variability in terms of how that was approached over different engagements.
Right. And really, in the past, you haven’t really had to address the low or the medium for internal vulnerability scans. So that will be a big deal. Another one of the targeted risk assessments is for reviewing any unauthorized modifications of your HTTP header or payment pages. So if it’s not done at least once every seven days, you’re going to have to determine the frequency that you believe that it needs to be done. And then one other one is the frequency of the periodic training for instant response personnel. How frequently do they really? need to have that training. Wow, that’s quite, that’s quite the list. Thank you for, you know, kind of, thank you for kind of spelling some of that out. I was thinking as we’re walking in, they’re like, you got to do this, you know, targeted risk analysis for periodic requirements.
Like, okay, well, what the hell are all the periodic requirements? Now, kind of changing gears just a little bit, can you give us kind of an overview of the new requirements under version four? Well, and I tell you, the one’s most notable. There are, there are a lot of changes, but some of the things that we believe will really trip up an organization, the first and foremost is that they’re going to have to be for their internal scans, doing authenticated scans versus unauthenticated scans. And that makes a huge. huge difference whether you’re doing authenticated versus unauthenticated. It can turn your vulnerabilities that it finds from 7 to 395 in the same exact environment and turn them from a level 3 criticality to a 5. It’s huge. For anyone who has never done this before, the first time you run an authenticated scan, you are going to see a lot of things you cannot unsee that you have never seen before. Once you’ve done the first go around and it’s not as painful afterwards, with that first go around, this is why we would advise very strongly, even though it’s not a requirement today, we advise very strongly to go ahead and do it now to see what it looks like with it. The numbers that I quoted are actually based on some scans that were done against the same exact environment using unauthenticated and then using authenticated, so the numbers I quoted are true. The good news on that one is that it’s not due until March of 2025, but there’s another one that’s due immediately upon doing V40 and that’s to have, and I’m getting mixed notices on this one, roles and responsibilities for everyone who has anything to do with PCI, so every requirement that you have that you’re covering in your organization, you’re going to have to have a role and responsibility for every one of those people who might touch that and that is due immediately upon doing V40 and I’ve had a lot of clients say, oh wait a minute, that’s going to take several years and you’re not going to have it. That will be interesting to see how they handle that.
Let me ask you a question, Sherri, on that one. The high level roles and responsibilities, that was always, you know, know for like role-based access control is always a thing for PCI what’s the what’s the major difference between kind of the 3.2.1 are seven requirements versus what they’re rolling out under 4.0? Those are big deals on the requirement seven so first off you’re gonna have to handle your application and system accounts as you would your other accounts like your admin accounts or user accounts and for companies that are had have to be compliant with SOX, Sarbanes Oxley they are probably already doing quarterly account reviews but for companies that aren’t, you’re gonna have to review those accounts every six months and that is really new for people they’re, they’re not going to be doing that yet and you have to look at what permissions those accounts have and whether they’re appropriate and get management sign off on them. Gotcha, yeah and for anyone who’s got some you know let’s just call it a technical legacy, there’s going to be a lot of digging around. It’s one thing if you’ve just stood up your infrastructure in the last few years, but if you had some infrastructure where Lord knows where it came from. There’s going to be a lot of legwork associated with trying to understand, you know, what’s the what and what sorts of account privileges. These things have, right. And another big change is if you if you don’t have a web application firewall in front of your web based applications. They used to say you could do a web application firewall or you could do a code review. They’re taking out the or, you’re now going to have to have a web application firewall as of 2025 so if you need to put some budget in place and get people who understand the technology, somebody who can implement it. And you have to fine tune it to make sure you’re not getting too much from it. You’re not getting too little from it. That’s going to take some time. And another thing that might hit your budget. If you don’t have someone that helps you do daily seven days a week. Log reviews, you’re going to have to put something in place for that. So I think many companies nowadays have some but there are still companies we run across that don’t have them. So they’re going to have to do another investment in that.
Gotcha. And another thing that’s a really a big deal. And I’m really glad to see this one. They’re finally calling out that companies have to look at equipment that’s end of life. So before you have, before you didn’t really have to look at that. But now they’re saying if you have equipment that has hit end of life, you’ve got to have a program in place that says what you’re going to do. When you want to get rid of those technologies from your environment. So that also has to be signed by senior management. So that’s going to add to that because that’s always, you know, it’s a hard and strict requirement. It’s always kind of been a soft requirement, and what we’ve always said here again taking the risk based approach is a lot of times when something’s end of life. It means it’s just no longer supported. It doesn’t mean that it’s not secure. But it also means that, you know, you are hanging by a thread because the minute something comes out where this particular end of life thing is not secure because somebody somehow figured out a way to breach it. You better figure out by now what you have to do to protect it. Now, sometimes you can build in things. We once had this client, it was a glorious thing, they had these old systems that ran on, I think they were DOS based systems. That’s how old they were. And we just came up with a whole bunch of compensating controls because sometimes you can harden something where what might impact you because something was end of life is no longer an issue because those attack factors are shut off because you’ve hardened something to within an inch of its life. But all that said, you know, one will have to run a pre detailed risk analysis, kind of what we were alluding to before so that you can at least demonstrate A, today this thing is secure and B, we have our ear to the track in the minute we hear about anything in the wild that could impact the security of this thing. We got a plan. Otherwise, you know, you’re at risk. Gotcha.
Hey, Sherri, one question for you, and that is just at a really, at a really high level. Obviously, we’re going from 3.2.1 to 4.0. You know, what are the, you know, what does the landscape look like in terms of new requirements for merchants, merchants or service provider? That’s a great question. So actually, there are 61 new requirements. The good news of that is 12 of those sub requirements are same for the each of the top level 12 requirements because they include those roles and responsibilities that you now have to define. Gotcha. And I would say also that 10 of the requirements that are new only apply to service providers. Okay, so 51 of the new requirements apply to both merchants and service providers. Cool. Well, that’s actually that’s really interesting.
Now something that I know is on everybody’s mind. Maybe you could share a little bit more about the implications of the reporting changes under 4.0. a big deal. Yeah. And I don’t, Steve, I know this one is close to your heart, about areas of remediation and also areas of improvement. Would you like to discuss that one? Yeah, absolutely. And one of the things that luckily we can just sweep under the carpet because there was a point in time where if there was something that had been a gap, but then of course you cleaned it up to get to the finish line, for example, right? You missed that scan nine months ago. There had been a category called in place with remediation. Now luckily, long story short, calmer mines prevailed. I think the industry realized that this could open up a huge can of worms for lawsuits or whatever, for maybe somebody who fell out of compliance for a period of time when they’re contractually bound to be PCI So the good of this is that rather than having lots, there’s instead a supplemental report that’s just internal. You don’t have to share it with the world, you know, called areas of improvement. So that’s where, look, if there was a gap, we all want to learn from it and do those things to make sure it doesn’t happen again. You know, it’s something that we’ve been doing within our practice for quite some time. We have this thing called supplemental findings report that, you know, talks to anything that’s programmatic that can be refined. Because really, if you think about this, if you’re approaching PCI, the way I think it ought to be approached, PCI is nothing but a happy byproduct of a robust security program. So therefore, you know, it helps coming up with continuous improvement on processes and security.
Steve, one question for you, and as I’m kind of thinking near the areas of improvement, have there been, you know, kind of any directional guidance on, you know, what liberty do assessors have for accepting versus denying this approach? And what I mean is that, I mean, I can see certain organizations, you know, just willingly going, well, we didn’t do it, you know, type of thing, and then, oh, well, let’s go ahead and, you know, and go drop the area of improvement thing in and, you know, we bypass that one type of deal.
I mean, how is there a notion of how they intend to address that? Well, first, I’ll give you the spectrum of possibilities, you know, on one end of the spectrum, and hopefully not many of these entities exist anymore, you have to check the box, QSAs are like, well, good enough. Now, on the other end, you have the hardcore auditors into the spectrum where their mamas didn’t love them and sorry, not good enough. So let’s just take the whole middle ground people being reasonable and pragmatic, right? So, so again, first and foremost, it has to be compliant today, you can’t say it’s close enough, right? It has to be compliant today. I think we can all agree on that. Council certainly would agree with that too. You can’t say something’s in place if it’s not in place. You can’t fudge it across the finish line. It’s got to be in place. But I think in addition, because PCI is a snapshot in time, but I think where the standard has been evolving, and what makes complete sense is that we want to feel reasonably confident that it’s going to be in compliance tomorrow and next week and next month. So once you know, if something hasn’t been done, as well as it could be, that’s where we want to take that collaborative approach with our clients, right? We, hopefully, because we have that permanent brain damage that may have been a little tweaked because of the fact that the numbers have changed. But we know PCI hopefully better than any of our clients for most of it. We have some clients that know it pretty darn well. But on the other end, our clients are going to know their technologies, their business, they’re going to know their, you know, all that better than we ever will. They live it every day. So we look at this as being a strong collaborative exercise. We need to work together to figure out the best way for somebody to raise the bar. We’re not gonna just shoot from the hips and make recommendations. We need to make sure that any recommendations we come up with are ones that are gonna resonate, right? Sure.
So Sherri, any additional reporting changes under 4.0? Yes, actually. One of the things that they now are allowing for are, let’s say that you’re a colo and all you do is physical security for clients and you have to be PCI compliant because you’re a service provider to those who need to be compliant. They now can do what they call a partial assessment. And literally it’s okay. It’s totally fine that they have a partial assessment. The partial assessment means that most of the core requirements didn’t really apply. So they are just doing a partial assessment because they’re just doing physical security or they may just be doing development. So only the development requirements would apply. So that’s one of the things that has come up. And so when you are looking at, you’re receiving AOCs as a merchant and you’ve got an attestation where somebody said, oh, we did a partial assessment. You don’t need to be alarmed. It’s really okay. And there’s another thing that you will see and it’s called not tested, which in the past that meant you could not have a compliant ROC. Now not tested is tied in with the partial assessment. So those are things you truly have not tested because they’re really not in scope. You don’t even need to consider them. And another time you would use this is if your acquirer said, you know, there were some challenges with these particular requirements. Can you go and do an assessment specifically for these requirements? You would use not tested for everything else. And you would say it’s a partial assessment. So again, in the past, it would have been a real big deal. And now it’s really ok. I was just gonna jump in with what’s, what is the material difference then between NA and not testing? Oh, that is something that we talk about every day and it’s something that it’s, for some reason it’s really difficult. So if something’s not applicable. So let’s say that I don’t do development. Now, all the other requirements in the standard apply to me, but I don’t do development work, then that really is not applicable to you for those development requirements.
So that’s what not applicable is. Now, not tested is meaning now that you did not have to look at those controls at all because they’re truly not in scope. You’re just doing physical security. So it’s obvious your network is not in scope because you’re not giving them access to your network. It’s not part of it. So that would be not tested versus the not applicable. Sure.
Now, for the rubber meets the road portion of things here, what’s the… the latest timeline for V4? Ah, great question. So on the timeline, version 3.2.1 expires on March 31st of 2024. So if you have your assessment completed by March 31st of 2024, you can still do version 3.2.1. However, if it’s after that time, you have to do a version 4.0 assessment. So if you’re really needing extra time, you might want to look at moving your assessment up a little earlier. But however, you have to be in V4.0 after March 31st of 2024 with other requirements becoming required in 2025. And one thing to add to that, too, we have a couple of clients whose anniversary dates are, let’s just say in April or May of 2024, maybe even June. And for some of those clients who feel like they may be struggling to be ready for V4.0 by April 1st, which, oh, by the way, is not an April fool’s joke. It’s real. If they’re not going to be ready for that, we told them, hey, look, if you can start and complete your assessment by March 31st, you could still get that in under the wire to do 3.2.1. Now, obviously, mileage may vary. If you are, say, a merchant, you probably should get the blessings of your acquiring bank to make sure you could submit early. For most service providers, they can just do it as they see fit, so they could if they needed to do it earlier. So provide that option for anyone who feels like they’re going to be struggling to hit that 4.0 deadline or 3.2.1 deadline. But obviously, it doesn’t make sense if your compliance date isn’t June, or scrunched up six months ahead of time.
One of the other things I was thinking about is that we’ve all seen it, right? And the organization that is marching to this date. And of course, nothing ever goes sideways. I, you know, the, the organization that’s literally, you know, trying to pull out this, you know, last, last second hail Mary, you know, etc, with everybody’s, you know, sweating bullets to try to get to, you get to March 31st. Well, I’ll tell you what I probably wouldn’t even, I probably wouldn’t even roll the dice unless I legitimately thought I was going to have everything concluded in January. Yeah. Type of thing. Cause otherwise, man, you’re running a, you’re running a real tightrope if you don’t make it. Well, what we’ve been saying ever since college is the sooner you fall behind, the more time you have to catch up. Oh man.
Parting thoughts and shots for the folks this week. Uh, yeah, no, honestly this overview has been awesome. So I really wanted to thank Steve and Sherri for you know sharing with the listeners so much great feedback on PCI for we do really, really, really appreciate it So that concludes our part one of this series. So like Todd said earlier, you know go check out Spotify subscribe to the podcast wherever you wherever you get them from And you’ll have the easy ability to get over to part two.
And that right there That’s the good stuff Thanks again to Steve and Sherri from Online. We look forward to chatting with you again soon Thank you guys very much Thank you Well, that’s all the time we have for this episode of compliance unfiltered I’m Todd Cashel and I’m Adam Gosling. Hope we help to get you fired up to make your compliance suck less
