Resources

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 AlamaLinux, 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 Single Sign-On, which leverages multi-factor authentication including either a physical hardware token or biometric, to a limited number of ChartHop employees.
  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 Single Sign-On, which leverages multi-factor authentication including either a physical hardware token or biometric, to a limited number of ChartHop employees.
  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 Datadog for centralized logging of the platform. Our customers’ sensitive data is stripped from the logs, and access to Datadog is restricted to multi-factor authenticated users with a business need to access logs. Information about Datadog’s security compliance procedures is available here: https://www.datadoghq.com/security/
  2. ChartHop uses Google’s G Suite product for corporate data storage and email. All ChartHop employees and contractors are required to use multi-factor authentication including either a physical hardware token or biometric. 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 multi-factor authentication, including either a physical hardware token or biometric, 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. Amazon’s Certificate Management service manages certificates, which are automatically rotated 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 an SQL database. That said, all user input is sanitized, including using OWASP's HTML sanitization libraries.
  5. ChartHop supports and strongly encourages the use of Single Sign-On rather than passworded logins and supports SAML, Google Workspace, and other methods. As a best practice, we further recommend that our customers use multi-factor authentication.
  6. Our Single Sign-On 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 who are not using SSO, strong passwords are required for user accounts.
  8. Passwords are one-way hashed using bcrypt 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)
    • People Ops Admin (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 annual security training.
  2. ChartHop employees and contractors are all required to use multi-factor authentication, including either a physical hardware token or biometric.
  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.
  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 have access to the production environment in the course of their duties. 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 28 Mar 2025
Doc contributor
Doc contributor
Did this page help you?
PREVIOUS
AI Usage Policy
NEXT
Subprocessors
Docs powered by Archbee