One of the more frequent questions I get from early stage enterprise founders is around security — specifically “what should I be doing and when should I be doing it?” The reality is that while you probably don’t need a full security team from the onset, building some sort of security foundation early on will make it easier as you grow and inherently take on more risk as a company.
In this post, I set up useful guardrails that early stage (Series A or earlier) startups should consider when building their security programs that I’ve gathered from experts in the security community and elsewhere. With so much helpful content out there, I also listed a few highly recommended reads at the end.
Finding What Matters
First, what does security even do? As Dev Akhawe, Head of Security at Figma, wrote in a recent article, security boils down to three north stars:
- Protect the company from data breaches
- Secure the product
- Provide customer trust and assurance
Ryan McGeehan describes in Starting Up Security: From Scratch that you need to know what your risks, threats, and fears are, along with a complete enumeration of the technology you depend on.
Even as a six to ten person company (with hopefully a product…), what are your biggest risks? Is it your customer data in production? Is it IP sitting in G Suite or your code repository? What would your users or customers care most about?
Then, what are the threats? Taking the risk of unauthorized access to a customer database as an example, threats could be a remote intruder with production SSH keys, an insider leaving with that DB, or a stolen corporate laptop. Other common threats include ransomware, cloud misconfigurations, and credential compromises from password leaks and phishing attacks.
While there are many possible threats, the likelihood of most of them occurring is low. As a relatively small startup, you aren’t important enough to be on the receiving end of a targeted attack and instead are more likely to be a victim of an opportunistic campaign. Because attackers care about efficiency, be practical about the threats you should care about.
Julian Cohen, VP of Security and CISO at Ocrolus, says you should prioritize threats that matter:
Prevent commodity malware and off-the-shelf office macros with an Endpoint Protection Platform.
Focus on password reuse. Enforce use of password managers, do frequent password audits, and monitor other breaches.
Watch your third-party vendors and partners closely. Enforce strict data boundaries, segment networks and access, and constantly review high-risk vendors and partners.
Attacks happen on user endpoints. Collect telemetry from your endpoints, like process trees, Powershell commands, and network traffic. Make sure all your data is easily correlated and searchable.
Build incident response. When something happens, you need a way to prevent it from becoming a breach. Focus on smart ways to detect maliciousness and orchestration to prevent escalation.
Keep systems patched and monitor for new vulnerabilities. Unknown vulnerabilities are expensive but patched vulnerabilities can be cheap, especially if an exploit has been made public.
Building a Strong Security Foundation
So now you might be wondering, “what’s the minimum security I need to sell my product to customers?”
You’ve probably heard about SOC 2 Compliance at this point. SOC 2 is an auditing standard maintained by the American Institute of Certified Public Accountants (AICPA) to test an organization’s internal controls for information security and privacy. It’s an objective, third-party system that tells customers that they can trust your startup to handle their information with the utmost care.
For an early stage company, passing a SOC 2 audit can be a useful baseline for establishing your security and privacy practices. Plus, it’ll help get your foot in the door of enterprise customers who often require hefty security standards for their vendors.
Check out Latacora’s SOC2 Starting Seven for a methodology on creating a solid security program baseline that will ultimately set yourself up for greater SOC 2 success, which they describe as:
- Single-Sign-On (SSO)
- PRs, Protected Branches, and CI/CD
- Centralized Logging
- Infrastructure-as-Code
- Enabling CloudTrail and AssumeRole
- Mobile Device Management
- Vendor Security
As you mature, there are other controls that you can start to bake in, but at the core, the above seven should help you build a solid foundation that will get you far and set you up to build up your program over time.
Is SOC 2 Enough?
The answer is “probably,” for now. But compliance doesn’t equal security. It is meant to be a floor and shouldn’t be treated as the ceiling. Compliance is the price of entry.
SOC 2 has a small number of controls and is not prescriptive about how you meet those controls. You need control over access, how you store data, etc. and they give you a lot of flexibility in how you meet them so long as you explain clearly this is what I’m doing and can prove it with evidence.
Depending on your industry, you may want to consider other compliance audits as well, such as HITRUST for healthcare clients or ISO 27001 if you’re based in Europe, which have more stringent requirements, but may be required for your customer type.
Securing Your Product
Enterprises will expect a certain level of security functionality in your product. This includes things like SSO, RBAC, and logging. But your early customer base should guide you on whether or not those features are necessary.
If your initial target market is driven by bottoms up sales or has a product-led growth motion, you can likely ride that out as you capture the small and midmarket segment. Conversely, if your initial target market is sales driven and targeted at highly regulated industries, then having these features built in will be a requirement.
At the same time, SSO is low friction and RBAC is hard to add in later, so adding them in advance can save on the headache later. Plus, there are many startups like Authzed* for authorization that make these security essentials a lot easier to bake into your products.
Don’t forget early deals are going to be about creating a partnership. You and your customer want to work with each other for a reason. Showing your commitment to unmatched customer experience and support, even in times of crisis, can be the assurance they need. Going back to Dev’s blog, “…you don’t have to offer logs as part of the product but assure customers that in case of a security incident on the customer’s side, you will work with them to filter out and share logs you have. This can be a great tactical step to unblock deals while you build out these features longer term.”
Passing Vendor Evaluations
As you move towards closing a customer, you get closer to the dreaded security review process. While the gripe about security questionnaires is longstanding, thankfully we’re starting to see the industry move towards more transparent and automated third party due diligence from companies like VISO Trust.*
As you start answering the likely 100+ questions, my advice is to leave sections of the questionnaire blank if you don’t have a proper answer. It’s better to say “no” than to hold yourself accountable to something that you can’t prove. Plus, you’re a small startup so your prospective customer should understand the limitations of your security program. If they don’t, they are not the right customer for you.
One way to speed up the process is to put together a tidy security package, which can include your SOC 2, pre-canned questionnaire (SIG Lite or CAIQ), API documentation, and other supporting documents like a Safebase page or one-page security marketing document. Some great examples of security and trust portals include Cockroach Labs,* Panther, Cedar, Snowflake, and Box. The neater and more prepared it looks, the better. When time is your enemy during a sales process, easy to consume security documentation helps your buyer pitch the case internally and ease any doubts about working with a young company.
What’s Next?
As a Series A or earlier company, your biggest risk is missing the market. Security, while an added step, will protect your organization and also enable you to close bigger and better deals. Start with baseline controls, assess your risks whether its end users handling sensitive data or databases housing client information, invest more in the areas that make the most sense for your business (corp, appsec, etc.), and build from there.
If you’re a seed stage enterprise startup thinking through how to best build your security program and support GTM, let’s talk!
More Content