Catalyst Security

Catalyst cares deeply about the security of our customers. We work continuously to ensure the protection of your privacy and data. If you have any questions please reach out to hello@getcatalyst.io.

Last updated: June 13, 2018

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 Why & How Data is Used
Heroku Servers and network infrastructure
Amazon Web Services Servers and network infrastructure
FullStory Product usage reporting
Segment Product usage reporting
Mixpanel Product usage reporting
Drift Customer support and sales

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 hello@getcatalyst.io.

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 True Ventures, Ludlow Ventures, and Compound.


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​ AWS IAM, Keybase, and OnePassword.

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 HTTPS SSL at 256-bit encryption strength via Heroku and AWS. All data assets at rest are stored using AWS RDS which uses AES-256 encryption.


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

Yes.​ ​This​ ​is​ ​a​ ​feature​ ​of​ Heroku SSL.


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

At​ ​the​ ​load​ ​balancer,​ ​and​ ​from​ ​there​ inbound requests are passed directly to a set of routers.


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​ ​data​ ​from​ GoogleAPIs and NewRelic.


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 SSL 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.
  • Contain at least one (1) character from three (3) of the following categories:
    • Uppercase letter (A-Z)
    • Lowercase letter (a-z)
    • Digit (0-9)
    • Special character (~`!@#$%^&*()+=_-{}[]\
  • Be rotated every quarterly.

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 35 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​ ​with​ ​a​ ​256​ ​bits​ ​key​ ​that​ ​rotates​ ​yearly. AWS​ ​RDS stores​ ​the​ ​backups.


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​ ​formalized​ ​process​ ​in​ ​place​ ​to​ ​track,​ ​mitigate​ ​or​ ​accept​ ​risks​ ​identified​ ​through audits,​ ​risk​ ​assessments,​ ​monitoring,​ ​testing,​ ​etc.?

  • Product​ ​and​ ​Issue​ ​Planning​ ​Process:
    • Product​ ​Planning​ ​Process​ ​considers​ ​user​ ​feature​ ​requests​ ​and​ ​bugs​ ​discovered post-release.
    • Product​ ​development​ ​process​ ​cadence​ ​is​ ​traditional​ ​agile​ ​process​ ​of​ ​two-week sprints,​ ​where​ ​sprint​ ​planning​ ​considers​ ​product​ ​roadmap​ ​and​ ​outstanding​ ​bugs and​ ​prioritizes​ ​based​ ​on​ ​importance,​ ​severity​ ​and​ ​level​ ​of​ ​effort.
    • Bugs​, ​feature​ ​requests, and tech debt​ are​ ​logged​ ​in​ ​JIRA​ ​for consideration,​ ​execution,​ ​and​ ​then​ ​historical​ ​reference.
  • 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​ ​JIRA​ ​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.

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?

Only​ ​our​ ​engineering​ ​team​ ​has​ ​access​ ​to​ ​the client data.


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.

  • Heroku for all hosting/infrastructure except for data
  • Amazon Web Services Relational Database (AWS RDS) for data storage

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

Heroku and Amazon Web Services


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

Yes.​ https://aws.amazon.com/compliance/ (Heroku is hosted on AWS)


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?

AWS RDS​ US-EAST-1 North Virginia


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?

HTTPS SSL​


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

We​ ​use​ ​the​ Automated Certificate Management​ ​provided​ ​by​ Heroku and it uses TLS version 1.2.


Is​ ​SSL​v3 disabled?

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


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

Yes.​ ​Rails framework ​does​ ​this​ ​for​ ​us.


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.​ Rails framework adds a header called X-CSRF-Token with the security token on every non-GET Ajax call. Without this header, non-GET Ajax requests won't be accepted by Rails. The​ ​application​ ​verifies​ ​the​ X-CSRF-Token ​header, and ​requires​ ​all​ ​state-changing​ ​actions​ ​to​ ​be​ ​POST requests.


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​ ​including​ ​storage​ ​devices,​ ​key fragmentation,​ ​key​ ​officers,​ ​etc.

  • We​ ​use​ ​Amazon​ ​IAM​ ​to​ ​manage​ ​and​ ​store​ ​our​ ​cryptographic​ ​keys.
  • Our​ ​keys​ ​are​ ​rotated​ ​yearly.
  • Our​ ​key​ ​officer is Jianghao Wang

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

We​ ​try​ ​to​ ​delete or disable​ ​users​ ​as soon as possible.


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

  • Our​ ​system​ ​uses​ ​IAM​ ​symetrics​ ​keys​ ​that​ ​are​ ​256-bits
  • People​ ​are​ ​asked​ ​to​ ​generate​ ​4096​ ​bit​ ​key​ ​pairs​ ​to​ SSH ​into​ ​the​ ​infrastructure

How​ ​are​ ​keys​ ​managed?

  • For​ ​local​ ​keys​ ​used​ ​for​ ​SSH,​ ​we​ ​use​ OnePassword and Keybase.
  • For​ ​server​ ​side​ ​keys,​ ​we​ ​use​ ​Amazon​ ​IAM

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​ ​SSL/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?

  • We have two dynos(servers) running for the web service on Heroku. It’s not guaranteed that these two dynos are in different availability zones, but it reduces the risk of service going offline due to server issues. We are still open to downtime caused by Heroku,​ ​but​ ​constrained​ ​by​ ​Heroku’s downtime​ ​frequency,​ ​which​ ​is​ ​extremely​ ​infrequent.
  • In the situation when Heroku goes down, we currently do not have other solutions to bring our service back online.
  • For​ ​instance​ ​issues,​ ​we​ can quickly spin up more dynos on Heroku to serve the higher usage.
  • For​ ​database​ ​issues,​ ​we​ ​have​ ​daily​ ​database​ ​snapshots​ ​that we​ ​can​ ​restore from. Also,​ ​Amazon​ ​RDS​ ​has​ ​“point​ ​in​ ​time”​ ​restore​ ​that​ ​is​ ​minute​ ​by​ ​minute​ ​for​ ​restore.

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.