Is Your Product Secure Enough For Enterprise Sales? Calendly’s CISO Shares His Security Tips

Casey Renner

September 1, 2022

A goal of most product-led growth (PLG) businesses is to eventually go beyond monetizing their product with individual users, and to start selling to larger organizations—a process known as embracing the enterprise.

But this market shift brings with it huge changes in responsibility. Software bugs or security concerns are no longer mere annoyances; they’re big issues with potentially bigger ramifications. As a result, it’s best to get your product security up to snuff as early as possible.

That’s what we discussed with Frank Russo, former senior director of enterprise security at Salesforce, and now chief information security officer (CISO) at Calendly. We sat down to ask him about his experience in software security, and what startups can do to ensure that certain issues don’t hold them back from achieving their full potential.

Security is part of everything in your startup

First, it can be helpful to break down the term “security” in how it relates to software. While there are a lot of different functions that fall under the umbrella, Frank spoke of three distinct categories:

1. Compliance and security fundamentals

This list of basic compliance and security features is one that every startup needs to have to address data vulnerabilities. Without these fundamentals, enterprise will not take you seriously, and they might not be able to even legally use your product. It includes:

SOC 2: A voluntary but now commonly expected certification by the Auditing Standards Board of the American Institute of Certified Public Accountants.
ISO/IEC 27001: The international standard certification for maintaining an information security management system, set by the International Organization of Standardization (ISO) and the International Electrotechnical Commission (IEC).
Third-party data processor analysis: Any details regarding your integrations with the other entities you’re sharing data with, including “vendor security,” properly vetting those who deploy their services to your product.
“Fourth-party” data processor analysis: Further details about who those third-parties are subsequently giving your data to.

2. Admin console

It’s impossible to tailor your product to fit the security and compliance needs of every company. Instead, focus on giving them administrative control over your service. It lets them customize the console to their requirements, like the abilities to:

Gain access to detailed activity logs.
Limit or restrict user access to fit into regulatory frameworks.
And other features that may be necessary if the business has to report to the Security and Exchange Commission or other government bodies.

“At the end of the day, it’s really about providing the customers with transparency and control. The enterprise customers, that’s what they’re looking for,” said Frank.

3. Fraud and abuse

These days, security isn’t just about protecting your system from hackers who want to steal your data. There are others who can misuse your product in a variety of ways, including:

Sending spam or phishing.
Attacking others using fake names or your company’s name.
Flooding your product with hate speech.

Those actions may be against your terms of service.

“You have to protect the customer in some ways from themselves,” he said. “Don’t assume the responsibility just cascades to them because that’s what your paper says. In the real world, the responsibility comes back to the provider.”

Baking in security from the get go

Threats to your data are constantly evolving and can be like fighting a shadow army. Before you run out to hire a CISO of your own, there are two important things to keep in mind:

1. Figure out what team members spend the most time on security and train them.

Whether they want to or not, your engineering and IT teams make security decisions with every line of code they write. If you invest time and money into security training for them, you can save more time and money down the road.

Being upfront about security with engineers can help them see security as a legitimate part of their job, rather than an afterthought, said Frank.

“They get to wear the security hat. That becomes one of their responsibilities. So make it explicit rather than implicit, and maybe that’s a way to see it as a resource constraint. It’s like, how much time should we dedicate to it? Is it 25% of their time? Is it 50%?”

Engineers wearing security hats is common, and your first CISO will likely be your chief technology officer (CTO). In fact, that’s a perfectly fine setup to have.

However, the situation becomes untenable when the friction of a potential enterprise sale is too high because you don’t have a dedicated security team. At that point, those employees you trained can become the foundation of your new centralized security department, and you can bring in a CISO whose time is 100 percent dedicated to security.

2. Vulnerabilities are everywhere. Developing an adequate response is what matters.

It’s not a matter of having no vulnerabilities. They will always exist in some form. But how you respond is what makes the difference between basic security and better security.

“My experience at Salesforce is that everybody has security vulnerabilities,” Frank said. “Everybody has flaws that you will find in their product…
The muscle of like, ‘hey, how quickly can we identify vulnerability? How quickly can we fix it?’ is very, very important.’ ”

According to Frank, depending on the issue, taking weeks or months to solve it is fine. The amount of time doesn’t really matter; it’s committing to a timeline to solve it that will show you’re a company others want to work with.

Even better than fixing problems as they come up, is having a system to identify security gaps before they happen in the first place. When a company has a bug bounty program, that’s when you know they take security seriously.

Some signs of a good bug bounty program are:

Incentivizing outsiders to test your product.
Allowing users to contact someone quickly when they find a security bug.
Offering a decent bounty–or high enough payment–to show confidence in your product.

Bug bounties can sound like an invitation for trouble. But, even if you aren’t asking people to take a peek under the hood, that won’t stop them from doing it on their own, said Frank.

“You want to be willing to have anyone bang on your system, report a vulnerability to you,” he said. “You fix it in a meaningful amount of time, because it’s happening anyway. Bad people are attacking you anyway, but they’re not doing it for the right reasons.”

It’s less about winning a company’s CISO and more about losing them

So you’ve followed all of Frank’s advice and set up a solid security system. Now the question is, how do you sell it to a prospective CISO?

Based on his experience, Frank said that the CISO is not typically the one who will give the final thumbs up on your product—it still has to sell itself. Instead, you want to avoid setting off a lot of red flags and having them give the thumbs down.

To that end, it’s pivotal to develop trust and rapport with the CISO, so they can suss out how seriously you take security. Here are some key ways to achieve that:

Don’t just say, “Trust me.” Give direct answers to the CISO’s questions. Anyone who is selling their product security with that blanket statement is ending the conversation from the start.
You are not expected to know every single detail about your product’s security. If you don’t know the answer, simply say, “I don’t know, but I’ll find out.” But don’t make a habit of it, as you can also seem unaware of your product’s security.
Don’t pat yourself on the back too much for compliance. SOC 2 and ISO certifications are only the beginning when it comes to compliance. Saying “we have SOC 2 and ISO” as answers to a CISO’s questions over and over again is a recipe for dismissal.

Once you’ve prepared all that information for a CISO, you might be worried that you will overwhelm them with information regarding your product security.

Frank said that’s not the case. “You can’t kill them with too much data,” as he succinctly put it. No matter how much information you present, there’s always going to be something that’s missing for them, such as:

How are you handling my credentials and how are you encrypting them?
How are you storing user data and which employees can view it?
Does everyone have access to my data?
Do you have security embedded in the software development life cycle?
How do you handle my authorization token?

That can seem like a lot, and that’s because it’s meant to. Security is not something you get at a one-stop shop. It takes time to develop a robust and responsive system. You’re not expected to have everything ready to go right away.

“Customers know that you’re not going to have everything. But the big ones, the enterprise deals, usually they’re willing to wait and say, ‘Okay, great. Let me know when you’ve got it, and we’re happy to talk, and we’re happy to help articulate that for you,'” said Frank.

When a CISO points out things that need cleaning up before sealing the deal, don’t waste time being embarrassed. Just be upfront and let them know you’re on it.

Not even the cloud’s the limit

Security is constantly evolving. It requires juggling multiple things, like staying on top of things as they change, staying ahead of the bad guys, and keeping up with what big companies are willing to try.

Even something like storing sensitive data in the cloud, which a few years ago would have been unthinkable, has now become a ripe field for new security innovations.

“I was at Salesforce when they landed their first big bank,” Frank said. “And everyone was like, “That bank will never trust their data in the cloud. They will never.” And then all of a sudden, they did.”

Stay ahead of the security game with these articles:

Note: Calendly is an OpenView portfolio company. For a full list of OV portfolio companies, please see our website.