Taylor Hersom of Eden Data

All right. Welcome back to another episode of Modern Cyber. We've got a great set of topics queued up for today's conversation. And I've got a really interesting guest who comes with a background that is exactly the right background to have this conversation about. We're going to be talking about shadow IT. We're going to be talking about governance. We're going to be talking about compliance. CMMC, SOC 2, probably lots of things in those areas that are coming up again and again and again, not only for customers that we work with, but also for vendors and partners in the cybersecurity arena. As you go engage with your customers, these are the things that you're going to get asked for, how you're managing these things internally for yourself.

And to that end, to shed some light on this conversation, I am delighted to be joined today by Taylor Hersom. Taylor is the founder of Eden Data, a cybersecurity firm recently acquired by Riveron, where Eden Data now plays a key role in expanding the firm's advisory platform. Taylor is a former Deloitte leader and CISO who brings deep experience in governance and compliance frameworks, including SOC 2, ISO 27001, HIPAA. I'm sure there's more than that as well. But since founding Eden Data, he has helped hundreds of startups and scaleups including Nooks AI, Zendesk, Bitly, and Kindbody navigate everything from early stage compliance and IPO readiness and earned the Partner of the Year awards four years in a row from Drata. With his background, Taylor speaks to the evolving intersection of cybersecurity, compliance, and enterprise growth, showing how trust can be a powerful driver of business success. Taylor, thank you so much for taking the time to join us today on Modern Cyber.

What an intro. Jeremy, you made me sound so much cooler than I actually am. No, thank you so much for being here. It is an honor to connect with you.

Seriously, my pleasure to have you on the show. And I do actually want to start with that last topic that we mentioned from your bio. And that is trust, because I know one of the things that you said to me is that most startups overinvest in security tools, but underinvest in trust. What does that mean to you?

Yeah. And Jeremy, I think that you can probably appreciate this topic more than many in the general business landscape, because as a security professional, we all know that cybersecurity has been talked about for a very long time. We invest in security, fighting for budget, trying to overinvest in the things that we know we should be doing to lower our risk posture, but that is like pig Latin to the average customer that you are selling to. And so in order to build a relationship with a customer and help them understand how you're protecting their data, you need to be building trust. And in order to build trust, it is not adopting security tools. That's an aspect of it. There are definitely customers that have great security hygiene themselves, and they're asking you great questions about how are you protecting my data as the vendor. But in reality, a lot of this is very confusing. And so to the average customer, how do you educate them on the things that you were doing to protect their data and overinvesting in ways to be able to do that, to earn that trust from them, therefore earning that business, therefore running off in the sunset, living happily ever after with multi-year contracts and such.

So is a way to think about that, like if I try to translate that to a concrete, you know, vendor-customer relationship, is part of the way to think about that if you come to me as a potential customer and you say, "Hey, Jeremy, why should I trust you?" And I say to you, "Look, I've got CSPM to cover my cloud footprint. I've got ASPM looking at the security of my application stack. I've got managed detection and response, so I know I've got 24/7 coverage." You know, that's alphabet soup to you. You don't necessarily understand or care about the individual technical controls. What you care about is kind of the holistic sum of how I, as a vendor, am worthy of your trust.

Incredibly well summarized. Yes. So those things, like you said, are alphabet soup many times, and they certainly are an important aspect because it gives you credibility. You are talking about things that sound really cool, and that's going to help you earn trust in and of itself with the customer. But these customers oftentimes are educated as "I need to be asking for a SOC 2," they call it certification when it's an attestation, "ISO 27001 certification," they have these certain buzzwords that they're looking for, even when it doesn't even make sense for your business. But the reality is, you are trying to sell yourself holistically and that includes your security posture. And I also want to clarify that it's not just earning trust with the customer. You're also, as a security professional, having to earn trust with your shareholders, with your stakeholders, with the C-suite. The average CIO, CEO, CTO, they have at least a cursory understanding of security, but oftentimes it doesn't go past cursory. And so how are you able to educate and say, "Look, I am investing in these tools, these tools, and doing this holistic approach to secure our company, but let me tie it back to ROI," because you and I both know getting budget when it's purely looked at as a cost center is next to impossible. So how can we tie back our security efforts to our sales efforts? How can we highlight and depict that, "Hey, the things that we're doing in the security department are making a direct impact on the customers that we're signing"? Um, that's another important aspect of the investment in security instead of trust.

Yeah. And it's interesting because one of the things as you were talking through that response, one of the things that occurred to me is that, you know, we as security founders, and I include myself in this group, a lot of us come from very technical backgrounds. Either we were security practitioners or we built products, or we were solution architects or, you know, pick two out of three columns, whatever the case may be. So we overindex on like, "I need these technical controls. That's how I solve this problem. I solve my cloud misconfiguration problem by having CSPM with auto-remediation," as an example, right? Like, and you know, that's solved. But in fact, when I think about, you know, any of the places where I've worked where I have experienced security breaches, the technical controls were only one aspect of it. And a lot of the times it was internal processes and people-driven processes that were actually the failings, or at least a huge contributing factor to the breaches that we experienced. And that's one of the areas where I think like, you know, something like a SOC 2 has a heavy process-oriented component in addition to what in my view is still actually—I still kind of argue that SOC 2 is underindexed on technical controls. But again, maybe that's just like my background bias.

No, I think you nailed it. SOC 2 is very focused on general governance processes. It's severely lacking in any sort of meaningful technical controls or anything that makes an impact on a continuous basis. But two things to call out, which is, okay, you nailed it in terms of companies are often missing the basics, and SOC 2 and ISO 27001 especially really emphasize the basics. And so getting things like vendor management and a risk register and having appropriate processes around your personnel going through training and reading policies and such, that stuff's boring, sounds easy, but in fact, oftentimes access management and basic security hygiene around just general processes is what is the weakest link in the chain. Um, so I would say that that's pretty paramount. And I would also say that the secondary benefit to that is SOC 2 or ISO, those are the—that's the language that your customer is speaking, because those are very well known at this point. And they do give a level of comfort, even though they are a piece of paper and I think in some ways are severely lacking, as you mentioned.

Yeah. I think of them a little bit like a trust escrow, right? Like I trust this kind of certification program and I trust my auditor who, you know, is accredited to do SOC 2 attestations, and my customer does as well. And so like, you know, I can save my customer all the time and thankfully, and hopefully save myself the 100-question security questionnaire, right? Like by pointing at this, he points at that, we all agree that this thing is—both sides are going to accept it as being like an acceptable kind of checkmark for the level of trust that we're looking for. But I do wonder about one thing, which is like, okay, we at FireTail, we chose to do SOC 2 year one. And it was something that I chose because at a previous company, we didn't do it, and by year five, it came back to bite us and we were so far down the path at that point, we were like, "Oh, this is going to be a nightmare. It's going to take forever." This was a little bit before platforms like Drata, Vanta, many of these platforms came around that, you know, frankly, made the process a lot easier for a young company like me. But if I hadn't had that mindset going into it, how would you talk to a very early stage company, especially kind of an early stage cybersecurity company, which is a large part of our audience? How would you talk to them about choosing the balance between going down that path versus the tools that they might look at buying?

This is definitely a biased opinion from my standpoint, and certainly a hot topic in our community in general. But the way that I look at it is that I am going to have a hard time convincing an early stage startup that's just trying to survive, trying to make it to the next round, trying to sign that next customer. If I'm trying to convince them, "Hey, this is important because you could end up in the news and you could get breached, and that would be very bad for your reputation and all those things." Those are all theoreticals. But oftentimes, even we have pre-revenue companies that we're signing all the time that are already, as they are talking to their first customers, even before they've released their first product, getting asked about these standards. And so the education piece that we're giving is, "Hey, go pay attention to what your customers are asking of you and use that as your North Star out of the gates." In some cases, for a SaaS startup, that's HIPAA or HITECH or HITRUST, in some cases it's SOC 2 or ISO. Now we're starting to see like ISO 42001, the AI governance framework. Like, there are certainly different requirements based on who your customer base is, what country you're selling into. But paying attention to that and using that as your first North Star is what's going to put rocket fuel in your ability to grow as a company and then to mature your security practice.

Yeah, yeah. Got it. There's something else around the compliance space that is like an acronym that I've seen that I admit I have heard a number of times, and I have like a little bit of an idea around it. And that's CMMC. And I know one of the M's stands for maturity and one of the C's stands for cybersecurity. But like, help me understand A) what that is, B) how that's different from a SOC 2 or an ISO and where that might be applicable.

Yeah, it's a great question. So the CMMC standard has been talked about for quite a while now, but it's essentially the government-mandated standard for subcontractors that are doing work directly or indirectly with government entities, prime contractors, anybody that's holding onto sensitive data that's even loosely related to the government. So to give you like a rudimentary example, that can be a SaaS company, a tech company that's selling a software solution to even just a subcontractor of the government. But that can also be one of our customers makes a specific machined screw for a specific jet that our military produces. They have to align with CMMC. So this has been talked about for years and been a theoretical framework that was allegedly going to drop and become enforced many times, except now we are at the point where it is being enforced. And the looming compliance date is coming up here in November. And the last thing I'll say to it is that CMMC is largely looked at as like kind of the SOC 2 standard for the government space.

Okay. So it's a little bit like SOC 2 is kind of general, HIPAA is very specific to healthcare, CMMC is kind of the government space version of this. Um, but like I said, one of the M's stands for maturity and I just went and googled it real quick. So Cybersecurity Maturity Model Certification.

Yes, there are three levels. Yeah. No worries.

There are three levels of it. What do we need to understand about those three levels of it?

Yeah. So this is going to really depend on the type of data that you are collecting. The type of information you have. Is it government data? Is it intellectual property? Is it sensitive customer data that touches the government? Those levels are set based on the severity or importance of the data that you're collecting as a company or what you're doing as a company. It's also a little bit tied to the criticality of your company and the service that it provides. Um, the good thing is that a lot of times the folks that are driving the compliance standard for CMMC, like typically it's your government entity or prime contractor, whatever the case may be, can give perspective on how they view essentially what bucket you fall in. And that's a great starting point, so you can understand the levels that you need to adhere to.

Okay. And you mentioned that the enforceability is now kicking in or has already kicked in.

Um, it is in November. So essentially it's been talked about since last year of like, "This is now coming, there is a drop dead date." That does not mean that everybody gets shut down the second that November hits and they don't have a CMMC standard in place or certification, but it is going to start being largely scrutinized by the customer base that's demanding it. And there are entities out there that are saying, "We can't do business with vendors that do not align with the CMMC standard."

Okay. Is the standard pretty well aligned to a SOC 2 or an ISO 27001, or does it have very different types of requirements?

Yeah. I mean, between us girls, it's all very incestuous. Like they very much, all these frameworks are very much overlapping with each other. So CMMC is based on the NIST standard. So you've got NIST CSF, you've got NIST 800-171, 800-53. All of those are overlapping with each other. Uh, CMMC is kind of cherry picking from those various standards, mostly 800-171 and the Cybersecurity Framework, CSF. But that's how it's built. It's structured very similarly to the NIST framework. However, it's I think important to note that the NIST frameworks, historically 800-53 and 800-171, were kind of like the precursors to CMMC. They were required if you were a government entity, if you were a prime contractor, that sort of thing. Uh, CSF was always optional, but CMMC is now very much being enforced, similar to 800-171 and 800-53.

Got it, got it. If you were talking to a startup today who's starting from scratch and you're advising them on their journey: SOC 2 first, ISO 27001 next, and then obviously like HIPAA, CMMC, depending on the customer base? Or do you think there's value between going from SOC 2 to ISO or is it, you know, like you said, it's all pretty incestuous, they're all roughly the same?

Yeah, very, very solid question. It's actually the first conversation we have with customers. Typically it's helping them understand what bucket do I fall in, what is important to me. And that actually goes back to you've got regulation—those are laws that you have to adhere to. So if you're collecting PHI, Protected Health Information, you do need to align with HIPAA, for example. But then you've also got standards which are very much optional: SOC 2, ISO 27001. There's no regulator that's forcing that upon you. That's just your customers that are forcing that. So the reason I bring that up is that one of the first conversations we have with customers is helping them understand, "Okay, what are my regulations and what are my compliance frameworks that I need to align with?" And to answer that second one, you got to look at that customer base. If you're selling globally and you have customers big and small, you're definitely going to want to look at ISO 27001 as a standard, usually first before SOC 2. But if ninety percent of your customer base is in the US, then we advise on SOC 2. But back to your question about SOC 2 versus ISO versus others, usually ninety percent of our customer base—it's actually a little bit less, we track the data the best we can—goes for SOC 2 and then ISO 27001 after that. That's like the most common step up. Um, but you know what's funny is that a lot of times the subsequent standards are brought up by our customers as like a scramble of like, "Oh my goodness, I got SOC 2, we got ISO 27001, we were just cooking with gas and cruising right along, and then all of a sudden a random customer just asked us about CMMC, and now we're in a panic because we need to sign this customer." Right. Um, and so that's always a big driver, is that the customer base will ask for increasingly more standards.

Yeah. And you kind of have to adhere to that. Yeah. And so for anybody who's gone through like, let's say it's us, for instance, you know, we don't happen to do any public sector work right now or have any customers in that space. But, you know, we've got our SOC 2. We just completed our HIPAA review. We have annual GDPR reviews as well. We pride ourselves on being pretty studious as well as pretty disciplined in a very fast moving environment where it's easy to get distracted and it's easy to kind of put a lot of these things into the background or deprioritize them. But let's say somebody comes to you today and is like, "Hey, I need CMMC. I've got those things in place." How big is the lift? Like, how long do you reckon is kind of the process from like "great, auditor engaged"? Is it a thirty day? Is it a sixty day? Is it a ninety day? Again, assuming that the company is really actually following their guidelines, adhering to all the processes that they've laid out, etc.

Yeah. And you're talking about for CMMC specifically?

Correct. Yeah.

Okay. Yeah. So it'll depend very much on the level. So you've got level one, which is just basic federal information. It's no controlled classified—I'm sorry, CUI is the acronym for the controlled unclassified information. That is what is used a lot, CUI, as it relates to CMMC. If you don't have CUI, that's level one. If you're a defense contractor or touching a defense contractor and you are touching CUI, then that's level two. And then level three is for like the just really highly sensitive stuff. So it very much depends on those. For level two and level three, it's a bit of an uplift. So the estimate that we give is anywhere from six to twelve months for both of those. Okay. Um, to get those controls rolled out, documented appropriately, testing long enough so that you have evidence to provide to an auditor. Um, that's typically the uplift. It can be expedited. We've had some customers move on level two a little faster, but the amount of requirements that go when you're level one versus level two and level three, it jumps up quite a bit.

Okay. Got it, got it. That's super helpful because, you know, it did come up in a conversation recently and I was like, "Look, you know, we're not doing public sector work," but just for my own information, I really appreciate you going through that and talking through it. So, awesome. There's another area that I always hear and, you know, you've probably heard the expression "compliance isn't security and security isn't compliance," but one of the other terms that gets lumped into that bucket very often is governance. How do you think about the tension between compliance and security? And we talked a little bit about how, in my opinion, some of the compliance standards are a little bit light on technical security controls, but maybe overindex on process. How do you view those tensions? And then how do you view governance as being complementary or different to compliance and security?

Oh, these are spicy, I like it. Uh, so because compliance, you're right, the topic of compliance versus security, you've got die-hard security professionals that say compliance is the silliest thing ever. And then you've got folks that are going and embracing SOC 2 thinking "I have the most robust security program out there." Both parties are wrong. Like compliance and security absolutely are different buckets. And we've actually treated them as siloed buckets in the past, where compliance lives off on its own, security lives off on its own. The way that we look at those is, are you protecting yourself against an auditor versus a hacker? Like those are two very different strategies. However, there is a ton of overlap and we talked about this a little bit. But yeah, like SOC 2, for example, it's not like what SOC 2 is recommending is crap. It's just very basic. You go and you embrace more mature security controls as you get bigger and as you mature your procedures internally.

So I do think that, um, this is a good segue to your second part of your question, which is governance in and of itself. How do you govern over your compliance strategy, your security strategy, and then kind of an ancillary to that is your privacy strategy? Those have been siloed in the past. They're coming together, especially with GRC tools like Drata and Vanta and others that are popping up. How do I track all this in one ecosystem and how do I make it overlap? How do I know that—I'll give a perfect example of if you're aligning with SOC 2 and NIST CSF, there's a user access review requirement for both of those. The user access review requirement for SOC 2 is not as intensive as the CSF requirement. So therefore you can build one control, but you got to beef it up to CSF standards if you want it to work for both frameworks. Otherwise, you have to operate essentially two different controls. "I'm doing this amount for SOC 2, and I'm doing much heavier uplift for CSF as it relates to user access review." Those are some considerations. And this is where governance comes in. You got to know exactly what frameworks you're aligning with, you got to know what you need to do. And usually we recommend the more robust of the two or three or ten that you align with is what you need to use as your North Star. So that's the way I look at it.

Yeah, that makes a ton of sense. There's an aspect to governance when people ask me, "How do I think about governance?" And obviously what we do is we help organizations with AI security strategies in order to enable AI adoption at whatever scale and pace is right for the customer. And so they ask me like, "Well, hey, help us with AI governance." And I'm like, "Great, what do you want?" And they're like, "Yes." And, you know, the real challenge in that is like, governance means a lot of things to a lot of people. And very often I think of it as being, especially in the AI context, like, look, number one is, you know all the AI that is being used inside the organization, right? So having that baseline visibility, which is also important as a security control, is critical. But number two is I kind of think of it in the context of like, whatever you say is right for your organization, governance is knowing that that is what's going on, right? That you've got the visibility and the technical controls to say like, "Hey, okay, we're all in on Copilot. Great." Well, now I should not see any Claude or Meta or Grok or whatever, or, you know, governance for us is "These are the tools we allow, absolutely no DeepSeek," you know, whatever that set of rules for your organization is. Governance is very often, in my opinion, knowing that that is exactly what's happening. And now I think a lot of organizations are very challenged in that. And I think AI is making that particularly challenging because it's like shadow IT on steroids, where literally every stakeholder within the business might have a use case for it, everything from finance to accounting to IT to development to what have you. So like, what kinds of challenges have you seen around AI governance? And why do you think that this is like an increasingly crucial thing to get right?

You actually brought up such a great point that is pretty prevalent in our industry, which is that even the terminology gets either misused or misinterpreted, or it means multiple things. So in this case, I'm over here talking about governance of your compliance strategy versus your security strategy. Then you break off AI, which is technically a subcomponent of that, but it's its own ballgame. Right. And so then the way I'm looking at AI governance in general is this is back to kind of what we talked about a little bit before, where people are going and adopting these incredible tools and LLMs and they're training models, and they're doing all these cool things, but they're skipping the basics, right? Like back to what you said, what is approved? What are we going to use? What are we going to invest in as a tooling? Is it going to be proprietary tooling? Is it going to be outsourced tooling? And how are we going to block using other platforms that we do not approve? What are we training our models on? That's like another very core question that you need to ask and then document appropriately. Um, and then also like who's approving deployments, who's approving what we're doing, who's actually reviewing this on a periodic basis? All of this sounds easy to say out loud, but educating all your staff on what our processes are, where it's documented, that's very basic, but it takes time. You got to have interviews, you got to have policies, you got to have procedures. And so governance is really like getting those cats herded into a singular location to get everyone on the same page about how the company is using AI, what's going into the LLMs, and then how are we going to make sure that this doesn't get out of hand quickly?

Yeah. And I think that last point, how does it not get out of hand quickly? Because there's so many organizations that we go in and talk to, when we talk to end users, like the actual end users, nobody is maliciously trying to do bad things with AI, but many people are under pressure to perform their job faster or quicker or better, whatever the case may be. And in many use cases, these tools are super helpful. And, you know, for instance, we recently spoke to a healthcare organization and I was talking to the CISO there and I asked him, you know, "Hey, how are you thinking about this? What's kind of your policy around it?" He's like, "Well, you know, we have some ideas." And we kept talking over the course of a couple of weeks, and then later he came back and he said, "Yeah, I figured out what our strategy is and how we're going to govern this." And I'm like, "Awesome, what are you going to do?" "We're writing a policy document." And I was like, "Wait, wait, wait, wait. Just to be clear, your solution is you're writing a policy document?" "Yeah. And, you know, it'll go through this employee training process, etc." Great, but no technical controls and no, let's say, technical oversight to see whether people are adhering to that document. And I think like, you know, for a lot of organizations that may be functionally where they're at because either they lack the tooling, or either they lack the resourcing and the manpower to actually go monitor logs or whatever the case may be. You know, like very few people check their DNS logs to see that, you know, Taylor's using ChatGPT. I can see Taylor's endpoint doing chatgpt.com lookups on a regular basis or whatever the case may be, right? Like that's a pretty obscure way to try to track that down.

This challenge, though, for an organization like that, does mean in my mind that they've got, you know, a relatively high risk that some well-intentioned employee takes confidential information, patient information, PII, PHI, whatever classification label you want to put on it and introduces risk to the organization that could result in compliance fines, regulatory oversight, etc. And that's where a lot of organizations are with AI today. A) does that match with some of your observations? And B) what would you—if you had a chance to sit down with that person, what would you say to them about some of the flaws in that thinking? Or if you see any, or how they should maybe think about approaching it differently?

First of all, I'm kind of sounding like a broken record because I just, I agree with you wholeheartedly. Like the space is very much at this stage where we have it's the wild West when it comes to AI in general. And most people are just misinformed about how to control it. Right. Because we are, I mean, even from a security professional perspective, you and I have had to teach ourselves about AI just in the last couple of years and how to be appropriately secure with it. Like, it's not like something that we've known for a decade.

You might have had a leg up on me, actually. But yeah, like, seriously, like the last two years and it's been, you know, the most intensive crash course and the fastest moving piece of technology I've ever had to deal with in my whole career.

Yeah. Really? Well. Please continue. So this is our profession, right? But the average CEO, CIO, even CISOs that have to deal with a million things, like it's very hard to stay on top of this. So I think the issue is very much that most folks are just misinformed and their intent is not to be malicious or create risks. It's in fact the opposite. But we also have to shift our perspective from a security standpoint on how we treat risk now that technology is getting better. And what I mean by that is having someone read a policy—I don't know the last time you looked at a security policy, but I can guarantee that you don't remember everything from it because I certainly don't.

And being able to—I wrote ours and I review it every year and I don't remember everything that's in it.

Yeah. There's no way, there's no way, no way. And it's like watching paint dry to read some of those. So I do sympathize with the average employee that has to look through these. I mean, I've seen some customers that were sending out twenty, twenty-five policies to get acknowledged by employees. There's no way they're retaining that information. So I focus on how can we automate controls? How can we remove the human in the loop whenever possible in order to avoid these situations? So back to your example of rather than us trying to go and have—I guess we can have alerts when someone is using a specific tool, most companies that I know of don't have that in place inherently. How can we block some of these tools? How can we set up a specific approval process? How can we remove access to data for Betty Sue, who does not need to be accessing PHI ever? Like that's a big aspect of how I look at it. And the things that I just said are actually quite simple to do. It just requires the knowledge to know to go do it. And I can't blame the average business leader for not knowing to do that.

Um, but your question back to the second part, you were asking me essentially like, how would I have this conversation with the average business leader about this? And it's really educating them on, "Hey, we usually talk about humans make mistakes and they don't mean to." And they're like, "You know better than most Mr. or Mrs. CEO that we are all focusing on a million things at once, and our attention span is at an all-time low. Let's figure out how can we proactively invest in technology to just remove the human from needing to do this, which creates a productivity boost and reduces risk." When you can give it from the perspective of "this is directly benefiting the business in multiple ways," that's usually an easier sell. That's how I take the approach.

Yeah, yeah, I really like that approach. I think that makes a ton of sense. I mean, everybody talks about aligning security to business outcomes. And that's very often easier said than done. But I do think that because there's a positive side and a negative side—and the positive side, very often compliance is actually the thing that is, referring back to the beginning part of our conversation, compliance is very often that trust escrow point that customers will point to that enables revenue, right? You've got that compliance checkmark. I trust your auditor. I can look at your SOC 2 report. I can read it for myself. I can see any variances, any incidents, any callouts on that report. Get a sense of you as an organization, how you operate, all those good things and come to an informed decision and then decide to move forward with you or not. And so that's like the positive side of it, right? Like revenue enablement.

The negative side of it is a little bit more nebulous in the sense that it's, you know, more often in the form of either regulatory fines if you're in one of those regulated spaces, or in the form of loss of customer trust and kind of brand and reputational damage, which is often harder to quantify. But it is very much one of those things that like, I can give you that as a risk conversation as a business leader and say like, "Look, your downside business outcome is there as well, right? You've got an upside if you follow all these guidelines, unlock revenue, you've got a downside, get penalized." What I have often felt to be the case, and maybe this is a little bit selfish as somebody who works in the cybersecurity tool space is, I think the penalties are not big enough and they're not frequent enough. And I really think like, I don't say that only as somebody who is again, has an inherent bias and incentive around selling more security tooling. But I also say this as somebody whose data sits with many, many different companies, and I don't want my data breached again and again and again. And I know that's happened any number of times. You know, for instance, I once, at some point twenty years ago applied for a government job. It was maybe a bad idea, but my data is in the OPM breach or the OMB or whatever that office is for government hiring. And it was in Equifax and it was in, you know, probably three or four other very, very large scale data breaches. And my understanding is that the penalties on any of those are pretty trivial. And it's one of the areas where I've argued that the downside should be bigger because it will incentivize better behaviors. I don't know if you have any reaction to that. I'll get off my soapbox now on that point.

I love how you said it. I mean, if you just look at humans in general, we've always had to incorporate regulation in order to enforce better habits. And so that's why we have laws. That's why we have speed limits. That's why we have very severe repercussions if you are driving under the influence of alcohol. Like it's no different than any of that. If we were just told, "Oh, don't do that again," or you have the slow down speed sign every time you're blowing through an area, nobody would change, right? You have to have repercussions. Um, so I could not agree with you more. And it's just unfortunately, it's really sad where we've gotten to, where you now have multiple examples of companies that are being fined where it just doesn't even remotely hurt them. Um, and there's nothing you can really do about it. The last example I'll give—I don't mean to knock any company, but we have a very real example that's happening right now in our industry, which is Delve, one of the software companies that is in the GRC space. Like they're virtually out of business overnight for a lot of speculative... it's speculative wrongdoing is what I would say. Like there's not even, it's still being investigated, but that's a Y Combinator backed company that now has lost the trust of their entire customer base for alleged claims.

Yeah, yeah. And it's one of these things, and I really love, by the way, I love your DUI parallel because, you know, if you get pulled over for drunk driving, whether you caused an accident or not, the penalty is there and it's real, right? And so, you know, you have a lapse in cybersecurity, whether records are breached or not, there should be in my mind some level of accountability. And whether it's a penalty or not, maybe the accountability is enough. You know, there are in many regulatory regimes these things called... oh shoot, it's escaping my mind. But Verizon had to go through one recently with the Federal Communications Commission, a consent decree where they agreed basically that they were at fault for failing in cybersecurity. Um, and in their case, actually records were breached. And in fact, hundreds of millions of records were breached. They actually didn't get a penalty, but they did get this regulator oversight that came in and said, "Hey, look, you're signing up to six months of cybersecurity improvements. We're going to monitor your sprints. We're going to come in and audit at the end of it and make sure you've held up your end of the deal. Otherwise, you know, we have every tool in our arsenal, including shutting you down." And like, those are some of the levels of penalties that I would like to actually see a little bit more frequently. Again, I'll get off my soapbox.

I want to move on to—we've got a couple of minutes left, and I want to move on to kind of the last thing that I think really ties it all together. You know, one of the things that you said before we started recording is that compliance can be a real competitive advantage in the AI era, and that security maturity is actually going to help companies move faster, especially as they do business with enterprise customers. I think we could draw a lot of logical conclusions based on today's conversation, but I'd love for you, in your own words, to just kind of summarize some of your thinking around that.

The way I look at this is that every business out there actually has an early mover advantage opportunity. Um, if you looked at the SOC 2 standard five years ago, it was still being embraced. It's been out for a while. It's been out longer than 2021, five years ago. It's been around for a bit, but even then, there are plenty of companies out there that did not have it five years ago. Now it's everybody and their mother's got it. The flower shop down the road's got it, it seems like. But for AI governance, there is nobody out there that really has their act together. "Nobody" is such a strong word. That's not true. But I don't know if you saw, like ServiceNow did a recent study and less than one percent of the organizations that partook in it got more than 50 out of a 100 score on their AI maturity. So I look at this as a business opportunity. Go and invest proactively at the very least in just documenting your AI processes into a marketing document that you can proactively provide to your customer, and then at best, go for something like ISO 42001, where you get that certificate to put on your digital fridge, and you can provide that to your customers proactively and say, "You don't even have to ask us about AI, because here it is right here." Yeah, this thing's beautiful. And you can be talking yourself up and it's going to grow your business and it's going to make you look good. So that is where my viewpoint is on using it to your advantage, because someday it will be enforced to the point where it is commoditized, like SOC 2. There's going to be more standards that pop up, but your customers are looking for this. They're asking the questions. Might as well just bite the bullet and use it as an early mover advantage.

Yeah. Love that thinking. I think that's a great note. And by the way, I'll just add into there. Bear in mind, the EU AI Act is also upcoming for enforcement. And that does touch companies outside the European Union. If you are serving customers inside the EU and you have AI anywhere in your stack, you are on the hook as a—I can't remember if it's a provider or a consumer or what the exact terminology is. We had a webinar about this just the other week, and we had an auditor from Ireland who spoke on this topic. I would refer anybody who's interested back to that webinar to get a little bit better educated than I myself can do. But I do think that is something that is also super relevant in this domain space.

Taylor, thank you so much for taking the time to join us and talk through this. You know, this topic is really one that so many organizations that we talk to right now are struggling with. You know, we see a lot of kind of bottoms-up AI adoption inside companies. And a little bit to your point, you know, I think you said fewer than fifty percent of companies really know what's going on. I think it's actually way, way lower. I think we might be, you know, single digit percentile of companies who really have a handle on what AI usage is happening inside the organization right now. And it's, again, you know, not necessarily any bad motivation. It's employees trying to be creative, effective, productive, you know, get ahead, whatever, all of those reasons. Any closing thoughts as we wrap up today's episode? Anything else you'd like to share with the audience? And also where can people find you and your work?

Yeah. The closing thought I would have is to reemphasize the last thing we talked about, which is that security absolutely can be used as a competitive advantage. It goes beyond just AI governance. Look at your customer base. See what they're asking. You can see it in their contracts that they're sending over to you. You can see it in their vendor procurement process. Proactively build something, make it a marketing opportunity so that you can be proactively providing that to your customers even before they ask. And I promise you, we're seeing it out in the field left and right, that it builds a tremendous amount of trust and helps put some velocity in that sales process. In terms of where to find me, LinkedIn is probably the best spot. So I thank everybody for taking the time out of their day to listen in and nerd out on these topics.

Awesome, awesome. And we will have your LinkedIn as well as your company URL linked from the show notes for today's episode. As always, I'm Jeremy signing off for this episode of Modern Cyber. Rate, review, like, subscribe, all that good stuff. You know what to do. But thank you so much for listening to today's episode and we'll talk to you next time. Bye bye.

‍