Transcript.

Erik: Justin, welcome to the podcast.

Justin: Thanks for having me. It's a pleasure to join you, Erik.

Erik: So, you're up there in the misty Northwest where I was also born. Were you born and raised there, or you moved there?

Justin: No, I was not born here. I'm originally from Atlanta, Georgia. That's where I grew up. Through multiple companies and relationships with great colleagues, I had the opportunity to move to the Pacific Northwest about six years ago. I've really enjoyed it. Certainly, the great outdoors is beautiful here. Really, a great tech industry ecosystem for startups, and the type of work I like to do as well.

Erik: Yeah, that's right. It's a great city. I'm sitting here in Shanghai. I haven't left China in four years because of lock downs. I'm very much missing the mountains of the Northwest right now.

Justin: Well, it would still be here. You've got millions of years, Erik.

Erik: That's true. Yeah, that's true. I just have to make sure my knees hold up. Well, you've got a fascinating background. I don't know how many tech companies you've worked with, but you've really covered the gamut here. I would love to understand how you convinced yourself to dive into this particular topic. It's always interesting talking to a founder and understanding what was it about this particular problem of security and compliance that excited you and led you to set up Strike Graph.

Justin: Yeah, I certainly am a little bit of a serial entrepreneur. One of the things you're always trying to be aware of, is problems in the market that you're dealing with, your colleagues are dealing with, that you think that you could solve.

Before being a CEO, I typically played the role of Chief Technology Officer. I was at a startup here in the Seattle Washington area about six years ago. We had an AI product that would predict the likelihood a job applicant would be a high performer. To power the most accurate models, we needed a fair bit of data. Our target market was Fortune 50 businesses that had a lot of employee data, so we could build a model and match the right applicants for the job.

When we started selling our solution, we had a real problem that we didn't predict but realize that we were struggling with. That is, all of a sudden, companies sharing data with us. These employee data were super sensitive about our security posture. So, we got into this really difficult situation where we get a verbal agreement to buy our product, but they're always taking 18 months and sometimes longer to get to a signed contract. So, we couldn't grow the business fast enough to attract new capital to grow it.

I really struggled with the problem. As a CTO, we'd always implement a good security. But I'd never been challenged with how do I communicate that good security practice in a really efficient manner so that buyers that are looking at us can gain a sense of trust for our solution — the way we care for the data, and the way we care for them — really quickly. That's how I really got interested in the problem area.

I'm not a compliance swank. I'm not an ex-auditor. I'm not a CSO by trade. I'm maybe a practitioner who really realized that this was an intense business challenge, and also realized that all of the companies that my peers were working at, and I had worked at, needed to share data to power our products. So, this is going to be a broad issue.

Erik: It's fascinating. We have a partner in North America. Just about three weeks ago, they lost a project because they hadn't had a cybersecurity audit. This is a consulting firm that's doing basically market research and strategy work. This was a long-term client of theirs who decided, at some point in the past couple of quarters, that all of their vendors needed to make sure that their cloud and so forth was secure. Because they hadn't actually been aware of that process, they lost this bid.

I think that illustrates how widespread the requirement is now. It's not just for SaaS companies. For some industries, any vendor, basically, is going to need to pass some degree of compliance here.

Justin: Yeah, that's right, Erik. I think one of the statistics to understand about why that's happening is, about 70% of major data breaches are coming from third-party vendors, even if it's just a laptop with a list of clients on it. That's why buyers have gotten so sensitive about this particular issue. It's a huge security surface area that can result in a really big data loss.

Erik: When we're talking about cybersecurity and compliance, what is the landscape that we're talking about? Because I guess you have all these different infrastructure nodes, and then you might have also internal policies. I guess there's the technical aspect, and then there's the process or the human aspect as well. So, what would be in scope in this landscape?

Justin: One thing I learned as a CTO that I didn't understand but now I do much better — especially having read many of the compliance standards that people are going after — is really only about 40% of the standards is what I would call cybersecurity specifically. The standard coverage, much of it, is on business operations characteristics.

Certainly, the most common standard in North America that we see customers are going after is SOC 2. They will have portions of the standard. That is, how do you manage data? Is it encrypted? Is there a firewall in front of your servers? Those types of more traditional cybersecurity challenges. But then, there's a whole slew of things that are, what is your onboarding and off-boarding process for employees? What is your process for board transparency?

I think that the way that we think about that security posture is really a control-centric design. Controls are just really small statements about some type of security habit or activity that you're going to implement. For example, you can have a control that says we're going to encrypt our production database, or you could have a control that says we're going to have every new employee sign an acceptable use policy, so they understand our requirements around use of devices and laptops at our company. That has a lot to do with the scope of practice.

The way to think about compliance here, there's two different types of compliance. The more traditional one is what I like to call liability compliance. A great example of liability compliance is HIPAA. You can state that you're HIPAA compliant. You don't have to get tested for it. But if you are not, and you are found to be not, you can be liable for a lawsuit. So, your lawyer is going to say, "Hey, this is a liability. We should be concerned about this. We should meet the compliance."

There's another type of compliance that is more around sales. That is the standards we hear about the most are SOC 2, ISO 27001, PCI DSS, where you're not going to be able to win deals in the marketplace if you haven't been audited or certified against these particular standards. Those are the ones that we solve for our customers the most, because they're a revenue issue. So, there's a real desire in the marketplace to go out and accomplish these particular compliance standards.

Erik: I guess we can look at this from a number of different angles. But maybe one place to start with, just because of the nature of our podcast, would be the difference in requirements between more traditional internet connected devices — mobile phones, laptops, et cetera — and then IoT devices, whether it's healthcare equipment, sensors in energy infrastructure, et cetera. Are there significant differences between these two? Are they both governed by the same set of requirements?

Justin: The requirements are the same. That's one nice thing. The standards don't really change depending on the technology infrastructure. I have to give credit to the authors of these standards. They've really made them act more like a rubric. This is a testing methodology and less as a prescription on exactly how you're going to implement security. That's also another common misconception that the standard is going to tell me what to do. Not quite so much. What it is going to tell you is, hey, you should keep data private. But how you do that is very different.

So, we can talk about, in a web-based application, in a mobile app, there's a lot of different techniques to keeping data private. In an IoT type implementation or a small device or hardware implementation, you're still going to think about, for each of those devices, what is the encryption methodology for me to get data on and off that device? What is the storage of data on that particular device? How do I ensure that I remove data when it's no longer necessary, so it doesn't present a security risk? Maybe another thing you might think of, is there a way that I can turn off a device or eliminate a device from my network so that it can't be turned into a bad actor?

You have to think about it differently. You need to think about your security for, what's unique about your product and company. But my best advice, broadly, across to all solutions, is really follow the data. That is where you're going to get the most amount of questions about your security. Of course, for an IoT solution, you can just think about data transfer and that data network, what's happening with that, and how are you securing that infrastructure.

Erik: Okay. Clear. Another perspective to look at this problem from would be the vertical perspective. You've mentioned HIPAA already. Certainly, healthcare is going to be one of the most heavily regulated around data security. What if we look at manufacturing, at automotive — I suppose with connected vehicles, this becomes more of an issue — maybe public infrastructure? Do these other verticals also have unique regulatory domains around compliance and cybersecurity?

Justin: Yeah, and you're exactly right, Erik. There are standards that are sometimes focused on certain verticals. That can help you pick the ones to focus on. We start off with the general standards. These are general business standards. They're pretty useful across vertical markets. So, you might think of them as a starting place.

In North America, SOC 2 is the most common standard that we solve for our customers. It is a general business standard. Certainly, for example, that's the one that Strike Graph has implemented and we utilize. Because our solution is used across multiple different verticals.

The one in Europe that we hear about the most in Asia pack that is a similar standard — the Venn diagram on the two is quite tight — is ISO 27001. I think from a general business standard, both business maturity and security posture, that's a great one. Let's say you were in automotive. You're dealing with IoT, but there's just doesn't seem to be a standard about security for devices and your central servers and the way you're utilizing this information that applies directly to you. You can use something like ISO 27001 as a great standard to begin with.

Now, generally, for manufacturing specifically, you'll hear a lot about ISO 9001, which is a quality assurance type standard, and it's very generally accepted. But if you're shipping, it's not going to cover data so much. If you're shipping a lot of data back and forth, you might have to get two. We have a lot of customers that give more than one standard accomplish. That is hard news but true, maybe in a way, in that you might be starting with one. Like, hey, we wanted to get SOC 2. But then, we have customers that realize that their product is being used for patient health care information. So, now they're doing HIPAA as well. Because HIPAA deals with patient health care information. The nice thing is that all these things have some overlap. Some of the work that you do for one of these will typically apply to the other one. What you really just want to do is look for the gap and fill in that gap.

Erik: Well, let's get into the business of Strike Graph a bit here. Maybe first covering it from a business perspective, then we can get into the technology. It's obviously a topic that every company in the world has to think about, to some extent. But as a company, you have to pick your battles. So, who are you primarily working with?

Justin: Our primary customers are mid-market customers. We focus on companies that have 50 employees up to 5,000 employees. That's been a great marketplace for us to focus on. We find that those customers are a little more experienced, a little more resilient. They also tend to have a dedicated resource to solving this problem. That could be everyone from a CTO that knows they need to spend time on it to CSOs, VP of security, chief risk officers, or director of compliance. That's really a great relationship start for us, where we have a leader and a champion inside the organization that's going to roll out that broader security posture.

Erik: Are you working more with technology providers, or software providers, or device manufacturers, or operators? If it's a bit of all three, it would be great to understand what are the different challenges that each of those different companies would face based on their operating model?

Justin: Yeah, it is a big mix. This is a really massive marketplace and a lot of different types of companies. But I'm happy to talk about some of the primary, some of the bigger populations that we see as customers of Strike Graph. Probably, the biggest group are B2B SaaS web applications. It's almost a requirement to operate in the marketplace, to achieve one of these compliance certifications. So, I would say that's the biggest group. They're dealing with typical AWS or as your type cloud implementation, and then the business processes for their company.

That spans multiple verticals. So, I would say we almost equally have companies in FinTech, health tech, AI tech. I don't know how to describe this. Almost like technology for technology's sake database vendor or even hardware vendors file system, software vendors, that type of thing. We have a fair number of education technology companies in that vertical. So, it's a real mixture.

We do have, I would say, a set of companies that are more mobile app-based, and some companies that work on device management. So, there is some organizations. But they will also have a centralized server, where they're dealing with data transfer on and off. Let's say they're doing BYOD mobile device management. They're still going to have centralized servers where they're having to manage a fair bit of important data.

Then we have some companies that are consultancies. We're starting to see that impact more and more, as you mentioned, where essentially company is going to — they're just critical to the bigger organization's operation. They're just getting asked to meet these security standards as a sign of maturity more than cybersecurity implementation.

Erik: Got you. Then if we if we look at the solution that you bring into the market here, at least, high level at your webpage, I see three products: AI security questionnaire, pen testing, and integration. The way that I would intuitively think about those is, a questionnaire is about checking do you have the right processes. Pen testing is challenging those processes and figuring out if there's any holes in them. Then integration sounds like you maybe have some solutions that can help people to address challenges, some software solutions. But maybe you can spell that out what does it look like from your solution stack, then if we get into some of the technical details of how do you deploy on the clients.

Justin: I might pull this back just a little bit, Erik. As we advertise our product, a lot of people are thinking like what are the solutions. But there's, I think, a better way to capture the broad value that Strike Graph provides.

Strike Graph is a security orchestration and measurement platform. I'm going to break down those two aspects. Security orchestration on our solution is three major steps — designing the right security posture. What is the scope of the security for my organization? We have features like risk scoring tool, control identification tool, standards mapping tool, so that you're designing the right security posture to match your business.

The second part of the Strike Graph security orchestration is distributing responsibility for that securitization across your organization. So, your VP of HR is assigned the controls to onboard, off-board talent. I, as our CEO, have control ownership for Strike Graph overboard transparency. Our CTO has responsibility for data encryption, for example. That's another critical aspect of security orchestration.

Then the final piece is validation of that security operation. The way that that validation happens is you have to collect evidence, almost like with receipts, that you operate at that control. That's done in a number of ways on the Strike Graph platform. One of the easiest ways is, a user can log in and upload that data. For example, I may upload the board minutes from our prior board meeting to show board transparency. But we also have deep integrations that automate the collection of that evidence, so that we can pull from your AWS cloud environment, so that we can pull from a juror, so that we can pull from GitHub or JIRA, examples of that security implementation across a number of really critical cloud providers via integration. That is the security orchestration bubble.

Now let's talk about measurement. You mentioned two really easy ways that we do measurement. One is penetration testing. So, we have certified web penetration testers. We can go and do a penetration task against anything from a mobile application. We can do penetration testing against a web application. We do compliant penetration — ISO 27001, SOC 2, PCI DSS type penetration testing. That's measurement. We want to measure that security implementation as an independent assessor and get what is a sales asset, the outcome of that penetration testing from Strike Graph.

Also, the security questionnaire tool, where you receive a security questionnaire that's a self-assessment of your security posture. We take those questions in, and we use natural language processing to identify the controls you're operating, to prove your active security operation. But there's a bigger form of measurement. Everything from performing as an outsourced internal auditor, things like SOC 2 audit as an ISO 27001 audit are not a certifying body, but the auditor for your ISO 27001 compliance. We offer HIPAA certifications as well. So, we can also measure against the standard.

To bring that back, what's really powerful about Strike Graph as a solution is we not only offer that security orchestration platform so that your company can operate a security posture that meets your business needs, but we are bringing right next to it the measurement requirements to receive those certifications or that independent assessment of appropriate security operation. It's just a very powerful tool for our customers.

Erik: What does the cadence of use look like? Is this something that is a lot of annual activity that needs to be reassessed on an annual basis, or when there are particular product updates? Is this is an integration where you're just continuously collecting data, and there's a dashboard where you can see here's the latest status? I guess, you have to work with an evolving organization also on your client side.

Justin: Yeah. So, let's start with these measurement activities. How often do I need to renew my SOC 2 audit or ISO 27001 certification? The general requirement is that you're going to need to go through that testing phase once a year. But what's happening is it's very similar to a financial audit. The assessment isn't for just that moment in time. It's actually a historical analysis of your practices over the prior year.

What's happening on the Strike Graph platform is, let's say, it's a simple piece of evidence. We need to give our latest policy changes over the year. Maybe you only do that every six months. Maybe you do that just in time when you change a policy. Maybe it's once a year. But over the course of that time, the Strike Graph system is either collecting that via automated integration where a user is being prompted to upload it.

But when we're dealing with a firewall configuration, we might be collecting that everything from daily to quarterly, to on a change basis out of your cloud provider on a regular basis. Just like a financial audit, you can't turn off the bank records for a month and expect to hit through your financial audit. Similarly, for a compliance audit, you need Strike Graph around throughout the year. So, when you get to that moment of measurement, you have all those receipts collected for the prior year.

The cadence is very different depending on how often that evidence needs to be collected. But it is an ongoing activity as security should be. Right, Eric? We should be operating our security postures throughout the year.

Erik: Got you. Yeah, I guess you have these annual requirements, compliance requirements. Are there also ad hoc situations? Is there, let's say, a lawsuit and then a scramble to pull together data to allocate responsibility for a particular case or other situations that are ad hoc? Are those typically going to be covered by annual work that's done more on a regular basis?

Justin: Certainly, if you decided that you had a major breach and you wanted to do an investigation in practices, you could look back through the data that we've gathered. It's not typically what we see. But there are certain standards as a company matures that are going to require more often audits. For example, FedRAMP — which in the United States is requirement for working with the federal government — there's a quarterly audit requirement. As you go up market for bigger contracts, the data is more sensitive. You're going to see an increased need to assess on a regular basis.

Erik: Well, let's talk about the people involved here a bit. You mentioned earlier that you typically work with organizations that have a CSO, or they have somebody that's a dedicated resource responsible for this. So, I guess that would be your primary touch point in terms of running audits, for example.

But then, you also alluded to other people. You might have HR involved. Because, obviously, people are a big source of worry when it comes to cybersecurity. So, there needs to be training, et cetera. You mentioned that sales is one of the big values here. Maybe the salespeople need to know how to present this information to their customers. So, who would be the different users of the platform or people that would be receiving information from the platform?

Justin: The primary user of the platform is whoever is leading that definition of the security scope. So, that could be the CSO. I'm going to define the security controls that we need to put in place. But then, what we recommend, certainly — it's both better security, and it's more efficient to operate — is really distributing ownership to other parts of the organization where there is ownership.

I'll describe some typical areas. But every company is different a little bit. What we typically see is between 5 and 25, users that are operating some portion of security that they have responsibility for. That could be the director of Developer Operations, or whoever is leading DevOps or systems administration. The head of IT oftentimes has control operation responsibility. A CTO will have control operation responsibility, or VP of engineering.

On the business side, we will definitely see HR heavily involved in the operations. The chief operations officer can oftentimes be involved as well. Then certainly, some executive like the CEO or a CFO might be engaged from a financial fraud risk perspective. If you have a data privacy officer, they will have controls that they're operating as a data privacy officer.

What you want to do to both, again, implement good security and spread the love a little bit, so it's not one person trying to operate this, is really assign that responsibility out to those owners. One nice thing about the Strike Graph platform is we have a deep library of just in time resources for these different controls that is mapped to the controls themselves.

If let's say a VP of HR hasn't really ever dealt with this before, they want to make sure they're doing it well and they're not quite sure, they can click on the control about onboarding, off-boarding employees. We have a ton of information for them, from policy templates to share, to typical asset management templates, just deep dive descriptions on how to roll out that particular security.

Now, consumers have the information, right? So, your sales team especially, when they are going to sell and they are especially in an RFP process or working with an enterprise customer, they are going to get things like a security questionnaire that needs to go back to Strike Graph to receive a report on how to answer that questionnaire. They're also going to ask for whatever certifications have been achieved like a SOC 2 audit, an ISO 27001 certification, a HIPAA attestation, for example, if they're working with a health care organization.

I want to highlight that your customers are the ultimate consumers of this information. They are reading these certifications and looking at the way you were tested and the types of controls you've implemented. That is really, I think, ultimately, the team that you need to think about as you're building these security postures as reading deeply into their trust for you.

Erik: Got you. Okay. Thank you. Say, on this topic of stakeholders, you have here mentioned — actually, I'm not sure if I'm interpreting this. You have mentioned companies that partner with Strike Graph. But maybe those are your clients. Are there companies that you are partnering with on a technical integration basis? Then what would be the areas where there would be value in those partnerships?

Justin: Yeah, we certainly have a fair number of integrations. From a technical integration, I think that probably the big ones that people know are like AWS or Azure with very broad integrations into those systems, really, so that our customers can configure their cloud environments the way that they want to. Then they can tell us where that data is, and we can go collect it.

Certainly, tools that are used in change management. For example, JIRA would be a good one. Concurrent versioning systems or code versioning systems like Git and GitLab or GitHub are very typical ones. We also integrate with just document repositories like Office 365 or Google Drive, where there might be business documentation that you want to collect.

But there are other partners that are a part of our ecosystem. One of the ones that we really like is partnering with managed security services providers or MSPs. We're not deep cybersecurity experts. Sometimes having that consultative analysis from a managed security services provider to help scope the security can be really helpful. So, we do build partnerships along those lines as well.

Erik: Let's touch quickly on your business model here. I see that you have an annual plan, which maybe for a lot of your mid-sized customers is a good fit. I think it's interesting always to look through the bullet points on a company's pricing page, because you really understand what are the value in terms of 280 plus ceded controls in this evidence example, repository, and different things you've mentioned here.

What would be the variables? So, there's a starting price here. What would be the variables for complexity that would impact pricing? Is it number of countries you're operating in, number of regulations you're complying with, or just the size of the company? What are the factors here?

Justin: Yeah, I'll tell you some of the ones that we don't focus on. Because I think it's really important for our customers to get the most value at the platform, we don't charge per seat. So, we do an annual subscription. But you're welcome to invite as many teammates as are helpful for you for operating your security posture onto the platform. That's really important for us. Because we think that the best value can be achieved by broadly distributing that security activity. It comes with all the risks and controls and evidence content with any annual subscription on the platform.

The place where we do start to adjust the pricing is the number of standards that a customer would like to adopt. It's a good way to identify the value we're providing. Because let's say you're only going for SOC 2. That's a very typical one, and the one that most people go through. But then later on, you start selling into health tech, and you're ready to upgrade to HIPAA, or you've added a feature set around credit card processing. So, you need PCI DSS.

Or you decide you're ready to go pitch for the Department of Defense here in the United States, and you need the CMMC standard, then we up the price as you're going for those different standards. But we also believe that you're acquiring those standards to acquire new sales. So, your revenue is growing with the value that Strike Graph is helping you acquire.

That is really how we mostly adjust the pricing. There is some bundles that we provide that are really beneficial. For example, if a company just wants to get all the way through the SOC 2 certification, we're able to bundle that. That includes the penetration test. That includes the actual audit and report for one single price with just a single vendor. Honestly, that has been a really winning combination for a lot of our customers. They really liked that. Of course, they get all the platform, all the content as many users as they might like utilizing it today.

We've tried to line up that annual subscription pricing in a way that is really outsized value. If you get a SOC 2 audit, let's say, or ISO 27001 and you added $500,000 in revenue in a quarter, and three quarters of those customers asked for your SOC 2 certificate, the value is outsized. It's immense.

Erik: Maybe we can wrap up here with an end-to-end walkthrough of a customer example. I think it's always helpful to visualize what does it actually look like to use a solution. If you think through kind of end-to-end, maybe we use one of these examples of, let's say, a SOC 2 kind of an integrated package. Say, the client is a mid-sized SAS company, and they've encountered some sales issues. What would it look like from first conversation through implementation? Then what are the timelines for when they would have the audit complete? If you can just kind of give us a nice walkthrough of what that process would look like.

Justin: Yeah, I'm happy to. Let's say, there's interest. They'd like to solve this problem. They come on to our website. They contact us, and they've scheduled a demo with one of our account executives. Generally, the first meeting takes 30 minutes. We're able to provide a demonstration of the software. They get a real clear understanding of the value prop and how that works really quickly.

What we typically see is, after a meeting or two, we're moved into a contract phase. Really, on average, we close a deal in under 30 days. So, it goes very quickly. But we've just designed it, so it's not painful for the customer to see all the value that's provided, easy to make a decision as a team.

On the day that we get a purchase, the first thing that we're going to do is schedule an onboarding call with one of our customer success representatives. They're a very talented team. They have a lot of experience in audit and audit management. So, they can help clear the air a little bit about what to expect. Because primarily why you're buying from us is you want to go get that certificate. So, we need to help define how we're going to set you up for success.

The first thing that we want to do is we want to design that security posture. One of the ways that our customers do it, because we have about 45 risk questions on the application. As you go through each of the risk questions, and you score the risk on a likelihood and impact vector, we recommend different security controls that mitigate that risk.

As you're answering the risk assessment, the customer will sit down and say, "Well, I'm already encrypting my data at rest. I'm going to activate that control. I already have an employee handbook. I'm going to activate that control." In just a couple of hours, right after they've on boarded, they've probably selected between 60 and 100 controls that they're just actively going to utilize.

Now, on the backside, in our database, we've already mapped all those controls to SOC 2. The second year done, our customer success team can tell you, "Hey, you have a gap to lean audit under the SOC 2 standard of 15 controls. That's all we need to implement, and you're ready to go.

Then they'll help you add those extra controls. Then the next step we recommend is that CSO that went through this initial process with us starts assigning those controls out to the owners, and inviting the rest of the team to the platform.

Okay. Now you have your security distributed from a responsibility perspective throughout your organization. You need to start collecting evidence that you're operating that security posture. For every control that you've activated, we've already listed one to three different evidences that are the typical evidences you're going to collect to prove that you operate at that control. So, your team now is working through rolling out these controls and getting an integration. So, you're pulling the firewall configuration from AWS or uploading the employee list that shows asset management to the system.

We're calculating for you on the platform, if all the evidence is supplied to meet the standard. The second all the evidence is supplied, you're ready to go into audit. At that point, Strike Graph is able to move you through the audit process. Anywhere from three to six weeks later, you get the report back from the auditor. Now you have the certificate.

So, it's not very complicated. We've made the system feel like you're breaking down the parts of the process into something you can stomach, where each individual can and really be able to track getting there. I would say, on average, you can certainly go very quickly. We have customers that have gotten into audit just a couple of weeks. That can be really painful, though. It can really disinter-mediate your whole team for a couple of weeks.

So, what we typically recommend is to give yourself 45 days, which is pretty fast, to get to that first audit. Let's say, you mentioned it and we get this all the time, I've got an RFP on the line or a customer contract today. I've really got to solve this. How is Strike Graph going to help me?

One of the things that we can provide is an assurance letter. We can say, "Hey, you're working with Strike Graph. This is signed by the Strike Graph team. You're driving that at SOC 2, and you set a goal to accomplish that. I'll talk to you by this day." You can use that initial assurance letter to get that contract over the line. Then when we finish the certificate, you hand that back to the customer. Now you're on that annual cycle. Every year, you're going to redo that audit while you're collecting that evidence. So, you maintain that trust with that customer.

Erik: Great. Thank you. Very clear. Maybe just last question from my side. You are still a relatively young company set up in 2020. You've raised some quite healthy seed round in 2020, then an eighth-round last year. So good timing before the market fell out a little bit in the venture capital market. I guess you're also now consistently building out new product, bringing new things to market. What's exciting for you on the horizon, from product development over the next 12, 24 months?

Justin: I'm really excited about maximizing the impact of the data we gather. One of the things that's very unique about Strike Graph is, I think, there's a lot of solutions in the marketplace that are SOC 2 in a box. When they do that, they'll try and fit every company into the same technological architecture, operations architecture. It's really the same set of controls for every single company.

As a CTO, I can tell you, that doesn't work. All of my companies are different that I've worked at. We need the flexibility. Strike Graph has baked that into our platform and our value prop. What we've gathered over 200 plus customers over just the first two years of selling is a real, almost understanding of different types of companies and the different types of security postures. I'm excited about maximizing the value of that data back for the organizations that adopt us.

We might call it benchmarking or reporting. We might be able to build some really interesting modeling techniques around effective practices using data science. But I think those are the types of things that we continue to build on top of. We will likely continue to move up market with our solution. We've organically found that enterprise customers, 5,000 plus employees, really find a lot of value with our solution. So, we'll continue to innovate into that particular marketplace over time.

Erik: Well, you're certainly in a good market. It might not make anybody particularly happy, but compliance and cybersecurity are increasingly important. So, you're in the right place. I really appreciate you taking the time to come on today. Thank you, Justin.

Justin: Erik, it's my pleasure. I wouldn't have guessed that this is where we had wound up, but I wanted to find a really impactful problem that made the world a better place. Honestly, I'm really proud that our customers are getting the ability to essentially sell on their company maturity, and making that a part of the buyer's conversation. When we do that, we build a more trusted marketplace. When we have a more trusted marketplace, hopefully have a more vibrant and better economy to operate in.

Erik: Yeah, great mentality. Thanks, Justin.

Justin: Thank you.