Overview

General Data Protection Regulation (GDPR) is a regulation within the European Union (EU) that protects the data and privacy of all individuals in the EU and European Economic Area (EEA).

Catalyst is a “data processor” as defined in GDPR Article 4 Section 8 and our customers are the “data controllers” as defined in GDPR Article 4 Section 7. Catalyst will comply to all Data Processing Agreement (DPA) requests from customers when legally advised to do so.

The following sub-processors have access to the customer data Catalyst is processing on behalf of data controllers:
Catalyst Sub-Processors
Catalyst Sub-Processors
Google Cloud
Servers and network infrastructure
Amazon Web Services
Servers and network infrastructure
FullStory
Product usage reporting
Segment
Product usage reporting
Mixpanel
Product usage reporting
Catalyst is fully committed to protecting the data and privacy of our customers and the users they service. Please read our security whitepaper to learn about how Catalyst protects customer data.

If you have any questions or concerns please send us an email at privacy@getcatalyst.io.

SOC 2 Compliance

SOC 2 is an auditing procedure that ensures service providers securely manage data to protect the interests of organizations and the privacy of its clients. SOC 2 reports on controls at a service organization relevant to security, availability, processing integrity, confidentiality and/or privacy.

Catalyst is a SOC 2 compliant organization, as defined by the American Institute of Certified Public Accountants (AICPA).
Learn more about SOC 2 Compliance

Please​ ​provide​ ​a​ ​background​ ​on​ ​the​ ​company.

Catalyst is a B2B SaaS company building a software platform for customer success organizations. Catalyst is based out of NYC and funded by Accel, True Ventures, Ludlow Ventures, Compound, Work-Bench.


Describe​ ​in​ ​detail​ ​the​ ​mechanisms​ ​used​ ​to​​authenticate​ ​and​ ​authorize​ ​internal​ ​code​ ​and data​​access.

  • Users​ ​authenticate​ ​via​ ​ssh or username and password with 2-factor authentication enabled.
  • To​ ​authenticate​ ​via​ ​ssh​ ​they​ ​use​ ​their​ ​username​ ​ssh​ ​key,​ ​and​ ​all​ ​users​ ​have​ ​individual user​ ​names​ ​and​ ​personal​ ​ssh​ ​keys.
  • People​ ​are​ ​asked​ ​to​ ​generate​ ​4096​ ​bit​ ​key​ ​pairs.
  • SSH​ ​with​ ​username​ ​and​ ​password​ ​is​ ​disabled.
  • We​ ​authorize​ ​and​ ​maintain​ ​an​ ​accurate​ ​list​ ​of​ ​authorized​ ​users​ ​and​ ​ssh​ ​keys​ ​via​ GCP/AWS IAM and a secure password manager.

To​ ​authenticate​ ​and​ ​authorize​ ​internal​ ​access​ ​are​ ​services​ ​like​ ​LDAP​ ​or​ ​Active​ ​Directory used?

Not at the moment. We will be implementing a formal service in the coming months

Are​ ​data​ ​assets​ ​encrypted​ ​in​ ​transit​ ​and/or​ ​at​ ​rest?​ ​​ ​If​ ​so,​ ​what​ ​is​ ​the​ ​encryption strength?

All data assets are encrypted in transit and at rest. All data assets in transit are encrypted via TLS 1.2 using 256-bit encryption. All data assets at rest are encrypted using AES-256 encryption.

Does​ ​your​ ​server​ ​offer​ ​forward​ ​secrecy​ ​for​ ​clients​ ​that​ ​support​ ​it?

Yes.

Where​ ​is​ ​the​ ​SSL​ ​connection​ ​between​ ​the​ ​user​ ​and​ ​your​ ​application​ ​terminated?

At​ ​the​ ​load​ ​balancer. Internally, traffic is encrypted and certificates between load balancer and application servers are validated.

How​ ​do​ ​you​ ​protect​ ​against​ ​SQL​ ​injection?

We​ ​use​ ActiveRecord in Rails ​as​ ​our​ ​ORM,​ ​which​ ​has​ ​SQL​ ​injection​ ​sanitizing​ ​cleaning​ ​included.

Does​ ​your​ ​application​ ​use​ ​any​ ​single-sign​ ​on​ ​SSO​ ​mechanisms?

OpenID​ ​Connect​ ​/​ ​OAuth2​ ​Login​ ​in​ ​the​ ​form​ ​of​ ​Google​ ​Apps​ ​OAuth.

When​ ​manually​ ​constructing​ ​queries,​ ​how​ ​do​ ​you​ ​preserve​ ​SQL​ ​injection​ ​protection?

The built-in methods and filters of the Rails framework protects us from SQL injection. With the use of ActiveRecord, we do not apply manually constructed queries.

Does​ ​your​ ​application​ ​load​ ​active​ ​content,​ ​such​ ​as​ ​scripts,​ ​applets​ ​or​ ​style​ ​sheets​ ​from third​ party​ ​servers?

Yes, ​we​ ​only​ ​load​ ​third​ ​party​ ​content from trusted third parties enforced by our content security policy.

Is​ ​all​ ​content​ ​you​ ​load​ ​to​ ​the​ ​DOM​ ​protocol-relative?

Yes,​ ​and​ ​if​ ​the​ ​user​ ​reaches​ ​our​ ​site​ ​in​ ​HTTP,​ ​we​ ​redirect​ ​to​ ​HTTPS

If​ ​your​ ​application​ ​supports​ ​authentication,​ ​are​ ​authentication​ ​cookies​ ​marked​ ​with​ ​the secure​ ​attribute?

Yes,​ ​the​ ​authentication​ ​cookies​ ​are​ ​marked​ ​with the secure attribute.

How​ ​do​ ​you​ ​guard​ ​against​ ​XSS?

Rails framework has a built-in XSS protection mechanism which automatically HTML escapes all the data being transferred from Rails to HTML.

Does​ ​the​ ​application​ ​set​ ​a​ ​valid​ ​and​ ​appropriate​ ​content​ ​type​ ​and​ ​character​ ​set​ ​for​ ​each page​ ​(in​ ​the​ ​Content-Type​ ​HTTP​ ​header)?

Yes,​ ​we​ ​take​ ​great​ ​care​ ​to​ ​set​ ​this,​ ​knowing​ ​that​ ​otherwise​ ​we​ ​might​ ​be​ ​introducing​ ​XSS vulnerabilities.

What​ ​are​ ​the​ ​requirements​ ​for​ ​passwords​ ​on​ ​systems​ ​holding,​ ​processing,​ ​or transporting​ ​data?

To connect to the systems holding the data(databases), the user is required to use TLS connections with username and password. The password must be:

  • Be a minimum of sixteen (16) characters in length.
  • Be memorized; if a password is written down it must be secure.
  • Be rotated quarterly.
  • Contain at least one (1) character from three (3) of the following categories:
  1. Uppercase letter (A-Z)
  2. Lowercase letter (a-z)
  3. Digit (0-9)
  4. Special character (~`!@#$%^&*()+=_-{}[]\

Do​ ​you​ ​support​ ​SAML​ ​or​ ​Google​ ​Apps?

Yes, both SAML and Google Apps.

Are​ ​regular​ ​backups​ ​of​ ​data​ ​on​ ​all​ ​systems​ ​performed?

We​ ​have​ ​daily​ ​automated​ ​backups​ ​of​ ​our​ ​databases and retain it for 30 days.

Is​ ​backup​ ​media​ ​encrypted​ ​and​ ​securely​ ​stored​ ​off-site​ ​at​ ​a​ ​protected​ ​facility,​ ​which​ ​is sufficiently​ ​distant​ ​from​ ​the​ ​processing​ ​site?​ ​What​ ​is​ ​the​ ​strength​ ​of​ ​the​ ​encryption?

Yes,​ ​backups​ ​are​ ​encrypted​ ​using​ ​AES-256​ using regularly rotated keys.

When​ ​not​ ​specified​ ​in​ ​customer​ ​contracts,​ ​describe​ ​your​ ​data​ ​retention​ ​standards​ ​in detail​ ​for​ ​information​ ​stored​ ​in​ ​your​ ​environment?

Once​ ​the​ ​contract​ ​is​ ​cancelled​ ​we​ ​purge​ ​the​ ​client’s​ ​data​ ​from​ ​production​ ​in​ ​the​ ​following​ ​30 days. Once​ ​the​ ​data​​ ​is​ ​gone​ ​from​ ​production​ the​ ​data​ ​is​ ​still​ ​in​ ​backups​ ​for​ ​an​ ​additional​ ​30​ ​days. After​ ​30​ ​days​ ​the​ ​data​ ​is​ gone​ ​from​ ​our​ ​system.

Can​ ​you​ ​ensure​ ​the​ ​client’s​ ​data​ ​will​ ​not​ ​be​ ​removed​ ​or​ ​destroyed​ ​unless​ ​action​ ​to​ ​do​ ​so initiated​ ​by​ ​client​ ​--​ ​unless​ ​otherwise​​documented​ ​in​ ​the​ ​agreement?

Yes.

Is​ ​there​ ​a​n escalation process​ ​in​ ​place​​ for incidents or security breaches? How are incidents reported?

P0 ​Process

  • In​ ​the​ ​scenario​ ​where​ ​a​ ​high​ ​severity​ ​issue​ ​is​ ​identified​ ​that​ ​requires​ ​attention and​ ​resolution​ ​outside​ ​of​ ​the​ ​normal​ ​sprint​ ​process,​ ​the​ ​team​ ​has​ ​an​ ​escalation process​ ​in​ ​place.
  • Specific​ ​“severity”​ ​field​ ​on​ ​tickets,​ ​when​ ​set,​ ​implements​ ​a​ ​set​ ​of​ messaging notifications​ ​that​ ​are​ ​sent​ ​to​ engineering ​staff​ ​who​ ​are​ ​on​ ​call​ ​to​ ​deal​ ​with​ ​these​ ​kinds of​ ​issues​ ​for​ ​immediate​ action.

Reporting an Incident

  • Customers should report any issues or concerns through or in-application support channel. Our support team will report the issue to our engineering team for resolution and stay in constant communication with you regarding its status.
  • You can always contact security@getcatalyst.io for any other issues or concerns.

How​ ​do​ ​you​ ​identify​ ​where​ ​the​ ​client’s​ ​data​ ​resides​ ​within​ ​your​ ​organization?

All​ ​database​ ​tables​ ​with​ ​user​ ​data​ ​includes​ ​an​ customer_id ​column ​and​ ​all​ ​the​ ​data​ ​that​ ​belongs​ ​to the​ ​same​ customer ​is​ ​marked​ ​with​ ​the​ ​same​ customer_id.

Are​ ​there​ ​mechanisms​ ​in​ ​place​ ​to​ ​ensure​ ​that​ all​ ​changes​ ​are​ ​adequately​ ​tested​ ​in​ ​a​ ​test environment​ ​prior​ ​to​ ​implementing​ ​in​ ​production?

All changes are first tested in a local environment. Then it must pass a code review from a different engineer. We​ ​use​ continuous integration ​to​ ​ensure​ ​that​ ​every​ ​commit​ ​triggers​ automated ​unit​ and functional tests before it is merged into the `staging` branch.​ Once the code is merged into the `staging` branch, it is deployed onto a staging environment for further automated and manual testing. Finally, the `staging` branch is merged into the `master` branch, deployed to the production environment, and then another set of automated tests are executed.

Who​ ​has​ ​access​ ​to​ ​client​ ​data?

Access to customer data is only granted to trained employees as needed to perform authorized job functions. Access is easily revokable and all activity is logged.

Are​ ​vendor​ ​default​ ​passwords​ ​removed,​ ​disabled​ ​or​ ​changed​ ​prior​ ​to​ ​placing​ ​the​ ​device or​ ​system​ ​into​ ​production?

Yes.

Does​ ​your​ ​application​ ​use​ ​test​ ​or​ ​custom​ ​accounts​ ​during​ ​the​ ​development​ ​process?​ ​If so,​ ​how​ ​are​ ​those​ ​accounts​ ​removed​ ​and/or​ ​sanitized​ ​before​ ​the​ ​application​ ​is​ ​promoted to​ ​a​ ​production​ ​environment?

Yes.​ ​The​ mock ​data​ ​is​ ​in​ ​the​ ​development​ ​database​ ​and​ ​the​ ​code​ ​acts​ ​as​ ​if​ ​this​ mock ​data​ ​is​ production ​data. We​ ​don't​ ​share​ ​the​ mock ​data​ ​with​ ​the production database.

Do​ ​you​ ​utilize​ ​"Cloud​ ​Computing"?​ ​If​ ​so,​ ​please​ ​explain.

Our network, servers, and databases are hosted by cloud providers.

What​ ​is​ ​the​ ​name​ ​of​ ​the​ ​cloud​ ​service​ ​provider?

Google Cloud Platform (GCP) and Amazon Web Services (AWS)

Does​ ​your​ ​Cloud​ ​Service​ ​Provider​ ​possess​ ​any​ ​of​ ​the​ ​following:​ ​​ ​ISO​ ​27001​ ​Certification, SOC-2​ ​Audit​ ​Report,​ ​SSAE​ ​16​ ​Audit​ ​Report,​ ​FISMA​ ​Certification?

How​ ​is​ ​customer​ ​data​ ​handled​ ​between​ ​original​ ​source​ ​(e.g.,​ ​Google,​ ​Salesforce)​ ​and​ ​the company’s​ ​database?

All​ ​API​ ​queries​ ​are​ ​made​ ​with​ ​HTTPS​ ​so​ ​data​ in transit ​is​ ​encrypted.

Geographically​ ​speaking,​ ​where​ ​will​ ​data​ ​be​ ​stored?

The United States.

Please​ ​explain​ ​how​ ​data​ ​is​ ​segregated​ ​from​ ​other​ ​customers​ ​e.g​ ​are​ ​VNs​ ​(Virtual Networks)​ ​used?

  • Customer​ ​data​ ​is​ ​segregated​ ​via​ ​the​ customer_id ​row-level​ ​tagging​ ​approach​ ​described above.
  • To​ ​segregate​ ​customer​ ​data​ ​from​ ​other​ ​clouds​ ​data​ ​we​ ​use​ an individual database instance.

How​ ​will​ ​data​ ​be​ ​transmitted​ ​between​ ​your​ ​organization​ ​and​ ​the​ ​client​ ​or​ ​a​ ​third​ ​party?

TLS.

Please​ ​describe​ ​the​ ​usage​ ​of​ ​Transport​ ​Layer​ ​Security​ ​(TLS)​ ​for​ ​any​ ​network communication​ ​in​ ​your​ ​environment. Please​ ​provide​ ​version​ ​of​ ​TLS​ ​used.​

TLS 1.2 is used for any network communication.

Is​ ​SSL​v3 disabled?

Yes,​ ​SSL​v3​ ​is​ ​disabled.

Have​ ​you​ ​deployed​ ​HTTP​ ​Strict​ ​Transport​ ​Security​ ​(HSTS)​ ​on​ ​your​ ​server?

Yes.​

Do​ ​you​ ​use​ ​HttpOnly​ ​on​ ​cookies?

Yes.

How​ ​do​ ​you​ ​construct​ ​your​ ​Session​ ​IDs?

The session ID is generated using SecureRandom.hex which generates a random hex string using platform specific methods (such as OpenSSL, /dev/urandom or Win32 CryptoAPI) for generating cryptographically secure random numbers. It is not possible to brute-force Rails' session IDs.

Do​ ​sessions​ ​automatically​ ​time​ ​out​ ​after​ ​a​ ​specified​ ​period​ ​of​ ​inactivity?

Sessions (cookies) ​expire​ ​after​ 7 ​days of inactivity.​

Does​ ​your​ ​application​ ​offer​ ​a​ ​“log​ ​out”​ ​button​ ​that​ ​not​ ​only​ ​terminates​ ​a​ ​session​ ​but invalidates​ ​the​ ​session​ ​ID?

Yes.

Does​ ​the​ ​application​ ​use​ ​a​ ​secure​ ​cryptographic​ ​pseudo​ ​random​ ​number​ ​generator (PRNG)​ ​to​ ​generate​ ​session​ ​IDs?

Yes.

Does​ ​your​ ​application​ ​protect​ ​all​ ​state-changing​ ​actions​ ​against​ ​XSRF?

Yes.​ A CSRF sceurity token is transmitted between client and server and validated on every state changing request.

Does​ ​your​ ​application​ ​guard​ ​against​ ​clickjacking?

We​ ​protect​ ​against​ ​clickjacking​ ​using​ ​X-Frame-Options: SAMEORIGIN

Do​ ​you​ ​implement​ ​Horizontal​ ​Access​ ​Control​ ​such​ ​that​ ​users​ ​cannot​ ​access​ ​other​ ​user’s data​ ​through​ ​URL​ ​hacking​ ​and​ ​such?

Yes.

Do​ ​you​ ​implement​ ​Vertical​ ​Access​ ​Control​ ​such​ ​that​ ​users​ ​cannot​ ​access​ ​other​ ​user’s data​ ​who​ ​are​ ​of​ ​higher​ ​privilege​ ​than​ ​them?

Yes.

Please​ ​describe​ ​the​ ​usage​ ​of​ ​Secure​ ​Shell​ ​(SSH)​ ​for​ ​any​ ​network​ ​communication​ ​in​ ​your environment.​​ ​​​​Please​ ​provide​ ​the​ ​version​ ​of​ ​SSH​ ​used.

We​ ​use​ ​SSH​ ​to​ ​login​ ​into​ ​the​ ​publicly​ ​accessible​ ​servers.​ ​We​ ​use​ SSH ​with​ ​certificate​ ​only and​ ​we have​ ​disabled​ SSH ​with​ ​user​ ​and​ ​password.

Version: OpenSSH_7.6p1, LibreSSL 2.6.2

Describe​ ​your​ ​Cryptographic​ ​key​ ​management​ ​process​.

  • We utilize GCP and AWS key management services.
  • Our​ ​keys​ ​are​ rotated on a regular basis.

How​ ​often​ ​are​ ​inactive​ ​userID(s)​ ​deleted​ ​or​ ​disabled​ ​after​ ​they​ ​are​ ​no​ ​longer​ ​needed?

We​ ​​delete or disable​ un-needed ​users​ ​as soon as possible.

Security​ ​requirements​ ​for​ ​your​ ​encryption​ ​keys:​

  • We require 256-bit strength for symemetric keys
  • People​ ​are​ ​asked​ ​to​ ​generate​ ​4096​ ​bit​ ​key​ ​pairs​ ​to​ SSH ​into​ ​the​ ​infrastructure

How​ ​are​ ​keys​ ​managed?

  • Local keys are stored securely using a password manager.
    For​ ​server​ ​side​ ​keys,​ ​we​ ​use​ AWS and GCP KMS

Are​ ​clear​ ​text​ ​login​ ​passwords​ ​to​ ​Internet​ ​accessible​ ​systems​ ​are​ ​prohibited​ ​by​ ​your organization?

Yes.

Wireless​ ​network​ ​connections​ ​used​ ​to​ ​transmit​ ​confidential​ ​information​ ​are​ ​protected​ ​by technology​ ​stronger​ ​than​ ​WEP​ ​(e.g.,​ ​WPA,​ ​IPSEC,​ ​SSL/TLS,​ ​etc.)

  • Yes.​ ​The​ ​security​ ​of​ ​our​ ​wireless​ ​network​ ​connection​ ​is​ ​WPA2​ ​Personal
  • All​ ​confidential​ ​communications​ ​are​ ​done​ ​using​ TLS

Password​ ​storing,​ ​password​ ​policy,​ ​password​ ​reset,​ ​etc

  • The Catalyst application ​uses​ ​Google​ ​Apps​ ​SSO​ ​to​ ​authorize​ ​users​ ​into​ ​the​ ​system.
  • No​ ​passwords​ ​are​ ​stored.
  • There​ ​is​ ​no​ ​restore​ ​password​ ​process​ ​for​ the Catalyst application.

Are​ ​unique​ ​user​ ​IDs​ ​used​ ​for​ ​access​ ​to​ ​any​ ​system​ ​collecting,​ ​storing​ ​or​ ​processing data?

Yes.​ ​Each​ ​user​ ​has​ ​a​ ​unique​ ​user​ ​ID​ ​and​ ​uses​ ​his​ ​or​ ​her​ ​ssh​ ​keys.

Do​ ​you​ ​have​ ​a​ ​process​ ​to​ ​revoke​ ​customer​ ​data​ ​access​ ​from​ ​PEL​ ​employees?

Yes, we have a set process for revoking access to customer data from PEL employees. Once the administrator is notified, they will remove the employee from all servers that are relevant.

What​ ​is​ ​your​ ​disaster​ ​recovery​ ​and​ ​business​ ​continuity​ ​policy?

All data is backed up and are systems are fully restorable in the case of disaster. We regularly test our process for disaster recovery.

Our business continuity plan consists of three phases: i) Activitation and Notification, ii) Recovery, and iii) Reconstitution. Training and testing of this plan is conducted on a regular basis.

What​ ​are​ ​your​ ​internal​ ​procedures​ ​in​ ​the​ ​event​ ​of​ ​a​ ​data​ ​spill?

Our​ ​internal​ ​procedures​ ​for​ ​data​ ​spills​ ​follow​ ​the​ ​Report,​ ​Analyze​ ​&​ ​Assess,​ ​Clean​ ​&​ ​Rectify, Document​ ​&​ ​Learn​ ​stepwise​ ​process.

First,​ ​engineering​ ​identifies​ ​the​ ​owner(s)​ ​of​ ​the​ ​spilled​ ​data,​ ​and​ ​reports​ ​the​ ​level​ ​of​ ​the​ ​spill. Second,​ ​engineering​ ​analyzes​ ​the​ ​nature​ ​of​ ​the​ ​spilled​ ​data​ ​and​ ​potential​ ​access​ ​to​ ​determine impact.​ ​Based​ ​on​ ​this​ ​analysis, ​the​ ​engineering​ ​organization​ ​moves​ ​to​ ​remedy​ ​the​ spill​ ​using the​ ​relevant​ ​sanitization​ ​technologies. Also when necessary, engineering will notify the account management team so that impacted customers will be notified as soon as possible.​ ​Lastly​ ​a​ ​post-mortem​ ​is​ ​performed,​ ​and​ ​all​ ​prior​ ​findings are​ ​documented​ ​to​ ​then​ ​be​ ​embedded​ ​in​ ​ongoing​ ​security​ ​training​ ​and​ ​education​ ​program.

What​ ​is​ ​your​ ​Security​ ​awareness​ ​training/education​ ​program?

All​ ​engineering​ ​staff​ ​are​ ​put​ ​through​ ​a​ ​security​ ​education​ ​program​ ​as​ ​part​ ​of​ ​onboarding, specifically​ ​around​ ​key​ ​management,​ ​endpoint​ ​security,​ ​and​ ​other​ ​topics.

Are​ ​non-disclosure​ ​agreements​ ​enforced​ ​with​ ​anyone​ ​handling​ ​confidential​ ​data?

All​ ​staff​ ​who​ ​have​ ​access​ ​to​ ​customer​ ​data​ ​are​ ​subject​ ​to​ ​NDAs.

Are​ ​there​ ​access​ ​control​ ​and/or​ ​intrusion​ ​detection​ ​alarm​ ​monitoring​ ​systems​ ​recording door​ ​opening,​ ​door​ ​closing,​ ​and​ ​all​ ​access​ ​attempts?

Yes.

Are​ ​all​ ​authorized​ ​guests/visitors​ ​required​ ​to​ ​sign​ ​in​ ​and​ ​out​ ​of​ ​the​ ​access​ ​logbook​ ​and be​ ​escorted​ ​at​ ​all​ ​times?

Yes.