Listen to learn how a third-party assessment can benefit your business and what elements support successful completion of an audit.
Preparing for a third-party security assessment or compliance audit can be a daunting experience, especially if it’s your first time.
Brian Gross (VP, Product & Technology, FISERV) sits down with Host and Principal Security Analyst Jen Stone (MCIS, CISSP, CISA, QSA) to discuss how he prepared his organization to respond successfully to a PCI DSS assessment, followed by a HIPAA audit.
Listen to learn:
Resources:
Download our Guide to PCI Compliance! - https://www.securitymetrics.com/lp/pci/pci-guide
Download our Guide to HIPAA Compliance! - https://www.securitymetrics.com/lp/hipaa/hipaa-guide
[Disclaimer] Before implementing any policies or procedures you hear about on this or any other episodes, make sure to talk to your legal department, IT department, and any other department assisting with your data security and compliance efforts.
Hi. And welcome back to the SecurityMetrics podcast. I'm Jen Stone. I'm one of the principal security analysts here at SecurityMetrics.
Very excited about the topic today. A lot of people, especially their first time when they're facing an audit from a third party auditor, they just it's a hard thing. This is a stressful thing. You know, your first PCI assessment, your first HIPAA, whatever it is that that you need to get an audit done and you're bringing someone in from the outside, it's a little scary.
Because first of all, someone is checking your work and telling you where you got it wrong. Nobody wants that. On the other hand, it's going to be super useful to you because someone else is checking your work and helping you find things that maybe you weren't even aware of. Now the the person that I have, speaking with us today, his name is Brian Gross, and he's currently the VP of Product and Technology at Fiserv.
I chose Brian because not only did he go through a PCI audit with us and had to prep for that and things went really interesting way.
HIPAA audit as well. And so he kinda has a view of how do you prepare, how do you respond, what do you do to really make the whole thing smooth. Let me tell you a little bit about Brian before we hop into this. Brian Gross is a self taught software engineer and architect.
The technical cofounder of two different ventures. In two thousand twelve, he and his childhood best friend cofounded AthleteTrax, a SaaS company that provides recreational sports facilities with cloud based payment processing and back office management tools. In two thousand sixteen, they joined forces with a third partner to launch Pineapple Payments, which provides payment technology solutions to SMBs and SaaS companies. In two thousand nineteen, everything came full circle when Pineapple acquired AthleteTrax to add another vertical market to its core distribution strategy.
They officially closed on this chapter of their journey when Fiserv acquired Pineapple in May two thousand twenty one. Brian is now VP product technology with the partner solutions division of Fiserv, which is focused on servicing agents, independent sales organizations, and integrated software vendors with its best in class payments technology solutions. Brian, welcome to the podcast. Thank you so much for joining me.
Thanks for having me, Jen. Love, any any time we get to spend together, especially when we get to talk about, some of our favorite topics like this. So looking forward to the discussion.
Well, I I really appreciate it.
As I mentioned in in the introduction, a lot of businesses struggle with that first audit.
And I I wanted I wanted you to be here because well, first of all, super enjoyed talking to you. You are always one of the people who who makes an audit experience fun, and it can be fun. I I promise people out there, if you approach it the right way, it doesn't have to be a drag. Right? But I wanted you to be able to tell people a little bit about your experience.
Yeah. I'm happy to do that. We, we've definitely had a unique experience, with Pineapple, and that really was driven by the acquisition nature of the growth strategy that we employed.
We started out with no technology in order, just, serving business customers, leveraging, third party solutions.
And, eventually, it came time that, you know, we needed to increase enterprise value by bringing technology in house. And, we acquired a business in twenty eighteen that was effectively a set of software as a service like solutions for for merchant customers and also had a payment gateway.
We happened to close on the acquisition.
I don't know. I think it was sixty days or so from when their PCI compliance was, was due for that year.
And there, you know, was a smaller organization, so there wasn't a whole lot of documentation.
Right.
And, from a personnel standpoint, there was really, you know, sort of one key figurehead who oversaw all of the infrastructure and technology operations.
So it was it was something that we really needed to do almost a forensic accounting type approach to, you know, the the technology side of the business.
And I think you remember, we we went through some of this together, where, you know, to the extent that we even had to, you know, sometimes pick up the phone and call AWS and have them explain certain things to us that didn't make sense in our, you know, cloud console portal. Right?
Sure.
And and I think that's one of the unique things about acquisitions is that, you always there's always, time to pick up the information and really understand it from a systems perspective.
Anytime back when I was working hands on, I didn't really understand, a networker systems for a couple years. Like, you really I mean, you can get it in a few months, but but to really know your own systems, it takes time. And so the acquisition, you've got that. And then there's always personnel changes. People often use an acquisition to maybe pursue other things or or find a different direction or or, you know, there's always a shuffle and a shakeup that happens that for a lot of reasons. And so then you you you close, and suddenly, you have this PCI assessment that you have to respond to, with with limited knowledge.
Mhmm.
And and I I I often will talk to groups that say, alright. Are we ready for an audit? Are we are we ready? And I think that that that when you and I sat down, the sense was we didn't know what we didn't know, and we were gonna try and find all of the information kind of on the fly. And, actually, I don't think that's a bad way to kinda jump into your first assessment is what's what do you need to have and what what do you know what to find how do you know where to find it? And then it kind of brings up the gaps and then you go and fill those in and then maybe, you know, come come around to to, maybe a second try at assessment if if you just can't put it all the pieces together in the first place.
Yeah. I mean, you you brought up two really key points from my perspective. One is that an audit can really be a way to do that risk analysis and doing an audit even if you're not going through, you know, there's there's no business requirement to it or a, you know, a customer requirement. It can just be a good exercise to come to the table from a different perspective.
The other thing that you and I have talked a lot about over the years is, you know, it's not just something where you wanna approach it from let's check these boxes and then move on, but you actually want to tie it to business operations and make sure that you're extracting enterprise value out of the process and exercise that you're going through because, otherwise, you're, you know, you're spending money for this. Right?
Right.
And it's it's of really no use to just have somebody give you a scorecard.
But if you approach it from that place of, you know, how can we improve our cybersecurity posture, how can we improve our internal processes to actually drive increased value for our customers and for our business, there's a lot of good that can come from that.
And so going into your first audit, really taking a step back and trying to look at it not just as an exam that you have to pass, I I I think can be a quite important perspective to have.
I think that's one of the reasons that you and I have gotten along is that, we do take it from the perspective of what is the what is the business value of knowing, and increasing your security stance. And so one of the arguments I hear a lot from people online, and even in person is compliance is not security, To which I would say, absolutely, compliance is not security. But compliance is the vehicle with which we can, delve deeper into various parts of your security program and find out where where is the security level. And I think done correctly, done incorrectly is where a lot of the kind of, frustration and arguments can happen in an assessment when when all you get is a a checkbox back, here's what I found there, hand over the report, instead of, alright, together, we should be able to look at the security controls in place for each point of this compliance effort.
And together, we know if you meet that or not rather than, I'm gonna spring something on you that's checkboxed and you have no context in the end. Right? So, I I I really like how you you take it, the business value of it, and the security insights is really what the way people should be leveraging their their assessments for sure. So so PCI, was the first thing that we did, and then we came to the HIPAA audit after had been working together, for a few years on on PCI. Tell me, tell me from your perspective the kind of the difference in, a HIPAA assessment versus a PCI assessment and how how you would prepare for them differently? Like, kind of how they impacted you? What what are your thoughts there?
It's a good question. They're they they can both be, you know, big big and beastly if, you know, it really depends on your business case. In in our case, our primary focus was on PCI, and, we're really bridging to HIPAA in order to satisfy, you know, some customer and marketing needs, wants that we had.
I would say there's there was probably two distinct differences that it took me a little bit of time to really understand.
The difference between a standard and PCI and law and regulation in HIPAA was that was a big one and what that means as far as the risk and exposure to a business. The other thing is, something with with with us is that, you know, we are very much on the front lines when it comes to PCI due to the fact that we are processing payment transactions, storing cardholder data.
So it is our number one cybersecurity compliance focus. Whereas with HIPAA, we aren't a system of record for protected health information. So, there it's just you you come to it from a different frame of, you know, the the compliance is still paramount. Right?
Mhmm.
And even more paramount is the security posture, but the business justification is drastically different.
And the approach that we take, you know, there there were some organizations that would actually come in it from the other angle where they would start with HIPAA and then bridge to PCI. Right? That would make more sense for them. And so, it was the right progression for us, and it paved the way, you know, for if if we wanted to go even deeper into HIPAA and say, you know, focus on the health care market as a vertical for us and become a system of record and move from being, you know, just a cursory business associate to someone who is really driving revenue off of that model. I think we could have scaled that program, just just to be as as strong as our PCI program.
So Right.
And I think, your your points that you made about HIPAA as a law, as as a set of regulations, it really you do have to look at it in a different way because well, first of all, you can't get a yes or no. I am certified. Here's your here's your document that says certified the way you can in PCI.
Because, with the law, you just have to get an a degree of an assurance. How closely am I meeting these things? And everything in HIPAA starts with it depends on what you're doing and and how you fit with the protection of of protected health information.
And so kind of understanding the different approaches that and the different perspectives that you have to use, whether you're meeting a standard or a regulation, that that can you have to actively think about it in two different ways.
And I think you're right. It takes time to grasp the differences there.
Yeah. It was the biggest thing I would call out with respect to that is, the the risk analysis process that we went through for the two separate programs was, you know, with PCI was very focused on satisfying our responsibility to our customers and to ultimately our caller cardholders, but also to our partners and to our vendors, and making sure that, we we were driving value, right, through our technology and the posture that we had. Whereas, with HIPAA, it was it was really about trying to understand just where we stood. Right? Because, you know, we've been, you know, four years deep into PCI, and this was our first HIPAA audit. Right?
Right.
And so, you know, it it it wasn't just, you know, a a well oiled machine, but it was something where we were trying to educate ourselves along the way.
Mhmm.
And may you know, and look at our cybersecurity posture from, again, a different perspective of, okay. If we come from the HIPAA lens, how are we actually doing, and what are the requirements of us? And, you know, as you said, again, nobody can really tell you, you know, there's there's no real right or wrong here. Mhmm. So the the risk analysis component, I think, actually even came into play more for us to understand what are the things that we need to prioritize here.
And they ultimately actually benefited our PCI program, honestly. It all sort of ends up tying together, which is the the cool thing about, about, you know, some of the business that we do together.
So Well and I'm glad that your PCI, portion was so solid because that probably supported your ability to be acquired by Fiserv.
And it's payment processing, you know, that's PCI is a is a real important piece of that.
And by the way, congratulations on the acquisition. Fiserv, I under is a is a pretty big organization in payments.
Yeah.
We we are not small by any means. I think the the the statistic out there is we touch roughly forty percent of every payment transaction in in the US on any given day.
So there's there's plenty to keep us busy. But, you know, for any large company, especially, you know, the the public companies too where you're, in the spotlight more often.
You know, the cybersecurity is is a huge, aspect of of our day to day, and it's sort of gone beyond just, you know, engineers and product folks, but it's really, started to to evolve the rest of the business.
It's become, you know, priorities for many companies, whether it's at the management level, executive level, board level. So, it was something that, you know, I had spent a lot of time looking at, from the buy side in our diligence processes on our acquisition target. So, you know, you sort of combine that experience with, you know, having a really well known PCI program. I think we were in good shape when, you know, we we had plenty of folks, looking underneath the covers.
But Right.
You know, there's always there there what actually that process did show me is just like with anything else in life, you can always get better. You can always improve.
And it's a living and breathing thing, especially if you're continuing to enhance your products. Mhmm. Right? You know, it's really important to make sure that, you keep up with, you know, how your environment is changing. And, and and, you know, there's there's there's plenty, plenty of good reading to do, across the board from vulnerability management to, you know, technologies and tooling and end of life and, you know, in in the scenarios that you're not updating or enhancing your technology. So it was, it was just a good reminder to to keep an eye for watch on on on things.
So Nice. So having been through it, what what advice would you give to other businesses who are who are dealing with, an external audit for for the first time?
Yeah. This is, something that, you know, we we've taken a pretty introspective approach to our to our programs, trying to understand how each year we can improve because, you know, on the one hand, we wanna be thoughtful about the time that we are spending and get the most value from it, but it's not always aligned with our current strategic objectives. Right? Cybersecurity is not always the number one corporate development priority.
So we've tried to take an approach where we don't lock ourselves in a room for two weeks or a month once a year and do it all at once, but we actually build it into our business process, you know, with our with our operating policies and procedures. We're doing things in a daily cadence, in some instances.
I think more, you know, more of the heavy hitting, aspects are done on a monthly and a quarterly cadence, but, you know, trying to make sure that our business process supports our cybersecurity programs, and then our cybersecurity programs actually, contribute to delivering great products and services that are scalable and secure ultimately.
So we've we've tried to make sure that, it becomes part of our our DNA, and we, we take the the same attitude to it, as we do product development in in an agile fashion and, and make sure that, the things that we're doing, you know, especially those that can be automated can, you know, set it and forget it. But that when there are things that we need to dig deeper into, that we're we're adequately taking the time to do that on frequent intervals.
So Right.
That's something I think is important to remember that for the security professionals who are supporting the business, who might be listening. Sometimes I I I get this question, how come they're not taking security more seriously?
And sometimes when I dig deeper, what I find is the business is taking security seriously, but they're they have to balance that against the business value of of what they're doing. And so there are, levels of security that can be, put into place. There are people that can be added. There are tools that can be added, that may or may not enhance the business side of things. And sometimes what I find is the security people, don't have maybe the language to explain how it can add value. And so doing that little extra research, finding the the the right language to really increase that conversation between the business and the security side, I think is really the way to build it into the the day to day that like you talked about.
Yeah. Yeah. If if if you can't communicate why you need to do certain things with respect to cybersecurity and tangibly articulate the value that it's creating for the business, it's it's probably not the best thing to be doing. Right?
Because, in in today's day and age, there should be a way to, zoom out a little bit, right, and see the bigger picture Right.
And communicate that to folks in a way that they can understand.
But it it can also be, there there are certain aspects, and especially in product development engineering that are more suited to facilitating that conversation, especially when you're talking about infrastructure architecture. Right? We had, a good example to to illustrate that is, you know, we we needed to look at implementing a new solution for credit card tokenization.
And, you know, there there are plenty of ways to approach it. Right?
Sure.
But rather than just sort of satisfying some of the, compliance aspects, right, We we did just that. We zoomed out, and we said, okay. Let's look at what the needs of the business and our customers are over the next three to five years, and how does our technology today position us to be able to be successful. Mhmm. And, ultimately, what we ended up with is sort of a joint solution that met the needs of the business and our customers, but also helps facilitate our our cybersecurity efforts. And the way that we did that was by not just, you know, solving the problem, putting a Band Aid on it, but actually building an entire service around our Vault solution.
And we took the time to look at the technologies and the tools that we were using and said, you know what? If we actually use a cloud serverless environment for this specific implementation, it will go above and beyond to scale, right, as we add throughput to it.
Mhmm.
But we're also using a serverless environment, which means there is no living and breathing server for somebody to hit an IP address on. Right? And that's very valuable from going through an assessment together like we've done where there are certain things that you automatically can just check the box on that's not applicable because of that implementation.
So, that's I think that's a good example of how to balance business objectives and cybersecurity objectives and ultimately, you know, that ended up becoming a product. Right? It wasn't just a cybersecurity initiative.
Right. Right. So so taking this, it sounds like, you kind of have a two pronged approach. One is the technical architectural side, and the other is the regular business processes side or maybe the the the human processes side.
Do you think that that this shift in perspective, helps when you, annually when you reassess, go going through the process re annually?
Yeah.
It's it's important, to have business leaders in in these conversations.
I would actually, I would challenge any CEO or chief revenue officer or, you know, somebody doing marketing. Go sit in one of our, you know, half day, you know, assessments and see see what you're able to soak in. And maybe maybe nothing comes from it. Right? But, you know, there's there are a lot of conversations that we end up having that are quite business oriented Mhmm. Especially when it comes to business justification.
Right.
And those are the discussions where you really start to to peel back the layers of the onion and understand why we've made certain decisions to do things in a certain way. So I I do like I I I I feel that I can bring a unique perspective to those conversations having started out as a programmer and sort of moved, you know, over the last decade or so more into a business focused role because being able to take the outputs of our audits and, you know, actually bring it back to the business. It's not just about saying, yeah. We passed. Here's our attestation of clients. It's about what are the things that we identified as risks, where are the gaps, and what's our road map to fill those, and how are we gonna make those efforts drive business value for everybody else in the company.
So I am never happier than when I get senior business leaders to sit in for at least part of a technical security assessment because the conversations that happen from that are outstanding, and it it increases the understanding on on both sides of that conversation.
Yeah. I mean, it's the the awareness piece going back to, you know, the initial premise of our of our conversation today.
A lot of folks coming into their first audit, they just need education and awareness, right Mhmm.
About what all of this is. And, you know, it's it's something that it does take time to get up to speed with you know, you could you could be formally trained. Right? But you have to just like anything else, you have to actually apply it in the real world and for your for your business and your various, you know, set of products and technology and in various environments. And so, you know, coming into it, looking at it from that perspective and bringing stakeholders with you, right, especially if it's the first time is a really great way to to educate folks.
For sure. One of the things that that, your company decided to do, with SecurityMetrics was not just have a a third party assessor come in, but you also chose to work with our penetration testing team and and see, that some of the technical perspectives, that penetration testing could offer. How do you go about penetration testing? What does what does that look like, in in terms of timing and and the types of things that you have performed?
Yeah. I mean, timing is really critical with all this.
There's there's, in my opinion, two main components to timing with with audits.
There's the timeline that the outside world requires of you. Mhmm. For us, it's, you know, we didn't make the decision years ago because the company that we bought was on a certain schedule, and we know that, you know, every December, we have to submit our attestations to Visa and Mastercard.
But there's also a timeline that works for us as a business given our other priorities. And so, we come up with with the schedule that that works for us. My goal every year is, you know, to always deliver that attestation before Thanksgiving so that the holidays can be, stress free.
Nice.
And in order to to make sure that that's the case, you do need to start penetration testing well in advance, of of any target date. So we we try and get penetration, testing kicked off in the month of August, which leaves enough time for the testers to come back and give us a first report and roughly at least sixty to ninety days for us to, to resolve any findings.
So that, you know, allows us to sort of lean in altogether with penetration testing kicking off at the same time that we're gathering any supplemental evidence that we need for that year's audit, and making sure that the time that we're spending in person is really productive together so that we can answer questions, talk about changes to the environment, make sure that we understand any of the new, standards that have come out and and how we're addressing those and, and spend especially a lot of time understanding, you know, risk where we are today versus where we were last year. And then we should be able to to hopefully sit back and see what comes back from penetration testing and have that be, you know, as soon as you or any assessor, gets the green light from our penetration test.
You know, the report is already done. It's been reviewed. We've been we've been through it and, you know, understand where where we are and what what needs to take place from there. So the the the synchronization of of everything, it it's not gonna happen perfectly the first year.
Definitely not the second year either. But, it yeah.
You made two really good points there. One was get your penetration testing started prior to the on-site. So sometimes I'm working with a customer and I'll say, alright. Talk to me about your penetration testing timing. And they'll say, oh, yeah. We have it scheduled for the same week that you are on-site. And I just think, well, then this one's gonna fail.
Because you really do need time.
You you have to get the findings, and then your teams have to be able to remediate whatever is found. Sometimes they take takes a little time, and then you have to retest so that you have a clean, penetration test report. So I love that you said that. But the other thing was you you don't wanna have anything going on in the holiday season.
Well, you know, November, December, sometimes even October, November, December, people take holidays. Not just not just the audit team, but also your team. People on your team are going to be out. And so trying to successfully complete this when when you know you have to have it done by the end of the year, we get a lot of customers coming and saying, hey.
I have to have this done by the end of the year. Can you come out in December? And, I mean, that's hard because even if we can come out, are they going to have people on-site? And then how quickly can the report get done?
Because there's there's it's just probably the worst time for anybody to get an assessment done.
So I recommend everybody do it not in the in the last quarter of the calendar year because Yeah.
The holidays. Yeah.
I I I agree with you, and our our teams definitely agree with us as well.
So I think you have really offered a lot of, excellent advice to people who are are either facing an audit for the first time or maybe wanna look at how do we do this better the next time.
Is there any, advice that maybe that we've missed or something you'd like to cover before we wrap up today?
I don't know.
I I would say, you know, we we talked about a lot of the key things, you know, the the schedule, the, you know, building, all of this into your operational, day to day life.
I I think the last thing I would say is just, you know, making sure that this is a team effort.
Mhmm.
One of the things that we've learned being at smaller organizations over the the couple of businesses that that we've started and some of the businesses that we bought is, you know, there can be a lot of concentrations of knowledge, and this is supposed to to be a program. Right?
Mhmm.
And a program is not just for one person. So making sure that, you bring you know, we we we bring engineers to the table. We bring infrastructure and DevOps.
We bring product. Right? And we make sure that there are certain aspects that, everybody can can share in and the responsibility.
And I think it's, it's something that actually can bring the team together, like we've talked about before, bring bring more education and awareness. But, ultimately, when, things are going well or that one finding from the penetration test is remediated or the vulnerability scans come back clean, it's something that we can all celebrate together. Right?
Yeah.
And and and that's how I think you make it fun is is by making it a team effort.
So That is a great piece of advice.
Well, thank you so much for your time today. Really, I enjoy talking to you every time and you have a lot of, broad spectrum knowledge, that I think people will find very valuable. So, again, thank you.
Thank you. I'm glad to hear that and, looking forward to our next chat.
Great. Thanks. Take care. Thanks again for joining us here on the SecurityMetrics podcast. If you liked what you heard, please do subscribe, leave a comment, leave a I don't even know what you'll leave on the various platforms, but I'll bet you do.
And also, if you know someone who is getting ready for an audit or an assessment, send this to them because this can honestly be a really stressful time and just having that a little extra knowledge knowing what to expect, knowing how to prepare can really kind of alleviate some of that stress. In the meantime, I hope to see you back here at SecurityMetrics podcast. Bye.
Thanks for watching. To watch more episodes of SecurityMetrics podcast, click on the box on the left. If you prefer to listen to this podcast, it's available on all your favorite podcast platforms. See you on the slopes.
.svg)
