Contas habilitadas para HIPAA e HDS (coletivamente "Contas habilitadas para a área de saúde"):
Todos os termos em letras maiúsculas usados neste documento terão os significados atribuídos a eles no Business Associate Agreement ("BAA") da Zendesk ou no Anexo de Termos da HDS ao Contrato Principal de Assinatura da Zendesk ("Anexo HDS"), conforme aplicável ao tipo de conta (coletivamente, “Contrato de assistência médica”).
Para fins de contas com HIPAA , "PHI" significa "Informações de saúde protegidas" e, para fins de contas com HDS, "PHI" significa "informações pessoais de saúde".
A Zendesk e o Assinante firmaram um Contrato de assistência médica que recomenda que o Assinante avalie e implemente, conforme apropriado para seu caso de uso, as seguintes configurações ou alternativas avaliadas pelo Assinante para atender aos requisitos de conformidade sob a lei aplicável, para toda e qualquer Conta Habilitada para a Saúde (s) antes de introduzir qualquer PHI no(s) Serviço(s).
Se o Assinante escolher, a seu exclusivo critério, renunciar à implementação de qualquer uma das configurações recomendadas listadas abaixo, o Assinante assumirá a responsabilidade por qualquer acesso não autorizado ou uso indevido de divulgação dos Dados de Serviço do Assinante, incluindo qualquer PHI, que resulte de qualquer tais desvios das configurações recomendadas pelo Assinante.
O assinante deve ter adquirido planos de serviço no nível apropriado e ter os complementos associados necessários (consulte seu representante de vendas em caso de dúvida).
Se o Assinante tiver uma Conta com HDS ativado, o Assinante deve clicar no botão "Seguir" na Política de Subprocessador do Zendesk para receber notificações de quaisquer alterações nos subprocessadores usados para fornecer os Serviços.
As configurações de segurança mínimas a seguir para os serviços do Zendesk devem ser implementadas e são reconhecidas no Contrato de assistência médica para qualquer conta habilitada para a área de saúde
I. Zendesk Support:
-
Proteja a autenticação do agente por um dos dois métodos a seguir:
- Empregando o Zendesk Support nativo com configurações de senha: (i) definido como “Recomendado”; ou (ii) personalizado pelo Assinante de maneira que estabeleça requisitos não menos seguros do que os estabelecidos na configuração “Recomendado”. Além disso, de acordo com a opção nesta subseção, o Assinante também deve ativar e aplicar a Autenticação de Dois Fatores ("2FA") nativamente dentro do Serviço; e os controles administrativos que permitem que os administradores definam senhas para os usuários finais devem ser desativados; ou
- 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 aplicar a autenticação de dois fatores dentro da 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.
- Todas as opções de autenticação que utilizam SSO como método de autenticação devem desativar o acesso por senha.
- A criptografia Secure Socket Layer ("SSL") nas contas com suporte para assistência médica deve permanecer sempre ativada. Contas habilitadas para a área de saúde que utilizam um domínio diferente de zendesk.com devem estabelecer e manter SSL hospedado.
- Sempre que possível, o acesso do agente deve ser restrito a endereços IP específicos sob o controle do Assinante a menos que o Assinante habilite a autenticação multifator para agentes conforme descrito acima nos requisitos 1.a ou 1.b (nativamente dentro do Serviço ou dentro do ambiente do Assinante, juntamente com o Enterprise SSO). Para evitar dúvidas, "Acesso de agente" deve denotar o acesso concedido a um agente humano que acessa os Dados de Serviço por meio da Interface do Usuário ("IU").
-
Na medida em que a Conta Habilitada para Saúde do Assinante permita chamadas para as Interfaces de Programação de Aplicativos do Zendesk ("APIs"), o Assinante assumirá toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros com permissão para criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio desse acesso e/ou integrações. Para acessar essas APIs, o 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 de API usado:
- Abordagem OAuth 2.0. Esse modelo fornece os recursos de segurança mais granulares, mas requer que os direitos sejam aceitos 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 dar a cada cliente OAuth uma função de designação de Nome do Cliente e Identificador Exclusivo descritivo e exclusivo. As permissões concedidas para cada token OAuth devem permitir o mínimo de privilégios necessários para realizar as tarefas necessárias.
- Abordagem do 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 acesso e 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 um nome descritivo que designe a função; (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 terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar o token associado imediatamente; e (iv) no mínimo, alterne o token com frequência de acordo com as políticas da organização do Assinante.
- Quando possível, o Assinante deve desativar a senha de acesso à API, pois essa abordagem envia credenciais de usuário a cada solicitação, o que as expõe de maneira ampla, facilitando a interceptação por terceiros mal-intencionados.
- O assinante deve ativar a opção "Solicitar autenticação para download" para solicitar autenticação para acessar anexos. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a esses dados de anexo.
- O Assinante deve aplicar sistematicamente, em todos os pontos de extremidade acessados por Agentes, Administradores e Proprietários, um protetor de tela bloqueado por senha ou uma tela de inicialização configurada para interagir com, no máximo, quinze (15) minutos de inatividade do sistema.
- 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 acesso além dos tickets ou grupo do próprio usuário (a menos que o Assinante assuma toda a responsabilidade por garantir que esses usuários sejam aprovados pelo Assinante para acessar todos os dados subsequentes). 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 anula a configuração menos permissiva.
- O Assinante reconhece que a Zendesk não é responsável por proteger as transmissões de e-mail dos Usuários Finais e os Dados de Serviço relacionados antes de serem recebidos na instância do Zendesk Support do Assinante. Isso inclui qualquer PHI que possa ser transmitida por e-mail por meio de respostas aos tickets do Zendesk Support , incluindo, entre outros, comentários ou anexos do ticket.
- O Assinante reconhece que o Zendesk Support envia um e-mail para um Usuário Final sob várias circunstâncias, por exemplo, quando um Agente do Assinante responde a um ticket do Zendesk Support pelo canal de e-mail ou iniciado por uma automação ou gatilho. Por padrão, esse email contém a correspondência de ticket mais recente ou outras informações configuradas para serem incluídas em uma notificação automatizada, que pode incluir PHI. Para proteger ainda mais o Assinante, sua instância do Zendesk Support deve ser configurado para alertar apenas o usuário final que um agente respondeue solicitar que o usuário final se autentique no Zendesk Support para ver o conteúdo da mensagem.
-
O Assinante reconhece que qualquer funcionalidade de mensagem de texto utilizada a seu exclusivo critério em qualquer Serviço da Zendesk é sustentada por SMS e/ou protocolos relacionados, que podem envolver a transmissão não criptografada de mensagens enviadas para ou fora do(s) Serviço(s). Como tal, a funcionalidade de mensagem de texto deve:
- não pode ser usado em uma conta habilitada para a área de saúde* ou
- se usado, o Assinante assume toda a responsabilidade pelo uso de tal funcionalidade
- O Assinante reconhece que o uso da funcionalidade legada das Pesquisas de satisfação do cliente (" CSAT legadas") do Serviço envia os 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 por Zendesk. Como tal, a funcionalidade CSAT legada deve:
- não pode ser usado em uma conta habilitada para a área de saúde* ou
- se usado, o Assinante assume toda a responsabilidade pelo uso de tal funcionalidade
-
O Assinante reconhece que o uso da funcionalidade Pesquisas de Satisfação do Cliente ("CSAT") do Serviço para o canal de tickets, se não estiver configurado adequadamente, enviará os Dados do serviço (que podem conter PHI) associados ao ticket do Support por email 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 de CSAT para o canal de tickets, o Assinante deve
- Configure o corpo do email de automação de CSAT para não incluir possíveis PHI e use o {{satisfaction.survey_url}} placeholder exclusivamente
- Não usar a funcionalidade de perguntas abertas
* Para evitar dúvidas, as advertências de dados relacionadas a 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 envia apenas uma sequência numérica para verificação de identidade.
II. Zendesk Guide e Gather:
- O Assinante reconhece que os Serviços do Guide e Gather são públicos por natureza (onde não é possível aproveitar artigos restritos ou usar uma instância fechada ou restrita) e, portanto, o Assinante deve garantir que quaisquer artigos no Zendesk Guide ou no Serviço Gather não incluam PHI, seja por meio do texto de artigo ou como anexo ou imagem dentro do artigo.
- O Assinante deve desativar a capacidade de os Usuários Finais adicionarem comentários no Zendesk Guide ou deve moderar e assumir a responsabilidade pela remoção de PHI de todos os comentários (conforme indicado na seção 3 abaixo).
- Onde o Serviço do Zendesk Guide for Guide Professional ou Enterprise, os Assinantes devem, quando possível, desativar a capacidade de os usuários finais criarem novas publicações desativando a funcionalidade Gather com o Zendesk Guide ou quando os recursos do Gather não puderem ser usados devido à intenção do Assinante caso de uso, os assinantes devem ativar a moderação de conteúdo no Zendesk Guide Service e definir como "Moderar todo o conteúdo". Nenhum envio contendo PHI deve ser aprovado.
- O uso por Assinante de “Moderadores da Comunidade” que não sejam funcionários no Serviço Gather não deve ser permitido, a menos que o Assinante assuma a responsabilidade pelo acesso potencial desses Usuários aos dados, incluindo possíveis PHI (quando aplicável).
- O Assinante reconhece que "@menções" de membros da comunidade do Gather são possíveis quando os usuários finais têm perfis públicos e, caso essa funcionalidade seja considerada um risco em seu caso de uso, os perfis públicos devem ser desativados ou as @menções devem ser desativadas.
III. Mensagens do Zendesk:
- O Assinante não deve ativar as integrações de canais de mensagens em redes sociais, a menos que assuma total responsabilidade por (i) garantir que nenhuma PHI esteja presente nas mensagens de redes sociais ou (ii) conclua seu próprio BAA com plataformas de mensagens integradas.
- O Assinante deve desativar a capacidade de os Usuários Finais anexarem arquivos a conversas por mensagens e deve assumir total responsabilidade por (i) ativar anexos seguros ou (ii) garantir que os Agentes não anexem arquivos contendo ePHI a conversas por mensagem. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a essas URLs e/ou dados de anexo.
- O Assinante assumirá toda a responsabilidade por garantir que todos os Agentes e Agentes light tenham permissão para visualizar todas as mensagens recebidas de todos os Usuários Finais.
- 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 assumirá total responsabilidade por entender as implicações de privacidade e segurança de todos os fluxos de trabalho personalizados e por todos Assinantes ou entidades terceirizadas (incluindo provedores de chatbots) têm permissão para criar, acessar, modificar ou apagar Dados do Serviço e ePHI por meio desse acesso e/ou integrações.
- 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 assumirá toda a responsabilidade por forçar o encerramento do acesso do referido Agente ao Zendesk.
- Por padrão, as conversas do Web Widget com os Usuários Finais são permanentes e poderão ser visualizadas pelo Usuário Final quando ele retornar ao web chat a partir do mesmo dispositivo. O Assinante deve desativar esse recurso ou assumir toda a responsabilidade por garantir que os Usuários Finais não compartilhem dispositivos.
-
Se o Assinante desejar implementar a autenticação para Usuários Finais, o Assinante assumirá toda a responsabilidade por implementá-la de maneira segura, de acordo com as práticas recomendadas e os padrões do setor.
- Ao usar essa abordagem, o Assinante deve (i) usar uma chave de assinatura JWT exclusiva para cada canal de autenticação e dar ao token um nome descritivo que designe a função; (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 do JWT for compartilhada com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar a chave de assinatura do JWT associada imediatamente; e (iv) no mínimo, alterne a chave de assinatura do JWT com frequência de acordo com as políticas da organização do Assinante.
- O assinante deve usar o atributo JWT de validade e definir seu valor como não mais que 15 minutos.
- 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 estão armazenadas no sistema e é responsabilidade do Assinante apagá-las de acordo com suas obrigações (por exemplo, implementando uma webhook que alerta o Assinante quando essas conversas são armazenadas e (automaticamente) aciona a exclusão pela API do Sunshine Conversations ).
- O Assinante reconhece que as conversas entre Usuários Finais e Agentes de IA que foram transformadas em um ticket não pode ser suprimido no momento. A exclusão é possível apagando o ticket.
- O Assinante reconhece que os anexos do Usuário Final nos canais de mensagens não são verificados quanto a malware no Zendesk no momento. O Assinante deve assumir total responsabilidade por implementar procedimentos e políticas para mitigar o risco para os ativos do Assinante.
- O Assinante reconhece que o uso da funcionalidade "Conversas paralelas" pode resultar na criação de mensagens de "ticket dependente" e/ou "conversa paralela" dentro ou enviadas da instância de Support do Assinante para destinatários por ticket, e-mail, Slack ou integrações (a critério do agente de configuração) . Se o Assinante optar por usar essa funcionalidade em uma Conta Habilitada para Saúde, o Assinante assumirá toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente em tais mensagens ou (ii) se PHI puder estar presente em mensagens, o Assinante é o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizados de PHI resultantes da troca de mensagens por meio da funcionalidade “Conversas paralelas”.
IV. Zendesk Sunshine Conversations:
- O Assinante não deve ativar integrações de canais de terceiros, a menos que assuma total responsabilidade por garantir que (i) nenhuma PHI esteja presente em mensagens de canal de terceiros ou (ii) conclua seu próprio BAA com plataformas de mensagens integradas.
-
O Assinante assumirá toda a responsabilidade por entender as implicações de segurança de todas as entidades do Assinante ou de terceiros com permissão para criar, acessar, modificar ou apagar Dados de Serviço e PHI por meio 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 de API usado:
- Abordagem OAuth 2.0. Esse modelo fornece os recursos de segurança mais granulares, mas requer que os direitos sejam aceitos por um usuário final. Sempre que possível, o Assinante deve utilizar a abordagem e o esquema de autenticação do OAuth 2.0. O Assinante deve dar a cada cliente OAuth uma função de designação de Nome do Cliente e Identificador Exclusivo descritivo e exclusivo.
- Abordagem do 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 acesso e 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 um nome descritivo que designe a função; (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 terceiros 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.
- 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 assumirá total responsabilidade por 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 chatbot) permitidas para criar, acessar, modificar ou apagar Dados do Serviço e PHI por meio desse acesso e/ou integrações.
- O Assinante reconhece que as restrições de IP configuradas para o Zendesk Support não se estendem à API do Sunshine Conversations . Os assinantes devem assumir total responsabilidade por restringir o acesso à API do Sunshine Conversations e aos tokens da API, conforme descrito em 2.b. e de acordo com as políticas do Assinante.
- O Assinante deve desativar a capacidade de os Usuários finais anexarem arquivos às conversas do Sunshine Conversations e deve assumir total responsabilidade por ativar anexos seguros ou garantir que os agentes não anexem arquivos contendo PHI a conversas por mensagem. Não fazer isso significa que qualquer anexo irrestrito pode ser acessado por qualquer pessoa com acesso à URL correta do referido anexo. Nesses casos, o Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a esses dados de anexo.
-
Se o Assinante desejar implementar a Autenticação para Usuários Finais, o Assinante assumirá toda a responsabilidade por implementá-la de maneira robusta, de acordo com as práticas recomendadas de segurança e os padrões do setor.
- Ao usar essa abordagem, o Assinante deve (i) usar uma chave de assinatura JWT exclusiva para cada canal de autenticação e dar ao token um nome descritivo que designe a função; (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 do JWT for compartilhada com terceiros e o Assinante for informado de uma violação de dados de terceiros, o Assinante deve alternar a chave de assinatura do JWT associada imediatamente; e (iv) no mínimo, alterne a chave de assinatura do JWT com frequência de acordo com as políticas da organização do Assinante.
- O assinante deve usar o atributo JWT de validade e definir seu valor como não mais que 15 minutos.
- 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 estão armazenadas no sistema e é responsabilidade do Assinante apagá-las 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 pela API do Sunshine Conversations
- 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.
- O Assinante reconhece que as mensagens apagadas pela API do Sunshine Conversations são apagadas apenas para os Usuários Finais, mas não são apagadas no Espaço de trabalho do agente do Zendesk. Isso pode ser feito com a exclusão do próprio ticket ou o uso da funcionalidade Supressão (consulte Limitações 7.).
- O Assinante reconhece que todos os anexos nos canais do Sunshine Conversation não são verificados quanto a malware no Zendesk. O Assinante deve assumir total responsabilidade por implementar procedimentos e políticas para mitigar o risco para os funcionários do Assinante.
V. Zendesk Chat:
- O Assinante deve limitar o acesso dos Agentes ao Serviço do Zendesk Chat associando e autenticando pelo Serviço do Zendesk Support .
- O assinante não deve enviar transcrições do Chat por e-mail, (a) desativando a transferência de e-mail, (b) desativando a opção de transcrição de chat por e-mail no Web Widget Clássico e (c) não compartilhando exportações por e-mail do painel do Chat
- O Assinante assume total responsabilidade por garantir que (i) nenhuma PHI esteja presente nos Chats e/ou (ii) que todos os Agentes tenham permissão para visualizar esses dados.
VI. Serviço do Zendesk Explore :
O Assinante reconhece que as PHI podem ser exibidas 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 formato livre.
- Para quaisquer instâncias de Serviço no escopo contendo PHI, o Assinante deve (i) conceder acesso à interface do Explore apenas aos agentes que podem acessar todos os tickets/chamadas/chats que possam conter PHI nas instâncias de Serviço pai e (ii) devem 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 a configuração de níveis de acesso no Explore, consulte aqui.
- Ao aproveitar a funcionalidade de "exportação", (i) o Assinante reconhece que as PHI podem ser transferidas para o dispositivo permitido pelo Assinante para acessar a interface do agente e todos os controles de atendimento nesses dispositivos são de responsabilidade do Assinante e (ii) o Assinante deve negar o uso da funcionalidade de exportação nativa por e-mail para os referidos relatórios exportados, a menos que assuma a responsabilidade de (a) garantir que nenhuma PHI esteja contida nessas exportações ou (b) que os serviços de e-mail usados para essas transferências possam acomodar a criptografia por meio do protocolo de criptografia mínimo permitido pelos padrões PCI então vigentes.
* Considerações especiais para o uso do Explore Enterprise:
O Assinante reconhece que o uso do Serviço Explore Enterprise pode implicar em mais recursos de compartilhamento e exportação de dados. O Assinante deve:
- (i) garantir que não existam PHI nesses painéis e/ou (ii) compartilhar painéis apenas com agentes, grupos, listas ou usuários finais aprovados para visualizar e receber esses dados.
- aproveitar restrições de IP
- ao compartilhar painéis por URL (Uniform Resource Locator), o Assinante reconhece que, em vez de compartilhar com contas de usuários individuais ou em grupo, os dados devem ser compartilhados por um link de acesso. Portanto, o Assinante deve (i) ativar a proteção por senha, (ii) garantir que a complexidade, a rotação, o armazenamento e a distribuição das senhas escolhidas para a parte receptora estejam em conformidade com as políticas de senha do Assinante para a proteção dos dados contidos nesses painéis e (iii) seja alternado sem demora indevida após a suspeita ou confirmação da exposição
VII. Aviso sobre a funcionalidade no produto para serviços associados implantados (“Complementos”):
- Serviço associado implantado do Collaboration: “Conversas paralelas”. O Assinante reconhece que o uso da funcionalidade "Conversas paralelas" pode resultar na criação de mensagens de "ticket dependente" e/ou "conversa paralela" dentro ou enviadas da instância de Support do Assinante para destinatários por ticket, e-mail, Slack ou integrações (a critério do agente de configuração) . Se o Assinante optar por usar essa funcionalidade em uma Conta Habilitada para Saúde, o Assinante assumirá toda e qualquer responsabilidade por (i) garantir que nenhuma PHI esteja presente em tais mensagens ou (ii) se PHI puder estar presente em mensagens, o Assinante é o único responsável por qualquer responsabilidade, custo, dano ou dano relacionado à aquisição, acesso, uso ou divulgação não autorizados de PHI resultantes da troca de mensagens por meio da funcionalidade “Conversas paralelas”.
VIII. Aplicativos para dispositivos móveis do Zendesk (ou acesso feito por dispositivos móveis, como smartphones ou tablets):
- O uso deve incluir criptografia no nível do dispositivo
- O acesso biométrico ou PIN definido para a configuração de dispositivo mais alta permitida deve ser aproveitado
- As notificações que permitem que os comentários do ticket sejam exibidos nas telas de bloqueio desses dispositivos devem ser desativadas
- Os bloqueios por inatividade de tela devem ser ativados e configurados para serem bloqueados a não mais de 15 minutos de inatividade.
- O Assinante reconhece que a funcionalidadede supressão não está disponível no aplicativo para dispositivos móveis do Support e que os agentes precisam entrar pelo navegador caso desejem usar a funcionalidade de supressão.
- Se o Assinante optar por autenticar os Usuários Finais para o recurso de mensagens do 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 a 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 outros):
- O Assinante reconhece que os recursos de IA do Zendesk têm como objetivo aumentar a produtividade dos Serviços do Zendesk e não devem ser usados de maneira que possa ser interpretada como (i) fornecimento de conselhos médicos ou de saúde, (ii) fornecimento de um diagnóstico de condição ou sintomas, (iii) prescrever um tratamento ou (iv) impedir de qualquer maneira que um usuário busque aconselhamento, diagnóstico ou tratamento de um profissional de saúde, (v) fornecer informações a um usuário ou tomar decisões, incluindo ou não o escopo 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 total responsabilidade por essa decisão com base em seu caso de uso exclusivo e interações com seus Usuários, também como as possíveis implicações do uso de IA dessa maneira).
- O Assinante reconhece que, se estiver usando recursos de IA generativa, essas saídas de 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 desses resultados.
- O Assinante reconhece que, se uma saudação do bot de conversa de Agentes de IA for usada para fornecer uma mensagem de isenção de responsabilidade aos Usuários Finais do Assinante, a funcionalidade "Gerar variações" não será ativada para garantir a integridade do conteúdo da mensagem.
- O Assinante reconhece que ativar a funcionalidade de Escrita Aprimorada 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
- O Assinante reconhece que os recursos de Zendesk QA IA do Zendesk têm como objetivo aumentar a produtividade dos Serviços do Zendesk e não devem ser usados de uma maneira que possa ser interpretada como (i) fornecimento de conselhos médicos ou de saúde, (ii) fornecimento de um diagnóstico de condição ou sintomas, (iii) prescrever um tratamento ou (iv) impedir de qualquer maneira que um usuário busque aconselhamento, diagnóstico ou tratamento de um profissional de saúde, (v) ou fornecer informações a um usuário ou tomar decisões que incluam ou excluam o escopo 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 total responsabilidade por essa decisão com base em seu caso de uso exclusivo e interações com seus Usuários, como bem como as possíveis implicações do uso de IA dessa maneira).
- 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 3 a 6 horas seguintes.
- 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 o trabalho de QA estejam liberados para ver quaisquer dados potenciais dentro dessa transação, além de garantir que os princípios do ponto 1 estejam em vigor) ( ii) certifique-se de configurar a pesquisa de maneira a não revelar PHI nas perguntas ou descrições da pesquisa (ou assumir a responsabilidade por esses dados em e-mails enviados pelo oportunista StartTLS)
- Ao usar a integração personalizada do “Zendesk Chat”, o Assinante deve considerar a definição de um período de retenção de dados alinhado com as políticas do Assinante para garantir que os dados não sejam retidos por tempo ilimitado.
- O Assinante reconhece que, ao usar a API do Sunshine Conversations para apagar partes de uma conversa do recurso de mensagens do Zendesk, 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.
- O Assinante reconhece que o Zendesk QA não oferece suporte ao recurso "anexos privados" do Zendesk no momento. Isso significa que os anexos podem ser acessados por qualquer pessoa com acesso à URL correta para o referido anexo e não devem ser usados com dados confidenciais, incluindo PHI. O Assinante assumirá toda a responsabilidade pelo conteúdo e acesso a tais URLs e/ou dados de anexo.
- O Assinante reconhece que, de acordo com as provisões iniciais do Zendesk QA, a configuração de conexão avançada só é possível após a primeira sincronização.
XII. Gerenciamento da força de trabalho do Zendesk "WFM":
- O Assinante reconhece que
- A função Administrador do WFM padrão tem acesso a todas as atividades e configurações do agente aplicáveis ao Serviço do WFM (incluindo as tags mencionadas no ponto 2 abaixo).
- A função de agente padrão tem acesso à atividade do agente, a menos que configurada pelos administradores para ter acesso diferente por meio da criação de funções personalizadas , conforme descrito aqui
- O Assinante reconhece que as tags aplicadas por Agentes, Administradores ou a lógica do sistema predefinida nos tickets no Support ficarão visíveis no produto WFM para qualquer Usuário com permissão para ver essa atividade do ticket. Se as tags forem consideradas confidenciais pelo Assinante, o acesso deve ser configurado adequadamente.
Isenção de responsabilidade: Devido a alterações em leis ou regulamentos ou alterações no Serviço do Zendesk, as configurações de segurança neste documento podem mudar periodicamente. Este documento contém as recomendações da Zendesk para as configurações de segurança mínimas eficazes para a proteção de 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 aconselhamento jurídico. Cada assinante do Zendesk deve procurar sua própria assessoria jurídica com relação aos requisitos de conformidade com HIPAA ou HDS e deve fazer 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 prejudiquem a segurança de as configurações descritas neste documento.
Registro de alterações:
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
- Várias instâncias de "Answer Bot" foram alteradas para " Agentes de IA " para denotar alterações na convenção de nomenclatura e um escopo mais amplo.
10 de outubro de 2024
- Adição da Seção I, Support, número 12 (CSAT) e edição da Seção I, Support, número 11 ( CSAT legado) para acomodar a nova funcionalidade.
7 de março de 2024
- Seção X adicionada, Aviso sobre a funcionalidade de IA do Zendesk
-
Seção I, Support, número 7 (permissões de visualização):
- Esclareceu que as "permissões de visualização" pertencem a uma "instância/marca/organização" inteira, e não apenas à "organização".
- Adição de uma nova disposição para o comportamento específico da organização do usuário final.
-
Seção I, Support, número 9 (e-mail):
- Expandiu as circunstâncias nas quais o Zendesk Support envia um email para um usuário final para incluir respostas pelo canal de email ou aquelas iniciadas por uma automação ou gatilho, em vez de apenas um agente respondendo a um ticket.
- Especificou 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 PHI.
25 de outubro de 2023
- Introdução: Linguagem de introdução mais clara para contas com HIPAA ativado
- Seção II, Guide e Gather, número 1 (Restrições da Central de Ajuda): substituição das restrições de IP por artigos restritos para esclarecimento
13 de abril de 2023
-
Seção I, Support, número 4 (APIs) :
- Link adicionado para os métodos de autenticação para fins de clareza
- b) Remoção das recomendações de período de tempo exato para rotação a fim de se alinhar às práticas recomendadas do setor e remoção da 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, Guide:
- Número 1 (Restrições da Central de Ajuda): adição de referência a centrais de ajuda fechadas ou restritas para alinhamento com a funcionalidade do produto
- Número 5 (@menções): Adicionada a opção de desativar @menções para alinhar com o produto funcionalidade
-
Seção III, mensagens:
- Números 1 e 2 (canais de terceiros e anexos privados): adicionados identificadoresde seção (i) e (ii) para maior clareza
- Número 2 (anexos privados): adicionado “URLs e/ou” para esclarecimento
- Número 7-10 (autenticação do usuário final, exclusão de conversas do Answerbot, supressão, verificação de malware): seções completas adicionadas para fins de transparência
- Seção IV, Sunshine Conversations: toda a seção foi adicionada devido ao Sunshine Conversations na Zendesk Suite se tornar parte do BAA
- Seção V, Chat, número 3 (Espaço de trabalho do agente): pequenas correções de frase
- Seção VIII, aplicativos para dispositivos móveis, número 5-7 (verificação de malware, supressão, autenticação do usuário final): seções inteiras adicionadas para fins de transparência
24 de fevereiro de 2023
- Seção I. Support, número 3: foi removida a distinção entre as restrições de IP do Support e do Chat, pois a interface do usuário agora está unificada.
- Seção I. Support, número 5: esclarecimento adicional sobre falha no cumprimento do requisito
- Seção I. Support, número 7: "Assinante não deve" alterado para "Assinante não deve".
- Seçã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 está restrita apenas a transcrições e encaminhamentos.
- Seção III. mensagens: seção inteira adicionada à conta para a funcionalidade de mensagens do 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 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 o CSAT, a menos que o Assinante assuma a responsabilidade pelos dados enviados por email como parte da pesquisa.
- A ressalva no número 1.7 permite que os Assinantes alterem as permissões de visualização devido ao fato de os usuários já terem aprovação para acessar esses dados em suas extremidades.
- Todo o documento foi atualizado para corresponder ao estiloda empresa de links incorporados no texto, em vez de URLs incorporados (sem impacto no conteúdo da configuração).
Agosto de 2020
- Adição do Explore Enterprise, que abrange o aumento dos recursos de compartilhamento de painéis
- Remoção do banimento de anexos do Chat (aborda agora os requisitos de autenticação do Support )
- Desambiguação de que o banimento de ePHI em campos personalizados se aplicava especificamente ao uso do Insights e não globalmente
- Adição de uma nova seção que aborda complementos para serviços implantados, com "Conversas paralelas" sendo a primeira adição
- Várias edições de gramática/formatação (inconsequentes para o conteúdo)
13 de julho de 2020:
- Desambiguação feita em relação ao uso de SMS pelo Serviço em oposição ao uso nativo de SMS para 2FA no produto. * Para evitar dúvidas, as advertências de dados relacionadas ao ePHI 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 envia apenas 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 removidas onde o caso de uso não permite essas restrições, desde que a MFA no 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 PHI.
6 de novembro de 2019
- Artigo atualizado para refletir a alteração de que os assinantes podem optar, a seu exclusivo critério, por abandonar ou substituir qualquer configuração específica, desde que assumam a responsabilidade por essa 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, deve ser
risco do Assinante e a critério exclusivo do Assinante; e tal falha isentará a Zendesk e seus funcionários, agentes e afiliados de qualquer responsabilidade com relação a qualquer acesso não autorizado ou uso ou divulgação impróprios dos Dados de Serviço do Assinante, incluindo qualquer Informação de Saúde Protegida eletrônica, que resulte de tal falha pelo Assinante . "
-
Outras alterações incluem
- 1. a capacidade de usar SMS, desde que o assinante assuma toda a responsabilidade por garantir que nenhuma PHI esteja presente em tais transmissões.
- 2. A capacidade de usar anexos no Chat, desde que o assinante assuma toda a responsabilidade por garantir que nenhuma 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.
0 comentários