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.
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.
Does your business offer services to customers who are interested in your level of PCI compliance?
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:
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
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
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
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