56. Kayne McGladrey, Field CISO at Hyperproof, SEC 10-K and Cybersecurity Leaders

Hello, everyone, and welcome to another episode of the security podcast of Silicon Valley. I'm your host, John McLaughlin. This is a YSecurity production, and I am joined today by a very special guest, Cain McGladry. Welcome to the show.

Thanks for having me on today, John. I've been excited to be talking with you and your audience today. We're happy to have you. Cain is the CISO at HyperPro.

Maybe you'd like to share a little bit about your background, Cain. Yeah, so I am a theater kid who eventually decided that there was not a lot of money in theater. I took my first semester of college and realized that wouldn't work. And I took the improv skills that I'd earned and parlayed that into a cybersecurity career, which is a weird origin story, right?

Most people have got degrees and stuff. And me, on the other hand, I remember doing security audits, both in person as well as physical security, as well as network security for government agencies in the late 90s. And making a lot of it up as I go along, which was exciting. I was supported by a really good team back then and have had the privilege of being supported by many good teams, as well as three mentors over the course of my career.

And I've worked. I've run worldwide professional services. I've been a CISO at a defense industrial-based company. I currently am the field CISO at HyperProof.

And my special skill that I've most recently adopted, and wasn't on my bingo card for this year, is reading investor regulatory filings for the SEC in the 10K. I can now read those in about two seconds at a crack, which again, like when I thought I was going to be singing and dancing on Broadway, none of this was on my bucket list of stuff to do. Maybe a different type of singing and dancing. This is true.

And I still am very comfortable on stage with a live audience. Let's share with our listeners maybe, what are the disclosures related to the 10K FCC regulations? So the reason I've been tracking that is most companies have had this concern over disclosing how or if or what they're doing around cybersecurity. And so late last year in October, the Security and Exchange Commission in the United States said, hey, look, you have to tell us how you're managing your risks and how the board and how management are doing with cybersecurity.

And all of the CISOs I know, and I run an invite-only CISO roundtable for about 100 close friends, and they're all worried because nobody's made a regulatory filing disclosure saying, here's how we manage our cybersecurity risks. Here's how the board gets involved. And so the reason I started studying it is it's never been done before, and there's going to be a train wreck in there. And somebody's going to do it really well, and somebody's going to do it not so well.

And the second part of that is last year, before this regulatory change went into effect, Tim Brown of SolarWinds had done a really bang-up job of helping disclose to the CSRB, the Cybersecurity Review Board, about how they had been dealing with Russia being all up in their cybers. And unfortunately, the SEC felt fit to file a civil lawsuit against Tim Brown, the CISO of SolarWinds, as well as SolarWinds, based on statements that were not regulatory in nature, like the security statement on their website, which as best as everyone can tell, was written by marketing.

So they already decided, hey, we're going to go enforce based on their alleged non-operation of security controls and what was in a non-regulatory filing. Now we've got regulatory filings by CISOs and their boards saying, here's what we do to manage our cyber risk. That sets up a really interesting narrative of if you don't disclose enough, investors might not have confidence or the SEC might not have confidence. And if you disclose too much, there was the fear put forth by many law journals that the threat actors are going to be able to figure out how you're doing the cybers and thereby attack your company more effectively, which haven't seen that happen yet.

But also there's the fear that if you disclose too much and you make a material misstatement that the SEC, if there's a breach and they decide, hey, we're going to go hard on enforcement, that they'll say, prove it. Like you said, you were running, I don't know, multi-factor authentication for all of your end users. Prove that to us. And when a regulatory subpoena shows up on your front, it's not a good day.

And so that's why I've been reading into all of these disclosures to find out how many people are going to do the barest minimum. How many of them are going to go further? How many of them probably got, I hope they got a sales discount from their vendor. Cause I can think of a couple that like mentioned specifically who their vendors are, which is an interesting thing.

What is some sideways avenue of marketing or exposure to risk? I can think of one that specifically said we use Microsoft Azure for our entire tech stack all up. And another one mentioned who they had for EDR and who they had for IR and doing a variety of other technologies. All of this is going to produce for a very interesting regulatory and litigation space in 2024 and beyond.

Because a filing that's made right now, it exists in perpetuity and it's a public record. A lot of the listeners are founders themselves, or they work for startups in the security space. And if I'm one of these founders in a security startup and I'm part of one of these companies supply chains, or I'm a vendor to one of these companies, what does that really translate to for me? So there's two parts to it, I guess.

I'm going to oversimplify. The first is that most startups want to eventually either get acquired or exit via PE, or they want to go public. And so if you want to go either of those routes, your institutional investor, your PE, or alternatively the public market are going to want to see that you are doing the cybers in a reasonable fashion. Now, we're not talking about like the reasonable cybersecurity standard, which is still not a litigation or legal standard, but they want to see you have, you look like the other companies that are doing cybersecurity.

And there are about 11 factors that I found that came across all the most robust 10K Section 1C, and the SEC only requires four of those. So companies have really been disclosing more as a way of assuring investors. And so there's 11 topics, and you have to be prepared to talk about those. But the other thing to keep in mind is that if you are, maybe not, this is not your year to go public.

Okay, cool. Do you share a board member? Because if you share a board member with a board or two members who have also sat or currently sit on a publicly traded company's board, they're going to be asking these same questions. They're going to have these same level expectations because for them, this is their new normal.

And I think that's going to end up throughout the entire ecosystem of startups and suppliers who are not publicly traded currently as board members and institutional investors start thinking, this is normal. Everybody talks about these things. This is just an expected disclosure that we'd see everybody would make. And if you can't make that, or alternatively, if it's very unpopular within your industry cohort, generally popular, if you're not, if you don't have that left-right visibility for what the middle of the road looks like, you're going to have a bad time, I suspect.

Yeah, I suspect so too. In terms of an action item that you would suggest that all of these security vendors and these startups like maybe take on, would that be something along the lines of, would SOC 2, type 2, help them get over that bump? You mentioned there's 10 or 11 of these 1C disclosures and you only have to pick four. But SOC 2 is not going to be, it's not going to cut it.

Yeah, so I've got a blog post up that will be up after this podcast is finished recording about those 11 factors. And we will definitely link to that in our description. So that's fantastic. But these go beyond things like having a SOC 2 or an ISO.

That's part of it, though. So, for example, one of the top factors is use of literally any cybersecurity framework. Don't care which one, NIST-CF, which in one case was called the NIST-CFS, and in several cases was just called the NIST framework, comes up quite a lot. And the reason for that is that companies are using that as a proxy to say, we know what we're doing because we're following an industry standard.

But another section that comes up there too, beyond just a framework, is governance. And that's a broader topic of when something happens, who knows when, who tells who. And some of these are tremendously detailed disclosures. Some of them are a little lighter on details, but it has to be included in there.

That's something that the SEs did not require. Same thing with frameworks. If you think of something that they did require was, how are you managing your cybersecurity risk? Okay, cool.

You look at the Section 10, what is it, Regulation 106 or 108SK. Anyhow, they have required disclosures. One of them is risk assessments or risk management. Something nobody expected would be in there, but is very much in the cultural zeitgeist of cybersecurity right now, is third-party risk management.

And companies are spending an inordinate amount of time disclosing, to the point that I've seen companies, I don't want to do business with them. If we have an opportunity to win them as an account, no, because they have an 11-step process that involves, and I think in one case, even if you've got an ISO 27001 certification, as well as your SOC 2 Type 2, they will send you an auditor to audit your organization in four hours. Because somehow they think they're going to do better in four hours than ISO 27001. And a SOC 2 Type 2.

Ah, yeah. So there's some disclosures in there that are just pure nightmare fuel. But my point is that companies have prepared to talk about this, and they also have to have the confidence that what they're disclosing is factually correct. Because the thing you don't want to get caught out in is running a paper tiger, where it works that way on paper, but it doesn't actually exist in reality.

I think that's going to be a bad time from a litigation and enforcement perspective. Again, I'm not a lawyer. I'm not making legal advice. No, neither of us are lawyers.

But I would suppose that hyper-proof, if you use that as a product and you have that high-level visibility and you have the constant reinforcement that the controls are being audited daily, continuously. Continuously. I think that makes a big difference. I think of, there was one cybersecurity disclosure from a company, and they made up a framework.

They just full-on made up a fictional cybersecurity framework, and it's in their public disclosure. I won't say who. And all I think of is, if they'd had hyper-proof, they would have opened their dashboard. They would have seen the programs they had.

Boom, done. Job done. Easy. You need to prove that you're actually collecting evidence on an hourly or a daily basis associated with the control operation.

Job done. Again. So that's really limiting that regulatory and investigative risk associated with the material breach. But also, if you think about it, if you're actually checking to see if your controls are running, like I as a CISO, that matters to me.

I want to know if I'm paying a vendor money for a thing, a service. Maybe it's EDR. Maybe it's something else. Maybe it's SOC as a service, right?

They're doing a security operations center for me. They're looking at my SIM. I want to know that the darn thing works so that I keep paying the bill and being able to have that continuous inspection and confidence, and then being able to report that up to my board and to my investors. I think that's really essential in today's world to really limit the spread of the risk associated with data breaches, which is, funny enough, one of the things we found in our 2024 IT survey, where we found companies that took that automated, that continuous assurance approach towards their GRC platform, or towards managing risk, I should say, had a substantially reduced risk of having a data breach.

And it's not correlation. It's not causation. It is correlation, I should say, where we're not saying this is absolutely a way to avoid the risk of a data breach, but it makes sense. If people are looking at the same thing, at the same set of facts, they're going to make way better decisions than if they're having to chip between three or five different Excel spreadsheets to figure out how we manage our risk associated with this today.

And this is being reported up to the board of directors. And the board of directors is essentially allocating resources to the company at the leadership level, right? And making decisions and judgment calls about how much more investment to be put into security. If you're on one of those boards, how can you tell a paper tiger from the real deal?

I think that's really challenging. And what I've seen effectively work with boards isn't what we've been doing. I think a lot of us as CISOs have been guilty over the years of, first of all, saying that cybersecurity risk exists. It doesn't.

We have business risks. We manage business risks. Cybersecurity is certainly a factor of business risk, but it is not itself a risk. Controversial opinion, I know.

But the other thing we've been doing is we've been failing to tie to business objectives. As we talk to the board, what matters most to them is their KPIs, key performance indicators for the company. If you, as a cybersecurity professional, head of securities, CISO director, whatever your title is, as you're preparing that, what is the business leader's KPI by which they are measured? And then you need to tie a KR, a key risk indicator to that.

That's a way to get board engagement. So a good example that comes to mind, risk of data exfiltration, right? Let's talk about how many people uploaded stuff to Google Docs or Dropbox or put in a USB disk into their computer. You put that in front of a board, it's a snooze fest.

They wonder, why are you here? Why are you telling us this? We don't care, but if you take the strategy of maybe HR has a goal of saying, how happy are our employees? What's our employee satisfaction?

We know as cybersecurity professionals, people about six weeks before they dip, about six weeks before they decide, I'm done, I'm leaving, I'm going to go look for another company. They exfilt all their data, whether they're a salesperson, their book of business, whether they're an engineer, all of their code that they've got in the repo. They take it all with them and then they leave in about six weeks. And so if you're talking to your HR professional about their key performance indicator of, I want to make sure the employees are happy, we've got a key risk indicator.

If you want to say, talk about data exfiltration, it's a leading indicator for how that point is going to go. We need as leaders to think of these intersectional points where we can bring in the data we have and use that to enrich the larger organizational viewpoint of how successful the business will be. I love tying security back into the business because you can do security all day long. You could have any budget under the sun and you could burn it all and still have business risks at the end of the day.

But it is a very controversial opinion. You can't let good be the enemy of perfect in cyberspace, just as any space inside of a business, engineering, HR, sales, whatever. But especially in cyber, it's tempting to get drawn into the perfect image of like perfectly secure systems. And I would argue that those don't exist, that there's always going to be risk and that we have to navigate that risk.

And to help us navigate that risk, you have to put on sort of the lens of the business. What does the business need at the end of the day? And I think like most businesses are interested in growing. I know that SOC 2, type 2 often is like the go-to growth mechanism.

Like, look, we're taking our security maturity and our operational maturity seriously, like indicator. As you get into those larger companies, I'm happy to hear that people are carrying all this. And that things are changing. Sounds like they're changing for the better.

The other thing is actually getting business owners to buy into cybersecurity. Something that's come to me from a few friends or CISOs is the traditional risk assessment risk decision of how are we going to manage this risk? So we've identified a risk. The risk is above our risk tolerance threshold.

We send the risk form over to the business leader and we say, here, sign this. And they say, cool, I accept the risk. Job done. Nothing changes.

And then we wonder why are we continuously living in a dumpster fire? And I think the CISOs that I know who've made a difference in this space, same basic process. You identify a risk. It's above the threshold.

You go to the business leader and you say, hey, there's this risk. Do you want to accept it or do you want us to work on mitigating this together? And they say, I want to accept it. Cool.

So you're going to pay for the insurance on that. And suddenly the narrative changes drastically because if, and this is happening at several companies that I know and have friends at, they say, wait, you're telling me I'm going to take a five to six figure loss on my P&L for this quarter to buy incident response insurance and remediation insurance against a risk. Depending on the size of the business, that will suddenly drive change. For a business leader who might have been reluctant, who you might have, as a CISO, you might have went to the board and showed, look, here are SLAs for how long bones and wrists can be open.

And this one department does nothing. If they're just printing money all day long, the board's not going to care. But if you can create that recognition that there is a cost here, if you can make them own that cost, it makes them more likely to engage and more likely to, whether it's get rid of a legacy system, whether it's actually patch their Mankey systems, whatever it might be, it provides an incentive that they can understand and take ownership in. Because if their KPI is financial performance, cool, let's tie this risk to your financial importance.

Because if the risk were to be realized, think of like a ransomware incident, for example, those seem popular these days. It's going to affect multiple aspects of the business, including theirs. So for them, I won't say it's necessarily meeting the standard of due care, but it certainly feels adjacent to saying they at least bought an insurance policy against that happening. Or paid into the main cyber insurance policy rather than just YOLOing it and figuring, we're just going to keep doing business.

And this cyber person can talk to us about some technical thing. I don't know what he said. Big deal. And then three weeks later, they have a material incident that affects everybody.

I think we can move towards avoiding that by getting, again, that partnership. Even in that case, if it's a bit draconian and saying, look, you have to pay for an insurance policy. It's working, right? And we have to have that level of engagement with other business leaders.

No, I love that because you're not owning the risk. You're not performing risk transference as a CISO onto the business decision leader. You're actually transferring cost, like the actual cost of cost and ownership. You're owning the cost and not just the risk.

Yes, that's incredible. And it's all just in positioning and how we talk about these things. And as business leaders, as security experts, we have to have that business perspective to get traction sometimes. Yeah.

And it's also necessary when you're scoping a risk. There's this fiction that CISOs can magically use something like FAIR to figure out how much a risk will cost if it becomes an impact. Right. And I don't think that's true.

And the reason I don't think that's true is as a CISO, I can ask the salesperson, the sales leader. I can ask the engineering leader, how much does this thing make on an hourly basis? But I don't inherently know that myself. I don't have that sense of how much money happens in a given quarter or how much cost happens in a given quarter.

And I think when we're doing our risk assessments and trying to do an impact analysis, we have to take a collaborative approach with other business leaders at our organizations. Because otherwise, we're throwing a fictional number in front of them and they could be like, where did this come from? A legitimate question. What is this?

It absolutely is. And so I think that ethically, we as CISOs and security leaders don't have the ability to put forth a material number. And this is especially in light now of what the SEC is doing around materiality, bringing it back to that, for us to make assertions that aren't based on facts. I think if we're going to do an impact analysis, let's partner with the business to figure out what is the potential impact there, as opposed to just wet finger in the wind and making up a number.

So do you have a favorite disclosure going back to those, the C1 disclosures? Oh boy, there are a few that, so if you follow me on LinkedIn, you'll see a whole bunch. Your LinkedIn, I just have to say, is hilarious and so much fun to follow. Everyone should follow it.

The last one that I saw was like the bear reporting, sad bear sitting on the park bench, who said because he reported some noncompliance thing, but the FCC already knew about it or something. Yeah, that was about the DOJ whistleblower. But I'm trying to, here's the thing. I am a former Twitter, now whatever it's called.

I was on that platform, got really good at my meme and cat gif game and, or cat gif game. Oh God, I'm going to start that war. Oh boy, do we just open that? Twitter just ruined everything.

And I'm bringing that same mentality of LinkedIn is way too serious. I inherently talk about serious, dull, boring things. I read way too many law journals and I'm reading regulatory filings for fun. How do I at least bring a little bit of interest into that?

So when I think of ones that come to mind, follow me on LinkedIn. There is a wine company that I'm pretty sure is one of the worst that I've read. There's the whole category of SPAC, special purpose acquisition company, where they just don't do cybersecurity at all. They say they don't have a cybersecurity program, don't plan on having one.

It's also known as a blank check company. I had to look up what the heck that is. And then there are a few that I've seen where one of them said, it was this wonderful circular reference. They said that they were required to disclose these things by the SEC as said in, as by the regulation.

It would be in section 1C. And then they listed out all the regulatory requirements that they had to meet. And then they said, for more details, see section 1C. And the whole time I'm thinking it's for more information, reread this poster, right?

There's just no information in there. It becomes a circuitous, or a couple of them have been combative in nature where it's forced by the SEC to disclose these things. Okay, great. Do you think that's going to really go well with the, now I know there's an SEC staff attorney who is reading my analysis.

I hope this gets in front of them because I'd be curious to see their take on how companies are reacting to this. Because some are welcoming it. They're being very transparent. And others, like I say, especially the combatively toned ones, I can't think that's going to go well.

Was it a technology? Was that a technology company? The one that's a little bit combative? Several of them.

Tech companies, actually software, and SaaS providers tend to be some of the best written. I think the only ones that are more comprehensive are in the aerospace and defense space. And rightly so, admittedly, I do have a personal bias in that I was in A&D. However, I think that the software companies and SaaS companies are doing a really good job.

They especially are likely to, it's funny, I've talked to a lot of CISOs who suggest the concept of let's have a risk register. And the company they're at goes, that's a neat idea. We never thought of that before. And you wonder, like, how did you get so far as a grown-up business, presumably run by adults, without having a risk register with the stuff written down?

And CISOs are bringing that in. And they're in these tech companies now where you see they have some of the most comprehensive disclosures around risk, around governance, around board level in intersections. Where they're actually communicating with the board, they disclose how those happen. In some cases, they're even bringing in external expertise, so consultants, to advise the board on additional matters where they're really leaning in hard.

Whereas other, I think it's the oil and natural gas field exploration category. I don't know if they know cybersecurity is a thing. But then again, if you think about the oil field business, actually the whole oil business, I used to try to do risk assessments for those companies. And making money their way out of anything of less than, I think, a quarter billion dollars was sort of their risk threshold.

It's like anything above that line might be a business risk. We'll get back to you. So you try to raise cybersecurity matters. No, it's making money their way out.

A lot of space to absorb risk. A quarter billion dollars, huh? Yeah. I guess a million dollars is not a million dollars anymore, but still.

And for these companies that. . . Okay, we'll leave that one to this side.

But for these companies where, you know, they're like, oh, the risk registry, that's a nice idea. That's a very nice idea. Maybe we'll do that at some point. Part of me is with you and definitely is, how did you get to be so successful and so large without just the basics?

Like, are we still teenagers here with running the company? But in another sense, like, we're always learning. We're always growing. And maybe they just didn't have the right person with the right expertise at the right place at the right time to help them nudge the group, the organization.

It's funny. I have this view of companies are just groups of people, right? We get together. We want to change the world.

We want to make a better product. We want to provide a service to our fellow human being. And you get together and you do something useful that's also useful for another group of people. And there's a certain type of responsibility that you have to the folks in that company, to the folks that you're servicing, whatever your product or your service.

And I'm always willing to give people the benefit of the doubt that people want to do the right thing. It's just that our life experiences, they can be so different sometimes. The answer to that question, like, what is the right thing to do, will vary wildly if you have a diverse group. We all enjoy each other's diversity.

But in that sense, you're going to get a lot of different answers. And standards are nice, right? Standards are nice. The C1 disclosures are, there are certain things that we just don't want to have to reinvent over and over ourselves again.

In cryptography, for example, like you have this rule number one in cryptography, do not invent your own cryptography. Just don't do it. That is very true. It goes to an area that I've been working on for some time now, which is the concept of a maturity model for governance, risk, and compliance.

And the reason that I've been doing that is I talk to a lot of CISOs who GRC ultimately reports into them, and they know what they're doing, but they couldn't tell you how to get better at it. And if you think it's cybersecurity, we have maturity models. Well, we have many maturity models, ultimately, of varying qualities that give us a sense of how do I get better at this thing? And yet GRC has become this intractable space where it's a cult of personality.

If you have somebody who's been at one of the big four companies, maybe they were a partner or a senior partner, or they were on track to be a partner, they probably have a very well-rounded view of how do we do governance? How do we do compliance? How do we actually manage this? And how do we make it better?

But if they don't, they've got somebody who's well-meaning, but their life experience hasn't shown them what good looks like or what bad looks like. They just know, how do I meet the standard that was established? And the challenge then becomes, those companies don't have a path forward. And so when they want to do something, maybe they're a startup, they want to go get a SOC 2 Type 2, and they don't know how to do it.

Or maybe they don't want to go get an ISO 27001, or whatever it might be. And it becomes very difficult for them because they haven't had those experiences, and they haven't built that organizational muscle memory. So something that I've been working on towards that is a maturity model where instead of saying, just do governance better, because that's like saying, be healthy. That's like saying, I don't know, have better relationships, right?

You've got to be more specific than that. What is be healthy? Does that mean eat better? Does that mean be better at sport?

What is the specific thing there? Trying to say, what is inside of the sphere of governance? What are the core business processes, and what are those core outcomes? And within risk, same thing.

What are the core things? Why do we do this? How can we actually get better at that? I hope to publish something later this year in this space, because I think without that, I think that there's going to continue to be a lot of flailing, well-intentioned flailing by people who don't know that there's a better way.

But where that comes to concern for me is, as a person who has a lot of friends who are CISOs or senior levels of senior leaders in security, the amount of civil risk that we carry becomes a big disincentive to staying in the career. If you do not have DNO and if you don't have indemnification and you don't have an umbrella policy, which I just mentioned, that's a whole whack of insurance just about your job. Because of mental health reasons. I cannot imagine that got better in 2024 with the SEC now saying, yeah, Section 1C is a thing.

You all need to file this out. And Tim Brown's going to have a bad time also. Right? So the intent of me working on this space is to give people that discipline and that peace of mind so that as they realize this is a risk to me, this is a risk to my organization, how do we get the organization's maturity level to improve?

So that not are we only more resilient as a business, not are we only more effective as a business, but also that our senior leaders don't just panic and dip one day because they realize, ah, this job sucks because I could go to court just for showing up. Yep. No, and I think I speak for many of the leaders out here. Thank you for the leadership too.

All the gratitude in the world for stepping up and providing some foundation for this. And perhaps even that group of a hundred, I'm sure, shares a huge debt of gratitude to you as well. They haven't received the draft document that I've read so far. They haven't received the draft document?

Okay. It's about 180 pages so far. So a few of them have said, I'd love to read it. Now, okay, cool.

It's currently like I'm doing a final editorial scan. It's early days, but I'm hopeful because the world we live in right now, I think about it when I first got into system security, when I first got into this space, like I said, I transferred over from being a theater kid. I had no idea what normalcy looked like. And I do not think that I would have chosen this career if I realized the amount of social pressure, the amount of economic pressure, the amount of litigation and the amount of personal liability that our professionals pick up in this job.

And it's not got any better. Right. Right. I didn't think that I'd be like, when I got into this, that I'd be reading regulatory filings and litigation and jurisprudence, which is a $5 word.

I didn't think this would be my day job of advising companies how to avoid these things or how to better think about them. And as we've seen, because of, and I get the sense there's people at regulatory agencies who are just frustrated, who aren't seeing progress. They keep seeing people's personal data getting breached. They keep seeing the transfer of funds from Western nations to Eastern nations, not to call Russia what it is, but just to name drop some Russians there.

Right. I think there's a level of frustration. And so the regulators are becoming more prescriptive and I get the sense that's not going to change. And so what can we each do?

What can I do? What can we each do within our community to try and make that a little bit better for everyone? Yeah, exactly. That's a mark of a real leader is that you're helping the community.

You step back and you look at the bigger picture and you go after large problems that are not just specific for your company or organization. And so recently you actually presented Hyperproof's fifth annual IT benchmark survey. And I noticed that one of the more interesting statistics to come out of that was that nearly half of the companies struggle with identifying critical risks so that they can prioritize the remediation. Do you think that's an indicator or why does that matter?

So I think that is a product of how companies have not had risk management discipline beforehand. If you think of my earlier remarks about how could companies get to be a grown-up company with business leaders without having an actual risk register. But it also comes down to those companies that have got five risk registers or they've got 12 risk registers. Everybody's got their own personal risk register.

And depending on the type of business, okay, sure. Like at a very mature, at a global defense company, I would expect to have different risk registers with certain controls to prevent people from seeing certain stuff because that's just the nature of the beast. But at other companies, no, not so much. The inability to find critical risk information really informs not only business strategy but also insurance and also career frustration.

If a CISO is in a risk conversation and they are not privy to the fact that the reason they didn't get budget is because their company has decided to do a global expansion and that's where they're putting their money, that CISO is going to be frustrated. Right? Or alternatively, if there are five business units and each one has its own different risk register and they also have their own different way of measuring risks, again, you get frustration when people are trying to prioritize it. When I used to do executive advisory work, one of the first things I'd ask folks was if they could show me in writing what a low impact reputational risk was or a high impact regulatory risk.

Don't tell me verbally. The software that engineers tend to write will reflect the communication channels within the company. And so the pieces of software that are connecting and working with other pieces of software, they reflect like the people that are actually talking to each other. And this discussion around risk and do we have a common language around our risk registry and do we have one central point where we go for our risk registry?

It feels like there's maybe a colary to that, the communication channels just within a company. And so this goes back to organizational structure, right? At Apple, there is a profit. And when this profit speaks, everyone listens.

And it's held as a spiritual, non-questioned, like here's the direction that we're going. That's Apple communication style. So it's very top down, very flat. But in a startup, you have tons of people just running around doing whatever needs to be done.

And you have something in the middle for all of the companies of middle size and different communication channels. And sometimes you get people that are building like little empires inside there. They're part of a company that go to war with other parts of the company or little pieces, little arguments, whatever. And I'm sure that all of those internal politics just bubbles up and you get something.

You get something in terms of your product, your engineering, the code and how it works. You also get something in terms of risk registry and risk language. Have you noticed that yourself over the years? I have, yes.

I've been brought in to companies to conduct assessments and to determine how they got to where they were and if there are ways to improve it. And often it comes to communications channel breakdowns or it comes down to expectations breakdowns. If there's an annual risk assessment process and only 20% of the company knows about it, how well of a treatment of your risks do you think you're going to have? Or if there is an agreed upon means by which you can transfer risk and nobody's actually following the form and they're just making it up as they go along.

Right. Again, these, what I do sounds very boring. I'm talking about committee meeting notes, like making sure that there was a committee meeting note that said, here's a person who agreed that they were going to mitigate this risk. And here's another person who said they were going to transfer that risk to insurance.

The funny thing, though, is if you don't write it down, often things come down to the old Cluedo board game. Professor Plum in the library. Oh, yeah. That's what investigators always come back to is who, what, where, when, how.

And it's always around risk management. And if you don't have that centralized repository of evidence, what I've also seen is that companies that lack that discipline of just writing stuff down and keeping it a central location, when they have a breach or when they have a material incident, when they have a serious thing that goes on in their cybers. And they are subject to not only incident response investigation, but also the legal investigation. Their engineering time gets consumed by everybody coming in after the fact and asking, show us how that control is operating.

And they're getting it from at least two spaces. They're getting it from the legal team in preparation for future litigation. And they're getting it from the internal incident response team to try and figure out what was going on at that point in time. And if that's not written down, if that's not consistently maintained, and again, it just comes down to, like, people talking and people agreeing, we should write this stuff down.

Be helpful. Have this stuff. You end up with wildly different outcomes. Something that we're also working on at Hyperproof is a FedRAMP.

And you want to go through a documentation exercise. They will have you write everything down. Like, you think of engineering code changes and how a code change cycle goes. They are very prescriptive in terms of what has to be written down, how it has to be written down, how often it has to be maintained, how long you have to keep those records for.

And when companies, startups are thinking about, how would I go get federal compliance so I could sell to an agency? Right. It becomes this very difficult challenge to meet the documentation requirements if a company hasn't already got that discipline built in at a lower level for a commercial market. Or if you try to go get ISO 27001 or any of the other ISOs, honestly, they love their documentation.

Right. You have to have that evidence that you're doing the things you say you're doing. If there's not that culture built in, some pockets of an organization might be doing it, but not everyone consistently. And unless you're at a large enough company that you have a subdivision where they're trying to get GXP or they're trying to get a FedRAMP or they're trying to get an ISO or whatever the thing is, usually it's an assessment of the entire company's business process.

And then you really start to understand how effectively your message has been getting out there or how effectively you've been doing organizational change management to get everyone to adopt this new way of working. It makes me think about the two main structures that I've seen around security is one of them is to have a CISO and the CISO has an entire org underneath them. And you have product security, you have infrastructure security, you have corporate security, you have governance and compliance in there. You also have maybe a red team as a feedback loop, but things are happening.

You want to double check, provide evidence for it. And it's all under one org. And then with leadership, you have a healthy tension, I would say, with all of the other pieces. The other way I've seen companies organize security efforts is more distributed, where your product security is going to be lodged somewhere inside engineering and your corporate security is going to be underneath IT.

And I'm not even sure where the red team ends up in an org like that, maybe over with the engineers in product security, but they would get landed out to IT for IT stuff. And for your devs, you put them in infrastructure right next to the DevOps folks. I guess there's pros and cons to each. And given all of these new regulatory requirements, is there one structure that you think might serve a CISO or serve the public interest like a little bit?

I think both of those are viable. What ultimately matters is ongoing sustainability and observability and transparency. So if you have a distributed security organization where every department has some aspect of it that is responsible for their own security or whether you've got a centralized security apparatus, I think what matters more is that you have a way of proving it. And when I say proving it, I want to be clear.

If you were being investigated as part of a legal investigation, could you prove it? Because if you can't meet that legal standard, and it is a high standard that I advocate for, then you're eventually going to have a bad time. Because you can say, yeah, we totally do that. You can have somebody on the record say verbally, we totally do that.

You can occasionally go and collect log files or screenshots that show you're doing the thing you say that you're doing. I think the way the world is moving right now, just to the amount of litigation we see, you have to have that continuous inspection of control operation, whether or not that is a central apparatus or a decentralized apparatus is immaterial when it comes to litigating. They don't care how you structured your company. That's really not that interesting.

The SEC, they don't care. They just want to know what you're doing. A lawyer does not care about how you structured your company. And so to ensure defensibility, you have to make sure that you have a continuous view of what's happening where, and it has to be transparent.

Because otherwise, a smart investigator, and that's whether they're an insurance investigator or a litigator, is going to look at the gaps. Let's take this to a very simple example. Let's say you have a policy that says you log everybody who comes in your front door, you hand them a guest badge. And at the end of the day, you get those guest badges back.

And you have all the records for every day except for Thursday. How's that going to go for you when the investigator, whether they're your cyber insurance provider or your adversarial counsel, they say, so what happened Thursday? And you go, I don't know. Right.

Right. They're going to immediately focus in on that. Whether or not anything happened on Thursday is not really of interest at that point. It's that you don't have the evidence to support the argument that says that you were doing the thing.

And then if you take a step back and, say, look at a program like FedRAMP, where it's not a compliance once a year type operation. It's that you are in compliance at a continuous basis. And if you don't, you're going to get locked out of seven and eight digit contracts. Painful.

Right? Yep. You have to be able to prove you have a continuous assurance process. And I think that as companies look at these opportunities, the advantage, as you start thinking about cybersecurity, you can weaponize it.

You can say, this is actually a strategic advantage for us, whether it's your SOC 2, Type 2, or some other external attestation. You can demonstrate to your customers, to your supply chain, that you are more secure than the other alternatives in the same marketplace that you serve. Thereby, you're probably more trustworthy than your competitors. It's a market distinguisher at that point, right?

It is. I think at some point we're going to hit table stakes where everybody's got a SOC 2, Type 2, right? I think that's going to be just the norm. That's right around the corner.

Everybody will have that. And it's no longer a market differentiator. It now becomes a blocker to get into a market. I was looking at all of these crazy little AI startups that are just popping up in the market and they're getting tons of $70 million seed rounds.

Am I just unveiled itself and it had an insane seed round and they're coming to the tables with a SOC 2, Type 2. I'm like, what? They came out of stealth with a SOC 2, Type 2. I'm like, wow.

I see it very quickly becoming table stakes and not just a nice-to-have-our-market distinguisher, especially for folks that are going after larger, larger contracts. But one of the questions that I often get from founders, and this is not like a founder of a security company. This is just a founder in general of a growing organization. I would love to hear your take on this as when is the right time to pull in a CISO or a security leader?

I go back and forth on this one, and I think it's after your Series B, unless you had a real banger of a Series A. I think it's your Series B, maybe your Series C is when you start really thinking seriously around bringing in a security leader. Be responsible. Because there's some other things that have to happen in there that often won't have happened before Series B.

And it's things like having DNO, Directors and Officers Insurance, making sure that your board members, making sure that your senior leadership team, and then as a way of incentivizing that CISOs will actually want to join your company, that they will be on the DNO, either as a named individual or by rule. I really don't care. But if you're not offering them a DNO spot in today's climate, they have really no reason to join your company. That becomes actually a reason to not join your company.

Huge liability, yeah. But also there's a certain amount of engineering product that has to be out there. There's a certain amount of organizational function that has to be out there. I think a lot of the other business functions need to be built out before.

This is funny. I'm not saying security is an add-on, but I'm saying centralizing the responsibility for communicating and overseeing the operation of the security apparatus. I think that a lot of well-intentioned people can get you to a Series B. Maybe you have a couple of hits and misses here.

That's fine. Everybody does. Companies with CISOs have hits and misses. It's not a guarantee that you're going to have a perfect day every day.

But I think that you need to have that organizational discipline. And also understand, what is the company trying to do? Because unless you're at a cybersecurity company, your business model has to prove out, too, before you bring in somebody to do security. Right.

You need to have something worth securing before you dump a bunch of investment on top of it. Yes. Exactly. Great discussion, Cain.

Thank you so much for joining. Would you like to leave our listeners with any final words of wisdom? Boy, words of wisdom. I think you said it earlier on the show, John, and it's really about giving back to the community.

It's about finding ways that we can help develop and diversify our community and bring in different ways of thinking into what has been a challenging space and a challenging few decades that we've had cybersecurity. I think that if you're a senior leader and you're listening to this, the thing you should be thinking about is how do I give back effectively and how do I incentivize people to get into this industry? Because there are a lot of reasons to get into our industry. There are a lot of different skills that we need.

There's a lot of different ways of thinking that we need that are not really well represented today. And so if you have the opportunity to influence a young person or influence somebody who's going to change careers, absolutely take that, whether it's one-on-one or whether that's en masse. Beyond that, if you're interested in HyperProof, check us out at hyperproof. io.

If you're interested in me and my meme game on LinkedIn, I'm Cain McGlattery on LinkedIn. There's only the one of me. Thanks, Mom and Dad, for the unique name. You'll be able to quickly find me.

Yeah, we'll link to your profile and all of that in the description of the podcast. And a huge thank you to all of our listeners for tuning in to another episode of the Security Podcast in Silicon Valley. I'm your host, John McLaughlin, and this is a YSecurity production. Thank you so much, Cain.

That was amazing.