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 a Business Associate Agreement (“BAA”) which recommends  Subscriber to assess and implement, as appropriate for their use case,  the following configurations, or alternatives assessed by Subscriber to be substantially similar, for any and all HIPAA Enabled Account(s) before introducing any Protected Health Information ("PHI") into the Services. 

If Subscriber chooses, at its sole discretion, to forego implementing any of the recommended configurations listed below, Subscriber shall assume sole responsibility for any unauthorized access to, or improper use of disclosure of, Subscriber’s Service Data, including any Protected Health Information, that results from any such deviation(s) from the recommended configurations 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 should 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 “Recommended”; or (ii) customized by Subscriber in a manner that establishes requirements not less secure than those established under the “Recommended” 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 "Recommended" 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 should 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. Where possible to do so, agent access should 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 should utilize the OAuth 2.0 approach and authentication scheme. Subscriber should 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 should (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 should 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 should disable password access to the API, as this approach sends the user credentials with every request which exposes them broadly, making them more easily intercepted by malicious parties.  
  5. Subscriber should 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 should 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 instance/brand/organization or alter the default setting allowing access beyond the user's own tickets or group (unless Subscriber assumes all responsibility for ensuring such users are approved by Subscriber to access all subsequent data). Subscriber acknowledges that End-User organization permissions can be set in the user profile and in the organization itself and if the settings conflict, the more permissive setting overrides the less permissive setting.
  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 to an End-User under various circumstances, e.g. when a Subscriber’s Agent responds to a Zendesk Support ticket via the email channel or initiated by an automation or trigger. By default, this email contains the most recent ticket correspondence or other information configured to be included in an automated notification, which 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 legacy Customer Satisfaction Surveys ("legacy 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, the legacy 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
  12. Subscriber acknowledges that use of the Service's Customer Satisfaction Surveys ("CSAT") functionality for the ticketing channel, if not configured accordingly, 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. Additionally, anyone with the specific CSAT URL has access to the answers given for a specific ticket. As such, when using CSAT functionality for the ticketing channel Subscriber should
    1. Configure the CSAT automation email body to not include potential ePHI and use the {{satisfaction.survey_url}} placeholder exclusively
    2. Not use the open-ended questions 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 should 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 restricted articles or using a closed or restricted instance) and therefore Subscriber should 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 should either disable the ability for End-Users to add comments in Zendesk Guide, or should 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 should enable content moderation in Zendesk Guide Service and set to "Moderate all content". No submissions containing PHI should be approved.
  4. Subscriber use of non-employee “Community Moderators” within the Gather Service should not be allowed unless Subscriber assumes responsibility for such Users' potential access to data, including possible ePHI (where applicable).
  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 should be turned off or @mentions should be disabled.

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

  1. Subscriber should 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 should 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 AI Agents) 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 should (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 should 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 should use the expiration JWT attribute and set its value to no more than 15 minutes.
  8. Subscriber acknowledges that interactions between End-Users and AI Agents 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 AI Agents 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. 
  11. 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.

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

  1. Subscriber should 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 should utilize the OAuth 2.0 approach and authentication scheme. Subscriber should 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 should (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 should 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 should 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 should (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 should 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 should use the expiration JWT attribute and set its value to no more than 15 minutes.
  6. Subscriber acknowledges that interactions between End-Users and AI Agents 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 AI Agents 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 should be put in place and are acknowledged on the BAA for any HIPAA Enabled Account(s):

  1. Subscriber should limit Agents’ access to the Zendesk Chat Service by coupling with and authenticating via the Zendesk Support Service.
  2. Subscriber should not send Chat transcripts via email, by (a) disabling email piping, (b) disabling the email chat transcript option in the Classic Web Widget, and (c) not sharing exports via email from the Chat dashboard
  3. 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 should 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 should (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) should 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 should 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 should 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) should 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 should be leveraged
  3. Notifications allowing ticket comments to be surfaced onto the lock screens of such devices should be disabled
  4. Screen inactivity locks should be enabled and configured to lock at not more than 15 minutes of inactivity.
  5. 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. 
  6. 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.   

X. Notice About Zendesk AI Functionality (“Zendesk AI”, “Advanced AI”, “Generative AI”, et al):

  1. Subscriber acknowledges that the Zendesk AI features are intended to increase productivity of the Zendesk Service(s) and should not be used in a manner which could be construed as (i) providing medical or healthcare advice, (ii) providing a diagnosis of condition or symptoms, (iii) prescribing a treatment, or (iv) in any manner preventing a User from seeking a healthcare professional’s advice, diagnosis, or treatment, (v) or otherwise providing a User with information or making decisions scoping them into or out of any healthcare plan, treatment program, testing service, or any other healthcare service which may impact their search for, or receipt of health services (unless Subscriber takes full responsibility for this decision based on their unique use case and interactions with their Users, as well as the potential implications of using AI in such a manner).
  2. Subscriber acknowledges that if using any generative AI features, Those generated AI outputs are computer-generated and not human-generated, and may produce inaccurate outputs. Zendesk does not guarantee the accuracy of these outputs.
  3. Subscriber acknowledges that if an AI Agents conversation bot greeting is used to provide a required disclaimer message to Subscriber’s End-Users, the functionality “Generate variations” shall not be activated to ensure the content integrity of the message. 
  4. Subscriber acknowledges that turning on Enhanced Writing functionality in the Admin Center will enable this functionality for all agents in their instance regardless of their roles and permissions. 

XI. The following minimum Security Configurations for usage of Zendesk QA Service Should be be put in place and are acknowledged on the BAA for any HIPAA Enabled Account(s):/strong

  1. Subscriber acknowledges that the Zendesk QA AI features are intended to increase productivity of the Zendesk Service(s) and should not be used in a manner which could be construed as (i) providing medical or healthcare advice, (ii) providing a diagnosis of condition or symptoms, (iii) prescribing a treatment, or (iv) in any manner preventing a User from seeking a healthcare professional’s advice, diagnosis, or treatment, (v) or otherwise providing a User with information or making decisions scoping them into or out of any healthcare plan, treatment program, testing service, or any other healthcare service which may impact their search for, or receipt of health services (unless Subscriber takes full responsibility for this decision based on their unique use case and interactions with their Users, as well as the potential implications of using AI in such a manner).
  2. Subscriber acknowledges that deletion or redaction in their Zendesk instance is not immediately synchronized with Zendesk QA but instead will be carried over in the following 3-6 hours.
  3. When using the Surveys functionality Subscriber should (i) disable the Zendesk QA AI assist functionality (or ensure all Agents performing QA work are cleared to see any potential data within such transaction, as well as ensuring the tenets of point 1 are in place) (ii) make sure to configure the survey in a way as not to reveal ePHI in the survey questions or descriptions (or assume the responsibility of such data in emails being sent via opportunistic StartTLS)
  4. When using the “Zendesk Chat” custom integration, Subscriber should consider setting a data retention period aligned with Subscriber’s policies to make sure data is not retained for an unlimited time.
  5. Subscriber acknowledges that when using the Sunshine Conversations API to delete parts of a Zendesk Messaging conversation, this change is not reflected in Zendesk QA. Instead, the information should be removed from the original ticket via redaction or the whole conversation should be removed.
  6. Subscriber acknowledges that Zendesk QA does not support Zendesk’s “private attachments” feature at this time. This means attachments may be accessed by anyone with access to the correct URL for said attachment and should not be used with sensitive data, including PHI. Subscriber shall assume all responsibility for the content of, and access to such URLs and/or attachment data.
  7. Subscriber acknowledges that upon initial provisions of Zendesk QA advanced connection configuration is only possible after first sync.


      

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:

 

December 16th, 2024

  • Added section XI to incorporate Zendesk QA into scope
  • Changed various instances of "Answer Bot" to "AI Agents" to denote naming convention changes and broader scope.

October 10, 2024

  • Added Section I, Support, number 12 (CSAT) and edited Section I, Support, number 11 (legacy CSAT) to accommodate for new functionality. 

March 7, 2024

  • Added Section X, Notice About Zendesk AI Functionality
  • Section I, Support, number 7 (viewing permissions):
    • Clarified that "viewing permissions" pertain to an entire "instance/brand/organization" rather than just "org."
    • Added a new provision for End-User specific organization behaviour. 
  • Section I, Support, number 9 (email):  
    • Expanded the circumstances under which Zendesk Support sends an email to an End-User to include responses via the email channel or those initiated by an automation or trigger, rather than just an agent responding to a ticket.
    • Specified that by default, automated notifications may contain the most recent ticket correspondence or other configured information, which could potentially include PHI.

 

October 25, 2023

  • Introduction: Clarified introduction language for HIPAA enabled accounts
  • Section II, Guide and Gather, number 1 (Help center restrictions): replaced IP restrictions with restricted articles for clarification

 

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.

Powered by Zendesk