Hello everybody and welcome back to the Decipher Podcast.
I'm Dennis Fisher. I'm pleased today to have
Shravish, the CEO and Co founder of Trust Cloud with me.
How are you today, Shravish? Dennis, I'm doing great.
Great to meet a fellow Bostonian and really happy and thankful
for you to inviting me on the podcast.
Yeah, absolutely. It's my pleasure.
It's always nice to have another Bostonian on the podcast,
although I'm, I'm not in the city.
You're closer than I am. But we'll we'll definitely meet
up in person one of these days. Once the weather actually gets
nice here, we can get that done. It's beautiful and it's the mid
60s. I'll take it.
Yeah, this is this is our one week of spring that we get in
New England. So then it just goes straight
into summer. That's just how it works here.
So I wanted to start a little bit with your your background,
if you don't mind, and tell me a little bit about how you sort of
got to where you are. Did you were you like a tech kid
growing up? Were you a a computer nerd?
Like I kind of was, but not completely.
But I'm always interested to see how people, you know what, what
entry point they had to this to this career.
At Dennis, I'm a fifth generation entrepreneur.
I guess I followed a family family tradition of starting
companies. And the interesting thing in my
family is every generation really hated what the previous
generation did. And so instead of taking on the
family business, we ended up starting our own thing in a
business and in an area that was very different than anything
that the previous generations did.
And so there isn't a technology bone in my family.
I did not grow up with computers.
I did not grow up with technology.
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.