Information security

This document outlines the areas we want you to consider. Which policies and procedures are right for your situation will depend on a number of factors, like your company size or whether or not you're storing consumer data.


In addition to asking for your information security policy, we interview new companies about their security posture. We understand that companies are making tradeoffs, and expect you to be able to defend your choices.

Network access control

If you maintain internet-connected servers, you'll want to consider:

  • What measures you have in place protecting your database or servers from unauthorized access
  • What third parties can connect to your system
  • Your management of secrets, keys, certificates

Network diagram

We typically ask for a network diagram. Your network diagram should include:

  • Network boundaries around your systems, clients, and partner systems
  • All third parties which access your system or that your system depends on
  • Broken out gateways and load balancers from API servers from databases

Monitoring and alerting

  • You should monitor your production systems.
  • Web application firewalls are one tool; these are commonly bundled with Application Load Balancers.
  • You should consider alerting on security events, like failed sign-ins.
  • You should consider formalizing an incident response plan.

Storing sensitive data

  • If users are trusting you with sensitive data, it's incumbent on you to take that trust seriously.
  • The Gramm-Leach-Bliley act specifically defines nonpublic personal information to include names, addresses, phone numbers, social security numbers, income, credit score, and information obtained through Internet collection devices (i.e., cookies).
  • You should consider what data you're storing and which systems have access to it.
  • Your databases likely have disk-level encryption. You'll want to consider column-level encryption for nonpublic personal information.
  • You should consider whether to allow your employees console access to production machines, and what kind of logging to put in place.
  • If your employees can impersonate users in your system, you should consider logging or placing limitations.

Device management

  • Employee devices are a significant attack vector.
  • You should consider centralizing provisioning of those devices. Mobile device management is one tool.
  • You should consider formalizing policies around third-party software, password management, disk encryption, and administrator privileges.
  • You should consider whether employee access to internal systems should happen over VPN.
  • You should consider asking employees to sign Confidentiality Agreements to protect customer information, as a condition of employment.

Change management

  • You should carefully scrutinize your deployment pipeline.
  • You should consider automated testing and staging environments.
  • You should consider requiring approval for deployment, and which employees may grant such approval.
  • You should consider tracking infrastructure in code, and subjecting changes to infrastructure to a similar review process.

User authentication

  • You should consider protecting user accounts, even against users' own lax security posture.
  • This section is most relevant to consumer applications.
  • You should consider multi-factor authentication.
  • You should have constraints on acceptable passwords. You should consider avoiding storing passwords yourself. If you do, you should learn about best practices.
  • You should consider tracking IP addresses associated with authentication events. In the right circumstances, you may consider allowlisting customer IP addresses.