Virtru Voice of the Customer: Achieving Email Security and Compliance with SEC Rule 17a-4

Juan Salinas: Good afternoon, and welcome everybody to today's Virtru Voice of the Customer webinar. Just for a quick background, the Virtru Voice of the Customer series features, of course, our customers and the important innovative work on the front lines of cybersecurity overall. In the VVOC series, we share customer experiences with people like yourselves, fellow leaders in technology security and privacy. Today, we're specifically focusing on achieving email security and compliance with SEC Rule 17a-4.

A couple of quick house rules. We welcome any and all questions via the Q&A tool. So feel free to drop them in there, and we will try to answer them as we go along or save some time at the end to address them there.

My name is Juan Salinas. I am a Senior Solutions Engineer here at Virtru, and I'm excited to be joined today by Karl Jankowski, a security advocate and CISO at WealthForge. Karl, always a pleasure.

Karl, to kick things off, could you share some insights into your role and provide just an overview of SEC Rule 17a-4?

Karl Jankowski: Sure. So my job is to ensure information security at WealthForge, which is a broker-dealer as well as a fintech company. We have a financial services product in the alts investment space. And so the challenge of this role is to ensure that we have SEC compliance, FINRA compliance, and all that stuff on the broker-dealer side, but then also ensure the integrity and safety of our platform that processed three and a half billion dollars in alts in the past few years. So my role includes policy as well as hands-on engineering and, of course, strategic as well.

Juan Salinas: Awesome, thank you. And overall, can you share some insight regarding the rule overall, what the compliance rule is and kind of how that fits into what you needed to accomplish overall?

Karl Jankowski: Right, so 17a-4 is about records. It's about keeping records for an extended period of time. Those records need to be kept searchable and accessible for a while, and then sort of cold storage the rest of the time. And the records are communications specifically.

So the challenge—this doesn't apply in our organization to everybody. So number one is there is a subset of the population that needs to be monitored in this way. And two, we are dealing with confidential information all the time, which means that we're not only retaining messages, we're also retaining highly confidential information that is likely being encrypted and consequently decrypted by our technology stack.

So the goal here is to preserve all communications. They come from many different systems. The primary focus of our solution here was email, and it's to preserve the encrypted content in decrypted form.

Juan Salinas: Excellent. And overall, so what problems were you trying to solve for specifically? And then how did Virtru play a role within that overall?

Karl Jankowski: Well, so ours was a little bit of a nonstandard situation. We already had a solution that was in charge of routing all email communications out of our Google Workspace tenant and into archive in its decrypted form. Because that's really the essence of what we're trying to accomplish.

My role at the time was sort of periphery. I was doing information security, and I just happened to be in an office that was adjacent to some of the support teams. And I could overhear often them chasing down messages that were presumably not being delivered in some shape or form. And I started digging in to try to understand why we were having so many deliverables. I thought trust was really important.

In the course of that chase, I learned that the messages that were leaving our systems were not DKIM signed. And because the third-party solution that was doing the magic of decrypting and storing data was very Microsoft heavy, they didn't have proper support for Google Workspace, and consequently, they could not do the DKIM signing. So we were sending a whole bunch of mail that was basically spam as far as other people were concerned. And that was the beginning of this journey.

Juan Salinas: Yeah. I mean, I remember working with you trying to solve these problems overall. I think obviously leveraging that Virtru technology, that gateway specifically, right, to kind of say, "Hey..."

And there's a couple of ways we look at this overall. We structure the deployment based on our customer's security posture overall. What does their email flow look like? What are they trying to achieve? I think your approach to this, focusing from a security perspective, was "I want to maintain that client-side encryption." So I want to make sure that emails are leaving my inbox encrypted.

However, make sure that the compliance component is still kept intact, right? So leveraging that gateway to essentially make sure a copy of that email is sitting in archive based on the regulation. However, using that gateway to essentially just decrypt that one copy that's going to that specific archiving tool, but maintaining the security posture—the encryption of that email—to the intended recipients.

So that's kind of one option of deploying the Virtru technology to make sure we are adhering to the compliance. Or we have organizations also that might not be as... you know, their security posture might be a little bit different where they're not too concerned over that end-to-end encryption. So making sure that the emails are leaving the inbox or their email client encrypted, where that same gateway technology essentially is going to handle the encryption as well.

But since that email is already going to that archiving tool in plain text, the encryption then happens more via that gateway. We call it on the "server-side" instead of within that inbox specifically.

So great, I think there is again two different options of making sure the compliance overall is there and maintaining obviously the security posture over the email as well.

Karl, what about the deployment overall? Your experience kind of deploying this? I know, again, you were very hands-on. I think you were extremely involved, very thorough with the documentation, etc. But yeah, if you could chat a little bit about just your experience with the deployment of this.

Karl Jankowski: Yeah, so, I mean, this might be the long answer here because there's quite a bit to it. But, you know, it started off as, I said, sort of a rogue issue that I thought was material and I wanted to deal with it. That led into a whole journey of really understanding what the requirements are, what we wanna do as a company.

And because I wanted to sort of plan for our future, I thought it was really important that we don't have a single choke point anymore, that we actually are able to route mail in different ways. And that created a whole lot of complexity. We didn't have that choice with the prior solution. So the number one thing we learned early was as far as the architecture, we'll be able to roll out gateways. Those gateways will somehow exist in our infrastructure.

So it started off as trying to understand what we need to do. We knew that there'll be gateways in our infrastructure with some stuff that we would control, and they would process some subset of messages. For us, it was really important that in some cases, a person is always archived. And in all those cases, if they send something that is in any way confidential, no matter what happens, that information is protected encrypted.

For others, we just wanted to give them the choice to encrypt some stuff, and the gateway wasn't as important anymore. So the idea of having a Chrome extension that we could deploy via Chrome browser management or Google Workspace browser management was extraordinarily valuable because you can get that to everybody and start the deployment sort of phase one "crawl" and then sort of extend into "walk" and "run" as we built out the rest of the infrastructure.

But that's for later. The more important part was we didn't know a lot, and we had a really good team that was there to try to understand what we needed to do. But all we knew is we had this problem. We thought Virtru could fix it, and we didn't know how to do the middle. And this is where we reached out to all of you and you specifically and your team.

And the first piece of this was to understand what is it that we actually needed to do as opposed to what we thought we needed to do. And your team was instrumental. And I say this all the time to anyone I speak to: that's the part that sold me on everything else because we were absolutely really well taken care of from the get-go. The insight that you guys were able to provide—asking a question and getting a really detailed response that understood what we're after every single time—was the thing that built trust early and it allowed everything else to fall through. We solved a really complex problem, and we did it with, I would say, ease.

Juan Salinas: No. I mean, so obviously, you know, I think that gateway, I see a tremendous amount of value. The gateway as a product overall, I think it is robust. It's flexible. It can get within different workflows for different use cases our customers have, right?

So your use case specifically saying, hey, I've got Virtru for Gmail installed via that simple Chrome extension. However, again, I need to send a decrypted copy of every email leaving to make sure we are adhering to that compliance. Where some organizations, again, the main use case of that gateway predominantly has been this outbound encryption, not outbound decryption like we did for your specific use case.

But it's powerful in the sense that let's say organizations like yourselves have Virtru for Gmail and that can be Virtru for O365, etc. However, we are deploying it for that email client, right? We're standing up or deploying that gateway almost to cast this broader net in the event that I have users that for XYZ reason decide to connect their work email account to an unsanctioned email client, right? Something that doesn't have that Virtru add-in installed.

Obviously, as long as those emails are going through your corporate email environment, that gateway makes sure that every email leaving gets scanned and then based on policy that the organization admins create—"this email contains sensitive information"—I want to make sure we are encrypting that content as well.

So again, I always advocate a lot for that gateway. You know, I think it takes one email to be having a different conversation altogether, right? So that gateway is almost a safety net to saying, hey, great, I'm going to trust my users to make the right decision by using a sanctioned email client. We've added the Virtru technology directly within that inbox. But in the event that they have access to a different email client, that gateway is going to be there to make sure those emails get encrypted as well.

Additionally, we know that organizations have other email gateway technologies installed, possibly right? Other technologies that do other things. The gateway, again, gives you the ability to kind of make sure those products do what they need to do. And then maybe that product does what it does, and then it sends it to the gateway, decrypt, re-encrypt, etc.

Karl Jankowski: I almost wanna put a different lens on what you just said. Actually, not almost. I do, and I will. So we are obsessing over customer privacy. We want to make sure that nothing leaves that shouldn't leave. That's speaking specifically to the encryption component, because the SEC part is a separate issue, but we want to make sure that nothing is leaving our systems that is not properly wrapped around encryption envelope if it needs to be. So that's important to us.

And then you described situations where different clients and so on and so forth. Yeah. That's a risk, but we can mitigate that with Google pretty easily. Here's a simple one, though. The browser extension can fail. The simple issue is that it doesn't activate. Chrome is pending an update. A message goes out. Something's wrong with it. It doesn't quite communicate, and it doesn't capture it. The Chrome extension does a really good job feeding DLP rules when it works, but we wanted to make sure that under no circumstances ever, a message goes out without DLP rules applied. And that's where the gateway kicked in. That was the redundancy that we needed in case something client-side happened that simply caused a simple malfunction. Because for us, it was absolutely never gonna happen that we're gonna let something go out that is PII in some way that isn't protected.

Juan Salinas: Sure. No. Spot on. Karl, wanted to get into some of the details about the deployment since you deployed this yourself. Can you walk us through that?

Karl Jankowski: Yeah. So I have a schematic that I said I'd share. So I'm gonna share that out and maybe try to walk everybody through that.

So this is the schematic. And on the left side is we have our Google Workspace. We have some business rules that matter and they do some analysis. So the first part was kind of wrapping our head around what is it that we needed to do, and this kind of thing was a really necessary exercise. So part of the deployment is just really understanding how things are gonna flow. For that, I think we started off with crayons and paper, and eventually were able to do a little bit more. But that's where we landed, and I had really good help on this particular piece from Andrew Bates, who's one of our service security engineers.

So that was part one: Understand what is it we're gonna do, how the DKIM is gonna work because that was one of the issues we needed to solve, and which OUs are going to have what rules apply. So the way it works with Google Workspace—or one way you can do this—you can have users in different OUs, which we did. We split them apart, and then have different compliance rules apply to those OUs, which is also what we did.

And at that point in time, compliance rules are really easy. You guys provide pretty much completely foolproof documentation for how to do that. And what you're really doing is you're checking to see if a message is encrypted or it isn't, and you're routing it accordingly. That's pretty much it on the Google side. It's just, in some cases, just a few minutes of work. We have to reorganize some stuff, but it's not terribly complicated. We ended up settling on four compliance rules that ubiquitously solve all of our issues.

Moving away from that, we brought in the gateways. So we chose to run Amazon Linux 2 instances in our Amazon environment. We spooled those up and we used Docker Compose to build out three individual gateways running on different ports, doing different things. The three gateways were the outbound decryption gateway, which is the thing we needed to take an encrypted message and decrypt it and send it to Smarsh, and an inbound decryption gateway which did the same thing. Because when you send an email out from us to a potential investor or someone else, and then that's encrypted, that needs to be decrypted and packaged away. But then of course, they're gonna reply and we need to repeat the cycle. The hardest part about that is setting up the rule system so that it actually knows that it's a reply and then a chain because you wanna do that for every message cleanly without doing too much.

And then the only third one is the outbound encryption gateway, which is the DLP. That's the thing that says, look, I have a message that wasn't encrypted, but it came from a high value asset inside our organization. I'm gonna scan it for business rules. And if I detect, say, an account number or whatever, I'm gonna go ahead and encrypt that and send it out along its way.

What's beautiful about all of this is apart from Docker Compose being really easy, very easy to rebuild, maintain, configure, really simple to take logs, send them off to a SIEM and do further analysis. All of that was really nice. But also at the end, the end user has information about what happened to a message. They can affect it if they wanted to pull it back or apply some additional restrictions on it. They can do that. And we also have really clean control of all of our audit logging because we know everything going. So if we're debugging a problem, say a deliverability issue, we're no longer just at a Google place where we're looking at an email transaction log and seeing that a message was successfully delivered to the gateway and nothing else happened. We actually have full visibility through and through, all the way through delivery no matter where it went.

Juan Salinas: Excellent. And obviously this, from somebody just taking a look at this, may seem very complicated. However, your experience—obviously we talk about Docker just being very simple to kinda use that technology, how we package the gateway—but overall, just getting your hands on the gateway deploying it was pretty straightforward?

Karl Jankowski: Yeah. I came in with minimal Docker experience. Like, I knew what a Docker Compose was, and I felt really comfortable creating this. Overall, I thought it was very easy. In fact, I would say the most complex part is the diagram that you see here. I think we should have spent more time on Lucidchart than we did on anything else in the deployment.

Juan Salinas: What about overall your experience with the Virtru technology as it relates to your users within the organization? Was there—obviously, introducing changes is scary, right? But how was that user adoption overall?

Karl Jankowski: Overall, was really good. I could have done it better. I think we were so focused on solving a whole lot of problems that the user experience was kinda forgotten about. But it was also something that we could forget about, which I think is what led us to be a little bit more cavalier about it than we should have been. But we were able to communicate the changes since it was a Chrome extension sent out to managed devices. That was really easy. Just have to let people know and just keep them abreast of what was going on.

We prepped some videos on-site. We have an in-house portal where we're just able to share knowledge. So we made sure that there were basic instructions. No one had more than three or four minutes worth of content to consume in order to be fully sort of abreast on how to use the technology. It's really intuitive.

So I think the mistakes we made were really we could have spent more time on homing in DLP rules, making sure that we really understood what needed to get encrypted, what didn't. And we did quite a bit of QA. We did a lot of internal testing. So that was very good, but not necessarily user experience. And that, of course, comes with a little bit of griping and change, and folks really were used to a real simple situation where they could just write the word "encrypt" on a subject and everything was handled off. That still continued to work, but now we had extra stuff available to them.

But in the end, despite all of our sort of failures in how we rolled this out—or I don't know if "failure" is the right word, but I considered it sort of not a success, I guess—it didn't matter because the technology lends itself to bringing them up to speed and sort of closing the gap. So in the end, no harm, no foul. But yeah, I think it was really good on the users ultimately.

Juan Salinas: Excellent. I mean, and we obviously know customers in financial services have identical regulatory requirements, right? But I think where things change is environments, IT infrastructure environments, organizations have different... their tech stacks look different, right? So you kind of have to make sure you're checking the box off regarding the compliance that everybody has that same rule. However, understanding different IT environments, different tech stacks, and I think making sure there's a level of flexibility with the technology, again, based on what your environment looks like, what are your email flows, etc.

No, I think that's spot on. I think being able to make sure we are understanding this, kind of how flexible our technology is, not just for your organization, but overall, right? I think we look at this—my role with Virtru and kind of how you and I work—was: let me understand what your pain points are. Right? What your email flows look like, what you're trying to accomplish. And then obviously, show you the best approach, the best product that we offer for that specific use case.

But really understanding what your tech stack looked like, what your different data flows were, to make sure you are well equipped to say, "Hey, okay, Virtru has understood what I'm trying to accomplish. Here's the technology they recommend. Here's the documentation on deploying this based on my use case."

And obviously, I think the proof is in the pudding here as far as this incredible documentation that you were able to put together based on your experience with the gateway technology overall.

Karl Jankowski: So there's one thing that could have sent us in the wrong direction really early on, and I credit just your process, Virtru's process, for not sending us down the wrong path. And that is you have a choice. You have a hosted gateway, and then you have a self-hosted gateway. And the documentation for that is—depending on how you look at it—it's either in its own swim lanes or it isn't, depending on what you're searching for and how you do it. And, of course, I definitely am in the bucket of people that will confuse the two instantly because I'm just looking for the answer sometimes, you know, I'm not looking at it high level, and here we are.

So, early on, you guys went to understand what we were trying to do, and that's something that was clear from the very first moment. Again, this is why I'm here today is because the support was, I thought, extraordinary. And very early on with minimal information, were able to call out that the hosted gateway is not the thing I need. Show me the difference. Make sure I fully understood that there were two separate products that sounded very similar to each other and that I would have some responsibility over developing my own environment. You would think that's obvious, but considering everything we're dealing with, that was a detail that could have easily gone for another cycle or two and led to some problems. So you kept us out of the woods early on because you listened to what we needed. And then as a result, we never went down that path, but we could have.

Juan Salinas: Yeah. No. It's yeah. That's I think that's spot on. I mean, obviously, from our view, every time anybody from our team, our deployment team, etc., we're trying to spend the right amount of time at the beginning doing proper discovery to make sure we fully understand everything that is involved. Where there is, again, I think different ways of deploying the technology, right? Not just one way. I think that speaks to the level of flexibility that our technology has.

Where your use case specifically was how you wanted to make sure those emails left encrypted from the inbox, understanding your archiving solution, what your emails flows were. Shortly after your implementation, we did a similar one based on regulatory requirements, right? However, this other organization, same space, again, wasn't too concerned about that client-side encryption. So the email leaving their inbox encrypted. So the deployment again—the technology very similar, but almost flipping the gateway around saying encrypt it, don't decrypt because nothing encrypted leaving their inbox.

But again, I think it's just really understanding the different workflows. We know the, as I said, the regulatory components are going to be identical, but it's just understanding what the tech stack looks like, understanding what your security position is. Are you focused on client-side so that email leaving your inbox encrypted already? If that's not a priority or concern, you know, we can still encrypt. It's just gonna be via that gateway. So just having the different options overall.

Karl Jankowski: Yeah. We understood that we had choices where you can do the Chrome extension only. Obviously, DLP made sense for us in this case. But also, it's not that we put less value on the encryption part because there's this team that really mattered for. It just we had this other thing where we had a team that we had other plans for. There was a strategic plan for what was gonna happen there. And for that team, we wanted to make sure that we didn't conflate too many of our resources. We kinda wanted to start untangling and unbundling things, thinking about future growth. So it wasn't that necessarily didn't care. It was it's it was still important, but it was a different point.

But, yeah, the flexibility was what we really needed, and it truly solved a lot of problems that we didn't even know we had to solve for until we were getting into deployment.

Juan Salinas: Bringing it back, Karl, to some of the more 17a-4 focused components. Do you feel like there's good flexibility considering potential future regulatory changes overall, both from your experience with Google Workspace, that things are going to be able to adapt if, you know, there are any future regulatory changes overall?

Karl Jankowski: Yeah, I think that one of the things that this is setting us up for is the sort of long-term planning for what happens if a public company that is somehow part of our supply chain—and not necessarily they are providing service to us, but the other way around, perhaps we're in their supply chain really—has a materially significant incident. And then suddenly, we are somewhere in the vendor chain, and they're asking us to help them in a very timely fashion document or possibly start breaking down the extent of a potential issue.

I think that one of the major things that we've gained here that we have yet to unlock, but I can see it's present in its current capacity, is the ability to take the logging and the metadata that we have available today and take it a step further to prepare us for, hopefully, a situation that will never develop. And that is we're having to help prove or disprove whether a thing took place that someone else upstream needs to prove. So I think with those changes, we're in a much better position.

The archiving stuff, you know, the hardest part of that was I thought making sure that mail was delivered and we could track it down as well as dealing with the chains. I think that the next big thing that we might be able to see in the future, and this is contingent upon a lot of things kind of going our way, is the ability to do that to messages that are encrypted somewhere else and not through our systems and decrypt them and archive those because they're part of our chain too. We have supervisory authority over a bunch of other broker-dealers, and we need to do that. That part is a riddle that's yet to be solved, but I think that maybe we're on path. Maybe we're on path to creating opportunity to solve that problem. Like, we're still two standard deviations away from it actually being solved, but that would be sort of a nice welcome thing. And if there's a chance of solving it, it's here.

Juan Salinas: Yeah. No. That makes sense. Obviously, I think too having that gateway or the gateways in place now, if there were changes, right, or new components introduced, etc., I feel like having that technology installed, regardless of what's happening upstream, the gateways are there. Again, I think it speaks to the flexibility of the gateways to know whatever if there's a change in workflow, etc. The gateways being there, at least to me, adds this level of comfort, knowing that can do what it needs to do both outbound, inbound, etc.

Karl Jankowski: So, I mean, to just strictly to the point you're making there. Yeah. The entire thing is modular. Right. Now we've taken one monolith of a thing that was fully in control of every single message that left our system, and we've broken it down into a bunch of small digestible solvable problems. And now if one of those things needs an upgrade of any sort, whether it's, you know, a new compliance set or rule set or technology that needs to work a little differently. I know that I can swap things out and make adjustments, incremental changes to our infrastructure without compromising the entire stack. That, think, for me, it was obvious, but I guess, yeah, that's something really worth sharing. We can fix a small issue now instead of fixing one giant problem.

Juan Salinas: Yeah. No. No. No. I think that's spot on. There's a question here in the chat. "Why would some people have higher or lower risk tolerance? E.G. Why would some people want end-to-end encryption, but others would not? And what are the pros and cons of client-side end-to-end versus server-side controls?"

That's a lot. There's a lot to unpack there. We gotta break this down into a bunch of smaller modular pieces. So obviously end-to-end or client-side encryption means the emails leaving that inbox are encrypted, right? So obviously, Virtru has technology both for the Google ecosystem, also for the Microsoft ecosystem overall that we deploy. For Gmail, for example, it's a simple Chrome extension gets added to that Gmail inbox. That email—Google's always processing that email encrypted already.

To me, why someone would have higher or lower risk tolerance, to me, compliance is one key driver, right? Certain compliance regulations require end-to-end. So true end-to-end where that email has to leave the inbox encrypted. And other regulations, other regulatory components do not require true end-to-end.

Pros and cons. I mean, I think a pro for end-to-end is, you know, that email is always encrypted, has always been encrypted, even in draft for Gmail. No third party has access to that email. Where server-side is you are relaying essentially that email still encrypted TLS, but you're not adding those controls until Gmail sends it to the gateway and then the gateway handles the encryption overall.

So there are a couple, you know, to me pros and cons is different, I feel, based on requirements. And then some folks say, you know, a pro about doing it server-side via the gateway is there is no user experience, meaning your regular users don't have to do anything. There is no Virtru extension. They're sending an email the regular way they would.

They can be involved in the technology, meaning as an admin, I create a DLP rule, right? So that outbound encryption gateway operates in what we call outbound DLP, meaning as an admin, I am creating the rules that the gateway is going to encrypt off of. So again, a Social Security number, keywords, specific domains, etc. Or I'm going to tell my users, "Hey, if you want to be involved, add hashtag secure in the subject line." I've created that rule for the gateway to encrypt so you can have them involved.

But a lot of organizations that purely use the gateway, they love the fact that there is no user experience at all. They control what's being encrypted and what's not via the rules that those admins are creating within the control center.

So to me there is two ways of looking at it. I think the gateway, again, provides you're casting a bigger net, right? Saying "I want to make sure every email that leaves my organization, my Workspace or O365 email environment gets scanned via the gateway." And then based on those rules, that's what it's telling the gateway to do versus client-side, you know, end-to-end, more focused on higher regulatory components. There's a lot of non-financial world federal focused things, compliance programs like CMMC that require true end-to-end. So, yeah, you know, two different ways of looking at it overall.

Karl Jankowski: If I can take a stab at that for a second. Look at the client-side as voluntary compliance first. So it's a "Here you go. Here's a tool. Use it. Use it however you think is appropriate for you." And then the server-side is mandatory compliance. Right? So it's not only voluntary because kinda everything's gonna get processed. So those are sort of the two distinctions. But, ultimately, I think that the answer is both because the server-side, the downfall is that you only get what the rules say. And if we didn't do the job at the rules, then yeah. And then on the client-side, you know, I mean, people more and more are concerned about messages. So why not give them the opportunity to safeguard anything that they send? So it just kinda gives the person freedom and empowers the end user, which is really good.

Juan Salinas: Great point. That's a fantastic point. Another question here. It looks like this one's gonna be for you, Karl. "What do you look for in a technology vendor who's going to be supporting you in something critical like compliance? How do you go about vetting them?"

Karl Jankowski: I mean, so we have a vendor due diligence process. So we go through that. First of all, we are looking for an established company that has... we sort of have our own mix of things that we specifically designed as part of our vendor due diligence. But first, we're looking for a company that is gonna be there, especially in this case, like, this is materially significant. If we have a problem, we have SLAs we need to worry about. We can make sure we can solve a problem in a finite amount of time. So we test that stuff early, and we look at number one support response capabilities, all that good stuff.

But maybe this is an opportunity to kinda dive into sort of the nonstandard stuff that we will look for in a vendor. We look at a digital footprint. We used to do it manually or at least just sort of like on a gut feeling, now ChatGPT all the way. You can just tell it what you want and they will just collect everything for you. It's great. But we'll actually go back out and kinda see what the overall presence is, whether blogs are being updated, whether Twitter feeds are stale or not. We're gonna look at the entire thing. And the reason we're doing that is because we kinda wanna see momentum cadence. We wanna see that there is innovation happening. And none of that stuff on its own, there's no red flag if you suddenly decided that you're not gonna tweet something. But collectively, I think you get a pretty good vibe for what's going on in the company, and we want stability out of a vendor.

Certainly, legal review, that I think goes without saying. Terms of service, ease of buying, flexibility on the purchase process. Certainly costs, that played a factor here as anything else would. This was a very easy choice for us because we didn't have to spend more money to shift. So it was a very easy case to make. I presented Virtru to our exec team. And because I didn't have to present "by the way, we can get, you know, another X number of dollars," it was "Sure. Let's just get it done. Sounds like a good idea." So there's that.

And finally, we look at privacy risk as well. We wanna know that any information we give you is gonna be handled with the same level of treatment and care and custody that we would with the data that we hold. So we look for a value comparison as much as we do for all the technical and the legal stuff.

Juan Salinas: Awesome. No. That's great feedback. Let's see if we have any other questions here. I know we got a couple minutes left. We'll give folks here a minute if anybody wants to add an additional question.

Karl Jankowski: How did you feel, Juan? Let's just turn the page. How did you feel about working with us? Like, the one thing I see that is sort of the Achilles heel of how you guys provide service is—I guess for anyone who doesn't know, you can email Virtru and you tell them what you need, and then an email comes back with an answer. It's pretty amazing because there's no Zendesk tickets. And, you know, fatigue on that is massive. So it's really nice not having to do that.

But it comes with a real-world danger here. One is something could be missed, which I assume you probably don't because you probably have tech behind the scenes that takes care of things. But two, you can also have people like me that occasionally fire off an email at one AM that is incoherent, not full of detail, and now you have to digest madness in order to turn it into something that is productive. So what's the cautionary tale? Like, what do you need from us as customers to ensure that you're really effective at your role?

Juan Salinas: Yeah. No. I think that's a great question. I mean, I I'm very hands-on. I think by nature, not just my role within Virtru in my career overall, it's very—I like to be involved. I think as a sales engineer involvement in, you know... to me, it can be very transactional, but I don't like it to be transactional. I want customer involvement. I want transparency, right?

It's if I'm asking what your email flow looks like, either somebody is going to tell me exactly what their email flow is like you, or they'll say, "I have no idea." And that's okay as well. Part of our role is let's figure this out together so we know what products or understand what your email flow is, what you're trying to solve for. And then, you know, at the end, it's "Okay, based on everything, here's the technology you need," right? It's never leading with technology. It's understanding what the process is.

So for me, always if folks are involved, that is a plus for me. It makes my life easier. And I know everything downstream, right? So you and I worked extremely close together. All of that great information that you gave me, I'm structuring now the deployment team and our customer support team and our customer success team, right? Like that knowledge that you gave me, I'm curating that and passing that down to make sure everybody that you are going to work with eventually have the same information that I had, which I feel like was extremely important.

So yeah, it's we look for partners to write. It's the same way you know you look at vendors is we want to establish a partnership with our customers, really understand their pain points. Things change, right? Technology changes, regulations change, right? So just understanding where you're at in your process overall to make the partnership better as things evolve. We want to make sure your solution is evolving as well. So yeah, I think just the more information for me is always... I can curate that and pass specific information to specific folks that need pieces of that puzzle. But yeah, it's doing proper discovery is extremely important.

Karl Jankowski: So I guess the answer to my question is give you as much detail as possible on like, yeah, because you guys are very good at it. That came through early. And, again, I don't shy away from the fact that I've really come to appreciate working with the company, with Virtru. It's been refreshing. I said that to others in the past, and I just really wish more of my stuff worked this way because it was a relatively easy experience for a really complex problem. So, yeah, I appreciate that.

Juan Salinas: Awesome. Well, I know we are up on time. One more question maybe? "For future regulation changes, Google Workspace,"

Karl Jankowski: I wanna just take a stab at it and say, you know, Google's an engineering company. Microsoft is out on products, professional services. Beats me. Either way, point is they're both really flexible. They're all really good at it. But having another company that is sort of boots on the ground is really helpful. So having something that's a little lighter and that's a little simpler, it's a little bit more mission-focused kinda taking the helm is probably better, and I think that's where Virtru lands.

Juan Salinas: Alright. Well, I wanna thank everybody for joining today's Virtru Voice of the Customer webinar. Karl, always a pleasure. We will speak soon. Cheers.