InfoSec

Shift Left: Turn Security into Revenue

August 3, 2022
7 min read

This blog post was adapted from the webinar Shift Left: Turn Security into Revenue with Chase Lee and Sabino Marquez, hosted by Mara Willemin. You can listen to the full webinar here.

For many SaaS businesses, “InfoSec” is a term that can send a shiver down anyone’s spine. Enormous spreadsheets, complex questions, and delayed deals has been the name of the game for the Sales <> InfoSec relationship.

We’re living in the time of a security revolution—one that calls for a different landscape entirely, where security evolves from a cost center into an asset. Forward-thinking security professionals and progressive sales leaders are joining forces to create a better future for the state of InfoSec at software companies and beyond—a future where security is a bullet point in everyone’s job description, executives position security as a revenue-driving investment, and Trust Centers are standard practice for buying and selling software.

The most successful companies are now treating security as a critical aspect of the buyer journey by educating prospects and customers early, removing roadblocks to closed revenue later in the deal. By applying the traditional DevOps principles of Shifting Left, teams are positioning security as a differentiator instead of a hurdle, and centering security in their sales conversations at every stage.

What is shifting left?

Originally a concept made popular by engineering teams, inefficiencies in the Waterfall Methodology hypothesized that distributing testing throughout the entire development cycle could produce more reliable code at a faster pace.

This hypothesis often proved true, and teams began iterating on software development through methodologies like Agile and Scrum. This meant that engineers were moving away from linear design and development cycles where testing and validation was tacked onto the end of the cycle, and began incorporating quality assurance testing earlier (or further left) in the process.

Some have mistaken the term to mean that testing is simply moved to the beginning of the process. When run effectively, however, “shifting left” results in the distribution of testing throughout each stage of the development cycle, rather than waiting until software is nearly complete to being checking quality. Teams found that when testing their products earlier and more often, they were producing more reliable code as a result.

How does the “Shift Left” apply to security and go-to-market teams?

If you map the traditional sales cycle alongside the software development cycle, you’re left with striking similarities. Buyers are often talking to your sales team for weeks or months, then you suddenly find yourself in the midst of a hundred-question questionnaire that could bring your deal to a screeching halt.

But imagine if you enabled buyers to educate themselves on your security policies and removed roadblocks earlier in their buying journey. You certainly don’t want to spend months nurturing a deal that is doomed to fail because of a lack of alignment on InfoSec policies, and buyers similarly don’t want to waste months evaluating a product only to find out their compliance team won’t allow them to sign the contract. Shifting left allows you to identify security concerns or vulnerabilities early on, giving the team time to mitigate those risks before the prospects become clients.

How can an organization introduce security earlier in the sales cycle?

Any strong vendor relationship is grounded in trust—trust that your software can achieve a goal, trust that you will not leak data, trust in your organization as a whole. When someone chooses to outsource a significant process to you, you need to be as good as or better than their internal IT and security processes in order to earn that trust.

In every company, there are actors (perhaps hiding) behind your champion who get paid to identify risk and stop the deal. Their sole job is to vet vendors, so as to not introduce risk into their environments, or to effectively mitigate whatever risk they decide to let in.

The reality is that without the approval of these actors, you cannot sell your software. They are just as much a part of your buying team as is your champion, so why not treat them like they are part of the buyers journey as early in the process as possible?

If we tell good security stories via the right documents, evidence, and artifacts, we can help our champions diffuse any risk conversations by making trust the first thing we talk about in a relationship. When you shift these conversations left in the process to win vendor security early, you speed up sales cycles and actualize revenue faster.

Security as a feature, not a bug.

Security is an operations practice—we can all agree on that. But security is also a communication practice, a legal practice, a revenue ops practice. We don’t report security outcomes in terms of “viruses stopped” or “firewall events analyzed” because no one really understands the ways this impacts the businesses’ bottom line.

When we report on the success of security in terms of revenue outcomes, we help a broader audience understand a tangible impact of the security program we’ve built. In turn, we’re helping leaders across business units understand the monetary value we’re adding to the organization.

When you visit a website for a software product, everything about the product is outlined. Use-cases, feature pages, and more. But we rarely see a page with much of any information about security. At best, companies who make this information available attempt to present technical information via marketing language and brand speak. Knowing that buyers evaluate security as a critical part of their purchasing process, why not treat security as the core product feature throughout the customer experience?

There are a few ways that you can begin to treat security as a feature to begin enabling revenue growth based on your product’s security features.

Building a culture around your security story

Instead of creating a silo called the security team, making security a bullet point in everyone’s job description is the most authentic way to build and articulate your security story. While a CISO is responsible for setting the standards for your security program, upholding and communicating these standards are a company-wide obligation.

Everyone on your team is responsible for creating value within your security program, so build a culture that encourages that. Security awareness training is important, (we wrote a whole blog post about selecting our vendor) but ultimately the culture must go deeper than a once-monthly required course. Talking about security often, without jargon, and across functions within your organization is a great way to start. TechTarget has a great article on the topic, if you’re interested in learning more about building a strong security culture.

Investing in your security story

Revenue teams’ ability to get a security persona on board is limited by an organization’s investment in security. Business leaders have been taught that security teams are a cost center to be minimized, then are surprised when the lack of investment leads to a lack of meaningful stories to tell about your product security.

Position security as revenue and value investments, not just as operations investments. Sure, having strong security policies can prevent data leaks that ruin your brand and harm your clients. But how are you telling the story of your security strengths throughout your brand today?

Investing in your security story means enabling buyers to access security-related content early in the process, even when they’re only engaging with your marketing content. Then,  they’re able to send the detailed, trustworthy content back to their procurement, diligence, security teams and show them everything they need to know before they’ll allow you to buy it.

Publishing a Trust Center

The less you lean into telling your security story, the bigger the questionnaire that is coming your way at the end of a sales cycle. By providing comprehensive and detailed information on your security policy via self-serve documentation, you enable prospects and customers to do the work of evaluating your security posture on your behalf, perhaps before they even start the sales process. Beyond building more confident buyers earlier in your sales cycle, this also enables your security team to spend more time working on security rather than just talking about it.

The future of security is here, and here to stay.

Optimizing processes and capitalizing on efficiencies can be the difference of building a strong pipeline and closing revenue faster. Telling a security story at scale is the next step in the evolution of software businesses across every niche.

As sellers start to meet buyers where they are in their buying requirements, collectively we create a more trusted ecosystem of software. As security becomes a cornerstone of the buying and selling journey, increased transparency and improved security policies will lead to better data protection. But perhaps more importantly in the short term: improving your transparency in security will lead to more closed deals and more revenue, faster.

Interested in learning how Trustpage automates this process? Book a demo with us today.

Similar posts

Join 300+ companies using Trustpage to communicate security.