Búsquedas recientes


No hay búsquedas recientes

Craig Lima's Avatar

Craig Lima

Incorporación 14 abr 2021

·

Última actividad 02 ene 2025

Seguimientos

0

Seguidores

0

Actividad total

11

Votos

0

Suscripciones

3

RESUMEN DE LA ACTIVIDAD

Última actividad de Craig Lima

Craig Lima hizo un comentario,

ComentarioZendesk policies and agreements

Dec 27th, 2024, added section XII to incorporate Workforce Management “WFM” into HIPAA BAA scope

Ver comentario · Publicado 02 ene 2025 · Craig Lima

0

Seguidores

0

Votos

0

Comentarios


Craig Lima hizo un comentario,

ComentarioZendesk policies and agreements

Dec 16th 2024

1. Added section XI to incorporate Zendesk QA into scope 

2. Changed various instances of "Answer Bot" to "AI Agents" to denote naming convention changes and broader scope.

3. Changed various instances of “must” and “shall” to “should” to denote best practices philosophy of configs, as well as to reinforce the Subscriber responsibility for interpretation of HIPAA compliance vis-a-vis Admin / Owner configurations and use case implementation  https://support.zendesk.com/hc/en-us/articles/4408833510938-The-Zendesk-Shared-Responsibility-Model

Ver comentario · Publicado 17 dic 2024 · Craig Lima

0

Seguidores

0

Votos

0

Comentarios


Craig Lima creó un artículo,

ArtículoPolíticas de Zendesk
Gestión de personal de Zendesk (Tymeshift), Zendesk QA (Klaus) y la funcionalidad Ultimate están alojados en Google Cloud Platform (GCP) y podrían no estar disponibles para alojarse en las regiones enumeradas en esta página.

Regiones de AWS donde Zendesk aloja los Datos de servicio del suscriptor

Actualmente alojamos los Datos de servicio del suscriptor en las siguientes regiones de AWS:

  • EE.UU. Este (Norte de Virginia)
  • EE.UU. Este (Ohio)
  • EE.UU. Oeste (Oregón)
  • EEE (Irlanda)
  • EEE (Fráncfort)
  • UK (Londres)
  • Asia Pacífico (Tokio)
  • Asia Pacífico (Osaka)
  • Asia Pacífico (Sídney)

Acuerdos de ubicación de datos

Tenga en cuenta que Zendesk asume compromisos sobre la ubicación del hosting de los Datos de servicio del suscriptor solo si los suscriptores han comprado nuestro complemento Ubicación del centro de datos (ya sea como compra independiente del complemento Ubicación del centro de datos o bien porque el complemento Ubicación del centro de datos esté incluido dentro del plan de servicio comprado). Lea la Política de Hosting regional de datos aquí para conocer las excepciones a este compromiso.

Para mantener un equilibrio en la demanda, mejorar el rendimiento y ofrecer el mejor servicio, es posible que movamos los datos de la cuenta de una región a otra sin aviso.  Si la cuenta ha comprado el complemento Ubicación del centro de datos, nos aseguraremos de que los datos transferidos permanezcan en el país o dentro de los límites legales requeridos.

Obtener la dirección física del host de los Datos de servicio

A solicitud, podemos indicar la región de Amazon Web Services (AWS) (un área general que puede ser descrita por AWS como un país, una región geográfica dentro de un país, un estado o una ciudad) donde alojamos los Datos de servicio.

No podemos proporcionar la dirección física exacta de dónde se alojan los Datos de servicio debido a la manera en que AWS opera en términos técnicos.  Esto se debe a la arquitectura de AWS en sí.  AWS tiene "regiones" alrededor del mundo.  Dentro de estas regiones existe el concepto de “zonas de disponibilidad” o "AZ".  Cuando se crea un recurso en AWS, este se encuentra en una o más zonas de disponibilidad en una región en particular.  Independientemente de la preferencia del dueño del recurso sobre la replicación de datos dentro de una región o en distintas regiones, AWS por sí solo puede replicar los datos dentro de la región en otras zonas de disponibilidad.  El resultado es que los Datos de servicio del suscriptor de Zendesk existen en varias instalaciones dentro de una determinada región.  Además, por razones de seguridad, AWS no sanciona oficialmente la divulgación de la ubicación específica de sus edificios de centros de datos o instalaciones asociadas.

Si necesita saber en qué región de AWS está alojado su subdominio de Zendesk, contacte a Atención al cliente de Zendesk.

REGISTRO DE CAMBIOS:

Abril de 2024: se agregó una advertencia para Gestión de personal de Zendesk (Tymeshift) y Zendesk QA (Klaus)

Julio de 2024: se agregó una advertencia para Ultimate

Julio de 2024: se agregaron dos nuevas ubicaciones de hosting: UK (Londres), Asia Pacífico (Osaka)

 

Editado 26 jul 2024 · Craig Lima

5

Seguidores

1

Voto

0

Comentarios


Craig Lima creó un artículo,

ArtículoPolíticas de Zendesk

Modelo de responsabilidad compartida de Zendesk

Zendesk ofrece a muchas de las compañías líderes en distintos sectores alrededor del mundo una plataforma de servicio de atención al cliente que se puede configurar extensamente y ampliar rápidamente.  Cuando nuestros suscriptores aprovechan nuestra plataforma en la nube para satisfacer sus necesidades de servicio de atención al cliente, en efecto les estamos ayudando a reducir sus gastos, escalar según las demandas y facilitar interacciones increíblemente sencillas con sus clientes.

Trasladar el negocio a la nube genera los beneficios que acabamos de mencionar, pero también puede producir ambigüedad en relación a quién es responsable de qué control.  Pero no se preocupe que para eso hemos elaborado el Modelo de responsabilidad compartida:  un marco que deja claro qué parte es responsable de qué controles relacionados con la seguridad y la privacidad de los datos.  Bien puede ser un administrador meticuloso o un agente de seguridad empresarial, cumplimiento o privacidad, o cualquier otra persona que tenga a su cargo la configuración de los controles apropiados para el uso de los Servicios de Zendesk en su entorno, esta norma detalla claramente los límites que es necesario conocer.

Para resumirlo en una sola frase: “Zendesk se encarga de la seguridad del Servicio propiamente dicho, mientras que usted se encarga de la seguridad dentro de sus instancias particulares del Servicio”.  

  1. Controles de acceso e higiene
  2. Integraciones
  3. Datos, privacidad, cumplimiento y aspectos normativos
  4. Monitoreo
  5. Mantenimiento
  6. Incidentes de seguridad (roles y responsabilidades)
  7. Vínculos útiles
  8. Registro de cambios

Tenga en cuenta que los términos escritos con mayúsculas tienen el significado que se les atribuye en el Contrato de servicios principales de Zendesk (“MSA”).

I. Controles de acceso e higiene
El control del acceso a los sistemas confidenciales y los datos contenidos en ellos es un aspecto fundamental de los principios de seguridad. 

  1. El Suscriptor es responsable de todos los controles de acceso a sus instancias del Servicio, lo que comprende lo siguiente:
    1. Aprovisionar, modificar, asegurar la higiene continua, mantener el rigor de los privilegios y cancelar el aprovisionamiento de todos los usuarios, incluidos los usuarios finales y los agentes (bien sea en el propio local, a distancia o respecto a personal de terceros)
    2. Elegir y configurar el método de autenticación para ingresar al Servicio desde ofertas compatibles (puede incluir contraseñas, la autenticación de múltiples factores (MFA), el inicio de sesión único (SSO), etc.)
    3. Configurar y monitorear los aspectos del manejo de sesión como los cierres de sesión, dispositivos conectados, etc.
    4. Autorizar o desautorizar a nuestro personal de soporte para que pueda ingresar en su instancia de Support con el fin de prestar asistencia
    5. Configurar el acceso a los servicios de la API de REST de Zendesk (donde corresponda, incluidas las integraciones, el uso del Servicio Zendesk Sunshine, etc.) y comprender las repercusiones de su uso
    6. Configurar las restricciones de IP admitidas por los productos donde se deseen
    7. Tomar en cuenta los demás controles de acceso que no se relacionen con los productos, como qué tipos de dispositivos permitir que usen los agentes para acceder a sus instancias, así como los controles físicos, lógicos o de política que puedan aplicarse ya sea a sus usuarios o a los dispositivos permitidos
  2. Zendesk es responsable de todos los controles de acceso a los sistemas que son los pilares del Servicio, incluido lo siguiente:
    1. Mantener las políticas y los procedimientos necesarios para aprovisionar, modificar, asegurar la higiene continua, mantener el rigor de los privilegios y cancelar el aprovisionamiento de todos los usuarios de manera segura (bien sea en el propio local, a distancia o respecto a personal de terceros)
    2. Hacer cumplir el Control al acceso basado en roles (“RBAC”), el Principio de mínimo privilegio (“PLP”), la seguridad de credenciales apropiada, incluida la Autenticación de varios factores (“MFA”), en relación al acceso de todos los empleados y contratistas a sistemas y aplicaciones vitales que contienen Datos de servicio del Suscriptor
    3. Realizar verificaciones periódicas de todo lo anterior

II. Integraciones 
Aprovechar los recursos de terceros puede mejorar considerablemente la eficiencia, pero también introduce cuestiones de seguridad que hay que tener en cuenta.

  1. El Suscriptor es responsable de tener en cuenta las repercusiones de seguridad que pueden derivarse de aprovechar todas las integraciones de terceros con el Servicio, entre ellas:
    1. Las integraciones efectuadas a través de la API o el SDK
    2. Las integraciones efectuadas instalando aplicaciones del Marketplace o activando canales de terceros
    3. Las integraciones con cualquier tercero que ayude al Suscriptor al proporcionar personal, herramientas, código o prestar servicio directamente a las instancias de Zendesk
  2. Zendesk es responsable de integrar al Servicio a terceros que sean de confianza, por lo que debe:
    1. Investigar y practicar continuamente la diligencia debida en relación a todos los Subprocesadores
    2. Integrar las adquisiciones en el Servicio de manera segura
    3. Asegurarse de que las afiliaciones de productos o las integraciones del Servicio con terceros tengan en cuenta todos los aspectos de seguridad que corresponda 

III. Datos, privacidad, cumplimiento y aspectos normativos
Es imprescindible que se asigne la responsabilidad de los datos en uso, su tratamiento correcto, todo marco regulatorio que sea pertinente y la importancia de las garantías de terceros.

  1. El Suscriptor es responsable del tratamiento correcto de los datos que recibe y utiliza, lo cual incluye:
    1. Comprender los tipos de datos utilizados en su caso práctico en particular
    2. Tratar tales datos de conformidad con la clasificación de datos y las políticas de privacidad de su compañía, las leyes aplicables que tienen que ver con los datos mismos, los usuarios que los proporcionan, el sector al que pertenece el Suscriptor así como todas las jurisdicciones pertinentes
    3. Elegir qué canales permitir para la comunicación con las instancias del Servicio
    4. Dar mantenimiento a las instancias y a los Datos de servicio de conformidad con todo marco de cumplimiento, legal o normativo, dentro de cuyo ámbito de aplicación se encuentre el sector, los usuarios, o bien el caso práctico del Suscriptor
    5. Proporcionar a Zendesk certificados de TLS alternativos cuando se desee utilizar el mapeo de host a un dominio principal que no sea de Zendesk con el objeto de encriptar el tráfico hacia y desde la interfaz de usuario o las API de Zendesk
    6. Comprender dónde los datos podrían no ser encriptados en tránsito y tratar esos canales o protocolos como corresponde (principalmente el correo electrónico, SMS o integraciones de terceros que no admiten encriptación y que hayan sido realizadas a criterio exclusivo del Suscriptor)
    7. Garantizar que los tipos de datos utilizados en la instancia del Suscriptor no violen los términos y condiciones del Contrato de servicios principales de Zendesk (consulte el MSA de Zendesk)
    8. Asegurarse de que el nivel de disponibilidad y recuperación ante desastres que elija el Suscriptor respete las políticas o reglamentos aplicables al Suscriptor
  2. Zendesk es responsable de: 
    1. Proteger debidamente todos los Datos de servicio contra su divulgación a nivel de Servicio (es decir, en la infraestructura o el código)  
    2. Encriptar todos los datos en tránsito por redes públicas desde o hacia nuestra interfaz de usuario o nuestras API
    3. Encriptar todos los Datos de servicio en reposo
    4. Proporcionar a los Suscriptores información acerca de los datos obtenidos por las cookies dentro de los productos y acerca del uso predeterminado de los Servicios 
    5. Describir correctamente cómo usamos los Datos de servicio, incluidos los Datos personales, de manera anónima y no anónima para prestar nuestros Servicios o con algún otro fin
    6. Proporcionar a los Suscriptores las herramientas y funciones que les ayuden a cumplir sus obligaciones en relación al tratamiento adecuado de datos personales o datos reglamentados
    7. Cumplir las leyes y los marcos normativos aplicables a nuestras ofertas de Servicio y a los lugares donde se ubican nuestros negocios
    8. Obtener y ofrecer garantías de cumplimiento de parte de terceros independientes que tengan que ver con nuestras ofertas de Servicio

IV. Monitoreo
Para garantizar una seguridad adecuada, es necesario comprender bien los procesos y la actividad.  

  1. El Suscriptor es responsable de monitorear toda la actividad en sus instancias del Servicio, lo que comprende lo siguiente:
    1. Monitorear la actividad de los usuarios (ya sea a través de visualizaciones de la interfaz de usuario o de registros de las API)
    2. Practicar la debida diligencia en relación a las comunicaciones con personas desconocidas o contenido que no sea de confianza y que lleguen a través del Servicio
    3. Mantener registros o datos extraídos del Servicio de conformidad con todo reglamento pertinente
  2. Zendesk es responsable de monitorear los procesos y la actividad del propio Servicio, lo cual incluye:
    1. El acceso privilegiado y las actividades que ocurren dentro de la red de producción
    2. El tráfico entrante a fin de alertar o bloquear envíos o direcciones IP conocidos por ser perjudiciales
    3. La disponibilidad del Servicio
    4. El comportamiento anómalo dentro de los recursos de la red corporativa o de producción
    5. La seguridad del código, de la infraestructura, del tráfico y de los empleados pertinentes o contratistas

V. Mantenimiento
Para prevenir problemas de seguridad, es importante mantener los sistemas y el código al día y aplicar los parches debidos. 

  1. El Suscriptor es responsable de dar mantenimiento y aplicar los parches necesarios a todo sistema o código que se encuentre fuera del ámbito de la arquitectura y los contratos de Zendesk*, lo que incluye:
    1. Su propia infraestructura, es decir: puntos de acceso de los empleados, redes, infraestructura personalizada o middleware de terceros que se usen para tener acceso a los Servicios de Zendesk o para procesar aun más sus Datos de servicio antes de ingresar o al egresar de los sistemas de Zendesk.  
    2. Su propio código no estándar utilizado para proporcionar funcionalidad adicional a los Servicios de Zendesk, en concreto: código desarrollado internamente o código de terceros que el propio Suscriptor haya desarrollado o comprado para usar con los Servicios de Zendesk. Esto también incluye todo código personalizado desarrollado por los Servicios profesionales de Zendesk a petición de los Suscriptores, a condición de que la responsabilidad de tal código y su mantenimiento se haya cedido al Suscriptor como parte del compromiso personalizado.
  2. Zendesk es responsable de dar mantenimiento y aplicar los parches necesarios a todo sistema o código que se encuentre dentro del ámbito de su arquitectura y sus contratos, lo que incluye:
    1. Su propia infraestructura administrada lógicamente dentro de las instalaciones del proveedor de hosting que se utilizan para proporcionar los Servicios, como sistemas operativos, infraestructura de seguridad y sistemas bajo su control directo, sistemas de contenedores y orquestación, etc.
    2. Su propia infraestructura administrada física o lógicamente y utilizada dentro del entorno corporativo de Zendesk como los puntos de acceso de los empleados, la infraestructura de red corporativa, etc.
    3. Las bases de código de propiedad de Zendesk que constituyen los pilares de los Servicios de Zendesk.

* Observe que si bien las aplicaciones del Marketplace se ejecutan dentro del ámbito arquitectónico de Zendesk, estas no están cubiertas dentro del Contrato de servicios principales estándar de Zendesk, sino que están cubiertas bajo términos específicos acordados entre el Suscriptor y los propios desarrolladores de las aplicaciones, tal como se indica en los Términos de uso del Marketplace de Zendesk. El mantenimiento de las aplicaciones del Marketplace es responsabilidad de los terceros desarrolladores de las aplicaciones que se encuentran en el Marketplace.

VI. Incidentes de seguridad
A pesar de los mejores esfuerzos, a veces las cosas pueden salir mal.  Sin embargo, la manera de reconocer, responder y recuperarse de un incidente de seguridad es clave para mitigarlo exitosamente y mantener la confianza del cliente.  Esta sección describe los roles y las responsabilidades de cada parte durante incidentes de seguridad. 

  1. El Suscriptor es responsable de todo incidente o filtración de seguridad que ocurra dentro de sus instancias particulares que no haya sido ocasionado o producido por vulnerabilidades o incidentes dentro del Servicio propiamente dicho, lo cual incluye:  
    1. Investigar y corregir toda filtración presunta o real ocurrida dentro de su instancia particular y que sea ocasionada por (i) controles de acceso o higiene insuficientes (lo que incluye el uso de credenciales públicas débiles o explotables); (ii) monitoreo insuficiente de las actividades de los usuarios; (iii) falta de diligencia debida en las comunicaciones o el contenido que no es de confianza y que llega a través de las interacciones con los usuarios; o (iv) todo incidente o filtración que se derive de la integración con un tercero, en los casos en que tal integración se haya efectuado a criterio exclusivo del Suscriptor.
    2. Cumplir con toda obligación de dar notificación al gobierno o a las agencias del orden público o a los usuarios finales en relación a filtraciones causadas por acciones del Suscriptor, los terceros integrados o en relación a notificaciones de Filtración de datos de servicio recibidas de Zendesk respecto a la instancia del Suscriptor
  2. Zendesk es responsable de los controles para investigar los incidentes de seguridad, así como de notificar a los Suscriptores afectados sobre Filtraciones de datos de servicio que ocurran a través del servicio mismo, lo cual incluye: 
    1. Contar con una Política de respuesta a incidentes de seguridad documentada, y contar con personal con los roles y las responsabilidades pertinentes en materia de seguridad
    2. Investigar la actividad anómala
    3. Contener toda Filtración de datos de servicio que esté confirmada
    4. Notificar a los Suscriptores afectados o a las agencias del gobierno o del orden público correspondientes, si lo exige la ley
    5. Garantizar que existan procesos robustos para las copias de seguridad y para la recuperación ante desastres y que se hayan probado

VII. Vínculos útiles

Atención al cliente segura con la seguridad de Zendesk

Mejores prácticas de seguridad de Zendesk

Portal - Aspectos legales de Zendesk

Controles de acceso e higiene

Administración de la seguridad y el acceso del usuario en Zendesk Support (colección de vínculos)

Roles de usuario en Chat

Autenticación de los usuarios en Chat

Otorgar a Zendesk acceso temporal a una cuenta

Integraciones

API de Zendesk

Aplicaciones del Marketplace de Zendesk

Subprocesadores de Zendesk

Subprocesadores de Zendesk Connect

Socios de Zendesk

Datos, privacidad, cumplimiento y aspectos normativos

Política de cookies dentro de los productos de Zendesk

Contrato de servicios principales de Zendesk

Protección de los datos y la privacidad de Zendesk

Monitoreo

Registro de auditoría de cambios en la instancia de Support (IU / API)

Support: API del registro de auditoría de eventos de tickets

Panel de Chat

IU del historial de chats

Chat: API de exportaciones incrementales y en tiempo real (en inglés)

Panel de Talk

API incremental de Talk

API de objetos personalizados, eventos y perfiles de Sunshine (en inglés)

API en tiempo real/Firehose de Sell (en inglés)

 

Si tiene preguntas adicionales, escríbanos a security@zendesk.com  

VIII. Registro de cambios
16 de junio de 2023

  1. Adición de un registro de cambios
  2. Adición de la Sección V, Mantenimiento
  3. Aclaración del detalle de los incidentes ocasionados por el uso de credenciales débiles o explotables públicamente por parte de los Suscriptores y/o sus Usuarios finales que indica que es la responsabilidad del Suscriptor; referencia a la sección VI, "Incidentes de seguridad"

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.

Editado 08 may 2024 · Craig Lima

0

Seguidores

2

Votos

0

Comentarios


Craig Lima creó un artículo,

ArtículoPolíticas de Zendesk

¿Qué plan tengo?

Todos los planes de Zendesk Suite

Se necesita mucha confianza para poner los datos en la nube. A cambio, desea saber que los socios con los que comparte esta información consideran que la seguridad es una prioridad máxima. Nuestros Suscriptores usan distintos estándares y marcos para administrar la información confidencial, por lo que hemos implementado los siguientes puntos de referencia de la Organización Internacional de Normalización (ISO) en todos nuestros servicios para mantener sus datos seguros y en cumplimiento.

ISO 27001 

Los estándares ISO/IEC 27000 proporcionan una serie de marcos para ayudar a las organizaciones a comparar el tratamiento de los datos. El más común de estos estándares, “ISO/IEC 27001”, proporciona los requisitos para un Sistema de administración de seguridad de la información (SGSI) y la garantía de que se cumplen los requisitos para las organizaciones que completan una auditoría exitosa.

ISO 27018 

La norma ISO/IEC 27018 proporciona indicaciones basadas en la norma ISO/IEC 27002, y se concentra en la protección de la información personal de identificación (PII) para los proveedores de servicios en la nube, como Zendesk.

ISO 27701 

La norma ISO/IEC 27701:2019 especifica los requisitos y la orientación para establecer, implementar, mantener y mejorar continuamente un Sistema de gestión de la privacidad de la información (PIMS). Sirve como complemento de las normas ISO/IEC 27001 e ISO/IEC 27002 para la administración de la privacidad dentro de una organización. Esto establece un marco para la administración de los datos personales utilizados por los controladores de datos y los procesadores de datos, alineando los controles de seguridad y privacidad.

Servicios y procesos de Zendesk considerados en el alcance de esas auditorías

El alcance de las certificaciones ISO/IEC 27001:2013, ISO/IEC 27018:2014 e ISO/IEC 27701:2019 está limitado por la infraestructura de red global de Zendesk, Inc. y los productos y servicios correspondientes, incluida la administración del desarrollo, las operaciones, el mantenimiento y la entrega de Support, Guide, Chat, Connect, Inbox y Explore, que se administran de manera centralizada fuera de la sede de Zendesk y reciben soporte desde las siguientes ubicaciones de oficinas incluidas en el alcance: San Francisco, CA y Madison, WI (Estados Unidos de América), Copenhagen (Dinamarca), Dublin (Irlanda), Manila (Filipinas), Melbourne (Australia), Montpellier (Francia) y Singapur.

Además, se usa un proveedor de centro de datos de infraestructura como servicio (IaaS) para proteger la infraestructura que ejecuta todos los servicios ofrecidos en la IaaS. Nube. Los controles de seguridad de Zendesk para administrar el entorno de IaaS se incluyen en el alcance de este certificado, con la excepción de los controles físicos y ambientales.

Nuestro subprocesador para los servicios de hosting es actualmente AWS, que cuenta con varias certificaciones ISO propias. Si desea más información, consulte la página de cumplimiento aquí.

Lo que esto significa para nuestros clientes

Internamente, realizamos estas auditorías independientes para garantizar que nuestras funciones de administración de seguridad y privacidad cumplan con los estándares líderes de la industria. Para nuestros clientes, estas normas de cumplimiento con validación externa confirman que asumimos nuestras obligaciones en lo que se refiere a la manera de manejar sus datos. Además, ISO/IEC 27701 exige que las organizaciones declaren las leyes y los reglamentos aplicables como parte de sus criterios de auditoría, lo que permite que este estándar se corresponda con requisitos como el Reglamento General de Protección de Datos (GDPR), la Ley de Privacidad del Consumidor de California (CCPA) y otra legislación. .

Todos los clientes que usan los productos especificados reciben esta protección

Estas certificaciones corresponden a los servicios antes mencionados. No es necesario hacer pagos adicionales ni configurar las instancias para tener la protección de esas certificaciones.

Las certificaciones ISO 27001, ISO 27018 e ISO 27701 de Zendesk frente a las certificaciones de los clientes

Nuestras certificaciones ISO 27001, ISO 27018 e ISO 27701 cubren los procesos de administración de la seguridad y la privacidad en un ámbito específico de los servicios de Zendesk. Si desea obtener cualquiera de estas certificaciones mientras opera una parte de su servicio con Zendesk, tenga en cuenta que no obtendrá la certificación automáticamente por asociación. Sin embargo, nuestras certificaciones pueden facilitarle la obtención de estas certificaciones para su propia instancia.

Obtención de las certificaciones ISO de Zendesk

Puede acceder libremente a nuestros certificados ISO en cualquier momento, sin costo, sin NDA, completando el siguiente formulario: https://www.zendesk.com/product/zendesk-security/#anchor-security-resources

 

 

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.

Editado 08 may 2024 · Craig Lima

3

Seguidores

2

Votos

0

Comentarios


Craig Lima creó un artículo,

ArtículoPolíticas de Zendesk

Cuentas habilitadas para HIPAA y HDS (conjuntamente, "Cuentas habilitadas para el cuidado de la salud"):

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 de Zendesk ("BAA") o el Anexo de términos de HDS del Acuerdo de suscripción general de Zendesk ("Documento de HDS"), según corresponda al tipo de cuenta (colectivamente, “Acuerdo de atención médica”).

A los efectos de las Cuentas habilitadas HIPAA , “PHI” significa “Información de salud protegida”, y a los fines de las Cuentas habilitadas por HDS, “PHI” significa “Información de salud personal”.

Zendesk y el Suscriptor han celebrado 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 sus requisitos de cumplimiento conforme a la ley aplicable, para todas y cada una de las Cuentas habilitadas para atención médica (s) antes de introducir cualquier 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 PHI, que resulte de cualquier tales desviaciones 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).

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

Las siguientes configuraciones de seguridad mínimas para los servicios de Zendesk deben implementarse y se reconocen en el contrato de atención médica para cualquier cuenta habilitada para atención médica

I. Zendesk Support:

  1. Autenticación de Secure Agent a través de uno de los dos métodos siguientes:
    1. Usar Zendesk Support nativo con la configuración de contraseña: (i) establecida en “Recomendada”; o (ii) personalizado por el Suscriptor de manera que establezca requisitos no menos seguros que los establecidos en 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 estar desactivados; o
    2. Utilizar una solución externa de inicio de sesión único ("SSO") con requisitos establecidos que no sean 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 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 habilitadas para atención médica debe permanecer activado en todo momento. Las cuentas habilitadas para atención médica que utilizan un dominio que no sea zendesk.com deben establecer y mantener SSL alojado.
  3. Siempre que sea posible, 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 ("IU").
  4. En la medida en que la cuenta habilitada para atención médica 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 debe utilizar el enfoque y el esquema de autenticación OAuth 2.0. El Suscriptor debe 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 debe (i) usar un token único para cada servicio y darle 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 debe 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 debe 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 requerir 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 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 o grupos del usuario (a menos que el Suscriptor asuma toda la responsabilidad de garantizar que dichos usuarios sean aprobados por el Suscriptor para acceder a todos los 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 el cuidado de la salud*, 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 el cuidado de la salud*, 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 PHI 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 PHI en la sección 10 sobre 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 (siempre que no se utilicen artículos restringidos ni se utilice una instancia cerrada o restringida) y, por lo tanto, el Suscriptor debe asegurarse de que los artículos de 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 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 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 de contenido en el servicio de Zendesk Guide y configurarlo en "Moderar todo el contenido". No se debe aprobar ningún envío que contenga PHI.
  4. No se debe permitir que el Suscriptor use “Moderadores de la comunidad” que no sean empleados dentro del Servicio de Gather a menos que el Suscriptor asuma la responsabilidad del posible acceso de dichos Usuarios a los datos, incluida la posible PHI (cuando corresponda).
  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 las 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) celebre su propio BAA con plataformas de mensajería integradas.
  2. El Suscriptor debe 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 (por ejemplo, como parte de un flujo creado para Agentes de IA ) para API y 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 todos 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 debe (i) usar una clave de firma JWT única para cada canal de autenticación y darle 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 se entera de una violació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 la 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 los Usuarios finales y los Agentes de IA que no se entreguen a un Agente humano y se transfieran 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 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 los agentes de IA 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. 
  11. 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 atención médica, el Suscriptor asume toda la responsabilidad de (i) garantizar que no haya PHI presente en dichos mensajes, o (ii) si PHI podría 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”.

IV. Zendesk Sunshine Conversations:

  1. El Suscriptor no debe activar las integraciones de canales de terceros a menos que asuma toda la responsabilidad de garantizar 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 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 debe utilizar el enfoque y el esquema de autenticación de OAuth 2.0. El Suscriptor debe 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 debe (i) usar un token único para cada servicio y darle 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 debe 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 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 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 debe desactivar la capacidad de los Usuarios finales para adjuntar archivos a las conversaciones de Sunshine Conversations , y asumir toda la responsabilidad de activar los 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 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 debe (i) usar una clave de firma JWT única para cada canal de autenticación y darle 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 se entera de una violació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 la 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 los Usuarios finales y los Agentes de IA 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 los agentes de IA 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. Zendesk Chat:

  1. El Suscriptor debe limitar el acceso de los Agentes al Servicio de Zendesk Chat acoplando y autenticando 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 las exportaciones por correo electrónico desde el panel de Chat
  3. El Suscriptor asume toda la responsabilidad de garantizar que (i) no haya PHI presente en los Chats, y/o (ii) que el Suscriptor permita que todos los Agentes vean dichos datos.

VI. Servicio Zendesk Explore :

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 formato libre.

  1. Para cualquier instancia del Servicio que contenga 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 del Servicio principal, y (ii) deben 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 ser transferida 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 exista PHI en dichos paneles, y/o (ii) compartir 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 debe (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 atención médica, el Suscriptor asume toda la responsabilidad de (i) garantizar que no haya PHI presente en dichos mensajes, o (ii) si PHI podría 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. Aplicaciones móviles de Zendesk (o acceso realizado por dispositivos móviles como teléfonos inteligentes o tabletas):

  1. El uso debe incluir el cifrado a nivel de dispositivo
  2. Se debe 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 deben desactivarse
  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 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.
  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 Support .

IX. Zendesk Insights: el soporte para este servicio quedó obsoleto a partir del 5 de febrero de 2021.   

X. Aviso sobre la funcionalidad de IA de Zendesk (“ IA de Zendesk”, “IA avanzada”, “IA generativa”, 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 alguna función de IA generativa, los resultados de IA generados 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 conversación de Agentes de IA 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 de Escritura mejorada en el Centro de administración, esta funcionalidad se activará para todos los agentes de su instancia, independientemente de sus roles y permisos. 

XI. Zendesk QA

  1. El Suscriptor reconoce que las funciones de IA de Zendesk QA tienen como objetivo 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, diagnóstico o tratamiento de un profesional de la salud, (v) o proporcionar información a un Usuario o tomar decisiones de 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, como así como las posibles implicaciones de usar la IA de esa manera).
  2. El Suscriptor reconoce que la eliminación o la supresión en su instancia de Zendesk no se sincronizan de inmediato con el Zendesk QA , sino que se transferirán en las siguientes 3 a 6 horas.
  3. Al usar la funcionalidad de encuestas, el Suscriptor debe (i) desactivar la funcionalidad de asistencia de IA Zendesk QA (o asegurarse de que todos los agentes que realizan el trabajo de QA tengan autorización 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 se revele la 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. Al usar 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 al usar la API de Sunshine Conversations para borrar partes de una conversación de Zendesk Messaging, este cambio no se refleja en el Zendesk QA. En su lugar, la información debe eliminarse del ticket original mediante supresión o toda la conversación debe eliminarse.
  6. El Suscriptor reconoce que el Zendesk QA no admite 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 se deben usar 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 con las provisiones iniciales del Zendesk QA, la configuración de la conexión avanzada 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 la configuración de los agentes aplicables al servicio de Gestión de personal (incluidas las etiquetas mencionadas en el punto 2 a continuación).
    2. El rol de agente predeterminado tiene acceso a la actividad del agente a menos que los administradores lo configuren para tener un 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, los Administradores o la lógica predefinida del sistema dentro de los tickets en Support serán visibles dentro del producto Gestión de personal para cualquier Usuario que tenga permiso para ver la actividad de los tickets. Si el suscriptor considera que las etiquetas son confidenciales, el acceso debe configurarse adecuadamente.

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 o 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 descritas en este documento.

 


Registro de cambios:

24 de enero de 2025

  • Configuraciones consolidadas de HIPAA y HDS

27 de diciembre de 2024

  • Se agregó la sección XII para incorporar Gestión de personal de Zendesk ("Gestión de personal") en el alcance

16 de diciembre de 2024

  • Se agregó la sección XI para incorporar el Zendesk QA en el alcance
  • Se cambiaron varias instancias de "Answer Bot" a "IA Agents" para indicar cambios en la convención de nomenclatura y un alcance más amplio.

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 heredado) para adaptarse a 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 estilode 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.

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.

Editado 28 ene 2025 · Craig Lima

0

Seguidores

1

Voto

0

Comentarios


Craig Lima hizo un comentario,

ComentarioZendesk policies and agreements

July 9th 2021 edit:

1. Adds point 3. under Chat section for responsibilities around Agent Workspace usage.

Ver comentario · Publicado 09 jul 2021 · Craig Lima

0

Seguidores

0

Votos

0

Comentarios


Craig Lima hizo un comentario,

ComentarioZendesk policies and agreements

January 21st, 2021

Addition of number 1.11 disallows CSAT unless Subscriber assumes responsibility of data sent via email as part of the survey. 

Caveat in number 1.7 to make allowances for Subscribers altering viewing permissions due to users already having approval to access such data on their ends.

Updated entire document to match company stle of embedded links within text as opposed to inline URLs (no impact to configuration content). 

Ver comentario · Publicado 21 ene 2021 · Craig Lima

0

Seguidores

0

Votos

0

Comentarios