
Create a culture of security from the start
Christina Cacioppo, Vanta’s CEO and Co-Founder, talked with Chris Evans, Co-Founder at Incident.io, about security strategies to help startups get secure from the start and stay compliant in order to focus on growth. They discussed how to instill a culture of security that doesn’t slow your team down, how to automate security, when to pursue a security certification, and more.
Christina and Chris walked through the five rules of thumb for building a secure product, breaking down the principles through the lens of Incident.io’s perspective.
1. Start doing things early, even if you don’t do them perfectly
As a startup, your company is likely launching by selling its product to small customers. As you grow and start to work with bigger companies, they tend to require greater levels of assurance over the security practices your company promises. Implementing strong security practices sooner rather than later will help your company scale in the future — and if you set up these processes correctly you’ll save your team time in the long run.
Chris noted that at Incident.io they started thinking early on about auditability and evidencing, and having robust processes in place for everything they do. It was critical for the Incident.io team to build good rails to ship things safely to production. The byproduct of good rails is the ability to show evidence of the procedures you’ve put in place, and to demonstrate to your customers that you’re thinking about security.
2. Codify as much as you can (yes, literally in code)
In the startup environment, the priority is generally to ship fast and to optimize around efficient delivery. Codifying practices on the front end might not seem to make sense when you’re pre-product and pre-customers, but as you start to grow you’ll find that you need to backfill. As Chris says, “If it moves and can be defined in code, do it.” There are operational benefits as well as secondary effects to this approach. Implementing a culture of security with auditable practices serves your company well whether you’re going through a compliance certification audit or whether an engineer on your team wants to know what happened — they can look through code changes and pull requests to find the answers they’re looking for.
Codification also comes into play when you’re onboarding new team members. Successful codification of policies and practices across the company means that team members are following those practices from day one.
As Chris noted, policy development can go awry when companies find that they’re creating policies to pass an audit, without real consideration of how those policies will be executed. It’s important to capture the ways that processes need to be done, in language that applies to your company. In other words, your goal is to codify practices and policies in ways that are pragmatic, meet compliance goals, and that are there to be utilized by the people on your team.
3. Track people as well as you track things
Security is non-negotiable, and you want everyone at your company to appreciate this. It is impossible to code people to do things in a certain way; however, it’s possible to tackle security and compliance in a way that makes it easy for people to do the right thing. If your company puts systems in place for employees to follow from the get-go, then no one is faced with making an individual choice about security.
It’s also key to avoid setting up security practices in a way that they serve as barriers to people getting things done. If your systems are too complicated, people will find workarounds — and you’re back at square one. Instead, work to establish practices such that security fits into the day and doesn’t add a lot of friction. Companies might consider following Incident.io’s lead by creating a way for employees to flag if security is making their job more difficult. Bringing those friction points to the fore when they appear, and finding workable solutions, means improving security while keeping it sustainable company-wide.
You’ll also need to review and update processes in a proportional way as your company grows. As Chris noted, what works well for a company with five employees will need to shift with 15 employees, and shift again at 50, with companies reassessing and recalibrating their culture of security at those inflection points.
4. Centralize and assign ownership
Christina and Chris also discussed how fragmentation is the enemy of productivity. The broader your tech stack and the more people doing different activities across an organization, the harder it is to make organization-wide changes. Startups that strive for consistency and uniformity in their practices will find that they can process changes and updates at once across the organization.
Chris noted that employees may come with interest in implementing new tech in order to move fast and meet short-term outcomes. To bring this conversation to teams in the moment, Chris suggests acknowledging employees’ good intentions while explaining local versus global optimization: There are security benefits to the whole organization if software and services are used and supported at the organizational level rather than at the team level.
5. Think about demonstrating your security with a SOC 2
SOC 2 offers the opportunity both to signal and to prove to your customers that you’ve done your due diligence and that you’re thinking about security practices in the right way. Companies will also find that when selling to the enterprise, there is a size of company for which the standardization of the SOC 2 is a necessity.
At Incident.io, the team valued the SOC 2 process of having an external auditor challenge their practices; it can be easy to miss obvious things, and it’s a benefit when someone comes in and spots something you might have missed. Those challenging moments point to opportunities to build stronger security practices that are ultimately better for customers.
After getting their SOC 2, Incident.io noted that the process changed the way they think about auditability and evidencing. Their key takeaway: it’s important not just to do things well, but to demonstrate that you are doing things well. Customers care that you are doing this, and SOC 2 serves as the proxy to communicate these qualities to your customers.
For a deeper dive, watch Christina Cacioppo and Chris Evans dig into the details during their session Secure from the Start, part of the LAUNCH Jam Session series.
More on security and compliance
Guide to effective compliance risk management
Customers who love Vanta security and compliance
Get a SOC 2

FEATURED VANTA RESOURCE
The ultimate guide to scaling your compliance program
Learn how to scale, manage, and optimize alongside your business goals.
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
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.
Subject to Vanta's Privacy Policy, you agree to allow Vanta to contact you via the email provided for marketing and other purposes