Comptes activés HIPAA et HDS (collectivement les « comptes activés pour la santé ») :

Tous les termes commençant par une lettre majuscule utilisés dans le présent document auront le sens qui leur est donné dans le Business Associate Agreement (Contrat d’associé commercial) de Zendesk (« BAA») ou l’article sur les conditions HDS figurant dans l’accord-cadre d’abonnement de Zendesk (« Affichee HDS »), tel qu’applicable au type de compte (collectivement, « Accord sur les soins de santé »).

Dans le cadre des comptes activés HIPAA , le terme « PHI » signifie « Informations de santé protégées » et dans le cadre des comptes activés HDS, le terme « PHI » signifie « Informations de santé personnelles ».

Zendesk et l’Abonné ont conclu un accord de santé qui recommande à l’Abonné d’évaluer et de mettre en œuvre, selon les besoins de son cas d’utilisation, les configurations suivantes ou les alternatives évaluées par l’Abonné pour satisfaire à ses exigences de conformité en vertu de la loi applicable, pour tout compte activé pour les soins de santé (s) avant d’introduire des informations de santé protégées dans les Services.

Si l’Abonné choisit, à sa seule discrétion, de renoncer à mettre en œuvre l’une des configurations recommandées répertoriées ci-dessous, l’Abonné assumera la responsabilité exclusive de tout accès non autorisé ou de toute utilisation inappropriée de la divulgation de ses Données de service, y compris les ICP, qui résultent de toute de tels écarts par rapport aux configurations recommandées par l’Abonné.

L’Abonné doit avoir acheté les éditions de service au niveau approprié et disposer des modules supplémentaires associés (consultez votre représentant en cas de doute).

Si l’Abonné a un compte activé HDS, il doit cliquer sur le bouton Suivre dans la Politique des sous-traitants de Zendesk pour recevoir des notifications de toute modification des sous-traitants utilisés pour fournir les Services.

Les configurations de sécurité minimum suivantes pour les services Zendesk doivent être mises en place et sont prises en compte dans le contrat de santé pour tous les comptes activés Zendesk

I. Zendesk Support:

  1. Authentification sécurisée de l’agent en utilisant l’une des deux méthodes suivantes :
    1. Utilisation de Zendesk Support natif avec les paramètres de mot de passe : (i) configuré sur Recommandé; ou (ii) personnalisées par l’Abonné d’une manière qui établit des exigences non moins sûres que celles établies pour le paramètre « Recommandé ». En outre, selon l’option de cette sous-section, l’Abonné doit aussi activer et appliquer l’authentification à deux facteurs (« A2F ») au sein du Service. et les contrôles administratifs qui permettent aux administrateurs de configurer les mots de passe pour les utilisateurs finaux doivent être désactivés. ou
    2. L’utilisation d’une solution de connexion unique externe avec des exigences établies non moins sûres que celles établies dans le paramètre de mot de passe Zendesk Recommandé, et l’activation et l’application de l’authentification à deux facteurs au sein de la solution sélectionnée pour l’accès de tous les Agents. Les contrôles administratifs permettant aux Administrateurs de configurer les mots de passe pour les Utilisateurs finaux doivent être désactivés.
    3. Tous les choix d’authentification utilisant la connexion unique comme méthode d’authentification doivent désactiver l’accès par mot de passe.
  2. Le cryptage SSL (Secure Socket Layer) pour les comptes de santé activés doit rester activé en permanence. Les comptes Zendesk Active qui utilisent un domaine autre que zendesk.com doivent établir et maintenir l’option SSL hébergé..
  3. Dans la mesure du possible, l’accès de l’agent doit être limité à des adresses IP spécifiques sous le contrôle de l’Abonné. sauf si l’Abonné active l’authentification multifacteur pour les agents comme décrit ci-dessus dans les exigences 1.a ou 1.b (soit au sein du Service, soit dans l’environnement de l’Abonné avec la connexion unique Enterprise).  Afin d’éviter le moindre doute, le terme « Accès des agents » désigne l’accès accordé à un agent humain accédant aux Données de service via l’interface utilisateur.
  4. Dans la mesure où le Compte de l’Abonné activé pour la santé permet des appels à la ou aux interfaces de programmation d’applications Zendesk (« API »), l’Abonné assumera la responsabilité de comprendre les implications en matière de sécurité de toutes les entités de l’Abonné ou de tierces parties autorisées à créer, accéder, modifier, ou supprimer. Données de service et informations de santé protégées via cet accès et/ou ces intégrations. Pour l’accès à de telles API, Zendesk propose diverses méthodes décrites dans le présent document et l’Abonné met en œuvre les meilleures pratiques de sécurité suivantes en fonction du modèle d’API utilisé :
    1. Approche OAuth 2.0.  Ce modèle offre les capacités de sécurité les plus détaillées, mais nécessite que les droits d’accès soient acceptés par l’utilisateur final.  Dans la mesure du possible, l’Abonné doit utiliser l’approche et le schéma d’authentification OAuth 2.0.. L’abonné doit attribuer à chaque client OAuth une fonction de description de nom de client et d’identifiant unique descriptive et unique. Les permissions accordées pour chaque token OAuth doivent autoriser le moindre privilège nécessaire pour accomplir la ou les tâches requises.
    2. Approche avec un token API REST.  Ce modèle est le plus large et permet à un token API d’utiliser toutes les fonctionnalités du modèle API. De par sa nature, il offre les capacités et l’accès les plus larges et doit être utilisé avec prudence. Lorsqu’il utilise cette approche, l’Abonné doit (i) utiliser un token unique pour chaque service et lui donner une fonction de nom descriptif ; (ii) ne partagerez pas les tokens API avec un tiers, sauf dans la limite raisonnable requise et par le biais de méthodes de transmission chiffrées de bout en bout ; (III) reconnaissez que si un token API est partagé avec un tiers et que l’Abonné est informé d’une violation de données tierce, l’Abonné doit changer le token associé immédiatement ; et (iv) au minimum, changer le token fréquemment conformément aux politiques de l’organisation de l’Abonné.  
    3. Dans la mesure du possible, l’Abonné doit désactiver l’accès à l’API par mot de passe, car cette approche envoie les identifiants utilisateur avec chaque demande qui les expose largement, ce qui les rend plus faciles à intercepter par des tiers malveillants.  
  5. L’abonné doit activer l’option « Demander une authentification pour télécharger » afin d’exiger une authentification pour accéder aux pièces jointes.. Sinon, tout utilisateur ayant accès à l’URL correcte pour cette pièce jointe pourra accéder à toute pièce jointe non restreinte. Dans de tels cas, l’Abonné assumera toute la responsabilité du contenu de ces pièces jointes et de l’accès à ces données.
  6. L’Abonné doit systématiquement appliquer, pour tous les points de terminaison accessibles par les Agents, les Administrateurs et les Propriétaires, un écran de démarrage ou un écran de démarrage verrouillé configuré pour engager un maximum de quinze (15) minutes d’inactivité du système.
  7. L’Abonné ne doit pas modifier les autorisations de consultation qui permettent à un utilisateur de voir les mises à jour pour une instance/marque/organisation entière, ni modifier le paramètre par défaut au-delà de ses propres tickets ou groupes (sauf si l’Abonné est responsable de s’assurer que ces utilisateurs sont approuvés par l’Abonné accéder à toutes les données suivantes). L’Abonné comprend que les autorisations de l’organisation de l’utilisateur final peuvent être configurées dans le profil de l’utilisateur et dans l’organisation elle-même et si ces paramètres sont contradictoires, le paramètre permissif remplace le paramètre moins permissif.
  8. L’Abonné reconnaît que Zendesk n’est pas responsable de la sécurisation des transmissions des e-mails des Utilisateurs finaux et des Données de service connexes avant leur réception dans l’instance Zendesk Support de l’Abonné. Cela inclut tous les ICP qui peuvent être transmis par e-mail via les réponses aux tickets Zendesk Support , y compris mais sans s’y limiter, les commentaires de ticket et les pièces jointes.
  9. L’Abonné reconnaît que Zendesk Support envoie un e-mail à un utilisateur final dans diverses circonstances, par exemple quand l’agent d’un Abonné répond à un ticket Zendesk Support par le biais du canal e-mail ou initié par un automatisme ou un déclencheur. Par défaut, cet e-mail contient la correspondance de ticket la plus récente ou d’autres informations configurées pour être incluses dans une notification automatisée, qui peuvent potentiellement inclure des informations de santé protégées. Pour plus de protection de l’Abonné, son instance Zendesk Support doit être configuré pour prévenir l’utilisateur final uniquement qu’un agent a réponduet exiger que l’utilisateur final s’authentifie dans Zendesk Support pour voir le contenu de son message.
  10. L’Abonné comprend que toute fonctionnalité de messagerie texte utilisée à sa seule discrétion dans tout Service Zendesk s’appuie sur des SMS ou des protocoles connexes, ce qui peut impliquer la transmission non chiffrée des messages envoyés à ou hors du ou des Services.  Ainsi, la fonctionnalité de SMS doit soit :
    1. ne pas être utilisé avec un compte activé Zendesk Chat*, ou
    2. si elle est utilisée, l’Abonné assume toute la responsabilité de l’utilisation de cette fonctionnalité
  11. L’Abonné comprend que l’utilisation de l’ ancienne fonctionnalité d’enquêtes de satisfaction client (« anciennes CSAT») du Service envoie les Données de service (qui peuvent contenir des informations de santé protégées) associées au ticket Support par e-mail afin d’obtenir la note de l’utilisateur, dont le statut de chiffrement n’est pas contrôlé. par Zendesk. Ainsi, l’ancienne fonctionnalité CSAT doit :
    1. ne pas être utilisé avec un compte activé Zendesk Chat*, ou
    2. si elle est utilisée, l’Abonné assume toute la responsabilité de l’utilisation de cette fonctionnalité
  12. L’Abonné comprend que l’utilisation de la fonctionnalité Enquêtes de satisfaction client (« CSAT») du Service pour le canal de gestion des tickets, s’il n’est pas configuré comme il faut, envoie les Données de service (qui peuvent contenir des informations PHI) associées au ticket Support par e-mail afin d’obtenir la note de l’utilisateur, dont le statut de chiffrement n’est pas contrôlé par Zendesk. En outre, toute personne disposant de l’URL CSAT spécifique a accès aux réponses données pour un ticket spécifique. Ainsi, quand l’Abonné utilise la fonctionnalité de CSAT pour le canal de tickets,
    1. Configurez le corps de l’e-mail de l’automatisme CSAT pour qu’il n’inclue pas les informations de santé client potentielles et utilise le mot {{satisfaction.survey_url}} balise exclusivement
    2. Ne pas utiliser la fonctionnalité de questions ouvertes

* Afin d’éviter le moindre doute, les mises en garde pour les données associées aux informations de santé dans la section 10 portant sur les SMS ne s’appliquent pas à l’utilisation de l’authentification à deux facteurs au sein du produit (comme expliqué dans la section 1.a), car une telle fonctionnalité envoie simplement une chaîne numérique pour la vérification de l’identité.

II. Zendesk Guide et Gather :

  1. L’Abonné convient que les Services Guide et Gather sont publics par nature (dans le cas où ils n’utilisent pas d’articles restreints ou n’utilisent pas une instance fermée ou restreinte) et par conséquent, l’Abonné doit s’assurer que les articles du Zendesk Guide ou des Services Gather n’incluent pas les informations de santé protégées, que ce soit par le biais du texte l’article, ou sous la forme d’une pièce jointe à l’article, ou d’une image au sein de cet article.
  2. L’Abonné doit soit désactiver la possibilité pour les Utilisateurs finaux d’ajouter des commentaires dans Zendesk Guide, soit modérer et assumer la responsabilité de supprimer les ICP de tous les commentaires (comme expliqué dans la section 3 ci-dessous).
  3. Lorsque le Service Zendesk Guide est Guide Professional ou Enterprise, les Abonnés doivent, dans la mesure du possible, désactiver la possibilité pour les utilisateurs finaux de créer de nouvelles publications en désactivant la fonctionnalité Gather avec Zendesk Guide ou quand ils désactivent les fonctionnalités Gather, ils ne peuvent pas être utilisés du fait de l’intention de l’Abonné. Les abonnés doivent activer la modération du contenu dans le service Zendesk Guide et configurer l’option « Modérer tout le contenu ».. Aucune soumission contenant des informations de santé protégées ne doit être approuvée.
  4. L’utilisation par l’Abonné de « Modérateurs de la communauté » au sein du Service Gather qui ne sont pas des employés ne doit pas être autorisée, sauf si l’Abonné assume la responsabilité de l’accès potentiel de ces utilisateurs aux données, y compris les informations de santé protégées (le cas échéant).
  5. L’abonné convient que l’utilisation de @mentions pour les membres de la communauté Gather est possible quand elle permet aux utilisateurs finaux d’avoir des profils publics et si cette fonctionnalité est considérée comme un risque dans leur cas d’utilisation, les profils publics doivent être désactivés ou @mentions désactivées.

III. Messagerie Zendesk :

  1. L’Abonné ne doit pas activer les intégrations des canaux de messagerie de réseaux sociaux, sauf s’il assume l’entière responsabilité soit (i) de s’assurer qu’aucun élément de santé personnel ne soit présent dans les messages de réseaux sociaux, soit (ii) de conclure son propre BAA avec les plateformes de messagerie intégrées.
  2. L’Abonné doit désactiver la possibilité pour les Utilisateurs finaux de joindre des fichiers aux conversations de messagerie et acceptera l’entière responsabilité soit (i) d’activer les pièces jointes sécurisées, ou (ii) en vous assurant que les agents ne joints pas de fichiers contenant des identifiants électroniques (ePHI) aux conversations de messagerie. Sinon, tout utilisateur ayant accès à l’URL correcte pour cette pièce jointe pourra accéder à toute pièce jointe non restreinte.  Dans de tels cas, l’Abonné assumera toute la responsabilité du contenu de ces URL et/ou données de pièces jointes, ainsi que de l’accès à ces URL et/ou données de pièces jointes.
  3. L’Abonné est responsable de s’assurer que tous les Agents et Agents light sont autorisés à consulter tous les Messages entrants de tous les Utilisateurs finaux.
  4. Si l’Abonné ou ses Agents accèdent à des intégrations ou les développent (par ex. dans le cadre d’un flux créé pour les Agents de IA ) pour les API et les webhooks ou personnalisent l’expérience de messagerie, l’Abonné est responsable de comprendre les implications en matière de confidentialité et de sécurité de tous les workflows personnalisés et pour tous L’abonné ou les entités tierces (y compris les fournisseurs de chatbot) autorisées à créer, accéder, modifier ou supprimer les Données de service et les ePHI via cet accès et/ou ces intégrations.
  5. Si l’Abonné souhaite supprimer la permission d’un agent de participer à une conversation de messagerie alors que la conversation par messagerie est active, il est responsable de forcer la résiliation de l’accès de cet agent à Zendesk.
  6. Par défaut, les conversations du Web Widget avec les utilisateurs finaux sont persistantes et peuvent être consultées par l’utilisateur final lorsqu’il revient au chat Web à partir du même appareil. L’Abonné doit désactiver cette fonctionnalité ou s’assurer que les Utilisateurs finaux ne partagent pas les appareils.
  7. Si l’Abonné souhaite mettre en œuvre l’authentification pour les Utilisateurs finaux, il est responsable de la mise en œuvre sécurisée, conformément aux meilleures pratiques et aux normes du secteur.
    1. Lorsqu’il utilise cette approche, l’Abonné doit (i) utiliser une clé de connexion JWT unique pour chaque canal d’authentification et attribuer au token un nom descriptif; (ii) ne partagez pas les clés de connexion JWT avec un tiers, sauf dans la mesure raisonnablement requise et en fonction de méthodes de transmission chiffrées de bout en bout ; (III) comprendre que si la clé de connexion JWT est partagée avec un tiers et si l’Abonné est informé d’une violation de données tierce, l’Abonné doit changer la clé de connexion JWT associée immédiatement ; et (iv) au minimum, changer la clé de connexion JWT fréquemment conformément aux politiques de l’organisation de l’Abonné.
    2. L’abonné doit utiliser l’attribut JWT d’expiration et définir sa valeur sur 15 minutes maximum.
  8. L’Abonné comprend que les interactions entre les Utilisateurs finaux et les Agents IA qui ne sont pas transférées à un Agent et transférées sur un ticket sont encore stockées dans le système et qu’il est de la responsabilité de l’Abonné de les supprimer conformément à ses obligations (par ex. en mettant en place une qui prévient l’Abonné quand ces conversations sont stockées et déclenche (automatiquement) la suppression via l’API Sunshine Conversations ). 
  9. L’Abonné comprend que les conversations entre les utilisateurs finaux et les agents IA qui ont été transformés dans un ticket ne peuvent pas être supprimées pour l’instant. Il est possible de les supprimer en supprimant le ticket. 
  10. L’Abonné confirme que les pièces jointes des utilisateurs finaux dans les canaux de messagerie ne sont actuellement pas analysées pour détecter les logiciels malveillants dans Zendesk. L’Abonné assumera l’entière responsabilité de mettre en place des procédures et des politiques pour minimiser le risque pour les actifs de l’Abonné. 
  11. L’Abonné comprend que l’utilisation de la fonctionnalité de conversations annexes peut entraîner la création de messages « ticket enfant » et/ou « conversation annexe » dans ou envoyés de l’instance Support de l’Abonné aux destinataires via ticket, e-mail, Slack ou intégrations (à la discrétion de l’Agent de configurer l’Agent) . Si l’Abonné choisit d’utiliser cette fonctionnalité dans un compte activé pour les soins de santé, l’Abonné assume toute la responsabilité soit (i) de s’assurer qu’aucun PHI n’est présent dans de tels messages, soit (ii) si des PHI peuvent être présents dans les messages, l’Abonné est seul responsable pour toute responsabilité, coût, dommage ou dommage en rapport avec l’acquisition, l’accès, l’utilisation ou la divulgation non autorisé(e) de PHI résultant de l’échange de messages via la fonctionnalité « Conversation annexe ».

IV. Zendesk Sunshine Conversations :

  1. L’Abonné ne doit pas activer les intégrations de canaux tiers, sauf s’il assume l’entière responsabilité de s’assurer (i) qu’il n’y a pas d’ICP présents dans les messages des canaux tiers ou (ii) de conclure son propre BAA avec les plateformes de messagerie intégrées.
  2. L’Abonné assume toute la responsabilité de comprendre les implications en matière de sécurité de tous les Abonnés ou entités tierces autorisées à créer, accéder, modifier ou supprimer les Données de service et les ICP via l’interface de programmation d’application Sunshine Conversations (« API »). Pour l’accès auxdites API, l’Abonné met en œuvre les meilleures pratiques de sécurité suivantes en fonction du modèle d’API utilisé :
    1. Approche OAuth 2.0.  Ce modèle offre les capacités de sécurité les plus détaillées, mais nécessite que les droits d’accès soient acceptés par l’utilisateur final.  Dans la mesure du possible, l’Abonné doit utiliser l’approche et le schéma d’authentification OAuth 2.0 ;. L’abonné doit attribuer à chaque client OAuth une fonction de description de nom de client et d’identifiant unique descriptive et unique. 
    2. Approche avec un token API REST.  Ce modèle est le plus large et permet à un token API d’utiliser toutes les fonctionnalités du modèle API.  De par sa nature, il offre les capacités et l’accès les plus larges et doit être utilisé avec prudence. Lorsqu’il utilise cette approche, l’Abonné doit (i) utiliser un token unique pour chaque service et lui donner une fonction de nom descriptif ; (ii) ne partagerez pas les tokens API avec un tiers, sauf dans la limite raisonnable requise et par le biais de méthodes de transmission chiffrées de bout en bout ; (III) reconnaissez que si un token API est partagé avec un tiers et que l’Abonné est informé d’une violation de données tierce, l’Abonné doit changer le token associé immédiatement ; et (iv) changer le token fréquemment conformément à la politique organisationnelle de l’Abonné.  
    3. Si l’Abonné ou ses Agents accèdent aux API ou aux webhooks ou personnalisent l’expérience Sunshine Conversations , l’Abonné est responsable de comprendre les implications en matière de confidentialité et de sécurité de tous les workflows personnalisés et de toutes les entités qu’Abonné ou des tierces parties (y compris les fournisseurs de chatbot) autorisent. pour créer, accéder, modifier ou supprimer les Données de service et les ICP via ces accès et/ou intégrations.
  3. L’Abonné comprend que les restrictions IP configurées pour Zendesk Support ne s’appliquent pas à l’API Sunshine Conversations . Les Abonnés sont responsables de restreindre l’accès à l’API Sunshine Conversations et aux tokens API comme expliqué dans l’article 2.b. et conformément aux politiques de l’Abonné. 
  4. L’Abonné doit désactiver la possibilité pour les Utilisateurs finaux de joindre des fichiers aux conversations Sunshine Conversations et adopter l’entière responsabilité d’ activer les pièces jointes sécurisées. ou de s’assurer que les agents ne joints pas de fichiers contenant les informations de santé protégées aux conversations de messagerie. Sinon, tout utilisateur ayant accès à l’URL correcte pour cette pièce jointe pourra accéder à toute pièce jointe non restreinte. Dans de tels cas, l’Abonné assumera toute la responsabilité du contenu de ces pièces jointes et de l’accès à ces données.
  5. Si l’Abonné souhaite mettre en œuvre l’authentification pour les utilisateurs finaux, il est responsable de la mise en œuvre d’une méthode solide, conforme aux meilleures pratiques de sécurité et aux normes du secteur.
    1. Lorsqu’il utilise cette approche, l’Abonné doit (i) utiliser une clé de connexion JWT unique pour chaque canal d’authentification et attribuer au token un nom descriptif; (ii) ne partagez pas les clés de connexion JWT avec un tiers, sauf dans la mesure raisonnablement requise et en fonction de méthodes de transmission chiffrées de bout en bout ; (III) comprendre que si la clé de connexion JWT est partagée avec un tiers et si l’Abonné est informé d’une violation de données tierce, l’Abonné doit changer la clé de connexion JWT associée immédiatement ; et (iv) au minimum, changer la clé de connexion JWT fréquemment conformément aux politiques de l’organisation de l’Abonné.
    2. L’abonné doit utiliser l’attribut JWT d’expiration et définir sa valeur sur 15 minutes maximum.
  6. L’Abonné comprend que les interactions entre les utilisateurs finaux et les agents IA qui ne sont pas transférées à un agent humain et transférées dans un ticket sont encore stockées dans le système et qu’il est de la responsabilité de l’Abonné de les supprimer conformément à ses obligations, par exemple en mettant en œuvre un webhook qui prévient l’Abonné quand ces conversations sont stockées et déclenche (automatiquement) la suppression via l’API Sunshine Conversations . 
  7. L’Abonné comprend que les conversations entre les Utilisateurs finaux et les Agents IA qui se sont transformées en tickets ne peuvent actuellement pas être biffées. Il est possible de les supprimer en supprimant le ticket. 
  8. L’Abonné comprend que les messages supprimés via l’API Sunshine Conversations sont supprimés uniquement pour les Utilisateurs finaux, mais pas dans l’ Espace de travail d’agent Zendesk. Pour ce faire, vous pouvez supprimer le ticket lui-même ou utiliser la fonctionnalité de suppression d’information (limitations, voir 7.). 
  9. L’Abonné confirme que toutes les pièces jointes dans les canaux Sunshine Conversations ne sont actuellement pas analysées pour détecter les logiciels malveillants dans Zendesk. L’Abonné assumera l’entière responsabilité de mettre en place des procédures et des politiques pour minimiser les risques encourus par ses employés. 

V. Zendesk Chat:

  1. L’Abonné doit limiter l’accès des Agents au Service Zendesk Chat en s’associant au Service d’assistance Zendesk et en s’authentifiant via le Service Zendesk Support .
  2. L’Abonné ne doit pas envoyer les transcriptions Chat par e-mail, en (a) désactivant l’acheminement e-mail, (b) désactivant l’option de transcription des chats par e-mail dans le Web Widget classique et (c) en nepartageant pas les exportations par e-mail à partir du tableau de bord Chat.
  3. L’Abonné assume l’entière responsabilité de s’assurer (i) qu’aucun PHI n’est présent dans les Chats, et/ou (ii) que tous les Agents sont autorisés par l’Abonné à consulter de telles données.

VI. Service Zendesk Explore :

L’Abonné convient que les ICP peuvent être affichés dans le produit Explore par le biais des noms d’utilisateur, des titres des tickets, des choix de champs et de formulaires et de tout contenu qui se trouve dans les champs de texte en forme libre.

  1. Pour toute instance du Service concernée contenant des ICP, l’Abonné doit (i) accorder l’accès à l’interface Explore aux agents qui peuvent accéder à l’ensemble des tickets/appels/chats pouvant contenir des ICP dans la ou les instances du Service parentes, et (ii) doivent accorder un tel accès en tenant compte du moins de droits nécessaires pour utiliser Explore dans leur environnement. Pour en savoir plus au sujet de la configuration des niveaux d’accès dans Explore, cliquez ici.
  2. Lorsqu’il utilise la fonctionnalité d’exportation, (i) l’Abonné comprend que les informations de santé peuvent être transférées vers un appareil autorisé par l’Abonné à accéder à l’interface d’agent et que toutes les contrôles sur ces appareils sont de la responsabilité de l’Abonné et (ii) l’Abonné doit refuser cette utilisation de la fonctionnalité d’exportation native par e-mail pour les rapports exportés, sauf s’il est responsable de (a) s’assurer que ces exportations sont absentes ou (b) que les services de messagerie utilisés pour de tels transferts prennent en charge le chiffrement via le protocole de chiffrement minimum autorisé par les dernières normes PCI.

* Considérations particulières pour l’utilisation d’Explore Enterprise :

L’Abonné comprend que l’utilisation du Service Explore Enterprise peut entraîner des fonctionnalités de partage et d’exportation de données améliorées. L’Abonné doit :

  1. soit (i) s’assurer qu’aucun identifiant n’existe dans ces tableaux de bord, soit (ii) partager les tableaux de bord uniquement avec des agents, groupes, listes ou utilisateurs finaux qui sont approuvés pour consulter et recevoir ces données.
  2. exploiter les restrictions IP
  3. en cas de partage des tableaux de bord via URL, l’Abonné comprend que, au lieu de les partager avec des comptes utilisateur individuels ou de groupes, les données seront partagées par un lien d'accès. L’Abonné doit donc (i) activer la protection par mot de passe, (ii) s’assurer que la complexité des mots de passe choisis, leur rotation, leur stockage et leur distribution à la partie destinataire sont conformes aux politiques de mots de passe de l’Abonné pour la protection des données contenues dans ces tableaux de bord, et (III) qu’ils sont modifiés sans délai injustifié dès le soupçon ou la confirmation de l’exposition

VII. Avis au sujet des fonctionnalités intégrées aux produits pour les services associés installés (« modules supplémentaires ») :

  1. Service associé de collaboration installé : « Conversations annexes ». L’Abonné comprend que l’utilisation de la fonctionnalité de conversations annexes peut entraîner la création de messages « ticket enfant » et/ou « conversation annexe » dans ou envoyés de l’instance Support de l’Abonné aux destinataires via ticket, e-mail, Slack ou intégrations (à la discrétion de l’Agent de configurer l’Agent) . Si l’Abonné choisit d’utiliser cette fonctionnalité dans un compte activé pour les soins de santé, l’Abonné assume toute la responsabilité soit (i) de s’assurer qu’aucun PHI n’est présent dans de tels messages, soit (ii) si des PHI peuvent être présents dans les messages, l’Abonné est seul responsable pour toute responsabilité, coût, dommage ou dommage en rapport avec l’acquisition, l’accès, l’utilisation ou la divulgation non autorisé(e) de PHI résultant de l’échange de messages via la fonctionnalité « Conversation annexe ».

VIII. Applications mobiles Zendesk (ou accès effectué par des appareils mobiles comme les smartphones ou les tablettes) :

  1. L’utilisation doit inclure le chiffrement au niveau de l’appareil
  2. L’accès biométrique ou PIN configuré sur le paramètre d’appareil le plus élevé autorisé doit être utilisé.
  3. Les notifications permettant l’affichage des commentaires de tickets sur les écrans de verrouillage de ces appareils doivent être désactivées.
  4. Les verrous d’inactivité de l’écran doivent être activés et configurés pour ne pas dépasser 15 minutes d’inactivité maximum.
  5. L’Abonné comprend que la fonctionnalitéde suppression d’information n’est pas disponible dans l’application Support mobile et que les Agents doivent se connecter par le biais du Navigateur s’ils souhaitent utiliser cette fonctionnalité.
  6. Si l’Abonné choisit d’authentifier les utilisateurs finaux pour la messagerie Zendesk, il reconnaît que le statut d’authentification d’un utilisateur final ne s’affiche pas dans l’application Support mobile.

IX. Zendesk Insights : La prise en charge de ce service a été abandonnée le 5 février 2021.   

X. Avis au sujet de la fonctionnalité IA de Zendesk (« Zendesk IA», « IA avancée», « IA générative», et al) :

  1. L’Abonné comprend que les fonctionnalités IA de Zendesk sont conçues pour accroître la productivité du ou des Services Zendesk et ne doivent pas être utilisées d’une manière qui pourrait être interprétée comme (i) fournir des conseils médicaux ou de santé, (ii) fournir un diagnostic de condition ou symptômes, (3) prescrire un traitement ou (iv) de toute manière empêchant un Utilisateur de demander les conseils, le diagnostic ou le traitement d’un professionnel de la santé, (v) ou de fournir à l’Utilisateur des informations ou de prendre des décisions tout plan de santé, programme de traitement, service de test ou tout autre service de santé pouvant avoir un impact sur la recherche ou la réception de services de santé par l’Abonné (sauf si l’Abonné n’est pas responsable de cette décision en fonction de son cas d’utilisation unique et des interactions avec ses utilisateurs), quant aux implications potentielles d’une telle utilisation de IA ).
  2. L’Abonné comprend que, s’il utilise des fonctionnalités IA générative, ces sorties IA générées sont générées par un ordinateur et non générées par des êtres humains et peuvent produire des résultats inexacts. Zendesk ne garantit pas la précision de ces sorties.
  3. L’Abonné comprend que si la salutation d’un bot de conversation d’Agents IA est utilisée pour fournir un message de clause de non-responsabilité obligatoire aux utilisateurs finaux de l’Abonné, la fonctionnalité « Générer des variantes » ne sera pas activée pour garantir l’intégrité du contenu du message. 
  4. L’Abonné comprend que l’activation de la fonctionnalité de rédaction améliorée dans le Centre d’administration active cette fonctionnalité pour tous les agents de son instance, quels que soient leurs rôles et permissions. 

XX. Zendesk QA

  1. L’Abonné comprend que les fonctionnalités IA de Zendesk QA sont conçues pour accroître la productivité du ou des Services Zendesk et qu’elles ne doivent pas être utilisées d’une manière qui pourrait être interprétée comme (i) fournir des conseils médicaux ou de santé, (ii) fournir un diagnostic d’état ou des symptômes, (III) prescrire un traitement ou (iv) de quelque façon que ce soit empêcher un Utilisateur de demander les conseils, le diagnostic ou le traitement d’un professionnel de la santé, (v) ou de fournir à l’Utilisateur des informations ou de prendre des décisions d’accès de tout plan de santé, programme de traitement, service de test ou tout autre service de santé pouvant avoir un impact sur sa recherche ou sa réception des services de santé (sauf si l’Abonné n’est pas responsable de cette décision en fonction de son cas d’utilisation unique et des interactions avec ses utilisateurs, ainsi que les implications potentielles d’une telle utilisation de IA ).
  2. L’Abonné comprend que la suppression ou la suppression d’information dans son instance Zendesk n’est pas immédiatement synchronisée avec Zendesk QA , mais sera transférée dans les 3-6 heures suivantes.
  3. Quand il utilise la fonctionnalité d’enquêtes, l’Abonné doit (i) désactiver la fonctionnalité d’assistance par IA de Zendesk QA (ou s’assurer que tous les agents effectuant des tâches QA sont autorisés à voir toutes les données potentielles au sein d’une telle transaction, ainsi que s’assurer que les principes du point 1 sont en place) ( ii) assurez-vous de configurer l’enquête de façon à ne pas révéler les informations PHI dans les questions ou les descriptions de l’enquête (ou à assumer la responsabilité de telles données dans les e-mails envoyés par le biais de StartTLS)
  4. Lors de l’utilisation de l’intégration personnalisée « Zendesk Chat», l’Abonné devrait envisager de définir une période de conservation des données alignée sur les politiques de l’Abonné afin de s’assurer que les données ne sont pas conservées pendant une durée illimitée.
  5. L’Abonné comprend que quand il utilise l’API Sunshine Conversations pour supprimer des parties d’une conversation de messagerie Zendesk, cette modification n’est pas reflétée dans Zendesk QA. Vous devez supprimer les informations du ticket d’origine via la suppression d’information ou toute la conversation.
  6. L’Abonné comprend que Zendesk QA ne prend pas en charge la fonctionnalité de pièces jointes privées de Zendesk actuellement. Cela signifie que toute pièce jointe est accessible à toute personne ayant accès à l’URL correcte pour la pièce jointe et qu’elle ne doit pas être utilisée avec des données sensibles, notamment les PHI. L’Abonné assumera toute la responsabilité du contenu et de l’accès à ces URL et/ou données de pièces jointes.
  7. L’Abonné comprend que, lors du provisionnement initial de Zendesk QA, la configuration d’une connexion avancée n’est possible qu’après la première synchronisation.

DOMAINES. Gestion des collaborateurs Zendesk "Gestion des collaborateurs" :

  1. L’Abonné confirme que
    1. Le rôle d’administrateur Gestion des collaborateurs par défaut a accès à toutes les activités et tous les paramètres de l’agent applicables au service Gestion des collaborateurs (notamment les marqueurs mentionnés au point 2 ci-dessous).
    2. Le rôle d’agent par défaut a accès à l’activité de l’agent, sauf s’il est configuré par les administrateurs pour un accès différent via la création de rôles personnalisés comme expliqué ici.
  2. L’Abonné comprend que les marqueurs appliqués par les Agents, les Administrateurs ou la logique système prédéfinie dans les tickets de Support seront visibles dans le produit Gestion des collaborateurs par tout utilisateur autorisé à voir une telle activité de ticket. Si l’Abonné considère les marqueurs comme sensibles, l’accès doit être configuré correctement.

Exonération : Du fait de changements des lois ou réglementations ou de changements du Service Zendesk, les configurations de sécurité décrites dans le présent document peuvent changer de temps à autre. Ce document contient les recommandations de Zendesk pour les configurations de sécurité minimum efficaces pour la protection des informations de santé protégées dans les produits Zendesk décrits ci-dessus à l’heure actuelle. Ce document ne constitue pas un modèle exhaustif pour tous les contrôles sur ces données et ne constitue pas des conseils juridiques. Chaque abonné Zendesk doit chercher son propre conseiller juridique au sujet de ses exigences de conformité HIPAA ou HDS et doit apporter les modifications supplémentaires à ses configurations de sécurité en fonction de l’analyse indépendante de chaque abonné, tant que ces modifications n’affectent pas ou ne dégradent pas la sécurité de les configurations décrites dans ce document.

 

Journal des modifications :

24 janvier 2025

  • Configurations HIPAA et HDS unifiées

27 décembre 2024

  • Ajout de la section Tweet pour incorporer la Gestion des collaborateurs Zendesk (Gestion des collaborateurs) dans le cadre

16 décembre 2024

  • Ajout de la section X1 pour incorporer Zendesk QA à la portée
  • Conversion de diverses instances d’Answer Bot en Agents IA pour dénoter les modifications de la nomenclature et une portée plus large.

10 octobre 2024

  • Ajout de la Section I, Support, numéro 12 (CSAT) et modification de la Section I, Support, numéro 11 (anciennes CSAT) pour prendre en compte les nouvelles fonctionnalités. 

7 mars 2024

  • Ajout de la section X, avis au sujet de la fonctionnalité IA de Zendesk
  • Section I, Support, numéro 7 (permissions de consultation) :
    • Préciser que les « permissions de consultation » s'appliquent à l'ensemble d'une « instance/marque/organisation » plutôt que d'une seule organisation.
    • Ajout d’une nouvelle disposition pour le comportement spécifique des utilisateurs finaux dans les organisations. 
  • Section I, Support, numéro 9 (e-mail) :  
    • Élargissement des situations dans lesquelles Zendesk Support envoie un e-mail à un utilisateur final pour inclure les réponses via le canal e-mail ou celles initiées par un automatisme ou un déclencheur, au lieu de la simple réponse d’un agent à un ticket.
    • Il est spécifié que par défaut, les notifications automatisées peuvent contenir la correspondance de ticket la plus récente ou d’autres informations configurées pouvant potentiellement inclure des informations de santé protégées.

25 octobre 2023

  • Introduction : Langue d’introduction claire pour les comptes activés HIPAA
  • Section II, Guide et Gather, numéro 1 (restrictions du centre d’aide) : remplacement des restrictions IP par des articles restreints pour plus de clarté

13 avril 2023

  • Section I, Support, numéro 4 (API) : 
    • Ajout d’un lien vers les méthodes d’authentification pour plus de clarté 
    • b) Suppression des recommandations de périodes exactes pour la rotation afin d'être en adéquation avec les meilleures pratiques du secteur et suppression de la référence aux conditions de services de l'API REST (redondance)
    • c) ajouté pour avertir de l’utilisation d’authentification de base pour l’API 
  • Section II, Guide :
    • Numéro 1 (restrictions du centre d’aide) : référence ajoutée aux centres d’aide fermés ou restreints pour plus de fonctionnalités des produits
    • Nombre 5 (@mentions) : Ajout d’une option permettant de désactiver @mentions pour l’alignement avec le produit mettre en avant 
  • Section III : messagerie : 
    • Numéro 1 et 2 (canaux tiers et pièces jointes privées) : ajout des identifiantsde section (i) et (ii) pour plus de clarté
    • Numéro 2 (pièces jointes privées) : ajouté « URL et/ou » pour plus de clarté
    • Numéro 7-10 (authentification de l’utilisateur final, suppression des conversations Answerbot, suppression d’information, analyse des logiciels malveillants) : sections complètes ajoutées pour plus de transparence
  • Section IV, Sunshine Conversations: section entière ajoutée car Sunshine Conversations dans Zendesk Suite fait partie du BAA 
  • Section V, Chat, numéro 3 (Espace de travail d’agent) : corrections de texte
  • Section VIII, applications mobiles, numéros 5-7 (analyse de détection des logiciels malveillants, suppression d’information, authentification de l’utilisateur final) : sections entières ajoutées pour plus de transparence

24 février 2023

  • Section I. Support, numéro 3 : suppression de la distinction entre les restrictions IP de Support et Chat car l’interface est désormais unifiée.
  • Section I. Support, numéro 5 : clarification supplémentaire sur le non-respect de l’exigence 
  • Section I. Support, numéro 7 : « L’abonné ne doit pas » remplacé par « L’abonné ne doit pas ».
  • Section IV. Chat, numéro 2 : précise que toute fonctionnalité d’exportation de données à partir de Chat par e-mail est interdite et pas seulement limitée aux transcriptions et à l’acheminement. 
  • Section III. messagerie : section entière ajoutée pour tenir compte de l’ajout de la fonctionnalité de messagerie Zendesk à la portée du contrat d’associé commercial de Zendesk.

9 juillet 2021

  • Ajoute le point 3. sous la section Chat pour les responsabilités portant sur l’utilisation de Espace de travail d’agent .

21 janvier 2021

  • L’ajout du numéro 1.11 interdit la CSAT sauf si l’abonné assume la responsabilité des données envoyées par e-mail dans le cadre de l’enquête. 
  • Mise en garde au numéro 1.7 afin de permettre aux Abonnés de modifier les autorisations de consultation parce que les utilisateurs ont déjà l'autorisation d'accéder à ces données de leur côté.
  • Tout le document a été mis à jour pour qu’il corresponde au styled’entreprise des liens incorporés dans le texte, par opposition aux URL incorporées (aucun impact sur le contenu de configuration).

Août 2020

  • Ajout d’Explore Enterprise couvrant des capacités accrues de partage des tableaux de bord
  • Suppression de l’interdiction des pièces jointes Chat (les exigences d’authentification de Support sont désormais couvertes)
  • Le fait que l’interdiction des ePHI dans les champs personnalisés s’appliquait spécifiquement à l’utilisation d’Insights et non au niveau mondial
  • Ajout d’une nouvelle section présentant les modules supplémentaires pour les services déployés, où « Conversations annexes » est le premier ajout
  • Diverses modifications de la grammaire/du formatage (elles n’ont pas d’incidence sur le contenu)

13 juillet 2020 :

  • Suppression de l’ambiguïté en ce qui concerne l’utilisation des SMS via le Service par opposition à l’utilisation native des SMS pour l’authentification à deux facteurs au sein du produit. * Pour éviter le moindre doute, les mises en garde pour les données liées à l’ePHI dans la section 10 portant sur les SMS ne s’appliquent pas à l’utilisation de l’authentification à deux facteurs au sein du produit (comme expliqué dans la section 1.a), car une telle fonctionnalité envoie simplement une chaîne numérique pour la vérification de l’identité. »

13 déc. 2019 

  • permet d’outrepasser les restrictions IP des agents quand le cas d’utilisation ne permet pas de telles restrictions tant que l’authentification multifacteur est appliquée pour l’accès des agents.

17 déc. 2019 

  • autorise les commentaires des utilisateurs finaux dans Guide tant que les agents les modèrent et suppriment les ICP.

6 novembre 2019

  • Article mis à jour pour refléter la modification que les abonnés peuvent choisir, à leur seule discrétion, d’abandonner ou de remplacer toute configuration spécifique, tant qu’ils assument la responsabilité d’une telle décision.

Si l’Abonné ne met pas en œuvre et ne se conforme pas à toute configuration particulière répertoriée ci-dessous, ou toute série de configurations requises,

Les risques de l’Abonné et à la seule discrétion de l’Abonné ; et un tel défaut dégage Zendesk et ses employés, agents et affiliés de toute responsabilité en ce qui concerne tout accès non autorisé, ou toute utilisation ou divulgation inappropriée des Données de service de l’Abonné, y compris les Informations de santé numériques protégées, qui résultent d’un tel défaut de la part de l’Abonné. . 

  • Les autres modifications incluent
    • 1. la possibilité d'utiliser les SMS tant que l'Abonné assume toute la responsabilité de s'assurer qu'aucun élément de contexte humain n'est présent dans de telles transmissions.
    • 2. La possibilité d’utiliser des pièces jointes dans Chat tant que l’Abonné assume toute la responsabilité de s’assurer qu’aucune information de contact n’est présente dans ces pièces jointes.

6 mars 2019 

  • a été mise à jour pour inclure les paramètres de Zendesk Explore

17 janvier 2019

  •  mis à jour pour interdire les pièces jointes dans Chat.

Traduction - exonération : cet article a été traduit par un logiciel de traduction automatisée pour permettre une compréhension élémentaire de son contenu. Des efforts raisonnables ont été faits pour fournir une traduction correcte, mais Zendesk ne garantit pas l’exactitude de la traduction.

Si vous avez des questions quant à l’exactitude des informations contenues dans l’article traduit, consultez la version anglaise de l’article, qui représente la version officielle.

Réalisé par Zendesk