Learn more about Consider Learn more

How we run security and privacy at an early stage company

What kind of data do you collect from your customers? What is this data for, and what is it not for? Where does it end up?

When and why do your employees access that customer data? How much of that can you prove and are certain of? What would you do if you found out that customer data has leaked to an unauthorized third party? What do you define as unauthorized?

Protecting customer privacy and trust should be a top priority for all businesses, but the stakes for us– a small email company– seem even higher. When I joined Consider last year, I was excited to help grow an internal culture of excellence in privacy and security, and help create a foundation of programs and processes to help our company grow, while maintaining our customers' utmost trust.

If you haven't worked on a project like this before, it can be daunting. I'm excited to share these 5 programs that work for us, that should help you get started.

1. Ethics agreements


First impressions matter. At Consider, our goal is that new-hires immediately start working with the knowledge that customer privacy is sacred. To this end, all of our team members sign an ethics agreement on day one that sets out:

  • How protecting customer privacy always trumps any other issue or goal.
  • How we never access customer data, unless in response to an explicit request and permission from the customer. When a customer explicitly asks us to look at some of their data to resolve an issue or question, we must establish a clear permission trail, and perform the required action in groups of two. All actions here are automatically logged and published to a realtime public audit trail.
  • We have a zero-tolerance policy of any misuse of customer data.

⁠2. Internal auditing


I recommend regularly auditing your whole company and all of the software you run. We do this every three months. First and foremost, we do this to find minor problems before they become bigger, such as a user account with slightly incorrect permissions. Secondly, we do this so that we can build confidence and communicate to business leadership how well we are doing at privacy at a very high level, and that we have a total grasp on all of the infrastructure and software we use. Thirdly, we do this as a regularly-scheduled reminder to teammates how important customer privacy is.

The exact steps that make sense during a routine audit will differ, but here's a few things we've found value doing:

  • Rotating every credential/password the service uses. We do this routinely so we never feel tied to a credential, and to ensure we can change it with ease if shit hits the fan.
  • Manually reviewing the access control and team settings for every single tool we use.
  • Manually reviewing audit trails such as CloudTrail.
  • Manually reviewing certain mission-critical things, like domain expiry settings and DNS settings.
  • Crucially, we re-evaluate the audit process itself. Are there new things we should be checking? Is there a step that doesn't make sense any more? This helps prevent the process from devolving into a box-checking exercise.

⁠3. Application Security


So often, application security is sidelined as a separate task and program to the day-to-day development and deployment of your app. But to me, a great appsec culture is embedded in new product development, where you can build and ship new product features and changes quickly, while also having high confidence that what you're releasing won't introduce new security vulnerabilities. You can start to introduce application security principles into day-to-day development:

  • Mention and discuss any new security issues during code review. For example, you need to treat any and all customer-provided data as untrusted input to your system. Untrusted input needs to be carefully stored, and carefully displayed, to avoid vulnerabilities. Be obsessive about this. Learning some threat modelling acronyms like STRIDE can help motivate questions during code review.
  • Familiarise yourself with basic security bugs. For example, you can check out the OWASP Top 10. This will help you spot bugs, but also helps you talk about and reason about them with others.
  • Research best practices for your app, and adopt them where possible. For example, webapps can adopt newer browser-level security features like CSP and SameSite cookies.
  • Schedule and perform regular external security audits.
  • Gratefully accept, fix, and reward security reports. A simple place to start here is having a dedicated `security@` email address, but you can also investigate bounty programs like Bugcrowd and HackerOne.

⁠4. Internal tooling


When building and continuously deploying software in a growing company, eventually you'll start building internal tools and admin dashboards to assist with the day-to-day maintenance of your application. At this early stage, it's easy to build tools that expose a huge amount of information about your customers, without building much access control or audit logging. Zoom ahead a couple of years, and suddenly you have hundreds of employees with thousands of workflows built on these admin tools. Introducing privacy controls at this stage will be met with justified resistance and turmoil.

At Consider, we're trying to build a privacy foundation that will work for us as our company grows. Therefore all of the tooling we're building redacts customer data. Does this make investigating an individual software crash more difficult here and there? Undoubtedly, but the problem is not a major one for us. We're used to it, and we build new product features with the knowledge that we are going to have to debug it anonymously, without customer data in stacktraces to help us.

5. Culture and Leadership


Your teammates have to internalize and truly believe in the importance of customer privacy. You can help here by simply being seen to care, and recognizing and rewarding good work that advances privacy internally.

You'll know when you've made progress here when you start seeing these signs:

  • Engineers start organically prioritising bugs that could lead to a privacy or security issue.
  • Team members advocate less and less for weakened customer privacy to make something like debugging or analytics easier.
  • Team members start to blow the whistle on privacy violations and issues, no matter how minor.

⁠Summing up


Warren Buffet said: "It takes 20 years to build a reputation and five minutes to ruin it". Prioritizing security and privacy at an early stage isn't always the easiest path, especially when there are hundreds of other things vying for attention and investment. However it's also true that the reputational, legal, and financial risks associated with ignoring it are bigger than ever.

It's important to start the conversation with your team about protecting your customers. If you'd like to give some of these practices and principles a shot - we'd love to hear how they work for you!