Comptes activés HIPAA :

Tous les termes commençant par une lettre majuscule utilisés dans le présent document auront la signification qui leur est donnée dans le Business Associate Agreement (Contrat d’associé commercial) de Zendesk. 

Zendesk et l’Abonné ont conclu un accord d’associé commercial (« BAA ») qui exige que l’Abonné évalue et implémente, comme approprié pour son cas d’utilisation, les configurations suivantes ou les alternatives évaluées par l’Abonné comme essentiellement semblables, pour toutes les configurations compatibles avec la norme HIPAA . compte(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, il 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 Informations de santé protégées, qui en résultent. de tout écart de ce type 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).

I. Les configurations de sécurité minimum suivantes pour Zendesk Support doivent être mises en place et reconnues sur le BAA pour tout compte activé HIPAA :

  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) défini sur Élevé; 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 « Élevée ». 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. Utiliser 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 « Élevé », et activer et appliquer l’authentification à deux facteurs dans 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 motde passe.
  2. Le chiffrement SSL (Secure Socket Layer) pour les comptes activés HIPAA doit rester activé en permanence. Les comptes activés HIPAA qui utilisent un domaine autre que zendesk.com doivent établir et maintenir l’option SSL hébergé..
  3. 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 activé HIPAA de l’Abonné permet les 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 et supprimer des 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 lepré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é utilisera l’approche et le schéma d’authentification OAuth 2.0.. L’Abonné donnera à 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. En utilisant cette approche, l’Abonné (i) utilise un token unique pour chaque service et donne au token 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é changera 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é désactivera 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 facilement interceptables par des parties malveillantes.  
  5. L’abonné doit activer « 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à des tickets de l’utilisateur (sauf si l’Abonné est responsable de s’assurer que ces utilisateurs sont autorisé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é HIPAA *, 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é Enquêtes de satisfaction client (« anciennes enquêtes de satisfaction client ») du Service envoie les Données de service (qui peuvent contenir des ICP) associées au ticket d’ 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é HIPAA *, 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 satisfaction client pour le canal de tickets,
    1. Configurez le corps de l’e-mail de l’automatisme CSAT pour qu’il n’inclue pas d’ePHI potentiel et utilisez le mot-clé {{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 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é.

II. Les configurations de sécurité minimum suivantes pour les services Zendesk Guide et Gather doivent être mises en place et reconnues sur le BAA pour tout compte activé HIPAA :

  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é s’assurera 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 indiqué 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é. Dans ce cas, les abonnés activent la modération du contenu dans le service Zendesk Guide et configurent l’option « Modérer tout le contenu ». Aucun envoi contenant des informations de santé client ne sera approuvé.
  4. L’utilisation par l’Abonné de Modérateurs de la communauté non employés au sein du Service Gather n’est pas autorisée.
  5. L’Abonné comprend que l’utilisation de @mentions pour les membres de la communauté Gather est possible quand les utilisateurs finaux ont 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. Les configurations de sécurité minimum suivantes pour l’utilisation de la messagerie Zendesk doivent être mises en place et prises en compte dans le BAA Zendesk pour tout compte activé HIPAA :

  1. L’Abonné n’activera pas 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 ePHI 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é désactivera 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 Answer Bot) pour les API et les webhooks ou personnalisent l’expérience de messagerie, l’Abonné est responsable de s’assurer que tous les workflows personnalisés et 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. En utilisant cette approche, l’Abonné (i) utilise une clé de connexion JWT unique pour chaque canal d’authentification et donne au token un nom descriptif pour la fonction de conception ; (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) vous reconnaissez 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é changera 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 Answerbot qui ne sont pas transférées à un agent 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 ex. 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 ). 
  9. L’Abonné confirme que les conversations entre les Utilisateurs finaux et Answerbot qui ont été transformées 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é. 

IV. Les configurations de sécurité minimum suivantes pour l’utilisation de Zendesk Sunshine Conversations (à utiliser avec Zendesk Suite) doivent être mises en place et reconnues dans le BAA Zendesk pour tout compte activé HIPAA :

  1. L’Abonné n’activera pas les intégrations de canaux tiers, sauf s’il assume l’entière responsabilité de s’assurer (i) qu’aucun ePHI n’est présent 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é utilisera l’approche et le schéma d’authentification OAuth 2.0 ;. L’Abonné donnera à 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. En utilisant cette approche, l’Abonné (i) utilise un token unique pour chaque service et donne au token 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é changera 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 ePHI 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é désactivera la possibilité pour les Utilisateurs finaux de joindre des fichiers aux Sunshine Conversations et adoptera l’entière responsabilité d’ activer les pièces jointes sécurisées. ou en vous assurant que les agents ne joints pas de fichiers contenant des informations de santé visuelles (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 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. En utilisant cette approche, l’Abonné (i) utilise une clé de connexion JWT unique pour chaque canal d’authentification et donne au token un nom descriptif pour la fonction de conception ; (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) vous reconnaissez 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é changera 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é reconnaît que les interactions entre les Utilisateurs finaux et Answerbot qui ne sont pas transférées à un agent 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) leur suppression via l’API Sunshine Conversations . 
  7. L’Abonné comprend que les conversations entre les Utilisateurs finaux et Answerbot qui se sont transformées en tickets ne peuvent actuellement pas être supprimé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. Les configurations de sécurité minimum suivantes pour le service Zendesk Chat doivent être mises en place et reconnues sur le BAA pour tout compte activé HIPAA :

  1. L’Abonné limite l’accès des Agents au Service Zendesk Chat en s’associant au Service d’assistance Zendesk et en s’authentifiant via le Service d’ Support Zendesk.
  2. L’Abonné n’enverra pas 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 et (c) en ne partageant pas les exportations par e-mail à partir du tableau de bord Chat .
  3. L’Abonné ne doit pas activer « Espace de travail d’agent » sauf s’il est entièrement responsable de s’assurer (i) qu’aucun ePHI 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. Les configurations de sécurité minimum suivantes pour l’utilisation du service Zendesk Explore doivent être mises en place et reconnues sur le BAA pour tout compte activé HIPAA :

L’Abonné comprend que des informations de santé électroniques peuvent apparaître 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 uniquement aux agents qui peuvent accéder à l’ensemble des tickets/appels/chats qui peuvent contenir des ICP dans la ou les instances du Service parentes, et (ii) accordera un tel accès en tenant compte du moins de droits nécessaires pour l’utilisation d’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 connexes sur ces appareils sont de la responsabilité de l’Abonné et (ii) l’Abonné refuse l’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 ePHI 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 des mots 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) que les mots de passe sont remplacé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é HIPAA , 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. Les configurations de sécurité minimum suivantes pour l’utilisation des applications Zendesk mobiles (ou l’accès effectué par des appareils mobiles comme les smartphones ou les tablettes) doivent être mises en place et prises en compte dans le BAA Zendesk pour tout compte activé HIPAA :

  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é sera 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 se verrouiller en cas d’inactivité maximum de 15 minutes.
  5. L’Abonné comprend que l’application mobile Zendesk Support n’affiche pas si les pièces jointes ont été analysées pour rechercher les pièces jointes et qu’elles ont été détectées comme étant des logiciels malveillants, et que les agents doivent se connecter par le biais du navigateur pour consulter ces informations. L’Abonné assumera l’entière responsabilité de mettre en place des procédures et des politiques pour minimiser les risques potentiels.
  6. 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é.
  7. 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. Pour les abonnés qui ont signé le BAA de Zendesk et ont utilisé le service Zendesk Insights par la suite, la prise en charge de ce Service doit être abandonnée à partir du 5 février 2021.   

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

  1. L’Abonné comprend que les fonctionnalités d’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 l’IA).
  2. L’Abonné comprend que si vous utilisez des fonctionnalités d’IA générative optimisées par OpenAI, les sorties OpenAI sont générées par ordinateur, pas 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 une salutation de bot Zendesk 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é IA générative pour les agents / IA générative pour la base de connaissances dans le Centre d’administration activera cette fonctionnalité pour tous les agents de son instance, quels que soient leurs rôles et permissions. 


      

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 et 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é des configurations. décrites dans ce document.

 

Journal des modifications pour les comptes activés HIPAA :

 

10 octobre 2024

  • Ajout de la Section I, Support, numéro 12 (CSAT) et section I, Support, numéro 11 (anciennes CSAT) modifiées pour les nouvelles fonctionnalités. 

7 mars 2024

  • Ajout de la section X, avis au sujet de la fonctionnalité d’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 certaines formulations
  • 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 l’espace de travail d’agent.

21 janvier 2021

  • L’ajout du numéro 1.11 interdit la satisfaction client 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 style d’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.

 

Comptes activés HDS :

Tous les termes commençant par une lettre majuscule utilisés dans le présent document ont la signification qui leur est donnée dans l’article sur les Conditions HDS de l’Accord-cadre d’abonnement de Zendesk (« Affiche sur les conditions HDS »).
Zendesk et l’Abonné ont accepté certaines Conditions générales HDS, qui exigent que l’Abonné mette en œuvre et se conforme aux configurations suivantes pour tous les Comptes activés HDS avant d’introduire des informations de santé personnelles (« Health Information ») dans les Services. Tous les termes commençant par une majuscule utilisés dans le présent document auront la signification qui leur est donnée dans l’illustration des conditions HDS.
Si l’Abonné n’implémente pas et ne se conforme pas à toute configuration particulière répertoriée ci-dessous, ou toute série de configurations requises répertoriées ci-dessous, sera aux 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é personnelles électroniques, qui résultent d’un tel défaut de la part de l’Abonné. .
Les configurations de sécurité minimum suivantes pour Zendesk Support doivent être mises en place et doivent être reconnues dans le document des conditions HDS pour tout compte activé HDS :

 

Les configurations de sécurité minimum suivantes pour Zendesk Support doivent être mises en place et doivent être reconnues dans le document des conditions HDS pour tout compte activé HDS :

  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) défini sur Élevé; 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 « Élevée ». 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. Utiliser 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 « Élevé », et activer et appliquer l’authentification à deux facteurs dans 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 motde passe.
  2. Le chiffrement SSL (Secure Socket Layer) sur les comptes activés HDS doit rester activé en permanence. Les comptes activés HDS qui utilisent un domaine autre que zendesk.com doivent établir et maintenir l’option SSL hébergé..
  3. L’accès des agents doit être limité à des adresses IP spécifiques sous le contrôle de l’abonné à Support et Chat.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 activé HDS de l’Abonné permet les 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 des Données de service et informations de santé protégées via cet accès et/ou ces intégrations. 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é utilisera l’approche et le schéma d’authentification OAuth 2.0.. L’Abonné donnera à 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. En utilisant cette approche, l’Abonné (i) utilise un token unique pour chaque service et donne au token 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é changera le token associé immédiatement ; et (iv) au minimum, faire pivoter le token une fois tous les cent quatre-vingt (180) jours.  L’Abonné doit suivre les conditions de service de l’API REST du Service. 
  5. L’abonné doit activer « Demander une authentification pour télécharger » afin d’exiger une authentification pour accéder aux pièces jointes.
  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 de toute une organisation, ni modifier le paramètre par défaut au-delà des tickets de l’utilisateur (sauf si l’Abonné est responsable de s’assurer que ces utilisateurs sont approuvés par l’Abonné pour l’accès à toutes les données suivantes).
  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é confirme que Zendesk Support envoie un e-mail à un utilisateur final quand l’agent de l’Abonné répond à un ticket Zendesk Support .  Par défaut, cet e-mail contient tous les messages que l’agent a envoyés à l’utilisateur final et peut potentiellement inclure des informations de santé protégées. Pour mieux protéger l’Abonné, son instance Zendesk Support doit être configurée pour seulement prévenir l’utilisateur final qu’un agent a réponduet pour exiger que l’utilisateur final s’authentifie dans Zendesk Support pour voir le contenu du 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é HDS*, ou
    2. si elles sont utilisées, l’Abonné assume la responsabilité de l’utilisation de cette fonctionnalité.

* Afin d’é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é.

Les configurations de sécurité minimum suivantes pour les services Zendesk Guide et Gather doivent être mises en place et doivent être reconnues dans l’illustration des conditions HDS pour tout compte activé HDS :

  1. L’Abonné reconnaît que les Services Guide et Gather sont publics par nature (dans le cas où les restrictions IP ne s’appliquent pas aux centres d’aide « internes ») et par conséquent, l’Abonné doit s’assurer que les articles du Zendesk Guide ou du Service Gather n’incluent pas les informations de santé protégées, que ce soit par le biais du de cet article, ou sous forme de pièce jointe à l’article, ou d’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.
  3. L’utilisation par l’Abonné de Modérateurs de la communauté non employés au sein du Service Gather n’est pas autorisée.

Les configurations de sécurité minimum suivantes pour le service Zendesk Chat doivent être mises en place et doivent être prises en compte dans le document des conditions HDS pour tout compte activé HDS :

  1. L’Abonné limite l’accès des Agents au Service Zendesk Chat en s’associant au Service d’assistance Zendesk et en s’authentifiant via le Service d’ Support Zendesk.
  2. L’abonné doit désactiver l’acheminement e-mail.
  3. L’Abonné ne doit pas activer les « Espaces de travail d’agent » sauf s’il est entièrement responsable de s’assurer (i) qu’aucun ePHI 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.

Les configurations de sécurité minimum suivantes pour l’utilisation du service Zendesk Explore doivent être mises en place et doivent être reconnues dans l’illustration des conditions HDS pour tout compte activé HDS :

L’Abonné comprend que des informations de santé électroniques peuvent apparaître 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 uniquement aux agents qui peuvent accéder à l’ensemble des tickets/appels/chats qui peuvent contenir des ICP dans la ou les instances du Service parentes, et (ii) accordera un tel accès en tenant compte du moins de droits nécessaires pour l’utilisation d’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 connexes sur ces appareils sont de la responsabilité de l’Abonné et (ii) l’Abonné refuse l’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 ePHI 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 des mots 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) que les mots de passe sont remplacés sans délai injustifié dès le soupçon ou la confirmation de l’exposition

Les configurations de sécurité minimum suivantes pour l’utilisation des applications Zendesk mobiles (ou l’accès par des appareils mobiles comme les smartphones ou les tablettes) doivent être mises en place et doivent être prises en compte dans le Présentation des conditions HDS pour tout compte activé HDS :

  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é sera 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 se verrouiller en cas d’inactivité maximum de 15 minutes.

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 » 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 les conversations). Si l’Abonné choisit d’utiliser cette fonctionnalité dans un Compte activé HDS, 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 ».

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é 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é des configurations. décrites dans ce document.

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