Security statement

Sign up for our privacy notifications mailing list to keep up to date with changes.

ChartHop’s mission is to organize your people data. As part of that mission, protecting your sensitive data is one of our core values. You are entrusting us with sensitive data about your most critical resource, and we do our best to earn that trust.

This document describes the mechanisms and procedures we use to keep your data safe.

1. Infrastructure

  1. ChartHop is hosted on Amazon Web Services (AWS), in us-east-1 (Virginia datacenter), in a Virtual Private Cloud (VPC) in EC2 (Elastic Compute Cloud).
  2. All application servers are on private IP addresses and are not exposed on the public internet.
  3. All servers are configured from the official hardened CentOS 7, using automated configuration management software (Ansible) that ensures consistency across the infrastructure. Security patches are automatically applied multiple times a week.
  4. All servers use AWS Security Group firewall rules to minimally restrict ingress.
  5. A bastion host is used as the only point of SSH ingress.
  6. Access to the bastion host is secured via SSH key (no password logins).
  7. Access to the bastion host is firewalled such that only specifically whitelisted IP addresses can SSH to the port.
  8. All servers use IAM EC2 roles and fine-grained least-privilege-access custom IAM policies to access AWS resources.
  9. Administrative access to the AWS account is only permitted via a physical-key FIDO U2F two-factor authenticated login held by the ChartHop Founder & CEO/CTO.
  10. Credentials are encrypted using AWS Key Management Service, and the keys are rotated yearly. For information about AWS’s physical security and procedures, please refer to their Compliance page at: https://aws.amazon.com/compliance/

2. Data Storage

  1. ChartHop’s production data is stored using MongoDB Atlas, MongoDB’s hosted database service.
  2. Data storage is multi-tenant within ChartHop, but ChartHop does not share data storage resources with any other company. All data is tagged by customer organization id at every level, throughout the lifecycle. The primary Atlas servers are also hosted in us-east-1 and use peering, such that the appservers communicate privately with Atlas within the VPC.
  3. In addition to the fact that normal communication is within the VPC, the appservers only communicate with the database servers using TLS/SSL.
  4. The production databases are firewalled such that only the appservers can communicate with them.
  5. The production databases use authentication with strong passwords; these credentials are encrypted using AWS Key Management Service.
  6. All data in the database is stored encrypted-at-rest on encrypted volumes.
  7. MongoDB Atlas provides point-in-time backup restore capabilities, and the backups are retained for a period of one year.
  8. Administrative access to the MongoDB Atlas console is only permitted via two-factor authenticated login held by the ChartHop Founder & CEO/CTO.
  9. For more information about MongoDB’s security capabilities, please refer to their Security Controls white paper at: https://webassets.mongodb.com/_com_assets/collateral/Atlas_Security_Controls.pdf

3. Other Key Vendors

  1. ChartHop uses Sumo Logic for centralized logging of the platform. Our customers’ sensitive data is stripped from the logs, and access to Sumo Logic is restricted to two-factor authenticated users with a business need to access logs. Information about Sumo Logic’s security compliance procedures is available here: https://www.sumologic.com/security/platform-security/
  2. ChartHop uses Google’s G Suite product for corporate data storage and email. All ChartHop employees and contractors are required to use physical-key FIDO U2F two-factor authentication. Information about Google’s security compliance procedures is available here: https://gsuite.google.com/security/
  3. ChartHop uses GitHub for private code repositories. All ChartHop employees and contractors are mandated to use physical-key FIDO U2F two-factor authentication, and under no circumstances are private keys of any kind checked into the repositories. Information about GitHub’s security compliance procedures is available here: https://help.github.com/articles/github-security/
  4. ChartHop uses Slack for internal communication and system monitoring. Information about Slack's security compliance procedures is available here: https://slack.com/security

4. Application Security

  1. TLS/SSL is mandatory for all web requests made to ChartHop. Certificates are managed by Amazon’s Certificate Management service, and rotated and updated yearly.
  2. ChartHop’s appservers use Jetty and JAX-RS, expose a minimum surface area, and apply regular security patches.
  3. The appservers use Amazon’s Web Application Firewall rules to block known bot attackers.
  4. SQL injection attacks are not possible, as ChartHop does not use a SQL database. That said, all user input is sanitized, including use of OWASP's HTML sanitization libraries.
  5. ChartHop supports and strongly encourages the use of Single-Sign On (currently Google), rather than passworded logins. As a best practice we further recommend our customers use two-factor.
  6. Our SSO auth does not provide automatic access to anyone with a customer-domain email; they must still have an authorized ChartHop user account.
  7. For those customers that are not using SSO, strong passwords are required for user accounts.
  8. Passwords are one-way bcrypted in the database and are not recoverable; they can only be reset.
  9. Authentication requests are protected against brute-force attacks; they are limited to 5 failed attempts before the account is disabled.

5. Customer Security Controls

  1. ChartHop treats all data as confidential to each customer, but has additional controls around data designated “Sensitive”. This category of data includes:
    • Employee Compensation
    • Future Hires and Departures (not yet announced)
    • Voluntary / Involuntary status of Departures
    • Birth Year and Ethnicity
    • Employee Home Email, Phone Number, and Home Address
    • Private Scenarios, Comments, and Notes
    • Custom fields that can be designated Sensitive at your option.
  2. ChartHop provides several user access levels which allow customers to control which of their users have access to Sensitive data. These levels currently include:
    • Owner (allows setting user privileges and enabling integrations)
    • Technical Owner (allows configuring integrations without direct access to sensitive data)
    • Primary Editor (allows making official changes to primary org chart)
    • Sensitive View (allows viewing all employees’ sensitive data)
    • All Compensation View (allows viewing compensation, but not other sensitive data)
    • Cash Compensation View (allows viewing cash, but not equity compensation)
    • Equity Compensation View (allows viewing equity, but not cash compensation)
    • Personal Contact View (allows viewing personal contact information)
    • Time Off View (allows viewing time off information)
    • Recruiting Editor (allows making official changes to open roles only)
    • Recruiting View (allows viewing sensitive data of open roles only)
    • Member View (allows viewing employees who report into the user)
    • Limited View (no sensitive data visible)
  3. ChartHop allows restricting of the above access by department or team, or by customer-defined rules.
  4. All users are allowed to create Scenarios (proposals for changes to the org chart), but only Primary Editors or Owners are allowed to “merge”, or approve/finalize, those changes.
  5. Therefore, ChartHop’s recommendation is that, depending on the organization:
    • No more than 1-3 people receive Owner access
    • If needed, a very limited number of IT staff receive Technical Owner access
    • No more than a small number of people receive Primary Editor access
    • Sensitive View is only offered to individuals who have a business need to view sensitive information across the whole organization (for example, senior members of the executive team, or HR / Finance / Strategy roles)
    • Some members of the recruiting team receive Recruiting View or Recruiting Editor access
    • Most members of the organization, including department heads, receive Member View access
    • Limited View is offered to low-level members of the organization or consultants / contractors / temps.
  6. ChartHop provides a “View Sensitive Data” button in the user interface which can be toggled. When that button is toggled off, no sensitive data will be retrieved from the API or displayed in the user interface.
  7. ChartHop's API is available for customers to use and build applications on top of, using access-scoped tokens. Access levels can be set for API applications and tokens in the same way as users.
  8. All data access and changes made to data in ChartHop are logged, authenticated, and auditable.

6. Employee Access and Procedures

  1. ChartHop employees and contractors sign confidentiality agreements, and undergo security training.
  2. ChartHop employees and contractors all are required to use two-factor authentication using physical FIDO U2F keys.
  3. ChartHop laptops and mobile devices are configured to wipe remotely if they are misplaced.
  4. ChartHop customer-facing staff are only granted access to accounts that they directly interface with. If you are working with a support staff member, they will ask you to explicitly add them to your account before they can see your data.
  5. Many ChartHop engineers do not receive access to the production environment or data. They work strictly off of development or demo accounts.
  6. Some ChartHop engineers, in the course of their duties, do have access to the production environment. Such access is strictly controlled and periodically audited.
  7. ChartHop engineers are issued credentials and keys specific to that engineer with minimal access required for that engineer’s duties. These keys are revoked upon offboarding.
  8. ChartHop maintains strict separation of the production data and environment from local and development environments.

7. Data Sharing

  1. ChartHop does not share your data with third parties except at your explicit request.
  2. For example, we offer integrations that synchronize your data with other authenticated systems. Those integrations can only be enabled by a ChartHop customer with Owner or Technical Owner access, and the list of enabled integrations is visible on the Apps and Integrations page. We will not synchronize with any external service that you do not explicitly turn on.
  3. Similarly, ChartHop offers an API, which you can make use of, given appropriate access controls, to share ChartHop data with your other internal systems.
  4. To the extent we can, ChartHop offers you data portability - via API and export. You can leave and take your data with you.
  5. Upon termination, ChartHop will retain your data a period of up to one year, after which it will all be irrevocably hard-deleted and cannot be recovered. If you wish your data to be irrevocably deleted immediately upon termination, notify us and we will do so.
  6. ChartHop plans to offer anonymous, aggregated network insights to our members, such as industry benchmarks.
    • When ChartHop offers this service, (1) no information attributable to an individual, or an individual company, will ever be shared and (2) you will be notified, and will receive the option to opt out of inclusion in aggregation.

8. Breach Notification

  1. If ChartHop becomes aware of a data breach, we will notify our affected customers as soon as we have an understanding of the extent of the breach, but in any case no later than within 72 hours.
  2. ChartHop follows postmortem procedures in the event of any security or system failures and will publish and distribute postmortems to our customers.

Updated 05 May 2022
Did this page help?