HIPAA -fähige Konten:

Alle in diesem Dokument verwendeten Begriffe haben die in der Partnervereinbarung von Zendesk festgelegte Bedeutung. 

Zendesk und der Abonnent haben ein Business Associate Agreement (Geschäftspartnervereinbarung) abgeschlossen, nach dem der Abonnent verpflichtet ist, die folgenden Konfigurationen oder Alternativen, die nach seiner Einschätzung im Hinblick auf seinen Anwendungsfall für alle HIPAA -fähigen Konten als im Wesentlichen gleichwertig eingeschätzt wurden, zu prüfen und zu implementieren Konto/Konten zu aktualisieren, bevor geschützte Gesundheitsinformationen (PHI) in die Dienste eingeführt werden. 

Wenn der Abonnent nach alleinigem Ermessen beschließt, auf die Implementierung einer der unten aufgeführten empfohlenen Konfigurationen zu verzichten, übernimmt er die alleinige Verantwortung für den daraus resultierenden unbefugten Zugriff auf oder unangemessene Verwendung oder Offenlegung seiner Servicedaten, einschließlich geschützter Gesundheitsinformationen von den vom Abonnenten empfohlenen Konfigurationen ausgeschlossen werden.

Der Abonnent muss Servicepläne auf der entsprechenden Stufe gekauft haben und über die erforderlichen Add-ons verfügen (bitte wenden Sie sich an Ihren Kundenberater, wenn Sie nicht sicher sind).

I Die folgenden Mindest-Sicherheitskonfigurationen für Zendesk Support müssen in der BAA für jedes HIPAA -fähige Konto bestätigt werden:

  1. Sichere Agentenauthentifizierung mit einer der beiden folgenden Methoden:
    1. Verwenden von nativem Zendesk Support mit Kennworteinstellungen: (i) auf „Hoch“ gesetzt; oder (ii) vom Abonnenten in einer Weise angepasst werden, die Anforderungen festlegt, die nicht weniger sicher sind als die unter der Einstellung „Hoch” festgelegten Anforderungen. Darüber hinaus muss der Abonnent unter der Option in diesem Unterabschnitt die Zwei-Faktor-Authentifizierung („2FA“) nativ im Dienst aktivieren und durchsetzen. und dass administrative Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, deaktiviert werden; oder
    2. Verwenden einer externen Single-Sign-On (SSO)-Lösung, deren Anforderungen nicht weniger sicher sind als die der Zendesk-Kennworteinstellung „Hoch“, und Aktivieren und Durchsetzen der Zwei-Faktor-Authentifizierung in der gewählten Lösung für den Zugriff aller Agenten. Die administrativen Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, müssen deaktiviert sein.
    3. Bei allen Authentifizierungsoptionen mit SSO als Authentifizierungsmethode muss der Kennwortzugriff deaktiviert werden.
  2. Die SSL-Verschlüsselung (Secure Socket Layer) muss in HIPAA -fähigen Konten immer aktiviert bleiben. HIPAA -fähige Konten, die eine andere Domäne als zendesk.com verwenden, müssen gehostetes SSL einrichten und pflegen.
  3. Der Agentenzugriff muss auf bestimmte IP-Adressen beschränkt werden, die unter der Kontrolle des Abonnenten stehen 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 Abonnentenumgebung in Verbindung mit Enterprise-SSO).  Zur Klarstellung: „Agentenzugriff“ bezieht sich auf den Zugriff, der einem menschlichen Agenten gewährt wird, der über die Benutzerschnittstelle („UI“) auf Dienstdaten zugreift.
  4. Soweit das HIPAA -fähige Konto des Abonnenten den Aufruf von Zendesk-Anwendungsprogrammierschnittstellen („APIs“) ermöglicht, übernimmt der Abonnent die volle Verantwortung für das Verständnis der Sicherheitsauswirkungen aller Abonnenten oder Dritten, die Daten erstellen, aufrufen, ändern oder löschen dürfen Servicedaten und personenbezogene Gesundheitsinformationen über diesen Zugriff und/oder Integrationen. Für den Zugriff auf die genannten APIs bietet Zendesk verschiedene Methoden an, diehier beschrieben werden. Der Abonnent ist verpflichtet, die folgenden bewährten Sicherheitspraktiken basierend auf dem verwendeten API-Modell zu implementieren:
    1. OAuth 2.0-Ansatz verwenden.  Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt aber voraus, dass die Zugriffsberechtigungen von einem Endbenutzer akzeptiert werden.  Der Abonnent wird nach Möglichkeit den Ansatz und das Authentifizierungsschema von OAuth 2.0 verwenden. Der Abonnent gibt jedem OAuth-Client einen aussagekräftigen und eindeutigen Clientnamen sowie eine eindeutige Kennung. Die für jedes OAuth-Token gewährten Berechtigungen sollten die geringsten Berechtigungen zulassen, die zur Erfüllung der erforderlichen Aufgaben erforderlich sind.
    2. REST-API-Token-Ansatz verwendet.  Dieses Modell ist am breitesten und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen. Sie bietet den umfassendsten Zugriff und die umfassendsten Funktionen und sollte mit Bedacht eingesetzt werden. Bei Verwendung dieses Ansatzes wird der Abonnent (i) für jeden Dienst ein eindeutiges Token verwenden und dem Token einen aussagekräftigen Namen geben, der die Funktion bestimmt; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) erkennen an, dass das zugehörige Token sofort rotiert, 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 Abonnentenrotieren.  
    3. Nach Möglichkeit muss der Abonnent den Zugriff auf die API per Kennwort deaktivieren, da Anmeldedaten des Benutzers bei jeder Anfrage mitgesendet werden, wodurch der Benutzer freigeschaltet wird und leicht für böswillige Parteien abgefangen werden kann.  
  5. Der Abonnent muss „Authentifizierung erforderlich, um Dateien herunterzuladen“ aktivieren, damit der Zugriff auf Anhänge authentifiziert werden kann. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und Zugriff auf solche Anhangsdaten.
  6. Der Abonnent muss auf allen Endpunkten, auf die Agenten, Administratoren und Kontoinhaber zugreifen, systematisch einen kennwortgeschützten Bildschirmschoner oder Startbildschirm einrichten, der nach maximal fünfzehn (15) Minuten Inaktivität aktiviert wird.
  7. Der Abonnent sollte die Anzeigeberechtigungen, die es einem Benutzer ermöglichen, Aktualisierungen für eine gesamte Instanz/Marke/Organisation anzuzeigen, oder die Standardeinstellung, die einen Zugriff über die eigenen Tickets hinaus ermöglicht, nicht ändern (es sei denn, der Abonnent übernimmt die gesamte Verantwortung dafür, sicherzustellen, dass diese Benutzer vom Abonnenten die Genehmigung zum Zugriff auf alle erhalten haben.) nachfolgende Daten). Der Abonnent erkennt an, dass die Berechtigungen für Endbenutzerorganisationen im Benutzerprofil und in der Organisation selbst festgelegt werden können und dass die freizügigere Einstellung hat 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 Dienstdaten vor dem Eingang in seiner Zendesk Support -Instanz zu schützen. Hierzu gehören alle personenbezogenen Gesundheitsinformationen, die per E-Mail über Antworten auf Zendesk Support Tickets weitergegeben werden, einschließlich Ticketkommentare oder Anhänge.
  9. Der Abonnent erkennt an, dass Zendesk Support unter verschiedenen Umständen eine E-Mail an einen Endbenutzer sendet, z. B. wenn ein Agent des Abonnenten über den E-Mail-Kanal auf ein Zendesk Support Ticket antwortet oder dies durch eine Automatisierung oder einen Auslöser ausgelöst wird. Standardmäßig enthält diese E-Mail die neuesten Tickets oder andere Informationen, die für eine automatische Benachrichtigung konfiguriert sind, darunter auch personenbezogene Informationen. Um den Abonnenten noch besser zu schützen, sollte seine Zendesk Support Instanz sein die so konfiguriert sind, dass der Endbenutzer nur benachrichtigt wird, dass ein Agent geantwortet hat, und dass der Endbenutzer sich bei Zendesk Support authentifizieren muss, um den Inhalt der Nachricht zu sehen.
  10. Der Abonnent erkennt an, dass alle nach eigenem Ermessen in einem beliebigen Zendesk-Dienst eingesetzten SMS-Funktionen auf SMS und/oder verwandten Protokollen basieren, die die unverschlüsselte Übertragung von Nachrichten zwischen und in die jeweiligen Dienste ermöglichen.  SMS-Funktionen sollten daher entweder:
    1. darf nicht in einem HIPAA -fähigen Konto* verwendet werden oder
    2. der Abonnent übernimmt die gesamte Verantwortung für die Nutzung dieser Funktionen
  11. Der Abonnent erkennt an, dass bei Nutzung der Legacy-Funktionalität Umfragen zur Kundenzufriedenheit („Legacy CSAT“) des Dienstes Servicedaten (die personenbezogene Gesundheitsinformationen enthalten können), die mit dem Support Ticket verknüpft sind, per E-Mail gesendet werden, um die Bewertung des Benutzers zu erhalten, deren Verschlüsselungsstatus nicht gesteuert wird von Zendesk entwickelt wurde. Daher sollte die Legacy-CSAT-Funktion entweder:
    1. darf nicht in einem HIPAA -fähigen Konto* verwendet werden oder
    2. der Abonnent übernimmt die gesamte Verantwortung für die Nutzung dieser Funktionen
  12. Der Abonnent erkennt an, dass er die Kundenzufriedenheitsumfragen („CSAT“) des Dienstes genutzt hat für den Ticketkanal konfiguriert ist, 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 wird nicht von Zendesk gesteuert. Darüber hinaus hat jeder mit der entsprechenden Kundenzufriedenheits-URL Zugriff auf die Antworten auf das jeweilige Ticket. Daher sollten Sie die CSAT-Funktionalität für den Ticketkanal verwenden
    1. Konfigurieren Sie den E-Mail-Text der CSAT-Automatisierung so, dass potenzielle ePHI nicht enthalten sind, und verwenden Sie die {{satisfaction.survey_url}} exklusiv für den -Platzhalter
    2. Verwenden Sie nicht die Funktion „Offene Fragen“.

* Zur Klarstellung: Die in Abschnitt 10 zu SMS genannten Vorbehalte zu ePHI gelten nicht für die produktintegrierte Nutzung der 2FA (siehe Abschnitt 1.a), da diese Funktion lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.

II. Die folgenden Mindest-Sicherheitskonfigurationen für die Zendesk Guide und Gather-Services müssen eingerichtet und in der BAA für jedes HIPAA -fähige Konto bestätigt werden:

  1. Der Abonnent erkennt an, dass die Guide- und Gather-Dienste öffentlich sind (sofern keine beschränkten Beiträge genutzt oder eine geschlossene oder beschränkte Instanzverwendet werden) und der Abonnent daher sicherstellen muss, dass Beiträge in Zendesk Guide oder Gather nicht personenbezogene Gesundheitsinformationen enthalten, auch nicht im Text von im Beitrag, als Anhang oder als Bild im Beitrag erscheinen.
  2. Der Abonnent muss entweder die Möglichkeit für Endbenutzer deaktivieren, Kommentare in Zendesk Guide hinzuzufügen , oder personenbezogene Gesundheitsinformationen aus allen Kommentaren entfernen (wie in Abschnitt 3 unten beschrieben).
  3. Wenn der Zendesk Guide -Dienst Guide Professional oder Enterprise ist, sollten Abonnenten die Möglichkeit, neue Posts zu erstellen, deaktivieren, indem sie die Gather-Funktionen mit Zendesk Guide deaktivieren bzw. Gather-Funktionen deaktivieren, weil die Absicht des Abonnenten besteht Anwendungsfall müssen Abonnenten die Inhaltsmoderation im Zendesk Guide -Dienst aktivieren und die Einstellung „Alle Inhalte moderieren“. Eingaben mit personenbezogenen Gesundheitsinformationen werden nicht genehmigt.
  4. Die Verwendung von Community-Moderatoren, die keine Mitarbeiter sind, ist im Gather-Dienst nicht gestattet.
  5. Der Abonnent erkennt an, dass „@Erwähnungen" von Gather-Community-Mitgliedern möglich sind, sofern Endbenutzer über öffentliche Profile verfügen; sollte diese Funktion in ihrem Anwendungsfall als Risiko eingestuft werden, müssen öffentliche Profile deaktiviert bzw. @Erwähnungen deaktiviert werden.

III. Die folgenden Mindest-Sicherheitskonfigurationen für die Nutzung von Zendesk Messaging müssen eingerichtet und in der Zendesk BAA für jedes HIPAA -fähige Konto bestätigt werden:

  1. Der Abonnent darf die Social-Media-Messaging-Kanalintegrationen nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, entweder (i) sicherzustellen, dass keine ePHI in Social-Media-Nachrichten enthalten sind, oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abzuschließen.
  2. Der Abonnent deaktiviert die Fähigkeit der Endbenutzer, Dateien an Messaging-Konversationen anzuhängen, und übernimmt die volle Verantwortung dafür, entweder (i) sichere Anhänge zu aktivieren oder (ii) die Sicherstellung, dass Agenten keine Dateien mit ePHI an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen.  In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und den Zugriff auf solche URLs und/oder Anhangsdaten.
  3. Der Abonnent trägt die gesamte Verantwortung dafür, dass alle Agenten und Light Agents alle eingehenden Nachrichten von allen Endbenutzern sehen können.
  4. Wenn der Abonnent oder seine Agenten auf Integrationen (z. B. als Teil eines für den Answer Bot erstellten Workflows) für APIs und Webhooks zugreifen oder diese entwickeln oder das Messaging-Erlebnis anpassen, übernimmt der Abonnent die volle Verantwortung, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows zu verstehen Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter), die über diesen Zugriff und/oder diese Integrationen Servicedaten und ePHI erstellen, aufrufen, ändern oder löschen dürfen.
  5. Wenn der Abonnent einem Agenten die Berechtigung zur Teilnahme an einer Messaging-Konversation entziehen möchte, während die Messaging-Konversation aktiv ist, übernimmt er die gesamte Verantwortung für die Kündigung des Zugriffs des Agenten auf Zendesk.
  6. Standardmäßig werden Web-Widget-Konversationen mit Endbenutzern dauerhaft vorgenommen und können von Endbenutzern angezeigt werden, wenn sie vom selben Gerät zum Web-Chat zurückkehren. Der Abonnent ist verpflichtet, diese Funktion entweder zu deaktivieren oder dafür zu sorgen, dass Endbenutzer keine Geräte teilen.
  7. Wenn der Abonnent eine Authentifizierung für Endbenutzer implementieren möchte, trägt er die gesamte Verantwortung dafür, dass dies auf sichere Weise im Einklang mit Best Practices und Industriestandards implementiert wird.
    1. Bei Verwendung dieses Ansatzes wird der Abonnent (i) einen eindeutigen JWT-Signaturschlüssel für jeden Authentifizierungskanal verwenden und dem Token eine aussagekräftige Namensfunktion geben; (ii) Sie geben JWT-Signaturschlüssel nicht an Dritte weiter, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) erkennen an, dass der Abonnent den zugehörigen JWT-Signaturschlüssel sofort rotieren wird, wenn der JWT-Signaturschlüssel an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) der JWT-Signaturschlüssel zumindest häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten rotiert wird.
    2. Der Abonnent muss das JWT-Ablaufattribut verwenden und seinen Wert auf maximal 15 Minuten setzen.
  8. Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und Answer Bot, die nicht von einem menschlichen Agenten übergeben und in ein Ticket umgewandelt werden, weiterhin im System gespeichert sind und dass es in der Verantwortung des Abonnenten liegt, diese Interaktionen entsprechend seinen Verpflichtungen zu löschen (z. B. durch Implementieren eines Webhooks). die den Abonnenten benachrichtigt, wenn diese Konversationen gespeichert werden, und (automatisch) die Löschung über die Sunshine Conversations -API auslöst. 
  9. Der Abonnent erkennt an, dass die Konversationen zwischen Endbenutzern und dem Answer Bot umgewandeltwurden in ein Ticket umgewandelt wurde, kann derzeit nicht geschwärzt werden. Zum Löschen wird das Ticket gelöscht. 
  10. Der Abonnent erkennt an, dass Endbenutzeranhänge in Messaging-Kanälen in Zendesk derzeit nicht auf Malware gescannt werden. Der Abonnent trägt die volle Verantwortung für die Einrichtung von Verfahren und Richtlinien zur Risikominderung für seine Vermögenswerte. 

IV. Die folgenden Mindest-Sicherheitskonfigurationen für die Nutzung von Zendesk Sunshine Conversations (in Verwendung mit der Zendesk Suite) sind in der Zendesk BAA für jedes HIPAA -fähige Konto bestätigt:

  1. Der Abonnent darf die Integration externer Kanäle nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, dass entweder (i) keine ePHI in den Nachrichten von Drittanbieter-Kanälen enthalten sind oder (ii) eine eigene BAA mit integrierten Messaging-Plattformen abgeschlossen wird.
  2. Der Abonnent übernimmt die gesamte Verantwortung für das Verständnis der Sicherheitsauswirkungen aller Abonnenten oder Dritten, die über die Sunshine Conversations APIs Dienstdaten und personenbezogene Gesundheitsinformationen erstellen, abrufen, modifizieren oder löschen dürfen. Für den Zugriff auf die genannten APIs muss der Abonnent die folgenden bewährten Sicherheitspraktiken auf Grundlage des verwendeten API-Modells implementieren:
    1. OAuth 2.0-Ansatz verwenden.  Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt aber voraus, dass die Zugriffsberechtigungen von einem Endbenutzer akzeptiert werden.  Wann immer möglich, wird der Abonnent nutzen Der OAuth 2.0-Ansatz und das Authentifizierungsschema. Der Abonnent gibt jedem OAuth-Client einen aussagekräftigen und eindeutigen Clientnamen sowie eine eindeutige Kennung. 
    2. REST-API-Token-Ansatz verwendet.  Dieses Modell ist am breitesten und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen.  Sie bietet den umfassendsten Zugriff und die umfassendsten Funktionen und sollte mit Bedacht eingesetzt werden. Bei Verwendung dieses Ansatzes wird der Abonnent (i) für jeden Dienst ein eindeutiges Token verwenden und dem Token einen aussagekräftigen Namen geben, der die Funktion bestimmt; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) erkennen an, dass das zugehörige Token sofort rotiert, 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 gemäß der Organisationsrichtlinie des Abonnenten häufig rotiert.  
    3. Wenn der Abonnent oder seine Agenten auf Integrationen für APIs und Webhooks zugreifen oder diese entwickeln oder das Sunshine Conversations -Erlebnis anpassen, übernimmt der Abonnent die volle Verantwortung, die Datenschutz- und Sicherheitsauswirkungen aller angepassten Workflows und aller zulässigen Abonnenten oder Drittanbieter (einschließlich Chatbot-Anbieter) zu verstehen über solche Zugriffe und/oder Integrationen Servicedaten und ePHI zu erstellen, aufzurufen, zu modifizieren oder zu löschen.
  3. Der Abonnent erkennt an, dass die für Zendesk Support konfigurierten IP-Beschränkungen nicht auch für die Sunshine Conversations -API gelten. Die Abonnenten tragen die volle Verantwortung für die Beschränkung des Zugriffs auf die Sunshine Conversations -API und die API-Token wie unter 2.b beschrieben. und im Einklang mit den Richtlinien des Abonnenten steht. 
  4. Der Abonnent deaktiviert die Möglichkeit für Endbenutzer, Dateien an Sunshine Conversations -Konversationen anzuhängen, und übernimmt die volle Verantwortung für die Aktivierung sicherer Anhänge und auch sicherzustellen, dass Agenten keine Dateien mit ePHI an Messaging-Konversationen anhängen. Andernfalls kann jeder, der Zugriff auf die richtige URL des Anhangs hat, auf den uneingeschränkten Anhang zugreifen. In solchen Fällen übernimmt der Abonnent die gesamte Verantwortung für den Inhalt und Zugriff auf solche Anhangsdaten.
  5. Wenn der Abonnent eine Authentifizierung für Endbenutzer implementieren möchte, trägt er die gesamte Verantwortung dafür, dass dies entsprechend den Best Practices zur Sicherheit und den Industriestandards erfolgt.
    1. Bei Verwendung dieses Ansatzes wird der Abonnent (i) einen eindeutigen JWT-Signaturschlüssel für jeden Authentifizierungskanal verwenden und dem Token eine aussagekräftige Namensfunktion geben; (ii) Sie geben JWT-Signaturschlüssel nicht an Dritte weiter, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) erkennen an, dass der Abonnent den zugehörigen JWT-Signaturschlüssel sofort rotieren wird, wenn der JWT-Signaturschlüssel an einen Dritten weitergegeben wird und der Abonnent auf eine Datenschutzverletzung durch einen Dritten aufmerksam gemacht wird; und (iv) der JWT-Signaturschlüssel zumindest häufig in Übereinstimmung mit den Organisationsrichtlinien des Abonnenten rotiert wird.
    2. Der Abonnent muss das JWT-Ablaufattribut verwenden und seinen Wert auf maximal 15 Minuten setzen.
  6. Der Abonnent erkennt an, dass Interaktionen zwischen Endbenutzern und Answer Bot, die nicht von einem menschlichen Agenten übergeben und in ein Ticket umgewandelt werden, weiterhin im System gespeichert sind und dass es in der Verantwortung des Abonnenten liegt, diese Interaktionen entsprechend seinen Verpflichtungen zu löschen, z. B. durch Implementierung eines Webhooks benachrichtigt den Abonnenten, wenn diese Konversationen gespeichert werden, und löst (automatisch) die Löschung über die Sunshine Conversations -API aus 
  7. Der Abonnent erkennt an, dass Konversationen zwischen Endbenutzern und dem Answer Bot, die in Tickets umgewandelt wurden, derzeit nicht geschwärzt werden können. Zum Löschen wird das Ticket gelöscht. 
  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. Sie können hierzu das Ticket selbst löschen oder die Funktion „Schwärzung“ verwenden (Einschränkungen: siehe Abschnitt 7.). 
  9. Der Abonnent erkennt an, dass derzeit nicht alle Anhänge in Sunshine Conversation-Kanälen in Zendesk auf Malware gescannt werden. Der Abonnent übernimmt die volle Verantwortung für die Einrichtung von Verfahren und Richtlinien zur Risikominderung für seine Mitarbeiter. 

V. Die folgenden Mindest-Sicherheitskonfigurationen für den Zendesk Chat -Service müssen eingerichtet und in der BAA für jedes HIPAA -fähige Konto bestätigt werden:

  1. Der Abonnent ist verpflichtet, den Zugriff von Bearbeitern auf den Zendesk Chat -Dienst durch Verknüpfung mit dem Zendesk Support-Dienst und Authentifizierung über den Zendesk Support -Dienst einzuschränken.
  2. Der Abonnent ist nicht berechtigt, keine Chatprotokolle per E-Mail zu senden , (a) das E-Mail-Piping zu deaktivieren, (b) die Option Chatprotokoll per E-Mail senden im Web Widget zu deaktivieren und (c) keine Exporte per E-Mail vom Chat-Dashboard aus zu teilen
  3. Der Abonnent darf den „Arbeitsbereich für Agenten“ nur dann aktivieren, wenn er die volle Verantwortung dafür übernimmt, dass (i) in Chats keine ePHI-Daten vorhanden sind und/oder (ii) alle Agenten die entsprechende Zugriffsberechtigung erhalten.

VI. Die folgenden Mindest-Sicherheitskonfigurationen für die Nutzung des Zendesk Explore -Dienstes müssen in der BAA für jedes HIPAA -fähige Konto bestätigt werden:

Der Abonnent erkennt an, dass in Explore über Benutzernamen, Tickettitel, Feld- und Formularoptionen und Inhalte von Freitextfeldern ePHI angezeigt werden können.

  1. Für alle internen Dienstinstanzen, die personenbezogene Gesundheitsinformationen enthalten, muss der Abonnent (i) nur solchen Agenten Zugriff auf die Explore-Oberfläche gewähren, die auf alle Tickets/Anrufe/Chats zugreifen können, die in der übergeordneten Dienstinstanz/den übergeordneten Diensten personenbezogene Gesundheitsinformationen enthalten können, und (ii) gewähren diesen Zugriff unter Berücksichtigung der Mindestanzahl von Berechtigungen, die für die Nutzung von Explore in ihrer Umgebung erforderlich sind. Weitere Informationen zum Konfigurieren von Zugriffsebenen in Explore finden Sie hier.
  2. Bei Nutzung der Exportfunktion (i) erkennt der Abonnent an, dass personenbezogene Gesundheitsinformationen an ein Gerät übertragen werden können, dem der Abonnent Zugriff auf die Agentenoberfläche gewährt hat und dass alle damit verbundenen Steuerungen auf diesem Gerät in der Verantwortung des Abonnenten liegen, und (ii) hat er die Verwendung zu verweigern Exportfunktionen per E-Mail für die exportierten Berichte nutzen, es sei denn, sie sind dafür verantwortlich, entweder (a) sicherzustellen, dass in diesen Exporten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (b) dass die für solche Übertragungen verwendeten E-Mail-Dienste die Verschlüsselung über das zulässige Mindestprotokoll unterstützen der bis dato aktuellen PCI-Standards entspricht.

* Besondere Überlegungen bei Verwendung von Explore Enterprise:

Der Abonnent erkennt an, dass bei Nutzung des Explore Enterprise-Dienstes möglicherweise mehr Funktionen für die gemeinsame Nutzung von Daten und zum Export bereitgestellt werden können. Der Abonnent muss:

  1. entweder (i) sicherstellen, dass keine ePHI in diesen Dashboards vorhanden sind, und/oder (ii) Dashboards nur mit Agenten, Gruppen, Listen oder Endbenutzern teilen, die zum Anzeigen und Empfangen dieser Daten berechtigt sind.
  2. IP-Beschränkungen nutzen
  3. beim Teilen von Dashboards über einen einheitlichen Ressourcen-Locator (URL) anerkennt der Abonnent, dass die Daten nicht mit einzelnen Benutzer- oder Gruppenbenutzerkonten geteilt werden, sondern über einen Zugriffslink. Der Abonnent muss daher (i) den Kennwortschutz aktivieren, (ii) sicherstellen, dass die Komplexität, Rotation, Speicherung und Verteilung der gewählten Kennwörter an die empfangende Partei im Einklang mit den Kennwortrichtlinien des Abonnenten zum Schutz der in solchen Dashboards enthaltenen Daten erfolgt, und (ieren) die Dokumente rotiert und zwar ohne unangemessene Verzögerung bei Verdacht oder Bestätigung der Offenlegung

VII. Produktintegrierte Funktionen für bereitgestellte verknüpfte Dienste („Add-ons“):

  1. Collaboration Deployed Associated Service: „Nebenkonversationen“. Der Abonnent erkennt an, dass bei Nutzung der Funktionalität „Nebenkonversationen“ untergeordnete Ticket- und/oder Nebenkonversationsnachrichten in der Support -Instanz des Abonnenten erstellt oder von dort aus per Ticket, E-Mail, Slack oder Integrationen (nach Ermessen des Agenten) an Empfänger gesendet werden können (je nach Ermessen des Agenten). . Wenn der Abonnent diese Funktionalität in einem HIPAA -fähigen Konto nutzt, übernimmt er die gesamte Verantwortung (i) dafür, dass in diesen Nachrichten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (ii) falls in diesen Nachrichten personenbezogene Gesundheitsinformationen enthalten sein könnten für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, Zugriff, Verwendung oder Offenlegung von PHI infolge des Nachrichtenaustauschs über die Funktion „Nebenkonversation“.

VIII. Für die Nutzung mobiler Zendesk-Apps (oder den Zugriff per Mobilgerät wie Smartphone oder Tablet) müssen die folgenden Mindest-Sicherheitskonfigurationen eingerichtet und in der BAA von Zendesk für HIPAA -fähige Konten bestätigt werden:

  1. Die Nutzung umfasst die Verschlüsselung auf Geräteebene
  2. Biometrische Daten oder ein PIN-Zugriff auf die höchste zulässige Geräteeinstellung sind erforderlich
  3. Benachrichtigungen, die es ermöglichen, dass Ticketkommentare auf den Sperrbildschirmen solcher Geräte angezeigt werden, müssen deaktiviert werden
  4. Die Bildschirmsperre für inaktive Inhalte muss aktiviert und so konfiguriert sein, dass sie bei Inaktivität von maximal 15 Minuten gesperrt wird.
  5. Der Abonnent erkennt an, dass die mobile Zendesk Support App nicht anzeigt, ob Anhänge gescannt und als Malware erkannt wurden. Agenten müssen sich zum Anzeigen dieser Informationen über den Browser anmelden. Der Abonnent trägt die volle Verantwortung dafür, dass über Verfahren und Richtlinien zur Minderung möglicher Risiken verfügt wird.
  6. Der Abonnent erkennt an, dass die Schwärzungsfunktion in der mobilen Support App nicht verfügbar ist und dass sich Agenten über den Browser anmelden müssen, um die Schwärzungsfunktion zu nutzen.
  7. Wenn der Abonnent die Authentifizierung von Endbenutzern für Zendesk Messaging wählt, erkennt er an, dass der Authentifizierungsstatus eines Endbenutzers in der mobilen Support -App nicht angezeigt wird.

IX. Für Abonnenten, die die BAA von Zendesk unterzeichnet haben und anschließend den Zendesk Insights Service genutzt haben, wird dieser Service am 5. Februar 2021 eingestellt.   

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

  1. Der Abonnent erkennt an, dass die KI-Funktionen von Zendesk zur Steigerung der Produktivität des bzw. der Zendesk-Dienste(s) bestimmt sind und nicht auf eine Weise verwendet werden sollten, die als (i) Bereitstellung von medizinischem Rat, (ii) Bereitstellung einer Diagnose des Zustands oder der Symptome zu entwickeln, (ii) eine Behandlung zu verschreiben oder (iv) den Nutzer in irgendeiner Weise daran zu hindern, einen Rat, eine Diagnose oder eine Behandlung eines Gesundheitsexperten in Anspruch zu nehmen, (v) einem Nutzer anderweitig Informationen bereitzustellen oder Entscheidungen zu treffen, um ihn einzuschränken oder auszuschließen Gesundheitspläne, Behandlungsprogramme, Testdienste oder andere Gesundheitsleistungen, die sich auf die Inanspruchnahme oder Inanspruchnahme von Gesundheitsdiensten auswirken könnten (es sei denn, der Abonnent übernimmt die volle Verantwortung für diese Entscheidung basierend auf seinem konkreten Anwendungsfall und seinen Interaktionen mit seinen Benutzern). sowie die potenziellen Auswirkungen eines solchen Einsatzes von KI.)
  2. Der Abonnent erkennt an, dass bei Verwendung von OpenAI-gestützten generativen KI-Funktionen die OpenAI -Ausgaben nicht von Menschen sondern von Computern generiert werden und deshalb zu ungenauen Ergebnissen führen können. Zendesk übernimmt keine Garantie für die Genauigkeit dieser Ergebnisse.
  3. Der Abonnent erkennt an, dass die Funktion „Variationen generieren“ nicht aktiviert werden darf, wenn ein Zendesk-Bot-Gruß verwendet wird, um den Endbenutzern des Abonnenten einen erforderlichen Haftungsausschluss zu übermitteln. 
  4. Der Abonnent erkennt an, dass durch Aktivierung der Funktion „Generative KI für Agenten/Generative KI für die Wissensdatenbank“ im Admin Center diese Funktion für alle Agenten in ihrer Instanz unabhängig von ihren Rollen und Berechtigungen aktiviert wird. 


      

Hinweis: Aufgrund gesetzlicher oder regulatorischer Änderungen oder Änderungen des Zendesk-Service können sich die Sicherheitskonfigurationen in diesem Dokument von Zeit zu Zeit ändern. Dieses Dokument enthält die Empfehlungen von Zendesk für die minimalen Sicherheitskonfigurationen zum Schutz personenbezogener Gesundheitsinformationen in den oben genannten Zendesk-Produkten. Dieses Dokument ist weder als umfassende Vorlage für die Kontrolle dieser Daten noch als Rechtsberatung gedacht. Jeder Zendesk-Abonnent sollte bezüglich der HIPAA -Compliance-Anforderungen einen eigenen Rechtsberater hinzuziehen und zusätzliche Änderungen an seinen Sicherheitskonfigurationen im Einklang mit der eigenen unabhängigen Analyse vornehmen, solange diese Änderungen die Sicherheit der Konfigurationen nicht beeinträchtigen oder beeinträchtigen die in diesem Dokument beschrieben werden.

 

Änderungsprotokoll HIPAA -fähige Konten:

 

10. Oktober 2024

  • Abschnitt I, Support, Nummer 12 (Kundenzufriedenheit) wurde hinzugefügt und Abschnitt I, Support, Nummer 11 (Legacy-Kundenzufriedenheit) bearbeitet, um neue Funktionen zu berücksichtigen. 

7. März 2024

  • Abschnitt X, „Hinweis zur KI-Funktionalität“ von Zendesk, wurde hinzugefügt
  • Abschnitt I, Support, Nummer 7 (Anzeigeberechtigungen):
    • Klarstellung, dass sich „Anzeigeberechtigungen“ auf die gesamte Instanz/Marke/Organisation und nicht nur auf die gesamte Organisation beziehen.
    • Neue Bestimmung für das Verhalten Endbenutzer-spezifischer Organisationen hinzugefügt. 
  • Abschnitt I, Support, Nummer 9 (E-Mail):  
    • Die Fälle, in denen Zendesk Support eine E-Mail an einen Endbenutzer sendet, haben jetzt auch Antworten über den E-Mail-Kanal oder solche, die durch eine Automatisierung oder einen Auslöser ausgelöst werden, anstatt nur einen Agenten, der auf ein Ticket antwortet.
    • Sie haben festgelegt, dass automatische Benachrichtigungen standardmäßig die jüngste Ticketkorrespondenz oder andere konfigurierte Informationen enthalten können, darunter auch personenbezogene Informationen.

 

25. Oktober 2023

  • Einführung: Verfeinerung des Einführungstexts für HIPAA -fähige Konten
  • Abschnitt II, Guide und Gather, Nummer 1 (Help-Center-Beschränkungen): Wir haben die IP-Beschränkungen durch beschränkte Beiträge ersetzt

 

13. April 2023

  • Abschnitt I, Support, Nummer 4 (APIs): 
    • Zur besseren Übersicht wurde ein Link zu den Authentifizierungsmethoden hinzugefügt 
    • b) Empfehlungen für den genauen Zeitrahmen für die Rotation zur Anpassung an branchenspezifische Best Practices entfernt und Verweis auf allgemeine Geschäftsbedingungen für die REST-API (Redundanz)
    • c) hinzugefügt, um vor der Verwendung der Standardauthentifizierung für die API zu warnen 
  • Abschnitt II, Leitfaden:
    • Nummer 1 (Help-Center-Beschränkungen): Verweis auf geschlossene oder beschränkte Help Center hinzugefügt, um an die Produktfunktionen anzugleichen
    • Nummer 5 (@Erwähnungen): Option zum Deaktivieren von @Erwähnungen zur Anpassung an das Produkt hinzugefügt für mehr Funktionalität sorgen 
  • Abschnitt III, Messaging: 
    • Nummer 1 und 2 (Drittanbieterkanäle und private Anhänge): Zur übersichtlicheren Darstellung wurden Abschnittskennungen ( i) und (ii) hinzugefügt
    • Nummer 2 (private Anhänge): „URLs und/oder“ zur Klarstellung hinzugefügt
    • Nummer 7-10 (Endbenutzer-Authentifizierung, Löschung von Answer-Bot-Konversationen, Schwärzung, Malware-Scanning): Aus Gründen der Transparenz wurden vollständige Abschnitte hinzugefügt
  • Abschnitt IV. Sunshine Conversations: ganzer Abschnitt hinzugefügt, da Sunshine Conversations in der Zendesk Suite Teil der BAA wird 
  • Abschnitt V, Chat, Nummer 3 (Arbeitsbereich für Agenten): kleine Formulierungskorrekturen
  • Abschnitt achten, Mobile Anwendungen, Nummer 5-7 (Malware-Scanning, Schwärzung, Endbenutzer-Authentifizierung): ganze Abschnitte aus Transparenzgründen hinzugefügt

24. Februar 2023

  • Abschnitt I. Support, Nummer 3: die separate Unterscheidung zwischen IP-Beschränkungen für Support und Chat wurde entfernt, da die Benutzeroberfläche jetzt vereinheitlicht ist.
  • Abschnitt I. Support, Nummer 5: Klarstellung im Fall der Nichterfüllung der Anforderung hinzugefügt 
  • Abschnitt I. Support, Nummer 7: „Abonnent darf nicht“ geändert in „Abonnent nicht“.
  • Abschnitt IV. Chat, Nummer 2: stellt klar, dass jegliche Exportfunktion von Daten aus Chat per E-Mail verboten ist und sich nicht nur auf Protokolle und Piping beschränkt. 
  • Abschnitt III. Messaging: gesamter Abschnitt hinzugefügt, um die Zendesk Messaging-Funktionalität über den Umfang der Zendesk-Geschäftspartnervereinbarung hinaus zu berücksichtigen.

9. Juli 2021

  • Fügt Punkt 3 im Chat-Abschnitt für Verantwortlichkeiten im Zusammenhang mit der Nutzung des Arbeitsbereichs für Agenten hinzu.

21. Januar 2021

  • Durch Hinzufügen von Nummer 1.11 wird keine Kundenzufriedenheitsumfrage zugelassen, es sei denn, der Abonnent übernimmt die Verantwortung für die Daten, die im Rahmen der Umfrage per E-Mail gesendet werden. 
  • Vorbehalt in Nummer 1.7, um zu berücksichtigen, dass Abonnenten die Anzeigeberechtigungen ändern, weil Benutzer bereits die Genehmigung zum Zugriff auf diese Daten erhalten haben.
  • Gesamtes Dokument aktualisiert, damit es dem Unternehmensstil der eingebetteten Links im Text entspricht (statt Inline-URLs) (keine Auswirkung auf Konfigurationsinhalte).

August 2020

  • Explore Enterprise bietet jetzt zusätzliche Funktionen zum Teilen von Dashboards
  • Aufhebung der Sperre für Chat-Anhänge (Support Authentifizierungsanforderungen jetzt erfüllt)
  • Es ist klar, dass das Verbot von ePHI in angepassten Feldern speziell für die Nutzung von Insights gilt, nicht global
  • Ein neuer Abschnitt über Add-ons für bereitgestellte Dienste wurde hinzugefügt, wobei „Nebenkonversationen“ die erste Wahl ist
  • Verschiedene Grammatik-/Formatierungsänderungen (die sich nicht auf den Inhalt auswirken)

13. Juli 2020:

  • Begriffsklärung bezüglich der Nutzung von SMS über den Dienst im Gegensatz zur nativen Nutzung von SMS für produktintegrierte 2FA. * Zur Klarstellung: Die in Abschnitt 10 zu SMS genannten Vorbehalte zu ePHI gelten nicht für die produktintegrierte Nutzung der 2FA (siehe Abschnitt 1.a), da diese Funktion lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.

13. Dezember 2019 

  • ermöglicht den Verzicht auf Agenten-IP-Beschränkungen, wenn der Anwendungsfall dies nicht zulässt, solange MFA für den Agentenzugriff durchgesetzt wird.

17. Dezember 2019 

  • lässt Kommentare von Endbenutzern in Guide zu, solange Agenten diese Kommentare moderieren und alle PHI-Kommentare entfernen.

6. November 2019

  • Beitrag aktualisiert, um die Änderung widerzuspiegeln, dass Abonnenten nach eigenem Ermessen auf eine bestimmte Konfiguration verzichten oder sie ersetzen können, solange sie die Verantwortung für diese Entscheidung übernehmen.

„Versäumt es ein Abonnent, eine bestimmte unten aufgeführte Konfiguration oder eine Reihe erforderlicher Konfigurationen unten zu implementieren und einzuhalten, ahnden wir als

auf eigenes Risiko und nach alleinigem Ermessen des Abonnenten; und ein solches Versäumnis entbindet Zendesk und seine Mitarbeiter, Agenten und verbundenen Unternehmen von jeglicher Verantwortung im Hinblick auf den unbefugten Zugriff auf oder die unsachgemäße Verwendung oder Offenlegung der Servicedaten des Abonnenten, einschließlich aller elektronischen geschützten Gesundheitsdaten, infolge eines solchen Versäumnisses durch den Abonnenten . "

  • Weitere Änderungen:
    • 1. die Fähigkeit zur Nutzung von SMS, solange der Abonnent selbst dafür verantwortlich ist, sicherzustellen, dass keine personenbezogenen Gesundheitsinformationen in solchen Übertragungen enthalten sind.
    • 2. Die Möglichkeit, Anhänge in Chat zu verwenden, solange der Abonnent die gesamte Verantwortung dafür trägt, dass in diesen Anhängen keine personenbezogenen Gesundheitsinformationen enthalten sind.

6. März 2019 

  • aktualisiert, um Einstellungen für Zendesk Explore

17. Januar 2019

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

 

HDS-fähige Konten:

Alle in diesem Dokument verwendeten Begriffe haben die im Rahmen-Abonnementvertrag von Zendesk vorgegebene Bedeutung für die HDS-Bedingungen („HDS-Bedingungen“).
Zendesk und der Abonnent haben sich mit bestimmten HDS-Geschäftsbedingungen einverstanden erklärt, nach denen der Abonnent die folgenden Konfigurationen für alle HDS-aktivierten Konten implementieren und einhalten muss, bevor er personenbezogene Gesundheitsinformationen (PHI) in die Dienste übermittelt. Alle in diesem Dokument verwendeten Begriffe, die in diesem Dokument verwendet werden, haben die in den HDS-Nutzungsbedingungen festgelegte Bedeutung.
Die Nichtimplementierung einer bestimmten unten aufgeführten Konfiguration oder einer Reihe erforderlicher Konfigurationen erfolgt auf eigenes Risiko und nach alleinigem Ermessen des Abonnenten; und ein derartiges Versäumnis entbinden Zendesk und seine Mitarbeiter, Agenten und verbundenen Unternehmen von jeder Verantwortung im Hinblick auf den unbefugten Zugriff auf das, die unangemessene Verwendung oder Offenlegung der Servicedaten des Abonnenten, einschließlich elektronischer personenbezogener Gesundheitsdaten, infolge eines derartigen Versagens des Abonnenten .
Die folgenden Mindest-Sicherheitskonfigurationen für Zendesk Support müssen eingerichtet werden und sind in den HDS-Nutzungsbedingungen für jedes HDS-fähige Konto bestätigt:

 

Die folgenden Mindest-Sicherheitskonfigurationen für Zendesk Support müssen eingerichtet werden und sind in den HDS-Nutzungsbedingungen für jedes HDS-fähige Konto bestätigt:

  1. Sichere Agentenauthentifizierung mit einer der beiden folgenden Methoden:
    1. Verwenden von nativem Zendesk Support mit Kennworteinstellungen: (i) auf „Hoch“ gesetzt; oder (ii) vom Abonnenten in einer Weise angepasst werden, die Anforderungen festlegt, die nicht weniger sicher sind als die unter der Einstellung „Hoch” festgelegten Anforderungen. Darüber hinaus muss der Abonnent unter der Option in diesem Unterabschnitt die Zwei-Faktor-Authentifizierung („2FA“) nativ im Dienst aktivieren und durchsetzen. und dass administrative Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, deaktiviert werden; oder
    2. Verwenden einer externen Single-Sign-On (SSO)-Lösung, deren Anforderungen nicht weniger sicher sind als die der Zendesk-Kennworteinstellung „Hoch“, und Aktivieren und Durchsetzen der Zwei-Faktor-Authentifizierung in der gewählten Lösung für den Zugriff aller Agenten. Die administrativen Kontrollen, die es Administratoren ermöglichen, Kennwörter für Endbenutzer festzulegen, müssen deaktiviert sein.
    3. Bei allen Authentifizierungsoptionen mit SSO als Authentifizierungsmethode muss der Kennwortzugriff deaktiviert werden.
  2. Die SSL-Verschlüsselung (Secure Socket Layer) muss in HDS-aktivierten Konten immer aktiviert bleiben. HDS-fähige Konten, die eine andere Domäne als Zendesk.com verwenden, müssen gehostetes SSL einrichten und pflegen.
  3. Der Agentenzugriff muss auf bestimmte IP-Adressen beschränkt werden, die vom Abonnenten für Support und Chatkontrolliert werdenes 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 Abonnentenumgebung in Verbindung mit Enterprise-SSO).  Zur Klarstellung: „Agentenzugriff“ bezieht sich auf den Zugriff, der einem menschlichen Agenten gewährt wird, der über die Benutzerschnittstelle („UI“) auf Dienstdaten zugreift.
  4. In dem Umfang, in dem das HDS-fähige Konto des Abonnenten Aufrufe an Zendesk-Anwendungsprogrammierschnittstellen (APIs) ermöglicht, übernimmt der Abonnent die volle Verantwortung für das Verständnis der Sicherheitsauswirkungen aller Abonnenten oder Dritten, die Daten erstellen, aufrufen, ändern oder löschen dürfen Servicedaten und personenbezogene Gesundheitsinformationen über diesen Zugriff und/oder Integrationen. Für den Zugriff auf die genannten APIs muss der Abonnent die folgenden bewährten Sicherheitspraktiken auf Grundlage des verwendeten API-Modells implementieren:
    1. OAuth 2.0-Ansatz verwenden.  Dieses Modell bietet die granularsten Sicherheitsfunktionen, setzt aber voraus, dass die Zugriffsberechtigungen von einem Endbenutzer akzeptiert werden.  Der Abonnent wird nach Möglichkeit den Ansatz und das Authentifizierungsschema von OAuth 2.0 verwenden. Der Abonnent gibt jedem OAuth-Client einen aussagekräftigen und eindeutigen Clientnamen sowie eine eindeutige Kennung. Die für jedes OAuth-Token gewährten Berechtigungen sollten die geringsten Berechtigungen zulassen, die zur Erfüllung der erforderlichen Aufgaben erforderlich sind.
    2. REST-API-Token-Ansatz verwendet.  Dieses Modell ist am breitesten und ermöglicht es einem API-Token, die volle Funktionalität des API-Modells zu nutzen.  Sie bietet den umfassendsten Zugriff und die umfassendsten Funktionen und sollte mit Bedacht eingesetzt werden. Bei Verwendung dieses Ansatzes wird der Abonnent (i) für jeden Dienst ein eindeutiges Token verwenden und dem Token einen aussagekräftigen Namen geben, der die Funktion bestimmt; (ii) API-Token nicht an Dritte weitergeben, es sei denn, dies ist erforderlich und es müssen Übertragungsverfahren durchgeführt werden, die durchgängig verschlüsselt sind; (ii) erkennen an, dass das zugehörige Token sofort rotiert, 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 einmal alle einhundertachtzig (180) Tage rotieren.  Der Abonnent hat die Allgemeinen Geschäftsbedingungen für die REST-API des Dienstes einzuhalten. 
  5. Der Abonnent muss die Option „Authentifizierung erforderlich, um Dateien herunterzuladen“ aktivieren, damit der Zugriff auf Anhänge eine Authentifizierung erfordert.
  6. Der Abonnent muss auf allen Endpunkten, auf die Agenten, Administratoren und Kontoinhaber zugreifen, systematisch einen kennwortgeschützten Bildschirmschoner oder Startbildschirm einrichten, der nach maximal fünfzehn (15) Minuten Inaktivität aktiviert wird.
  7. Der Abonnent darf die Anzeigeberechtigungen, die es einem Benutzer ermöglichen, Aktualisierungen für die gesamte Organisation anzuzeigen, oder die Standardeinstellung, die einen Zugriff über die eigenen Tickets hinaus ermöglicht, nicht ändern (es sei denn, er übernimmt die gesamte Verantwortung dafür, sicherzustellen, dass diese Benutzer vom Abonnenten die Genehmigung zum Zugriff auf alle nachfolgenden Daten erhalten).
  8. Der Abonnent erkennt an, dass Zendesk nicht dafür verantwortlich ist, E-Mail-Übertragungen von Endbenutzern und zugehörige Dienstdaten vor dem Eingang in seiner Zendesk Support -Instanz zu schützen. Hierzu gehören alle personenbezogenen Gesundheitsinformationen, die per E-Mail über Antworten auf Zendesk Support Tickets weitergegeben werden, einschließlich Ticketkommentare oder Anhänge.
  9. Der Abonnent erkennt an, dass Zendesk Support eine E-Mail an einen Endbenutzer sendet, wenn ein Agent des Abonnenten auf ein Zendesk Support Ticket antwortet.  Standardmäßig enthält diese E-Mail die Korrespondenz, die der Agent an den Endbenutzer gesendet hat, und möglicherweise auch personenbezogene Gesundheitsinformationen. Um den Abonnenten noch besser zu schützen, sollte seine Zendesk Support -Instanz so konfiguriert werden, dass der Endbenutzer nur benachrichtigt wird, dass ein Agent geantwortet hat, und dass der Endbenutzer sich bei Zendesk Support authentifizieren muss, um den Inhalt der Nachricht zu sehen.
  10. Der Abonnent erkennt an, dass alle nach eigenem Ermessen in einem beliebigen Zendesk-Dienst eingesetzten SMS-Funktionen auf SMS und/oder verwandten Protokollen basieren, die die unverschlüsselte Übertragung von Nachrichten zwischen und in die jeweiligen Dienste ermöglichen.  SMS-Funktionen sollten daher entweder:
    1. nicht in einem HDS-fähigen Konto* verwendet werden oder
    2. der Abonnent übernimmt die gesamte Verantwortung für die Nutzung dieser Funktionen.

* Zur Klarstellung: Die in Abschnitt 10 zu SMS genannten Vorbehalte zu ePHI gelten nicht für die produktintegrierte Nutzung der 2FA (siehe Abschnitt 1.a), da diese Funktion lediglich eine numerische Zeichenfolge zur Identitätsprüfung sendet.

Die folgenden Mindest-Sicherheitskonfigurationen für die Zendesk Guide und Gather-Services müssen eingerichtet werden und sind in den HDS-Nutzungsbedingungen für HDS-fähige Konten aufgeführt:

  1. Der Abonnent erkennt an, dass die Guide- und Gather-Dienste öffentlich sind (sofern keine IP-Beschränkungen für „interne“ Help Center in Anspruch genommen werden), und dass der Abonnent daher sicherstellen muss, dass Beiträge in Zendesk Guide oder Gather keine personenbezogenen Gesundheitsinformationen enthalten, auch nicht im Text der oder als Anhang oder Bild im Beitrag veröffentlichen.
  2. Der Abonnent muss entweder die Möglichkeit für Endbenutzer deaktivieren, Kommentare in Zendesk Guide hinzuzufügen , oder personenbezogene Gesundheitsinformationen aus allen Kommentaren entfernen bzw. moderieren und selbst dafür verantwortlich sein.
  3. Die Verwendung von Community-Moderatoren, die keine Mitarbeiter sind, ist im Gather-Dienst nicht gestattet.

Die folgenden Mindest-Sicherheitskonfigurationen für den Zendesk Chat -Dienst müssen eingerichtet werden und sind in den HDS-Nutzungsbedingungen für HDS-fähige Konten aufgeführt:

  1. Der Abonnent ist verpflichtet, den Zugriff von Bearbeitern auf den Zendesk Chat -Dienst durch Verknüpfung mit dem Zendesk Support-Dienst und Authentifizierung über den Zendesk Support -Dienst einzuschränken.
  2. Der Abonnent muss das E-Mail-Piping deaktivieren.
  3. Der Abonnent darf „Arbeitsbereiche für Agenten“ nur aktivieren, wenn er die volle Verantwortung dafür hat, dass (i) in Chats keine ePHI vorhanden sind und/oder (ii) alle Agenten die entsprechende Datenberechtigung erhalten.

Die folgenden Mindest-Sicherheitskonfigurationen für die Nutzung des Zendesk Explore -Dienstes sind in den HDS-Nutzungsbedingungen für HDS-fähige Konten aufgeführt:

Der Abonnent erkennt an, dass in Explore über Benutzernamen, Tickettitel, Feld- und Formularoptionen und Inhalte von Freitextfeldern ePHI angezeigt werden können.

  1. Für alle internen Dienstinstanzen, die personenbezogene Gesundheitsinformationen enthalten, muss der Abonnent (i) nur solchen Agenten Zugriff auf die Explore-Oberfläche gewähren, die auf alle Tickets/Anrufe/Chats zugreifen können, die in der übergeordneten Dienstinstanz/den übergeordneten Diensten personenbezogene Gesundheitsinformationen enthalten können, und (ii) gewähren diesen Zugriff unter Berücksichtigung der Mindestanzahl von Berechtigungen, die für die Nutzung von Explore in ihrer Umgebung erforderlich sind. Weitere Informationen zum Konfigurieren von Zugriffsebenen in Explore finden Sie hier.
  2. Bei Nutzung der Exportfunktion (i) erkennt der Abonnent an, dass personenbezogene Gesundheitsinformationen an ein Gerät übertragen werden können, dem der Abonnent Zugriff auf die Agentenoberfläche gewährt hat und dass alle damit verbundenen Steuerungen auf diesem Gerät in der Verantwortung des Abonnenten liegen, und (ii) hat er die Verwendung zu verweigern Exportfunktionen per E-Mail für die exportierten Berichte nutzen, es sei denn, sie sind dafür verantwortlich, entweder (a) sicherzustellen, dass in diesen Exporten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (b) dass die für solche Übertragungen verwendeten E-Mail-Dienste die Verschlüsselung über das zulässige Mindestprotokoll unterstützen der bis dato aktuellen PCI-Standards entspricht.

* Besondere Überlegungen bei Verwendung von Explore Enterprise:

Der Abonnent erkennt an, dass bei Nutzung des Explore Enterprise-Dienstes möglicherweise mehr Funktionen für die gemeinsame Nutzung von Daten und zum Export bereitgestellt werden können. Der Abonnent muss:

  1. entweder (i) sicherstellen, dass keine ePHI in diesen Dashboards vorhanden sind, und/oder (ii) Dashboards nur mit Agenten, Gruppen, Listen oder Endbenutzern teilen, die zum Anzeigen und Empfangen dieser Daten berechtigt sind.
  2. IP-Beschränkungen nutzen
  3. beim Teilen von Dashboards über einen einheitlichen Ressourcen-Locator (URL) anerkennt der Abonnent, dass die Daten nicht mit einzelnen Benutzer- oder Gruppenbenutzerkonten geteilt werden, sondern über einen Zugriffslink. Der Abonnent muss daher (i) den Kennwortschutz aktivieren, (ii) sicherstellen, dass die Komplexität, Rotation, Speicherung und Verteilung der gewählten Kennwörter an die empfangende Partei im Einklang mit den Kennwortrichtlinien des Abonnenten zum Schutz der in solchen Dashboards enthaltenen Daten erfolgt, und (ieren) die Dokumente rotiert und zwar ohne unangemessene Verzögerung bei Verdacht oder Bestätigung der Offenlegung

Für die Nutzung mobiler Zendesk-Anwendungen (oder den Zugriff per Mobilgerät wie Smartphone oder Tablet) müssen die folgenden Mindest-Sicherheitskonfigurationen eingerichtet sein:

  1. Die Nutzung umfasst die Verschlüsselung auf Geräteebene
  2. Biometrische Daten oder ein PIN-Zugriff auf die höchste zulässige Geräteeinstellung sind erforderlich
  3. Benachrichtigungen, die es ermöglichen, dass Ticketkommentare auf den Sperrbildschirmen solcher Geräte angezeigt werden, müssen deaktiviert werden
  4. Die Bildschirmsperre für inaktive Inhalte muss aktiviert und so konfiguriert sein, dass sie bei Inaktivität von maximal 15 Minuten gesperrt wird.

Produktintegrierte Funktionen für bereitgestellte verknüpfte Dienste („Add-ons“):

  1. Collaboration Deployed Associated Service: „Nebenkonversationen“. Der Abonnent erkennt an, dass bei Nutzung der Funktionalität „Nebenkonversationen“ untergeordnete Ticket- oder Nebenkonversationsnachrichten in der Support -Instanz des Abonnenten erstellt oder von dort aus per Ticket, E-Mail, Slack oder Integrationen (nach Ermessen des Agenten konfiguriert) an Empfänger gesendet werden können. Wenn der Abonnent diese Funktionalität in einem HDS-fähigen Konto nutzt, übernimmt er die gesamte Verantwortung (i) dafür, dass in diesen Nachrichten keine personenbezogenen Gesundheitsinformationen enthalten sind, oder (ii) falls in diesen Nachrichten personenbezogene Gesundheitsinformationen enthalten sein könnten für jegliche Haftung, Kosten, Schäden oder Schäden im Zusammenhang mit dem unbefugten Erwerb, Zugriff, Verwendung oder Offenlegung von PHI infolge des Nachrichtenaustauschs über die Funktion „Nebenkonversation“.

Hinweis: Aufgrund gesetzlicher oder regulatorischer Änderungen oder Änderungen des Zendesk-Service können sich die Sicherheitskonfigurationen in diesem Dokument von Zeit zu Zeit ändern. Dieses Dokument enthält die Empfehlungen von Zendesk für die minimalen Sicherheitskonfigurationen zum Schutz personenbezogener Gesundheitsinformationen in den oben genannten Zendesk-Produkten. Dieses Dokument ist weder als umfassende Vorlage für die Kontrolle dieser Daten noch als Rechtsberatung gedacht. Jeder Zendesk-Abonnent sollte bezüglich der HDS-Compliance-Anforderungen einen eigenen Rechtsberater hinzuziehen und alle zusätzlichen Änderungen an seinen Sicherheitskonfigurationen im Einklang mit der eigenen Analyse vornehmen, solange diese Änderungen die Sicherheit der Konfigurationen nicht beeinträchtigen oder beeinträchtigen die in diesem Dokument beschrieben werden.

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