ALL RESOURCES
SOC 2
5 Principles for building a secure product
BlogsSOC 2
August 30, 2021

5 Principles for building a secure product

Vanta CEO, Christina Cacioppo, recently spoke at the Startup Grind 2021 Global Conference. Here’s your session recap on SOC 2 and how to build a secure product.

Vanta’s history with SOC 2

After working on Dropbox Paper, Christina realized that large companies wanted tangible proof of product security. This is a huge blocker for many startups selling to enterprises. Vanta makes it easy for startups to get and stay SOC 2 certified.


What is a SOC 2?

SOC 2 is a standard created by the American Institute of CPAs that looks at your overall security posture and evaluates it against a standardized framework. You can customize your SOC 2 prior to an audit to reflect the processes that you have in place. An auditor then looks at the evidence that you provide them and validates that your listed practices are correct and implemented. We recommend startups to proactively obtain an SOC 2. This report shows your prospects and customers that your company takes security seriously.


Two main reasons companies are getting SOC 2 certified are to hold them accountable to high security standards and to protect their customers' data. SOC 2 is a standard, streamlined, way of communicating security practices to new and existing customers.


At the time of this session, Vanta had helped 800 companies prepare for their SOC 2 audit. Roughly six months later, Vanta now has over 1600 customers. Despite doubling the size of the business, Christina’s five key security principles have remained the same.


Principle 1: Start doing things early, even if you don’t do them perfectly

Establish strong security practices from the very beginning. It’s critical to track who at your company has access to what. This will give you a single location to store all of your key information on where to offboard or deactivate employee access when people leave or shift roles. Track everything, even if it's not perfect. It can be anything from a basic spreadsheet to a developed software like Github.


Christina’s main takeaway is that “You don’t want to wait for an audit to start thinking about your security practices. Starting early may slow you down a bit now but will ultimately help you scale later and if you set your processes up correctly, can save your engineering team time in the long run.”


Principle 2: Codify as much as you can (yes, literally in code)

Document your practices in code wherever possible. Whether this be security logging or change management, the more you set aspects like this in code, the easier it is to see approval patterns, hence also giving the benefit of hindsight when something goes wrong. There are good reasons outside of security to do this too.


Examples of where you can codify your practices now include:

  • Infrastructure: You can manage infrastructure through Terraform, CloudFormation, or any other Infrastructure as Code tools.
  • Testing: Defining a CI/CD pipeline, creating unit or integration tests where it makes sense and having testing descriptions written in PR’s can help your whole team stay on the same page.
  • Personnel access: Create IAM policies in AWS or any cloud infrastructure provider you use. You should version these to see what changes have been made overtime.  


Principle 3: Track people as well as you track things

Many companies are already tracking a lot of the ‘things’ that are expected in a SOC 2 audit which is a great first step. Where most startups are lacking is in their people management. As with all security practices, starting these practices earlier makes it a lot easier when you grow.


Some steps you should take to track your people:

  • Set up single sign-on wherever possible: This helps you move toward a good access control policy. If you're using single sign-on, you often also get multi-factor authentication for free.
  • Access review: Review which employees have access to which system periodically and write everything down to maintain a secure record. This ensures that you can remove access to these tools when people leave the company.
  • Assign admins: Within systems like GitHub, you should assign ‘super admins.’ Not everyone needs to be a super admin and it should be clearly labelled and documented.


Principle 4: Centralize and assign ownership

Fragmentation is the enemy of compliance (and your sanity), making it critical to centralize processes as much as possible and then assign ownership. We advise using single sign-on providers, and centralizing deploy systems, vendor tracking, password managers, and mobile device management on one platform wherever possible. These practices will maintain security and organization. Christina advises companies to “default to prescriptiveness. Be communicative and directly tell your employees what the standard is, and make sure they follow it.”


Assign ownership to individuals, instilling a culture of accountability and a focus on security. This is also the best way to ensure that a task is completed by a specified deadline. The directly responsible person or deadline may change but someone is directly held accountable for projects this way. This has to come from the top and start from the beginning.


Principle 5: Think about demonstrating your security with a SOC 2

Get SOC 2 certified and show it off! SOC 2 certification proactively displays your commitment to security. Many customers seek out this certification — differentiating you from your competition. Vanta provides customers with a badge to prove that they are SOC 2 compliant. Consider creating a blog post or social media announcement publicizing your SOC 2 report and utilize this credential in your sales and marketing efforts.



Vanta makes it easy for startups to get and stay SOC 2 certified. We’ll customize security procedures based on your needs and ensure that your SOC 2 is right for your customers. Let’s get started!

Watch Christina Cacioppo’s full session, Before SOC 2: 5 Principles for Building a Secure Product, from the Startup Grind conference.  

Written by
No items found.
Access Review Stage Content / Functionality
Across all stages
  • Easily create and save a new access review at a point in time
  • View detailed audit evidence of historical access reviews
Setup access review procedures
  • Define a global access review procedure that stakeholders can follow, ensuring consistency and mitigation of human error in reviews
  • Set your access review frequency (monthly, quarterly, etc.) and working period/deadlines
Consolidate account access data from systems
  • Integrate systems using dozens of pre-built integrations, or “connectors”. System account and HRIS data is pulled into Vanta.
  • Upcoming integrations include Zoom and Intercom (account access), and Personio (HRIS)
  • Upload access files from non-integrated systems
  • View and select systems in-scope for the review
Review, approve, and deny user access
  • Select the appropriate systems reviewer and due date
  • Get automatic notifications and reminders to systems reviewer of deadlines
  • Automatic flagging of “risky” employee accounts that have been terminated or switched departments
  • Intuitive interface to see all accounts with access, account accept/deny buttons, and notes section
  • Track progress of individual systems access reviews and see accounts that need to be removed or have access modified
  • Bulk sort, filter, and alter accounts based on account roles and employee title
Assign remediation tasks to system owners
  • Built-in remediation workflow for reviewers to request access changes and for admin to view and manage requests
  • Optional task tracker integration to create tickets for any access changes and provide visibility to the status of tickets and remediation
Verify changes to access
  • Focused view of accounts flagged for access changes for easy tracking and management
  • Automated evidence of remediation completion displayed for integrated systems
  • Manual evidence of remediation can be uploaded for non-integrated systems
Report and re-evaluate results
  • Auditor can log into Vanta to see history of all completed access reviews
  • Internals can see status of reviews in progress and also historical review detail

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 compliance news you need. Delivered securely to your inbox.