Cybersecurity technology adoption cycle and its implications for startups and security teams
Looking at the cybersecurity technology adoption cycle, the "reverse crossing the chasm" problem in cybersecurity, and what these things mean for startup founders and security teams
Many people in the industry assume that when a new security need emerges, customers are immediately going to look for innovative solutions that address that need. In reality, different types of customers exhibit different buying behaviors. In this piece, in collaboration with Kane Narraway, Head of Enterprise Security at Canva, we are looking at ways different types of security teams adopt new solutions and the implications this has for startups.
Welcome to Venture in Security! Before we begin, do me a favor and make sure you hit the “Subscribe” button. Subscriptions let me know that you care and keep me motivated to write more. Thanks folks!
Over 2,510 copies of my best selling book “Cyber for Builders: The Essential Guide to Building a Cybersecurity Startup” have been distributed to the readers so far. This book is unique as it talks about building cybersecurity startups. It is intended for current and aspiring cybersecurity startup founders, security practitioners, marketing and sales teams, product managers, investors, software developers, industry analysts, and others who are building the future of cybersecurity or interested in learning how to do it.
Cybersecurity technology adoption cycle
The way security teams approach adopting new cybersecurity ideas and technologies is highly correlated with their level of maturity, engineering mindset, and access to resources. Broadly speaking, there are three types of security teams as it relates to the way they adopt new ideas:
Mature and engineering-focused security teams.
Mature but not engineering-focused security teams.
Less mature security teams and organizations that lack resources.
Mature and engineering-focused security teams
Mature and engineering-focused security teams are most commonly seen in cloud-native, venture-backed, frequently (but not necessarily) Silicon Valley-based software companies that operate at exceptionally large scales and face problems that are years ahead of the problems experienced by the rest of the industry. These are the kinds of companies that see the need and have the resources to hire security engineers, security architects, detection engineers, and other types of practitioners with an engineering mindset. Google, Microsoft, Netflix, Uber, Meta, Figma, Brex, Canva, and the like all belong to this category.
Mature security teams with engineering resources often don't use conventional off-the-shelf tools directly. When a new security need emerges, engineering-focused organizations usually allocate resources to develop custom solutions in-house (Canva, for example, built a tool that exports tickets/findings to the right places, assigns owners, etc). This makes perfect sense as they are incentivized to respond to the new attack vector or a technological need faster than the broader market.
As soon as the solutions on the market are 70-80% as good as the in-house tool, smart security teams seek to become design partners of ambitious early-stage startups tackling the same problem. Doing this allows them to shape the direction of the startup while recognizing that the organization’s engineering resources are best used to address problems unique to the company, and not to build solutions that can be bought off the shelf. The challenge is to make this switch at the right time, when the startups on the market are ready to offer something usable, and to do it without upsetting the engineers who built an in-house solution.
At some point, solutions in the specific market become commoditized - they all look the same, solve the same problems, and offer the same capabilities. When that happens, it is wise to go with “good enough” solutions and make decisions based on pricing.
Image Source: Ross Haleliuk in Canva
Mature but not engineering-focused security teams
The second category, namely mature security teams without an engineering mindset, is often seen at financial institutions, large corporations that handle a lot of data, and other organizations sensitive about their security posture. Often, these are companies operating in highly regulated industries such as biotech, healthcare, and finance. Unlike software companies, they lack the mindset and the know-how around software product development and therefore rarely invest resources into building their own security solutions.
When there is an emerging security need, mature organizations frequently become early adopters of new solutions offered by early-stage cybersecurity startups. For entrepreneurs, companies in this segment are a great source of user feedback since they have much less tolerance for bugs and other issues than engineering teams who are used to finding workarounds when they run into issues.
Similar to the engineering-focused security teams, mature security teams without an engineering mindset will choose an acceptable solution based on review criteria such as price once the new category becomes a commodity. This commoditization is frequently referred to as industry consolidation, despite the fact that the two terms represent different trends and are not the same.
Less mature security teams and organizations that lack resources
The vast majority of security teams are much less mature, and the organizations they work at do not allocate a sufficient amount of resources to security. The specific reasons why that is the case are outside of the scope of this article, but it suffices to say that without continued investment in security, they are forced to do a lot with little.
Companies that fall under this category are late adopters of security solutions, and their decision to move forward with a new tool is generally dependent on compliance standards and customer requests. These companies will often try to live off the land, utilizing their existing vendors to implement as much security as they can for free. Less mature security teams rarely buy from “best of breed” startups; instead, they usually wait for the large vendors to start offering the new solution and only then buy it, often consolidating on a few select platforms.
Image Source: Kane Narraway in Canva
Cybersecurity technology adoption cycle: implications for startups
For cybersecurity startups, understanding the technology adoption cycle in the industry is critical for designing a successful go-to-market strategy. This is especially the case because the way it works in security is the opposite of most (or all?) other industries.
In most industries, startups enter the market by targeting small and mid-size businesses (SMBs) as they are the most receptive to new technologies. After finding the initial product-market fit and maturing the solution, they move up the market and sell to mid-sized enterprises, and only then to large enterprises and Fortune 500 companies.
In security, startups are faced with the inverted crossing the chasm problem (I first heard this term from Joel de la Garza of a16z). To put it simply, while in other industries SMBs are the first and large enterprises are the last to adopt new solutions, when it comes to security, the opposite is true.
Selling security products is harder than selling other solutions: security teams at large enterprises are notoriously risk-averse, and yet they are innovators and early adopters. This dichotomy creates a barrier to adoption many startups find themselves unable to bridge. To make matters worse, because most security problems are fairly niche, there is often no path to mass market adoption (and therefore, no opportunity for a startup to cross the chasm).
Image Source: Ross Haleliuk in Canva
Cybersecurity technology adoption cycle: best practices for security teams
The cybersecurity technology adoption cycle has several important implications for security teams. First and foremost, they need to be smart when making build vs. buy decisions, while recognizing that some of their problems will eventually be solved by innovative startups, while others are so niche that the solutions will most likely have to be built in-house indefinitely. Second, they need to establish scalable ways to access innovation from the market without getting distracted by shiny tools of which there are many. Third, they need to ensure that evaluating and/or building new security solutions doesn’t distract them from prioritizing the defense of their organizations.
Here are some best practices for security teams to keep in mind:
Always reconsider building a product that has already become a commodity. There are reasons you might still do this but strongly veer away from it if you can. Building is always harder than you expect. These reasons include:
You only need one small part of the product and you want to avoid bloat.
You think you can do it cheaper internally (but can you really?).
You want to keep your supply chain risk down, reducing surface area means having fewer external vendors.
The products on the market don't meet all your needs. Potentially they don't scale to your size, don't have data residency, or don't quite fit into your ecosystem.
If you do decide to build, don’t put all your eggs in one basket.
Many times we see security engineering teams throwing everything under one "product". Even in microservice architectures, services can become heavily interconnected and thus hard to remove a single component. Consider segmented designs early on, so that in the future you might be able to switch as needed.
Finding a design partner isn’t hard; finding a design partner that is both good and will stick around for the long term is. Startups fail more often than not. You can reduce this risk by:
Doing your due diligence on the partner just like you would if you were an investor. Ask about their financials, goals, and objectives.
Ensure you aren’t their only customer. Long-term health of a startup requires at least some level of early growth.
For extremely early startups consider putting escrow agreements into the contract. If the startup calls it quits you at least have the source code to continue what’s been built so far.
There are reasons to use (and not to use) market incumbents. For instance:
Often using a market leader is a safe choice, the old “nobody gets fired for buying IBM”. At the same time, market leaders can become stale and dated. Just look at the endpoint security market and how many iterations it has gone through. The big tools of the past are often not even in business anymore.
Keep close to the security community to learn about what the next market leaders might be. You can’t always pick them with accuracy, but attempting to do so may save you from having to change tools too quickly.
Don’t move tools every time you encounter a problem. Too many people move between the same two or three tools every few years. Instead, try to work with the vendor and get them to build what you need.
If you like my blog, please subscribe & share it with your friends. I do this in my free time, so seeing the readership grow helps me to stay motivated and write more. I don’t send anything except my writing and don’t sell your data to anyone as I have better stuff to do.
If you are a builder - current or aspiring startup founder, security practitioner, marketing or sales leader, product manager, investor, software developer, industry analyst, or someone else who is building the future of cybersecurity, check out my best selling book, Cyber for Builders.
If you are a security practitioner, check out & spread the word about the VIS Angel Syndicate.
If your company is interested in sponsoring Venture in Security, check out Sponsorships. Thank you!
 | A guest post by
|