Security Review

Security review of third parties is often neglected at early stage companies, with decision making purely driven based on adjacency (this is the first result I found, I'm using tool x already!) or prior experience with the tool. This is fine but sometimes we want to add more rigor to the decision making, especially when working with sensitive data. Getting this in place without adding a lot of bureaucracy is a challenge - afterall, you're a startup and you want to move as quickly as possible. You also probably don't have the resource for someone to focus on this as part of their role. The idea of this template is to provide a scorecard that can be used by anyone to quickly appraise the security posture of a third party bit of software. This allows for the decision making to be decentralised, but also means that where it does need to be bubbled up for further discussion, it is.

Security Review Checklist (TEMPLATE)

Completed By: @yourself

Date: **@Today**

You should be able to find out the majority of the answers to these questions by browsing the vendor’s website. If you’re struggling then it may be worth scheduling a call with a sales rep and seeing if you can answer the questions. If you’re still having issues or this is a major account and you think it needs some extra scrutiny, then reach out to <who’s in charge here?> and they can have a chat with their engineering team.

It should take about 1 hour to complete - if it’s taking longer then reach out to <who’s in charge here?> for support.

Third Party Security Testing

Aim for at least three of the below.

  • SOC2 Compliant (you might see something like Type 1 or Type 2 after the statement of compliance, either is fine)
  • ISO Certified (you might see something like 27001 after the statement)
  • PCI DSS certification (only applicable to platforms that handle payments or card data)
  • Annual (or better) Security Pen Test (are they prepared to share it under NDA?)
  • Annual (or better) Security Review (i.e. white box style review rather than a pen test; this is rare)

Data Storage, Processing and Recovery

Aim for at least five of the following statements:

  • The vendor is using a major cloud provider like AWS, GCP or Azure for all of their hosting
  • Data is always encrypted in transit (HTTPS, ≥TLS 1.2)
  • Data is always encrypted at rest (AES-256 key encryption or better)
  • Data is backed up (ideally at least daily)
  • Backups are tested by a full restore
  • They have a Disaster Recovery Plan
  • The Disaster Recovery Plan is tested at least annually
  • We can export data from our account manually
  • We can export data from our account using an API

Access Controls

Aim for at least 2 of the following statements**:**

  • They can provide SSO support (SAML based workflow required; we use AWS SSO at Bother)
  • They can provide 2 factor or multi factor authentication (MFA)
  • They provide Role Based Access Controls (RBAC)
  • They can provide audit logging on access changes
  • They can provide audit logging on sensitive or confidential data access

Security Incidents

Aim for 1 of the below:

  • There’s NOT been a security incident, hack, ethical hack, disclosure or data breach in the past 5 years (have a Google with each keyword and see what you find)
    • If there has reach out to <who’s in charge here?> for review and fire over the link of what you found

Security Operations

Aim for at least 2 of the below:

  • They have a security team (typically ~3 people in a 100 person organisation)
  • They have a security incident process, and they have SLAs in place for response
  • They have some sort of intrusion detection system or security monitoring
  • They have a Security Incident Event Management (SIEM) system
  • Their staff have security awareness training, typically annually
  • If staff can access payment or sensitive data, then background checks (i.e. criminal record, reference checks) are conducted (staff may also have signed something like a confidentiality agreement)

Secure Development

Bonus questions, might only be available if we chat with their sales or engineering team:

  • Vulnerability Scanning
  • Static Analysis (SAST)
  • Production and Test environments are kept separate
  • Secrets are managed (i.e. ephemeral credentials)
  • Configuration is treated as code
  • Insecure dependency alerting
  • There is a Bug bounty program
  • They are using open sourced software
  • They have a process for security disclosure
# Security Review Checklist (TEMPLATE)

**Completed By: `@yourself`**

**Date:** `**@Today**`

**<remove me>**

You should be able to find out the majority of the answers to these questions by browsing the vendor’s website. If you’re struggling then it may be worth scheduling a call with a sales rep and seeing if you can answer the questions. If you’re still having issues or this is a major account and you think it needs some extra scrutiny, then reach out to <who's in charge here?> and they can have a chat with their engineering team. 

It should take about **1 hour to complete** - if it’s taking longer then reach out to <who's in charge here?> for support.

**<remove me>**

### Third Party Security Testing

Aim for **at least three** of the below.

- [ ]  SOC2 Compliant (you might see something like Type 1 or Type 2 after the statement of compliance, either is fine)
- [ ]  ISO Certified (you might see something like 27001 after the statement)
- [ ]  PCI DSS certification (only applicable to platforms that handle payments or card data)
- [ ]  Annual (or better) Security Pen Test (are they prepared to share it under NDA?)
- [ ]  Annual (or better) Security Review (i.e. white box style review rather than a pen test; this is rare)

### Data Storage, Processing and Recovery

Aim for **at least five** of the following statements:

- [ ]  The vendor is using a major cloud provider like AWS, GCP or Azure for all of their hosting
- [ ]  Data is always encrypted in transit (HTTPS, ≥TLS 1.2)
- [ ]  Data is always encrypted at rest (AES-256 key encryption or better)
- [ ]  Data is backed up (ideally at least daily)
- [ ]  Backups are tested by a full restore
- [ ]  They have a Disaster Recovery Plan
- [ ]  The Disaster Recovery Plan is tested at least annually
- [ ]  We can export data from our account manually
- [ ]  We can export data from our account using an API

### Access Controls

Aim for **at least 2** of the following statements**:**

- [ ]  They can provide SSO support (SAML based workflow required; we use AWS SSO at Bother)
- [ ]  They can provide 2 factor or multi factor authentication (MFA)
- [ ]  They provide Role Based Access Controls (RBAC)
- [ ]  They can provide audit logging on access changes
- [ ]  They can provide audit logging on sensitive or confidential data access

### Security Incidents

**Aim for 1** of the below:

- [ ]  There’s NOT been a `security incident`, `hack`, `ethical hack`, `disclosure` or `data breach` in the past 5 years (have a Google with each `keyword` and see what you find)
    - [ ]  If there has reach out to <who's in charge here?> for review and fire over the link of what you found

### Security Operations

**Aim for at least 2** of the below:

- [ ]  They have a security team (typically ~3 people in a 100 person organisation)
- [ ]  They have a security incident process, and they have SLAs in place for response
- [ ]  They have some sort of intrusion detection system or security monitoring
- [ ]  They have a Security Incident Event Management (SIEM) system
- [ ]  Their staff have security awareness training, typically annually
- [ ]  If staff can access payment or sensitive data, then background checks (i.e. criminal record, reference checks) are conducted (staff may also have signed something like a confidentiality agreement)

### Secure Development

Bonus questions, might only be available if we chat with their sales or engineering team:

- [ ]  Vulnerability Scanning
- [ ]  Static Analysis (SAST)
- [ ]  Production and Test environments are kept separate
- [ ]  Secrets are managed (i.e. ephemeral credentials)
- [ ]  Configuration is treated as code
- [ ]  Insecure dependency alerting
- [ ]  There is a Bug bounty program
- [ ]  They are using open sourced software
- [ ]  They have a process for security disclosure