Vanta’s 6 principles for pragmatic startup security

Building startups is hard; securing them can be downright confusing. There are a mess of standards, frameworks, consultants, and bloggers. Even YouTubers are competing to overwhelm you with advice.

There is often an underlying assumption that security should be the main concern of the startup founder and early engineers, but that’s not always the case. Security is a tool to protect your customers and your business, and a founder’s main concern is growing that business. That’s a good thing.

It usually takes several years for security jobs to appear at a new startup. In the beginning, it’s a shared responsibility of everyone working to build the business. With this in mind, Vanta has put together a set of tips for a more pragmatic startup security program. These are the things that should matter to your team on day one. They’ll not only improve your security, they’ll make it easier for your team to scale quickly and safely. If you’re wondering whether you’re behind the ball when it comes to your startup’s security, this list should help you close any gaps in the early stages of growth.

1. It’s easier to secure one thing than it is to secure many things

Use SSO everywhere you can 

Today there are a ton of SSO tools to choose from. If your team uses Google Workspace, you should sign in to everything you can with Google. The same idea applies to any other identity provider. This gives you the opportunity to securely configure one system and avoid inconsistent configurations, like multi-factor authentication (MFA), across different tools.

Write your infrastructure as code

Tools like Terraform or CloudFormation allow you to define your cloud infrastructure in code. This means changes can be peer reviewed and tracked in revision control repositories. This also means you don’t have to dig through dozens of dashboards to spot insecure configurations. Everything comes back to the source.

Consider Mobile Device Management (MDM)

MDM software manages the configuration of all of your employee laptops from a single tool. This lets you set up things like disk encryption, firewalls, screen locks, and installed software consistently across your whole fleet. If you’re not ready to deploy MDM software yet, you should try and centralize the process of setting up new employee machines as much as possible. This could be a simple shell script you have new employees run during onboarding.

Centralize CI/CD

Having a centralized deployment pipeline allows you to provide an easy “paved path” for engineers to deploy their code. If you’re asking everyone to SSH into production machines every day, you’re opening yourself up to more work, higher rates of human error, and a larger attack surface that needs to be secured.

2. Keep secrets secret

Get a password manager

Look into getting a team plan for a password manager. Your team will inevitably need to create, store, and share passwords to get their job done. If you want them to do so with minimal risk of using insecure passwords, and inadvertently leaking them, you want them to use a password manager. When someone joins your company, set them up with a license on your team plan to ensure effortless security.

Know your vendors

Vendor management can be a big rabbit hole, so keep this one simple. The goal here is to create a list all of the companies you share important things with, and to do some basic due diligence on those companies. You should set up a system to accomplish those goals with simplicity in mind. Here’s what an efficient system might look like:

  • You keep a spreadsheet called “Vendors”
  • Vendors that receive customer data or have some control over your production environment should be labeled “High” risk 
  • Label them “Medium” risk if they receive intellectual property or metadata about your customers (e.g. contract details, communications, etc.)
  • Label them “Low” risk if they’re only getting metadata about your company (e.g. a payroll provider)

For all High and Medium risk vendors, ask a few security questions before going forward with them:

  1. Who are the people responsible for your company’s security program? What are their roles/responsibilities?
  2. Have you had a security incident in the last three years? If so, please share what happened, how you responded, and what you changed as a result.
  3. What kind of tools are you using to secure your product and your company?

When they answer these questions, ask yourself “Do I trust these people with my customers’ data? Do I believe they will keep it safe?” When it comes to High risk vendors, ask for documentation as proof of their security. SOC 2 and ISO 27001 are commonly used to satisfy this query. It’s also normal to ask for their most recent penetration testing results. They’ll usually have a report ready for external distribution, but you’ll likely need to be under a non-disclosure agreement to acquire these documents.

3. It’s harder to hack two things than it is to hack one

Use MFA everywhere you can

Your team probably has a lot of accounts to manage for a variety of tools. Not all of them will support SSO. If you have to use a password somewhere, you should require a second factor as well. Passwords aren’t perfect, so having a good second authentication factor makes it incredibly unlikely that someone will gain unauthorized access. To really lock this down, avoid using SMS-based MFA. It’s known to be relatively easy to bypass in a targeted attack, because phone companies aren’t very resilient against SIM swapping attacks. Still, it’s better than nothing if it’s your only option.

Use protected branches

Source control hosts like GitHub and GitLab allow you to designate certain branches as protected and limit the circumstances under which code can be merged to them. Combined with a CI/CD pipeline, this can enforce secure workflows like requiring approval on a pull request before code can be merged to production. It also means that even if an engineer has some level of access taken over or abused by an attacker, they still have to get through an additional layer of protection before they can modify production code.

4. When software tells you it’s insecure, believe it

Update your browser and OS

When it comes to laptops, the most important software to keep up to date are your browser and operating system. These are going to be your biggest defenses against malware, and new security issues are regularly discovered in both types of software.

Update your infrastructure

On the server, the details depend on what your production environment looks like. If you rely heavily on containers, make it a point to use secure base images and do some basic scanning for known vulnerabilities in the software you use. On the server, you should update packages with known security vulnerabilities using something like “yum update --security”. You don’t have to go overboard here and desperately avoid using any out of date software, but set up your infrastructure to regularly move things forward, and try to avoid having software installed that you don’t need.

Note: This seems like a reasonable place to mention that your servers should only support TLS 1.2 and 1.3. All prior versions of TLS and SSL are considered insecure for various reasons at this point.

5. It’s better to find security bugs before the bad guys

Get an annual penetration test

The annual penetration test is a time-honored tradition in the information security world, and for good reason. The “bad guys” will be looking for security bugs, so you should have some “good guys” looking too. This can cost a bit of money, but the benefits of stronger security and your ability to sell to larger customers (if you’re in the B2B space) is invaluable.

There are almost certainly security bugs in your application. More will be introduced over time as well. Having professionals dig deep to find them each year greatly reduces the risk of a vulnerability being found and exploited by a malicious actor.

Create a means for responsible disclosure

There are many people who enjoy finding security bugs without any promise of compensation. If they come across something that looks suspect, they’ll dig in and report it. You can encourage this activity by promising rewards for good bugs with a bug bounty program, but for most early-stage startups this isn’t a high priority.

You should have a way for people to report bugs when they find them though. This can be as simple as setting up security@example.com and making sure it gets routed to the right people. You might get a bit of spam, but you’d be amazed at what sorts of genuinely impressive security findings make their way into that inbox. Try to be courteous, calm, and collected with the people who submit findings.

Warning: Be wary of people reporting security bugs but demanding payment before sharing information. That’s not how these types of programs work.

6. It’s easier to see with your eyes open

Keep an eye on security alerts

Bigger companies have dedicated teams filtering the signal from the noise in all of the security data they collect from their systems.

You may not be ready to build a full-on Security Information and Event Management system (SIEM), but you don't need to fly blind. It’s very likely that the tools you’re already using have some security alerting features. They won’t always be the most sophisticated, but they can give you some visibility into malicious activity directed at your company.

Some good examples of these tools are AWS GuardDuty or Google’s Alert Center. Make it a point to regularly review new alerts coming from these services. Make use of the tools available to you, especially with critical systems like your identity provider and cloud platform. 

Alerts should be actionable. For example, a good alert might be “Jennifer, your coworker, just signed into Google from an unusual country.” It should be rare, and you can go ask Jennifer if she’s in that country. A less actionable alert would be “Jennifer, your coworker, just signed in.” Without any additional filtering you’re going to be staring at logs all day and bugging your coworkers all the time. The more likely scenario is that you’ll just end up ignoring them.

Warning: Watch out for alert fatigue. Find a way to silence alerts that provide no information or value. When you see an alert, you want to have the mental bandwidth to give it a good look before assuming it’s nothing.

Rob Picard, Internal Security Lead

About the author: Rob leads Vanta's internal security program. He has spent almost 8 years in the security industry, including time as a penetration tester, an early hire on Robinhood's security team, and a Y Combinator backed founder. Rob enjoys camping with his wife and two dogs, cooking, and drinking good bourbon.

Interested in more?

Share your email so Vanta can send you new guides and helpful steps to improve security at your company.

GET STARTED
GET IN TOUCH

PCI Compliance Selection Guide

Determine Your PCI Compliance Level

If your organization processes, stores, or transmits cardholder data, you must comply with the Payment Card Industry Data Security Standard (PCI DSS), a global mandate created by major credit card companies. Compliance is mandatory for any business that accepts credit card payments.

When establishing strategies for implementing and maintaining PCI compliance, your organization needs to understand what constitutes a Merchant or Service Provider, and whether a Self Assessment Questionnaire (SAQ) or Report on Compliance (ROC) is most applicable to your business.

Answer a few short questions and we’ll help identify your compliance level.

1
2
3
4
!
👍

Does your business offer services to customers who are interested in your level of PCI compliance?

Yes
No

Identify your PCI SAQ or ROC level

The PCI Security Standards Council has established the below criteria for Merchant and Service Provider validation. Use these descriptions to help determine the SAQ or ROC that best applies to your organization.

Good news! Vanta supports all of the following compliance levels:

SAQ A

A SAQ A is required for Merchants that do not require the physical presence of a credit card (like an eCommerce, mail, or telephone purchase). This means that the Merchant’s business has fully outsourced all cardholder data processing to PCI DSS compliant third party Service Providers, with no electronic storage, processing, or transmission of any cardholder data on the Merchant’s system or premises.

Get PCI DSS certified

SAQ A-EP

A SAQ A-EP is similar to a SAQ A, but is a requirement for Merchants that don't receive cardholder data, but control how cardholder data is redirected to a PCI DSS validated third-party payment processor.

Learn more about eCommerce PCI

SAQ D
for service providers

A SAQ D includes over 200 requirements and covers the entirety of PCI DSS compliance. If you are a Service Provider, a SAQ D is the only SAQ you’re eligible to complete.

Use our PCI checklist

ROC
Level 1 for service providers

A Report on Compliance (ROC) is an annual assessment that determines your organization’s ability to protect cardholder data. If you’re a Merchant that processes over six million transactions annually or a Service Provider that processes more than 300,000 transactions annually, your organization is responsible for both a ROC and an Attestation of Compliance (AOC).

Automate your ROC and AOC

Download this checklist for easy reference

Questions?

Learn more about how Vanta can help. You can also find information on PCI compliance levels at the PCI Security Standards Council website or by contacting your payment processing partner.

The SOC 2 Compliance Checklist

Most businesses look at security compliance as a mountain that is impossible to conquer without an equally mountainous budget and ample time with endless frustrations. The truth is that every organization’s experience will vary, but in most cases, you can achieve compliance and certification easier than you think if you only prepare properly.

That begins with educating yourself about the road ahead and having the right tools in your toolbox, like automated compliance software. If you’re preparing to guide your organization through SOC 2 compliance, our SOC 2 compliance checklist will break down the process and give you a digestible view of the road ahead.

1

Pre-Work for Your SOC 2 Compliance

Choose the right type of SOC 2 report:

A SOC 2 Type 1 report assesses how your organization aligns with the security controls and policies outlined in SOC 2
A SOC 2 Type 2 report has all the components of a Type 1 report with the addition of testing your controls over a period of time
The correct report will depend on the requirements or requests of the client or partner that is requested a SOC 2 report from you

Determine the framework for your SOC 2 report. Of the five Trust Service Criteria in SOC 2, every organization needs to comply with the first criteria (security), but you only need to assess and document the other criteria that apply. Determining your framework involves deciding which Trust Service Criteria and controls are applicable to your business using our Trust Service Criteria Guide.

Estimate the resources you expect to need. This will vary depending on how closely you already align with SOC 2 security controls but it can include several costs such as:

Compliance software
Engineers and potentially consultants
Security tools such as access control systems
Administrative resources to draft security policies
Auditing for your compliance certification

Obtain buy-in from your organization leadership to provide the resources your SOC 2 compliance will need.

2

Work Toward SOC 2 Compliance

Begin with an initial assessment of your system using automated compliance software to determine which necessary controls and practices you have already implemented and which you still need to put in place.

Review your Vanta report to determine any controls and protocols within the “Security” Trust Service Criteria that you do not yet meet and implement these one by one. These are multi-tiered controls across several categories of security, including:

CC1: Control Environment
CC2: Communication and Information
CC3: Risk Assessment
CC4: Monitoring Activities
CC5: Control Activities
CC6: Logical and Physical Access Controls
CC7: System Operations
CC8: Change Management
CC9: Risk Mitigation

Using Vanta’s initial assessment report as a to-do list, address each of the applicable controls in the other Trust Services Criteria that you identified in your initial framework but that you have not yet implemented.

Using Vanta’s initial assessment report, draft security policies and protocols that adhere to the standards outlined in SOC 2. Vanta’s tool includes thorough and user-friendly templates to make this simpler and save time for your team.

Run Vanta’s automated compliance software again to determine if you have met all the necessary criteria and controls for your SOC 2 report and to document your compliance with these controls.

3

Complete a SOC 2 Report Audit

Select and hire an auditor affiliated with the American Institute of Certified Public Accountants (AICPA), the organization that developed and supports SOC 2.

Complete a readiness assessment with this auditor to determine if you have met the minimum standards to undergo a full audit.

If your readiness assessment indicates that there are SOC 2 controls you need to address before your audit, complete these requirements. However, if you have use automated compliance software to guide your preparations and your SOC 2 compliance, this is unlikely.

Undergo a full audit with your SOC 2 report auditor. This may involve weeks or longer of working with your auditor to provide the documentation they need. Vanta simplifies your audit, however, by compiling your compliance evidence and documentation into one platform your auditor can access directly.

When you pass your audit, the auditor will present you with your SOC 2 report to document and verify your compliance.

4

Maintain Your SOC 2 Compliance Annually

Establish a system or protocol to regularly monitor your SOC 2 compliance and identify any breaches of your compliance, as this can happen with system updates and changes.

Promptly address any gaps in your compliance that arise, rather than waiting until your next audit.

Undergo a SOC 2 re-certification audit each year with your chosen SOC 2 auditor to renew your certification.

Prioritizing Your Security and Opening Doors with SOC 2 Compliance

Information security is a vital priority for any business today from an ethical standpoint and from a business standpoint. Not only could a data breach jeopardize your revenue but many of your future clients and partners may require a SOC 2 report before they consider your organization. Achieving and maintaining your SOC 2 compliance can open countless doors, and you can simplify the process with the help of the checklist above and Vanta’s compliance automation software. Request a demo today to learn more about how we can help you protect and grow your organization.

Download this checklist for easy reference

DOWNLOAD NOW

“Getting our SOC 2 and HIPAA was an absolute game-changer for the way that Nayya is able to sell into larger companies.”

Akash Magoon
Co-Founder + Chief Technology Officer  |  Nayya

Related guides

HIPAA

Your HIPAA Compliance Checklist

Our HIPAA compliance checklist will help simplify your path to compliance.
PCI

Vanta's PCI Selection Guide

Which PCI compliance level is right for you? Answer a few short questions and we'll help identify your compliance level.
Security monitoring

The security for SaaS CTO checklist

CTOs are responsible for securing a lot of moving parts of an organization. Vanta created this checklist to simplify the process so that you can help secure your organization as efficiently as possible.
Vanta automates security compliance.
Please enter your first name
Please enter your last name
Please enter a valid email address
Please enter a job title
Please enter your company name
Please enter your company website
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.