Cuentas habilitadas HIPAA :

Todos los términos en mayúsculas que se usan en este documento tendrán el significado que se les da en el Acuerdo de socio comercial ("BAA") de Zendesk. 

Zendesk y el Suscriptor han celebrado un Acuerdo de socio comercial (“BAA”) que requiere que el Suscriptor evalúe e implemente, según corresponda para su caso de uso, las siguientes configuraciones, o alternativas que el HIPAA considere sustancialmente similares, para todos y cada uno de los antes de introducir cualquier Información de salud protegida ("PHI") en los Servicios. 

Si el Suscriptor decide, a su entera discreción, no implementar cualquiera de las configuraciones recomendadas que se enumeran a continuación, el Suscriptor asumirá la responsabilidad exclusiva por cualquier acceso no autorizado o uso indebido de la divulgación de los Datos de servicio del Suscriptor, incluida cualquier Información médica protegida, que resulte de cualquier desviación de las configuraciones recomendadas por el Suscriptor.

El Suscriptor debe haber comprado planes de servicio en el nivel apropiado y tener los complementos asociados requeridos (consulte a su representante de ventas si no está seguro)

I. Se deben establecer las siguientes configuraciones de seguridad mínimas para Zendesk Support y se reconocen en el BAA para cualquier cuenta habilitada para HIPAA :

  1. Autenticación de Secure Agent a través de uno de los dos métodos siguientes:
    1. Usar Zendesk Support nativo con configuración de contraseña: (i) establecida en “Alta”; o (ii) personalizado por el Suscriptor de manera que establezca requisitos no menos seguros que los establecidos en la configuración “Alta”. 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 estar desactivados; 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 "Alta" de Zendesk y activar y hacer cumplir la autenticación de 2 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 estar desactivados.
    3. Todas las opciones de autenticación que utilicen SSO como método de autenticación deben desactivar el acceso con contraseña.
  2. El cifrado Secure Socket Layer ("SSL") en las cuentas activadas por HIPAA debe permanecer activado en todo momento. Las cuentas habilitadas para HIPAA que utilizan un dominio que no sea zendesk.com deben establecer y mantener SSL alojado.
  3. El acceso de los agentes debe estar restringido 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 más arriba 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 dudas, “Acceso de agente” se refiere al 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 habilitada para HIPAA del Suscriptor permita llamadas a las interfaces de programación de aplicaciones de Zendesk ("API"), 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 permite 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 debe 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 los derechos sean aceptados por un usuario final.  Siempre que sea posible, el Suscriptor utilizará el enfoque y el esquema de autenticación OAuth 2.0. El Suscriptor le dará 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 de OAuth deben permitir el privilegio mínimo necesario para realizar las tareas requeridas.
    2. Enfoque de token de API de 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. Al usar este enfoque, el Suscriptor (i) usará un token único para cada servicio y le dará al token un nombre descriptivo que designe la función; (ii) no compartir tokens de API con terceros a menos que sea razonablemente necesario y de conformidad con los métodos de transmisión que están encriptados de extremo a extremo; (iii) reconocer que si el token de API se comparte con un tercero, y el Suscriptor se entera de una violación de datos de un tercero, el Suscriptor rotará el token asociado de inmediato; y (iv) como mínimo, rotar el token con frecuencia de acuerdo con las políticas de la organización del Suscriptor.  
    3. Cuando sea posible, el Suscriptor desactivará el acceso con contraseña a la API, ya que este enfoque envía las credenciales del usuario con cada solicitud, lo que lo expone ampliamente, lo que hace que sea más fácil de interceptar por parte de terceros malintencionados.  
  5. El suscriptor debe activar "requerir autenticación para la descarga" para que se requiera 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 aplicar sistemáticamente, en todos los terminales a los que acceden los agentes, administradores y propietarios, un protector de pantalla bloqueado con contraseña o una pantalla de inicio configurada para interactuar con un máximo de quince (15) minutos de inactividad del sistema.
  7. El Suscriptor no debe modificar los permisos de visualización que permiten a un usuario ver las actualizaciones de toda una instancia/marca/organización, ni modificar la configuración predeterminada que permite el acceso más allá de los propios tickets del usuario (a menos que el Suscriptor asuma toda la responsabilidad de garantizar que dichos usuarios tengan la aprobación del Suscriptor para acceder a todos los tickets). datos subsiguientes). El suscriptor reconoce que los permisos de organización del usuario final se pueden establecer 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 configuración menos permisiva.
  8. El Suscriptor reconoce que Zendesk no es responsable de proteger las transmisiones de correo electrónico de los Usuarios finales y los Datos de servicio relacionados, antes de que se reciban en la cuenta de Zendesk Support del Suscriptor. Esto incluye cualquier PHI que se pueda pasar por correo electrónico a través de respuestas a tickets de Zendesk Support , incluidos, entre otros, comentarios de tickets o archivos adjuntos.
  9. El Suscriptor reconoce que Zendesk Support envía un correo electrónico a un Usuario final en diversas circunstancias, por ejemplo, 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, este correo electrónico contiene la correspondencia más reciente del ticket u otra información configurada para incluirse en una notificación automatizada, que podría incluir PHI. Para proteger aún más al Suscriptor, su cuenta de Zendesk Support debe ser configurado para alertar solo al usuario final de que un agente ha respondido, 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 utilizada a su exclusivo criterio en cualquier Servicio de Zendesk está respaldada por SMS y/o protocolos relacionados, lo que puede implicar la transmisión sin cifrar de mensajes que se envían hacia o desde los Servicios.  Como tal, la funcionalidad de los mensajes de texto debería:
    1. no se puede usar en una cuenta habilitada para HIPAA *, 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 heredada de Encuestas de satisfacción del cliente ("CSAT heredada") del Servicio envía Datos del servicio (que pueden contener PHI) asociados con el ticket de Support por correo electrónico para obtener la calificación del usuario, cuyo estado de encriptación no está controlado de Zendesk. Como tal, la funcionalidad de CSAT heredada debería:
    1. no se puede usar en una cuenta habilitada para HIPAA *, 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 las Encuestas de satisfacción del cliente ("CSAT") del Servicio para el canal de gestión de tickets, si no está configurado en consecuencia, envía Datos de servicio (que pueden contener PHI) asociados con el ticket de Support por correo electrónico 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 de CSAT específico tiene acceso a las respuestas proporcionadas para un ticket específico. Por lo tanto, cuando se usa la funcionalidad de CSAT para el canal de gestión de tickets, el Suscriptor debe
    1. Configure el cuerpo del correo electrónico de automatización de CSAT para que no incluya ePHI potencial y use el {{satisfaction.survey_url}} marcador de posición exclusivamente
    2. No usar la funcionalidad de preguntas abiertas

* Para evitar dudas, las advertencias de datos relacionadas con la ePHI en la sección 10 con respecto a los 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. Las siguientes configuraciones de seguridad mínimas para Zendesk Guide y Gather Services deben implementarse y se reconocen en el BAA para cualquier cuenta habilitada para HIPAA :

  1. El Suscriptor reconoce que los Servicios de Guide y Gather son públicos por naturaleza (siempre que no se utilicen artículos restringidos ni se utilice una instancia cerrada o restringida) y, por lo tanto, el Suscriptor se asegurará de que los artículos en Zendesk Guide o el Servicio de Gather no incluyan PHI, ya sea a través del texto de el artículo o como un archivo adjunto o una imagen dentro del artículo.
  2. El Suscriptor deberá desactivar la capacidad de los Usuarios finales para agregar comentarios en Zendesk Guide, o bien 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 es Guide Professional o Enterprise, los Suscriptores deben, cuando sea posible, desactivar la capacidad de los usuarios finales para crear nuevas publicaciones desactivando la funcionalidad de Gather con Zendesk Guide, o si no pueden desactivar las funciones de Gather debido a la intención del Suscriptor. caso práctico, los suscriptores deben activar la moderación del contenido en el servicio de Zendesk Guide y establecerlo en "Moderar todo el contenido". No se aprobará ningún envío que contenga PHI.
  4. No se permitirá el uso por parte del Suscriptor de “Moderadores de la comunidad” que no sean empleados dentro del Servicio de Gather.
  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 se desactivarán o las @menciones se desactivarán.

III. Se deben establecer las siguientes configuraciones de seguridad mínimas para el uso de la mensajería de Zendesk y se reconocen en el BAA de Zendesk para cualquier cuenta habilitada para HIPAA :

  1. El Suscriptor no activará las integraciones de canales de mensajería por redes sociales a menos que asuma la responsabilidad total de (i) asegurarse de que no haya ePHI presente en los mensajes de redes sociales o (ii) celebre su propio BAA con plataformas de mensajería integradas.
  2. El Suscriptor desactivará la capacidad de los Usuarios finales para adjuntar archivos a las conversaciones de mensajería, y asumirá toda la responsabilidad de (i) activar los 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 los Agentes Light puedan ver todos los mensajes entrantes de todos los Usuarios finales.
  4. Si el Suscriptor o sus Agentes acceden o desarrollan integraciones (p. ej., como parte de un flujo creado para el Answer Bot) para las API y webhooks o si 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 de todos los Las entidades del Suscriptor o de terceros (incluidos los proveedores de chatbots) pueden crear, acceder, modificar o borrar Datos de servicio y ePHI a través de dicho acceso o integraciones.
  5. Si el Suscriptor desea eliminar 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 del Web Widget con los usuarios finales son persistentes y el usuario final las podrá ver 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 implementarla de manera segura de acuerdo con las mejores prácticas y los estándares de la industria.
    1. Al usar este enfoque, el Suscriptor (i) usará una clave de firma JWT única para cada canal de autenticación y le dará al token un nombre descriptivo que designe la función; (ii) no compartirá las claves de firma JWT con terceros a menos que sea razonablemente necesario y de conformidad con los 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 tiene conocimiento de una violación de datos de terceros, el Suscriptor 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 la organización del Suscriptor.
    2. El suscriptor debe usar el atributo JWT de expiración y establecer su valor en no más de 15 minutos.
  8. El Suscriptor reconoce que las interacciones entre los Usuarios finales y el Answerbot que no se entregan 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, mediante la implementación de un webhook que alerta al Suscriptor cuando esas conversaciones se almacenan y (automáticamente) activa la eliminación a través de la API de Sunshine Conversations ). 
  9. El suscriptor reconoce que las conversaciones entre los usuarios finales y el Answerbot que se han transformado en un ticket no se puede suprimir actualmente. Se puede borrar 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á toda la responsabilidad de contar con procedimientos y políticas para mitigar el riesgo para los activos del Suscriptor. 

IV. Las siguientes configuraciones de seguridad mínimas para el uso de Zendesk Sunshine Conversations (en uso con Zendesk Suite) se deben implementar y se reconocen en el BAA de Zendesk para cualquier cuenta habilitada para HIPAA :

  1. El Suscriptor no activará las integraciones de canales de terceros a menos que asuma toda la responsabilidad de garantizar que (i) no haya ePHI 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 permite crear, acceder, modificar o borrar Datos de servicio y PHI a través de las Interfaces de programación de aplicaciones de Sunshine Conversations ("API"). Para acceder a dichas API, el Suscriptor deberá 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 los derechos sean aceptados por un usuario final.  Siempre que sea posible, el Suscriptor utilizará el enfoque y el esquema de autenticación de OAuth 2.0. El Suscriptor le dará a cada cliente OAuth un nombre de cliente descriptivo y único y una función de designación de identificador único. 
    2. Enfoque de token de API de 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. Al usar este enfoque, el Suscriptor (i) usará un token único para cada servicio y le dará al token un nombre descriptivo que designe la función; (ii) no compartir tokens de API con terceros a menos que sea razonablemente necesario y de conformidad con los métodos de transmisión que están encriptados de extremo a extremo; (iii) reconocer que si el token de API se comparte con un tercero, y el Suscriptor se entera de una violación de datos de un tercero, el Suscriptor rotará el token asociado de inmediato; y (iv) rotar el token con frecuencia de acuerdo con la política de la 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 de Sunshine Conversations , 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 chatbot) permitidas para crear, acceder, modificar o borrar los Datos de servicio y la ePHI 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 de Sunshine Conversations . Los Suscriptores asumirán toda la responsabilidad de restringir el acceso a la API de Sunshine Conversations y los tokens de API como se describe en 2.b. y de acuerdo con las políticas del Suscriptor. 
  4. El Suscriptor desactivará la capacidad de los Usuarios finales para adjuntar archivos a las conversaciones de Sunshine Conversations , y asumirá toda la responsabilidad de activar archivos adjuntos seguros o 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 datos adjuntos.
  5. Si el Suscriptor desea implementar la Autenticación para Usuarios Finales, el Suscriptor asumirá toda la responsabilidad de implementarla de manera sólida de acuerdo con las mejores prácticas de seguridad y los estándares de la industria.
    1. Al usar este enfoque, el Suscriptor (i) usará una clave de firma JWT única para cada canal de autenticación y le dará al token un nombre descriptivo que designe la función; (ii) no compartirá las claves de firma JWT con terceros a menos que sea razonablemente necesario y de conformidad con los 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 tiene conocimiento de una violación de datos de terceros, el Suscriptor 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 la organización del Suscriptor.
    2. El suscriptor debe usar el atributo JWT de expiración y establecer su valor en no más de 15 minutos.
  6. El Suscriptor reconoce que las interacciones entre los Usuarios finales y el Answerbot que no se entregan 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, mediante la implementación de un webhook que alerta al suscriptor cuando esas conversaciones se almacenan y (automáticamente) activa la eliminación a través de la API de Sunshine Conversations 
  7. El suscriptor reconoce que las conversaciones entre los usuarios finales y el Answerbot que se han transformado en un ticket no se pueden suprimir actualmente. Se puede borrar borrando el ticket. 
  8. El Suscriptor reconoce que los mensajes borrados a través de la API de Sunshine Conversations solo se borran para los Usuarios finales, pero no se borran en el espacio de trabajo de agente de Zendesk. Esto se puede lograr borrando el ticket en sí o usando la funcionalidad de supresión (consulte las limitaciones en 7.). 
  9. El Suscriptor reconoce que todos los archivos adjuntos en los canales de Sunshine Conversation no se analizan actualmente en busca de malware en Zendesk. El Suscriptor asumirá toda la responsabilidad de contar con procedimientos y políticas para mitigar el riesgo para los empleados del Suscriptor. 

V. Las siguientes configuraciones de seguridad mínimas para el servicio de Zendesk Chat deben implementarse y se reconocen en el BAA para cualquier cuenta habilitada para HIPAA :

  1. El Suscriptor limitará el acceso de los Agentes al Servicio de Zendesk Chat mediante la conexión y la autenticación a través del Servicio de Zendesk Support .
  2. El Suscriptor no podrá 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, y (c) no compartiendo exportaciones por correo electrónico desde el panel de Chat
  3. El Suscriptor no activará el "Espacio de trabajo de agente" a menos que el Suscriptor asuma toda la responsabilidad de garantizar que (i) no haya ePHI presente en Chats, y/o (ii) que el Suscriptor permita que todos los Agentes vean dichos datos.

VI. Se deben establecer las siguientes configuraciones de seguridad mínimas para el uso del servicio Zendesk Explore y se reconocen en el BAA para cualquier cuenta habilitada para HIPAA :

El Suscriptor reconoce que la ePHI 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 formato libre.

  1. Para cualquier instancia del Servicio dentro del alcance que contenga PHI, el Suscriptor (i) solo otorgará acceso a la interfaz de Explore a los agentes que puedan acceder a todos los tickets/llamadas/chats que puedan contener PHI en las instancias del Servicio principal, y (ii) 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 aprovecha la funcionalidad de "exportación", (i) el Suscriptor reconoce que la PHI puede transferirse al dispositivo que el Suscriptor permite para acceder a la interfaz del agente y todos los controles del operador 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) garantizar que dichas exportaciones no contengan PHI, o (b) que los servicios de correo electrónico utilizados para dichas transferencias puedan admitir el cifrado a través del protocolo de cifrado mínimo permitido por los estándares PCI vigentes en ese momento.

* Consideraciones especiales para el uso de Explore Enterprise:

El Suscriptor reconoce que el uso del Servicio Explore Enterprise puede implicar un mayor intercambio de datos y funcionalidades de exportación. El Suscriptor deberá:

  1. (i) asegurarse de que no haya ePHI en dichos paneles, y/o (ii) compartir los paneles solo con agentes, grupos, listas o usuarios finales que estén aprobados para ver y recibir dichos datos.
  2. aprovechar las restricciones de IP
  3. cuando se comparten paneles a través del Localizador uniforme de recursos (URL), el Suscriptor reconoce que en lugar de compartir con cuentas de usuarios individuales o grupales, los datos se compartirán mediante un vínculo de acceso. Por lo tanto, el Suscriptor deberá (i) activar la protección con contraseña, (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) sea rotado sin demora indebida en caso de sospecha o confirmación de exposición

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

  1. Collaboration Deployed Associated Service: “Conversaciones secundarias”. El Suscriptor reconoce que el uso de la funcionalidad “Conversación secundaria” puede implicar que se creen mensajes de “ticket secundario” o “conversación secundaria” dentro de la instancia de Support del Suscriptor o se envíen desde ella a los destinatarios a través de un ticket, correo electrónico, Slack o integraciones (a discreción del Agente). . Si el Suscriptor elige usar esta funcionalidad en una cuenta habilitada para HIPAA , el Suscriptor asume toda la responsabilidad de (i) asegurarse de que no haya PHI presente en dichos mensajes, o (ii) si PHI pudiera estar presente en los mensajes, el Suscriptor es el único responsable por cualquier responsabilidad, costo, daño o perjuicio relacionado con la adquisición, el acceso, el uso o la divulgación no autorizados de la PHI como resultado del intercambio de mensajes a través de la funcionalidad “Conversación secundaria”.

VIII. Se deben establecer las siguientes configuraciones de seguridad mínimas para el uso de las aplicaciones móviles de Zendesk (o el acceso realizado por dispositivos móviles como teléfonos inteligentes o tabletas) y se reconocen en el BAA de Zendesk para cualquier cuenta habilitada para HIPAA :

  1. El uso debe incluir el cifrado a nivel de dispositivo
  2. Se aprovechará el acceso biométrico o con PIN establecido en la configuración de dispositivo más alta permitida
  3. Las notificaciones que permiten que los comentarios de los tickets aparezcan en las pantallas de bloqueo de dichos dispositivos serán desactivadas
  4. Los bloqueos de pantalla por inactividad deben estar activados y configurados para bloquearse en no más de 15 minutos de inactividad.
  5. El Suscriptor reconoce que la aplicación móvil de Zendesk Support no muestra si los archivos adjuntos han sido escaneados y detectados como malware, y los agentes deben iniciar sesión a través del navegador para ver esta información. El Suscriptor asumirá toda la responsabilidad de contar con procedimientos y políticas para mitigar los posibles riesgos.
  6. El Suscriptor reconoce que la funciónde supresión no está disponible en la aplicación móvil de Support y que los agentes deben iniciar sesión a través del navegador si desean usar la función de supresión.
  7. 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 Support .

IX. Para los suscriptores que han firmado un BAA de Zendesk y posteriormente han usado el servicio Zendesk Insights, nuestro soporte para este servicio quedará obsoleto a partir del 5 de febrero de 2021.   

X. Aviso sobre la funcionalidad de IA de Zendesk (“Zendesk AI”, “Advanced AI”, “Generative AI”, et al):

  1. El Suscriptor reconoce que las funciones de IA de Zendesk están destinadas a aumentar la productividad de los Servicios de Zendesk y no deben usarse de manera que pueda interpretarse como (i) proporcionar asesoramiento médico o de atención médica, (ii) proporcionar un diagnóstico de condición o síntomas, (iii) prescribir un tratamiento, o (iv) impedir de cualquier manera que un Usuario busque el consejo, el diagnóstico o el tratamiento de un profesional de la salud, (v) o proporcionar a un Usuario información o tomar decisiones que lo identifiquen o no. cualquier plan de atención médica, programa de tratamiento, servicio de pruebas o cualquier otro servicio de atención médica 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 y las interacciones con sus Usuarios, así como como las implicaciones potenciales de usar la IA de esa manera).
  2. El Suscriptor reconoce que si usa cualquier función de IA generativa con tecnología de OpenAI, los resultados de OpenAI son generados por computadora y no por humanos, y pueden producir resultados inexactos. Zendesk no garantiza la precisión de estos resultados.
  3. El Suscriptor reconoce que si se usa un mensaje de bot de Zendesk para proporcionar un mensaje de descargo de responsabilidad obligatorio 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 al activar la funcionalidad IA generativa para agentes / IA generativa para la base de conocimientos en el Centro de administración, se activará esta funcionalidad para todos los agentes en su instancia, independientemente de sus roles y permisos. 


      

Descargo de responsabilidad: Debido a cambios en las leyes o reglamentos 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 para las configuraciones de seguridad mínimas efectivas para la protección de la PHI dentro de los productos Zendesk descritos anteriormente en este momento. Este documento no constituye una plantilla exhaustiva para todos los controles sobre dichos datos ni constituye asesoramiento legal. Cada suscriptor de Zendesk debe buscar su propio asesoramiento legal con respecto a sus requisitos de cumplimiento de HIPAA y debe hacer los cambios adicionales a sus configuraciones de seguridad de acuerdo con el análisis independiente de cada suscriptor, siempre que dichos cambios no contrarresten o degraden la seguridad de las configuraciones. descritos en este documento.

 

Change Log HIPAA Enabled Accounts:

 

10 de octubre de 2024

  • Se agregó la Sección I, Support, número 12 (CSAT) y se editó la Sección I, Support, número 11 (CSAT heredada) para acomodar la nueva funcionalidad. 

7 de marzo de 2024

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

 

25 de octubre de 2023

  • Introducción: Se aclaró el lenguaje de introducción para las cuentas habilitadas para HIPAA
  • Sección II, Guide and Gather, número 1 (Restricciones del centro de ayuda): reemplazó las restricciones de IP con artículos restringidos para aclaración

 

13 de abril de 2023

  • Sección I, Support, 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 alinearse con las mejores prácticas de la industria y se eliminó la referencia a los Términos de servicio de la API de REST (redundancia)
    • c) agregado para advertir sobre el uso de la autenticación básica para la API 
  • Sección II, Guía:
    • Número 1 (Restricciones del centro de ayuda): se agregó una referencia a los centros de ayuda cerrados o restringidos para alinearlos con la funcionalidad del producto
    • Número 5 (@menciones): Se agregó una opción para desactivar las @menciones para alinearlas con el producto funcionalidad 
  • Sección III, mensajería: 
    • Número 1 y 2 (canales de terceros y archivos adjuntos privados): se agregaron identificadoresde sección (i) y (ii) para mayor claridad
    • Número 2 (adjuntos privados): se agregó “URL y/o” para 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: se agregó toda la sección debido a que Sunshine Conversations en Zendesk Suite se convirtió en parte del BAA 
  • Sección V, Chat, número 3 (Espacio de trabajo de agente): pequeñas correcciones de redacción
  • Sección VIII, aplicaciones móviles, números 5-7 (análisis de malware, supresión, autenticación del usuario final): secciones completas agregadas para mayor transparencia

24 de febrero de 2023

  • Sección I. Support, número 3: se eliminó la distinción separada entre las restricciones de IP de Support y Chat porque la interfaz de usuario ahora está unificada.
  • Sección I. Support, número 5: aclaración adicional sobre el incumplimiento del requisito 
  • Sección I. Support, número 7: “El suscriptor no debe” cambió a “El suscriptor no debe”.
  • Sección IV. Chat, número 2: aclara que toda la funcionalidad de exportación de datos de Chat usando correo electrónico está prohibida, y no solo en el ámbito de las transcripciones y la canalización. 
  • Sección III. mensajería: se agregó toda la sección a la cuenta para la adición de la funcionalidad de mensajería de Zendesk al alcance del Acuerdo de socio comercial de Zendesk.

9 de julio de 2021

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

21 de enero de 2021

  • La adición del número 1.11 no permite la CSAT a menos 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 tener en cuenta que los Suscriptores modifican 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 la configuración).

Agosto de 2020

  • La adición de Explore Enterprise cubre una mayor capacidad para compartir paneles
  • Eliminación de la prohibición de archivos adjuntos de Chat (ahora se incluyen los requisitos de autenticación de Support )
  • Desambiguación de que la prohibición de ePHI en los campos personalizados se aplicaba específicamente al uso de Insights y no globalmente
  • Adición de una nueva sección que cubre los complementos para los servicios implementados, siendo "Conversaciones secundarias" la primera adición
  • Varias ediciones de gramática y formato (sin consecuencias para el contenido)

13 de julio de 2020:

  • Eliminación de ambigüedades con respecto al uso de SMS a través del Servicio en lugar del uso nativo de SMS para la 2FA en el producto. * Para evitar dudas, las advertencias de datos relacionadas con la ePHI en la sección 10 con respecto a los 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.

13 de diciembre de 2019 

  • permite prescindir de las restricciones de IP del agente cuando el caso de uso no permite tales restricciones siempre que se aplique la MFA en el acceso de los agentes.

17 de diciembre de 2019 

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

6 de noviembre de 2019

  • Se actualizó el artículo 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 detalla a continuación, o cualquier serie de configuraciones requeridas que se detallan a continuación, será en

por cuenta y riesgo del Suscriptor ya su entera discreción; y dicho incumplimiento eximirá a Zendesk y sus empleados, agentes y afiliados de cualquier responsabilidad con respecto a cualquier acceso no autorizado, o uso indebido o divulgación de los Datos de servicio del Suscriptor, incluida cualquier Información de salud protegida electrónica, que resulte de dicho incumplimiento por parte del Suscriptor. . "

  • Otros cambios incluyen
    • 1. la capacidad de usar SMS siempre que el suscriptor asuma toda la responsabilidad de asegurarse de que no haya PHI presente en dichas transmisiones.
    • 2. La capacidad de usar archivos adjuntos en Chat siempre que 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.

 

Cuentas habilitadas para HDS:

Todos los términos en mayúsculas que se usan en este documento tendrán el significado que se les da en el Anexo de términos de HDS del Acuerdo de Suscripción General de Zendesk ("Anexo de términos de HDS").
Zendesk y el Suscriptor han suscrito ciertos Términos de HDS que exigen que el Suscriptor implemente y cumpla con las siguientes configuraciones para todas y cada una de las Cuentas habilitadas para HDS antes de introducir cualquier Información de salud personal ("PHI") en los Servicios. Todos los términos en mayúsculas que se usan en este documento tendrán el significado que se les da en el Anexo de términos de HDS.
El incumplimiento por parte del Suscriptor de cualquier configuración en particular que se detalla a continuación, o cualquier serie de configuraciones requeridas que se detallan a continuación, será por cuenta y riesgo del Suscriptor y a su entera discreción; y dicho incumplimiento eximirá a Zendesk y a sus empleados, agentes y afiliados de cualquier responsabilidad con respecto al acceso no autorizado, o el uso indebido o la divulgación de los Datos de servicio del Suscriptor, incluida cualquier Información personal de salud electrónica, que resulte de dicho incumplimiento por parte del Suscriptor. .
Se deben establecer las siguientes configuraciones de seguridad mínimas para Zendesk Support y se reconocen en el Anexo de términos de HDS para cualquier cuenta habilitada para HDS:

 

Se deben establecer las siguientes configuraciones de seguridad mínimas para Zendesk Support y se reconocen en el Anexo de términos de HDS para cualquier cuenta habilitada para HDS:

  1. Autenticación de Secure Agent a través de uno de los dos métodos siguientes:
    1. Usar Zendesk Support nativo con configuración de contraseña: (i) establecida en “Alta”; o (ii) personalizado por el Suscriptor de manera que establezca requisitos no menos seguros que los establecidos en la configuración “Alta”. 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 estar desactivados; 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 "Alta" de Zendesk y activar y hacer cumplir la autenticación de 2 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 estar desactivados.
    3. Todas las opciones de autenticación que utilicen SSO como método de autenticación deben desactivar el acceso con contraseña.
  2. El cifrado Secure Socket Layer ("SSL") en la(s) cuenta(s) habilitada(s) para HDS debe permanecer activada en todo momento. Las cuentas habilitadas para HDS que utilizan un dominio que no sea zendesk.com deben establecer y mantener SSL alojado.
  3. El acceso de los agentes debe estar restringido a direcciones IP específicas bajo el control del Suscriptor para Support y Chata menos que el Suscriptor active la autenticación de varios factores para los agentes como se describe más arriba 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 dudas, “Acceso de agente” se refiere al 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 habilitada para HDS del Suscriptor permita llamadas a las interfaces de programación de aplicaciones de Zendesk ("API"), 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 permite crear, acceder, modificar o borrar Datos de servicio y PHI a través de dicho acceso y/o integraciones. Para acceder a dichas API, el Suscriptor deberá 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 los derechos sean aceptados por un usuario final.  Siempre que sea posible, el Suscriptor utilizará el enfoque y el esquema de autenticación OAuth 2.0. El Suscriptor le dará 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 de OAuth deben permitir el privilegio mínimo necesario para realizar las tareas requeridas.
    2. Enfoque de token de API de 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. Al usar este enfoque, el Suscriptor (i) usará un token único para cada servicio y le dará al token un nombre descriptivo que designe la función; (ii) no compartir tokens de API con terceros a menos que sea razonablemente necesario y de conformidad con los métodos de transmisión que están encriptados de extremo a extremo; (iii) reconocer que si el token de API se comparte con un tercero, y el Suscriptor se entera de una violación de datos de un tercero, el Suscriptor rotará el token asociado de inmediato; y (iv) como mínimo, rotar el token una vez cada ciento ochenta (180) días.  El Suscriptor deberá cumplir los Términos de servicio de la API de REST del Servicio. 
  5. El suscriptor debe activar "requerir autenticación para la descarga" para que se requiera autenticación para acceder a los archivos adjuntos.
  6. El Suscriptor debe aplicar sistemáticamente, en todos los terminales a los que acceden los agentes, administradores y propietarios, un protector de pantalla bloqueado con contraseña o una pantalla de inicio configurada para interactuar con un máximo de quince (15) minutos de inactividad del sistema.
  7. El Suscriptor no debe alterar los permisos de visualización que permiten a un usuario ver las actualizaciones de toda una organización ni alterar la configuración predeterminada que permite el acceso más allá de los propios tickets del usuario (a menos que el Suscriptor asuma toda la responsabilidad de garantizar que dichos usuarios tengan la aprobación del Suscriptor para acceder a todos los datos subsiguientes).
  8. El Suscriptor reconoce que Zendesk no es responsable de proteger las transmisiones de correo electrónico de los Usuarios finales y los Datos de servicio relacionados, antes de que se reciban en la cuenta de Zendesk Support del Suscriptor. Esto incluye cualquier PHI que se pueda pasar por correo electrónico a través de respuestas a tickets de Zendesk Support , incluidos, entre otros, comentarios de tickets o archivos adjuntos.
  9. El Suscriptor reconoce que Zendesk Support envía un correo electrónico a un Usuario final cuando el Agente del Suscriptor responde a un ticket de Zendesk Support .  De manera predeterminada, este correo electrónico contiene toda la correspondencia que el agente ha enviado al usuario final y podría incluir PHI. Para proteger aún más al Suscriptor, su cuenta de Zendesk Support debe configurarse para que solo avise al Usuario final de que un agente ha respondidoy requiera 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 utilizada a su exclusivo criterio en cualquier Servicio de Zendesk está respaldada por SMS y/o protocolos relacionados, lo que puede implicar la transmisión sin cifrar de mensajes que se envían hacia o desde los Servicios.  Como tal, la funcionalidad de los mensajes de texto debería:
    1. no se puede usar en una cuenta habilitada para HDS*, o
    2. si se usa, el Suscriptor asume toda la responsabilidad por el uso de dicha funcionalidad.

* Para evitar dudas, las advertencias de datos relacionadas con la ePHI en la sección 10 con respecto a los 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.

Las siguientes configuraciones de seguridad mínimas para los servicios de Zendesk Guide y Gather Services deben implementarse y se reconocen en el Anexo de términos de HDS para todas las cuentas habilitadas para HDS:

  1. El Suscriptor reconoce que los Servicios de Guide y Gather son públicos por naturaleza (siempre que no se aprovechen las restricciones de IP para los centros de ayuda “internos”) y, por lo tanto, el Suscriptor se asegurará de que los artículos de Zendesk Guide o el Servicio de Gather no incluyan PHI, ya sea a través del texto del como un archivo adjunto o una imagen dentro del artículo.
  2. El Suscriptor deberá desactivar la capacidad de los Usuarios finales para agregar comentarios en Zendesk Guide, o bien moderar y asumir la responsabilidad de eliminar la PHI de todos los comentarios.
  3. No se permitirá el uso por parte del Suscriptor de “Moderadores de la comunidad” que no sean empleados dentro del Servicio de Gather.

Las siguientes Configuraciones de seguridad mínimas para el servicio de Zendesk Chat deben implementarse y se reconocen en el Anexo de términos de HDS para cualquier cuenta habilitada para HDS:

  1. El Suscriptor limitará el acceso de los Agentes al Servicio de Zendesk Chat mediante la conexión y la autenticación a través del Servicio de Zendesk Support .
  2. El suscriptor deberá desactivar la canalización de correo electrónico.
  3. El Suscriptor no activará los "Espacios de trabajo de agente" a menos que asuma toda la responsabilidad de garantizar que (i) no haya ePHI presente en Chats, y/o (ii) que el Suscriptor permita que todos los Agentes vean dichos datos.

Se deben establecer las siguientes configuraciones de seguridad mínimas para el uso del servicio Zendesk Explore y se reconocen en el Anexo de términos de HDS para cualquier cuenta habilitada para HDS:

El Suscriptor reconoce que la ePHI 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 formato libre.

  1. Para cualquier instancia del Servicio dentro del alcance que contenga PHI, el Suscriptor (i) solo otorgará acceso a la interfaz de Explore a los agentes que puedan acceder a todos los tickets/llamadas/chats que puedan contener PHI en las instancias del Servicio principal, y (ii) 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 aprovecha la funcionalidad de "exportación", (i) el Suscriptor reconoce que la PHI puede transferirse al dispositivo que el Suscriptor permite para acceder a la interfaz del agente y todos los controles del operador 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) garantizar que dichas exportaciones no contengan PHI, o (b) que los servicios de correo electrónico utilizados para dichas transferencias puedan admitir el cifrado a través del protocolo de cifrado mínimo permitido por los estándares PCI vigentes en ese momento.

* Consideraciones especiales para el uso de Explore Enterprise:

El Suscriptor reconoce que el uso del Servicio Explore Enterprise puede implicar un mayor intercambio de datos y funcionalidades de exportación. El Suscriptor deberá:

  1. (i) asegurarse de que no haya ePHI en dichos paneles, y/o (ii) compartir los paneles solo con agentes, grupos, listas o usuarios finales que estén aprobados para ver y recibir dichos datos.
  2. aprovechar las restricciones de IP
  3. cuando se comparten paneles a través del Localizador uniforme de recursos (URL), el Suscriptor reconoce que en lugar de compartir con cuentas de usuarios individuales o grupales, los datos se compartirán mediante un vínculo de acceso. Por lo tanto, el Suscriptor deberá (i) activar la protección con contraseña, (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) sea rotado sin demora indebida en caso de sospecha o confirmación de exposición

Las siguientes configuraciones de seguridad mínimas para el uso de las aplicaciones móviles de Zendesk (o el acceso realizado por dispositivos móviles como teléfonos inteligentes o tabletas) deben implementarse y se reconocen en la Exposición de términos de HDS para cualquier cuenta habilitada para HDS:

  1. El uso debe incluir el cifrado a nivel de dispositivo
  2. Se aprovechará el acceso biométrico o con PIN establecido en la configuración de dispositivo más alta permitida
  3. Las notificaciones que permiten que los comentarios de los tickets aparezcan en las pantallas de bloqueo de dichos dispositivos serán desactivadas
  4. Los bloqueos de pantalla por inactividad deben estar activados y configurados para bloquearse en no más de 15 minutos de inactividad.

Aviso sobre la funcionalidad dentro del producto para los servicios asociados implementados ("complementos"):

  1. Collaboration Deployed Associated Service: “Conversaciones secundarias”. El Suscriptor reconoce que el uso de la funcionalidad “Conversación secundaria” puede implicar que se creen mensajes de “ticket secundario” o “Conversación secundaria” dentro de la instancia de Support del Suscriptor o se envíen desde ella a los destinatarios a través de un ticket, correo electrónico, Slack o integraciones (a discreción del Agente). Si el Suscriptor elige usar esta funcionalidad en una Cuenta habilitada para HDS, el Suscriptor asume toda la responsabilidad de (i) garantizar que no haya PHI presente en dichos mensajes, o (ii) si PHI pudiera estar presente en los mensajes, el Suscriptor es el único responsable por cualquier responsabilidad, costo, daño o perjuicio relacionado con la adquisición, el acceso, el uso o la divulgación no autorizados de la PHI como resultado del intercambio de mensajes a través de la funcionalidad “Conversación secundaria”.

Descargo de responsabilidad: Debido a cambios en las leyes o reglamentos 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 para las configuraciones de seguridad mínimas efectivas para la protección de la PHI dentro de los productos Zendesk descritos anteriormente en este momento. Este documento no constituye una plantilla exhaustiva para todos los controles sobre dichos datos ni constituye asesoramiento legal. Cada suscriptor de Zendesk debe buscar su propio asesoramiento legal con respecto a los requisitos de cumplimiento de HDS y debe hacer los cambios adicionales a sus configuraciones de seguridad de acuerdo con el análisis independiente de cada suscriptor, siempre que dichos cambios no contrarresten o degraden la seguridad de las configuraciones. descritos en este documento.

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