HIPAA Compliance with Looker Services

The Business Associate Agreement (BAA) covers Looker’s Services under a Looker Hosted Deployment as described in the applicable Looker services agreement to which the BAA is attached, except that the following (the "Excluded Services") are not covered by the BAA:

• Any third party services (including those at the following link https://looker.com/trust-center/privacy/google-cma-subprocessors ) other than services provided by (i) a Google Affiliate or (ii) a cloud based infrastructure provider included in the Services.
• Any API Integration tool that is not secure
• Any Services that are not generally available, including beta features and previews

Given the functionality of the Services, you, as the customer, are in control of (i) the environment where you deploy the Services, (ii) the configuration of the Services (including configuration of the access permissions and security controls) in such a way that complies with your BAA, this implementation guide and HIPAA requirements, (iii) the applications that are connected to the Services by your end users, and (iv) how or if your users access Protected Health Information (PHI) when using the Services. To the extent you elect to use Excluded Services (as defined above), you must manage the risk of using such services in compliance with your obligations under HIPAA. 

Essential best practices:

• Execute a BAA. You can request a BAA directly from your account manager.
• Disable or otherwise ensure that you do not use services that are not covered by the BAA when working with PHI. 
• Turn off Excluded Services so that end users do not use services not covered by the BAA.

• Access Controls

  • Use the “access filter” parameter in conjunction with user attributes to apply row, column, or field level data security by user or user group.
  • Minimize data access for your users by limiting administrator, developer, and SQL runner access privileges.
  • Ensure you have a process in place to prevent sharing of PHI with Excluded Services and Google personnel, including technical support teams via support access or professional services teams during an engagement.

• Sharing

  • Set up any API usage between Google and your vendor or any other third party in a secure way.
  • Do not share PHI via the Services with a third-party unless a BAA is in place with the third-party. Do not instruct Google to share PHI via the Services (including an API) with a third-party unless a BAA is in place with the third-party.
  • Manage use of the Services such that PHI is not shared via email by ensuring email recipients get redirected to the Looker Instance where they must log into the Services before accessing PHI or related sensitive content.
  • Have processes in place to ensure PHI is not attached to or sent via any technical support chat functionality
  • Store cache query results for only the minimum time necessary for the data set(s) and use case(s) by configuring the Services accordingly.
  • Restrict when users can create public links by utilizing the administrator functionality of the Services.
  • Create and maintain logs when you permit a third party to use aggregated PHI.

• Secure Configuration

  • Implement industry-standard methods of authenticating users such as two-factor authentication or SAML-supported SSO iDP, and to the extent a user relies on SSO, restrict the “login_special_email” permission to a maximum of two (2) users.
  • Apply data set security within the Looker model.
  • At least quarterly, perform an audit on all users, groups, permissions, roles, API keys, public links, and additional access controls, sharing, and security configuration.

• When granting the necessary authorization for the Services to access your databases, you must follow the principle of granting the least privilege to this database and its information.
• When configuring database security controls, you should:
  • ensure that all connections to the database are encrypted in transit, employ a tunnel server for any SSH tunnel connection,
  • allow list external access to permit only Google-specific IP addresses, and
  • configure your database rights such that Google does not have write-access or administrative-access to your databases.