Recherches récentes
Pas de recherche récente

Craig Lima
Adhésion le 14 avr. 2021
·
Dernière activité le 02 janv. 2025
Suivis
0
Abonnés
0
Activité totale
11
Votes
0
Abonnements
3
APERÇU DES ACTIVITÉS
BADGES
ARTICLES
PUBLICATIONS
COMMENTAIRES DE LA COMMUNAUTÉ
COMMENTAIRES SUR L’ARTICLE
APERÇU DES ACTIVITÉS
Dernière activité effectuée par Craig Lima
Craig Lima a ajouté un commentaire,
Dec 27th, 2024, added section XII to incorporate Workforce Management “WFM” into HIPAA BAA scope
Afficher le commentaire · Publication le 02 janv. 2025 · Craig Lima
0
Abonnés
0
Votes
0
Commentaire
Craig Lima a ajouté un commentaire,
Dec 16th 2024
1. Added section XI to incorporate Zendesk QA into scope
2. Changed various instances of "Answer Bot" to "AI Agents" to denote naming convention changes and broader scope.
3. Changed various instances of “must” and “shall” to “should” to denote best practices philosophy of configs, as well as to reinforce the Subscriber responsibility for interpretation of HIPAA compliance vis-a-vis Admin / Owner configurations and use case implementation https://support.zendesk.com/hc/en-us/articles/4408833510938-The-Zendesk-Shared-Responsibility-Model
Afficher le commentaire · Publication le 17 déc. 2024 · Craig Lima
0
Abonnés
0
Votes
0
Commentaire
Craig Lima a créé un article,
Pays/régions AWS dans lesquelles Zendesk héberge les Données de service des abonnés
Actuellement, nous hébergeons les Données de service des abonnés dans les pays/régions AWS suivantes :
- USA Est (Virginie du Nord)
- USA Est (Ohio)
- USA Ouest (Oregon)
- EEE (Irlande)
- EEE (Francfort)
- R-U (Londres)
- Asie-Pacifique (Tokyo)
- Asie-Pacifique (Osaka)
- Asie-Pacifique (Sydney)
Accords sur l’emplacement des données
Notez que Zendesk ne s’engage sur l’emplacement de l’hébergement des Données de service d’un abonné que si cet abonné a acheté notre module supplémentaire Emplacement du centre de données (que le module supplémentaire Emplacement du centre de données ait été acheté de façon autonome ou qu’il soit inclus à l’édition de service achetée). Consultez la Politique d’hébergement régional des données ici pour prendre connaissance des exceptions à cet engagement.
Afin d’équilibrer la demande, d’améliorer les performances et de fournir le meilleur service, nous pouvons transférer les données du compte entre les régions sans préavis. Si un compte a acheté le module supplémentaire de localisation des données, nous veillerons à ce que les déplacements régionaux restent dans le pays ou les limites légales requis.
Obtention de l’adresse physique de l’hébergement de vos Données de service
Sur demande, nous pouvons communiquer la région Amazon Web Services (AWS) (une zone générale qui peut être décrite par AWS comme un pays, une région géographique à l’intérieur d’un pays, un état et/ou une ville) où nous hébergeons vos Données de service.
Nous ne sommes pas en mesure de donner les adresses physiques exactes où vos données de service sont hébergées en raison du fonctionnement technique d’AWS. Cela dépend de l’architecture d’AWS. AWS a des régions dans le monde entier. Au sein de ces régions, il existe un concept de « zones de disponibilité ». Lors de la création d’un actif dans AWS, celui-ci est placé dans une ou plusieurs zones de disponibilité au sein d’une région donnée. Indépendamment du choix du propriétaire de l’actif de répliquer les données au sein d’une région ou entre les régions, AWS lui-même peut répliquer les données au sein de la région dans d’autres zones de disponibilité. Ainsi, les Données de service des abonnés Zendesk existent dans plusieurs infrastructures d’une région donnée. En outre, pour des raisons de sécurité, AWS n’autorise pas officiellement la communication de l’emplacement spécifique des bâtiments de ses centres de données ou des infrastructures associées.
Si vous avez besoin de savoir dans quelle région AWS votre sous-domaine Zendesk est hébergé, contactez l’assistance client Zendesk.
Journal des modifications :
Avril 2024 - Ajout d’une limitation pour Gestion des collaborateurs Zendesk (Tymeshift) et Zendesk QA (Klaus)
Juillet 2024 - Ajout d’une limitation pour Ultimate
Juillet 2024 - Ajout de deux nouveaux emplacements d’hébergement : R-U (Londres), Asie-Pacifique (Osaka)
Modification le 26 juil. 2024 · Craig Lima
5
Abonnés
1
vote
0
Commentaire
Craig Lima a créé un article,
Le modèle de responsabilité partagée de Zendesk
Zendesk fournit une plateforme de service client capable d’évoluer rapidement et configurable à l’extrême, et beaucoup des plus grandes entreprises au monde, travaillant dans tous les secteurs, nous font confiance. En aidant nos clients à exploiter notre plateforme cloud pour leurs besoins de service client, nous leur permettons de réduire leurs frais, d’évoluer pour pouvoir toujours répondre à la demande et d’offrir à leurs clients des interactions remarquablement simples.
En passant au cloud, les entreprises bénéficient des avantages mentionnés ci-dessus, mais il peut y avoir une certaine ambiguïté : quelle partie est responsable de quoi ? Pour que les choses soient claires et simples, nous avons créé un modèle de responsabilité partagée, que nous vous présentons ci-dessous. C’est un cadre qui clarifie quelle partie est responsable de quels contrôles pour la sécurité et la confidentialité de vos données. Que vous soyez un administrateur consciencieux, un responsable de la sécurité, de la conformité ou de la confidentialité ou que vous soyez chargé de configurer les contrôles appropriés pour l’utilisation des Services Zendesk dans votre environnement, vous devriez y trouver toutes les précisions dont vous avez besoin.
En bref, « Zendesk est responsable de la sécurité du Service lui-même et vous êtes responsable de la sécurité de vos instances particulières du Service ».
- Contrôles d’accès et hygiène des données
- Intégrations
- Données, confidentialité, conformité et considérations réglementaires
- Surveillance
- Maintenance
- Incidents de sécurité (rôles et responsabilités)
- Liens utiles
- Journal des modifications
Remarque – Notez que les termes qui commencent pas une lettre majuscule ont le sens qui leur est affecté dans l’Accord sur les services principaux de Zendesk (ASP).
I. Contrôles d’accès et hygiène
Le contrôle de l’accès aux systèmes sensibles et aux données qu’ils contiennent est au cœur des principes de sécurité.
-
L’Abonné est responsable de tous les contrôles d’accès à ses instances du service, notamment :
- Gérer le provisioning, la modification, l’hygiène continue, le maintien de la précision des droits et le deprovisioning de tous les utilisateurs, y compris les utilisateurs finaux et les agents (qu’ils soient sur site, à distance ou fassent partie du personnel d’une tierce partie)
- Choisir et configurer la méthode d’authentification pour accéder au service parmi les offres prises en charge (qui peuvent inclure mots de passe, authentification multifacteur, connexion unique, etc.)
- Configurer et surveiller divers aspects du traitement des sessions comme les déconnexions, les appareils connectés, etc.
- Autoriser ou interdire l’accès à son instance Support à notre personnel d’assistance
- Configurer l’accès aux services de l’API REST de Zendesk (le cas échéant, notamment les intégrations, l’utilisation du Service Zendesk Sunshine, etc.) et en comprendre les implications
- Configurer les restrictions IP de produit prises en charge, s’il le souhaite
- Considérer les autres contrôles d’accès n’ayant pas trait aux produits, par exemple, les appareils que les agents ont le droit d’utiliser pour accéder à ses instances, ainsi que tous les contrôles physiques, logiques ou réglementaires applicables pour ses utilisateurs ou appareils autorisés
-
Zendesk est responsable de tous les contrôles d’accès aux systèmes sous-jacents du service, notamment :
- Maintenir des politiques et des procédures pour assurer le provisioning, la modification, l’hygiène continue, le maintien de la précision des droits et le deprovisioning de tous les utilisateurs (qu’ils soient sur site, à distance ou fassent partie du personnel d’une tierce partie) en toute sécurité
- Appliquer le contrôle d’accès en fonction du rôle (Role Based Access Control ou RBAC), le principe du moindre privilège (Principle of Least Privilege ou PLP), la sécurité via des identifiants appropriés, y compris l’authentification multifacteur pour l’accès de tous les employés et tous les sous-traitants aux systèmes et applications critiques contenant des Données de service de l’Abonné
- Effectuer des vérifications ponctuelles de ce qui précède
II. Intégrations
L’utilisation de tierces parties peut considérablement améliorer l’efficacité, mais peut aussi nuire à la sécurité.
-
L’Abonné est responsable de réfléchir aux implications en matière de sécurité de l’utilisation de toutes les intégrations tierces qu’il choisit d’utiliser avec le Service, notamment :
- Les intégrations via l’API et/ou le SDK
- Les intégrations via l’installation d’applications Marketplace ou l’activation de canaux tiers
- Les intégrations avec toute partie tierce qui aide l’Abonné en lui fournissant du personnel, des outils, du code ou entretenant directement les instances Zendesk
-
Zendesk est responsable de faire attention d’intégrer des parties tierces dignes de confiance au Service, notamment :
- Contrôler et exercer une diligence raisonnable continue pour tous les Sous-traitants
- Intégrer les acquisitions au Service de façon sécurisée
- S’assurer que tous les partenariats produits et/ou intégrations du Service avec des tierces parties respectent les considérations appropriées en matière de sécurité
III. Données, confidentialité, conformité et considérations réglementaires
Il est indispensable de tenir compte des données utilisées, de leur traitement approprié, de tout cadre réglementaire pertinent et de l’importance des garanties données par des tiers.
-
L’Abonné est responsable de traiter de façon appropriée les données qu’il obtient et utilise, notamment :
- Comprendre les types de données pour son cas d’utilisation spécifique
- Traiter ces données conformément aux politiques de classification et de confidentialité des données de son entreprise, aux lois applicables aux données elles-mêmes, aux utilisateurs qui les fournissent, au secteur de l’Abonné et à toute juridiction pertinente
- Choisir les canaux qu’il autorise pour la communication avec ses instances du Service
- Assurer la maintenance des instances et des Données de service conformément à tous les cadres de conformité, juridiques ou réglementaires applicables qui peuvent concerner le secteur, les utilisateurs ou le cas d’utilisation de l’Abonné
- Fournir à Zendesk les certificats TLS nécessaires s’il souhaite un mappage d’hôte avec un domaine parent non Zendesk à des fins de cryptage du trafic vers et depuis l’interface et l’API Zendesk
- Comprendre quand il est possible que les données ne soient pas cryptées en transit et traiter ces canaux ou protocoles en conséquence (principalement l’e-mail, les SMS ou les intégrations tierces réalisées à l’entière discrétion de l’Abonné qui ne prennent pas le cryptage en charge)
- S’assurer que les types de données utilisés dans l’instance de l’Abonné respectent les Conditions générales de l’Accord sur les services principaux de Zendesk (pour en savoir plus, consultez l’Accord en question)
- S’assurer que le niveau de disponibilité et le plan de reprise d’activité choisis par l’Abonné sont conformes aux politiques et aux réglementations que doit respecter l’Abonné
-
Zendesk est responsable de :
- Protéger de façon appropriée toutes les Données de service de toute divulgation au niveau du Service (c.-à-d. infrastructure ou code)
- Crypter les données en transit vers ou depuis l’interface ou l’API Zendesk sur les réseaux publics
- Crypter toutes les données au repos
- Fournir à l’Abonné des informations sur les données recueillies par les cookies des produits ainsi que par l’utilisation par défaut des services
- Décrire avec précision l’utilisation que Zendesk fait des Données de service, notamment les Données à caractère personnel, de façon anonymisée ou non, pour fournir ses Services ou à d’autres fins
- Fournir à l’Abonné des outils et des fonctionnalités qui l’aident à remplir ses propres obligations en matière de données à caractère personnel ou données réglementées
- Respecter les lois et cadres réglementaires applicables pertinents pour nos offres de service et les emplacements où nous les proposons
- Obtenir et fournir les assurances de conformité des tierces parties indépendantes pertinentes pour nos offres de service
IV. Surveillance
Pour assurer une sécurité adéquate, il faut connaître et comprendre les processus et les activités.
-
L’Abonné est responsable de surveiller toutes les activités dans ses instances du Service, notamment :
- Surveiller les activités des utilisateurs (via les consultations de l’interface ou les journaux API)
- Exercer une diligence raisonnable pour les communications avec des inconnus ou le contenu non approuvé provenant du Service
- Tenir des journaux des données extraites du Service conformément à toutes les réglementations applicables
-
Zendesk est responsable de surveiller les processus et les activités du Service lui-même, notamment :
- Les activités et les accès avec droits au sein du réseau de production
- Le trafic entrant afin de signaler ou de bloquer les envois ou les adresses IP non approuvés
- La disponibilité du Service
- Les comportements anormaux dans les ressources du réseau de l’entreprise ou de production
- La sécurité du code, de l’infrastructure, du trafic et du personnel pertinent (employés ou sous-traitants)
V. Maintenance
La mise à jour et la correction des systèmes et du code permettent de prévenir de nombreux problèmes de sécurité.
-
L’Abonné est responsable d’assurer la maintenance et de réparer tous les systèmes ou le code au-delà des limites architecturales et/ou contractuelles de Zendesk*, notamment :
- Sa propre infrastructure, notamment les points de terminaison des employés, les réseaux, l’infrastructure personnalisée ou les couches intergicielles tierces qu’il utilise pour accéder au ou aux Services Zendesk et/ou traiter ses Données de service avant l’entrée ou la sortie des systèmes Zendesk
- Son propre code non standard utilisé pour fournir des fonctionnalités supplémentaires au ou aux Services Zendesk, notamment le code développé en interne ou par un tiers que l’Abonné a développé lui-même ou acheté pour l’utiliser avec les services Zendesk. Cela inclut également le code personnalisé développé par les Services professionnels Zendesk à la demande de l’Abonné, à condition que la responsabilité dudit code et de sa maintenance ait été transférée à l’Abonné dans le cadre de l’accord personnalisé.
-
Zendesk est responsable d’assurer la maintenance et de réparer tous les systèmes ou le code qui se trouvent dans ses limites architecturales et/ou contractuelles, notamment :
- Sa propre infrastructure gérée logiquement au sein des installations du fournisseur d’hébergement utilisées pour fournir les Services, y compris les systèmes d’exploitation, l’infrastructure de sécurité et les systèmes sous son contrôle direct, les systèmes de conteneurs et d’orchestration, etc.
- Sa propre infrastructure gérée physiquement et/ou logiquement au sein de l’environnement d’entreprise Zendesk, comme les points de terminaison des employés, l’infrastructure du réseau d’entreprise, etc.
- Les bases de code propriétaires qui permettent les Services Zendesk
* Notez que bien que les applications Marketplace s’exécutent au sein des limites architecturales de Zendesk, elles ne sont pas couvertes par l’Accord sur les services principaux de Zendesk : elles sont couvertes par des modalités spécifiques entre l’Abonné et les développeurs des applications comme l’indiquent les conditions d’utilisation des applications de notre Marketplace. Les développeurs tiers des applications Marketplace sont responsables de leur maintenance.
VI. Incidents de sécurité
Malgré tous les efforts déployés, il peut arriver que des incidents surviennent. La manière dont vous identifiez, réagissez et récupérez après un incident de sécurité est essentielle pour atténuer les problèmes et conserver la confiance des clients. Cette section explique les rôles et les responsabilités de chaque partie pendant les incidents de sécurité.
- L’Abonné est responsable de tous les incidents ou violations de sécurité au sein de ses instances, qui ne sont pas dus à des vulnérabilités ou des incidents au sein du service lui-même, notamment :
- Enquêter sur et remédier à toute infraction présumée ou réelle au sein de son instance due à (i) un contrôle d’accès ou une hygiène des données insuffisant (y compris l’utilisation d’identifiants faibles ou exploitables), (ii) une surveillance insuffisante des activités des utilisateurs, (iii) une absence de diligence raisonnable pour les communications ou le contenu non approuvé dérivé d’interactions avec les utilisateurs ou (iv) tout incident ou toute violation dû à une intégration avec une tierce partie, quand l’Abonné a réalisé cette intégration à son entière discrétion
- Envoyer les notifications obligatoires aux organismes gouvernementaux et aux forces de l’ordre ou aux utilisateurs finaux pour les prévenir des violations dues aux actions de l’Abonné, des tierces parties intégrées ou ayant un lien avec les notifications de violation des Données de service au sujet de l’instance de l’Abonné reçues de Zendesk
-
Zendesk est responsable de contrôler les enquêtes sur les incidents de sécurité et de notifier les abonnés concernés de toute violation des Données de service ayant eu lieu via le service lui-même, notamment :
- Avoir une politique de réponse aux incidents de sécurité documentée et des membres du personnel avec des rôles et des responsabilités de sécurité pertinents
- Enquêter sur toute activité anormale
- Contenir toute violation des Données de service confirmée
- Prévenir les abonnés concernés, ainsi que les organismes gouvernementaux et les forces de l’ordre si la loi l’exige
- S’assurer que des processus de sauvegarde et de reprise d’activité solides sont mis en place et testés
VII. Liens utiles
Un service client sécurisé avec la sécurité Zendesk
Meilleures pratiques de sécurité de Zendesk
Contrôles d’accès et hygiène des données
Gestion de la sécurité et de l’accès des utilisateurs dans Zendesk Support (liens agrégés)
Authentification des utilisateurs dans Chat
Accorder à Zendesk un accès temporaire à votre compte
Intégrations
Applications de Zendesk Marketplace
Sous-traitants Zendesk Connect
Données, confidentialité, conformité et considérations réglementaires
Politiques portant sur les cookies au sein des produits Zendesk
Accord sur les services principaux
Protection des données et de la confidentialité Zendesk
Surveillance
Journal des audits des modifications des instances Support (Interface / API)
API Journal des audits des événements des tickets Support
Interface de l’historique des chats
API Exportations incrémentales et API en temps réel Chat
API Objets personnalisés, événements et profils Sunshine
API en temps réel Sell/Firehose API
Si vous avez d’autres questions, contactez-nous en envoyant un message à security@zendesk.com
VIII. Journal des modifications
16 juin 2023
- Ajout d’un journal des modifications
- Ajout à la Section V - Maintenance
- Clarification des détails des incidents causés par l’utilisation d’identifiants faibles ou exploitables utilisés par les Abonnés et/ou leurs utilisateurs finaux comme relevant de la responsabilité de l’Abonné dans la section VI - Incidents de sécurité.
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.
Modification le 08 mai 2024 · Craig Lima
0
Abonnés
2
Votes
0
Commentaire
Craig Lima a créé un article,
Il faut beaucoup de confiance pour placer vos données dans le cloud. En retour, vous voulez savoir que les partenaires avec qui vous partagez ces informations placent la sécurité au cœur de leurs priorités. Nos Abonnés utilisent divers frameworks et normes pour gérer les informations sensibles, nous avons donc mis en œuvre les benchmarks ISO (Organization for Standardization) suivants dans l’ensemble de nos services afin d’assurer la sécurité et la conformité de vos données.
ISO 27001
Les normes ISO/CEI 27000 fournissent une série de frameworks pour aider les organisations à référencer leur traitement des données. La plus courante de ces normes, ISO/CEI 27001, fournit les exigences pour la sécurité des systèmes d’information (ISMS) et l’assurance que les entreprises qui passent un audit respectent ces exigences.
ISO 27018
La norme ISO/CEI 27018 fournit des directives basées sur la norme ISO/CEI 27002 et est axée sur la protection des informations personnelles identifiables (PII) pour les prestataires de services cloud comme Zendesk.
ISO 27701
La norme ISO/CEI 27701:2019 spécifie les exigences et les directives pour la mise en place, la mise en œuvre, la maintenance et l’amélioration continue d’un système de gestion des informations de confidentialité (PIMS). Elle complète les normes ISO/CEI 27001 et ISO/CEI 27002 pour la gestion de la confidentialité au sein d’une organisation. Cela crée un cadre pour la gestion des données personnelles utilisées par les responsables du traitement et du traitement des données, en associant les contrôles de sécurité et de confidentialité.
Services et processus Zendesk concernés par ces audits
La portée des certifications ISO/CEI 27001:2013, ISO/CEI 27018:2014 et ISO/CEI 27701:2019 est limitée par l’infrastructure réseau mondiale de Zendesk Inc. et les produits et services correspondants, notamment la gestion du développement, des opérations la maintenance et la livraison de Support, Guide, Chat, Connect, Inbox et Explore qui sont gérés de façon centralisée au siège de Zendesk et pris en charge par les bureaux concernés suivants : San Francisco, CA et Madison, Wisconsin (États-Unis d’Amérique), Copenhague (Danemark), Dublin (Irlande), Manille (Philippines), Melbourne (Australie), Montpellier (France) et Singapour.
En outre, un fournisseur de centre de données IaaS (infrastructure en tant que service) est utilisé pour protéger l’infrastructure qui exécute tous les services proposés dans l’infrastructure IaaS .IasS. Les contrôles de sécurité Zendesk pour la gestion de l’environnement IaaS sont inclus dans le portée de ce certificat, à l’exception des contrôles physiques et environnementaux.
Notre sous-traitant pour l’hébergement des services est actuellement AWS, qui a plusieurs certifications ISO. Pour en savoir plus, consultez la page de conformité ici.
Ce que cela signifie pour les clients
En interne, nous réalisons ces audits indépendants pour nous assurer que nos fonctions de gestion de la sécurité et de confidentialité sont conformes aux principales normes du secteur. Pour nos clients, ces normes de conformité validées en externe confirment que nous respectons nos obligations en termes de traitement des données. En outre, la norme ISO/CEI 27701 exige que les organisations déclarent les lois et réglementations applicables dans le cadre de ses critères d’audit, ce qui permet à cette norme de se conformer à des exigences telles que le Règlement général sur la protection des données (RGPD), le California Consumer Privacy Act (CCPA) et autres législations. .
Tous les clients qui utilisent des produits concernés bénéficient de cette protection
Ces certifications s’appliquent à nos services répertoriés ci-dessus. Vous n’avez pas à payer de frais supplémentaires ni à configurer votre instance pour être protégé par ces certifications.
Certifications ISO 27001, ISO 27018 et ISO 27701 de Zendesk par rapport aux certifications des clients
Nos certifications ISO 27001, ISO 27018 et ISO 27701 couvrent les processus de gestion de la sécurité et de la confidentialité pour une portée spécifique des services Zendesk. Si vous souhaitez obtenir l’une de ces certifications alors que vous exploitez une partie de votre service en utilisant Zendesk, notez que vous ne serez pas automatiquement certifié par association. Cependant, nos certifications peuvent vous aider à obtenir ces certifications pour votre instance.
Obtention des certifications ISO de Zendesk
Vous pouvez accéder gratuitement à nos certificats ISO à tout moment (sans accord de confidentialité) en remplissant le formulaire suivant : https://www.zendesk.com/product/zendesk-security/#anchor-security-resources
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.
Modification le 08 mai 2024 · Craig Lima
3
Abonnés
2
Votes
0
Commentaire
Craig Lima a créé un article,
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:
-
Authentification sécurisée de l’agent en utilisant l’une des deux méthodes suivantes :
- 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
- 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.
- Tous les choix d’authentification utilisant la connexion unique comme méthode d’authentification doivent désactiver l’accès par mot de passe.
- 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é..
- 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.
-
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é :
- 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.
- 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é.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
-
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 :
- ne pas être utilisé avec un compte activé Zendesk Chat*, ou
- si elle est utilisée, l’Abonné assume toute la responsabilité de l’utilisation de cette fonctionnalité
- 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 :
- ne pas être utilisé avec un compte activé Zendesk Chat*, ou
- si elle est utilisée, l’Abonné assume toute la responsabilité de l’utilisation de cette fonctionnalité
-
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,
- 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
- 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 :
- 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.
- 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).
- 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.
- 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).
- 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 :
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
-
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.
- 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é.
- L’abonné doit utiliser l’attribut JWT d’expiration et définir sa valeur sur 15 minutes maximum.
- 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 ).
- 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.
- 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é.
- 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 :
- 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.
-
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é :
- 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.
- 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é.
- 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.
- 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é.
- 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.
-
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.
- 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é.
- L’abonné doit utiliser l’attribut JWT d’expiration et définir sa valeur sur 15 minutes maximum.
- 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 .
- 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.
- 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.).
- 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:
- 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 .
- 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.
- 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.
- 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.
- 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 :
- 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.
- exploiter les restrictions IP
- 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 ») :
- 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) :
- L’utilisation doit inclure le chiffrement au niveau de l’appareil
- L’accès biométrique ou PIN configuré sur le paramètre d’appareil le plus élevé autorisé doit être utilisé.
- Les notifications permettant l’affichage des commentaires de tickets sur les écrans de verrouillage de ces appareils doivent être désactivées.
- Les verrous d’inactivité de l’écran doivent être activés et configurés pour ne pas dépasser 15 minutes d’inactivité maximum.
- 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é.
- 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) :
- 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 ).
- 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.
- 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.
- 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
- 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 ).
- 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.
- 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)
- 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.
- 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.
- 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.
- 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" :
- L’Abonné confirme que
- 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).
- 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.
- 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.
Modification le 28 janv. 2025 · Craig Lima
0
Abonnés
1
vote
0
Commentaire
Craig Lima a ajouté un commentaire,
July 9th 2021 edit:
1. Adds point 3. under Chat section for responsibilities around Agent Workspace usage.
Afficher le commentaire · Publication le 09 juil. 2021 · Craig Lima
0
Abonnés
0
Votes
0
Commentaire
Craig Lima a ajouté un commentaire,
January 21st, 2021
Addition of number 1.11 disallows CSAT unless Subscriber assumes responsibility of data sent via email as part of the survey.
Caveat in number 1.7 to make allowances for Subscribers altering viewing permissions due to users already having approval to access such data on their ends.
Updated entire document to match company stle of embedded links within text as opposed to inline URLs (no impact to configuration content).
Afficher le commentaire · Publication le 21 janv. 2021 · Craig Lima
0
Abonnés
0
Votes
0
Commentaire