Contas habilitadas HIPAA e HDS (coletivamente "Contas habilitadas para saúde"):

Todos os termos em letras maiúsculas usados neste documento terão os significados fornecidos no Contrato de Associação de Negócios da Zendesk ("BAA") ou na Exibição de Termos da HDS no Contrato do Cliente da Zendesk ("Exibição da HDS"), conforme aplicável ao tipo de conta (coletivamente, "Contrato de Saúde").

Para fins de contas com HIPAA, "PHI" significa "Informações de Saúde Protegidas" (conforme a sigla em inglês, Protected Health Information) e, para fins de contas com HDS, "PHI" significa "Informações de Saúde Pessoais".

A Zendesk e o Assinante concluíram um Contrato de Saúde que recomenda ao Assinante avaliar e implementar, conforme apropriado para o seu caso de uso, as configurações a seguir, ou alternativas avaliadas pelo Assinante para atender de outra forma aos requisitos de conformidade de acordo com a lei aplicável, para qualquer e todas as contas habilitadas para o atendimento de saúde antes de introduzir qualquer PHI no Serviço.

Se o Assinante optar, a seu exclusivo critério, por renunciar à implementação de qualquer uma das configurações recomendadas listadas abaixo, o Assinante assume a responsabilidade exclusiva por qualquer acesso não autorizado ou uso indevido da divulgação dos Dados de Serviço do Assinante, incluindo qualquer PHI, resultante de qualquer desvio dessas configurações recomendadas pelo Assinante.

O Assinante deve ter adquirido os planos de serviço no nível apropriado e ter os complementos associados necessários (consulte o seu representante de vendas se não tiver certeza).

Se o Assinante tiver uma Conta habilitada para HDS, o Assinante deve clicar no botão “Seguir” na Política de Subprocessadores da Zendesk para receber notificações de quaisquer alterações nos subprocessadores usados para fornecer o(s) Serviço(s).

As seguintes configurações mínimas de segurança para os Serviços Zendesk devem ser implementadas e são reconhecidas no Contrato de atendimento médico para qualquer conta habilitada para o atendimento médico.

I. Zendesk Support:

  1. Autenticar o agente por um dos dois métodos a seguir:
    1. Empregar Zendesk Support nativo com configurações de senha: (i) definido como “Recomendado”; ou (ii) personalizado pelo Assinante de uma maneira que estabeleça requisitos não menos seguros do que os estabelecidos na configuração “Recomendado”. Além disso, sob a opção nesta subseção, o Assinante também deve ativar e impor a Autenticação de dois fatores ("2FA") nativamente no Serviço; e, os controles administrativos que permitem que os administradores definam senhas para os Usuários Finais devem ser desativados; ou
    2. Usar uma solução externa de single sign-on ("SSO") com requisitos estabelecidos não menos seguros do que os estabelecidos na configuração de senha "Recomendado" do Zendesk e ativar e impor a autenticação de dois fatores na solução selecionada para o acesso de todos os agentes. Os controles administrativos que permitem que os administradores definam senhas para os Usuários finais devem ser desativados.
    3. Todas as opções de autenticação que utilizam o SSO como método de autenticação devem desativar o acesso por senha.
  2. A criptografia Secure Socket Layer ("SSL") em contas habilitadas para saúde deve permanecer ativada em todos os momentos. As contas com assistência médica que utilizam um domínio diferente do zendesk.com devem estabelecer e manter SSL hospedado.
  3. Se possível, o acesso do agente deve ser restritos a endereços IP específicos sob o controlo do Assinante , a menos que o Assinante ative a autenticação multifator para agentes conforme descrito acima nos requisitos 1.a ou 1.b (nativamente no Serviço ou no ambiente do Assinante em conjunto com o SSO corporativo).  Para evitar dúvidas, “Acesso do agente” significa o acesso concedido a um agente humano que acessa Dados do Serviço através da Interface do Usuário (“UI”).
  4. Na medida em que a Conta habilitada para o atendimento médico do Assinante permita chamadas para a(s) Interface(s) de Programação de Aplicativos da Zendesk ("APIs"), o Assinante assume toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros autorizadas a criar, acessar, modificar ou apagar Dados de Serviço e PHI através desse acesso e/ou integrações. Para o acesso a essa API, a Zendesk oferece vários métodos conforme descrito aqui e o Assinante deve implementar as seguintes práticas recomendadas de segurança com base no modelo da API usado:
    1. Abordagem OAuth 2.0.  Esse modelo fornece os recursos de segurança mais granulares, mas requer que as permissões sejam aceitas por um Usuário Final.  Sempre que possível, o Assinante deve utilizar a abordagem e o esquema de autenticação OAuth 2.0. O Assinante deve fornecer a cada cliente OAuth uma função descritiva e exclusiva de designação de Nome do cliente e Identificador exclusivo. As permissões concedidas para cada token OAuth devem permitir o mínimo de privilégio necessário para realizar as tarefas necessárias.
    2. Abordagem de token da REST API.  Esse modelo é o mais amplo e permite que um token da API utilize toda a funcionalidade do modelo da API. Por sua natureza, ele fornece o acesso e os recursos mais amplos e deve ser usado com cautela. Ao usar essa abordagem, o Assinante deve (i) usar um token exclusivo para cada serviço e dar ao token uma função descritiva de designação de nome; (ii) não compartilhar tokens da API com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se o token da API for compartilhado com um terceiro e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve rotacionar o token associado imediatamente; e (iv) no mínimo, rotacionar o token com frequência de acordo com as políticas da organização do Assinante.
    3. Quando possível, o Assinante deve desativar o acesso por senha à API, pois essa abordagem envia as credenciais do usuário com cada solicitação, o que os expõe amplamente, tornando-os mais facilmente interceptados por partes maliciosas.
  5. O Assinante deve ativar ‘requer autenticação para download’ para solicitar autenticação para acessar anexos. Não fazer isso significa que qualquer anexo não restrito pode ser acessado por qualquer pessoa com acesso à URL correta desse anexo. Nesses casos, o Assinante assume toda a responsabilidade pelo conteúdo e acesso a tais dados anexados.
  6. O Assinante deve aplicar sistematicamente, em todos os pontos de extremidade acessados por Agentes, Administradores e Responsáveis, um protetor de tela ou tela de inicialização com senha bloqueada definido para interagir com um máximo de quinze (15) minutos de inatividade do sistema.
  7. O Assinante não deve alterar as permissões de visualização que permitem que um usuário veja atualizações de uma instância/marca/organização inteira ou alterar a configuração padrão que permite o acesso além dos próprios tickets ou grupos do usuário (a menos que o Assinante assuma toda a responsabilidade de garantir que esses usuários sejam aprovados pelo Assinante para acessar todos os dados subsequentes). O Assinante reconhece que os fluxos de trabalho automatizados e os recursos de encaminhamento podem atribuir tickets a Agentes ou Grupos de Agentes, concedendo assim acesso a esses tickets, e o Assinante deve configurar esses fluxos de trabalho para garantir que apenas os Agentes sejam atribuídos e recebam acesso de acordo com as permissões previstas do Assinante e os requisitos de privilégios mínimos. O Assinante reconhece que as permissões da organização do Usuário Final podem ser definidas no perfil do usuário e na própria organização e, se as configurações forem conflitantes, a configuração mais permissiva substitui a configuração menos permissiva.
  8. O Assinante reconhece que a Zendesk não é responsável pela segurança das transmissões de e-mail de Usuários Finais e Dados de Serviço relacionados antes de serem recebidos na instância do Zendesk Support do Assinante. Isso inclui qualquer PHI que possa ser transmitido por e-mail através de respostas a tickets do Zendesk Support, incluindo, mas não limitado a, comentários ou anexos de tickets.
  9. O Assinante reconhece que o Zendesk Support envia notificações aos Usuários finais em várias circunstâncias, por exemplo, quando um Agente do Assinante responde a um ticket do Zendesk Support por meio do canal de e-mail ou iniciado por uma automação ou gatilho. Por padrão, as notificações podem conter correspondência entre os agentes/administradores do Assinante e os usuários finais ou outras informações configuradas para serem incluídas em uma notificação automatizada, o que potencialmente pode incluir o PHI. Para proteger ainda mais o Assinante, sua instância do Zendesk Support deve ser configurada para alertar apenas o Usuário Final de que um Agente respondeu ou sua correspondência no Zendesk foi atualizada e exigir que o Usuário Final se autentique no Zendesk Support para ver o conteúdo da mensagem.
  10. O Assinante reconhece que qualquer funcionalidade de mensagem de texto aproveitada a seu exclusivo critério em qualquer Serviço da Zendesk é apoiada por SMS e/ou protocolos relacionados, o que pode envolver a transmissão sem criptografia de mensagens enviadas para ou fora do Serviço(s).  Como tal, a funcionalidade de mensagem de texto deve:
    1. não ser usado em uma conta com acesso à saúde*, ou
    2. se usado, o Assinante assume toda a responsabilidade pelo uso dessa funcionalidade
  11. O Assinante reconhece que o uso da funcionalidade legada de Pesquisas de satisfação do cliente (“CSAT legado”) do Serviço envia Dados do Serviço (que podem conter PHI) associados ao ticket do Support por e-mail para obter a classificação do usuário, cujo status de criptografia não é controlado pela Zendesk. Assim, a funcionalidade legada CSAT deve:
    1. não ser usado em uma conta com acesso à saúde*, ou
    2. se usado, o Assinante assume toda a responsabilidade pelo uso dessa funcionalidade
  12. O Assinante reconhece que o uso da funcionalidade Pesquisas de Satisfação do Cliente do Serviço ("CSAT") para o canal de tickets, se não configurado adequadamente, envia Dados de Serviço (que podem conter PHI) associados ao ticket de suporte por e-mail para obter a classificação do usuário, cujo status de criptografia não é controlado pela Zendesk. Além disso, qualquer pessoa com a URL de CSAT específica tem acesso às respostas fornecidas para um ticket específico. Assim, ao usar a funcionalidade CSAT para o canal de tickets, o Assinante deve
    1. Configure o corpo do e-mail de automação CSAT para não incluir o potencial PHI e use o placeholder de {{satisfaction.survey_url}} exclusivamente
    2. Não usar a funcionalidade de perguntas abertas

* Para evitar dúvidas, as advertências de dados relacionadas ao PHI na seção 10 sobre SMS não se aplicam ao uso de 2FA no produto (conforme descrito na seção 1.a), pois essa funcionalidade apenas envia uma cadeia de caracteres numérica para verificação de identidade.

II. Zendesk Guide e Gather:

  1. O Assinante reconhece que os Serviços do Guide e do Gather são públicos por natureza (quando não utilizam artigos restritos ou usando uma instância fechada ou restrita) e, portanto, o Assinante deve garantir que quaisquer artigos no Zendesk Guide ou no Serviço do Gather não incluam PHI, seja através do texto do artigo ou como anexo ou imagem dentro do artigo.
  2. O Assinante deve desativar a capacidade dos Usuários Finais de adicionar comentários no Zendesk Guide, ou deve moderar e assumir a responsabilidade de remover o PHI de todos os comentários (conforme indicado na seção 3 abaixo).
  3. Se o Serviço do Zendesk Guide for Guide Professional ou Enterprise, os Assinantes devem, quando possível, desativar a capacidade dos usuários finais de criar novas publicações desativando a funcionalidade Gather com o Zendesk Guide, ou quando desativar os recursos do Gather não puderem ser usados devido ao caso de uso pretendido do Assinante, os Assinantes devem ativar a moderação do conteúdo no Serviço do Zendesk Guide e definir para "Moderar todo o conteúdo". Nenhuma apresentação contendo PHI deve ser aprovada.
  4. O uso do Assinante de “Moderatores da Comunidade” não funcionários no Serviço do Gather não deve ser permitido, a menos que o Assinante assuma a responsabilidade pelo possível acesso desses Usuários aos dados, incluindo o possível PHI (quando aplicável).
  5. O Assinante reconhece que “@menções” de membros da comunidade do Gather são possíveis quando permitem que os usuários finais tenham perfis públicos e se essa funcionalidade for considerada um risco em seu caso de uso, os perfis públicos devem ser desativados ou @menções devem ser desativadas.
     

III. Mensagens da Zendesk:

  1. O Assinante não deve ativar Integrações de canais de mensagens de mídia social a menos que assuma a responsabilidade total de (i) garantir que nenhum PHI esteja presente nas mensagens de mídia social ou (ii) concluir seu próprio BAA com plataformas de mensagens integradas.
  2. O Assinante deve desativar a capacidade dos Usuários Finais de anexar arquivos às conversas por mensagem e deve assumir toda a responsabilidade por (i) ativar anexos seguros ou (ii) garantir que os Agentes não anexem arquivos contendo ePHI às conversas por mensagem. Não fazer isso significa que qualquer anexo não restrito pode ser acessado por qualquer pessoa com acesso à URL correta desse anexo.  Nesses casos, o Assinante assume toda a responsabilidade pelo conteúdo e pelo acesso a tais URLs e/ou dados de anexos.
  3. O Assinante assume toda a responsabilidade de garantir que todos os agentes e agentes light tenham permissão para visualizar todas as mensagens recebidas de todos os Usuários Finais.
  4. Se o Assinante ou seus Agentes acessarem ou desenvolverem integrações (por exemplo, como parte de um fluxo criado para Agentes de IA) para APIs e webhooks ou personalizarem a experiência de mensagens, o Assinante assume toda a responsabilidade de entender as implicações de privacidade e segurança de todos os fluxos de trabalho personalizados e de todas as entidades do Assinante ou de terceiros (incluindo provedores de chatbots) autorizadas a criar, acessar, modificar ou apagar Dados de Serviço e ePHI por meio desses acessos e/ou integrações.
  5. Se o Assinante desejar remover a permissão de um Agente para participar de uma conversa por mensagem enquanto a conversa por mensagem estiver ativa no momento, o Assinante terá toda a responsabilidade de forçar a rescisão do acesso desse Agente ao Zendesk.
  6. Por padrão, as conversas do Web Widget com os Usuários Finais são persistentes e poderão ser visualizadas pelo Usuário Final quando retornarem ao chat da Web pelo mesmo dispositivo. O Assinante deve desativar esse recurso ou assumir toda a responsabilidade de garantir que os Usuários finais não estejam compartilhando dispositivos.
  7. Se o Assinante desejar implementar a autenticação para os Usuários Finais, o Assinante terá toda a responsabilidade de implementar isso de maneira segura de acordo com as práticas recomendadas e os padrões do setor.
    1. Ao usar esta abordagem, o Assinante deve (i) usar uma chave de assinatura JWT exclusiva para cada canal de autenticação e dar ao token uma função de designação de nome descritiva; (ii) não compartilhar chaves de assinatura JWT com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se a chave de assinatura JWT for compartilhada com um terceiro e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve girar a chave de assinatura JWT associada imediatamente; e (iv) pelo menos, girar a chave de assinatura JWT frequentemente de acordo com as políticas da organização do Assinante.
    2. O assinante deve usar o atributo JWT de validade e definir seu valor para não mais de 15 minutos.
  8. O Assinante reconhece que as interações entre Usuários Finais e Agentes de IA que não são entregues a um agente humano e transferidas para um ticket ainda são armazenadas no sistema e é responsabilidade do Assinante apagar essas interações de acordo com suas obrigações (por exemplo, implementando um webhook que alerta o Assinante quando essas conversas são armazenadas e (automaticamente) aciona a exclusão por meio da API Sunshine Conversations). 
  9. O Assinante reconhece que as conversas entre Usuários Finais e Agentes de IA que foram transformadas em um ticket não podem ser suprimidas no momento. A exclusão é possível apagando o ticket. 
  10. O Assinante reconhece que os anexos do Usuário Final em canais de mensagens não são verificados para malware no Zendesk. O Assinante assume toda a responsabilidade de ter procedimentos e políticas para mitigar o risco para os ativos do Assinante. 
  11. O Assinante reconhece que o uso da funcionalidade "Conversa paralela" pode implicar a criação de mensagens de "ticket dependente" e/ou "conversa paralela" dentro ou enviadas da instância do Assinante do soporte para os destinatários por meio de tickets, e-mail, Slack ou integrações (na configuração de critério do agente). Se o Assinante optar por usar essa funcionalidade em uma conta habilitada para o atendimento médico, o Assinante assume toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente nessas mensagens, ou (ii) se a PHI puder estar presente nas mensagens, o Assinante será o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizada da PHI resultante da troca de mensagens por meio da funcionalidade "Conversa paralela".

IV. Zendesk Sunshine Conversations:

  1. O Assinante não deve ativar Integrações de canais de terceiros a menos que assuma toda a responsabilidade de assegurar (i) que não haja PHI nas mensagens de canais de terceiros ou (ii) conclua seu próprio BAA com plataformas de mensagens integradas.
  2. O Assinante assume toda a responsabilidade de compreender as implicações de segurança de todos os Assinantes ou entidades terceirizadas autorizados a criar, acessar, modificar ou apagar Dados de Serviço e PHI através das Interfaces de Programação de Aplicativos do Sunshine Conversations ("APIs"). Para acessar essas APIs, o Assinante deve implementar as seguintes práticas recomendadas de segurança com base no modelo da API usado:
    1. Abordagem OAuth 2.0.  Esse modelo fornece os recursos de segurança mais granulares, mas requer que as permissões sejam aceitas por um Usuário Final.  Sempre que possível, o Assinante deve utilizar a abordagem e o esquema de autenticação OAuth 2.0. O Assinante deve fornecer a cada cliente OAuth uma função descritiva e exclusiva de designação de Nome do cliente e Identificador exclusivo. 
    2. Abordagem de token da REST API.  Esse modelo é o mais amplo e permite que um token da API utilize toda a funcionalidade do modelo da API.  Por sua natureza, ele fornece o acesso e os recursos mais amplos e deve ser usado com cautela. Ao usar essa abordagem, o Assinante deve (i) usar um token exclusivo para cada serviço e dar ao token uma função descritiva de designação de nome; (ii) não compartilhar tokens da API com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se o token da API for compartilhado com um terceiro e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar o token associado imediatamente; e (iv) alternar o token com frequência de acordo com a política da organização do Assinante.  
    3. Se o Assinante ou seus agentes acessarem ou desenvolverem integrações para APIs e webhooks ou personalizarem a experiência do Sunshine Conversations, o Assinante terá toda a responsabilidade de entender as implicações de privacidade e segurança de todos os fluxos de trabalho personalizados e de todas as entidades do Assinante ou de terceiros (incluindo provedores de chatbots) autorizadas a criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio desse acesso e/ou integrações.
  3. O Assinante reconhece que as restrições de IP configuradas para o Zendesk Support não se estendem à API do Sunshine Conversations. Os Assinantes assumem toda a responsabilidade de restringir o acesso à API e tokens da API do Sunshine Conversations conforme descrito em 2.b. e de acordo com as políticas do Assinante. 
  4. O Assinante deve desativar a capacidade dos Usuários Finais de anexar arquivos às conversas do Sunshine Conversations e deve assumir a responsabilidade total de ativar anexos seguros ou garantir que os Agentes não anexem arquivos contendo PHI às conversas por mensagem. Não fazer isso significa que qualquer anexo não restrito pode ser acessado por qualquer pessoa com acesso à URL correta desse anexo. Nesses casos, o Assinante assume toda a responsabilidade pelo conteúdo e pelo acesso a esses dados de anexo.
  5. Se o Assinante desejar implementar a Autenticação para Usuários Finais, o Assinante terá toda a responsabilidade de implementá-la de maneira robusta de acordo com as práticas recomendadas de segurança e os padrões do setor.
    1. Ao usar esta abordagem, o Assinante deve (i) usar uma chave de assinatura JWT exclusiva para cada canal de autenticação e dar ao token uma função de designação de nome descritiva; (ii) não compartilhar chaves de assinatura JWT com terceiros, a menos que seja razoavelmente necessário e de acordo com métodos de transmissão que são criptografados de ponta a ponta; (iii) reconhecer que, se a chave de assinatura JWT for compartilhada com um terceiro e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve girar a chave de assinatura JWT associada imediatamente; e (iv) pelo menos, girar a chave de assinatura JWT frequentemente de acordo com as políticas da organização do Assinante.
    2. O assinante deve usar o atributo JWT de validade e definir seu valor para não mais de 15 minutos.
  6. O Assinante reconhece que as interações entre Usuários Finais e Agentes de IA que não são entregues a um agente humano e transferidas para um ticket ainda são armazenadas no sistema e é responsabilidade do Assinante apagar essas interações de acordo com suas obrigações, por exemplo, implementando um webhook que alerta o Assinante quando essas conversas são armazenadas e (automaticamente) aciona a exclusão por meio da API Sunshine Conversations 
  7. O Assinante reconhece que as conversas entre Usuários Finais e Agentes de IA que se transformaram em um ticket não podem ser suprimidas no momento. A exclusão é possível apagando o ticket. 
  8. O Assinante reconhece que as mensagens apagadas pela API do Sunshine Conversations são apagadas apenas para os Usuários Finais, mas não no Espaço de trabalho do agente do Zendesk. Isso pode ser alcançado com a exclusão do próprio ticket ou o uso da funcionalidade Supressão (limitações, consulte 7.). 
  9. O Assinante reconhece que todos os anexos nos canais do Sunshine Conversations não são verificados para malware no Zendesk. O Assinante assume toda a responsabilidade de ter procedimentos e políticas para mitigar o risco para os funcionários do Assinante. 

V. Zendesk Chat:

  1. O Assinante deve limitar o acesso dos Agentes ao Serviço Zendesk Chat ao se conectar e autenticar pelo Serviço Zendesk Support.
  2. O Assinante não deve enviar transcrições do Chat por e-mail (a) desativando o encaminhamento por e-mail, (b) desativando a opção de transcrição do chat por e-mail no Web Widget Clássico e (c) não compartilhando exportações por e-mail do painel do Chat
  3. O Assinante assume toda a responsabilidade de garantir que (i) nenhum PHI esteja presente nos Chats e/ou (ii) todos os Agentes tenham permissão do Assinante para visualizar esses dados.

VI. Serviço Zendesk Explore:

O Assinante reconhece que o PHI pode ser exibido no produto Explore por meio de nomes de usuário, títulos de ticket, opções de campo e formulário e qualquer conteúdo encontrado em campos de texto de formulário livre.

  1. Para todas as instâncias do Serviço no escopo que contenham PHI, o Assinante deve (i) conceder acesso à interface do Explore apenas a agentes que possam acessar todos os tickets/chamadas/chats que possam conter PHI nas instâncias do Serviço principal e (ii) conceder esse acesso levando em consideração o mínimo de privilégios necessários para o uso do Explore em seu ambiente. Para obter mais informações sobre como configurar níveis de acesso no Explore, consulte aqui.
  2. No aproveitamento da funcionalidade de "exportação", (i) o Assinante reconhece que o PHI pode ser transferido para um dispositivo permitido pelo Assinante para acessar a interface do agente e todos os controles associados nesses dispositivos são da responsabilidade do Assinante e (ii) o Assinante deve recusar o uso da funcionalidade de exportação nativa por e-mail para esses relatórios exportados, a menos que assuma a responsabilidade de (a) assegurar que nenhuma PHI esteja contida nessas exportações ou (b) que os serviços de e-mail usados para tais transferências possam acomodar a criptografia através do protocolo de criptografia mínimo permitido pelos padrões PCI atuais.

* Considerações especiais para o uso do Explore Enterprise:

O Assinante reconhece que o uso do Serviço Explore Enterprise pode implicar um aumento das funcionalidades de compartilhamento e exportação de dados. O Assinante deverá:

  1. ou (i) garantir que não haja PHI nesses painéis e/ou (ii) compartilhar painéis apenas com agentes, grupos, listas ou usuários finais que tenham autorização para visualizar e receber esses dados.
  2. restrições de IP de alavanca
  3. quando o compartilhamento de painéis via Uniform Resource Locator (URL), o Assinante reconhece que, em vez de compartilhar com contas de usuário individuais ou de grupo, os dados serão compartilhados por meio de um link de acesso. O Assinante deve, portanto (i) ativar a proteção por senha, (ii) garantir que a complexidade das senhas escolhidas, a rotação, o armazenamento e a distribuição para o destinatário estejam em conformidade com as políticas de senha do Assinante para a proteção dos dados contidos nesses painéis e (iii) seja girado sem atraso indevido em caso de suspeita ou confirmação de exposição.

VII. Aviso sobre a funcionalidade no produto para serviços associados implantados (“complementos”):

  1. Serviço associado implantado de colaboração: “Conversas paralelas.” O Assinante reconhece que o uso da funcionalidade "Conversa paralela" pode implicar a criação de mensagens de "ticket dependente" e/ou "conversa paralela" dentro ou enviadas a partir da instância do Suporte do Assinante para os destinatários por meio de ticket, e-mail, Slack ou integrações (na configuração de critério do Agente). Se o Assinante optar por usar essa funcionalidade em uma conta habilitada para o atendimento médico, o Assinante assume toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente nessas mensagens, ou (ii) se a PHI puder estar presente nas mensagens, o Assinante será o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizada da PHI resultante da troca de mensagens por meio da funcionalidade "Conversa paralela".

VIII. Aplicativos móveis da Zendesk (ou acesso feito por dispositivos móveis como smartphones ou tablets):

  1. O uso deve incluir a criptografia no nível do dispositivo
  2. O acesso biométrico ou PIN definido para a configuração de dispositivo mais alta permitida deve ser aproveitado
  3. As notificações que permitem que comentários de ticket sejam exibidos nas telas de bloqueio desses dispositivos devem ser desativadas.
  4. Os bloqueadores de inatividade da tela devem estar ativados e configurados para bloquear no máximo 15 minutos de inatividade.
  5. O Assinante reconhece que a funcionalidade de supressão não está disponível no aplicativo para dispositivos móveis do soporte e os agentes precisam entrar pelo navegador se desejarem usar a funcionalidade de supressão. 
  6. Se o Assinante optar por autenticar os Usuários Finais para mensagens da Zendesk, o Assinante reconhece que o status de autenticação de um Usuário Final não é exibido no Aplicativo para dispositivos móveis do Support.

IX. Zendesk Insights: o Suporte para esse serviço foi descontinuado em 5 de fevereiro de 2021.

X. Aviso sobre a funcionalidade de IA do Zendesk (“IA do Zendesk”, “IA avançada”, “IA generativa”, e col):

  1. O Assinante reconhece que os recursos de IA da Zendesk têm por objetivo aumentar a produtividade do(s) Serviço(s) da Zendesk e não devem ser usados de forma que possa ser interpretada como (i) fornecendo aconselhamento médico ou de saúde, (ii) fornecendo um diagnóstico de condição ou sintomas, (iii) prescrevendo um tratamento, ou (iv) de qualquer forma impedindo que um Usuário procure o conselho, diagnóstico ou tratamento de um profissional de saúde, (v) ou de outra forma fornecendo a um Usuário informações ou tomando decisões que o abranjam em ou fora de qualquer plano de saúde, programa de tratamento, serviço de teste ou qualquer outro serviço de saúde que possa afetar sua pesquisa ou recebimento de serviços de saúde (a menos que o Assinante assuma a responsabilidade total por essa decisão com base em seu caso de uso único e interações com seus Usuários, bem como as possíveis consequências de usar IA de tal forma).
  2. O Assinante reconhece que, se usar quaisquer recursos IA generativa, essas saídas IA geradas são geradas por computador e não por humanos, e podem produzir saídas imprecisas. A Zendesk não garante a precisão dessas saídas.
  3. O Assinante reconhece que se uma saudação de bot de conversa de Agentes de IA for usada para fornecer uma mensagem de isenção de responsabilidade obrigatória aos Usuários Finais do Assinante, a funcionalidade “Gerar variações” não será ativada para garantir a integridade do conteúdo da mensagem. 
  4. O Assinante reconhece que ativar a funcionalidade Escritura avançada na Central de administração ativará essa funcionalidade para todos os agentes em sua instância, independentemente de suas funções e permissões. 

XI. Zendesk QA

  1. O Assinante reconhece que os recursos de IA do Zendesk QA destinam-se a aumentar a produtividade do(s) Serviço(s) da Zendesk e não devem ser usados de forma que possa ser interpretada como (i) fornecendo aconselhamento médico ou de saúde, (ii) fornecendo um diagnóstico de condição ou sintomas, (iii) prescrevendo um tratamento, ou (iv) de qualquer forma impedindo que um Usuário procure o conselho, diagnóstico ou tratamento de um profissional de saúde, (v) ou de outra forma fornecendo a um Usuário informações ou tomando decisões que o abranjam em ou fora de qualquer plano de saúde, programa de tratamento, serviço de teste ou qualquer outro serviço de saúde que possa afetar sua pesquisa ou recebimento de serviços de saúde (a menos que o Assinante assuma a responsabilidade total por essa decisão com base no seu caso único de uso e interações com seus Usuários, bem como as possíveis consequências de usar IA de tal forma).
  2. O Assinante reconhece que a exclusão ou supressão em sua instância do Zendesk não é sincronizada imediatamente com o Zendesk QA, mas será transferida nas próximas 3-6 horas.
  3. Ao usar a funcionalidade Pesquisas, o Assinante deve (i) desativar a funcionalidade de assistência de IA do Zendesk QA (ou garantir que todos os Agentes que realizam trabalhos de QA sejam autorizados a ver quaisquer dados potenciais dentro dessa transação, bem como garantir que os princípios do ponto 1 estejam em vigor) (ii) configurar a pesquisa de modo a não revelar o PHI nas perguntas ou nas descrições da pesquisa (ou assumir a responsabilidade de tais dados nos emails enviados por StartTLS oportunista)
  4. Ao usar a integração personalizada “Zendesk Chat”, o Assinante deve considerar a definição de um período de retenção de dados alinhado às políticas do Assinante para garantir que os dados não sejam mantidos por tempo ilimitado.
  5. O Assinante reconhece que, ao usar a API do Sunshine Conversations para apagar partes de uma conversa do Zendesk Messaging, essa alteração não é refletida no Zendesk QA. Em vez disso, as informações devem ser removidas do ticket original por supressão ou toda a conversa deve ser removida.
  6. O Assinante reconhece que, quando "baixos seguros (anexos privados)" estiverem ativados no soporte, os anexos de canais de mensagens não estarão visíveis nos tickets do Zendesk QA e o acesso será restrito apenas ao solicitante ou atribuído do ticket.
  7. O Assinante reconhece que, segundo as disposições iniciais do Zendesk QA, a configuração avançada da conexão só é possível após a primeira sincronização.

XII. Gerenciamento da força de trabalho do Zendesk "WFM":

  1. O assinante reconhece que
    1. A função de administrador padrão do WFM tem acesso a todas as atividades e configurações do agente aplicáveis ao serviço WFM (incluindo as tags mencionadas no ponto 2 abaixo).
    2. A função de agente padrão tem acesso à atividade do agente, a menos que seja configurada por administradores para ter acesso diferente por meio da criação de funções personalizadas conforme descrito aqui
  2. O Assinante reconhece que as tags aplicadas por Agentes, Administradores ou lógica do sistema predefinida em tickets no soporte ficarão visíveis no produto WFM para qualquer Usuário com permissão para ver essa atividade de ticket. Se as tags forem consideradas confidenciais pelo Assinante, o acesso deve ser configurado adequadamente.

Aviso: Devido a alterações na legislação ou regulamentação ou alterações no Serviço Zendesk, as configurações de segurança neste documento podem mudar de tempos em tempos. Este documento contém as recomendações da Zendesk para as configurações de segurança mínimas e eficazes para a proteção da PHI nos produtos Zendesk descritos acima no momento. Este documento não constitui um modelo exaustivo para todos os controles sobre esses dados nem constitui um conselho jurídico. Cada assinante do Zendesk deve procurar seu próprio consultor jurídico em relação aos requisitos de conformidade com HIPAA ou HDS e deve fazer as alterações adicionais em suas configurações de segurança de acordo com a análise independente de cada assinante, desde que essas alterações não contrariem ou reduzam a segurança das configurações descritas neste documento.

 

Registro de alterações:

13 de maio de 2026

  • Atualizado Secção XI ("QA"), ponto 6 para indicar que o Support para "anexos privados" agora existe 

10 de novembro de 2025

  • Atualização do nome do contrato do cliente do Contrato Principal de Serviços para Contrato do cliente Zendesk

24 de janeiro de 2025

  • Configurações HIPAA e HDS consolidadas

27 de dezembro de 2024

  • Adição da seção XII para incorporar o Gerenciamento da força de trabalho do Zendesk ("WFM") ao escopo

16 de dezembro de 2024

  • Adição da seção XI para incorporar o Zendesk QA ao escopo
  • Alterou várias instâncias de "Answer Bot" para "Agentes de IA" para indicar alterações na convenção de nomenclatura e um escopo mais amplo.

10 de outubro de 2024

  • Adicionou a Seção I, soporte, número 12 (CSAT) e editou a Seção I, soporte, número 11 (CSAT legado) para acomodar a nova funcionalidade. 

7 de março de 2024

  • Adição da Seção X, Aviso sobre a funcionalidade Zendesk IA
  • Seção I, soporte, número 7 (visualização de permissões):
    • Esclareceu que as "permissões de visualização" pertencem a uma "instância/marca/organização" inteira e não apenas a uma "org.".
    • Uma nova disposição foi adicionada para o comportamento específico da organização do usuário final. 
  • Seção I, soporte, número 9 (e-mail):  
    • Expandiu as circunstâncias em que o Zendesk Support envia um email para um Usuário Final para incluir respostas pelo canal de email ou as iniciadas por uma automação ou gatilho, em vez de apenas um agente respondendo a um ticket.
    • Especificado que, por padrão, as notificações automatizadas podem conter a correspondência de ticket mais recente ou outras informações configuradas, que podem incluir o PHI.
       

25 de outubro de 2023

  • Introdução: Linguagem de introdução esclarecida para contas com HIPAA
  • Seção II, Guide e Gather, número 1 (restrições da central de ajuda): substituiu as restrições de IP por artigos restritos para esclarecimento

13 de abril de 2023

  • Seção I, soporte, número 4 (APIs): 
    • Link para métodos de autenticação adicionado para maior clareza 
    • b) Removeu as recomendações de período exato para a rotação para alinhar com as práticas recomendadas do setor e removeu a referência aos Termos de serviço da REST API (redundância)
    • adicionou c) para avisar sobre o uso da Autenticação básica para a API 
  • Seção II, Guia:
    • Número 1 (restrições da central de ajuda): adição de referência a centrais de ajuda fechadas ou restritas para alinhar com a funcionalidade do produto
    • Número 5 (@Menções): Opção adicionada para desativar @Menções para alinhar com a funcionalidade do produto 
  • Seção III, mensagens: 
    • Números 1 e 2 (canais de terceiros e anexos privados): identificadores de seção (i) e (ii) adicionados para maior clareza
    • Número 2 (anexos privados): adicionou “URLs e/ou” para esclarecimento 
    • Número 7-10 (autenticação de usuário final, exclusão de conversas do Answerbot, supressão, varredura de malware): seções completas foram adicionadas para aumentar a transparência
  • Seção IV, Sunshine Conversations: seção inteira adicionada devido ao facto de o Sunshine Conversations na Zendesk Suite fazer parte do BAA 
  • Seção V, Chat, número 3 (Espaço de trabalho do agente): pequenas correções de frases
  • Seção VIII, aplicativos para dispositivos móveis, números 5-7 (verificação de malware, supressão, autenticação de usuário final): seções inteiras foram adicionadas para aumentar a transparência

24 de fevereiro de 2023

  • Seção I. soporte, número 3: removeu a distinção separada entre as restrições de IP do soporte e do Chat, pois a interface do usuário agora está unificada.
  • Seção I. soporte, número 5: esclarecimento adicionado sobre o incumprimento do requisito 
  • Seção I. soporte, número 7: “Assinante não deve” foi alterado para “Assinante não deve”.
  • Secção IV. Chat, número 2: esclarece que toda a funcionalidade de exportação de dados do Chat usando e-mail é proibida e não apenas abrangida por transcrições e encaminhamentos. 
  • Seção III. mensagens: uma seção inteira foi adicionada para levar em conta a funcionalidade de mensagens da Zendesk, além do escopo do Business Associate Agreement da Zendesk.

9 de julho de 2021

  • Adiciona o ponto 3. na seção Chat para as responsabilidades relacionadas ao uso do espaço de trabalho do agente.

21 de janeiro de 2021

  • A adição do número 1.11 não permite CSAT a menos que o Assinante assuma a responsabilidade dos dados enviados por e-mail como parte da pesquisa. 
  • Cuidado no número 1.7 para permitir que os Assinantes alterem as permissões de visualização devido aos usuários que já têm permissão para acessar esses dados em suas respectivas extremidades.
  • Documento inteiro atualizado para corresponder ao estilo da empresa de links inseridos no texto em vez de URLs embutidas (sem impacto no conteúdo de configuração). 

Agosto de 2020

  • Adição do Explore Enterprise que abrange recursos aumentados de compartilhamento de painéis
  • Remoção do banimento de anexos do Chat (os requisitos de autenticação do soporte agora cobrem)
  • Desambiguação de que o banimento de ePHI em campos personalizados foi aplicado especificamente ao uso do Insights e não globalmente
  • Adição de uma nova seção que abrange complementos aos serviços implantados, com "Conversas paralelas" sendo a primeira adição
  • Várias edições de gramática/formatação (inconsequentes ao conteúdo)

13 de julho de 2020:

  • Desambiguação feita em relação ao uso de SMS através do Serviço em oposição ao uso nativo de SMS para a 2FA no produto. * Para evitar dúvidas, as advertências de dados relacionadas à ePHI na seção 10 sobre SMS não se aplicam ao uso da 2FA no produto (conforme descrito na seção 1.a) pois essa funcionalidade simplesmente envia uma cadeia de caracteres numérica para verificação de identidade."

13 de dezembro de 2019

  • permite que as restrições de IP do agente sejam evitadas quando o caso de uso não permite essas restrições, desde que a MFA sobre o acesso do agente seja aplicada.

17 de dezembro de 2019

  • permite comentários de usuários finais no Guide, desde que os agentes moderem esses comentários e removam todas as PHIs.

6 de novembro de 2019

  • Artigo atualizado para refletir a mudança que os assinantes podem optar por renunciar ou substituir qualquer configuração específica, desde que assumam a responsabilidade dessa decisão.

"A falha do Assinante em implementar e cumprir qualquer configuração específica listada abaixo, ou qualquer série de configurações obrigatórias listadas abaixo, será em

Em risco próprio e a critério exclusivo do Assinante; e tal falha isentará a Zendesk e seus funcionários, agentes e afiliados de qualquer responsabilidade em relação a qualquer acesso não autorizado, ou uso indevido ou divulgação de Dados de Serviço do Assinante, incluindo qualquer Informação de Saúde Protegida eletrônica, resultante de tal falha por parte do Assinante. "

  • Outras alterações incluem
    • 1. a capacidade de usar SMS, desde que o assinante assuma toda a responsabilidade de garantir que nenhuma PHI esteja presente nessas transmissões.
    • 2. A capacidade de usar anexos no Chat, desde que o assinante assuma toda a responsabilidade de garantir que nenhum PHI esteja presente nesses anexos.

6 de março de 2019

  • atualizado para incluir as configurações do Zendesk Explore

17 de janeiro de 2019

  •  atualizado para não permitir anexos no Chat.

Aviso sobre a tradução: este artigo foi traduzido por um software de tradução automática para oferecer a você uma compreensão básica do conteúdo. Medidas razoáveis foram tomadas para fornecer uma tradução precisa, no entanto, a Zendesk não garante a precisão da tradução.

Em caso de dúvidas relacionadas à precisão das informações contidas no artigo traduzido, consulte a versão oficial do artigo em inglês.

Powered by Zendesk