Cuentas activadas HIPAA y HDS (colectivamente "Cuentas activadas para atención médica"):

Todos los términos escritos en mayúsculas que se utilicen en este documento tendrán el significado que se les asigne en el Acuerdo de socio comercial ("BAA") de Zendesk o en la Prueba de términos HDS del Acuerdo de cliente de Zendesk ("Prueba HDS"), según corresponda al tipo de cuenta (colectivamente, "Acuerdo de atención médica").

Para los propósitos de las cuentas activadas por HIPAA, “PHI” significa “Información médica protegida”, y para los propósitos de las cuentas activadas por HDS, “PHI” significa “Información médica personal”.

Zendesk y el Suscriptor han suscrito un Acuerdo de atención médica que recomienda al Suscriptor que evalúe e implemente, según corresponda para su caso de uso, las siguientes configuraciones, o alternativas evaluadas por el Suscriptor para abordar de otra manera sus requisitos de cumplimiento según la ley aplicable, para cualquiera y todas las Cuentas activadas para atención médica antes de introducir cualquier PHI en los Servicios.

Si el Suscriptor decide, a su entera discreción, renunciar a implementar cualquiera de las configuraciones recomendadas que se enumeran a continuación, el Suscriptor asumirá la responsabilidad exclusiva por cualquier acceso no autorizado a los Datos de Servicio del Suscriptor, incluido cualquier PHI, o por el uso inadecuado de la divulgación que resulte de tales desviaciones de las configuraciones recomendadas por el Suscriptor.

El Suscriptor debe haber comprado planes de Servicio al nivel correspondiente y tener los complementos asociados necesarios (consulte a su representante de ventas si no está seguro).

Si el Suscriptor tiene una Cuenta activada para HDS, el Suscriptor debe hacer clic en el botón “Seguir” en la Política de subprocesadores de Zendesk para recibir notificaciones de cualquier cambio en los subprocesadores utilizados para proporcionar los Servicios.

Se deben establecer las siguientes configuraciones de seguridad mínimas para los servicios de Zendesk y se reconocen en el Acuerdo de atención médica para cualquier cuenta activada para la atención médica

I. Zendesk Support:

  1. Autenticación segura de agentes a través de uno de los dos métodos siguientes:
    1. Emplear Zendesk Support nativo con configuración de contraseña: i) establecido en “Recomendado”; o (ii) personalizado por el Suscriptor de manera que establezca requisitos no menos seguros que los establecidos bajo la configuración “Recomendado”. Además, bajo la opción en esta subsección, el Suscriptor también debe activar y hacer cumplir la Autenticación de dos factores ("2FA") de forma nativa dentro del Servicio; y, los controles administrativos que permiten a los administradores establecer contraseñas para los Usuarios finales deben desactivarse; o
    2. Utilizar una solución externa de inicio de sesión único ("SSO") con requisitos establecidos no menos seguros que los establecidos bajo la configuración de contraseña "Recomendada" de Zendesk y activar y hacer cumplir la autenticación de dos factores dentro de la solución seleccionada para el acceso de todos los agentes. Los controles administrativos que permiten a los administradores establecer contraseñas para los usuarios finales deben desactivarse.
    3. Todas las opciones de autenticación que utilicen SSO como método de autenticación deben desactivar el acceso con contraseña.
  2. La encriptación de Secure Socket Layer ("SSL") en las cuentas activadas para atención médica debe permanecer activada en todo momento. Las cuentas activadas para atención médica que utilicen un dominio que no sea zendesk.com deberán establecer y mantener SSL alojado.
  3. Si es posible, el acceso de los agentes debe restringirse a direcciones IP específicas bajo el control del Suscriptor, a menos que el Suscriptor active la autenticación de varios factores para los agentes como se describe anteriormente en los requisitos 1.a o 1.b (ya sea de forma nativa dentro del Servicio o dentro del entorno del Suscriptor junto con el SSO Enterprise).  Para evitar cualquier duda, “Acceso del agente” denota el acceso otorgado a un agente humano que accede a los Datos de servicio a través de la Interfaz de usuario (“UI”).
  4. En la medida en que la Cuenta activada para atención médica del Suscriptor permita llamadas a las Interfaces de programación de aplicaciones ("API") de Zendesk, el Suscriptor asumirá toda la responsabilidad de comprender las implicaciones de seguridad de todas las Entidades del Suscriptor o de terceros autorizadas a crear, acceder, modificar o borrar Datos de Servicio y PHI a través de dicho acceso y/o integraciones. Para acceder a dicha API, Zendesk ofrece varios métodos como se describe aquí, y el Suscriptor implementará las siguientes mejores prácticas de seguridad en función del modelo de API utilizado:
    1. Enfoque OAuth 2.0.  Este modelo proporciona las capacidades de seguridad más detalladas, pero requiere que un usuario final acepte los derechos.  Siempre que sea posible, el Suscriptor debe utilizar el método OAuth 2.0 y el esquema de autenticación. El Suscriptor debe asignar a cada cliente OAuth un Nombre de Cliente descriptivo y único y una función de designación de Identificador Único. Los permisos otorgados para cada token OAuth deben permitir el mínimo privilegio necesario para realizar las tareas requeridas.
    2. Enfoque de token de API REST.  Este modelo es el más amplio y permite que un token de API utilice toda la funcionalidad del modelo de API. Por su naturaleza, proporciona el acceso y las capacidades más amplios y debe usarse con precaución. Cuando se utiliza este método, el Suscriptor debe (i) usar un token único para cada servicio y asignar al token una función de designación de nombre descriptivo; (ii) no compartir tokens de API con ningún tercero a menos que sea razonablemente necesario y de acuerdo con métodos de transmisión que están encriptados de principio a fin; (iii) reconocer que si el token de API se comparte con un tercero, y el Suscriptor es informado de una filtración de datos de terceros, el Suscriptor debe rotar el token asociado de inmediato; y (iv) como mínimo, rotar el token con frecuencia de acuerdo con las políticas de organización del Suscriptor.
    3. Si es posible, el Suscriptor debe desactivar el acceso con contraseña a la API, ya que esta estrategia envía las credenciales de usuario con cada solicitud que las expone ampliamente, lo que hace que sean interceptadas más fácilmente por partes maliciosas.
  5. El suscriptor debe activar “requerir autenticación para descargar” para exigir autenticación para acceder a los archivos adjuntos. De lo contrario, cualquier persona que tenga acceso al URL correcto para dicho archivo adjunto podrá acceder a cualquier archivo adjunto no restringido. En tales casos, el Suscriptor asumirá toda la responsabilidad por el contenido y el acceso a dichos datos adjuntos.
  6. El Suscriptor debe hacer cumplir sistemáticamente, en todos los extremos a los que acceden Agentes, Administradores y Dueños, un protector de pantalla bloqueado con contraseña o una pantalla de inicio configurada para activarse en un máximo de quince (15) minutos de inactividad del sistema.
  7. El Suscriptor no debe modificar los permisos de visualización que permiten que un usuario vea las actualizaciones de toda una instancia, marca u organización ni modificar la configuración predeterminada que permite el acceso más allá de los tickets o el grupo del propio usuario (a menos que el Suscriptor asuma toda la responsabilidad de asegurarse de que dichos usuarios sean aprobados por el Suscriptor para acceder a todos los datos subsiguientes). El Suscriptor reconoce que los flujos de trabajo automatizados y las funciones de desvío pueden asignar tickets a Agentes o Grupos de Agentes, otorgando así acceso a esos tickets, y el Suscriptor debe configurar dichos flujos de trabajo para garantizar que solo se asigne y otorgue acceso a los Agentes de acuerdo con los permisos previstos del Suscriptor y los requisitos de privilegios mínimos. El Suscriptor reconoce que los permisos de organización del Usuario final se pueden configurar en el perfil del usuario y en la propia organización y si la configuración entra en conflicto, la configuración más permisiva anula la menos permisiva.
  8. El Suscriptor reconoce que Zendesk no es responsable de proteger las transmisiones por correo electrónico de los Usuarios finales, y los Datos de servicio relacionados, antes de ser recibidos en la cuenta de Zendesk Support del Suscriptor. Esto incluye cualquier PHI que pueda pasarse por correo electrónico a través de respuestas a tickets de Zendesk Support, incluidos, entre otros, comentarios o archivos adjuntos de tickets.
  9. El Suscriptor reconoce que Zendesk Support envía notificaciones a los Usuarios finales en diversas circunstancias, p. ej., cuando el Agente del Suscriptor responde a un ticket de Zendesk Support a través del canal de correo electrónico o iniciado por una automatización o un disparador. De manera predeterminada, las notificaciones pueden contener correspondencia entre los Agentes/Administradores Suscriptores y los Usuarios Finales u otra información configurada para incluirse en una notificación automatizada, que potencialmente podría incluir PHI. Para proteger aún más al Suscriptor, su instancia Zendesk Support debe estar configurada para alertar únicamente al Usuario Final que un Agente ha respondido o que su correspondencia dentro de Zendesk ha sido actualizada, y exigir que el Usuario Final se autentique en Zendesk Support para ver el contenido del mensaje.
  10. El Suscriptor reconoce que cualquier funcionalidad de mensajes de texto que se aproveche a su entera discreción en cualquier Servicio de Zendesk está respaldada por SMS y/o protocolos relacionados, lo que puede implicar la transmisión no encriptada de mensajes que se envían a, o salen de, los Servicios.  Como tal, la funcionalidad de los mensajes de texto debe:
    1. no usarse en una cuenta activada para atención médica*, o
    2. si se usa, el Suscriptor asume toda la responsabilidad por el uso de dicha funcionalidad
  11. El Suscriptor reconoce que el uso de la funcionalidad de Encuestas de satisfacción del cliente heredadas ("CSAT heredadas") del Servicio envía los Datos de servicio (que pueden contener PHI) asociados con el ticket de soporte por correo electrónico con el fin de obtener la calificación del usuario, cuyo estado de encriptación no está controlado por Zendesk. Como tal, la funcionalidad CSAT heredada debe:
    1. no usarse en una cuenta activada para atención médica*, o
    2. si se usa, el Suscriptor asume toda la responsabilidad por el uso de dicha funcionalidad
  12. El Suscriptor reconoce que el uso de la funcionalidad de CSAT para el canal de gestión de tickets, si no se configura en consecuencia, envía por correo electrónico los Datos de servicio (que pueden contener PHI) asociados con el ticket de soporte para obtener la calificación del usuario, cuyo estado de encriptación no está controlado por Zendesk. Además, cualquier persona que tenga el URL CSAT específico tiene acceso a las respuestas proporcionadas para un ticket específico. Como tal, cuando se usa la funcionalidad CSAT para el canal de gestión de tickets, el Suscriptor debe
    1. Configurar el cuerpo del correo electrónico de automatización CSAT para que no incluya la PHI potencial y usar el marcador de posición de {{satisfaction.survey_url}} exclusivamente
    2. No usar la funcionalidad de preguntas abiertas

* Para evitar cualquier duda, las advertencias de datos relacionadas con la PHI en la sección 10 con respecto a SMS no se aplican al uso de 2FA en el producto (como se describe en la sección 1.a), ya que dicha funcionalidad simplemente envía una cadena numérica para la verificación de identidad.

II. Zendesk Guide y Gather:

  1. El Suscriptor reconoce que los Servicios de Guide y Gather son públicos por naturaleza (cuando no se aprovechen artículos restringidos o se use una instancia cerrada o restringida) y por lo tanto el Suscriptor debe asegurarse de que los artículos de Zendesk Guide o Gather Service no incluyan PHI, ya sea a través del texto del artículo o como un archivo adjunto o una imagen dentro del artículo.
  2. El Suscriptor debe desactivar la capacidad de los Usuarios finales para agregar comentarios en Zendesk Guide o debe moderar y asumir la responsabilidad de eliminar la PHI de todos los comentarios (como se indica en la sección 3 a continuación).
  3. Cuando el Servicio de Zendesk Guide sea Guide Professional o Enterprise, los Suscriptores deben, siempre que sea posible, desactivar la capacidad de los usuarios finales de crear nuevas publicaciones desactivando la funcionalidad de Gather con Zendesk Guide, o cuando no se puedan seguir desactivando las funciones de Gather debido al caso de uso previsto del Suscriptor, los Suscriptores deben activar la moderación del contenido en el Servicio de Zendesk Guide y establecerlo en "Moderar todo el contenido". No se debe aprobar ninguna presentación que contenga PHI.
  4. No se debe permitir el uso por parte del Suscriptor de “Moderadores de la comunidad” no empleados dentro del Servicio de Gather a menos que el Suscriptor asuma la responsabilidad del acceso potencial de dichos Usuarios a los datos, incluida la posible PHI (si corresponde).
  5. El Suscriptor reconoce que las “@menciones” de los miembros de la comunidad de Gather son posibles cuando se permite que los usuarios finales tengan perfiles públicos y si esta funcionalidad se considera un riesgo en su caso de uso, los perfiles públicos deben desactivarse, o las @menciones deben desactivarse.
     

III. Mensajería de Zendesk:

  1. El Suscriptor no debe activar Integraciones de canales de mensajería por redes sociales a menos que asuma toda la responsabilidad de (i) asegurarse de que no haya PHI presente en los mensajes de redes sociales o (ii) concluir su propio BAA con plataformas de mensajería integradas.
  2. El Suscriptor debe desactivar la capacidad de los Usuarios finales de adjuntar archivos a las conversaciones de mensajería, y asumirá toda la responsabilidad de (i) activar archivos adjuntos seguros o (ii) asegurarse de que los Agentes no adjunten archivos que contengan ePHI a las conversaciones de mensajería. De lo contrario, cualquier persona que tenga acceso al URL correcto para dicho archivo adjunto podrá acceder a cualquier archivo adjunto no restringido.  En tales casos, el Suscriptor asumirá toda la responsabilidad por el contenido y el acceso a dichos URL y/o datos adjuntos.
  3. El Suscriptor asumirá toda la responsabilidad de garantizar que todos los Agentes y Agentes Light puedan ver todos los mensajes entrantes de todos los Usuarios finales.
  4. Si el Suscriptor o sus Agentes acceden o desarrollan integraciones (por ejemplo, como parte de un flujo creado para Agentes IA) para las API y los webhooks o personalizan la experiencia de mensajería, el Suscriptor asumirá toda la responsabilidad de comprender las implicaciones de privacidad y seguridad de todos los flujos de trabajo personalizados y para todas las Entidades del Suscriptor o de terceros (incluidos los proveedores de chatbots) autorizadas a crear, acceder, modificar o borrar Datos de Servicio y ePHI a través de dicho acceso y/o integraciones.
  5. Si el Suscriptor desea retirar el permiso de un Agente para participar en una conversación de mensajería mientras la conversación de mensajería está activa, el Suscriptor asumirá toda la responsabilidad de forzar la terminación del acceso de dicho Agente a Zendesk.
  6. De manera predeterminada, las conversaciones Web Widget con los Usuarios finales son persistentes y serán visibles por el Usuario final cuando regrese al chat web desde el mismo dispositivo. El Suscriptor deberá desactivar esta función o asumir toda la responsabilidad de asegurarse de que los Usuarios finales no compartan dispositivos.
  7. Si el Suscriptor desea implementar la autenticación para los Usuarios finales, el Suscriptor asumirá toda la responsabilidad de implementar esto de manera segura de acuerdo con las mejores prácticas y los estándares del sector.
    1. Cuando utilice este método, el Suscriptor debe (i) usar una clave de firma JWT única para cada canal de autenticación y asignar al token una función descriptiva de designación de nombre; (ii) no compartir claves de firma JWT con ningún tercero a menos que sea razonablemente necesario y de acuerdo con métodos de transmisión que están encriptados de extremo a extremo; (iii) reconocer que si la clave de firma JWT se comparte con un tercero, y el Suscriptor es informado de una filtración de datos de terceros, el Suscriptor debe rotar la clave de firma JWT asociada de inmediato; y (iv) como mínimo, rotar la clave de firma JWT con frecuencia de acuerdo con las políticas de organización del Suscriptor.
    2. El Suscriptor debe usar el atributo JWT de vencimiento y establecer su valor en no más de 15 minutos.
  8. El Suscriptor reconoce que las interacciones entre Usuarios Finales y Agentes IA que no se transfieren a un Agente humano y se transfieren a un ticket aún se almacenan en el sistema y es responsabilidad del Suscriptor borrarlas de acuerdo con sus obligaciones (por ejemplo, implementando un webhook que alerte al Suscriptor cuando se almacenan esas conversaciones y active (automáticamente) la eliminación a través de la API Sunshine Conversations). 
  9. El Suscriptor reconoce que las conversaciones entre Usuarios finales y Agentes IA que se han transformado en un ticket no se pueden suprimir actualmente. La eliminación es posible borrando el ticket. 
  10. El Suscriptor reconoce que los archivos adjuntos de los Usuarios finales en los canales de mensajería no se analizan actualmente en busca de malware en Zendesk. El Suscriptor asumirá la plena responsabilidad de contar con procedimientos y políticas para mitigar el riesgo para los activos del Suscriptor. 
  11. El Suscriptor reconoce que el uso de la funcionalidad de “Conversación secundaria” puede implicar que se creen mensajes de “ticket secundario” y/o “conversación secundaria” dentro de la instancia de soporte del Suscriptor o que se envíen desde ella a los destinatarios a través de ticket, correo electrónico, Slack o integraciones (a discreción del Agente). Si el Suscriptor elige usar esta funcionalidad en una Cuenta activada para atención médica, asume toda la responsabilidad de (i) asegurarse de que no haya PHI presente en dichos mensajes, o (ii) si la PHI pudiera estar presente en los mensajes, el Suscriptor es el único responsable de cualquier responsabilidad, costo, daño o perjuicio relacionado con la adquisición, acceso, uso o divulgación no autorizados de PHI que resulten del intercambio de mensajes a través de la funcionalidad de “Conversación secundaria”.

IV. Zendesk Sunshine Conversations:

  1. El Suscriptor no debe activar Integraciones de canales de terceros a menos que asuma toda la responsabilidad de asegurarse de que (i) no haya PHI presente en los mensajes de canales de terceros o (ii) celebre su propio BAA con plataformas de mensajería integradas.
  2. El Suscriptor asumirá toda la responsabilidad de comprender las implicaciones de seguridad de todas las entidades del Suscriptor o de terceros a las que se les permita crear, acceder, modificar o borrar Datos de Servicio y PHI a través de las Interfaces de Programación de Aplicaciones ("API") de Sunshine Conversations. Para acceder a dichas API, el Suscriptor implementará las siguientes mejores prácticas de seguridad en función del modelo de API utilizado:
    1. Enfoque OAuth 2.0.  Este modelo proporciona las capacidades de seguridad más detalladas, pero requiere que un usuario final acepte los derechos.  Siempre que sea posible, el Suscriptor debe utilizar el método OAuth 2.0 y el esquema de autenticación. El Suscriptor debe asignar a cada cliente OAuth un Nombre de Cliente descriptivo y único y una función de designación de Identificador Único. 
    2. Enfoque de tokens API REST.  Este modelo es el más amplio y permite que un token de API utilice toda la funcionalidad del modelo de API.  Por su naturaleza, proporciona el acceso y las capacidades más amplios y debe usarse con precaución. Cuando se utiliza este método, el Suscriptor debe (i) usar un token único para cada servicio y asignar al token una función de designación de nombre descriptivo; (ii) no compartir tokens de API con ningún tercero a menos que sea razonablemente necesario y de acuerdo con métodos de transmisión que están encriptados de principio a fin; (iii) reconocer que si el token de API se comparte con un tercero, y el Suscriptor es informado de una filtración de datos de terceros, el Suscriptor debe rotar el token asociado de inmediato; y (iv) rotar el token con frecuencia de acuerdo con la política de organización del Suscriptor.  
    3. Si el Suscriptor o sus Agentes acceden o desarrollan integraciones para las API y los webhooks o personalizan la experiencia Sunshine Conversations, el Suscriptor asumirá toda la responsabilidad de comprender las implicaciones de privacidad y seguridad de todos los flujos de trabajo personalizados y de todas las Entidades del Suscriptor o de terceros (incluidos los proveedores de chatbots) que tengan permiso para crear, acceder, modificar o borrar Datos de Servicio y PHI a través de dicho acceso y/o integraciones.
  3. El Suscriptor reconoce que las restricciones de IP configuradas para Zendesk Support no se aplican a la API Sunshine Conversations. Los Suscriptores asumirán toda la responsabilidad de restringir el acceso a Sunshine Conversations API y tokens de API como se describe en 2.b. y de acuerdo con las políticas del Suscriptor. 
  4. El Suscriptor debe desactivar la capacidad de los Usuarios finales de adjuntar archivos a Sunshine Conversations Conversations, y asumirá toda la responsabilidad de activar archivos adjuntos seguros o asegurarse de que los Agentes no adjunten archivos que contengan PHI a las conversaciones de mensajería. De lo contrario, cualquier persona que tenga acceso al URL correcto para dicho archivo adjunto podrá acceder a cualquier archivo adjunto no restringido. En tales casos, el Suscriptor asumirá toda la responsabilidad por el contenido y el acceso a dichos datos adjuntos.
  5. Si el Suscriptor desea implementar la Autenticación para los Usuarios Finales, el Suscriptor asumirá toda la responsabilidad de implementar esto de manera sólida de acuerdo con las mejores prácticas de seguridad y los estándares del sector.
    1. Cuando utilice este método, el Suscriptor debe (i) usar una clave de firma JWT única para cada canal de autenticación y asignar al token una función descriptiva de designación de nombre; (ii) no compartir claves de firma JWT con ningún tercero a menos que sea razonablemente necesario y de acuerdo con métodos de transmisión que están encriptados de extremo a extremo; (iii) reconocer que si la clave de firma JWT se comparte con un tercero, y el Suscriptor es informado de una filtración de datos de terceros, el Suscriptor debe rotar la clave de firma JWT asociada de inmediato; y (iv) como mínimo, rotar la clave de firma JWT con frecuencia de acuerdo con las políticas de organización del Suscriptor.
    2. El Suscriptor debe usar el atributo JWT de vencimiento y establecer su valor en no más de 15 minutos.
  6. El Suscriptor reconoce que las interacciones entre Usuarios Finales y Agentes IA que no se transfieren a un Agente humano y se transfieren a un ticket aún se almacenan en el sistema y es responsabilidad del Suscriptor borrarlas de acuerdo con sus obligaciones, por ejemplo, implementando un webhook que alerte al Suscriptor cuando se almacenan esas conversaciones y active (automáticamente) la eliminación a través de la API Sunshine Conversations 
  7. El Suscriptor reconoce que las conversaciones entre Usuarios finales y Agentes IA que se han transformado en un ticket no se pueden suprimir actualmente. La eliminación es posible borrando el ticket. 
  8. El Suscriptor reconoce que los mensajes borrados a través de la API Sunshine Conversations solo se borran para los Usuarios finales, pero no en el espacio de trabajo de agentes de Zendesk. Esto se puede lograr con la eliminación del ticket en sí o el uso de la funcionalidad de supresión (limitaciones consulte 7.). 
  9. El Suscriptor reconoce que actualmente no se analizan todos los archivos adjuntos en los canales de Sunshine Conversation en busca de malware en Zendesk. El Suscriptor asumirá la plena responsabilidad de contar con procedimientos y políticas para mitigar el riesgo para los empleados del Suscriptor. 

V. Zendesk Chat:

  1. El Suscriptor debe limitar el acceso de los Agentes al Servicio de Zendesk Chat acoplándose y autenticándose a través del Servicio de Zendesk Support.
  2. El suscriptor no debe enviar transcripciones de Chat por correo electrónico, (a) desactivando la canalización de correo electrónico, (b) desactivando la opción de transcripción de chat por correo electrónico en el Web Widget clásico, y (c) no compartiendo exportaciones por correo electrónico desde el panel de Chat
  3. El Suscriptor asume toda la responsabilidad de asegurarse de que (i) no haya PHI presente en los Chats, y/o (ii) todos los Agentes estén autorizados por el Suscriptor para ver dichos datos.

VI. Zendesk Explore Service:

El Suscriptor reconoce que la PHI puede aparecer en el producto Explore a través de nombres de usuario, títulos de tickets, opciones de campos y formularios, y cualquier contenido que se encuentre en los campos de texto de formulario libre.

  1. Para las instancias de Servicio dentro del alcance que contengan PHI, el Suscriptor debe (i) otorgar acceso a la interfaz de Explore únicamente a los agentes que puedan acceder a todos los tickets/llamadas/chats que puedan contener PHI en las instancias de Servicio principales, y (ii) debe otorgar dicho acceso teniendo en cuenta la menor cantidad de privilegios necesarios para el uso de Explore en su entorno. Si desea más información sobre cómo configurar los niveles de acceso en Explore, consulte aquí.
  2. Cuando se aproveche la funcionalidad de "exportación", (i) el Suscriptor reconoce que la PHI puede transferirse al dispositivo permitido por el Suscriptor para acceder a la interfaz del agente y todos los controles asociados en dichos dispositivos son responsabilidad del Suscriptor, y (ii) el Suscriptor debe negar el uso de la funcionalidad de exportación nativa por correo electrónico para dichos informes exportados a menos que asuma la responsabilidad de (a) asegurarse de que no haya PHI contenida en dichas exportaciones, o (b) que los servicios de correo electrónico utilizados para dichas transferencias puedan acomodar la encriptación a través del protocolo de encriptación mínimo permitido por las normas de PCI vigentes en ese entonces.

* Consideraciones especiales para el uso de Explore Enterprise:

El Suscriptor reconoce que el uso del Servicio Explore Enterprise puede implicar un aumento de las funcionalidades para compartir datos y exportar. El Suscriptor deberá:

  1. ya sea (i) asegurarse de que no exista PHI en dichos paneles, o (ii) compartir paneles solo con Agentes, Grupos, Listas o Usuarios finales que estén autorizados para ver y recibir dichos datos.
  2. aprovechar restricciones de IP
  3. cuando se compartan paneles a través del localizador uniforme de recursos (URL), el Suscriptor reconoce que en lugar de compartirlos con cuentas de usuario individuales o de grupo, los datos se compartirán a través de un vínculo de acceso. Por lo tanto, el Suscriptor debe (i) activar la protección de contraseñas, (ii) asegurarse de que la complejidad, rotación, almacenamiento y distribución de las contraseñas elegidas a la parte receptora cumpla con las políticas de contraseñas del Suscriptor para la protección de los datos contenidos en dichos paneles, y (iii) rotar sin demora indebida ante sospechas o confirmación de exposición

VII. Aviso sobre la funcionalidad dentro del producto para los servicios asociados desplegados ("Complementos"):

  1. Servicio Asociado Utilizado de Colaboración: “Conversaciones secundarias”. El Suscriptor reconoce que el uso de la funcionalidad de “Conversación secundaria” puede implicar que se creen mensajes de “ticket secundario” y/o “conversación secundaria” dentro de la instancia de soporte del Suscriptor o que se envíen desde ella a los destinatarios a través de tickets, correo electrónico, Slack o integraciones (a discreción del Agente). Si el Suscriptor elige usar esta funcionalidad en una Cuenta activada para atención médica, asume toda la responsabilidad de (i) asegurarse de que no haya PHI presente en dichos mensajes, o (ii) si la PHI pudiera estar presente en los mensajes, el Suscriptor es el único responsable de cualquier responsabilidad, costo, daño o perjuicio relacionado con la adquisición, acceso, uso o divulgación no autorizados de PHI que resulten del intercambio de mensajes a través de la funcionalidad de “Conversación secundaria”.

VIII. Aplicaciones móviles de Zendesk (o acceso realizado desde dispositivos móviles como smartphones o tabletas):

  1. El uso incluirá la encriptación a nivel de dispositivo
  2. Se debe aprovechar el acceso biométrico o PIN establecido en la configuración más alta permitida para el dispositivo
  3. Las notificaciones que permiten mostrar comentarios de tickets en las pantallas de bloqueo de dichos dispositivos deben desactivarse
  4. Los bloqueos de inactividad de pantalla deben estar activados y configurados para bloquearse en un máximo de 15 minutos de inactividad.
  5. El Suscriptor reconoce que la funcionalidad de supresión no está disponible en la aplicación móvil de soporte y los Agentes tienen que iniciar sesión a través del Navegador si desean usar la funcionalidad de supresión. 
  6. Si el Suscriptor elige autenticar a los Usuarios finales para la mensajería de Zendesk, el Suscriptor reconoce que el estado de autenticación de un Usuario final no se muestra en la aplicación móvil de soporte.

IX. Zendesk Insights: Support for this Service quedó obsoleto a partir del 5 de febrero de 2021.

X. Aviso sobre la funcionalidad IA de Zendesk ("IA de Zendesk", "IA avanzada", "IA generativa", etc.):

  1. El Suscriptor reconoce que las funciones IA de Zendesk están destinadas a aumentar la productividad de los Servicios de Zendesk y no deben usarse de manera que puedan interpretarse como (i) proporcionar asesoramiento médico o sanitario, (ii) proporcionar un diagnóstico de afección o síntomas, (iii) recetar un tratamiento, o (iv) impedir de alguna manera que un Usuario solicite el asesoramiento, diagnóstico o tratamiento de un profesional de la salud, (v) o proporcionarle información o tomar decisiones que lo incluyan o salgan de cualquier plan de salud, programa de tratamiento, servicio de pruebas o cualquier otro servicio de salud que pueda afectar su búsqueda o recepción de servicios de salud (a menos que el Suscriptor asuma toda la responsabilidad de esta decisión en función de su caso de uso único e interacciones con sus Usuarios, así como las posibles implicaciones de usar IA de tal manera).
  2. El Suscriptor reconoce que si usa cualquier función IA generativa, Esas salidas IA generadas son generadas por computadora y no por seres humanos, y pueden producir salidas inexactas. Zendesk no garantiza la precisión de estos resultados.
  3. El Suscriptor reconoce que si se usa un mensaje bot de conversación Agentes IA para proporcionar un mensaje de descargo de responsabilidad requerido a los Usuarios finales del Suscriptor, la funcionalidad “Generar variaciones” no se activará para garantizar la integridad del contenido del mensaje. 
  4. El Suscriptor reconoce que si se activa la Funcionalidad de escritura mejorada en el Centro de administración se activará esta funcionalidad para todos los agentes en su instancia independientemente de sus roles y permisos. 

XI. Zendesk QA

  1. El Suscriptor reconoce que las funciones IA Zendesk QA están destinadas a aumentar la productividad de los Servicios de Zendesk y no deben usarse de manera que puedan interpretarse como (i) proporcionar asesoramiento médico o sanitario, (ii) proporcionar un diagnóstico de afección o síntomas, (iii) recetar un tratamiento, o (iv) impedir de alguna manera que un Usuario solicite el asesoramiento, diagnóstico o tratamiento de un profesional sanitario, (v) o proporcionar de otra manera información a un Usuario o tomar decisiones que lo incluyan o salgan de cualquier plan de atención sanitaria, programa de tratamiento, servicio de pruebas o cualquier otro servicio sanitario que pueda afectar su búsqueda o recepción de servicios sanitarios (a menos que el Suscriptor asuma toda la responsabilidad de esta decisión en función de su caso de uso único e interacciones con sus Usuarios, así como las posibles implicaciones de usar IA de tal manera).
  2. El Suscriptor reconoce que la eliminación o supresión en su instancia de Zendesk no se sincroniza de inmediato con Zendesk QA sino que se transferirá en las siguientes 3-6 horas.
  3. Cuando use la funcionalidad de encuestas El Suscriptor debe (i) desactivar la funcionalidad de asistencia IA Zendesk QA (o asegurarse de que todos los Agentes que realizan trabajo QA estén autorizados para ver cualquier dato potencial dentro de dicha transacción, además de asegurarse de que se cumplan los principios del punto 1) (ii) asegurarse de configurar la encuesta de manera que no revele PHI en las preguntas o descripciones de la encuesta (o asumir la responsabilidad de dichos datos en los correos electrónicos que se envían a través de StartTLS oportunista)
  4. Cuando use la integración personalizada “Zendesk Chat”, el Suscriptor debe considerar establecer un periodo de retención de datos alineado con las políticas del Suscriptor para asegurarse de que los datos no se retengan por un tiempo ilimitado.
  5. El Suscriptor reconoce que cuando se usa la API Sunshine Conversations para borrar partes de una conversación de mensajería de Zendesk, este cambio no se refleja en Zendesk QA. En su lugar, la información debe eliminarse del ticket original a través de la supresión o debe eliminarse toda la conversación.
  6. El Suscriptor reconoce que Zendesk QA no Support la función de “archivos adjuntos privados” de Zendesk en este momento. Esto significa que cualquier persona que tenga acceso al URL correcto para dicho archivo adjunto puede acceder a los archivos adjuntos y no deben usarse con datos confidenciales, incluida la PHI. El Suscriptor asumirá toda la responsabilidad por el contenido y el acceso a dichos URL y/o datos adjuntos.
  7. El Suscriptor reconoce que, según las disposiciones iniciales de Zendesk QA, la configuración avanzada de la conexión solo es posible después de la primera sincronización.

XII. Gestión de personal de Zendesk "Gestión de personal":

  1. El Suscriptor reconoce que
    1. El rol predeterminado de Administrador de Gestión de personal tiene acceso a toda la actividad y configuración del Agente aplicable al Servicio de Gestión de personal (incluidas las etiquetas mencionadas en el punto 2 a continuación).
    2. El rol predeterminado de Agente tiene acceso a la actividad del Agente a menos que los administradores lo hayan configurado para que tenga acceso diferente a través de la creación de roles personalizados como se describe aquí
  2. El Suscriptor reconoce que las etiquetas aplicadas por los Agentes, Administradores o la lógica predefinida del sistema dentro de los tickets en soporte serán visibles dentro del producto Gestión de personal para cualquier Usuario autorizado a ver dicha actividad de tickets. Si el Suscriptor considera que las etiquetas son confidenciales, el acceso debe configurarse correctamente.

Descargo de responsabilidad: Debido a cambios legales o reglamentarios o cambios en el Servicio de Zendesk, las configuraciones de seguridad en este documento pueden cambiar de vez en cuando. Este documento contiene las recomendaciones de Zendesk sobre las configuraciones mínimas de seguridad efectiva para la protección de la PHI dentro de los productos Zendesk que se describen anteriormente en este momento. Este documento no constituye una plantilla exhaustiva para todos los controles sobre dichos datos ni constituye asesoramiento jurídico. Cada suscriptor de Zendesk debe buscar su propio asesor legal con respecto a sus requisitos de cumplimiento HIPAA o HDS y debe hacer los cambios adicionales a sus configuraciones de seguridad de acuerdo con el análisis independiente de cada suscriptor, siempre y cuando dichos cambios no contrarresten o degraden la seguridad de las configuraciones descritas en este documento.

 

Registro de cambios:

10 de noviembre de 2025

  • Actualizó el nombre del contrato de cliente de Contrato de servicios principales a Contrato de cliente de Zendesk

24 de enero de 2025

  • Configuraciones HIPAA y HDS consolidadas

27 de diciembre de 2024

  • Se agregó la sección XII para incorporar la Gestión de personal de Zendesk ("Gestión de personal") al ámbito

16 de diciembre de 2024

  • Se agregó la sección XI para incorporar Zendesk QA al ámbito
  • Ha cambiado varias instancias de "Answer Bot" a "Agentes IA" para indicar cambios en la convención de nombres y un alcance más amplio.

10 de octubre de 2024

  • Se agregó la sección I, soporte, número 12 (CSAT) y se editó la sección I, soporte, número 11 (CSAT heredada) para dar cabida a la nueva funcionalidad. 

7 de marzo de 2024

  • Se agregó la Sección X, Aviso sobre la Funcionalidad IA de Zendesk
  • Sección I, soporte, número 7 (permisos de visualización):
    • Aclaró que los "permisos de visualización" pertenecen a toda una "instancia/marca/organización" en lugar de solo "organización".
    • Se agregó una nueva disposición para el comportamiento de organizaciones específicas del usuario final. 
  • Sección I, soporte, número 9 (correo electrónico):  
    • Amplió las circunstancias en las que Zendesk Support envía un correo electrónico a un usuario final para incluir las respuestas a través del canal de correo electrónico o las iniciadas por una automatización o un disparador, en lugar de solo un agente que responde a un ticket.
    • Especificó que, de manera predeterminada, las notificaciones automatizadas pueden contener la correspondencia del ticket más reciente u otra información configurada, lo que podría incluir PHI.
       

25 de octubre de 2023

  • Introducción: Idioma de introducción aclarado para las cuentas activadas HIPAA
  • Sección II, Guide y Gather, número 1 (restricciones del centro de ayuda): sustituyó las restricciones de IP por artículos restringidos para mayor claridad

13 de abril de 2023

  • Sección I, soporte, número 4 (API): 
    • Se agregó un vínculo a los métodos de autenticación para mayor claridad 
    • b) Se eliminaron las recomendaciones de plazos exactos para la rotación para ajustarse a las mejores prácticas del sector y se eliminó la referencia a los Términos de servicio de la API de REST (redundancia)
    • agregó c) para advertir sobre el uso de la autenticación básica para la API 
  • Sección II, Guide:
    • Número 1 (restricciones del centro de ayuda): se agregó referencia a los centros de ayuda cerrados o restringidos para ajustarse a la funcionalidad del producto
    • Número 5 (@menciones): Se agregó la opción de desactivar las @menciones para que coincidan con la funcionalidad del producto 
  • Sección III, Mensajería: 
    • Números 1 y 2 (canales de terceros y archivos adjuntos privados): se agregaron identificadores de sección (i) y (ii) para mayor claridad
    • Número 2 (archivos adjuntos privados): se agregó “URL y/o” para una aclaración 
    • Número 7-10 (autenticación del usuario final, eliminación de conversaciones del Answerbot, supresión, análisis de malware): secciones completas agregadas para mayor transparencia
  • Sección IV, Sunshine Conversations: toda la sección fue agregada debido a que Sunshine Conversations en Zendesk Suite pasó a formar parte del BAA 
  • Sección V, Chat, número 3 (espacio de trabajo de agentes): pequeñas correcciones de frases
  • Sección VIII, aplicaciones móviles, número 5-7 (análisis de malware, supresión, autenticación de usuarios finales): secciones enteras agregadas para mayor transparencia

24 de febrero de 2023

  • Sección I. Soporte, número 3: eliminó la distinción separada entre soporte y restricciones de IP de Chat, ya que la interfaz de usuario ahora está unificada.
  • Sección I. Soporte, número 5: aclaración adicional sobre el incumplimiento del requisito 
  • Sección I. Soporte, número 7: “El suscriptor no debe” cambió a “El suscriptor no debe”.
  • Sección IV. Chat, número 2: aclara que está prohibida toda funcionalidad de exportación de datos de Chat usando correo electrónico, y no solo las transcripciones y las tuberías. 
  • Sección III. Mensajería: toda la sección agregada para tener en cuenta la funcionalidad de mensajería de Zendesk, además del alcance del Business Associate Agreement de Zendesk.

9 de julio de 2021

  • Agrega el punto 3. en la sección Chat para las responsabilidades relacionadas con el uso del espacio de trabajo de agentes.

21 de enero de 2021

  • La adición del número 1.11 no permite CSAT salvo que el Suscriptor asuma la responsabilidad de los datos enviados por correo electrónico como parte de la encuesta. 
  • Advertencia en el número 1.7 para permitir que los Suscriptores modifiquen los permisos de visualización debido a que los usuarios ya tienen aprobación para acceder a dichos datos en sus extremos.
  • Se actualizó todo el documento para que coincida con el estilo de la compañía de los vínculos incrustados dentro del texto en lugar de los URL incorporados (sin impacto en el contenido de configuración). 

Agosto de 2020

  • Adición de Explore Enterprise que cubre el aumento de las capacidades para compartir paneles
  • Eliminación de la prohibición de adjuntar archivos de Chat (los requisitos de autenticación de soporte ahora cubren)
  • Desambiguación de que la prohibición del ePHI en los campos personalizados se aplicaba específicamente al uso de Insights y no globalmente
  • Adición de una nueva sección que cove complementos a los servicios desplegados, con "Conversaciones secundarias" como la primera adición
  • Varias ediciones de gramática/formato (sin importancia para el contenido)

13 de julio de 2020:

  • * Para evitar cualquier duda, las advertencias de datos relacionadas con el ePHI en la sección 10 con respecto al SMS no se aplican al uso de SMS en el producto (como se describe en la sección 1.a), ya que dicha funcionalidad simplemente envía una cadena numérica para la verificación de identidad".

13 de diciembre de 2019

  • permite que se renuncien a las restricciones de IP de los agentes cuando el caso de uso no permita dichas restricciones siempre que se cumpla la ley de acceso anticipado de los agentes.

17 de diciembre de 2019

  • permite comentarios de usuarios finales en Guide siempre y cuando los Agentes moderen dichos comentarios y eliminen toda la PHI.

6 de noviembre de 2019

  • Artículo actualizado para reflejar el cambio que los suscriptores pueden elegir a su entera discreción para renunciar o sustituir cualquier configuración en particular siempre y cuando asuman la responsabilidad de dicha decisión.

"El incumplimiento por parte del Suscriptor de implementar y cumplir con cualquier configuración en particular que se enumera a continuación, o cualquier serie de configuraciones requeridas que se enumeran a continuación, será al

El Suscriptor asume su propio riesgo y a su entera discreción; y dicha falla eximirá a Zendesk y a sus empleados, agentes y afiliados de cualquier responsabilidad con respecto a cualquier acceso no autorizado a los Datos de Servicio del Suscriptor, incluido cualquier Información de Salud Protegida electrónica, que resulte de dicha falla del Suscriptor. "

  • Otros cambios incluyen:
    • 1. la capacidad de usar SMS siempre y cuando el suscriptor asuma toda la responsabilidad de garantizar que no haya PHI presente en dichas transmisiones.
    • 2. La capacidad de usar archivos adjuntos en Chat siempre y cuando el suscriptor asuma toda la responsabilidad de asegurarse de que no haya PHI presente en dichos archivos adjuntos.

6 de marzo de 2019

  • actualizado para incluir la configuración de Zendesk Explore

17 de enero de 2019

  •  actualizado para no permitir archivos adjuntos en Chat.

Descargo de responsabilidad de la traducción: Este artículo ha sido traducido usando software de traducción automática para proporcionar una idea básica del contenido. Se han realizado esfuerzos razonables para proporcionar una traducción exacta, sin embargo, Zendesk no garantiza la exactitud de la traducción.

Si surge alguna pregunta relacionada con la exactitud de la información incluida en el artículo traducido, consulte la versión en inglés del artículo, que es la versión oficial.

Tecnología de Zendesk