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)

I. 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 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 Zendesk offers various methods as described here and 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 frequently in accordance with Subscriber’s organization policies.  
3. When possible, Subscriber shall disable password access to the API, as this approach sends the user credentials with every request which exposes them broadly, making them more easily interceptable by malicious parties.  
5. Subscriber must enable ‘require authentication for download’ in order to require authentication to access attachments. Failure to do so shall mean that any unrestricted attachment may be accessed by anyone with access to the correct URL for said attachment. In such cases, Subscriber shall assume all responsibility for the content of, and access to such attachment data.
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 should 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.

II. 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 or using a closed or restricted instance) 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 or @mentions shall be disabled.
   

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

1. Subscriber shall not enable social media messaging channel integrations unless it assumes full responsibility for either (i) ensuring no ePHI is present in social media messages or (ii) concludes its own BAA with integrated messaging platforms.
2. Subscriber shall disable the ability for End-Users to attach files to messaging conversations, and shall take full responsibility for either (i) enabling secure attachments or (ii) ensuring that Agents do not attach files containing ePHI to messaging conversations. Failure to do so shall mean that any unrestricted attachment may be accessed by anyone with access to the correct URL for said attachment.  In such cases, Subscriber shall assume all responsibility for the content of, and access to such URLs and/or attachment data.
3. Subscriber shall take all responsibility for ensuring all Agents and light Agents are allowed to view all incoming messages from all End-Users.
4. If Subscriber or its Agents access or develop integrations (e.g. as part of a flow created for Answer Bot) for APIs and webhooks or customize the messaging experience, Subscriber shall take full responsibility for understanding the privacy and security implications of all custom workflows and for all Subscriber or third party entities (including chatbot providers) allowed to create, access, modify, or delete Service Data and ePHI via such access and/or integrations.
5. If Subscriber wishes to remove an Agent’s permission to participate in a messaging conversation while the messaging conversation is currently active, Subscriber shall take all responsibility for forcing termination of said Agent’s access to Zendesk.
6. By default, web widget conversations with End-Users are persistent and will be viewable by the End-User when they return to the web chat from the same device. Subscriber shall either disable this feature or take all responsibility for ensuring End-Users are not sharing devices.
7. If Subscriber wishes to implement authentication for End-Users, Subscriber shall take all responsibility for implementing this in a secure manner according to best practices and industry standards.
   1. When using this approach, Subscriber will (i) use a unique JWT signing key for each authentication channel and give the token a descriptive name designating function; (ii) not share JWT signing keys with any third-party unless reasonably required and pursuant to transmission methods which are encrypted from end-to-end; (iii) acknowledge that if JWT signing key is shared with a third-party, and Subscriber is made aware of a third-party data breach, Subscriber will rotate the associated JWT signing key immediately; and (iv) at a minimum, rotate the JWT signing key frequently in accordance with Subscriber’s organization policies.
   2. Subscriber shall use the expiration JWT attribute and set its value to no more than 15 minutes.
8. Subscriber acknowledges that interactions between End-Users and Answerbot which are not handed to a human Agent and transferred into a ticket are still stored in the system and it is the responsibility of Subscriber to delete those in accordance with their obligations (e.g. by implementing a webhook that alerts Subscriber when those conversations are stored and (automatically) triggers deletion via the Sunshine Conversations API). 
9. Subscriber acknowledges that conversations between End-Users and Answerbot that have been transformed into a ticket cannot currently be redacted. Deletion is possible by deleting the ticket. 
10. Subscriber acknowledges that End-User attachments on messaging channels are currently not scanned for malware in Zendesk. Subscriber shall take full responsibility of having procedures and policies in place to mitigate the risk for Subscriber’s assets. 

IV. The following minimum Security Configurations for usage of Zendesk Sunshine Conversations (in use with the Zendesk Suite) must be put in place and are acknowledged on the Zendesk BAA for any HIPAA Enabled Account(s):

1. Subscriber shall not enable third party channel integrations unless it assumes full responsibility for ensuring either (i) no ePHI is present in third party channel messages or (ii) concludes its own BAA with integrated messaging platforms.
2. 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 the Sunshine Conversations Application Programming Interface(s) ("API's"). 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. 
   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) rotate the token frequently in accordance with Subscriber’s organization policy.  
   3. If Subscriber or its Agents access or develop integrations for APIs and webhooks or customize the Sunshine Conversations experience, Subscriber shall take full responsibility for understanding the privacy and security implications of all custom workflows and for all Subscriber or third party entities (including chatbot providers) allowed to create, access, modify, or delete Service Data and ePHI via such access and/or integrations.
3. Subscriber acknowledges that the IP restrictions configured for Zendesk Support do not extend to the Sunshine Conversations API. Subscribers shall take full responsibility for restricting access to Sunshine Conversations API and API tokens as described in 2.b. and in accordance with Subscriber’s policies. 
4. Subscriber shall disable the ability for End-Users to attach files to Sunshine Conversations conversations, and shall take full responsibility for either enabling secure attachments or ensuring that Agents do not attach files containing ePHI to messaging conversations. Failure to do so shall mean that any unrestricted attachment may be accessed by anyone with access to the correct URL for said attachment. In such cases, Subscriber shall assume all responsibility for the content of, and access to such attachment data.
5. If Subscriber wishes to implement Authentication for End-Users, Subscriber shall take all responsibility for implementing this in a robust way according to security best practices and industry standards.
   1. When using this approach, Subscriber will (i) use a unique JWT signing key for each authentication channel and give the token a descriptive name designating function; (ii) not share JWT signing keys with any third-party unless reasonably required and pursuant to transmission methods which are encrypted from end-to-end; (iii) acknowledge that if JWT signing key is shared with a third-party, and Subscriber is made aware of a third-party data breach, Subscriber will rotate the associated JWT signing key immediately; and (iv) at a minimum, rotate the JWT signing key frequently in accordance with Subscriber’s organization policies.
   2. Subscriber shall use the expiration JWT attribute and set its value to no more than 15 minutes.
6. Subscriber acknowledges that interactions between End-Users and Answerbot which are not handed to a human Agent and transferred into a ticket are still stored in the system and it is the responsibility of Subscriber to delete those in accordance with their obligations e.g. by implementing a webhook that alerts Subscriber when those conversations are stored and (automatically) triggers deletion via the Sunshine Conversations API 
7. Subscriber acknowledges that conversations between End-Users and Answerbot that have transformed into a ticket can currently not be redacted. Deletion is possible by deleting the ticket. 
8. Subscriber acknowledges that messages deleted via the Sunshine Conversations API are only deleted for End-Users but not deleted on the Zendesk Agent Workspace. This can be achieved with the deletion of the ticket itself or use of the Redaction functionality (limitations see 7.). 
9. Subscriber acknowledges that all attachments on Sunshine Conversation channels are currently not scanned for malware in Zendesk. Subscriber shall take full responsibility of having procedures and policies in place to mitigate the risk for Subscriber’s employees. 

V. 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 not send Chat transcripts via email, by (a) disabling email piping, (b) disabling the email chat transcript option in Web Widget, and (c) not sharing exports via email from the Chat dashboard
3. Subscriber shall not enable "Agent Workspace" unless Subscriber 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.

VI. 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

VII. 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.

VIII. 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.
5. Subscriber acknowledges that the Zendesk Support Mobile Application does not display whether attachments have been scanned for and detected as malware, and Agents need to login via Browser to view this information. Subscriber shall take full responsibility of having procedures and policies in place to mitigate possible risks.
6. Subscriber acknowledges that the redaction functionality is not available in the Support Mobile Application and Agents need to login via Browser should they wish to use the redaction functionality. 
7. If Subscriber chooses to authenticate End-Users for Zendesk messaging, Subscriber acknowledges that the authentication status of an End-User is not displayed in the Support Mobile Application.

IX. 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.       

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.

---

Change Log HIPAA Enabled Accounts:

April 13th, 2023

• Section I, Support, number 4 (APIs) : 
  • Added link to authentication methods for clarity 
  • b) Removed exact time frame recommendations for rotation to align with industry best practices and removed reference to REST API Terms of Services (redundancy)
  • added c) to warn about the use of Basic Authentication for the API 
• Section II, Guide:
  • Number 1 (Help center restrictions): added reference to closed or restricted help centers to align with product functionality
  • Number 5 (@mentions): Added option to disable @mentions to align with product functionality 
• Section III, messaging: 
  • Number 1 and 2 (third party channels and private attachments): added section identifiers (i) and (ii) for clarity
  • Number 2 (private attachments) : added “URLs and/or” for clarification 
  • Number 7-10 (End-User authentication, Answerbot conversation deletion, redaction, malware scanning): full sections added for transparency
• Section IV, Sunshine Conversations: whole section added due to Sunshine Conversations in the Zendesk Suite being made part of the BAA 
• Section V, Chat, number 3 (Agent Workspace): small phrasing corrections
• Section VIII, mobile applications, number 5-7 (malware scanning, redaction, End-User authentication): whole sections added for transparency

February 24th, 2023

• Section I. Support, number 3: removed separate distinction between Support and Chat IP restrictions as the UI is now unified.
• Section I. Support, number 5: added clarification on failure to meet requirement 
• Section I. Support, number 7: “Subscriber must not” changed to “Subscriber should not”.
• Section IV. Chat, number 2: clarifies that all export functionality of data from Chat using email is prohibited, and not just scoped to transcripts and piping. 
• Section III. messaging: entire section added to account for Zendesk messaging functionality addition to the scope of Zendesk’s Business Associate Agreement.

July 9th, 2021

• Adds point 3. under Chat section for responsibilities around Agent Workspace usage.

January 21st, 2021

• Addition of number 1.11 disallows CSAT unless Subscriber assumes responsibility of data sent via email as part of the survey. 
• Caveat in number 1.7 to make allowances for Subscribers altering viewing permissions due to users already having approval to access such data on their ends.
• Updated entire document to match company style of embedded links within text as opposed to inline URLs (no impact to configuration content). 

August 2020

• Addition of Explore Enterprise covering increased dashboard sharing capabilities
• Removal of the ban on Chat attachments (Support auth requirements now cover)
• Disambiguation that the ban on ePHI in custom fields applied specifically to Insights usage and not globally
• Addition of a new section coving Add-Ons to Deployed Services, with "Side Conversations" being the first addition
• Various grammar / formatting edits (inconsequential to content)

July 13th, 2020:

• Disambiguation made regarding usage of SMS via the Service as opposed to native use of SMS for in-product 2FA. * 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."

December 13th, 2019 

• allows for Agent IP restrictions to be foregone where use case does not allow for such restrictions so long as MFA on Agent access is enforced.

December 17th, 2019 

• allows for end user comments in Guide so long as Agents moderate such comments and remove all PHI.

November 6th, 2019

• Article updated to reflect the change that subscribers may elect at their sole discretion to forgo or substitute any particular configuration so long as they assume the responsibility for such decision.

"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. "

• Other changes include
  • 1. the ability to use SMS so long as subscriber assumes all responsibility for ensuring no PHI is present in such transmissions.
  • 2. The ability to use attachments in Chat so long as subscriber assumes all responsibility for ensuring no PHI is present in such attachments.

March 6th, 2019 

• updated to include settings for Zendesk Explore

January 17th, 2019

•  updated to disallow attachments in Chat.

---

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.