Security Configuration Requirements for HIPAA or HDS Enabled Accounts on Zendesk

HIPAA Enabled Accounts:

All capitalized terms used in this document shall have the meanings given to them in Zendesk's Business Associate Agreement ("BAA"). 

Zendesk and Subscriber have entered into that certain Business Associate Agreement (“BAA”) which requires that Subscriber implement and comply with the following configurations for any and all HIPAA Enabled Account(s) before introducing any Protected Health Information ("PHI") into the Services. All capitalized terms used in this document shall have the meanings given to them in the BAA. 

Subscriber’s  failure to implement and comply with any particular configuration listed below, or any series of required configurations listed below, shall be at Subscriber’s own risk and  at Subscriber’s sole discretion; and such failure shall relieve Zendesk and its employees, agents, and affiliates of any responsibility with respect to any unauthorized access to, or improper use or disclosure of, Subscriber’s Service Data, including any electronic Protected Health Information, that results from such failure by Subscriber.

Subscriber must have purchased Service plans at the appropriate level and have the required associated add-ons (please consult your Sales representative where unsure)

The following minimum Security Configurations for Zendesk Support must be put in place and are acknowledged on the BAA for any HIPAA Enabled Account(s):

1. Secure Agent authentication through one of the two following methods:
1. Employing native Zendesk Support with password settings: (i) set to “High”; or (ii) customized by Subscriber in a manner that establishes requirements not less secure than those established under the “High” setting. Additionally, under the option in this subsection Subscriber must also enable and enforce Two Factor Authentication ("2FA") natively within the Service; and, administrative controls that permit administrators to set passwords for End-Users must be disabled; or
2. Utilizing an external Single Sign On (”SSO") solution with established requirements not less secure than those established under the Zendesk "High" password setting and enabling and enforcing 2-factor authentication within the selected solution for all Agents’ access. Administrative controls permitting Administrators to set passwords for End-Users must be disabled.
3. All authentication choices utilizing SSO as the authentication method must disable password access.
2. Secure Socket Layer ("SSL") encryption on HIPAA Enabled Account(s) must remain enabled at all times. HIPAA Enabled Accounts which utilize a domain other than zendesk.com must establish and maintain hosted SSL.
3. Agent access must be restricted to specific IP addresses under the control of Subscriber for Support and Chat unless Subscriber enables multi-factor authentication for agents as described above in requirements 1.a or 1.b (either natively within the Service, or within the Subscriber’s environment as coupled with Enterprise SSO).  For the avoidance of doubt, “Agent access” shall denote the access granted to a human agent accessing Service Data via the User Interface ("UI").
4. To the extent Subscriber’s HIPAA Enabled Account enables calls to Zendesk Application Programming Interface(s) ("API's"), Subscriber shall assume all responsibility for understanding the security implications of all Subscriber or third party entities allowed to create,  access, modify, or delete Service Data and PHI via such access and/or integrations. For access to said API’s, Subscriber shall implement the following security best practices based on the API model used:
1. OAuth 2.0 approach.  This model provides the most granular security capabilities, but requires that entitlements be accepted by an End-User.  Where possible, the Subscriber will utilize the OAuth 2.0 approach and authentication scheme. Subscriber will give each OAuth client a descriptive and unique Client Name and Unique Identifier designating function. Permissions granted for each OAuth token should allow for the least privilege needed to accomplish the required task(s).
2. REST API token approach.  This model is the broadest, and allows an API token to utilize the full functionality of the API model.  By its nature, it provides the widest access and capabilities and should be used with caution. When using this approach, Subscriber will (i) use a unique token for each service and give the token a descriptive name designating function; (ii) not share API tokens with any third-party unless reasonably required and pursuant to transmission methods which are encrypted from end-to-end; (iii) acknowledge that if API token is shared with a third-party, and Subscriber is made aware of a third-party data breach, Subscriber will rotate the associated token immediately; and (iv) at a minimum, rotate the token once every one hundred and eighty (180) days.  Subscriber shall follow Service’s REST API Terms of Service. 
5. Subscriber must enable ‘require authentication for download’ in order to require authentication to access attachments.
6. Subscriber must systematically enforce, on all Agents, Admins, and Owners accessed endpoints, a password-locked screensaver or startup screen set to engage at a maximum of fifteen (15) minutes of system inactivity.
7. Subscriber must not alter viewing permissions which allow a user to see updates for an entire org or alter the default setting allowing access beyond the user's own tickets (unless Subscriber assumes all responsibility for ensuring such users are approved by Subscriber to access all subsequent data).
8. Subscriber acknowledges that Zendesk is not responsible for securing email transmissions from End-Users, and related Service Data, prior to being received into Subscriber’s Zendesk Support instance. This includes any PHI that may be passed through email via replies to Zendesk Support tickets, including but not limited to, ticket comments or attachments.
9. Subscriber acknowledges that Zendesk Support sends an email out to an End-User when a Subscriber’s Agent responds to a Zendesk Support ticket.  By default, this email contains whatever correspondence the Agent has sent back to the End-User, and potentially could include PHI. To further protect Subscriber, their Zendesk Support instance should be configured to only alert the End-User that an Agent has responded, and require the End-User to authenticate into Zendesk Support to see the contents of the message.
10. Subscriber acknowledges that any text message functionality leveraged at its sole discretion across any Zendesk Service is underpinned by SMS and/or related protocols, which may involve the unencrypted transmission of messages being sent into, or out of the Service(s).  As such, text message functionality should either:
1. not be used in a HIPAA Enabled Account*, or
2. if used, the Subscriber assumes all responsibility for the usage of such functionality
11. Subscriber acknowledges that use of the Service's Customer Satisfaction Surveys ("CSAT") functionality sends Service Data (which may contain PHI) associated with the Support ticket via email in order to obtain the user's rating, the encryption status of which is not controlled by Zendesk. As such, CSAT functionality should either:
1. not be used in a HIPAA Enabled Account*, or
2. if used, the Subscriber assumes all responsibility for the usage of such functionality

* For the avoidance of doubt, the data caveats related to ePHI in section 10 regarding SMS do not apply to in-product 2FA usage (as described in section 1.a) as such functionality merely sends out a numerical string for identity verification.

The following minimum Security Configurations for the Zendesk Guide and Gather Services must be put in place and are acknowledged on the BAA for any HIPAA Enabled Account(s):

1. Subscriber acknowledges that the Guide and Gather Services are public by nature (where not leveraging IP restrictions for “internal” help centers) and therefore Subscriber shall ensure that any articles in Zendesk Guide or Gather Service do not include PHI, either through the text of the article or as an attachment to, or image within the article.
2. Subscriber shall either disable the ability for End-Users to add comments in Zendesk Guide, or shall moderate and assume responsibility for removing PHI from all comments (as denoted in section 3 below).
3. Where Zendesk Guide Service is Guide Professional or Enterprise, Subscribers should, when possible, disable the ability for end users to create new posts by turning off the Gather functionality with Zendesk Guide, or when turning off Gather features cannot be pursued due to the Subscriber’s intended use case, Subscribers shall enable content moderation in Zendesk Guide Service and set to "Moderate all content". No submissions containing PHI shall be approved.
4. Subscriber use of non-employee “Community Moderators” within the Gather Service shall not be allowed.
5. Subscriber acknowledges that “@mentions” of Gather community members are possible where allowing for end users to have public profiles and should this functionality be deemed a risk in their use case, public profiles shall be turned off.

For subscribers who have signed Zendesk’s BAA, and subsequently used the Zendesk Insights Service, our support for this Service is to be deprecated as of February 5th, 2021.       

The following minimum Security Configurations for the Zendesk Chat Service must be put in place and are acknowledged on the BAA for any HIPAA Enabled Account(s):

1. Subscriber shall limit Agents’ access to the Zendesk Chat Service by coupling with and authenticating via the Zendesk Support Service.
2. Subscriber shall disable email piping.
3. Subscriber shall not enable "Agent Workspaces" unless it assumes full responsibility for ensuring (i) no ePHI is present in Chats, and/or (ii) all Agents are allowed by Subscriber to view such data.

The following minimum Security Configurations for usage of Zendesk Explore Service must be put in place and are acknowledged on the BAA for any HIPAA Enabled Account(s):

Subscriber acknowledges that ePHI may be surfaced in the Explore product via usernames, ticket titles, field and form choices, and any content found in free form text fields.

1. For any in-scope Service instance(s) containing PHI, Subscriber shall (i) only grant access to the Explore interface to agents who can access all tickets/calls/chats which may contain PHI in the parent Service instance(s), and (ii) shall grant such access taking into account the least amount of privileges necessary for the use of Explore in their environment. For more information on configuring access levels in Explore, please see here.
2. Where leveraging "export" functionality, (i) Subscriber acknowledges that PHI may be transferred to device allowed by Subscriber to access agent's interface and all attendant controls on such device(s) are the Subscriber's responsibility, and (ii) Subscriber shall deny the use of native export functionality via email for said exported reports unless it assumes the responsibility of either (a) ensuring that no PHI is contained in such exports, or (b) that email services used for such transfers can accommodate encryption via the minimum encryption protocol allowed by the then-current PCI standards.

* Special Considerations for use of Explore Enterprise:

Subscriber acknowledges that use of the Explore Enterprise Service may entail increased data sharing and export functionalities. Subscriber shall:

1. either (i) ensure that no ePHI exists in such dashboards, and/or (ii) share dashboards only with Agents, Groups, Lists, or End Users who are approved to view and receive such data.
2. leverage IP restrictions
3. where sharing dashboards via Uniform Resource Locator (URL), Subscriber acknowledges that rather than sharing with individual or group user accounts, the data shall be shared by an access link. Subscriber shall therefore (i) enable password protection, (ii) ensure the chosen passwords’ complexity, rotation, storage, and distribution to receiving party complies with Subscriber’s password policies for the protection of data contained in such dashboards, and (iii) is rotated without undue delay upon suspicion or confirmation of exposure

The following minimum Security Configurations for usage of Zendesk mobile applications (or access made by mobile devices such as smartphones or tablets) must be put in place and are acknowledged on the Zendesk BAA for any HIPAA Enabled Account(s):

1. Usage shall include device level encryption
2. Biometric or PIN access set to the highest device setting allowed shall be leveraged
3. Notifications allowing ticket comments to be surfaced onto the lock screens of such devices shall be disabled
4. Screen inactivity locks shall be enabled and configured to lock at not more than 15 minutes of inactivity.

Notice About In-Product Functionality for Deployed Associated Services (“Add-Ons”):

1. Collaboration Deployed Associated Service: “Side Conversations.” Subscriber acknowledges that use of “Side Conversation” functionality may entail "child ticket" and/or "side conversation" messages being created within or sent from Subscriber’s Support instance to recipients via ticket, email, Slack, or integrations (at configuring Agent’s discretion). If Subscriber elects to use this functionality in a HIPAA Enabled Account, Subscriber assumes any and all responsibility for either (i) ensuring that no PHI is present in such messages, or (ii) if PHI could be present in messages, Subscriber is solely responsible for any liability, cost, damage or harm relating to the unauthorized acquisition, access, use, or disclosure of PHI resulting from exchange of messages via the “Side Conversation” functionality.

Disclaimer: Due to changes in law or regulation or changes in the Zendesk Service, the security configurations in this document may change from time to time. This document contains Zendesk’s recommendations for the minimum effective security configurations for the protection of PHI within the Zendesk products outlined above at this time. This document does not constitute an exhaustive template for all controls over such data nor constitutes legal advice. Each Zendesk subscriber should seek its own legal counsel with regard to its HIPAA compliance requirements and should make the additional changes to its security configurations in accordance with each subscriber’s own independent analysis, so long as such changes do not counteract or degrade the security of the configurations outlined in this document.

HDS Enabled Accounts:

All capitalized terms used in this document shall have the meanings given to them in the HDS Terms Exhibit to Zendesk's Master Subscription Agreement ("HDS Terms Exhibit").
Zendesk and Subscriber have entered into that certain HDS Terms Exhibit which requires that Subscriber implement and comply with the following configurations for any and all HDS Enabled Account(s) before introducing any Personal Health Information ("PHI") into the Services. All capitalized terms used in this document shall have the meanings given to them in the HDS Terms Exhibit.
Subscriber’s failure to implement and comply with any particular configuration listed below, or any series of required configurations listed below, shall be at Subscriber’s own risk and at Subscriber’s sole discretion; and such failure shall relieve Zendesk and its employees, agents, and affiliates of any responsibility with respect to any unauthorized access to, or improper use or disclosure of, Subscriber’s Service Data, including any electronic Personal Health Information, that results from such failure by Subscriber.
The following minimum Security Configurations for Zendesk Support must be put in place and are acknowledged on the HDS Terms Exhibit for any HDS Enabled Account(s):

The following minimum Security Configurations for Zendesk Support must be put in place and are acknowledged on the HDS Terms Exhibit for any HDS Enabled Account(s):

1. Secure Agent authentication through one of the two following methods:
1. Employing native Zendesk Support with password settings: (i) set to “High”; or (ii) customized by Subscriber in a manner that establishes requirements not less secure than those established under the “High” setting. Additionally, under the option in this subsection Subscriber must also enable and enforce Two Factor Authentication ("2FA") natively within the Service; and, administrative controls that permit administrators to set passwords for End-Users must be disabled; or
2. Utilizing an external Single Sign On (”SSO") solution with established requirements not less secure than those established under the Zendesk "High" password setting and enabling and enforcing 2-factor authentication within the selected solution for all Agents’ access. Administrative controls permitting Administrators to set passwords for End-Users must be disabled.
3. All authentication choices utilizing SSO as the authentication method must disable password access.
2. Secure Socket Layer ("SSL") encryption on HDS Enabled Account(s) must remain enabled at all times. HDS Enabled Accounts which utilize a domain other than zendesk.com must establish and maintain hosted SSL.
3. Agent access must be restricted to specific IP addresses under the control of Subscriber for Support and Chat unless Subscriber enables multi-factor authentication for agents as described above in requirements 1.a or 1.b (either natively within the Service, or within the Subscriber’s environment as coupled with Enterprise SSO).  For the avoidance of doubt, “Agent access” shall denote the access granted to a human agent accessing Service Data via the User Interface ("UI").
4. To the extent Subscriber’s HDS Enabled Account enables calls to Zendesk Application Programming Interface(s) ("API's"), Subscriber shall assume all responsibility for understanding the security implications of all Subscriber or third party entities allowed to create,  access, modify, or delete Service Data and PHI via such access and/or integrations. For access to said API’s, Subscriber shall implement the following security best practices based on the API model used:
1. OAuth 2.0 approach.  This model provides the most granular security capabilities, but requires that entitlements be accepted by an End-User.  Where possible, the Subscriber will utilize the OAuth 2.0 approach and authentication scheme. Subscriber will give each OAuth client a descriptive and unique Client Name and Unique Identifier designating function. Permissions granted for each OAuth token should allow for the least privilege needed to accomplish the required task(s).
2. REST API token approach.  This model is the broadest, and allows an API token to utilize the full functionality of the API model.  By its nature, it provides the widest access and capabilities and should be used with caution. When using this approach, Subscriber will (i) use a unique token for each service and give the token a descriptive name designating function; (ii) not share API tokens with any third-party unless reasonably required and pursuant to transmission methods which are encrypted from end-to-end; (iii) acknowledge that if API token is shared with a third-party, and Subscriber is made aware of a third-party data breach, Subscriber will rotate the associated token immediately; and (iv) at a minimum, rotate the token once every one hundred and eighty (180) days.  Subscriber shall follow Service’s REST API Terms of Service. 
5. Subscriber must enable ‘require authentication for download’ in order to require authentication to access attachments.
6. Subscriber must systematically enforce, on all Agents, Admins, and Owners accessed endpoints, a password-locked screensaver or startup screen set to engage at a maximum of fifteen (15) minutes of system inactivity.
7. Subscriber must not alter viewing permissions which allow a user to see updates for an entire org or alter the default setting allowing access beyond the user's own tickets (unless Subscriber assumes all responsibility for ensuring such users are approved by Subscriber to access all subsequent data).
8. Subscriber acknowledges that Zendesk is not responsible for securing email transmissions from End-Users, and related Service Data, prior to being received into Subscriber’s Zendesk Support instance. This includes any PHI that may be passed through email via replies to Zendesk Support tickets, including but not limited to, ticket comments or attachments.
9. Subscriber acknowledges that Zendesk Support sends an email out to an End-User when a Subscriber’s Agent responds to a Zendesk Support ticket.  By default, this email contains whatever correspondence the Agent has sent back to the End-User, and potentially could include PHI. To further protect Subscriber, their Zendesk Support instance should be configured to only alert the End-User that an Agent has responded, and require the End-User to authenticate into Zendesk Support to see the contents of the message.
10. Subscriber acknowledges that any text message functionality leveraged at its sole discretion across any Zendesk Service is underpinned by SMS and/or related protocols, which may involve the unencrypted transmission of messages being sent into, or out of the Service(s).  As such, text message functionality should either:
1. not be used in a HDS Enabled Account*, or
2. if used, the Subscriber assumes all responsibility for the usage of such functionality.

* For the avoidance of doubt, the data caveats related to ePHI in section 10 regarding SMS do not apply to in-product 2FA usage (as described in section 1.a) as such functionality merely sends out a numerical string for identity verification.

The following minimum Security Configurations for the Zendesk Guide and Gather Services must be put in place and are acknowledged on the HDS Terms Exhibit for any HDS Enabled Account(s):

1. Subscriber acknowledges that the Guide and Gather Services are public by nature (where not leveraging IP restrictions for “internal” help centers) and therefore Subscriber shall ensure that any articles in Zendesk Guide or Gather Service do not include PHI, either through the text of the article or as an attachment to, or image within the article.
2. Subscriber shall either disable the ability for End-Users to add comments in Zendesk Guide, or shall moderate and assume responsibility for removing PHI from all comments.
3. Subscriber use of non-employee “Community Moderators” within the Gather Service shall not be allowed.

The following minimum Security Configurations for the Zendesk Chat Service must be put in place and are acknowledged on the HDS Terms Exhibit for any HDS Enabled Account(s):

1. Subscriber shall limit Agents’ access to the Zendesk Chat Service by coupling with and authenticating via the Zendesk Support Service.
2. Subscriber shall disable email piping.
3. Subscriber shall not enable "Agent Workspaces" unless it assumes full responsibility for ensuring (i) no ePHI is present in Chats, and/or (ii) all Agents are allowed by Subscriber to view such data.

The following minimum Security Configurations for usage of Zendesk Explore Service must be put in place and are acknowledged on the HDS Terms Exhibit for any HDS Enabled Account(s):

Subscriber acknowledges that ePHI may be surfaced in the Explore product via usernames, ticket titles, field and form choices, and any content found in free form text fields.

1. For any in-scope Service instance(s) containing PHI, Subscriber shall (i) only grant access to the Explore interface to agents who can access all tickets/calls/chats which may contain PHI in the parent Service instance(s), and (ii) shall grant such access taking into account the least amount of privileges necessary for the use of Explore in their environment. For more information on configuring access levels in Explore, please see here.
2. Where leveraging "export" functionality, (i) Subscriber acknowledges that PHI may be transferred to device allowed by Subscriber to access agent's interface and all attendant controls on such device(s) are the Subscriber's responsibility, and (ii) Subscriber shall deny the use of native export functionality via email for said exported reports unless it assumes the responsibility of either (a) ensuring that no PHI is contained in such exports, or (b) that email services used for such transfers can accommodate encryption via the minimum encryption protocol allowed by the then-current PCI standards.

* Special Considerations for use of Explore Enterprise:

Subscriber acknowledges that use of the Explore Enterprise Service may entail increased data sharing and export functionalities. Subscriber shall:

1. either (i) ensure that no ePHI exists in such dashboards, and/or (ii) share dashboards only with Agents, Groups, Lists, or End Users who are approved to view and receive such data.
2. leverage IP restrictions
3. where sharing dashboards via Uniform Resource Locator (URL), Subscriber acknowledges that rather than sharing with individual or group user accounts, the data shall be shared by an access link. Subscriber shall therefore (i) enable password protection, (ii) ensure the chosen passwords’ complexity, rotation, storage, and distribution to receiving party complies with Subscriber’s password policies for the protection of data contained in such dashboards, and (iii) is rotated without undue delay upon suspicion or confirmation of exposure

The following minimum Security Configurations for usage of Zendesk mobile applications (or access made by mobile devices such as smartphones or tablets) must be put in place and are acknowledged on the HDS Terms Exhibition for any HDS Enabled Account(s):

1. Usage shall include device level encryption
2. Biometric or PIN access set to the highest device setting allowed shall be leveraged
3. Notifications allowing ticket comments to be surfaced onto the lock screens of such devices shall be disabled
4. Screen inactivity locks shall be enabled and configured to lock at not more than 15 minutes of inactivity.

Notice About In-Product Functionality for Deployed Associated Services (“Add-Ons”):

1. Collaboration Deployed Associated Service: “Side Conversations.” Subscriber acknowledges that use of “Side Conversation” functionality may entail "child ticket" or "side Conversation" messages being created within or sent from Subscriber’s Support instance to recipients via ticket, email, Slack, or integrations (at configuring Agent’s discretion). If Subscriber elects to use this functionality in a HDS Enabled Account, Subscriber assumes any and all responsibility for either (i) ensuring that no PHI is present in such messages, or (ii) if PHI could be present in messages, Subscriber is solely responsible for any liability, cost, damage or harm relating to the unauthorized acquisition, access, use, or disclosure of PHI resulting from exchange of messages via the “Side Conversation” functionality.

Disclaimer: Due to changes in law or regulation or changes in the Zendesk Service, the security configurations in this document may change from time to time. This document contains Zendesk’s recommendations for the minimum effective security configurations for the protection of PHI within the Zendesk products outlined above at this time. This document does not constitute an exhaustive template for all controls over such data nor constitutes legal advice. Each Zendesk subscriber should seek its own legal counsel with regard to its HDS compliance requirements and should make the additional changes to its security configurations in accordance with each subscriber’s own independent analysis, so long as such changes do not counteract or degrade the security of the configurations outlined in this document.