Solving Hard Security Problems With an Outsider's Perspective | Sravish Sridhar

I grew up in in India. And as a 17 year old kid, I decided to come to Texas, which is if you put your finger on the globe on one side and you put your finger on the other side. Austin, TX is exactly the opposite side of the world that I grew. Up was going to say yeah. And so I ended up in Texas and they asked me what I wanted to study and there was this thing called computers that was taking off in the mid 90s. And so I said computer science and then I became a nerd where it was actually in college that I got my first computer and started coding.

And since then I've built 2 businesses that were venture backed with successful exits and now I'm doing my third one. Oh my gosh, what a, that's a really boiled down version, I'm sure of what's a, a, a very cool story. But I've met a lot of people in this industry and others that are, you know, second or third or fourth generation in a business. But usually it's a business that was started by those older generations, not like 5 generations starting their own business because everybody else hated what the other ones were. That's right.

My parents were extremely successful entrepreneurs in the shipping industry. They ran the largest container feeder operator in the Bay of Bengal. And I grew up as a kid around ports, and I saw my fair share of container terminals and ships and how that entire business worked. And after I got into that, I said I'd never want to do anything with shipping for the rest of my life. It seems extremely complex and labor intensive in just like a million things could go wrong at any time. It is, but it's still the lifeblood of the world, right? Like with things that are going on in the, in the current political climate that we're in, with the state of Hormuz and everything like that, one sliver of ocean water is affecting the entire world economy.

So shipping is still an integral part of how we operate and run our day-to-day lives. But to your point, it's it's one of those things that have existed for a couple of millennia. Someone still has to do it, but it's hard work. It's really true. It's one of those things where you don't think about it very much unless, you know, like you, you were steeped in and you grew up with it. But you think about it. If say you go to the store and there aren't any, you know, pick a product that day, you're like, oh, that's because this ship didn't get to where it needed to go 4 weeks ago because there was a storm in the South Pacific. And that's why you don't have, you know, laundry detergent today.

That's, you know, it's, that's a whole long supply chain that we deal with in software too. It's a different thing, but same sort of thing. One little thing goes wrong and it has these downstream effects for a very long time. And, and I think the way you described it is very apartment because even though I didn't like to get into the shipping industry, the thing I really absorbed through osmosis of just observing how the industry worked is how distributed but yet connected that industry was. And so as a computer scientist, I kept thinking about this problem of distributed but yet connected networks and how you can build businesses on top of that level of complexity. Because if you can solve for that distributed yet connected complexity, then you're solving a really hard problem that everybody's struggling with.

So all three of my startups have that as a common theme across each idea. That's fascinating because those that distributed complexity problem is one of those computer science problems and networking problems that people have been trying to solve since we've had networks and computers, you know, and there's different parts of it and it's nobody's going to solve the problem itself. But it's, it's a long standing computer science and networking issue that especially people in the security world are still trying to tackle, obviously from many different angles.

So when, what was the going back a little bit, what was the culture shock like when you got to Austin, TX from India? I just, I was in Austin last week, as a matter of fact, just just by chance. And it's a place I love, but it is not. I can't imagine it's very similar to India. You want the R rated version or do you want the PG rated version? What kind of what kind of podcast? This is this is not a family podcast. Well, you have to put this in context, right? So this was the mid 90s. I've never travelled outside the country and I'd never been to the US, And my entire perception of the US was based around TV shows that I saw, you know, things from Doogie Howser and The Wonder Years to, Oh my God, Knight Rider and The A-Team and like, stuff like that, right?

And so I didn't know what to expect when I came to this country. And I got dropped in Austin, TX end of August when it was the height of the summer. And you're walking around Austin, TX for the first time on campus and you see young men and women who look like Greek gods and goddesses. And they're just walking around. And there is a huge party culture. There's, there's still, you know, a lot of innovation, technology, academia that is happening.

But if there's an equal amount of partying and drinking and going to football games and like all of these things. And so there was a rude shock for me on both ends, 1, the rigor of academia was both inspiring and intimidating. And then in the other, how much fun people are having was absolutely phenomenal. In fact, a quick story on how I ended up in Texas. It was based on advice I had from a family friend of my dad's. He said now that you've decided to pick, you want to study computer science. Here's the top 25 computer science schools in the US. Sure.

And then he pulled out a Playboy magazine and he said, here's the top 25 party schools in the US And I created a data-driven decision before it was data science was a thing of picking the intersection of that list. And Texas was the number one on that list. And when you combine those two lists, and that's why I applied to that one school and I got in and. I was going to say that the overlap of those two lists is probably 1 school. It was. It was probably UTI. Think there was a Florida some like something, but yes, those basically there was, I think there was 2 schools there.

UT was by far the full one, yeah. It makes sense. Yeah. And it's it's funny because it Austin like is such AI mean not to turn this into some kind of Texas podcast, but like it's a college town. It's a very like weird creative arts town, but it's also the capital of Texas. So it has like all of these weird kind of overlapping cultures that, you know, get along in some cases and don't always get along in other cases. Yeah.

In fact, when I when I landed in Austin, the theme in Austin at the time was the slogan for Austin, if you will, at the time was Keep Austin Weird. Yeah, I think it. Stole that and we all had T-shirts that said that and we wore it and we wore it proudly. Yeah. So you, you mentioned that was the first time you got a computer was when you got to to college. Yeah, my, my, my Texas e-mail was the first e-mail address I'd ever gotten. Oh my gosh. I never personally. I never owned a computer personally till I think I was almost 30 years old.

I've always either had university computers or I've had work computers. I've never had a personal computer of mine ever in my life till I was about 30 years old. Wow. And all my computer time was in the labs on campus till 2:00 AM and 3:00 AM. Trying to figure this whole thing out. So what were the when you decided to study computer science, was there anything specific about it that appealed to you? Was it just sort of the way that your mind works, like kind of the analytical, you know, I, I feel like this is something I'd be good at, or was there something else that really appealed to you?

It was, I mean, I, I was both a computer science and a math major. Math was my strong skill set, continues to be a strong skill set of mine. And applied mathematics was, was, was a field that a lot of people were looking at at the time. And computers was the way that they were expressing modern applied mathematics. And so that was the the combination of getting a math degree and a computer science degree at the same time. I didn't think I was going to become wholly in the computer science space. I thought math was going to be my calling when I was younger.

But here we are, more money. More money in computer science and math. Yeah, I was going to say the the career paths for a mathematician are pretty limited unless you're really. Good. And I wasn't that good. Right. I, I feel like you're either in academia or you get some sort of applied math job at, you know, a defense contractor or something along those lines and, you know, a. Lot of my friends ended up at banks. This was also the height of the.com era and so, you know, all the big banks were hiring people from my cohort of mathematics and statistics majors to just come and applied quantum to quant, become quad jocks essentially in all the banks, which is also a big, big, big career move for those folks.

And all those people are running hedge funds now. They are. Some of them are managing hundreds of billions of dollars. One of them is managing a number that starts with with T, So it's, yeah, God, some pretty significant roles. That's mind bending. Jeez. So what made you, when you not thinking that you were going to be an entrepreneur or you thought you were going to be a mathematician, what what was it just sort of the family heritage that led you down the entrepreneurial path after school? I'm always yeah, that's exactly it.

You know, I think whether you like it or not, your what your parents and your family does does rub off, rub off on most of us. We are formed by our experiences as children, both good and bad. And I think what I saw in my parents was a deep passion for what they did. You know, when they truly love something and made it their life's mission, mission to build that thing, there's a lot of satisfaction in in what they did. It never felt like work. It felt like more a passion and yet a responsibility. Sure.

And it just so happened that during my undergraduate years I was working with, one of the professors I was working with was a very famous professor in the world of distributor computing, a gentleman by the name of Doctor Jim Brown. And he introduced me to this concept of SETI at home, which was a screensaver that people were putting on their PCs. That's a throwback. Wow to. To try to find if there was extraterrestrial life in the universe. And I got introduced to a couple of entrepreneurs who are thinking of taking that idea and making it into enterprise software.

And I started working on that project with them. And we ended up starting a company called United Devices. And the gentleman who started the City at Home project ended up being our founding CTO. And so if you've ever run City at Home, you've run my code. I was. I. I built this significant part of that screensaver. That's crazy. And, and then we then took that and also built another not-for-profit project to help find a cure for cancer. So we partnered with the National Foundations of Cancer Research and the University of Oxford, and we ran a grid.

It was called a grid computer with three and a half million PCs all over the world networked into one supercomputer so you could run molecular discovery for Cancer Research. I remember this. This is. Yeah, that's crazy, 'cause this was for, there's, believe it or not, probably people that listen to this, that will not remember SETI because they're too young. But it it was the search for Extraterrestrial intelligence and essentially was a yeah, it was a I'll let you describe it. But it was using distributed computing power among millions of people around the world to do little essentially like micro problems, right, to like look for to crunch data. This is before we had all the compute power we have now. But yeah, we screensaver the.

Next was you had this big satellite called the Arecibo satellite, which was bringing signals from outer space. And most signals from outer space have no patterns to it only, only artificial signals will have patterns to it. And So what we're essentially doing is we're analyzing every signal coming from outer space to find if there's any patterns in the signals which become a hint that they're being generated by an artificial life form or an extraterrestrial life form rather. And so you needed computing capacity that didn't exist on the planet to do that analysis.

And that's why we built this idea of a screensaver that people downloaded. At one point, I think we had about 750,000 machines operating concurrently on this. And then we took it up a notch with our company where we had one part of our business which was selling this concept to enterprises to deploy inside their enterprises to aggregate all the computing capacity inside their enterprise for confidential research. And then we had this public grid of three and a half million PCs that we're doing a lot of not-for-profit research with academia as well as we even for at one time we even took all of the micro fish, journalist data, newspaper articles, etcetera. And we converted into digital form using this network. We did denial of service attack testing, we did encryption, cracking all sorts of use cases right on that public grid. Yeah, it's funny.

Those were you just described essentially the three or four main use cases for the grid computing, which was going to be the next big thing, you know, before the cloud, you know, Yeah. There's a big part of me that that that is disappointed that I didn't come up with the phrase cloud computing because, because this whole time as we were building this company, every time we would draw a market extra diagram on the board or in a slide, there would always be a cloud in the diagram. Yep.

But we focused on the interconnectedness AKA the grid, but we didn't focus on this cloud that we were trying to call it cloud computing. I think you're in good company. There are people that wish they had come up with the idea of or the phrase cloud computing. Yeah, I, I remember that very clearly in when I was at a tech magazine in the early 2000s, Literally every whiteboard diagram of some somebody coming in to pitch us, you know, it had a cloud here and just a bunch of arrows. And then like little, you know, PC icons or something, you're just like, OK, I get it, that's the Internet up there. But now, yeah, now it's just Amazon or Google or IBM or whatever it happens to be.

And in fact, we actually built a precursor to the cloud with a few telecom companies like British Telecom was was one of our customers in that company. And we deployed our software inside the BT network with their data centers and created on demand computed storage for BT customers where they could click a button and say I want so many servers and databases storage and so on. And then they would get that provision that they would get access to it. So we built all of that. Again, we didn't call it cloud, we called it utility computing. Yep.

Utility computing? Yeah, sure. But but yeah, we, we, we, we, we built that company and then that company got acquired and then the iPhone was launched and just grew like a weed all of a sudden. And my next thesis was enterprises are going to go through a digital transformation exercise where they're going from web to mobile and IoT. And, but all this data that they had all over the enterprise was not designed for this new form factor. So how do you build essentially A middleware that connected to legacy authentication and data related systems and make them available for more real time use cases, offline use cases, mobile use cases, etcetera?

So again, if you see the theme here, you know, on one end I was harnessing distributed networks and computers and storage. And in this scenario I was aggregating distributed data and identity and making it available for a new form factor. I am sensing a common theme given that your your current venture is called Trust Cloud. So where did the where did the germ for this idea start? Yeah. So after my previous start up was, was also acquired, I took some time off and I was reminiscing on that, that journey of about 15761516 years of building two companies.

And the thing I kept coming back to was a piece of advice that my parents gave me when I started my first company, which was we don't know anything about technology. So we kind of advise you on what it is to build a software company. But what we will tell you is as an entrepreneur, the only way you're going to sleep well at night is if you tell somebody you're going to do something, do it. And if you're not able to do it, just be upfront and let them know as quickly as possible and deal with the consequences. Like don't play any games.

Trust is the only currency you have in the land, in the long journey of life as well as in in work. Excellent advice. And I lived that. I lived that day in and day out. I lived that. I'd made sense to me. I lived that. And I think for me, the evidence that that is true is now in my third company, customers, investors and colleagues from both my previous companies are not working with me for the third time, right? So that is like the evidence that you did it the right way. And so when I was thinking of that idea, I was asking myself, we have a system of record for everything in business, but nobody's really built something that is the system of record for trust.

No one has codified trust as a machine readable and machine inspectable object and I was intrigued by that concept. You know, can you codify trust? Can you build an API for trust? And at the time blockchain was a thing. Can you build the Ledger for trust? Yeah. So these were all ideas sort of swirling in my head, and I talked to a lot of people. You know, the advantage of building two companies is you end up building a fairly large network of people from different backgrounds, experiences, titles, etcetera.

And I would ask them questions like, what does trust mean to you? What, what, what are your trust obligations? How do you meet them? How do you know you're meeting them? Do you measure them like, and it was I was getting all sorts of answers across the board. I actually lost my faith in humanity quite a bit during that that period because people talked a good game around trust. But then when you actually understood what they were doing to meet their obligations and prove they were meeting their obligations was actually not much and they were kicking the can down the road essentially at the time. But there was 1 persona that I found was actually wanting that problem solved.

Most people were willing to like make it someone else's problem or wait. But there was 1 persona which was either the CIO or the CSO in a company where this problem of trust was now becoming front and Center for them across multiple dimensions. One dimension was audits. There was more and more pressure on on completing and maintaining compliance to both regulatory and commercials standards. Another area was risk. They were buying a lot of security tools, but they didn't know what risks they were living on. And, and once he so beautifully explained it to me, he said looks rubbish.

I've got every security tool you can think of and I'm getting smoke alarms going off from each one of those tools, but I don't know where the fire is and I don't know which fire to work on. Yeah, they don't know how to prioritize it in in budget. Right, Yeah, yeah. And then the other area is there's this whole customer side where if I have a regulator or a customer who's who's demanding contractually that I will do these things. And now every, for example, if you look at any customer contract, it has a security addendum and a data processing agreement and a privacy addendum.

And now in the last 2-3 years an AI addendum. So now companies are making contractual commitments that they're going to do these things from a security, privacy and AI standpoint. And that is tied to liability with the contract. So all the Csos were saying my business is sitting on hundreds of millions if not billions of dollars of liability because I know for a fact that we're not doing those things that we've said we're going to. Do, yeah, yeah, right. So that was a problem.

I was like, that is a distributed computing problem. I I know how to solve that problem. So unlike what you may assume, Dennis, I actually could not spell security or could not spell GRC before I started Trustcloud. I have no background in this space. But it sounds like you fundamentally understand what the at least one of the foundational problems in the security world is, which is trust. But it, you know, there's a million different names for that thing of like, can I trust that this person or this device says that they are who they assert themselves to be? Can I trust that this company or my customer is going to do what they say they're going to do?

You know, can I trust this data that my customer or my supplier gave me? Can I trust this software that I'm running? The answer to that is no, you can't, you know, but I am really fascinated by the fact that you went and asked a bunch of people like how do you codify trust or how do you define trust? Because I was going to ask you that question. How were you defining trust when you went about, you know, creating the idea for this? For this question, so my Co founders and I and these are people that I've now worked with across two companies.

They're also all software engineers by background in training. We actually got together and we wrote after a period of a couple of months of brainstorming, we actually wrote that an internal memo called the kernel of trust OS. We, we basically thought about trust as an operating system. And we said, if I was writing an operating system, going back to my operating system classes as a computer science student, everything starts with the kernel and then you sort of build on top of that. So, so how do you, what, what defines the kernel of trust was the, was the underlying thesis. And what it really comes down to, I'm, I'm going to make it, I'm giving you the Super simplified version is it always starts with an objective, right?

Every trust obligation has an objective. I am going to keep your data secure or I'm going to meet my contractual obligations with you or I'm going to help grow our revenue, right? It starts with some sort of objective like that. Sure. And the next step to that is you're then trying to say, OK, for me to not meet these objectives, there's a set of risks that are in place that are if any of those risks are elevated, then I'm not going to meet that objective.

And so you need to figure out how to describe these risks in machine readable form. And then you need to have things like the likelihood of these risks, the impact these risks have, What is the consequence of these risks? What is the financial obligation like? All of these parameters are on risks. Yeah. Once you understand the risk for each risk, you then put mitigations in place, like what are the things you have to have to avoid this risk from happening? No mitigation is 100% or very few mitigations are 100% foolproof. So you have to weight these risks. You have to weight these controls.

They call them controls. You weight these controls and you measure if you're meeting these mitigation obligations. And the way you measure them is through data. You have to collect data because these mitigations apply to a resurface. That resurface should be a set of contracts, should be an asset. It could be devices, it could be an application, and you have to collect data to make sure that those mitigations are operating effectively to protect those services. And usually there's always some issues.

And once you have an issue, it has to calculate the impact of that issue and spin it out as your answer. And then you're sort of going back and evaluating it against the original objective and saying, because this issue exists and this impact, do I need to start budgeting, prioritizing, taking action, reporting, whatever the consequences? You have to then sort of create that feedback loop. And that became the idea that we said if we can go build this idea, then you can essentially build the AWS of trust where you're building all the building blocks that allow any stakeholder in the business, the CSO, the CRO, the CHRO, the CIO, the CEO, the board to take any trust obligation and build on top of this.

So right now we're focused on the Cecil as our ICP, but we have companies where the CFO is using Trust Lab for things like Sarbanes-Oxley. Yeah, yeah. We have customers in the food and manufacturing space. We have customers in the Pharmaceutical industry that is using US for trust obligations around FDA compliance. Sure. Nothing to do with, you know, nothing purely to do with security. It has all sorts of other controls and risks and so on.

So we're slowly expanding into other markets, but our primary bean and butter is how do we help Cisos list their objectives? How do they map risks to those objectives? And how do they then deploy controls and continuously monitor them and measure them to determine which risks are elevated and therefore which objectives need to be prioritized and budgeted better? You know, it's, there's a couple interesting things about what you just described. 1 is that Seesos and I, I know a bunch of seesos and many of whom are, you know, mutual friends of me and Jen, your, your CMO and they are some of the most stressed out, like sleepless people you will ever meet.

I'm sure you're, you're noticing this in your customers, especially people that see So's that are in like tightly regulated industries like financial services or, or food or healthcare or any of those. Because they, they know for certain, whether it's through, you know, one Ave. or another, they're sitting at a bunch of liability as you described earlier that they can't really control. You know, they can do the best they can possibly do, but there's just stuff that's out of their hands.

And if one little thing goes wrong, they get a bunch of regulators walking through the door and they get a bunch of customer lawsuits and they get all that kind of stuff. And if you can take away even a little bit of that stress from their lives, you're their best friend in the world. Like they they couldn't be happier, I would think. Yeah, everything you said is accurate. And so when I observed what you just said, I would ask the question why? Like I'm a, by nature, I'm a very curious person. So I'm always asking like, tell me, tell me more why, why, why, why? And it really whittled down to four simple truths, which it baffles me that these are still unsolved for a majority to see.

So the first simple truth is your job is defined as proving a negative. Yes. Correct. Yep. Right. Impossible task. Cesos need a way to then figure out how do I display how I'm positively affecting the business instead of only being asked to prove the negative. That was one learning. The second learning was if something does happen that is bad, it's already happened in the past, right?

It happened a long time ago, and they don't know that it happened and when it happened. Why? Because most of their assessments are being done with surveys and security questionnaires. Oh, absolutely right. It's like going to a dentist and the dentist asks you, Dennis, do you floss twice a day? Do you brush your teeth twice a day? And you say yes, but of course, takes your essay and starts looking at your teeth. And they know the reality, right? Yeah. They know online. And it's already happened in the past. And so you need to give them real time risk data, real time telemetry that allows them to change their perspective from looking at the past to now.

How do I look into the future? So that was observation #2 observation #3 is they have a really important job. They're the custodians of their intellectual property, their customer data. They are highly underfunded. Oh yeah, and understaffed. And yeah. Right. Why? Because they have not been able to articulate in a business friendly fashion, the business case to fix some of those issues. Most Seesos are very technical.

They're great at what they do. They're not able to speak the language of business. Yeah, in, excuse me, I think some of that is beginning to change, you know, that you are seeing, I think a newer generation of Seesos that maybe came up through Business School, but also have some technical chops and that sort of thing. But you know that doesn't fix the budget problem that you just described, that you know that doesn't give them a magic pile of money to go fix things.

That's right. And that brings me to the fourth one, which is the information security program is seen as a cost center. Yeah, absolutely. And I think it's important to reframe it as this is a value add to the business. This is actually a profit center. This is actually helping support revenue growth. If you don't do the things we need to do, we cannot close deals. It is actually reducing risk. And if you look at a balance sheet, it is actually reducing the risk. Liabilities in a balance sheet like these are the types of conversations that need to happen relative to the invest investment that is going into the security program to show that the security program is actually green, not red.

Yeah, I think the the really difficult challenge is that a lot of Csos when they go talk to their boards when it's time to ask for more money or whatever it happens to be, the best thing that they can say is that nothing bad happened in the last year or the last quarter. Like nobody, there's no disaster on our you know, we didn't have to file any eight KS disclosing other events or, you know, we weren't the news. Like everything was calm. Like that's great, but we're not giving you any more money. You know, it's it's kind of like if if you did that with that, with just this little bit amount of money, then we don't need to give you any more.

Like you're doing fine. Yeah. And you left the caveat tennis in that statement, right? It is to the best of my knowledge, I think that happened. Yeah, as far as I know now, there could be an attacker in our network right now that we'll only find out about four months from now at a very bad, inopportune moment. But I we don't know that yet. Yeah. Because I look, I, I have great empathy for them because not a single siso I've ever met will ever say I am secure. And I think they're right.

They shouldn't say I am secure, right? They're absolutely right. Because you never know. There's always a bunch of so-called unknown unknowns in this in this industry, but the current processes is pretty low confidence in assessing risk or understanding the security posture. I work we work with some of the largest enterprises in the world and they are still assessing their risk posture by sending out surveys once a quarter or once a year. Do it totally, yeah.

And they're basing their entire strategy and risk assessments based on assuming that the person responding a is giving the truth and B sampling evidence and basing verifying their responses with sampling is good enough to believe what they're saying. How many of your customers or you know, just the the folks that you talked to, you know, potential customers do you think really have a handle on what they should be measuring or, you know, looking for in their organization? It's a great question.

I'm actually going to say most of them actually know what to measure. They do OK, that's good. They do know what to measure. And, and, and they've been thinking about this. They're, as you know, they're all part of various groups and small networks. They're, they're exchanging ideas, they're collaborating. They know what needs to be done. What's stopping them is #1 there's not been a modern set of tools that has become mainstream that is enabling all of them to do it.

So that's Part 1. Part 2 is the tools need to solve for enterprise complexity, and large enterprises are mostly snowflakes. So it is also hard for software to be built where every customer engagement looks like a unique environment, right? It is a hard problem, Very hard. Problem. And then the third thing which has stopped them from doing it is because there's a lot of inertia in this practice of risk and compliance and governance and all this that has been built over the last 20 years.

And Csos have been traditionally not owned that function. That function is usually reported into the chief risk officer, the chief legal officer, the chief audit officer now are trying to inherit some portions of these function. And there's a tension in replacing manual work, humans that have invested in the job tools that have been basically imprinted into the enterprise fabric. It's hard to take these tools out. So there's a lot of inertia that they're dealing with.

And that takes time and effort to to change. Yeah, that's, that's extremely true. I mean, the, the security field is relatively young compared to computer science anyway. And the compliance part of it is even younger than the security part. You know, it's, you know, depending on the industry you're in, 25 years old or, or maybe 30 at the most. So people are still wrapping their arms around exactly how to go about all of this. And I would think that automating some of that or all of that for them can be a big kind of weight off of their shoulders of like, OK, that's one thing that I don't have to be stressed about it. 2:00 AM.

It is. And like honestly, like when I talk to Caesars, I what I tell them is I'm like, look, you guys are focusing on the wrong problem. You're focusing on compliance because compliance is being asked to you by the product owners, the product managers and your CEO because you need compliance to do business in certain verticals or certain geographies. But that's the wrong problem. What you should be focusing is on risks. Lack of compliance is 1 risk, right? So risk should feed into your compliance framework because at the end of the day, all of these are business obligations that you're making.

Me being compliant with AB and C regulations is one such objective, one such obligation. So think of everything as a risk problem, and if you can apply telemetry and automation, then the same telemetry and automation, if if you're using a product that is designed well, can point it to solving for risk. It can also point it for solving for compliance. It can point it to solving for anything else in the future. Much like the human body has one set of data, I'm giving that data to an oncologist to test for cancer and giving it to my GP for my health check, and I'm giving it to a diabetologist, right?

It's the same data. And I think if you think about things as objectives and risks in a consistent fashion, then you do the work once and you apply to many, and that helps you solve for a big problem most Sisos are having right now, which is team burnout. Oh, yeah, yeah, that's, that's a massive 1. There's a, a few younger people I know in the industry who are, I mean, like under 35 years old and have been in cybersecurity for 10 years at the most and are absolutely fried. You know, cannot, cannot possibly think about doing this for another 30 years.

Just because, you know, even in a mature security organization, they still don't have enough resources to deal with all of the issues that they face every day. They don't have enough staff, they don't have enough money. They don't have the right tools or enough tools or whatever the case may be. And the scope is changing quarterly. At best. And sometimes it's like monthly, yeah. Like I have, you know, one of the areas in our business is we help Cisos and their teams use AI to accurately complete security questionnaires. That's one of the capabilities we have in our platform. And I, I, I'm fascinated by this problem because I always feel like every startup should have a villain. And the villain in the Trust Club movie is a security questionnaire.

Like we hate security questioners. We think they should be abolished from the pace of the earth. I would be disappointed if my kids live in a world where security questioners still existed. Hey, man. But I find people to this day still their sole job in life is to wake up coming to work, turn on their computers and answer security questionnaires the whole day. Brutal. Rinse and repeat every day. You know, weekly in and out. And they have to do between 200 and 300 security questionnaires a year. Like Seesos. Some seesos I've talked to have a KPI that is measuring the number of security questionnaires a human being isn't answering manually every day. Oh God, what a tremendous waste of time and resources, that is. That's right.

That's unreal. But they have to do it because it ties to revenue, and if we don't do it, then the deal's not going to close. Yeah, yeah. How much of the conversations you're having with your customers, you mentioned AI. Thankfully, this is the first time we've mentioned this in 42 minutes. I appreciate that very much. And I mean, I guess this isn't directly tied to, to the problem you guys are trying to solve, but how much of the conversations you're having with the Csos and other customers is about the way that AI is affecting how they do business every day?

Because it's it's sort of affecting every, every aspect of enterprises these days, especially in security. Yeah. I mean, there's, there's four pillars, right? It's very simple. It's 4 pillars. 1 is AI is bringing new security threats into their business. So how are you going to solve for that #2 is AI is bringing new compliance obligations to your business. How are you going to solve for that? Number 3 is AI is bringing data and intellectual property related issues into your business. How are you going to solve for that? And then the 4th is AI is promising an improvement in productivity to your business because all your peers are doing it, so you're feeling the pressure to adopt it. So how do you prove that AI is positively affecting your business because your board is asking you to do it, right? Like those are the fourth thing, four things that they have to do.

Now there's a few more things apart from that, but I'm like bubbling up the the top four things that I'm hearing, you know, all the time. And the irony is they have to now do this, these four things while they're still brittle in all the other areas and all the other debt that they've inherited for all these years. So now there's they've been locked on, on top of all the brittleness they have right now in their business. Yeah, I think the the last one you mentioned of the board is saying what are we doing about AI? How are we using AI?

Are we putting AI into our products? How are we dealing with AI enabled threats depending on what your, your core business is. And the seeso who knows all about this is like, well, we're doing AB and C but we don't have enough money to do EF and G, you know, or or D or whatever the alphabet is. So AI is like creating more and more and more of these issues and headaches for organizations all the time. And they're snowballing, you know, to a, to a degree.

That's like the pace of that snowball coming down the hill is crazy. That's right. And I think the thing that people are not asking for as part of that conversation, and I see this because right now it's we're in the, we're, we're sort of in that phase of everything is the wild, Wild West right now is accuracy, which, which in I, I use the word assurance and impact. I think ultimately what I see the maturities was doing is they're taking a measured approach where they're saying we're not going to say no to AI. We believe it is going to change the business and we need to get on the bandwagon.

But the way we're going to do it is we're going to measure AI for assurance. So assurance means are the results accurate? Are they secure? Are they meeting my compliance, my compliant objectives? And can I have deterministic observability in like what the AI did? So in case something changes, I can go back and roll it back, right? So that's one area, which is assurance. The other one is impact. Is it really delivering the automation that it promised that? Great question is. It is it really enabling productivity or it's actually giving my team more work?

What ROI has it delivered relative to the investment that I made? Right. So like, like I used the short and I said AI is really assurance and impact is the real AI. If you can't deliver assurance and impact, AI is useless. Yeah. And the issue of it just creating more work for teams is real. That is absolutely real. And it's not just well, evaluating which tool to use or all of that. It depending on the context in which you're using it. If you're using it in a SoC, for example, to analyze incoming threats and try and triage what's happening, you still need a human person to double go back and check the A is results and make sure that what they said was a false positive was actually a false positive or vice versa.

You know it, It's not, it's certainly not a cure all in in you know, some cases it creates other issues. It does. And like AI, the modern current view of AI is still based on probabilistic models, computer science models that are built on probabilistic algorithms. And so it's not deterministic. And there are lots of use cases that require determinism. And therefore, to your point, a human has to be involved. And so like, for example, at Trust Cloud, we've coined the storm internally for our technology where we've built our own AI capabilities.

We call it Plaid, which stands for People LED assurance and impact driven. And if you can't create a methodology of that kind in whatever AI you're selling to your customers, then it's going to fail in the enterprise. Because if you don't have the people LED experience, then there's going to be use cases where the AI will do some bad things and that's going to create bad outcomes for the business that's going to affect them and you. But if you don't have assurance and impact baked in, then the AI might do bad things, but also it's not going to deliver on the value that you promised. And so that's almost a philosophy that we have at Trust Cloud and everybody should come up with their own version of the philosophy.

I think Plaid is a great philosophy, but they need the theme is correct, right? There needs to be people that it needs to be accurate and assured and it needs to deliver impact. Yeah, that's a great way of looking at it. It's a, it's a perspective that I don't think enough people have right now on when they're rolling out these AI tools and just trying to get them to solve every single problem that they have and, you know, hoping for the best. And that's not really a great strategy.

By the way, I just want to say don't get me wrong, I am all in on AI. No, I get you. Yeah, I'm. All in, I think it's going to change the world. 10 years from now, we're going to look back and get them. Oh my God this is amazing. Well, that's funny because that's kind of the, the way I was going to wrap it up was to ask you, you know, if we, if we talk again in, in a year, say a year from now, next April, how different do you think the landscape will look for, say, your business and your customers, you know, with the, the pace of change with AI right now?

I I'll answer it in two parts. I'll first start with like what I think is going to happen in the industry in general or what I hope is going to happen in the industry in general. And then I'll give you the answer specifically to trust what Trustcard does. Look, in the industry in general, there's so many companies where models are improving in parallel across multiple use cases, where we're going to live in a world where there's going to be multiple multi billion, in some cases trillion dollar markets that are fundamentally being reshaped because of AI, right?

In the last two weeks, we have seen not only what happens in software development, but we've seen what happened in vulnerabilities with the Project Glass Wing and Mythos announcements. I think we're going to see that where the entire legal industry is going to deal with a significant amount of disruption in the next 12 months. I think some part of the legal stack is going to get disrupted with AI and therefore a lot of jobs are going to get disrupted with AII. Think manufacturing shipping, like a lot of industries where human labor is involved in a lot of paper pushing. Yeah.

AI is going to take over like a lot of those things. So I think at a macro level multiple multi billion dollar industries are going to see seismic shifts happen in what AI is going to do. Now it's going to be a step one seismic shift because then it's going to take some time to bake and operationalize. But these models are going to get so advanced when people see what they're capable of, it's going to be amazing. Another big industry is entertainment, music and video. Like Trust Now is running ads around funny things. C source tell us that I then take and make into an ad and you see the ad and it looks 100% real, completely built with AI. Yeah, it's, it's impossible to tell now, even for people like us that live in this world and like are paying attention. And I'm skeptical of everything that I see now, unfortunately. But there's stuff you look at.

You're like I, I have no idea. That looks 100%, you know human to me. I was showing these ads to somebody in our network and they looked at it and said, Hey, who is this actor? We, we use the same. We have a, a Siso persona called Michael King. Michael King shows up in all the ads. So the person looked at me and said, Hey, who's this person? Who's this actor? And I look at him and go, that's, that's an AI. That's an AI characterizes really can't tell the difference.

But then you look from a trust load standpoint. So what does trust load do? We've we've built the product specifically focused on Sisos. That's all three problems for them. Number one, we give them an accurate view of their risk posture by continuously monitoring all their controls so they don't have to manually do risk assessments. That's Part 1. Part 2 is we take those same continuously controlled, continuously monitored controls and map it to compliance, and we automate all their compliance readiness workflows. And then #3 is when they get questionnaires from their regulators and their customers, we use AI to take the data of information that we have with their evidence and their controls and their policies and so on.

And we create accurate responses in a few minutes for all of the questionnaires that come by. And so we tie all that together and we say what used to be called GRC, which stood for governance, risk and compliance, should now stand from a CISO standpoint, should stand for growth resilience and risk reduction. And that becomes the new language of GRC, right? You're showing that you're growing your business. You're showing that you're increasing your resilience and therefore reducing risk.

And #3 the AI is now automating a lot of your work flows. And so you're enabling cost optimization in your business with all the automation. Like that becomes the definition of how Cisos can show the business impact of their security program by supporting growth, resilience and cost optimization. Yeah, well, a lot of CSO's need that help, you know, justifying their not justifying. It's not the right word, but yeah. Yeah, I will. I will. I have plenty of friends in that world. So, yeah, Charles, thank you so much for your time.

And this is really, I really enjoyed this. It was great hearing, hearing your background and your story and and getting to hear about what Trust Cloud is building. So thanks so much for your time. And I look forward to seeing you more and more in Boston now that we know we're. Pretty close. Absolutely. Yeah, for sure. Thanks again. Thank you for having me. Take care.