Account abilitati HIPAA :

Tutti i termini in maiuscolo usati in questo documento hanno il significato loro attribuito nel Contratto di società in affari ("BAA") di Zendesk. 

Zendesk e l’Abbonato hanno stipulato un Business Associate Agreement (“BAA”) che richiede all’Abbonato di valutare e implementare, a seconda del caso d’uso, le seguenti configurazioni o alternative valutate dall’Abbonato come sostanzialmente simili, per tutti gli HIPAA abilitati prima di introdurre nei Servizi informazioni sanitarie protette ("PHI"). 

Se l’Abbonato sceglie, a sua esclusiva discrezione, di rinunciare a implementare una qualsiasi delle configurazioni consigliate elencate di seguito, l’Abbonato si assume la responsabilità esclusiva per qualsiasi accesso non autorizzato o uso improprio della divulgazione dei Dati di servizio dell’Abbonato, incluse le Informazioni sanitarie protette, che ne derivano. da qualsiasi deviazione dalle configurazioni consigliate dall’abbonato.

L’abbonato deve aver acquistato piani di servizio del livello appropriato e disporre dei componenti aggiuntivi necessari (in caso di dubbi, consulta il tuo rappresentante commerciale)

I. Le seguenti configurazioni di sicurezza minime per Zendesk Support devono essere implementate e sono riconosciute nel BAA per qualsiasi account abilitato HIPAA :

  1. Autenticazione Secure Agent tramite uno dei due metodi seguenti:
    1. Utilizzo di Zendesk Support nativo con impostazioni della password: (i) impostato su “Alto”; o (ii) personalizzato dall’Abbonato in modo da stabilire requisiti non meno sicuri di quelli stabiliti nell’impostazione “Alto”. Inoltre, in base all'opzione in questa sottosezione, l'Abbonato deve anche abilitare e applicare l'autenticazione a due fattori ("2FA") in modo nativo all'interno del Servizio; e i controlli amministrativi che consentono agli amministratori di impostare le password per gli utenti finali devono essere disabilitati; o
    2. Utilizzo di una soluzione Single Sign-On ("SSO") esterna con requisiti consolidati non meno sicuri di quelli stabiliti nell'impostazione della password Zendesk "Alta" e abilitazione e applicazione dell'autenticazione a 2 fattori all'interno della soluzione selezionata per l'accesso di tutti gli agenti. I controlli amministrativi che consentono agli amministratori di impostare le password per gli utenti finali devono essere disabilitati.
    3. Tutte le opzioni di autenticazione che usano SSO come metodo di autenticazione devono disabilitare l’accesso con password.
  2. La crittografia Secure Socket Layer ("SSL") sugli account abilitati HIPAA deve rimanere sempre abilitata. Gli account abilitati HIPAA che utilizzano un dominio diverso da zendesk.com devono stabilire e mantenere SSL in hosting.
  3. L’accesso degli agenti deve essere limitato a specifici indirizzi IP sotto il controllo dell’abbonato a meno che l’Abbonato non abiliti l’autenticazione a più fattori per gli agenti come descritto sopra nei requisiti 1.a o 1.b (in modo nativo all’interno del Servizio o nell’ambiente dell’Abbonato in combinazione con Enterprise SSO).  A scanso di equivoci, “Accesso agente” indica l’accesso concesso a un agente umano che accede ai Dati del servizio tramite l’interfaccia utente (“UI”).
  4. Nella misura in cui l’account abilitato HIPAA dell’abbonato consente le chiamate alle interfacce di programmazione delle applicazioni Zendesk ("API"), l’abbonato si assume tutta la responsabilità di comprendere le implicazioni sulla sicurezza di tutti gli abbonati o di entità di terzi autorizzati a creare, accedere, modificare o eliminare Dati di servizio e PHI tramite tale accesso e/o integrazioni. Per l’accesso a tale API, Zendesk offre vari metodi descritti qui e l’abbonato deve implementare le seguenti best practice di sicurezza in base al modello API usato:
    1. Approccio OAuth 2.0.  Questo modello fornisce le funzionalità di sicurezza più granulari, ma richiede che i diritti siano accettati da un utente finale.  Ove possibile, l’abbonato utilizzerà l’approccio e lo schema di autenticazione OAuth 2.0. L’abbonato assegna a ciascun client OAuth un nome client descrittivo e univoco e una funzione di designazione di un identificatore univoco. Le autorizzazioni concesse per ciascun token OAuth dovrebbero consentire il privilegio minimo necessario per svolgere le attività richieste.
    2. Approccio token API REST.  Questo modello è il più ampio e consente a un token API di utilizzare tutte le funzionalità del modello API. Per sua natura, fornisce l’accesso e le funzionalità più ampi e deve essere usato con cautela. Quando usa questo approccio, l’abbonato (i) usa un token univoco per ciascun servizio e assegna al token una funzione di designazione del nome descrittivo; (ii) non condividere token API con terzi a meno che non sia ragionevolmente richiesto e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se il token API è condiviso con terzi e l’abbonato viene informato di una violazione dei dati di terzi, l’abbonato ruota immediatamente il token associato; e (iv) come minimo, ruotare frequentemente il token in base alle politiche dell’organizzazione dell’abbonato.  
    3. Quando possibile, l’abbonato deve disabilitare l’accesso tramite password all’API, in quanto questo approccio invia le credenziali dell’utente con ogni richiesta che le espone ampiamente, rendendole più facilmente intercettabili da parte di malintenzionati.  
  5. L’abbonato deve abilitare “Richiedi autenticazione per il download” per richiedere l’autenticazione per accedere agli allegati. In caso contrario, chiunque abbia accesso all’URL corretto per tale allegato può accedere a qualsiasi allegato senza limitazioni. In tali casi, l’Abbonato si assume tutta la responsabilità del contenuto e dell’accesso a tali dati allegati.
  6. L’abbonato deve applicare sistematicamente, a tutti gli endpoint a cui accedono agenti, amministratori e proprietari, uno screensaver bloccato con password o una schermata di avvio impostata per un massimo di quindici (15) minuti di inattività del sistema.
  7. L’abbonato non deve alterare le autorizzazioni di visualizzazione che consentono a un utente di vedere gli aggiornamenti per un’intera istanza/brand/organizzazione o modificare l’impostazione predefinita che consente l’accesso oltre ai ticket dell’utente (a meno che l’abbonato non si assuma tutta la responsabilità di garantire che tali utenti siano autorizzati ad accedere a tutti dati successivi). L’abbonato riconosce che le autorizzazioni dell’organizzazione degli utenti finali possono essere impostate nel profilo utente e nell’organizzazione stessa e, in caso di conflitto, l’impostazione più permissiva ha la precedenza su quella meno permissiva.
  8. L’abbonato riconosce che Zendesk non è responsabile della protezione delle trasmissioni email degli utenti finali e dei relativi Dati di servizio prima che vengano ricevuti nell’istanza Zendesk Support dell’abbonato. Sono incluse le PHI che possono essere inoltrate via email tramite risposte ai ticket Zendesk Support , inclusi, a titolo esemplificativo, commenti o allegati ai ticket.
  9. L’abbonato riconosce che Zendesk Support invia un’email a un utente finale in varie circostanze, ad esempio quando l’agente di un abbonato risponde a un ticket Zendesk Support tramite il canale email o quando viene avviato da un’automazione o da un trigger. Per impostazione predefinita, questa email contiene la corrispondenza dei ticket più recente o altre informazioni configurate per essere incluse in una notifica automatizzata, che potrebbe includere PHI. Per proteggere ulteriormente l’abbonato, la sua istanza Zendesk Support dovrebbe esserlo configurato per avvisare solo l’utente finale della risposta di un agentee richiedere all’utente finale di autenticarsi in Zendesk Support per vedere il contenuto del messaggio.
  10. L’Abbonato riconosce che qualsiasi funzionalità di SMS sfruttata a sua esclusiva discrezione in qualsiasi Servizio Zendesk è supportata da SMS e/o protocolli correlati, il che può comportare la trasmissione non crittografata di messaggi inviati o usciti dai Servizi.  Pertanto, la funzionalità degli SMS dovrebbe:
    1. non può essere usato in un account abilitato HIPAA *, oppure
    2. se utilizzato, l’Abbonato si assume tutta la responsabilità dell’uso di tale funzionalità
  11. L’Abbonato riconosce che l’uso della funzionalità legacy Sondaggi sulla soddisfazione dei clienti ("CSAT legacy") del Servizio invia via email i Dati del servizio (che potrebbero contenere PHI) associati al ticket Support al fine di ottenere la valutazione dell’utente, il cui stato di crittografia non è controllato di Zendesk. Pertanto, la funzionalità CSAT legacy dovrebbe:
    1. non può essere usato in un account abilitato HIPAA *, oppure
    2. se utilizzato, l’Abbonato si assume tutta la responsabilità dell’uso di tale funzionalità
  12. L’ Abbonato prende atto dell’uso della funzionalità Sondaggi sulla soddisfazione dei clienti ("CSAT") del Servizio per il canale di ticketing, se non configurato di conseguenza, invia via email i dati del servizio (che potrebbero contenere PHI) associati al ticket Support per ottenere la valutazione dell’utente, il cui stato di crittografia non è controllato da Zendesk. Inoltre, chiunque abbia l’URL CSAT specifico ha accesso alle risposte fornite per un ticket specifico. Pertanto, quando si usa la funzionalità CSAT per il canale di ticketing, l’abbonato dovrebbe
    1. Configura il corpo dell’email di automazione CSAT in modo da non includere potenziali ePHI e usa il file {{satisfaction.survey_url}} esclusivamente segnaposto
    2. Non usare la funzionalità delle domande aperte

* A scanso di equivoci, le avvertenze sui dati relative a ePHI nella sezione 10 relativa agli SMS non si applicano all’uso dell’autenticazione 2FA all’interno del prodotto (come descritto nella sezione 1.a), in quanto tale funzionalità invia semplicemente una stringa numerica per la verifica dell’identità.

II. Le seguenti configurazioni di sicurezza minime per Zendesk Guide e Gather Services devono essere implementate e sono riconosciute nel BAA per qualsiasi account abilitato HIPAA :

  1. L’Abbonato riconosce che i Servizi Guide e Gather sono pubblici per natura (se non sfruttano articoli soggetti a limitazioni o un’istanza chiusa o limitata) e pertanto l’Abbonato deve garantire che gli articoli in Zendesk Guide o Gather Service non includano PHI, sia attraverso il testo di l’articolo o come allegato o immagine all’interno dell’articolo.
  2. L’abbonato può disabilitare la possibilità per gli utenti finali di aggiungere commenti in Zendesk Guide oppure moderare e assumersi la responsabilità della rimozione delle PHI da tutti i commenti (come indicato nella sezione 3 di seguito).
  3. Laddove il servizio Zendesk Guide sia Guide Professional o Enterprise, gli abbonati devono, quando possibile, disabilitare la possibilità per gli utenti finali di creare nuovi post disattivando la funzionalità Gather con Zendesk Guide oppure quando le funzioni Gather non possono essere utilizzate a causa delle intenzioni dell’abbonato caso d’uso, gli abbonati devono abilitare la moderazione dei contenuti in Zendesk Guide Service e impostarla su “Modera tutti i contenuti”. Nessun invio contenente PHI verrà approvato.
  4. Non è consentito l’uso da parte degli abbonati di “Moderatori della community” non dipendenti dal servizio Gather.
  5. L’abbonato riconosce che le “@menzioni” dei membri della community Gather sono possibili quando consentono agli utenti finali di avere profili pubblici e se questa funzionalità è considerata un rischio nel loro caso d’uso, i profili pubblici saranno disattivati o le @menzioni saranno disabilitate.

III. Le seguenti configurazioni di sicurezza minime per l’uso della messaggistica Zendesk devono essere implementate e sono riconosciute nel BAA Zendesk per qualsiasi account abilitato HIPAA :

  1. L’abbonato non deve abilitare le integrazioni dei canali di messaggistica sui social media a meno che non si assuma la piena responsabilità di (i) garantire che non siano presenti ePHI nei messaggi sui social media o (ii) concludere il proprio BAA con piattaforme di messaggistica integrate.
  2. L’abbonato disabilita la possibilità per gli utenti finali di allegare file alle conversazioni di messaggistica e si assume la piena responsabilità di (i) abilitare allegati sicuri o (ii) garantire che gli agenti non alleghino file contenenti ePHI alle conversazioni di messaggistica. In caso contrario, chiunque abbia accesso all’URL corretto per tale allegato può accedere a qualsiasi allegato senza limitazioni.  In tali casi, l’Abbonato si assume tutta la responsabilità del contenuto e dell’accesso a tali URL e/o dati degli allegati.
  3. L’abbonato si assume la responsabilità di garantire che tutti gli agenti e gli agenti interni possano visualizzare tutti i messaggi in ingresso da tutti gli utenti finali.
  4. Se l’abbonato o i suoi agenti accedono o sviluppano integrazioni (ad esempio come parte di un flusso creato per Answer Bot) per API e webhook o personalizzano l’esperienza di messaggistica, l’abbonato si assume la piena responsabilità di comprendere le implicazioni sulla privacy e sulla sicurezza di tutti i workflow personalizzati e per tutti Gli abbonati o le entità di terzi (inclusi i provider di chatbot) sono autorizzati a creare, accedere, modificare o eliminare i Dati di servizio e le ePHI tramite tale accesso e/o integrazioni.
  5. Se l’Abbonato desidera rimuovere l’autorizzazione di un agente a partecipare a una conversazione di messaggistica mentre la conversazione di messaggistica è attiva, l’Abbonato si assume tutta la responsabilità di forzare la cessazione dell’accesso di tale agente a Zendesk.
  6. Per impostazione predefinita, le conversazioni dei widget web con gli utenti finali sono persistenti e saranno visibili all’utente finale quando torna alla chat web dallo stesso dispositivo. L’abbonato può disabilitare questa funzione o assumersi la responsabilità di garantire che gli utenti finali non condividano i dispositivi.
  7. Se l’abbonato desidera implementare l’autenticazione per gli utenti finali, si assume la responsabilità di implementarla in modo sicuro secondo le migliori pratiche e gli standard del settore.
    1. Quando usa questo approccio, l’abbonato (i) usa una chiave di firma JWT univoca per ciascun canale di autenticazione e assegna al token una funzione di designazione del nome descrittivo; (ii) non condividere le chiavi di firma JWT con terzi a meno che non sia ragionevolmente necessario e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se la chiave di firma JWT viene condivisa con terzi e l’abbonato viene a conoscenza di una violazione dei dati di terzi, l’abbonato ruota immediatamente la chiave di firma JWT associata; e (iv) come minimo, ruotare frequentemente la chiave di firma JWT in conformità con le politiche dell’organizzazione dell’abbonato.
    2. L’abbonato deve usare l’attributo JWT di scadenza e impostarne il valore su non più di 15 minuti.
  8. L’abbonato riconosce che le interazioni tra gli utenti finali e Answerbot che non vengono trasferite a un agente umano e trasferite in un ticket sono comunque memorizzate nel sistema ed è responsabilità dell’abbonato eliminarle in conformità ai propri obblighi (ad esempio implementando un webhook che avvisa l’abbonato quando tali conversazioni vengono memorizzate e ne attiva (automaticamente) l’eliminazione tramite l’API Sunshine Conversations ). 
  9. L’abbonato riconosce che le conversazioni tra gli utenti finali e Answerbot sono state trasformate al momento in un ticket non può essere rimosso. L’eliminazione è possibile eliminando il ticket. 
  10. L’abbonato riconosce che gli allegati degli utenti finali sui canali di messaggistica non sono attualmente sottoposti a scansione per rilevare eventuali malware in Zendesk. L’Abbonato si assume la piena responsabilità di mettere in atto procedure e politiche per ridurre il rischio per le risorse dell’Abbonato. 

IV. Le seguenti configurazioni di sicurezza minime per l’uso di Zendesk Sunshine Conversations (in uso con Zendesk Suite) devono essere implementate e sono riconosciute nel BAA Zendesk per qualsiasi account abilitato HIPAA :

  1. L’abbonato non può abilitare le integrazioni dei canali di terzi a meno che non si assuma la piena responsabilità di garantire (i) l’assenza di ePHI nei messaggi dei canali di terzi o (ii) concludere il proprio BAA con piattaforme di messaggistica integrate.
  2. L’abbonato si assume tutta la responsabilità di comprendere le implicazioni sulla sicurezza di tutti gli abbonati o di entità di terzi autorizzati a creare, accedere, modificare o eliminare i dati di servizio e le PHI tramite le interfacce di programmazione delle applicazioni Sunshine Conversations ("API"). Per l’accesso a tali API, l’abbonato deve implementare le seguenti best practice di sicurezza in base al modello API utilizzato:
    1. Approccio OAuth 2.0.  Questo modello fornisce le funzionalità di sicurezza più granulari, ma richiede che i diritti siano accettati da un utente finale.  Ove possibile, l’abbonato utilizzerà l’approccio e lo schema di autenticazione OAuth 2.0. L’abbonato assegna a ciascun client OAuth un nome client descrittivo e univoco e una funzione di designazione di un identificatore univoco. 
    2. Approccio token API REST.  Questo modello è il più ampio e consente a un token API di utilizzare tutte le funzionalità del modello API.  Per sua natura, fornisce l’accesso e le funzionalità più ampi e deve essere usato con cautela. Quando usa questo approccio, l’abbonato (i) usa un token univoco per ciascun servizio e assegna al token una funzione di designazione del nome descrittivo; (ii) non condividere token API con terzi a meno che non sia ragionevolmente richiesto e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se il token API è condiviso con terzi e l’abbonato viene informato di una violazione dei dati di terzi, l’abbonato ruota immediatamente il token associato; e (iv) ruotare frequentemente il token in conformità con la policy dell’organizzazione dell’abbonato.  
    3. Se l’abbonato o i suoi agenti accedono o sviluppano integrazioni per API e webhook o personalizzano l’esperienza Sunshine Conversations , l’abbonato si assume la piena responsabilità di comprendere le implicazioni sulla privacy e sulla sicurezza di tutti i workflow personalizzati e di tutti gli abbonati o entità di terzi (inclusi i provider di chatbot) consentiti per creare, accedere, modificare o eliminare Dati di servizio ed ePHI tramite tale accesso e/o integrazioni.
  3. L’abbonato riconosce che le limitazioni IP configurate per Zendesk Support non si estendono all’API Sunshine Conversations . Gli abbonati si assumono la piena responsabilità di limitare l’accesso all’API Sunshine Conversations e ai token API come descritto in 2.b. e in conformità con le politiche dell’abbonato. 
  4. L’abbonato disabilita la possibilità per gli utenti finali di allegare file alle Sunshine Conversations e si assume la piena responsabilità dell’abilitazione di allegati sicuri o assicurando che gli agenti non alleghino file contenenti ePHI alle conversazioni di messaggistica. In caso contrario, chiunque abbia accesso all’URL corretto per tale allegato può accedere a qualsiasi allegato senza limitazioni. In tali casi, l’Abbonato si assume tutta la responsabilità del contenuto e dell’accesso a tali dati allegati.
  5. Se l’abbonato desidera implementare l’autenticazione per gli utenti finali, si assume la responsabilità di implementarla in modo solido in base alle best practice di sicurezza e agli standard del settore.
    1. Quando usa questo approccio, l’abbonato (i) usa una chiave di firma JWT univoca per ciascun canale di autenticazione e assegna al token una funzione di designazione del nome descrittivo; (ii) non condividere le chiavi di firma JWT con terzi a meno che non sia ragionevolmente necessario e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se la chiave di firma JWT viene condivisa con terzi e l’abbonato viene a conoscenza di una violazione dei dati di terzi, l’abbonato ruota immediatamente la chiave di firma JWT associata; e (iv) come minimo, ruotare frequentemente la chiave di firma JWT in conformità con le politiche dell’organizzazione dell’abbonato.
    2. L’abbonato deve usare l’attributo JWT di scadenza e impostarne il valore su non più di 15 minuti.
  6. L’abbonato riconosce che le interazioni tra gli utenti finali e Answerbot che non vengono trasferite a un agente umano e trasferite in un ticket sono comunque memorizzate nel sistema ed è responsabilità dell’abbonato eliminarle in conformità ai propri obblighi, ad esempio implementando un webhook che avvisa l’abbonato quando tali conversazioni vengono memorizzate e ne attiva (automaticamente) l’eliminazione tramite l’API Sunshine Conversations 
  7. L’abbonato riconosce che le conversazioni tra gli utenti finali e Answerbot che si sono trasformate in un ticket al momento non possono essere eliminate. L’eliminazione è possibile eliminando il ticket. 
  8. L’abbonato riconosce che i messaggi eliminati tramite l’API Sunshine Conversations vengono eliminati solo per gli utenti finali ma non nello spazio di lavoro agente Zendesk. Ciò può essere ottenuto eliminando il ticket stesso o usando la funzionalità di rimozione (per le limitazioni, vedere 7.). 
  9. L’abbonato riconosce che tutti gli allegati sui canali Sunshine Conversation non sono attualmente sottoposti a scansione alla ricerca di malware in Zendesk. L’Abbonato si assume la piena responsabilità di mettere in atto procedure e politiche per ridurre il rischio per i dipendenti dell’Abbonato. 

V. Le seguenti configurazioni di sicurezza minime per Zendesk Chat Service devono essere implementate e sono riconosciute nel BAA per qualsiasi account abilitato HIPAA :

  1. L’abbonato limita l’accesso degli agenti al servizio Zendesk Chat tramite l’associazione e l’autenticazione tramite il servizio Zendesk Support .
  2. L’abbonato non deve inviare trascrizioni di Chat via email (a) disabilitando il piping email, (b) disabilitando l’opzione di trascrizione email della chat nel Web Widget e (c) non condividendo le esportazioni via email dal dashboard di Chat
  3. L’abbonato non può abilitare lo “Spazio di lavoro agente” a meno che l’abbonato non si assuma la piena responsabilità di garantire (i) l’assenza di ePHI in Chat e/o (ii) che tutti gli agenti siano autorizzati dall’abbonato a visualizzare tali dati.

VI. Le seguenti configurazioni di sicurezza minime per l’uso del servizio Zendesk Explore devono essere implementate e sono riconosciute nel BAA per qualsiasi account abilitato HIPAA :

L’abbonato riconosce che le ePHI possono essere visualizzate nel prodotto Explore tramite nomi utente, titoli dei ticket, scelte di campi e moduli e qualsiasi contenuto trovato nei campi di testo a modulo libero.

  1. Per qualsiasi istanza del Servizio inclusa nell’ambito contenente PHI, l’Abbonato deve (i) concedere l’accesso all’interfaccia Explore solo agli agenti che possono accedere a tutti i ticket/chiamate/chat che possono contenere PHI nelle istanze del Servizio principali e (ii) concede tale accesso tenendo conto del minor numero di privilegi necessari per l’uso di Explore nel proprio ambiente. Per ulteriori informazioni sulla configurazione dei livelli di accesso in Explore, consulta qui.
  2. Laddove sfruttando la funzionalità di “esportazione”, (i) l’abbonato riconosce che le PHI possono essere trasferite al dispositivo autorizzato dall’abbonato ad accedere all’interfaccia dell’agente e che tutti i relativi controlli su tali dispositivi sono responsabilità dell’abbonato e (ii) l’abbonato negherà l’uso della funzionalità di esportazione nativa via email per detti report esportati, a meno che non si assuma la responsabilità di (a) garantire che non contengano PHI in tali esportazioni, oppure (b) che i servizi email usati per tali trasferimenti possano supportare la crittografia tramite il protocollo di crittografia minimo consentito dagli attuali standard PCI.

* Considerazioni speciali sull’uso di Explore Enterprise:

L’abbonato riconosce che l’uso del servizio Explore Enterprise può comportare una maggiore condivisione dei dati e funzionalità di esportazione. L’abbonato deve:

  1. (i) assicurarsi che non esistano ePHI in tali dashboard e/o (ii) condividere i dashboard solo con agenti, gruppi, elenchi o utenti finali autorizzati a visualizzare e ricevere tali dati.
  2. sfruttare le limitazioni IP
  3. in caso di condivisione di dashboard tramite URL (Uniform Resource Locator), l’abbonato riconosce che, anziché condividere con account utente individuali o di gruppo, i dati devono essere condivisi tramite un link di accesso. L’Abbonato deve pertanto (i) abilitare la protezione tramite password, (ii) garantire che la complessità, la rotazione, l’archiviazione e la distribuzione delle password scelte alla parte ricevente siano conformi alle policy sulle password dell’Abbonato per la protezione dei dati contenuti in tali dashboard e (iii) sia ruotata senza indebito ritardo in caso di sospetto o conferma di esposizione

VII. Avviso sulle funzionalità interne al prodotto per i servizi associati distribuiti ("Componenti aggiuntivi"):

  1. Servizio associato distribuito in collaborazione: “Conversazioni laterali”. L’abbonato riconosce che l’uso della funzionalità “Conversazione laterale” può comportare la creazione o l’invio di messaggi “ticket secondari” e/o “conversazioni laterali” dall’istanza Support dell’abbonato ai destinatari tramite ticket, email, Slack o integrazioni (a discrezione dell’agente). . Se l’abbonato sceglie di usare questa funzionalità in un account abilitato HIPAA , l’abbonato si assume la responsabilità di (i) garantire che non siano presenti PHI in tali messaggi o (ii) se le PHI potrebbero essere presenti nei messaggi, l’abbonato è l’unico responsabile per qualsiasi responsabilità, costo, danno o danno relativo all’acquisizione, all’accesso, all’uso o alla divulgazione non autorizzati di PHI derivanti dallo scambio di messaggi tramite la funzionalità “Conversazione laterale”.

VIII. Le seguenti configurazioni di sicurezza minime per l’uso delle applicazioni mobili Zendesk (o l’accesso effettuato da dispositivi mobili come smartphone o tablet) devono essere implementate e sono riconosciute nel BAA Zendesk per qualsiasi account abilitato HIPAA :

  1. L’uso include la crittografia a livello di dispositivo
  2. Si utilizzerà l’accesso biometrico o PIN impostato sul dispositivo più alto consentito
  3. Le notifiche che consentono di visualizzare i commenti dei ticket nelle schermate di blocco di tali dispositivi saranno disabilitate
  4. I blocchi di inattività dello schermo devono essere abilitati e configurati in modo da bloccarsi a non più di 15 minuti di inattività.
  5. L’abbonato riconosce che l’applicazione mobile Zendesk Support non mostra se gli allegati sono stati scansionati e rilevati come malware e gli agenti devono accedere tramite browser per visualizzare queste informazioni. L’abbonato si assume la piena responsabilità di mettere in atto procedure e politiche per mitigare possibili rischi.
  6. L’abbonato riconosce che la funzionalitàdi rimozione non è disponibile nell’applicazione per dispositivi mobili Support e che gli agenti devono accedere tramite browser se desiderano usare la funzionalità di rimozione.
  7. Se l’abbonato sceglie di autenticare gli utenti finali per la messaggistica Zendesk, l’abbonato riconosce che lo stato di autenticazione di un utente finale non viene visualizzato nell’applicazione Support Mobile.

IX. Per gli abbonati che hanno firmato il BAA di Zendesk e successivamente hanno usato il servizio Zendesk Insights, la nostra assistenza per questo servizio sarà ritirata a partire dal 5 febbraio 2021.   

X. Avviso sulle funzionalità di intelligenza artificiale di Zendesk (“Intelligenza artificiale Zendesk”, “Intelligenza artificiale avanzata”, “Intelligenza artificiale generativa”, ecc.):

  1. L’abbonato riconosce che le funzioni di intelligenza artificiale di Zendesk hanno lo scopo di aumentare la produttività dei Servizi Zendesk e non devono essere usate in un modo che potrebbe essere interpretato come (i) fornire consulenza medica o sanitaria, (ii) fornire una diagnosi di una condizione o sintomi, (iii) prescrivere un trattamento o (iv) impedire in qualsiasi modo a un Utente di chiedere consiglio, diagnosi o trattamento a un operatore sanitario, (v) o fornire in altro modo a un Utente informazioni o prendere decisioni in merito a tali sintomi. qualsiasi piano sanitario, programma di trattamento, servizio di test o qualsiasi altro servizio sanitario che potrebbe influire sulla ricerca o sulla ricezione di servizi sanitari (a meno che l’Abbonato non si assuma la piena responsabilità di questa decisione in base al suo caso d’uso unico e alle interazioni con i propri Utenti, nonché come le potenziali implicazioni dell’uso dell’intelligenza artificiale in questo modo).
  2. L’abbonato riconosce che, se si usa qualsiasi funzione di intelligenza artificiale generativa basata su OpenAI, gli output di OpenAI sono generati dal computer e non dall’uomo e possono produrre output imprecisi. Zendesk non garantisce l'accuratezza di questi output.
  3. L’abbonato riconosce che se un messaggio di saluto bot Zendesk viene usato per fornire un messaggio di limitazione di responsabilità agli utenti finali dell’abbonato, la funzionalità “Genera varianti” non sarà attivata per garantire l’integrità del contenuto del messaggio. 
  4. L’abbonato riconosce che l’attivazione della funzionalità di intelligenza artificiale generativa per gli agenti / intelligenza artificiale generativa per la Knowledge base nel Centro amministrativo abiliterà questa funzionalità per tutti gli agenti nella sua istanza, indipendentemente dai ruoli e dalle autorizzazioni. 


      

Dichiarazione di non responsabilità: A causa di modifiche legislative o regolamentari o di modifiche al Servizio Zendesk, le configurazioni di sicurezza in questo documento potrebbero cambiare di volta in volta. Questo documento contiene le raccomandazioni di Zendesk per le configurazioni di sicurezza minime efficaci per la protezione delle PHI nei prodotti Zendesk descritte sopra. Questo documento non costituisce un modello esaustivo per tutti i controlli su tali dati né costituisce una consulenza legale. Ogni abbonato Zendesk deve rivolgersi al proprio consulente legale in merito ai propri requisiti di conformità HIPAA e apportare le modifiche aggiuntive alle proprie configurazioni di sicurezza in base all'analisi indipendente di ciascun abbonato, a condizione che tali modifiche non contrastino o riducano la sicurezza delle configurazioni descritto in questo documento.

 

Registro modifiche Account abilitati HIPAA :

 

10 ottobre 2024

  • Aggiunta la sezione I, Support, numero 12 (CSAT) e modificata la sezione I, Support, numero 11 (CSAT legacy) per adattarsi alle nuove funzionalità. 

7 marzo 2024

  • Aggiunta la sezione X, Avviso sulle funzionalità di intelligenza artificiale di Zendesk
  • Sezione I, Support, numero 7 (autorizzazioni di visualizzazione):
    • È stato chiarito che le "autorizzazioni di visualizzazione" riguardano un'intera "istanza/brand/organizzazione" anziché solo "organizzazione".
    • Aggiunta una nuova disposizione per il comportamento dell’organizzazione specifico degli utenti finali. 
  • Sezione I, Support, numero 9 (email):  
    • Sono state ampliate le circostanze in cui Zendesk Support invia un’email a un utente finale per includere le risposte tramite il canale email o quelle avviate da un’automazione o da un trigger, anziché solo un agente che risponde a un ticket.
    • Ha specificato che, per impostazione predefinita, le notifiche automatizzate possono contenere la corrispondenza dei ticket più recente o altre informazioni configurate, che potrebbero includere le PHI.

 

25 ottobre 2023

  • Introduzione Chiarito il linguaggio di introduzione per gli account abilitati HIPAA
  • Sezione II, Guide and Gather, numero 1 (Restrizioni del centro assistenza): ha sostituito le limitazioni della PI con articoli riservati per chiarimenti

 

13 aprile 2023

  • Sezione I, Support, numero 4 (API): 
    • Aggiunto link ai metodi di autenticazione per maggiore chiarezza 
    • b) Rimossi i consigli sull’intervallo di tempo esatto per la rotazione per allinearli alle best practice del settore e rimossi i riferimenti ai Termini di servizio dell’API REST (ridondanza)
    • aggiunto c) per avvertire dell’uso dell’autenticazione di base per l’API 
  • Sezione II, Guida:
    • Numero 1 (Limitazioni per i centri assistenza): aggiunto riferimento ai centri assistenza chiusi o con limitazioni per allinearlo alle funzionalità del prodotto
    • Numero 5 (@menzioni): Aggiunta opzione per disabilitare le @menzioni per allinearle al prodotto funzionalità 
  • Sezione III, Messaggistica: 
    • Numero 1 e 2 (canali di terzi e allegati privati): aggiunti gliidentificatoridi sezione (i) e (ii) per maggiore chiarezza
    • Numero 2 (allegati privati): aggiunto “URL e/o” per chiarimenti
    • Numero 7-10 (Autenticazione utente finale, eliminazione conversazioni Answerbot, rimozione, scansione malware): sezioni complete aggiunte per trasparenza
  • Sezione IV, Sunshine Conversations: l’intera sezione è stata aggiunta a causa dell’inclusione nel BAA di Sunshine Conversations in Zendesk Suite 
  • Sezione V, Chat, numero 3 (Spazio di lavoro agente): piccole correzioni di fraseggio
  • Sezione VIII, applicazioni mobili, numero 5-7 (scansione malware, rimozione malware, autenticazione degli utenti finali): intere sezioni aggiunte per trasparenza

24 febbraio 2023

  • Sezione I. Support, numero 3: è stata rimossa la distinzione separata tra le limitazioni IP di Support e Chat in quanto l’interfaccia utente è ora unificata.
  • Sezione I. Support, numero 5: chiarimenti aggiunti sul mancato rispetto del requisito 
  • Sezione I. Support, numero 7: “L’abbonato non deve” è cambiato in “L’abbonato non deve”.
  • Sezione IV. Chat, numero 2: chiarisce che tutte le funzionalità di esportazione dei dati da Chat tramite email sono vietate e non riguardano solo trascrizioni e piping. 
  • Sezione III. messaggistica: aggiunta dell’intera sezione all’account della funzionalità di messaggistica Zendesk che si aggiunge all’ambito del Contratto di società in affari di Zendesk.

9 luglio 2021

  • Aggiunge il punto 3. nella sezione Chat per le responsabilità relative all’utilizzo dello spazio di lavoro agente.

21 gennaio 2021

  • L’aggiunta del numero 1.11 non consente CSAT a meno che l’abbonato non si assuma la responsabilità dei dati inviati via email nell’ambito del sondaggio. 
  • Avvertenza nel numero 1.7 per consentire agli abbonati di alterare le autorizzazioni di visualizzazione a causa del fatto che gli utenti hanno già l’autorizzazione ad accedere a tali dati.
  • Intero documento aggiornato in modo che corrisponda allo stileaziendale dei link incorporati nel testo anziché agli URL incorporati (nessun impatto sul contenuto della configurazione).

Agosto 2020

  • Aggiunta di Explore Enterprise che copre maggiori capacità di condivisione dei dashboard
  • Rimozione del divieto di allegati Chat (ora sono coperti i requisiti di autenticazione di Support )
  • Disambigua: il divieto di ePHI nei campi personalizzati si applicava specificamente all’uso di Insights e non a livello globale
  • Aggiunta di una nuova sezione relativa ai componenti aggiuntivi ai servizi distribuiti, con la prima aggiunta di "Conversazioni laterali"
  • Varie modifiche alla grammatica e alla formattazione (senza conseguenze per il contenuto)

13 luglio 2020:

  • Disambiguazione dell’uso degli SMS tramite il Servizio rispetto all’uso nativo degli SMS per l’autenticazione 2FA all’interno del prodotto. * A scanso di equivoci, le avvertenze sui dati relative a ePHI nella sezione 10 relativa agli SMS non si applicano all’uso dell’autenticazione 2FA all’interno del prodotto (come descritto nella sezione 1.a), in quanto tale funzionalità invia semplicemente una stringa numerica per la verifica dell’identità.

13 dicembre 2019 

  • consente di eliminare le limitazioni IP degli agenti laddove il caso d'uso non consente tali limitazioni, a condizione che venga applicata l'autenticazione a più fattori dell'accesso degli agenti.

17 dicembre 2019 

  • consente di inserire i commenti degli utenti finali in Guide, a condizione che gli agenti moderano tali commenti e rimuovano tutte le PHI.

6 novembre 2019

  • Articolo aggiornato per riflettere la modifica che gli abbonati possono scegliere a loro esclusiva discrezione di rinunciare o sostituire qualsiasi configurazione particolare purché si assumano la responsabilità di tale decisione.

"La mancata implementazione e osservanza da parte dell'abbonato di una particolare configurazione elencata di seguito o di qualsiasi serie di configurazioni richieste elencate di seguito, sarà

a proprio rischio e a esclusiva discrezione dell’Abbonato; e tale inadempimento esonera Zendesk e i suoi dipendenti, agenti e affiliati da qualsiasi responsabilità in relazione a qualsiasi accesso non autorizzato o uso o divulgazione impropri dei Dati di servizio dell’abbonato, incluse le informazioni sanitarie protette elettroniche, risultante da tale errore da parte dell’abbonato . "

  • Altre modifiche includono
    • 1. la possibilità di usare gli SMS a condizione che l’abbonato si assuma la responsabilità di garantire che non siano presenti PHI in tali trasmissioni.
    • 2. La possibilità di usare gli allegati in Chat a condizione che l’abbonato si assuma la responsabilità di garantire che non siano presenti PHI in tali allegati.

6 marzo 2019 

  • aggiornato per includere le impostazioni per Zendesk Explore

17 gennaio 2019

  •  aggiornato per non consentire gli allegati in Chat.

 

Account abilitati HDS:

Tutti i termini in maiuscolo usati in questo documento hanno il significato loro attribuito nell’Allegato sui termini HDS al Master Subscription Agreement di Zendesk ("Allegato sui termini HDS").
Zendesk e l’Abbonato hanno stipulato l’Allegato relativo alle condizioni HDS, che richiede che l’Abbonato implementi e rispetti le seguenti configurazioni per tutti gli Account abilitati HDS prima di introdurre qualsiasi Informazione sanitaria personale ("PHI") nei Servizi. Tutti i termini in maiuscolo usati in questo documento hanno il significato loro attribuito nell’Allegato sui termini HDS.
La mancata implementazione e osservanza da parte dell’Abbonato di una qualsiasi configurazione particolare elencata di seguito, o qualsiasi serie di configurazioni richieste elencate di seguito, sarà a proprio rischio e ad esclusiva discrezione dell’Abbonato; e tale inadempimento esonera Zendesk e i suoi dipendenti, agenti e affiliati da qualsiasi responsabilità in relazione a qualsiasi accesso non autorizzato o uso o divulgazione impropri dei Dati di servizio dell’abbonato, incluse le informazioni sanitarie personali elettroniche, che derivi da tale errore da parte dell’abbonato. .
Le seguenti configurazioni di sicurezza minime per Zendesk Support devono essere implementate e sono indicate nell’Allegato sui termini HDS per qualsiasi account abilitato per HDS:

 

Le seguenti configurazioni di sicurezza minime per Zendesk Support devono essere implementate e sono indicate nell’Allegato sui termini HDS per qualsiasi account abilitato per HDS:

  1. Autenticazione Secure Agent tramite uno dei due metodi seguenti:
    1. Utilizzo di Zendesk Support nativo con impostazioni della password: (i) impostato su “Alto”; o (ii) personalizzato dall’Abbonato in modo da stabilire requisiti non meno sicuri di quelli stabiliti nell’impostazione “Alto”. Inoltre, in base all'opzione in questa sottosezione, l'Abbonato deve anche abilitare e applicare l'autenticazione a due fattori ("2FA") in modo nativo all'interno del Servizio; e i controlli amministrativi che consentono agli amministratori di impostare le password per gli utenti finali devono essere disabilitati; o
    2. Utilizzo di una soluzione Single Sign-On ("SSO") esterna con requisiti consolidati non meno sicuri di quelli stabiliti nell'impostazione della password Zendesk "Alta" e abilitazione e applicazione dell'autenticazione a 2 fattori all'interno della soluzione selezionata per l'accesso di tutti gli agenti. I controlli amministrativi che consentono agli amministratori di impostare le password per gli utenti finali devono essere disabilitati.
    3. Tutte le opzioni di autenticazione che usano SSO come metodo di autenticazione devono disabilitare l’accesso con password.
  2. La crittografia Secure Socket Layer ("SSL") negli account abilitati HDS deve rimanere sempre abilitata. Gli account abilitati per HDS che utilizzano un dominio diverso da zendesk.com devono stabilire e mantenere SSL in hosting.
  3. L’accesso degli agenti deve essere limitato a specifici indirizzi IP sotto il controllo di Abbonato per Support e Chata meno che l’Abbonato non abiliti l’autenticazione a più fattori per gli agenti come descritto sopra nei requisiti 1.a o 1.b (in modo nativo all’interno del Servizio o nell’ambiente dell’Abbonato in combinazione con Enterprise SSO).  A scanso di equivoci, “Accesso agente” indica l’accesso concesso a un agente umano che accede ai Dati del servizio tramite l’interfaccia utente (“UI”).
  4. Nella misura in cui l’account abilitato per HDS dell’abbonato consente le chiamate alle interfacce di programmazione delle applicazioni Zendesk ("API"), l’abbonato si assume tutta la responsabilità di comprendere le implicazioni sulla sicurezza di tutti gli abbonati o di entità di terzi autorizzate a creare, accedere, modificare o eliminare Dati di servizio e PHI tramite tale accesso e/o integrazioni. Per l’accesso a tali API, l’abbonato deve implementare le seguenti best practice di sicurezza in base al modello API utilizzato:
    1. Approccio OAuth 2.0.  Questo modello fornisce le funzionalità di sicurezza più granulari, ma richiede che i diritti siano accettati da un utente finale.  Ove possibile, l’abbonato utilizzerà l’approccio e lo schema di autenticazione OAuth 2.0. L’abbonato assegna a ciascun client OAuth un nome client descrittivo e univoco e una funzione di designazione di un identificatore univoco. Le autorizzazioni concesse per ciascun token OAuth dovrebbero consentire il privilegio minimo necessario per svolgere le attività richieste.
    2. Approccio token API REST.  Questo modello è il più ampio e consente a un token API di utilizzare tutte le funzionalità del modello API.  Per sua natura, fornisce l’accesso e le funzionalità più ampi e deve essere usato con cautela. Quando usa questo approccio, l’abbonato (i) usa un token univoco per ciascun servizio e assegna al token una funzione di designazione del nome descrittivo; (ii) non condividere token API con terzi a meno che non sia ragionevolmente richiesto e in base a metodi di trasmissione crittografati end-to-end; (iii) riconosce che se il token API è condiviso con terzi e l’abbonato viene informato di una violazione dei dati di terzi, l’abbonato ruota immediatamente il token associato; e (iv) come minimo, ruotare il token una volta ogni centottanta (180) giorni.  L’abbonato deve attenersi ai Termini di servizio dell’API REST del servizio. 
  5. L’abbonato deve abilitare “Richiedi autenticazione per il download” per richiedere l’autenticazione per accedere agli allegati.
  6. L’abbonato deve applicare sistematicamente, a tutti gli endpoint a cui accedono agenti, amministratori e proprietari, uno screensaver bloccato con password o una schermata di avvio impostata per un massimo di quindici (15) minuti di inattività del sistema.
  7. L’abbonato non deve modificare le autorizzazioni di visualizzazione che consentono a un utente di vedere gli aggiornamenti per un’intera organizzazione o l’impostazione predefinita che consente l’accesso al di là dei ticket dell’utente (a meno che l’abbonato non si assuma tutta la responsabilità di garantire che tali utenti siano autorizzati dall’abbonato ad accedere a tutti i dati successivi).
  8. L’abbonato riconosce che Zendesk non è responsabile della protezione delle trasmissioni email degli utenti finali e dei relativi Dati di servizio prima che vengano ricevuti nell’istanza Zendesk Support dell’abbonato. Sono incluse le PHI che possono essere inoltrate via email tramite risposte ai ticket Zendesk Support , inclusi, a titolo esemplificativo, commenti o allegati ai ticket.
  9. L’abbonato riconosce che Zendesk Support invia un’email a un utente finale quando l’agente dell’abbonato risponde a un ticket Zendesk Support .  Per impostazione predefinita, questa email contiene tutta la corrispondenza che l’agente ha inviato all’utente finale e potrebbe includere PHI. Per proteggere ulteriormente l’abbonato, la sua istanza Zendesk Support deve essere configurata in modo da avvisare l’utente finale solo della risposta di un agentee richiedere all’utente finale di autenticarsi in Zendesk Support per vedere il contenuto del messaggio.
  10. L’Abbonato riconosce che qualsiasi funzionalità di SMS sfruttata a sua esclusiva discrezione in qualsiasi Servizio Zendesk è supportata da SMS e/o protocolli correlati, il che può comportare la trasmissione non crittografata di messaggi inviati o usciti dai Servizi.  Pertanto, la funzionalità degli SMS dovrebbe:
    1. non può essere usato in un account abilitato HDS*, oppure
    2. se utilizzato, l’Abbonato si assume tutta la responsabilità dell’uso di tale funzionalità.

* A scanso di equivoci, le avvertenze sui dati relative a ePHI nella sezione 10 relativa agli SMS non si applicano all’uso dell’autenticazione 2FA all’interno del prodotto (come descritto nella sezione 1.a), in quanto tale funzionalità invia semplicemente una stringa numerica per la verifica dell’identità.

Le seguenti configurazioni di sicurezza minime per Zendesk Guide e Gather Services devono essere implementate e sono indicate nell’Allegato sui termini HDS per qualsiasi account abilitato per HDS:

  1. L’Abbonato riconosce che i Servizi Guide e Gather sono pubblici per natura (se non sfruttano le limitazioni IP per i centri assistenza “interni”) e pertanto l’Abbonato deve garantire che gli articoli in Zendesk Guide o Gather Service non includano le PHI, sia attraverso il testo del articolo o come allegato o immagine all’interno dell’articolo.
  2. L’abbonato può disabilitare la possibilità per gli utenti finali di aggiungere commenti in Zendesk Guide oppure moderare e assumersi la responsabilità della rimozione delle PHI da tutti i commenti.
  3. Non è consentito l’uso da parte degli abbonati di “Moderatori della community” non dipendenti dal servizio Gather.

Le seguenti configurazioni di sicurezza minime per il servizio Zendesk Chat devono essere implementate e sono indicate nell’Allegato sui termini HDS per qualsiasi account abilitato per HDS:

  1. L’abbonato limita l’accesso degli agenti al servizio Zendesk Chat tramite l’associazione e l’autenticazione tramite il servizio Zendesk Support .
  2. L’abbonato deve disabilitare il piping email.
  3. L’abbonato non può abilitare gli “Spazi di lavoro agente” a meno che non si assuma la piena responsabilità di garantire (i) l’assenza di ePHI in Chat e/o (ii) che tutti gli agenti siano autorizzati dall’abbonato a visualizzare tali dati.

Le seguenti configurazioni di sicurezza minime per l’uso del servizio Zendesk Explore devono essere implementate e sono indicate nell’Allegato sui termini HDS per qualsiasi account abilitato per HDS:

L’abbonato riconosce che le ePHI possono essere visualizzate nel prodotto Explore tramite nomi utente, titoli dei ticket, scelte di campi e moduli e qualsiasi contenuto trovato nei campi di testo a modulo libero.

  1. Per qualsiasi istanza del Servizio inclusa nell’ambito contenente PHI, l’Abbonato deve (i) concedere l’accesso all’interfaccia Explore solo agli agenti che possono accedere a tutti i ticket/chiamate/chat che possono contenere PHI nelle istanze del Servizio principali e (ii) concede tale accesso tenendo conto del minor numero di privilegi necessari per l’uso di Explore nel proprio ambiente. Per ulteriori informazioni sulla configurazione dei livelli di accesso in Explore, consulta qui.
  2. Laddove sfruttando la funzionalità di “esportazione”, (i) l’abbonato riconosce che le PHI possono essere trasferite al dispositivo autorizzato dall’abbonato ad accedere all’interfaccia dell’agente e che tutti i relativi controlli su tali dispositivi sono responsabilità dell’abbonato e (ii) l’abbonato negherà l’uso della funzionalità di esportazione nativa via email per detti report esportati, a meno che non si assuma la responsabilità di (a) garantire che non contengano PHI in tali esportazioni, oppure (b) che i servizi email usati per tali trasferimenti possano supportare la crittografia tramite il protocollo di crittografia minimo consentito dagli attuali standard PCI.

* Considerazioni speciali sull’uso di Explore Enterprise:

L’abbonato riconosce che l’uso del servizio Explore Enterprise può comportare una maggiore condivisione dei dati e funzionalità di esportazione. L’abbonato deve:

  1. (i) assicurarsi che non esistano ePHI in tali dashboard e/o (ii) condividere i dashboard solo con agenti, gruppi, elenchi o utenti finali autorizzati a visualizzare e ricevere tali dati.
  2. sfruttare le limitazioni IP
  3. in caso di condivisione di dashboard tramite URL (Uniform Resource Locator), l’abbonato riconosce che, anziché condividere con account utente individuali o di gruppo, i dati devono essere condivisi tramite un link di accesso. L’Abbonato deve pertanto (i) abilitare la protezione tramite password, (ii) garantire che la complessità, la rotazione, l’archiviazione e la distribuzione delle password scelte alla parte ricevente siano conformi alle policy sulle password dell’Abbonato per la protezione dei dati contenuti in tali dashboard e (iii) sia ruotata senza indebito ritardo in caso di sospetto o conferma di esposizione

Le seguenti configurazioni di sicurezza minime per l’uso delle applicazioni mobili Zendesk (o l’accesso tramite dispositivi mobili come smartphone o tablet) devono essere implementate e sono riconosciute nell’esposizione delle condizioni HDS per qualsiasi account abilitato per HDS:

  1. L’uso include la crittografia a livello di dispositivo
  2. Si utilizzerà l’accesso biometrico o PIN impostato sul dispositivo più alto consentito
  3. Le notifiche che consentono di visualizzare i commenti dei ticket nelle schermate di blocco di tali dispositivi saranno disabilitate
  4. I blocchi di inattività dello schermo devono essere abilitati e configurati in modo da bloccarsi a non più di 15 minuti di inattività.

Avviso sulle funzionalità interne al prodotto per i servizi associati distribuiti ("Componenti aggiuntivi"):

  1. Servizio associato distribuito in collaborazione: “Conversazioni laterali”. L’abbonato riconosce che l’uso della funzionalità “Conversazione laterale” può comportare la creazione o l’invio di messaggi “ticket secondari” o “conversazione laterale” dall’istanza Support dell’abbonato ai destinatari tramite ticket, email, Slack o integrazioni (a discrezione dell’agente). Se l’abbonato sceglie di usare questa funzionalità in un account abilitato per HDS, l’abbonato si assume la responsabilità di (i) garantire che non siano presenti PHI in tali messaggi o (ii) se le PHI potrebbero essere presenti nei messaggi, l’abbonato è l’unico responsabile per qualsiasi responsabilità, costo, danno o danno relativo all’acquisizione, all’accesso, all’uso o alla divulgazione non autorizzati di PHI derivanti dallo scambio di messaggi tramite la funzionalità “Conversazione laterale”.

Dichiarazione di non responsabilità: A causa di modifiche legislative o regolamentari o di modifiche al Servizio Zendesk, le configurazioni di sicurezza in questo documento potrebbero cambiare di volta in volta. Questo documento contiene le raccomandazioni di Zendesk per le configurazioni di sicurezza minime efficaci per la protezione delle PHI nei prodotti Zendesk descritte sopra. Questo documento non costituisce un modello esaustivo per tutti i controlli su tali dati né costituisce una consulenza legale. Ogni abbonato Zendesk deve rivolgersi al proprio consulente legale in merito ai requisiti di conformità HDS e apportare le modifiche aggiuntive alle proprie configurazioni di sicurezza in base all'analisi indipendente di ciascun abbonato, a condizione che tali modifiche non contrastino o riducano la sicurezza delle configurazioni descritto in questo documento.

Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.

Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.

Powered by Zendesk