Boston-Based Venture Capitalists Weigh in on the Importance of Cybersecurity

At Threat Stack we have developed best practices around cloud security — when it should be introduced, what it should cover at each stage of the security maturity lifecycle, whether a company should build or buy — and so on.

But we always want to hear what other experts have to say. So we recently asked two leaders in Boston’s VC community — Greg Dracon of Boston’s .406 Ventures and Gaurav Tuli, of F-Prime Capital Partners — to share some of the security-related insights they’ve gained from their extensive experience guiding start-up and early-stage companies to success over the years.

Without further commentary, here’s what Greg and Gaurav had to say . . .

Q 1. While I imagine that the timing of compliance is largely industry driven (e.g., by Health or FinTech, etc.), at what round of investment does security become part of your due diligence?


Given our focus on information security, I’d like to think that our companies are more “security-aware” than most. That said, we’re often investing in a company’s first institutional round of financing, so it’s pretty safe to say that it’s minimal at first investment given that they may not even have a product yet, and it’s seldom actually part of our formal diligence process even in follow-on rounds. That said, we expect information security to be understood and considered at idea inception and that the company has a plan for how they’ll protect company and customer data before a line of code is written.

As board members, we often start pushing the need for internal (non-product specific) security controls once a company starts thinking about its second round of financing — perhaps when they have 20–40 people. It’s hard to draw a hard line though as it’s very dependent on what type of data the company holds within its infrastructure and how sensitive that data is.


It’s always a part of our diligence. We know how limited the resources of a startup can be, and our expectations vary depending on the stage / round of company. But perhaps more importantly, it depends on what product you’re offering and what data you are holding. A startup’s customers assume and demand that their confidential data is safe. It’s table stakes.

For example, if we’re looking at a consumer payments company, we would care very much about how they are protecting customer data and securing access to customer accounts. This would be true whether it’s a seed stage company with two entrepreneurs in a garage or a pre-IPO company with 500 employees and hundreds of millions of revenue.

Q 2. As you think about the maturation curve of organizations you are involved in, how do you map internal security investments to that curve, either in terms of staffing or sophistication?


As mentioned above, it’s largely dependent on the type of data the company holds. If it’s a video management company with technology for the efficient delivery of video streams (little held other than creds and content), it may happen much later, but if the company holds the keys to encrypt its customers’ most sensitive data, it begins as the product is being built.

Very generally, we start to see thought being put into how to protect its data (and the spec added to someone’s responsibilities) when the company reaches 20–40 people/surpassing $5M in revenue, and a dedicated information security resource should be added when the company hits around 80–100 people.


You mean your first hire wasn’t a CISO? J/K… With all the priorities a startup has, from building and releasing product to getting users and press, we know how hard it is to have the time and energy to focus on security and privacy. However, a breach early in a startup’s journey might cause irreparable reputational damage. In most cases with very early stage companies (you’re still in the garage), we don’t expect there to be dedicated security staffing. But, security awareness should run through the veins of the organization, and everyone should be working to proactively secure the company and its customers.

This culture includes developing good security hygiene early on and doesn’t need to cost much, if anything (some examples: phishing training, encryption, logging, MFA, and patching). Good engineers understand the importance of security and now have access to easily deployable third-party tools to help them cover at least the basics. After the company has grown out of the garage and there is a tech team with somewhat defined roles, someone in that org should feel ownership for security and also be a go-to person for questions (could be the CTO himself/herself as part of their job). From there, building out a security team really comes back to Question #1 — what kind of product are you offering. But at this point, sooner is still better than later!

Q 3. How should A and B round organizations approach their Build vs Buy decisions for non-commoditized tools? Do you think this answer changes even for commodity tools as you move into specialties like security and data systems, versus a generic topic like log aggregation?


At the A and B stages, it’s hard enough to build your own core product to ensure market fit and ability to scale, so I’d recommend buying if there’s a tool that fits the bill (pun intended). Assuming adequate funding, I’d buy the core set of both commodity and non-commodity tools essential to build the business well for that stage no more.

If a tool doesn’t exist, it might be necessary to build one. More likely, the tool you think you need really isn’t necessary, or it’s out there if you look hard enough. Of course, there are exceptions, but my preference is to put as much of your wood (capital/effort) behind the arrow with which you hope to capture your market.


Early stage companies should prioritize the iterative process of building a great product and getting it into the hands of customers. It’s hard to find value in development projects that deviate from this mission, and not only would you have to build tools, but also maintain them. One exception: If the problem is truly mission critical (e.g., would give you a huge competitive advantage) and the tools out there can’t solve 7080% of the problem or would require a tremendous amount of customization, you might need to build.

I would be very reticent to develop in-house security tools. The bad guys can outmaneuver even the best. Leave it to the companies who do this for a living, and focus your efforts on prioritizing which tools to use.

Q 4. Have you ever seen an investment delayed or derailed by the absence or poor implementation of a security program? At a high level, what were the issues?


Yes, especially at later stages. In most cases, it’s been due to a lack of security awareness and just poor hygiene. We’re trying to build data protection into the fabric of a company earlier and earlier to prevent this, but cyber security has just become well-understood/feared by the masses over the past couple of years.


Delayed and repriced — Verizon / Yahoo

Final Words . . .

Gaurav and Greg believe in building security into an organization as early as possible. The exact timing depends on whether the company even has a product yet, and specific security needs depend on the nature of the company’s information or product (storing medical records vs delivering entertainment video streams, for example). But there is always a need to protect intellectual property, data, systems, and customer information. And regardless of when security is actually implemented, it should always be part of the company mindset from the very outset.