9 Security tips For startups
Christina Cacioppo, Co-Founder and CEO of Vanta, recently spoke at TechCrunch Sessions: SaaS 2021. In her talk, she shares nine tips for building your product with security in mind and how to engage in conversations around security from the start.
Let’s take a look at the nine best practices Christina has used for creating a secure startup:
1. You know more than you think
People often consider security and best practices for implementing security as priorities for their organization. However, most people stumble after acknowledging this need. When Christina was researching security practices for Vanta, she asked a lot of startups how they felt about security at their company. The most common response was, “I know enough to know that I should be worried and something bad could happen, but I don't know what to do or how to start.”
Not true, says Christina, because you have experience in your speciality focus area and you’ve researched, learned, and created in your space. So, in fact, you can demystify security in just the same way. “The solid engineering practices that you've learned in school or through side projects or prior companies actually get you pretty far when you think about compliance and some amount of security,” she says. Approach security with the same exploration techniques that you’re comfortable with and you’ll realize you know more than you think.
2. Communicate in English*
When people start talking about security and compliance, the lingo starts getting complicated. And, here is where the asterisk is essential to this point, it is a best practice to communicate in whatever language is natural for you. Don’t overcomplicate what you’re trying to say when you’re trying to communicate normal concepts.
“When you're talking about security, when you're talking about compliance, when you're talking about these things with your company or with your customers, you just want to be clear and communicate in words everyone understands,” Christina says. Speaking in this way makes everyone more comfortable and alleviates any pressure to have to question whether they understand overly technical terms. You can discuss security in an informal way and still get your point across.
3. Inculcate new team members
After working with hundreds of startups, Christina became increasingly aware of how important setting up culture is when onboarding new team members. As a new team member starts, it is the perfect opportunity to create a sense of importance around the objectives within the company.
You can take your early team members or new team members, tell them your best practices and then manifest that future. The new members will think this is just the way the company works and will incorporate it into daily life. “It is just easier to roll out new practices when you are smaller with fewer people on board. And so take that, and in your early days just roll out the practices that you think you want for the company over the long term,” Christina says. “It's a little bit of a magic wand thing. It seems so simple, but it ends up being pretty cool. A little bit of a way to program people in a way they don't realize.”
4. Codify in code
According to Christina: Compliance loves record keeping. This tends to be an engineering best practice, but also works well for compliance. Codifying in code acts as a single source of truth and records any changes that are made. So, if one person makes a change to the code, anyone can see who made the change.
Further, if anyone is looking for a paper trail, which is common in security compliance, the code exists. “If you're using infrastructure as code tools, you're doing code reviews, you will have whole records. If somebody comes in and asks to see these records, you can say, ‘Here we go, we’ve got them all for you,’” Christina says.
5. Review code
Review code early and often. Make this a best practice from onboarding and continue to do so throughout. “You can institute code review in your company as early as possible, even if it is non-blocking, I would recommend it,” Christina says.
Code reviews will ease the hassle of a compliance audit because there is a trail of what code has changed. This becomes especially important as a team grows and more people are committing code. You start to review if the code makes sense to system feedback, how the naming works, or if your data modeling makes sense to the larger set of users. “With code review there's the compliance benefits, there's the security benefits to see what's going on. More eyes makes bugs more shallow. And so when you're picking someone else's data model, you can understand what's going on.”
6. Build audit trails
Audit trails are a chronological set of records that provide documented evidence and basically log any events within your code in order to provide context for any changes made. Building audit trails advances forward the motion of reviewing code. Because, like reviewing code, building audit trails creates a SSoT for anyone looking to review commits. An audit trail can also be a security best practice in that there is record of every movement, both good and bad.
The caveat to this is that if you’re not communicating in English (or the language you’re most comfortable with), then the reporting may be useless. Steps might be lost, security actions might be missed, and what happened could be anything in the world if it is misunderstood. “I encourage you to think about investing in this early. This doesn't have to be fancy, this doesn't have to be human readable. Definitely doesn't have to be a UI. It's just structured data that you can query over if you ever needed to. But it's not like a human actually has to be able to read it,” Christina says.
7. Centralize tools
Centralizing your tool stack is the standard. There are thousands of different tooling options for basically anything these days. And though broader tool options are wonderful to have, using too many tools can be chaotic and wasteful. On top of that, using too many tools can be harmful to customer data because if one platform is breached, then you’re putting all your data at risk.
According to Christina, let your team experiment and figure out what tools you want. Spend time learning what works for your organization and use the one that makes the most sense. You’ll save money by not paying for four different email tools and you’ll be more secure with centralized tools in place.
8. Prompt the conversation
If you’re selling a product or service, especially one that works with customer data, your software buyers will ask about your company’s security and compliance. So, prompt the conversation around the tool that you’re selling. This step assumes that you’re ready to talk to buyers about security. Working with any sort of customer data can make buyer’s anxious and you can create assurances by getting ahead of the conversation.
“But actually prompting the conversation in that way one, makes you look like you're totally on top of things. Like, you know enough to know it's a concern, you've read their minds. You understand what a big company enterprise buyer wants,” according to Christina. In doing this, you get to shape the narrative and appear ahead of the game.
9. Do the dance
As you dive further into the conversation around security and product sales, you can expect to have to do the dance. And by that, according to Christina, expect that you will get asked a lot of questions, so be prepared to answer them in a way that makes sense for you but also remains appealing for the buyer. “There is good and bad to it. But it has just ended up being much more inevitable and much more of something that companies do need to engage in. So figure out a way to engage in the dance, in a way that works for you.”
Want to learn more about Christina's nine security tips for startups? Check out her talk from TechCrunch Sessions: SaaS 2021 to learn more.
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