Our security platform is founded on the controls we have built into our service to protect customer data.
We regularly assess risk, monitor our controls, evaluate potential threats, and use this information to update our controls framework from policies and procedures to encryption protocols.
The type of data stored in our system commonly includes:
Confidentiality and integrity of customer data is our most important mission. We make all commercially and professionally reasonable efforts to maintain the highest levels of each, as customers would expect from us and themselves.
We provide strong encryption of all data in transit and at rest. Encryption in transit is achieved via the industry-standard TLS (Transport Layer Security) protocol supporting only the strongest encryption algorithms, including AES (Advanced Encryption Standard) with up to 256-bit key lengths. Encryption at rest is achieved by leveraging AWS storage encryption, using AWS KMS to create and store the 256-bit AES encryption keys.
By using TLS version 1.2, an encrypted communication channel between the end-user web browser and the HighBond service is established, ensuring the confidentiality and integrity of all data transmissions from end-to-end.
The AES encryption algorithm is widely recognized and approved by organizations worldwide as an industry standard in government, military, and commercial applications.
AES-256 bit TLS encryption is supported on most browsers. If your browser does not support AES-256 bit TLS encryption, you will not be able to access the HighBond service and all related components.
All emails from our platform are transmitted via TLS-encrypted channels, when available. If the recipient's email server does not support TLS, emails are delivered over the default unencrypted connection.
Process for data encryption between web server and web browser
|Android 4.0.4 and above|
|Chrome / OS X|
|Firefox 31.3.0 ESR/ Win 7 and above|
|Firefox 37 / OS X and above|
|Internet Explorer 11 / Win 7|
|Internet Explorer 11 / Win 8.1|
|IE Mobile 10 / Win Phone 8.0 and above|
|Safari OS X 10.6.8 and above|
|Safari iOS 8 and above|
If and when customers choose to publish data to Results for evidence as part of control testing, or for further review as part of risk mitigation, ACL Analytics and Analytics Exchange both include a hashing function for customer end-users to apply to any sensitive data fields, such as:
The hashing feature enables customers to cryptographically protect any sensitive data fields that are being uploaded to our service. Hashed values are protected by a cryptographic one-way function that cannot be reversed, keeping sensitive data confidential at rest and during further processing.
User passwords are never stored. A strong cryptographic algorithm is used to generate irreversible strings known as password hashes. The stored hashes are without any value to an adversary even if obtained. The algorithm uses a unique long random value known as a salt, which is different for each user and ensures protection against attacks based on pre-computation of password hashes.
Password expiry is a security feature that limits unauthorized access to our service.
If you are using password expiry, consider the following:
The minimum duration supported for password expiry is 7 days. There is no maximum duration.
Our service includes a security setting that determines whether passwords meet complexity requirements. Complexity requirements are enforced when you change or reset your password in Launchpad.
Passwords must meet the following requirements:
Passwords may contain special characters.
When signing in to our platform or generating a token to use in another application, you have up to five attempts to enter your password.
After five attempts, reCAPTCHA displays. reCAPTCHA is a service that protects websites from spam and abuse, and requires you to enter a series of characters or numbers to prove you are human.
A session is a period of activity between a user logging in and out of an application. Sessions are global to all HighBond SaaS modules, which means you use the same login session whether you are in Strategy, Projects, Results, or Reports. Your session expires if you are inactive for the duration of time set by an Account Admin.
Session expiry does not apply to the mobile app, ACL Analytics, or Analytics Exchange.
When a new organization is created, the default session timeout is set to 60 minutes. If users have access to more than one organization, their session will expire as per the shortest session expiration time limit set across all their organizations.
If you are using session expiry, consider the following:
IP allowlisting allows organizations to configure one or more IP (Internet Protocol) addresses or IP address ranges from which a user may access the organization. IP allowlisting may be used as an additional factor in multi-factor authentication, in addition to password credentials, to ensure only authorized users access the organization.
IP allowlisting only impacts our applications when they interact with Cloud data, including:
If you are using IP allowlisting, consider the following:
In order to prevent Accounts Admins from locking themselves out of our service, Account Admins are unable to configure an IP address that does not comply with their current IP address.
To comply with your organization's IP allowlist, you can connect to your organization's VPN (Virtual Private Network) to access our service on your laptop or mobile device.
Roles define the types of permissions a user has in accessing cloud data. Permissions can include tasks such as managing settings, and adding, viewing, editing, or deleting data. A user can have varying roles in different modules.
You are accountable to provision access to all of your licensed users via a designated Account Admin role, and in doing so, determine which users get access and to which level of access is required by business need and applicable compliance regulations.
Depending on how your organization manage logical access, you can use a centralized approach and assign your IT Department as Account Admin allowing them to administer overall user access.
Alternatively, you can use a more decentralized approach where the leadership of the respective assurance buying center(s) can administer access control through user application roles dictated that comply with IT or regulatory security requirements.
For detailed information on roles and privileges in each module, see the following topics: