HIPAA- und HDS-fähige Konten (kollektiv „gesundheitsbezogene Konten“):

Alle in diesem Dokument verwendeten Begriffe haben die im Zendesk-Geschäftspartnervertrag (BAA) oder im HDS-Aushang zum Zendesk-Kundenvertrag (HDS-Aushang) angegebene Bedeutung, wie sie für den Kontotyp (kollektiv „Gesundheitsvereinbarung“) gelten.

Für HIPAA fähige Konten bedeutet „PHI“ „geschützte Gesundheitsinformationen“, für HDS fähige Konten „PHI“ „personenbezogene Gesundheitsinformationen“.

Zendesk und der Abonnent haben eine Gesundheitsschutzvereinbarung geschlossen, in der der Abonnent empfohlen wird, die folgenden Konfigurationen oder Alternativen, die der Abonnent bewertet hat, um seine Compliance-Anforderungen nach geltendem Recht zu erfüllen, für jedes beliebige Healthcare-fähige(s) Konto(s) zu bewerten und zu implementieren, bevor er PHI in den Dienst(en) einführt.

Wenn sich der Abonnent nach eigenem Ermessen entschließt, auf die Implementierung einer der unten aufgeführten empfohlenen Konfigurationen zu verzichten, übernimmt er die alleinige Verantwortung für den unbefugten Zugriff auf die Servicedaten des Abonnenten oder die missbräuchliche Verwendung der Offenlegung, einschließlich etwaiger personenbezogener Informationen, die sich aus einer solchen Abweichung von den empfohlenen Konfigurationen durch den Abonnenten ergibt.

Der Abonnent muss Servicepläne auf der entsprechenden Ebene erworben und die erforderlichen Add-ons installiert haben (bitte wenden Sie sich an Ihren Kundenberater, wenn Sie nicht sicher sind).

Wenn der Abonnent über ein HDS-fähiges Konto verfügt, muss er in der Zendesk-Unterauftragsverarbeiterrichtlinie auf die Schaltfläche „Folgen“ klicken, um B enachrichtigungen über Änderungen an den Unterauftragsverarbeitern zu erhalten, die zur Bereitstellung der Dienste verwendet werden.

Die folgenden Mindestsicherheitskonfigurationen für Zendesk-Dienste sollten eingerichtet werden und werden in der Gesundheitsvereinbarung für jedes gesundheitsbezogene Konto bestätigt.

I. Zendesk Support:

  1. Sichere Agentenauthentifizierung durch eine der beiden folgenden Methoden:
    1. Verwendung <nativer Zendesk Support mit Kennworteinstellungen: (i) auf „Empfohlen“ gesetzt oder (ii) vom Abonnenten so angepasst, dass Anforderungen festgelegt werden, die nicht weniger sicher sind als die unter der Einstellung „Empfohlen“ festgelegten. Außerdem muss der Abonnent unter der Option in diesem Unterabschnitt die Zwei-Faktor-Authentifizierung („2FA“) nativ im Dienst aktivieren und durchsetzen und administrative Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, müssen deaktiviert werden.
    2. Verwendung einer externen Single-Sign-On-Lösung („SSO“) mit festgelegten Anforderungen, die nicht weniger sicher sind als die unter der Zendesk-Kennworteinstellung „Empfohlen“ festgelegten, und Aktivierung und Durchsetzung der Zwei-Faktor-Authentifizierung in der ausgewählten Lösung für den Zugriff aller Agenten. Verwaltungskontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, müssen deaktiviert sein.
    3. Alle Authentifizierungsoptionen, die SSO als Authentifizierungsmethode verwenden, sollten den Kennwortzugriff deaktivieren.
  2. Die SSL-Verschlüsselung (Secure Socket Layer) muss bei Konten, die für das Gesundheitswesen aktiviert sind, jederzeit aktiviert bleiben. Healthcare-fähige Konten, die eine andere Domäne als zendesk.com verwenden, müssen gehostetes SSL einrichten und aufrechterhalten.
  3. Sofern möglich, sollte der Agentenzugriff auf bestimmte IP-Adressen unter der Kontrolle des Abonnenten beschränkt werden, es sei denn, der Abonnent aktiviert die Multi-Faktor-Authentifizierung für Agenten wie oben in den Anforderungen 1.a oder 1.b beschrieben (entweder nativ im Dienst oder in der Umgebung des Abonnenten in Verbindung mit Enterprise-SSO).  Um Zweifel auszuschließen, bezieht sich der Begriff „Agentenzugriff“ auf den Zugriff eines menschlichen Agenten auf Servicedaten über die Benutzeroberfläche („UI“).
  4. Soweit das Healthcare-fähige Konto des Abonnenten Anrufe an die Zendesk-Anwendungsprogrammierschnittstelle(n) („API“) ermöglicht, ist der Abonnent dafür verantwortlich, die Sicherheitsaspekte aller Abonnenten oder Drittanbieter zu verstehen, die berechtigt sind, Servicedaten und PHI über solche Zugriffe und/oder Integrationen zu erstellen, zuzugreifen, zu ändern oder zu löschen. Für den Zugriff auf diese API bietet Zendesk verschiedene Methoden an, wie hier beschrieben. Der Abonnent muss die folgenden Best Practices für die Sicherheit implementieren, die auf dem verwendeten API-Modell basieren:
    1. OAuth 2.0-Ansatz.  Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt jedoch voraus, dass die entsprechenden Berechtigungen von einem Endbenutzer akzeptiert werden.  Der Abonnent sollte nach Möglichkeit den OAuth 2.0-Ansatz und das Authentifizierungsschema verwenden. Der Abonnent sollte jedem OAuth Client einen aussagekräftigen und eindeutigen Clientnamen und eine eindeutige Kennung geben. Die für jedes OAuth Token gewährten Berechtigungen sollten das geringste zur Ausführung der erforderlichen Aufgaben erforderliche Recht enthalten.
    2. REST-API-Tokenansatz.  Dieses Modell ist das umfassendste und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen. Aufgrund seiner Beschaffenheit bietet es den weitesten Zugriff und die weitesten Funktionen und sollte mit Vorsicht verwendet werden. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Dienst ein eindeutiges Token verwenden und dem Token einen aussagekräftigen Namen mit einer bezeichnenden Funktion zuweisen; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist nach vernünftigem Ermessen erforderlich und wird durchgängig verschlüsselt; (iii) anerkennen, dass der Abonnent das zugehörige Token sofort rotieren sollte, wenn das API-Token an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) das Token mindestens häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten rotieren.
    3. Wenn möglich, sollte der Abonnent den Kennwortzugriff auf die API deaktivieren, da der Benutzer bei jeder Anfrage Anmeldedaten erhält, wodurch er leichter von bösartigen Parteien abgefangen werden kann.
  5. Der Abonnent sollte „Authentifizierung zum Herunterladen erforderlich“ aktivieren, damit er für den Zugriff auf Anhänge eine Authentifizierung verlangen kann. Andernfalls kann jeder, der Zugriff auf die richtige URL für diesen Anhang hat, auf einen uneingeschränkten Anhang zugreifen. In solchen Fällen ist der Abonnent für den Inhalt und den Zugriff auf diese Anhangsdaten verantwortlich.
  6. Der Abonnent sollte auf allen Agenten, Administratoren und Inhabern, die auf Endpunkte zugreifen, systematisch einen Bildschirmschoner mit Kennwortsperre oder einen Startbildschirm erzwingen, der maximal 15 Minuten lang inaktiv ist.
  7. Der Abonnent sollte weder die Anzeigeberechtigungen ändern, die es einem Benutzer ermöglichen, Aktualisierungen für eine gesamte Instanz/Marke/Organisation zu sehen, noch die Standardeinstellung ändern, die den Zugriff über die eigenen Tickets oder Gruppen des Benutzers hinaus ermöglicht (es sei denn, er übernimmt die Verantwortung dafür, dass diese Benutzer vom Abonnenten die Genehmigung zum Zugriff auf alle nachfolgenden Daten erhalten). Der Abonnent erkennt an, dass automatisierte Workflows und Verteilungsfunktionen Tickets Agenten oder Agentengruppen zuweisen und ihnen dadurch Zugriff gewähren können. Der Abonnent sollte diese Workflows so konfigurieren, dass Agenten nur Zugriff gewährt wird, der den beabsichtigten Berechtigungen und den am wenigsten privilegierten Anforderungen des Abonnenten entspricht. Der Abonnent erkennt an, dass Organisationsberechtigungen für Endbenutzer im Benutzerprofil und in der Organisation selbst festgelegt werden können. Wenn die Einstellungen in Konflikt stehen, hat die freizügigere Einstellung Vorrang vor der weniger freizügigen Einstellung.
  8. Der Abonnent erkennt an, dass Zendesk nicht dafür verantwortlich ist, E-Mail-Übertragungen von Endbenutzern und zugehörige Servicedaten vor Eingang in die Zendesk Support-Instanz des Abonnenten zu sichern. Hierzu gehören alle personenbezogenen Informationen, die per E-Mail über Antworten auf Zendesk Support-Tickets weitergegeben werden, einschließlich, aber nicht beschränkt auf Ticketkommentare oder Anhänge.
  9. Der Abonnent erkennt an, dass Zendesk Support unter verschiedenen Umständen Benachrichtigungen an Endbenutzer sendet, z. B. wenn der Agent eines Abonnenten über den E-Mail-Kanal auf ein Zendesk Support-Ticket antwortet oder durch eine Automatisierung oder einen Auslöser ausgelöst wird. Standardmäßig können die Benachrichtigungen Korrespondenz zwischen Agenten/Administratoren des Abonnenten und Endbenutzern oder andere Informationen enthalten, die für eine automatische Benachrichtigung konfiguriert sind und möglicherweise PHI enthalten. Um den Abonnenten noch besser zu schützen, sollte seine Zendesk Support-Instanz den Endbenutzer nur so konfigurieren, dass er benachrichtigt wird, dass ein Agent geantwortet hat oder seine Korrespondenz in Zendesk aktualisiert wurde, und dass er sich bei Zendesk Support authentifizieren muss, um den Inhalt der Nachricht zu sehen.
  10. Der Abonnent erkennt an, dass SMS-Funktionen, die nach eigenem Ermessen in allen Zendesk-Diensten genutzt werden, durch SMS und/oder zugehörige Protokolle untermauert werden, was die unverschlüsselte Übertragung von Nachrichten in oder aus den Diensten beinhalten kann.  Die SMS-Funktionalität sollte also entweder
    1. nicht in einem Healthcare-fähigen Konto* verwendet werden oder
    2. falls verwendet, übernimmt der Abonnent die gesamte Verantwortung für die Nutzung dieser Funktionalität.
  11. Der Abonnent erkennt an, dass die Nutzung der Legacy-Kundenzufriedenheitsumfragen des Dienstes („Legacy CSAT“) Servicedaten (die PHI enthalten können), die mit dem Support Ticket verknüpft sind, per E-Mail sendet, um die Bewertung des Benutzers zu erhalten, deren Verschlüsselungsstatus nicht von Zendesk kontrolliert wird. Daher sollte die LegacyCSAT-Funktionalität entweder:
    1. nicht in einem Healthcare-fähigen Konto* verwendet werden oder
    2. falls verwendet, übernimmt der Abonnent die gesamte Verantwortung für die Nutzung dieser Funktionalität.
  12. Der Abonnent erkennt an, dass die Nutzung der Kundenzufriedenheitsumfragen (CSAT) des Dienstes für den Ticketkanal, wenn sie nicht entsprechend konfiguriert ist, Servicedaten (die möglicherweise PHI enthalten) des Support Tickets per E-Mail sendet, um die Bewertung des Benutzers zu erhalten, deren Verschlüsselungsstatus nicht von Zendesk kontrolliert wird. Außerdem hat jeder Benutzer mit der CSAT URL Zugriff auf die Antworten, die zu einem bestimmten Ticket gegeben werden. Daher sollte der Abonnent bei Verwendung der CSAT-Funktionalität für den Ticketkanal
    1. Konfigurieren Sie den E-Mail-Text der CSAT-Automatisierung so, dass er keine potenzielle PHI enthält und verwenden Sie ausschließlich den Platzhalter „{{satisfaction.survey_url}}“.
    2. Keine offenen Fragen verwenden

* Zur Vermeidung von Zweifeln gelten die in Abschnitt 10 bezüglich SMS in Bezug auf PHI genannten Dateneinschränkungen nicht für die produktinterne 2FA-Nutzung (wie in Abschnitt 1.a beschrieben), da diese Funktionalität lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.

II. Zendesk Guide und Gather:

  1. Der Abonnent erkennt an, dass die Guide- und Gather-Dienste von Natur aus öffentlich sind (d. h. keine beschränkten Beiträge nutzen oder eine geschlossene oder beschränkte Instanz verwenden);
  2. Der Abonnent sollte entweder die Möglichkeit deaktivieren, Kommentare in Zendesk Guide hinzuzufügen, oder PHI moderieren und dafür verantwortlich sein (siehe Abschnitt 3).
  3. Wenn der Zendesk Guide-Dienst Guide Professional oder Enterprise ist, sollten Abonnenten die Gather-Funktionalität in Zendesk Guide deaktivieren, damit Endbenutzer keine neuen Posts erstellen können. Wenn die Gather-Funktionen aufgrund des beabsichtigten Anwendungsfalls des Abonnenten nicht aktiviert werden können, sollten sie die Inhaltsmoderation im Zendesk Guide-Dienst aktivieren und auf „Alle Inhalte moderieren“ setzen. Es sollten keine Einreichungen genehmigt werden, die PHI enthalten.
  4. Die Verwendung von „Community-Moderatoren“ außerhalb des Gather-Dienstes durch Abonnenten sollte nur zulässig sein, wenn der Abonnent die Verantwortung für den potenziellen Zugriff dieser Benutzer auf Daten übernimmt, einschließlich etwaiger PHI (falls zutreffend).
  5. Der Abonnent erkennt an, dass „@Erwähnungen“ von Mitgliedern der Gather-Community möglich sind, wenn Endbenutzer öffentliche Profile haben können. Sollte diese Funktionalität in ihrem Anwendungsfall als Risiko betrachtet werden, sollten öffentliche Profile deaktiviert oder @Erwähnungen deaktiviert werden.
     

III. Zendesk Messaging:

  1. Der Abonnent sollte Kanalintegrationen für Social-Media-Messaging nur aktivieren, wenn er die volle Verantwortung dafür übernimmt, (i) sicherzustellen, dass in Social-Media-Nachrichten keine PHI enthalten sind, oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abschließt.
  2. Der Abonnent sollte die Möglichkeit deaktivieren, dass Endbenutzer Dateien an Messaging-Konversationen anhängen, und entweder (i) sichere Anhänge aktivieren oder (ii) sicherstellen, dass Agenten keine Dateien mit ePHI an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL für diesen Anhang hat, auf einen uneingeschränkten Anhang zugreifen.  In solchen Fällen ist der Abonnent für den Inhalt und den Zugriff auf diese URLs und/oder Anhangsdaten verantwortlich.
  3. Der Abonnent ist dafür verantwortlich, dass alle Agenten und Light Agents alle eingehenden Nachrichten aller Endbenutzer sehen können.
  4. Wenn der Abonnent oder seine Agenten auf Integrationen für APIs und Webhooks zugreifen oder diese entwickeln (z. B. als Teil eines für AI Agents erstellten Konversationsflusses) oder das Messaging-Erlebnis anpassen, ist er dafür verantwortlich, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows zu verstehen und für alle Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter), die berechtigt sind, Servicedaten und ePHI über einen solchen Zugriff und/oder eine solche Integration zu erstellen, zuzugreifen, zu ändern oder zu löschen.
  5. Wenn der Abonnent einem Agenten die Berechtigung zur Teilnahme an einer Messaging-Konversation entziehen möchte, während die Messaging-Konversation gegenwärtig aktiv ist, trägt er die gesamte Verantwortung dafür, dass der Zugriff dieses Agenten auf Zendesk beendet wird.
  6. Standardmäßig sind Web Widget-Konversationen mit Endbenutzern persistent und für Endbenutzer sichtbar, wenn sie vom selben Gerät aus zum Web-Chat zurückkehren. Der Abonnent muss diese Funktion entweder deaktivieren oder die gesamte Verantwortung dafür übernehmen, dass Endbenutzer keine Geräte teilen.
  7. Wenn der Abonnent die Authentifizierung für Endbenutzer implementieren möchte, ist er dafür verantwortlich, diese auf sichere Weise gemäß Best Practices und Branchenstandards zu implementieren.
    1. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Authentifizierungskanal einen eindeutigen JWT-Signaturschlüssel verwenden und dem Token einen aussagekräftigen Namen mit einer bezeichnenden Funktion zuweisen; (ii) JWT-Signaturschlüssel nicht an Dritte weitergeben, es sei denn, dies ist nach vernünftigem Ermessen erforderlich und wird durchgängig verschlüsselt; (iii) anerkennen, dass der Abonnent den zugehörigen JWT-Signaturschlüssel sofort rotieren sollte, wenn er mit einem Dritten geteilt wird und auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) mindestens den JWT-Signaturschlüssel in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten häufig rotieren.
    2. Der Abonnent sollte das Attribut „JWT-Ablaufdatum“ verwenden und seinen Wert auf maximal 15 Minuten setzen.
  8. Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und AI Agents, die nicht an einen menschlichen Agenten übergeben und an ein Ticket weitergeleitet werden, weiterhin im System gespeichert werden und dass es in der Verantwortung des Abonnenten liegt, sie gemäß seinen Verpflichtungen zu löschen (z. B. durch Implementieren eines Webhooks, der den Abonnenten benachrichtigt, wenn diese Konversationen gespeichert werden, und (automatisch) über die Sunshine Conversations API die Löschung auslöst). 
  9. Der Abonnent erkennt an, dass Konversationen zwischen Endbenutzern und AI Agents, die in ein Ticket umgewandelt wurden, derzeit nicht geschwärzt werden können. Das Ticket kann durch Löschen gelöscht werden. 
  10. Der Abonnent erkennt an, dass Anhänge von Endbenutzern in Messaging-Kanälen derzeit nicht in Zendesk auf Malware untersucht werden. Der Abonnent trägt die volle Verantwortung dafür, dass Verfahren und Richtlinien zur Risikominderung für die Vermögenswerte des Abonnenten eingerichtet sind. 
  11. Der Abonnent erkennt an, dass bei Verwendung der Funktion „Nebenkonversation“ möglicherweise „untergeordnete Tickets“ und/oder „Nebenkonversationen“ in der Support-Instanz des Abonnenten erstellt oder per Ticket, E-Mail, Slack oder Integrationen an Empfänger gesendet werden (nach Ermessen des Agenten). Wenn der Abonnent diese Funktion in einem Healthcare-fähigen Konto verwendet, übernimmt er die gesamte Verantwortung dafür, entweder (i) sicherzustellen, dass in solchen Nachrichten keine PHI enthalten ist, oder (ii) dass PHI in Nachrichten vorhanden sein könnte. Der Abonnent haftet allein für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, dem unbefugten Zugriff, der unbefugten Nutzung oder der unbefugten Offenlegung von PHI, die sich aus dem Austausch von Nachrichten über die Funktion „Nebenkonversation“ ergeben.

IV. Zendesk Sunshine Conversations:

  1. Der Abonnent sollte Kanalintegrationen von Drittanbietern nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, sicherzustellen, dass (i) in Kanalnachrichten von Drittanbietern keine PHI enthalten sind oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abgeschlossen wird.
  2. Der Abonnent ist dafür verantwortlich, die Sicherheitsaspekte aller Abonnenten oder Drittanbieter zu verstehen, die berechtigt sind, Servicedaten und PHI über die Sunshine Conversations Application Programming Interface(s) („API“) zu erstellen, darauf zuzugreifen, zu ändern oder zu löschen. Für den Zugriff auf diese APIs muss der Abonnent die folgenden Best Practices für die Sicherheit implementieren, die auf dem verwendeten API-Modell basieren:
    1. OAuth 2.0-Ansatz.  Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt jedoch voraus, dass die entsprechenden Berechtigungen von einem Endbenutzer akzeptiert werden.  Der Abonnent sollte nach Möglichkeit den OAuth 2.0-Ansatz und das Authentifizierungsschema verwenden. Der Abonnent sollte jedem OAuth Client einen aussagekräftigen und eindeutigen Clientnamen und eine eindeutige Kennung geben. 
    2. REST-API-Tokenansatz.  Dieses Modell ist das umfassendste und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen.  Aufgrund seiner Beschaffenheit bietet es den weitesten Zugriff und die weitesten Funktionen und sollte mit Vorsicht verwendet werden. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Dienst ein eindeutiges Token verwenden und dem Token einen aussagekräftigen Namen mit einer bezeichnenden Funktion zuweisen; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist nach vernünftigem Ermessen erforderlich und wird durchgängig verschlüsselt; (iii) anerkennen, dass der Abonnent das zugehörige Token sofort rotieren sollte, wenn das API-Token an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) das Token entsprechend der Organisationsrichtlinie des Abonnenten häufig rotieren.  
    3. Wenn der Abonnent oder seine Agenten auf APIs und Webhooks zugreifen oder Integrationen für sie entwickeln oder das Sunshine Conversations Erlebnis anpassen, ist er dafür verantwortlich, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows zu verstehen und für alle Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter), die berechtigt sind, Servicedaten und PHI über einen solchen Zugriff und/oder solche Integrationen zu erstellen, zuzugreifen, zu ändern oder zu löschen.
  3. Der Abonnent erkennt an, dass die für Zendesk Support konfigurierten IP-Beschränkungen nicht für die Sunshine Conversations API gelten. Der Abonnent trägt die volle Verantwortung für die Beschränkung des Zugriffs auf die Sunshine Conversations API und API-Token, wie in Absatz 2.b beschrieben und in Übereinstimmung mit den Richtlinien des Abonnenten. 
  4. Der Abonnent sollte die Möglichkeit für Endbenutzer deaktivieren, Dateien an Sunshine Conversations anzuhängen, und die volle Verantwortung dafür übernehmen, entweder sichere Anhänge zu aktivieren oder sicherzustellen, dass Agenten keine Dateien mit PHI an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL für diesen Anhang hat, auf einen uneingeschränkten Anhang zugreifen. In solchen Fällen ist der Abonnent für den Inhalt und den Zugriff auf diese Anhangsdaten verantwortlich.
  5. Wenn der Abonnent die Authentifizierung für Endbenutzer implementieren möchte, übernimmt er die gesamte Verantwortung für die robuste Implementierung dieser Authentifizierung in Übereinstimmung mit bewährten Sicherheitspraktiken und Branchenstandards.
    1. Bei Verwendung dieses Ansatzes sollte der Abonnent (i) für jeden Authentifizierungskanal einen eindeutigen JWT-Signaturschlüssel verwenden und dem Token einen aussagekräftigen Namen mit einer bezeichnenden Funktion zuweisen; (ii) JWT-Signaturschlüssel nicht an Dritte weitergeben, es sei denn, dies ist nach vernünftigem Ermessen erforderlich und wird durchgängig verschlüsselt; (iii) anerkennen, dass der Abonnent den zugehörigen JWT-Signaturschlüssel sofort rotieren sollte, wenn er mit einem Dritten geteilt wird und auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) mindestens den JWT-Signaturschlüssel in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten häufig rotieren.
    2. Der Abonnent sollte das Attribut „JWT-Ablaufdatum“ verwenden und seinen Wert auf maximal 15 Minuten setzen.
  6. Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und AI Agents, die nicht an einen menschlichen Agenten übergeben und an ein Ticket weitergeleitet werden, weiterhin im System gespeichert werden und dass es in der Verantwortung des Abonnenten liegt, sie gemäß seinen Verpflichtungen zu löschen, z. B. durch Implementieren eines Webhooks, der den Abonnenten benachrichtigt, wenn diese Konversationen gespeichert werden, und (automatisch) über die Sunshine Conversations API die Löschung auslöst. 
  7. Der Abonnent erkennt an, dass Konversationen zwischen Endbenutzern und AI Agents, die in ein Ticket umgewandelt wurden, derzeit nicht geschwärzt werden können. Das Ticket kann durch Löschen gelöscht werden. 
  8. Der Abonnent erkennt an, dass über die Sunshine Conversations API gelöschte Nachrichten nur für Endbenutzer, nicht aber im Zendesk-Arbeitsbereich für Agenten gelöscht werden. Dies kann durch Löschen des Tickets selbst oder Verwenden der Schwärzungsfunktion (Einschränkungen siehe 7.) erreicht werden. 
  9. Der Abonnent bestätigt, dass gegenwärtig nicht alle Anhänge in Sunshine Conversation-Kanälen in Zendesk auf Malware untersucht werden. Der Abonnent trägt die volle Verantwortung dafür, dass Verfahren und Richtlinien zur Risikominderung für die Mitarbeiter des Abonnenten eingerichtet sind. 

V. Zendesk Chat:

  1. Der Abonnent sollte den Zugriff der Agenten auf den Zendesk Chat Service beschränken, indem er sich mit dem Zendesk Support Service koppelt und über ihn authentifiziert.
  2. Abonnenten sollten Chatprotokolle nicht per E-Mail senden, indem sie (a) die E-Mail-Piping deaktivieren, (b) im Classic Web Widget die Option „E-Mail-Chatprotokoll“ deaktivieren und (c) im Chat-Dashboard keine Exporte per E-Mail teilen.
  3. Der Abonnent trägt die volle Verantwortung dafür, sicherzustellen, dass (i) keine personenbezogenen Informationen in Chats vorhanden sind und/oder (ii) dass alle Agenten vom Abonnenten die entsprechenden Daten sehen können.

VI. Zendesk Explore Service:

Der Abonnent erkennt an, dass PHI im Explore-Produkt über Benutzernamen, Tickettitel, Feld- und Formularauswahl und alle Inhalte in Freitextfeldern angezeigt werden kann.

  1. Für jede Serviceinstanz, die PHI enthält, sollte der Abonnent (i) nur Agenten Zugriff auf die Explore-Oberfläche gewähren, die in der übergeordneten Serviceinstanz (den übergeordneten Serviceinstanzen) auf alle Tickets/Anrufe/Chats zugreifen können, die PHI enthalten können, und (ii) einen solchen Zugriff gewähren, wobei die geringsten für die Nutzung von Explore in seiner Umgebung erforderlichen Berechtigungen zu berücksichtigen sind. Weitere Informationen zum Konfigurieren der Zugriffsebenen in Explore finden Sie hier.
  2. Wenn der Abonnent die „Export“-Funktionalität nutzt, erkennt er an, dass PHI auf ein Gerät übertragen werden kann, das dem Abonnenten Zugriff auf die Agentenoberfläche gewährt, und dass alle zugehörigen Kontrollen auf diesen Geräten in der Verantwortung des Abonnenten liegen, und ii) sollte der Abonnent die Nutzung der nativen Exportfunktionalität per E-Mail für die exportierten Berichte ablehnen, es sei denn, er übernimmt die Verantwortung dafür, (a) sicherzustellen, dass in diesen Exporten keine PHI enthalten sind, oder (b) dass E-Mail-Dienste, die für solche Übertragungen verwendet werden, eine Verschlüsselung über das nach den damals geltenden PCI-Standards zulässige Mindestverschlüsselungsprotokoll ermöglichen.

* Besondere Überlegungen zur Verwendung von Explore Enterprise:

Der Abonnent erkennt an, dass die Nutzung des Explore Enterprise-Dienstes möglicherweise mit erweiterten Funktionen zum Teilen und Exportieren von Daten verbunden ist. Der Abonnent muss:

  1. entweder (i) sicherstellen, dass in solchen Dashboards kein PHI vorhanden ist, und/oder (ii) Dashboards nur mit Agenten, Gruppen, Listen oder Endbenutzern teilen, die zum Anzeigen und Empfangen solcher Daten berechtigt sind.
  2. IP-Beschränkungen nutzen
  3. Wenn der Abonnent Dashboards über den Uniform Resource Locator (URL) teilt, erkennt er an, dass die Daten nicht über einen Zugriffslink mit einzelnen Benutzern oder Gruppen geteilt werden, sondern über einen Link. Der Abonnent sollte daher (i) den Kennwortschutz aktivieren, (ii) sicherstellen, dass die Komplexität, Rotation, Speicherung und Verteilung der ausgewählten Kennwörter an die empfangende Partei den Kennwortrichtlinien des Abonnenten zum Schutz der in solchen Dashboards enthaltenen Daten entspricht, und (iii) bei Verdacht oder Bestätigung der Offenlegung unverzüglich rotieren.

VII. Hinweis zu produktintegrierten Funktionen für bereitgestellte verbundene Dienste („Add-ons“):

  1. Collaboration Deployed Associated Service: „Nebenkonversationen.“ Der Abonnent erkennt an, dass bei Verwendung der Funktion „Nebenkonversationen“ möglicherweise „untergeordnete Tickets“ und/oder „Nebenkonversationen“ in der Support-Instanz des Abonnenten erstellt oder über Tickets, E-Mails, Slack oder Integrationen an Empfänger gesendet werden (nach Ermessen des Agenten). Wenn der Abonnent diese Funktion in einem Healthcare-fähigen Konto verwendet, übernimmt er die gesamte Verantwortung dafür, entweder (i) sicherzustellen, dass in solchen Nachrichten keine PHI enthalten ist, oder (ii) dass PHI in Nachrichten vorhanden sein könnte. Der Abonnent haftet allein für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, dem unbefugten Zugriff, der unbefugten Nutzung oder der unbefugten Offenlegung von PHI, die sich aus dem Austausch von Nachrichten über die Funktion „Nebenkonversation“ ergeben.

VIII. Mobile Zendesk-Anwendungen (oder Zugriff über Mobilgeräte wie Smartphones oder Tablets):

  1. Die Nutzung muss die Verschlüsselung auf Geräteebene umfassen
  2. Biometrischer oder PIN-Zugriff auf die höchste zulässige Geräteeinstellung sollte verwendet werden
  3. Benachrichtigungen, mit denen Ticketkommentare auf den Sperrbildschirmen solcher Geräte angezeigt werden können, sollten deaktiviert werden.
  4. Inaktivitätssperren sollten aktiviert und so konfiguriert sein, dass sie nicht länger als 15 Minuten inaktiv sind.
  5. Der Abonnent erkennt an, dass die Schwärzungsfunktion in der mobilen Support-Anwendung nicht verfügbar ist und Agenten sich per Browser anmelden müssen, wenn sie die Schwärzungsfunktion nutzen möchten. 
  6. Wenn sich der Abonnent für die Authentifizierung von Endbenutzern für Zendesk Messaging entscheidet, bestätigt er, dass der Authentifizierungsstatus eines Endbenutzers in der mobilen Support-Anwendung nicht angezeigt wird.

IX. Zendesk Insights: Support für diesen Dienst wurde am 5. Februar 2021 eingestellt.

X. Hinweis zu den Funktionen von Zendesk KI („Zendesk KI“, „Fortschrittliche KI“, „Generative KI“ usw.):

  1. Der Abonnent erkennt an, dass die KI-Funktionen von Zendesk die Produktivität der Zendesk-Dienste steigern sollen und nicht in einer Weise verwendet werden sollten, die so ausgelegt werden könnte, dass sie (i) medizinische Beratung oder medizinische Beratung, (ii) Diagnose von Krankheit oder Symptomen, (iii) Verschreibung einer Behandlung oder (iv) Verhinderung, dass ein Benutzer den Rat, die Diagnose oder die Behandlung eines medizinischen Fachpersonals in Anspruch nimmt, (v) oder anderweitig Informationen bereitstellen oder Entscheidungen treffen, die ihn in einen Gesundheitsplan, ein Behandlungsprogramm, einen Testdienst oder einen anderen Gesundheitsdienst einbeziehen oder daraus entfernen, was seine Suche nach Gesundheitsdiensten oder den Erhalt von Gesundheitsdiensten beeinträchtigen könnte (es sei denn, der Abonnent übernimmt die volle Verantwortung für diese Entscheidung basierend auf seinem speziellen Anwendungsfall und seinen Interaktionen mit seinen Benutzern sowie den potenziellen Auswirkungen einer solchen Verwendung von KI).
  2. Der Abonnent erkennt an, dass bei Verwendung Generative KI-Funktionen diese KI-Ausgaben computergeneriert und nicht von Menschen generiert werden und möglicherweise ungenaue Ausgaben erzeugen. Zendesk übernimmt keine Garantie für die Genauigkeit dieser Ausgaben.
  3. Der Abonnent erkennt an, dass die Funktion „Variationen generieren“ nicht aktiviert wird, um die inhaltliche Integrität der Nachricht sicherzustellen, wenn ein AI Agents Konversations-Bot Gruß verwendet wird, um eine erforderliche Haftungsausschlussnachricht an die Endbenutzer des Abonnenten zu senden. 
  4. Der Abonnent erkennt an, dass die erweiterte Schreibfunktion im Admin Center für alle Agenten in ihrer Instanz unabhängig von ihren Rollen und Berechtigungen aktiviert wird. 

XI. Zendesk QA

  1. Der Abonnent erkennt an, dass die KI-Funktionen von Zendesk QA die Produktivität der Zendesk-Dienste steigern sollen und nicht in einer Weise verwendet werden sollten, die so ausgelegt werden könnte, dass sie (i) medizinische Beratung oder medizinische Betreuung, (ii) Diagnose von Krankheit oder Symptomen, (iii) Verschreibung einer Behandlung oder (iv) Verhinderung, dass ein Benutzer den Rat, die Diagnose oder die Behandlung eines medizinischen Fachpersonals in Anspruch nimmt, (v) oder anderweitig Informationen bereitstellen oder Entscheidungen treffen, die ihn in einen Gesundheitsplan, ein Behandlungsprogramm, einen Testdienst oder einen anderen Gesundheitsdienst einbeziehen oder daraus entfernen, was seine Suche nach Gesundheitsdiensten oder den Erhalt von Gesundheitsdiensten beeinträchtigen könnte (es sei denn, der Abonnent übernimmt die volle Verantwortung für diese Entscheidung basierend auf seinem speziellen Anwendungsfall und seinen Interaktionen mit seinen Benutzern sowie den potenziellen Auswirkungen einer solchen Nutzung von KI).
  2. Der Abonnent erkennt an, dass das Löschen oder Schwärzen in seiner Zendesk-Instanz nicht sofort mit Zendesk QA synchronisiert wird, sondern innerhalb der folgenden 3-6 Stunden.
  3. Bei Verwendung der Umfragefunktion sollte der Abonnent (i) die Unterstützungsfunktion Zendesk QA KI deaktivieren (oder sicherstellen, dass alle Agenten, die QA durchführen, gelöscht werden, um potenzielle Daten in einer solchen Transaktion zu sehen, und sicherstellen, dass die Grundsätze von Punkt 1 eingehalten werden) (ii) sicherstellen, dass die Umfrage so konfiguriert wird, dass PHI in den Fragen oder Beschreibungen der Umfrage nicht angegeben werden (oder dass diese Daten in E-Mails, die über opportunistische StartTLS gesendet werden, die Verantwortung übernehmen)
  4. Wenn der Abonnent die angepasste Integration „Zendesk Chat“ verwendet, sollte er eine an den Richtlinien des Abonnenten ausgerichtete Aufbewahrungsfrist festlegen, um sicherzustellen, dass Daten nicht unbegrenzt aufbewahrt werden.
  5. Wenn ein Abonnent Teile einer Zendesk Messaging-Konversation mit der Sunshine Conversations API löscht, wird diese Änderung in Zendesk QA nicht berücksichtigt. Stattdessen sollten die Informationen per Schwärzung aus dem ursprünglichen Ticket entfernt werden oder die gesamte Konversation.
  6. Der Abonnent erkennt an, dass Zendesk QA die Funktion „Private Anhänge“ von Zendesk gegenwärtig nicht Support. Das bedeutet, dass Anhänge von jedem aufgerufen werden können, der Zugriff auf die richtige URL für diesen Anhang hat, und nicht mit vertraulichen Daten, einschließlich PHI, verwendet werden sollten. Der Abonnent ist für den Inhalt und den Zugriff auf solche URLs und/oder Anhangsdaten verantwortlich.
  7. Der Abonnent erkennt an, dass die erweiterte Verbindungskonfiguration erst nach der ersten Synchronisation möglich ist, wenn die anfängliche Bereitstellung von Zendesk QA erfolgt ist.

XII. Zendesk Workforce Management (WFM):

  1. Der Abonnent erkennt an, dass
    1. Die WFM Standardrolle „Administrator“ hat Zugriff auf alle Agentenaktivitäten und Einstellungen für den WFM Service (einschließlich der in Punkt 2 genannten Stichwörter).
    2. Die Standardrolle „Agent“ hat Zugriff auf die Aktivitäten des Agenten, es sei denn, Administratoren konfigurieren sie hier durch Erstellung angepasster Rollen für unterschiedliche Zugriffsberechtigungen.
  2. Der Abonnent erkennt an, dass Stichwörter, die von Agenten, Administratoren oder einer vordefinierten Systemlogik in Tickets in Support angewendet werden, für jeden Benutzer, der berechtigt ist, diese Ticketaktivität zu sehen, im WFM Produkt sichtbar sind. Wenn der Abonnent Stichwörter als vertraulich einstuft, sollte der Zugriff entsprechend konfiguriert werden.

Haftungsausschluss: Aufgrund von Gesetzes- oder Verordnungsänderungen oder Änderungen im Zendesk-Dienst können sich die Sicherheitskonfigurationen in diesem Dokument von Zeit zu Zeit ändern. Dieses Dokument enthält Empfehlungen von Zendesk zu den derzeit beschriebenen minimalen effektiven Sicherheitskonfigurationen zum Schutz von PHI in den Zendesk-Produkten. Dieses Dokument stellt weder eine umfassende Vorlage für alle Kontrollen dieser Daten noch eine Rechtsberatung dar. Jeder Zendesk-Abonnent sollte sich in Bezug auf seine HIPAA- oder HDS-Compliance-Anforderungen einen eigenen Rechtsbeistand holen und die zusätzlichen Änderungen an seinen Sicherheitskonfigurationen gemäß seiner eigenen unabhängigen Analyse vornehmen, solange diese Änderungen die Sicherheit der in diesem Dokument beschriebenen Konfigurationen nicht beeinträchtigen oder beeinträchtigen.

 

Änderungsprotokoll:

10. November 2025

  • Name der Kundenvereinbarung von „Hauptdienstleistungsvertrag“ in „Zendesk-Kundenvertrag“ geändert

24. Januar 2025

  • Konsolidierte HIPAA und HDS-Konfigurationen

27. Dezember 2024

  • Abschnitt XII zur Einbeziehung von Zendesk Workforce Management („WFM“) in den Anwendungsbereich hinzugefügt

16. Dezember 2024

  • Abschnitt XI zur Integration von Zendesk QA in den Anwendungsbereich hinzugefügt
  • Verschiedene Instanzen von „Answer Bot“ wurden in „AI Agents“ geändert, um Konventionsänderungen und einen größeren Anwendungsbereich zu kennzeichnen.

10. Oktober 2024

  • Abschnitt I, Support, Nummer 12 (CSAT) hinzugefügt und Abschnitt I, Support, Nummer 11 (Legacy CSAT) bearbeitet, um neue Funktionen zu nutzen. 

7. März 2024

  • Abschnitt X, Hinweis zur Zendesk KI hinzugefügt
  • Abschnitt I, Support, Nummer 7 (Anzeigeberechtigungen):
    • Klargestellt: „Anzeigeberechtigungen“ beziehen sich auf eine gesamte „Instanz/Marke/Organisation“ und nicht nur auf „Organisation“.
    • Eine neue Bestimmung für das Verhalten von Endbenutzern in der Organisation wurde hinzugefügt. 
  • Abschnitt I, Support, Nummer 9 (E-Mail):  
    • Die Umstände, unter denen Zendesk Support eine E-Mail an einen Endbenutzer sendet, wurden erweitert und umfassen Antworten über den E-Mail-Kanal oder durch Automatisierung oder Auslöser, statt nur durch einen Agenten auf ein Ticket zu antworten.
    • Gibt an, dass automatisierte Benachrichtigungen standardmäßig die neueste Ticketkorrespondenz oder andere konfigurierte Informationen enthalten können, die möglicherweise PHI enthalten.
       

25. Oktober 2023

  • Einführung: Klare Einführungssprache für HIPAA aktivierte Konten
  • Abschnitt II, Guide und Gather, Nummer 1 (Help Center Restrictions): IP-Beschränkungen durch beschränkte Beiträge zur Klarstellung ersetzt

13. April 2023

  • Abschnitt I, Support, Nummer 4 (APIs): 
    • Link zu Authentifizierungsmethoden hinzugefügt, um die Übersichtlichkeit zu verbessern 
    • b) genaue Zeitrahmenempfehlungen für Rotationen entfernt, um Best Practices der Branche zu erfüllen, und Verweis auf die Allgemeinen Geschäftsbedingungen der REST-API entfernt (Redundanz)
    • hat c) hinzugefügt, um vor der Verwendung der Standardauthentifizierung für die API zu warnen 
  • Abschnitt II, Leitfaden:
    • Nummer 1 (Help Center Restrictions): Bezug auf geschlossene oder beschränkte Help Center hinzugefügt, um die Produktfunktionalität anzupassen
    • Nummer 5 (@Erwähnungen): Option zum Deaktivieren von @Erwähnungen hinzugefügt, um die Produktfunktionalität anzupassen 
  • Abschnitt III, Messaging: 
    • Nummer 1 und 2 (Drittanbieterkanäle und private Anhänge): Abschnittskennungen (i) und (ii) zur Verdeutlichung hinzugefügt
    • Nummer 2 (private Anhänge): „URLs und/oder“ zur Klarstellung hinzugefügt 
    • Nummer 7-10 (Endbenutzerauthentifizierung, Löschen von Answerbot-Konversationen, Schwärzung, Malware-Scanning): Aus Transparenzgründen vollständige Abschnitte hinzugefügt
  • Abschnitt IV, Sunshine Conversations: ganzer Abschnitt hinzugefügt, da Sunshine Conversations in der Zendesk Suite Teil der BAA wurde 
  • Abschnitt V, Chat, Nummer 3 (Arbeitsbereich für Agenten): Korrekturen an kleinen Formulierungen
  • Abschnitt VIII, mobile Anwendungen, Nummer 5-7 (Malware-Scanning, Schwärzung, Endbenutzerauthentifizierung): Ganze Abschnitte aus Transparenzgründen hinzugefügt

24. Februar 2023

  • Abschnitt I. Support, Nummer 3: Separate Unterscheidung zwischen Support und Chat-IP-Beschränkungen entfernt, da die Benutzeroberfläche jetzt einheitlich ist.
  • Abschnitt I. Support, Nummer 5: Klarstellung zur Nichterfüllung der Anforderung hinzugefügt 
  • Abschnitt I. Support, Nummer 7: „Abonnent darf nicht“ wurde in „Abonnent darf nicht“ geändert.
  • Abschnitt IV. Chat, Nummer 2: stellt klar, dass der Export von Daten aus Chat per E-Mail verboten ist und nicht nur auf Protokolle und Piping beschränkt ist. 
  • Abschnitt III. Messaging: Der gesamte Abschnitt wurde zum Zendesk Messaging-Funktionsumfang hinzugefügt, der zum Geltungsbereich der Geschäftspartnervereinbarung von Zendesk hinzugefügt wurde.

9. Juli 2021

  • Fügt unter Chat Abschnitt 3. für die Zuständigkeiten im Zusammenhang mit der Nutzung des Arbeitsbereichs für Agenten hinzu.

21. Januar 2021

  • Durch Hinzufügung von Ziffer 1.11 ist CSAT nicht zulässig, es sei denn, der Abonnent übernimmt die Verantwortung für die im Rahmen der Umfrage per E-Mail gesendeten Daten. 
  • Bedenken Sie, dass Abonnenten die Anzeigeberechtigungen ändern können, da Benutzer bereits die Berechtigung zum Zugriff auf diese Daten besitzen.
  • Das gesamte Dokument wurde aktualisiert, damit eingebettete Links im Text anstelle von Inline-URLs dem Stil des Unternehmens entsprechen (keine Auswirkung auf Konfigurationsinhalte). 

August 2020

  • Hinzufügen von Explore Enterprise zum Teilen von Dashboards
  • Aufhebung der Sperre von Chat-Anhängen (Authentifizierungsanforderungen für Support jetzt verfügbar)
  • Klarstellung, dass das ePHI-Verbot in angepassten Feldern speziell für die Insights-Nutzung gilt und nicht global
  • Hinzufügen eines neuen Abschnitts mit Add-ons für bereitgestellte Dienste, wobei „Nebenkonversationen“ die erste Ergänzung ist
  • Diverse Grammatik-/Formatierungsänderungen (inhaltlich irrelevant)

13. Juli 2020:

  • Begriffsklärung bezüglich der Nutzung von SMS über den Dienst im Gegensatz zur nativen Verwendung von SMS für produktinterne 2FA. * Um Zweifel zu vermeiden, gelten die in Abschnitt 10 bezüglich SMS in Bezug auf ePHI genannten Dateneinschränkungen nicht für die produktinterne 2FA-Nutzung (wie in Abschnitt 1.a beschrieben), da diese Funktionalität lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.“

13. Dezember 2019

  • lässt den Verzicht auf IP-Beschränkungen für Agenten zu, wenn der Anwendungsfall solche Beschränkungen nicht zulässt, solange MFA für den Agentenzugriff durchgesetzt wird.

17. Dezember 2019

  • lässt Endbenutzerkommentare in Guide zu, solange Agenten solche Kommentare moderieren und alle PHI entfernen.

6. November 2019

  • Beitrag aktualisiert, um der Änderung Rechnung zu tragen, die Abonnenten nach eigenem Ermessen wählen können, um auf eine bestimmte Konfiguration zu verzichten oder sie zu ersetzen, solange sie die Verantwortung für diese Entscheidung übernehmen.

„Wenn der Abonnent eine der unten aufgeführten Konfigurationen oder eine Reihe der unten aufgeführten erforderlichen Konfigurationen nicht implementiert und erfüllt, ist Folgendes zu beklagen:

Das Risiko des Abonnenten liegt auf dessen eigenes Risiko und liegt im alleinigen Ermessen des Abonnenten; ein solcher Fehler entbindet Zendesk und seine Mitarbeiter, Agenten und verbundenen Unternehmen von jeglicher Verantwortung für den unbefugten Zugriff auf oder die missbräuchliche Verwendung oder Offenlegung von Servicedaten des Abonnenten, einschließlich aller elektronischen geschützten Gesundheitsinformationen, die aus einem solchen Fehler des Abonnenten resultieren. „

  • Weitere Änderungen:
    • 1. die Möglichkeit, SMS zu verwenden, solange der Abonnent die gesamte Verantwortung dafür übernimmt, sicherzustellen, dass bei solchen Übertragungen keine PHI vorhanden ist.
    • 2. Die Möglichkeit, Anhänge in Chat zu verwenden, solange der Abonnent die gesamte Verantwortung dafür übernimmt, dass in diesen Anhängen keine PHI vorhanden ist.

6. März 2019

  • Einstellungen für Zendesk Explore hinzugefügt

17. Januar 2019

  •  aktualisiert, damit Anhänge in Chat nicht mehr zulässig sind.

Hinweis zur Übersetzung: Dieser Beitrag wurde mit automatischer Übersetzungssoftware übersetzt, um dem Leser ein grundlegendes Verständnis des Inhalts zu vermitteln. Trotz angemessener Bemühungen, eine akkurate Übersetzung bereitzustellen, kann Zendesk keine Garantie für die Genauigkeit übernehmen.

Sollten in Bezug auf die Genauigkeit der Informationen im übersetzten Beitrag Fragen auftreten, beziehen Sie sich bitte auf die englische Version des Beitrags, die als offizielle Version gilt.

Powered by Zendesk