Security Controls

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:

  • risks, controls, and policies related to the organization or public sector entity at both a strategic or enterprise level and process or location level
  • testing of design and effectiveness of risks, controls, and policies
  • exceptions and issues related to the testing
  • integrating relevant data analytics related to transactional data sampling or monitoring

Confidentiality and integrity of customer data is our most important mission, and we take all commercially and professionally reasonable efforts to maintain the highest levels of each, as customers would expect from us and themselves.

Data encryption

ACL provides 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 EBS storage encryption, which also relies on the AES encryption algorithm with strong 256-bit keys.

About encryption

By using TLS, an encrypted communication channel between the end-user web browser and ACL GRC 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 ACL Launchpad and all related components.

All emails from the ACL 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 ACL data encryption between web server and web browser

Web browsers that support AES-256 bit TLS encryption and ACL GRC

Web browser Supported
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 6-8 / XP
Internet Explorer 8-10 / Win 7
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

Hashing function

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:

  • patient records
  • social security identifiers
  • credit card numbers
  • bank or mortgage account numbers
  • payroll
  • criminal activity

The hashing feature enables customers to cryptographically protect any sensitive data fields that are being uploaded to our service. Hashed values are protected by cryptographically one-way function that cannot be reversed, keeping sensitive data confidential at rest and during further processing.

Passwords

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

Password expiry is a security feature that limits unauthorized access to the ACL service.

If you are using password expiry, consider the following:

  • Account Admins can enable password expiry under Settings > Update Organization in ACL Launchpad.
  • Password expiry is configured as the number of days between password changes.
  • Note

    The minimum duration supported for password expiry is 7 days. There is no maximum duration.

  • If your password expires, one or more organizations you belong to have enabled password expiry.
  • Your password expiry is based on the shortest expiry length of all the organizations you belong to.
  • You will receive a notice in ACL Launchpad one week prior to your password expiring.
  • If your password expires, you will need to reset your password to sign in to ACL Launchpad.

Password complexity

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 ACL Launchpad.

Passwords must meet the following requirements:

  • Passwords must be a minimum of 8 characters in length
  • Passwords must include at least one lower case, one upper case, and one numeric character.
  • Note

    Passwords may contain special characters.

  • You cannot re-use any of your last five passwords as your new password.

Password attempts

When signing in to ACL Launchpad 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.

Session expiry

A session is a period of activity between a user logging in and out of an application. Sessions are global to all ACL 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.

Note

Session expiry does not apply to the ACL GRC 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:

  • Account Admins can enable session expiry under Settings > Update Organization in ACL Launchpad.
  • Session expiry is calculated by the number of minutes that a browser session remains inactive.
  • The minimum duration supported for session expiry is 30 minutes and the maximum is 30 days.
  • You can have many sessions open at one time as multiple tabs or windows belonging to the same browser on the same machine share the same session.
  • You can log in with either the same user or different users on different browsers or machines, and logging out of one will not log you out of the others.
  • Your session expiry is based on the shortest expiry length of all the organizations you belong to.

IP whitelisting

IP whitelisting allows organizations to configure one or more IP (Internet Protocol) addresses or IP address ranges from which a user may access the organization. IP whitelisting 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 whitelisting only impacts ACL applications when they interact with Cloud data, including:

  • Exporting results from Results to ACL Analytics
  • Importing results from ACL Analytics to Results
  • Using scripts to export results from Analytics Exchange to Results
  • Publishing results from Add-In for Excel to Results
  • Importing tables from Projects to ACL Analytics
  • Checking in or checking out sections in the ACL GRC mobile app or Projects client
  • Uploading Excel worksheets from ACL Acerno to Projects

If you are using IP whitelisting, consider the following:

  • Account Admins can configure IP whitelisting under Settings > Update Organization in ACL Launchpad.
  • Note

    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.

  • If the IP whitelist has any IP addresses or IP address ranges defined, only users whose IP addresses match the IP whitelist may access the organization.
  • All users accessing Cloud data within a specific organization are subject to IP whitelisting.
  • Users belonging to multiple organizations must comply only with the IP whitelist of the organization they are currently accessing.
  • If an IP whitelist is enabled, users on mobile devices or public networks with dynamic IP addresses cannot comply with their organization's IP whitelist.
  • Tip

    To comply with your organization's IP whitelist, you can connect to your organization's VPN (Virtual Private Network) to access our service on your laptop or mobile device.

Role-based access control

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.

Accountability

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.

Administering user access

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: