最近搜索


没有最近搜索

Craig Lima's Avatar

Craig Lima

已加入2021年4月14日

·

最后活动2025年1月02日

关注

0

关注者

0

活动总数

11

投票

0

订阅

3

活动概览

的最新活动 Craig Lima

Craig Lima 进行了评论,

评论Zendesk policies and agreements

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

查看评论 · 已于 2025年1月02日 发布 · Craig Lima

0

关注者

0

投票

0

评论


Craig Lima 进行了评论,

评论Zendesk policies and agreements

Dec 16th 2024

1. Added section XI to incorporate Zendesk QA into scope 

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

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

查看评论 · 已于 2024年12月17日 发布 · Craig Lima

0

关注者

0

投票

0

评论


Craig Lima 创建了一篇文章,

文章Zendesk 政策和协议
Zendesk WFM (Tymeshift)、Zendesk QA (Klaus) 和 Ultimate 功能由 Google Cloud Platform (GCP) 托管,可能无法在此页面所列的地区提供托管。

Zendesk 托管订阅者服务数据的 AWS 区域

我们目前在以下 AWS 区域托管订阅者服务数据:

  • 美国东部(弗吉尼亚北部)
  • 美国东部(俄亥俄州)
  • 美国西部(俄勒冈)
  • EEA(爱尔兰)
  • EEA(法兰克福)
  • 英国(伦敦)
  • 亚太地区(东京)
  • 亚太地区(大阪)
  • 亚太区域(悉尼)

数据本地化协议

请注意,Zendesk 仅对已购买我们数据中心位置附加功能的订阅者服务数据的托管位置做出承诺 (单独购买数据中心位置附加功能,或数据中心位置附加功能包含在所购买的服务模式中)。请阅读区域数据托管政策在这里 ,了解此承诺的例外情况。

为了平衡需求,提高业绩,并提供最好的服务,我们可能在不预先通知的情况下在地区之间移动帐户数据。  如果帐户已购买数据位置附加功能,我们将确保区域移动保持在所需的国家或法律范围内。

获取托管服务数据的实际地址

根据请求,我们会告知我们托管您的服务数据的 Amazon Web Services (AWS) 区域(AWS 可能描述的国家、国家中地理区域、州和/或城市的统称)。

由于 AWS 的技术运作方式,我们无法提供托管服务数据的确切实际地址。  这取决于 AWS 本身的架构。  AWS 在全球设有“区域”。  这些区域中存在一个概念,即“可用区”或“AZ”。  在 AWS 中创建一项资产时,该资产位于特定区域中的一个或多个可用区。  无论资产所有者选择在区域内还是跨区域复制数据,AWS 本身都可能将该区域内的数据复制到其他可用区。  其结果是,Zendesk 用户服务数据存在于给定区域内的众多设施中。  此外,出于安全原因,AWS 并未正式批准对其数据中心建筑或相关设施特定位置的通信。

如果您想知道您的 Zendesk 子域名托管在哪个 AWS 区域,请联系 Zendesk 客户支持

更改日志:

2024 年 4 月 - 添加了 Zendesk WFM (Tymeshift) 和 Zendesk QA (Klaus) 的警告

2024 年 7 月 - 为旗舰版添加警告

2024 年 7 月 —— 新增两个托管位置:英国(伦敦)、亚太地区(大阪)

 

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年7月02日 编辑 · Craig Lima

5

关注者

1

投票

0

评论


Craig Lima 创建了一篇文章,

文章Zendesk 政策和协议

Zendesk 责任共担模式

Zendesk 为各行各业的许多全球领先公司提供一个高度可配置、可快速扩展的客户服务平台。  通过帮助订阅者利用我们的云平台满足其客户服务需求,他们可以减少管理费用,进行扩展以满足需求,并提供与客户的精美而简单的互动。  

将业务迁移到云端不仅可以带来上述好处,还可以明确谁负责谁控制。  别担心,我们的责任共担模式如下所示。  此框架明确了数据安全和隐私相关控制措施的负责方。  无论您是尽职尽责的管理员、公司安全、合规或隐私专员,还是负责为在您环境中使用 Zendesk 服务的情况设置适当控制措施的其他人员,此标准都应清楚划清界限。 

简而言之,“Zendesk 负责服务本身的安全,而您负责特定服务实例的安全”。 

  1. 访问控制和卫生
  2. 整合
  3. 数据、隐私、合规和法规注意事项
  4. 监测
  5. 维护
  6. 安全事务(用户角色和职责)
  7. 有用的链接
  8. 更改日志

请注意,大写术语应具有 Zendesk 主服务协议(“MSA”)中所述含义。   

I.访问控制和卫生
控制对敏感系统及其数据的访问是安全原则的核心。 

  1. 订阅者负责 对其服务实例的所有访问控制,包括:
    1. 对包括终端用户和专员在内的所有用户(无论是本地、远程还是第三方劳动力)进行配置、修改、持续清理、维护权限准确性以及取消配置 
    2. 从受支持的产品中选择和配置服务的身份验证方法(可能包括密码、MFA、SSO 等)
    3. 配置和监测会话处理的各个方面,例如退出、登录设备等。
    4. 允许或禁止我们的支持员工输入您的 Support 实例以获得帮助
    5. 配置对 Zendesk REST API 服务的访问并了解使用的含义(如适用,包括整合、Zendesk Sunshine 服务的使用等)
    6. 根据需要配置任何产品支持的 IP 限制
    7. 考虑其他与产品无关的访问控制,例如您允许专员在访问您的实例时使用的设备类型,以及对您的用户或允许的设备进行任何适用的物理、逻辑或政策控制。
  2. Zendesk 负责对 支持服务的系统进行所有访问控制,包括:
    1. 维护安全配置、修改、持续清理、维护权限准确性和取消配置所有用户(包括内部部署、远程和第三方劳动力)的政策和程序
    2. 针对所有员工和承包商对包含订阅者服务数据的关键系统和应用程序的访问,执行基于用户角色的访问控制“rbac”、最小权限原则“plp”、适当的凭证安全性,包括多重身份验证“MFA”
    3. 对上述进行定期检查

II.整合 
借助第三方可大幅提高效率,但同时也带来了安全注意事项。

  1. 订阅者有责任 考虑利用其与服务进行的所有第三方整合的安全影响,包括:
    1. 通过 API 和/或 SDK 进行的整合
    2. 通过安装市场应用或启用第三方渠道进行的整合
    3. 通过提供工作人员、工具、代码或直接为 Zendesk 实例提供服务,与任何支持订阅者的第三方进行整合
  2. Zendesk 负责 谨慎将声誉良好的第三方整合到服务中,包括:
    1. 对所有子处理者的审查和持续尽职调查
    2. 以安全的方式将收购整合到服务中
    3. 确保与第三方的任何产品合作伙伴关系和/或服务整合都具有适当的安全注意事项 

三、数据、隐私、合规和法规注意事项
必须考虑正在使用的数据及其适当处理方式,任何相关监管框架,以及第三方鉴证的重要性。

  1. 订阅者有责任 妥善处理其获取和使用的数据,包括:
    1. 了解特定用例中涉及的数据类型
    2. 根据其公司的数据分类和隐私政策、与数据本身、提供数据的用户、订阅者行业以及任何相关司法管辖区相关的适用法律处理此类数据
    3. 选择他们允许与其服务实例通信的渠道
    4. 根据订阅者行业、用户或用例可能在范围内的任何适用的合规、法律或监管框架维护实例和服务数据
    5. 如果需要将主机映射到非 Zendesk 父域名,以加密进出 Zendesk UI 或 API 的流量,则为 Zendesk 提供备用 TLS 证书
    6. 了解哪些数据在传输过程中可能未加密,并相应处理此类渠道或协议(主要是电邮、短信或订阅者自行决定不支持加密的第三方整合)
    7. 确保订阅者实例中涉及的数据类型不违反 Zendesk 主要服务协议(请参阅 Zendesk MSA)的条款和条件
    8. 确保订阅者选择的正常运行时间和灾难恢复级别符合其应遵守的任何政策或法规
  2. Zendesk 负责: 
    1. 在一个服务级别(即基础设施或代码)适当保护所有服务数据免遭泄露 
    2. 加密通过公共网络传入或传出我们的 UI 或 API 的数据传输过程 
    3. 加密所有静态服务数据
    4. 为订阅者提供关于产品内 Cookie 收集的数据以及服务默认使用的信息 
    5. 准确描述我们如何以匿名和非匿名方式使用服务数据(包括个人数据)来提供我们的服务或其他。
    6. 为订阅者提供工具和功能,帮助他们履行适当处理个人或受监管数据的义务。
    7. 遵守与我们提供的服务和营业地点相关的适用法律和监管框架
    8. 获取并提供与我们的服务相关的独立第三方合规保证

四.监测
适当的安全保护需要深入了解流程和活动。  

  1. 订阅者有责任 监测其服务实例中的所有活动,包括:
    1. 监测用户活动(通过 UI 视图或 API 日志)
    2. 对与未知个人的通讯或通过服务获取的不受信任的内容进行尽职调查
    3. 根据任何适用法规维护从服务中提取的日志或数据
  2. Zendesk 负责 监测服务本身的流程和活动,包括:
    1. 生产网络中的特权访问和活动
    2. 需要对新到的流量发出警报,或阻止已知的不良提交或 IP 地址
    3. 服务正常运行时间
    4. 公司或生产网络资产中的异常行为
    5. 代码、基础设施、流量以及相关员工或承包商人员的安全

V.维护
及时更新系统和代码并打上补丁可以避免许多安全问题。 

  1. 订阅者负责对 超出 Zendesk 架构和/或合同范围*的任何系统或代码进行维护和安装补丁,包括:
    1. 其自己的基础设施,包括员工端点、网络、自定义基础设施或第三方中间件,用于在进入 Zendesk 系统之前或离开时用于访问 Zendesk 服务和/或进一步处理其服务数据  
    2. 利用其自己的非标准代码,为 Zendesk 服务提供额外功能,包括订阅者自行开发或购买用于 Zendesk 服务的内部或第三方开发的代码。这也包括 Zendesk 专业服务部应订阅者请求开发的任何自定义代码,前提是作为自定义互动的一部分,此类代码的责任及其维护已移交给订阅者。
  2. Zendesk 负责 在其架构和/或合同范围内,对所有系统和代码进行维护和修复,包括:
    1. 其在托管提供商设施中自己逻辑管理的基础设施,用于提供服务,包括其直接控制下的操作系统、安全基础设施和系统、容器和协作系统等。
    2. 其在 Zendesk 企业环境中使用的自己的物理和/或逻辑托管基础设施,例如员工端点、公司网络基础设施等。
    3. 支持 Zendesk 服务的专有代码库。

* 请注意,虽然市场应用在 Zendesk 架构范围内运行,但它们不在 Zendesk 的标准 Master Services Agreement(主服务协议)范围内,而是受到订阅者和应用开发者之间特定条款的约束(详见我们的市场应用使用条款)。维护市场应用是市场应用的第三方开发者的责任。

六.安全事务
尽管已尽力,有时仍会出错。  如何识别、响应安全事件并从中恢复是成功缓解并保持客户信任的关键。  本节阐述了安全事件中各方的角色和责任。 

  1. 订阅者应对 其特定实例中的任何并非由服务本身的漏洞或事件引起或造成的安全事件或违规负责,包括 
    1. 调查并修复特定实例中由于以下原因造成的任何疑似或实际违规行为:(i) 访问控制或卫生不足(包括使用较弱或可被利用的公共凭证),(2) 对用户活动监测不充分,(3) 未能履行应有义务对因与用户互动而产生的通讯或不可信内容的尽职调查,或 (iv) 因与任何第三方整合而产生的任何事件或违规(该等整合由订阅者自行决定)。
    2. 向政府或执法机构或终端用户发出与由订阅者操作、整合第三方造成的违规相关的任何必要通知,或与从 Zendesk 收到的关于订阅者实例的服务数据违规通知相关的通知
  2. Zendesk 负责 调查安全事件的控制措施,并通过服务本身通知受影响的订阅者发生的服务数据泄露,包括 
    1. 制定书面的安全事件响应政策,并为员工分配相关安全用户角色和职责
    2. 调查异常活动
    3. 包含任何已确认的服务数据泄露
    4. 根据法律要求,通知任何受影响的订阅者或相关政府或执法机构。
    5. 确保强大的备份和灾难恢复流程就位并经过测试

7.有用的链接

使用 Zendesk Security 保护客户服务的安全

Zendesk 安全性最佳实践

Zendesk 法律门户

访问控制和卫生

管理 Zendesk Support 中的安全性和用户访问权限 (链接聚合)

Chat 中的用户角色

Chat 中的用户身份验证

授予 Zendesk 临时访问您帐户的权限

整合

Zendesk API

Zendesk 市场应用

Zendesk 受托处理者

Zendesk Connect 受托处理者

Zendesk 合作伙伴

数据、隐私、合规和法规注意事项

Zendesk 产品内 Cookie 政策

Zendesk 主要服务协议

Zendesk 数据和隐私保护

监测

Support 实例更改审核日志(UI / API

Support 工单活动日志审核日志 API

Chat 面板

在线交谈记录 UI

Chat 增量导出实时 API

Talk 面板

Talk Incremental API

Sunshine 自定义对象、事件和个人资料 API

Sell 实时/Firehose API

 

如有任何其他问题,请联系我们: security@zendesk.com  

八。更改日志
2023 年 6 月 16 日

  1. 添加更改日志
  2. 添加“第 V 部分维护”
  3. 在第 II 节“安全事件”中,澄清了由于订阅者和/或其终端用户使用较弱或可公开利用的凭证所致事件的详情,这是订阅者的责任

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年5月08日 编辑 · Craig Lima

0

关注者

1

投票

0

评论


Craig Lima 创建了一篇文章,

文章Zendesk 政策和协议

我的服务模式是什么?

Suite 所有

要将数据存入云端,需要高度的信任。作为回报,您想知道与之共享此信息的合作伙伴是否将安全视为重中之重。我们的订阅者使用不同的标准和框架来管理敏感信息,因此我们在各项服务中实施了以下国际标准化组织 (ISO) 基准,以确保您的数据安全合规。

ISO 27001 

ISO/IEC 27000 标准提供了一系列框架,以帮助组织制定其数据处理基准。其中最常见的标准“ISO/IEC 27001”规定了对信息安全管理体系 (ISMS) 的要求,并保证组织能够满足要求,从而成功完成审核。

ISO 27018 

ISO/IEC 27018 提供了基于 ISO/IEC 27002 的指南,侧重于保护 Zendesk 等云服务提供商的个人身份信息 (PII)。

ISO 27701 

ISO/IEC 27701:2019 规定了建立、实施、维护和持续改进隐私信息管理系统 (PIMS) 的要求和指南。它是对 ISO/IEC 27001 和 ISO/IEC 27002 的补充,适用于组织内隐私管理。这为数据控制者和数据处理者管理个人数据奠定了框架,协调了安全和隐私控制。

在这些审核范围内的 Zendesk 服务和流程

ISO/IEC 27001:2013、ISO/IEC 27018:2014 和 ISO/IEC 27701:2019 认证的范围仅限于 Zendesk, Inc. 的全球网络基础设施和相应产品和服务,包括开发管理、运营、 Support、Guide、Chat、Connect、Inbox 和 Explore 的维护和交付,这些服务由 Zendesk 总部集中管理,并从以下范围内的办公地点提供支持:加州旧金山和威斯康星州麦迪逊(美利坚合众国)、哥本哈根(丹麦)、都柏林(爱尔兰)、马尼拉(菲律宾)、墨尔本(澳大利亚)、蒙彼利埃(法国)和新加坡。

此外,基础设施即服务 (IaaS) 数据中心提供商用于 保护运行 IaaS 中提供的所有服务的基础设施。 云。Zendesk 用于管理 IaaS 环境的安全控件包含在 本证书范围,但物理和环境控制除外。

我们的托管服务子处理者当前是 AWS,其拥有多项自己的 ISO 认证。如需了解更多信息,请参阅其合规页面 在这里

这对客户意味着什么

在内部,我们进行这些独立审核,以确保我们的安全管理和隐私功能符合领先的行业标准。对于我们的客户,这些经过外部验证的合规标准确认我们在处理您的数据的方式方面履行了对您的义务。此外,ISO/IEC 27701 要求组织声明适用的法律和法规作为其审核标准的一部分,从而使该标准能够满足通用数据保护条例 (GDPR)、加州消费者隐私法案 (CCPA) 和其他法规的要求。更新。

所有使用范围内产品的客户都会受到这种保护

这些认证适用于我们的上述服务。您无需支付任何额外费用,或以任何方式配置您的实例,即可受到它们的保护。

Zendesk 的 ISO 27001、ISO 27018 和 ISO 27701 认证与客户认证

我们的 ISO 27001、ISO 27018 和 ISO 27701 认证涵盖特定 Zendesk 服务范围的安全和隐私管理流程。如果您想获得这些认证,同时使用 Zendesk 运营部分服务,请注意,您不会自动获得关联认证。但是,有了我们的认证,您就可以更轻松地为自己的实例获得这些认证。

获得 Zendesk 的 ISO 认证

您可填写以下表格,随时免费访问我们的 ISO 证书,无需保密:https ://www.zendesk.com/product/zendesk-security/#anchor-security-resources

 

 

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2024年5月08日 编辑 · Craig Lima

3

关注者

1

投票

0

评论


Craig Lima 创建了一篇文章,

文章Zendesk 政策和协议

HIPAA和 HDS 已启用帐户(统称“Healthcare 已启用帐户”):

本文档中使用的所有大写术语应具有 Zendesk Business Associate Agreement(“BAA”)或 Zendesk Master Subscription Agreement(主订阅协议)的 HDS 条款附件(“ HDS 附件”)中给出的含义,适用于帐户类型(统称为“ “Healthcare Agreement”)。

对于已启用HIPAA的帐户,“PHI”指“受保护的健康信息”;对于已启用 HDS 的帐户,“PHI”指“个人健康信息”。

Zendesk 和订阅者已签订“Healthcare Agreement”(医疗保健协议),建议订阅者针对其用例评估并实施以下配置或订阅者评估的替代方案,以满足适用法律下的合规要求。 ( 个)在将任何 PHI 添加到服务中之前。

如果订阅者自行决定选择放弃实施下列任何推荐配置,则订阅者应对因任何原因导致的对订阅者服务数据(包括任何 PHI)的未授权访问或不当使用披露承担全部责任。与订阅者推荐配置的偏差。

订阅者必须购买适当级别的服务模式,并具有所需的关联附加功能(请咨询您的销售代表)。

如果订阅者的帐户已启用 HDS,则必须单击 Zendesk 子处理者政策 上的“关注”按钮,以便接收关于提供服务的子处理者发生任何更改的通知。

应实施以下 Zendesk 服务的最低安全配置,并在任何医疗保健启用帐户的医疗保健协议中予以确认

I.Zendesk Support:

  1. 通过以下两个方法之一进行安全专员身份验证:
    1. 使用 原生Zendesk Support 的密码设置:(i) 设置为“推荐”;或 (i) 由订阅者自定义,其安全性不低于“推荐”设置下的要求。此外,根据本小节中的选项,订阅者还必须在服务中本地启用并强制执行双重身份验证(“2FA”);并且必须禁用允许管理员为终端用户设置密码的管理控制功能;或
    2. 使用外部单点登录(“SSO”)解决方案,且既定要求不低于 Zendesk“推荐”密码设置下既定要求的安全性,并在所选解决方案中对所有专员的访问启用并强制执行双重身份验证。允许管理员为终端用户设置密码的管理控制必须被禁用。
    3. 所有使用 SSO 作为身份验证方法的身份验证选项 应禁用密码访问
  2. 医疗保健启用帐户的安全套接字层(“SSL”)加密必须始终保持启用状态。使用 zendesk.com 以外域名的已启用医疗保健的帐户必须建立并 维护托管 SSL更新。
  3. 如果可能,专员的访问应 限于订阅者控制下的特定 IP 地址。除非订阅者按照上述要求 1.a 或 1.b 为专员启用了多重身份验证(在服务本身中,或在订阅者环境中与企业 SSO 结合使用)。  为免生疑问,“专员访问权限”是指授予人工专员通过用户界面(“UI”)访问服务数据的访问权限。
  4. 如果订阅者的医疗保健帐户已启用调用 Zendesk 应用程序编程接口(以下简称“API”),订阅者应承担所有责任,了解所有被允许创建、访问、修改或删除服务数据和 PHI 通过此类访问和/或整合提供。要访问所述 API,Zendesk 提供了此处所述的各种方法 ,订阅者应根据所使用的 API 模型实施以下安全最佳实践:
    1. OAuth 2.0 方法更新。  此模式提供了最精细的安全功能,但需要终端用户接受授权。  订阅者应尽可能使用 OAuth 2.0 方法和身份验证方案更新。订阅者应为每个OAuth客户端提供一个描述性且唯一的客户端名称和唯一标识符指定功能。为每个OAuth密钥授予的权限应允许完成所需任务所需的最小权限。
    2. REST API 密钥方法更新。  此模型适用面最广,允许一个 API 密钥使用 API 模型的全部功能。就其性质而言,它提供了最广泛的访问和功能,应谨慎使用。在使用此方法时,订阅者应 (i) 对每项服务使用唯一的密钥,并为该密钥指定一个指定功能的描述性名称; (二) 不与任何第三方共享 API 密钥,除非合理需要,且采用端到端加密的传输方法; (三) 确认如果 API 密钥被共享给第三方,并且订阅者应立即轮换相关密钥; (iv) 至少, 根据订阅者的组织政策经常轮换密钥。  
    3. 如果可能,订阅者应禁用对 API 的密码访问,因为这种方法会随每个请求发送用户凭证,这会将用户凭证广泛暴露,使其更容易被恶意方截获。  
  5. 订阅者应启用 “下载需要身份验证”, 以便需要身份验证才能访问附件更新。否则,意味着任何可访问该附件正确 URL 的人都可以对任何无限制附件进行访问。在这种情况下,订阅者应对此类附件数据的内容和访问权限承担所有责任。
  6. 订阅者应在所有专员、管理员和所有者访问的端点上系统地强制执行用密码锁定的屏幕保护或启动屏幕,设置为系统处于非活跃状态最多十五 (15) 分钟。
  7. 订阅者不得更改查看权限(允许用户查看整个实例/品牌/组织的更新),也不得更改允许用户自己的工单或组之外的人员进行访问的默认设置(除非订阅者承担所有责任,确保此类用户得到订阅者批准)。访问所有后续数据)。订阅者确认终端用户组织权限可以在用户个人资料和组织本身中进行设置,如果设置发生冲突, 较宽松的设置会覆盖较宽松的设置
  8. 订阅者确认,在订阅者的Zendesk Support实例接收之前,Zendesk 不负责来自终端用户的电邮及相关服务数据的安全保护。这包括任何可能通过电邮和Zendesk Support工单回复传播的 PHI,包括但不限于工单评论或附件。
  9. 订阅者确认Zendesk Support在各种情况下都会向终端用户发送电邮,例如当订阅者的专员通过电邮渠道回复Zendesk Support工单时,或由自行程序或触发器发起时。默认情况下,此电邮包含最近的工单通信或配置为包含在自动通知中的其他信息,其中可能包含 PHI。要进一步保护订阅者,其Zendesk Support实例应 配置为仅提醒终端用户专员已回复,并需要终端用户对Zendesk Support进行身份验证以查看消息内容。
  10. 订阅者确认其自行决定在任何 Zendesk 服务中使用的任何短信功能均由短信和/或相关协议支持,这可能涉及进出服务的消息未加密传输。  因此,短信功能应:
    1. 未用于医疗保健启用帐户*,或
    2. 如果使用,则订阅者承担此类功能使用的所有责任
  11. 订阅者确认,使用本服务的 旧版客户满意度调查(以下简称“旧版CSAT”) 功能时,通过电邮发送与Support工单相关的服务数据(可能包含 PHI)以便获取用户的评价,其加密状态不受控制。由 Zendesk 提供。因此,旧版CSAT功能应:
    1. 未用于医疗保健启用帐户*,或
    2. 如果使用,则订阅者承担此类功能使用的所有责任
  12. 订阅者确认,对该 服务的客户满意度调查(“CSAT”)功能的使用 对于工单处理渠道,如果未进行相应配置,则会通过电邮发送与Support工单关联的服务数据(可能包含 PHI),以获取用户评价,其加密状态不受 Zendesk 控制。此外,任何具有特定CSAT URL 的人都可访问特定工单的答案。因此,在工单处理渠道中使用CSAT功能时,订阅者应
    1. 将CSAT自行程序电邮正文配置为不包含潜在的 PHI,并使用 {{satisfaction.survey_url}} 占位符,只对
    2. 不使用开放式问题功能

* 为避免疑义,第 10 条中有关短信的 PHI 数据说明不适用于产品内 2FA 使用(如第 1.a 条中所述),因为此类功能仅发送一个数字字符串以进行身份验证。

II.Zendesk Guide和 Gather:

  1. 订阅者确认 Guide 和 Gather 服务本质上是公开的(不利用受限文章 或使用 已关闭或受限的实例),因此订阅者应确保Zendesk Guide或 Gather 服务中的任何文章不包含 PHI,方法是或作为附件或文章中的图像。
  2. 订阅者应 禁用终端用户 在Zendesk Guide中添加评论的功能, 或者应进行审阅并承担从所有评论中移除 PHI 的责任(如下文第 3 部分所述)
  3. 当Zendesk Guide服务为 Guide Professional 或 Enterprise 时,订阅者应尽可能通过使用Zendesk Guide 关闭 Gather 功能 来禁用终端用户创建新帖子的功能, 或者由于订阅者的预期目的而无法关闭 Gather 功能,用例,订阅者应 在Zendesk Guide服务中启用内容审阅,并将其设置为“审阅所有内容”更新。不得批准任何包含 PHI 的提交。
  4. 不允许订阅者在 Gather 服务中使用非员工的“社区维护者”,除非订阅者承担此类用户对数据(包括可能的 PHI(如适用))可能访问的责任。
  5. 订阅者确认可以对 Gather 社区成员进行“@提及”,因为终端用户可以拥有公开个人资料。如果此功能在其用例中被视为风险, 则应关闭公开个人资料禁用 @提及

三、Zendesk 消息传送:

  1. 订阅者不应启用社交媒体消息传送渠道整合,除非其承担全部责任:(i) 确保社交媒体消息中不存在 PHI,或 (ii) 与已整合的消息传送平台签订其自己的BAA 。
  2. 订阅者应禁用终端用户将文件附加到消息传送对话的功能,并对以下任一操作负全部责任:(i) 启用安全附件 (i)确保专员不会将包含 ePHI 的文件附加到消息传送对话中。否则,意味着任何可访问该附件正确 URL 的人都可以对任何无限制附件进行访问。  在这种情况下,订阅者应对此类 URL 和/或附件数据的内容和访问权限承担所有责任。
  3. 订阅者应自行负责,确保所有专员和低权限专员都有权查看来自所有终端用户的所有新到消息。
  4. 如果订阅者或其专员访问或开发 API 和 Webhook 的整合(例如,作为为人工智能专员创建的工作流程的一部分),或自定义消息传送体验,订阅者应全面负责了解所有自定义工作流程对隐私和安全的影响,并订阅者或第三方实体(包括聊天机器人提供商)可通过此类访问和/或整合创建、访问、修改或删除服务数据和 ePHI。
  5. 如果订阅者希望移除专员参与消息传送对话当前处于活跃状态的权限,则订阅者应自行承担所有责任,强制终止该专员对 Zendesk 的访问。
  6. 默认情况下,与终端用户的 Web Widget 对话是永久性的,当终端用户从同一设备返回网络在线交谈时仍可以查看。订阅者应禁用此功能,或承担所有责任,确保终端用户不共享设备。
  7. 如果订阅者希望对终端用户实施身份验证,则订阅者应自行负责根据最佳实践和行业标准以安全的方式实施此操作。
    1. 使用此方法时,订阅者应 (i) 每个身份验证渠道使用唯一的 JWT 签名密钥,并为该密钥指定一个指定功能的描述性名称; (二) 不与任何第三方共享 JWT 签名密钥,除非合理需要,并采用端到端加密的传输方法; (三) 确认如果与第三方共享 JWT 签名密钥,并且订阅者被告知发生第三方数据泄露,则应立即轮换相关的 JWT 签名密钥; (iv) 根据订阅者的组织政策,经常至少轮换 JWT 签名密钥。
    2. 订阅者应使用过期 JWT 属性,并将其值设置为不超过 15 分钟。
  8. 人工智能Webhook,用于在这些对话被存储时提醒订阅者并(自动)通过Sunshine Conversations API 触发删除。 
  9. 订阅者确认,终端用户和人工智能专员之间的对话已 转化 进入工单的 条当前无法标记为密文删除 即可删除工单。 
  10. 订阅者确认 Zendesk 中当前不会扫描消息传送渠道中的终端用户附件是否含有恶意软件。订阅者应全面负责制定适当程序和政策,以减轻其资产风险。 
  11. 订阅者知悉,使用“协作快捷对话”功能可能需要在订阅者的Support实例中创建“子工单”和/或“协作快捷对话”消息,或通过工单、电邮、 Slack或整合将其发送给收件人(由专员自行决定)更新。如果订阅者选择在医疗保健启用帐户中使用此功能,则订阅者承担以下方面的全部责任:(i) 确保此类消息中不存在 PHI,或 (ii) 如果消息中可能包含 PHI,订阅者独自承担责任与因通过“协作快捷对话”功能交换消息而未经授权获取、访问、使用或披露 PHI 相关的任何责任、费用、损害或损害。

四.Zendesk Sunshine Conversations:

  1. 订阅者不应启用第三方渠道整合,除非它承担全部责任,确保 (i) 第三方渠道消息中不存在 PHI,或 (ii) 与已整合的消息传送平台自行签订BAA 。
  2. 订阅者应自行负责理解所有订阅者或第三方实体被允许通过Sunshine Conversations应用程序编程接口(以下简称“API”)创建、访问、修改或删除服务数据和 PHI 的安全含义。要访问所述 API,订阅者应根据所使用的 API 模型实施以下安全最佳实践:
    1. OAuth 2.0 方法更新。  此模式提供了最精细的安全功能,但需要终端用户接受授权。  如有可能,订阅者应使用 OAuth 2.0 方法和身份验证方案更新。订阅者应为每个OAuth客户端提供一个描述性且唯一的客户端名称和唯一标识符指定功能。 
    2. REST API 密钥方法更新。  此模型适用面最广,允许一个 API 密钥使用 API 模型的全部功能。  就其性质而言,它提供了最广泛的访问和功能,应谨慎使用。在使用此方法时,订阅者应 (i) 对每项服务使用唯一的密钥,并为该密钥指定一个指定功能的描述性名称; (二) 不与任何第三方共享 API 密钥,除非合理需要,且采用端到端加密的传输方法; (三) 确认如果 API 密钥被共享给第三方,并且订阅者应立即轮换相关密钥; (iv) 根据订阅者的组织政策经常轮换密钥。  
    3. 如果订阅者或其专员访问或开发 API 和 Webhook 的整合,或自定义Sunshine Conversations体验,订阅者应全面负责了解所有自定义工作流程对隐私和安全的影响,并允许所有订阅者或第三方实体(包括聊天机器人提供商)参与其中。通过此类访问和/或整合创建、访问、修改或删除服务数据和 PHI。
  3. 订阅者确认为Zendesk Support配置的 IP 限制不会延伸到Sunshine Conversations API。订阅者应对限制对Sunshine Conversations API 和 API 密钥的访问负全部责任(如 2.b 中所述)。并符合订阅者的政策。 
  4. 订阅者应禁用终端用户将文件附加到Sunshine Conversations对话的功能,并对 启用安全附件 确保专员不会将包含 PHI 的文件附加到消息传送对话中。否则,意味着任何可访问该附件正确 URL 的人都可以对任何无限制附件进行访问。在这种情况下,订阅者应对此类附件数据的内容和访问权限承担所有责任。
  5. 如果订阅者希望实施终端用户身份验证,则订阅者应自行承担根据安全最佳实践和行业标准可靠实施此实施的所有责任。
    1. 使用此方法时,订阅者应 (i) 每个身份验证渠道使用唯一的 JWT 签名密钥,并为该密钥指定一个指定功能的描述性名称; (二) 不与任何第三方共享 JWT 签名密钥,除非合理需要,并采用端到端加密的传输方法; (三) 确认如果与第三方共享 JWT 签名密钥,并且订阅者被告知发生第三方数据泄露,则应立即轮换相关的 JWT 签名密钥; (iv) 根据订阅者的组织政策,经常至少轮换 JWT 签名密钥。
    2. 订阅者应使用过期 JWT 属性,并将其值设置为不超过 15 分钟。
  6. 订阅者确认终端用户与人工智能专员之间的交互信息,即未移交给人工专员并转入工单的信息仍存储在系统中,订阅者有责任根据其义务删除这些交互信息,例如通过实施 Webhook当这些对话被存储并通过Sunshine Conversations API(自动)触发删除时提醒订阅者 
  7. 订阅者确认,终端用户与人工智能专员之间已转为工单的对话当前无法标记为密文。删除 即可删除工单。 
  8. 订阅者确认通过Sunshine Conversations API 删除的消息仅会从终端用户删除,而不会在 Zendesk专员工作区中删除。这可以通过删除工单或使用标记为密文功能来实现(限制条件请参阅 7.)。 
  9. 订阅者确认 Zendesk 尚未对Sunshine Conversation 渠道中的所有附件进行恶意软件扫描。订阅者应全面负责制定程序和政策,以减轻订阅者员工的风险。 

V.Zendesk Chat:

  1. 订阅者应与Zendesk Support服务联系并通过身份验证,限制专员对Zendesk Chat服务的访问。
  2. 订阅者不应通过电邮发送在线交谈记录副本,(a) 禁用电邮管道, (b) 在Web Widget经典中 禁用电邮在线交谈记录副本选项 ,(c) 请勿 从 Chat 面板通过电邮共享导出
  3. 订阅者承担全部责任,确保 (i) Chats 中不存在 PHI,和/或 (ii) 订阅者允许所有专员查看此类数据。

六.Zendesk Explore服务:

订阅者确认 PHI 可能通过用户名、工单标题、字段和表格选择,以及自由格式文本字段中的任何内容显示在 Explore 产品中。

  1. 对于范围内任何包含 PHI 的服务实例,订阅者应 (i) 仅向可以访问父服务实例中可能包含 PHI 的所有工单/通话/在线交谈的专员授予 Explore 界面的访问权限,并且(二) 应授予此类访问权限,同时考虑到在其环境中使用 Explore 所需的最少权限。有关在 Explore 中配置访问级别的更多信息,请参阅 此处
  2. 在利用“导出”功能时,(i) 订阅者确认 PHI 可能会被传输到订阅者允许访问专员界面的设备,且有责任控制此类设备上的所有专员,且 (II) 订阅者应拒绝的导出功能,除非其承担 (a) 确保此类导出中不包含 PHI 的责任,或 (b) 用于此类传输的电邮服务可通过允许的最小加密协议进行加密根据当时的 PCI 标准。

* 使用 Explore Enterprise 的特别注意事项:

订阅者确认,使用 Explore Enterprise Service 可能需要增加数据共享和导出功能。订阅者应:

  1. (i) 确保此类面板中不存在 PHI,和/或 (ii) 仅与经批准可查看和接收此类数据的专员、组、列表或终端用户共享面板。
  2. 利用 IP 限制
  3. 如通过统一资源定位符 (URL) 共享面板,则订阅者确认应通过访问链接共享数据,而不是与个人或组用户帐户共享数据。因此,订阅者应 (i) 启用密码保护,(iv) 启用密码保护,在怀疑或确认接触时,不得无故延误

7.关于已部署关联服务(以下简称“附加功能”)的产品内功能的通知:

  1. 协作已部署关联服务:“协作快捷对话。”订阅者知悉,使用“协作快捷对话”功能可能需要在订阅者的Support实例中创建“子工单”和/或“协作快捷对话”消息,或通过工单、电邮、 Slack或整合将其发送给收件人(由专员自行决定)更新。如果订阅者选择在医疗保健启用帐户中使用此功能,则订阅者承担以下方面的全部责任:(i) 确保此类消息中不存在 PHI,或 (ii) 如果消息中可能包含 PHI,订阅者独自承担责任与因通过“协作快捷对话”功能交换消息而未经授权获取、访问、使用或披露 PHI 相关的任何责任、费用、损害或损害。

八。Zendesk 移动应用程序(或通过智能手机或平板电脑等移动设备进行的访问):

  1. 使用量应包括设备级加密
  2. 应利用已设置为允许的最高设备设置的生物识别或 PIN 访问
  3. 应禁用允许将工单评论显示到此类设备的锁定屏幕上的通知
  4. 应启用屏幕非活跃状态锁定,并将其配置为在非活跃状态的时间不超过 15 分钟时锁定。
  5. 订阅者确认标记为密文 功能 在Support移动应用程序中不可用,专员需要通过浏览器登录才能使用标记为密文功能。
  6. 如果订阅者选择对 Zendesk 消息传送的终端用户进行身份验证,即表示订阅者确认终端用户的身份验证状态不会显示在Support移动应用中。

IX.Zendesk Insights: 对此服务的支持已于 2021 年 2 月 5 日弃用。   

X:关于 Zendesk人工智能功能(“Zendesk人工智能”、“高级人工智能”、“生成式人工智能”等):

  1. 订阅者确认 Zendesk人工智能功能 旨在提高 Zendesk 服务的工作效率,不应被视为 (i) 提供医疗或保健建议,(ii) 提供身体状况或健康状况的诊断。症状,(3) 开出治疗处方,(iv) 以任何方式阻止用户寻求医疗保健专业人士的建议、诊断或治疗,(v) 或以其他方式向用户提供信息或做出相关决定,任何可能影响其搜索或接收健康服务的医疗保健计划、治疗计划、检测服务或任何其他医疗保健服务(除非订阅者根据其独特用例以及与用户的互动对此决定承担全部责任,以及以及以这种方式使用人工智能的潜在影响)。
  2. 订阅者确认,如果使用任何生成式人工智能功能,则生成的人工智能输出是计算机生成的而不是人工生成的,可能会产生不准确的输出。Zendesk 不保证这些输出的准确性。
  3. 订阅者确认,如果使用 人工智能专员对话智能机器人问候语 向订阅者的终端用户提供所需的免责声明消息,则“生成变量”功能将不会被激活,以确保消息内容的完整性。 
  4. 订阅者确认在管理中心启用增强型撰写功能将对其实例中的所有专员启用此功能,无论其用户角色和权限如何。 

XI.Zendesk 质量保证

  1. 订阅用户确认Zendesk 质量保证人工智能功能旨在提高 Zendesk 服务的工作效率,不应被视为 (i) 提供医疗或保健建议,(ii) 提供健康状况诊断。或症状,(iv) 以任何方式阻止用户寻求医疗保健专业人员的建议、诊断或治疗,(v) 或以其他方式向用户提供信息或做出将其纳入或排除的决定任何可能影响其搜索或获得健康服务的医疗保健计划、治疗计划、检测服务或任何其他医疗保健服务的信息(除非订阅者根据其独特用例以及与用户的互动对此决定承担全部责任,因为以及以这种方式使用人工智能的潜在影响)。
  2. 订阅者确认其 Zendesk 实例中的删除或标记为密文不会立即与Zendesk 质量保证同步,而是会在随后的 3-6 小时内进行。
  3. 在使用调查功能时,订阅者应 (i) 禁用Zendesk 质量保证人工智能协助功能(或确保所有进行质量保证工作的专员都已获得许可,可以查看此类交易中的任何潜在数据,并确保第 1 点原则得到实施)( ii) 确保对调查进行配置,以免在调查问题或描述中透露 PHI(或对通过机会性 StartTLS 发送的电邮中此类数据负责)
  4. 在使用“Zendesk Chat”自定义整合时,订阅者应考虑设置一个与订阅者政策一致的数据保留期,以确保数据不是无限期保留的。
  5. 订阅者确认,当使用Sunshine Conversations API 删除部分 Zendesk 消息传送对话时,此更改不会反映在Zendesk 质量保证中。相反,应通过标记为密文从原始工单中移除信息,或移除整个对话。
  6. 订阅者确认Zendesk 质量保证目前不支持 Zendesk 的“私密附件”功能。这意味着任何能访问附件正确 URL 的人均可访问附件,但不应包含敏感数据(包括 PHI)。订阅者应对此类 URL 和/或附件数据的内容和访问权限承担所有责任。
  7. 订阅者确认,根据Zendesk 质量保证的初始规定,高级连接配置仅在首次同步后可用。

XII.Zendesk 劳动力管理“劳动力管理”:

  1. 订阅者确认
    1. 默认劳动力管理管理员用户角色可访问所有适用于劳动力管理服务的专员活动和设置(包括以下第 2 点中提到的标签)。
    2. 默认专员用户角色可访问专员活动,除非管理员通过创建自定义用户角色将其配置为具有不同访问权限 (如此处所述)
  2. 订阅者确认由专员、管理员或Support中的工单逻辑预定义的系统逻辑应用的标签在劳动力管理产品中对任何被允许查看此类工单活动的用户可见。如果工单标签被订阅者视为敏感,则应适当配置访问权限。

免责声明:由于法律法规的更改,或者 Zendesk 服务的更改,本文档中的安全配置可能会不时更改。本文档包含 Zendesk 目前关于在上述 Zendesk 产品中保护 PHI 的最低有效安全配置的建议。本文档既不构成对此类数据进行所有控制的详尽模板,也不构成法律建议。每个 Zendesk 订阅者应自行寻求关于其HIPAA或 HDS 合规要求的法律顾问,并应根据每个订阅者自己的独立分析对其安全配置进行额外更改,只要此类更改不会抵消或降低 Zendesk 的安全性。本文档中概述的配置。

 


更改日志:

2025 年 1 月 24 日

  • 合并的HIPAA和 HDS 配置

2024 年 12 月 27 日

  • 添加了第 XII 部分,以将Zendesk 劳动力管理(“劳动力管理”)纳入范围

2024 年 12 月 16 日

  • 添加了第 XI 部分,以将Zendesk 质量保证纳入范围
  • 已将“Answer Bot”的多个实例更改为“人工智能专员”,以表示命名约定的更改并缩小范围。

2024 年 10 月 10 日

  • 添加了第 I 部分,Support,第 12 号 (CSAT),并编辑了第 I 部分,Support,第 11 号(旧版CSAT),以适应新功能。 

2024 年 3 月 7 日

  • 添加了 X 节,关于 Zendesk人工智能功能的通知
  • 第 I 部分,Support,第 7 号(查看权限):
    • 澄清了“查看权限”适用于整个“实例/品牌/组织”,而不仅仅是“组织”。
    • 添加了一项针对终端用户特定组织行为的新规定。 
  • 第 I 部分,Support,编号 9(电邮):  
    • 扩展了Zendesk Support向终端用户发送电邮的情况,涵盖通过电邮渠道发送的回复,以及由自行程序或触发器发起的回复,而不仅仅是专员回复工单的回复。
    • 已指定默认情况下自动通知可包含最近的工单通信或其他已配置信息,其中可能包括 PHI。

2023 年 10 月 25 日

  • 简介:澄清了已启用HIPAA 的帐户的介绍语言
  • 第 II 部分 Guide 和 Gather,第 1 号(帮助中心限制):将 IP 限制替换为受限文章以进行澄清

2023 年 4 月 13 日

  • 第 I 部分, Support,第 4 号(API): 
    • 为清楚起见,已添加到身份验证方法的链接 
    • b) 移除了轮换的确切时间范围建议,以与行业最佳实践保持一致,并移除了对 REST API 服务条款的引用(多余
    • 添加了 c) 以针对 API 使用基本身份验证发出警告 
  • 第 II 部分, 指南:
    • 第 1 项(帮助中心限制):添加了对关闭或受限帮助中心的引用,以与产品功能保持一致
    • 第 5 条(@提及):添加了禁用 @提及功能以与产品保持一致的选项 功能 
  • 第 II 部分,消息传送: 
    • Number 1 和 2(第三方渠道和私密附件):为清晰起见,已添加组别 标识符 (i) 和 (II)
    • Number 2(私密附件):已添加“URL 和/或”以进行说明
    • 数字 7-10(终端用户身份验证、Answerbot 对话删除、标记为密文、恶意软件扫描):添加了完整的组别,以提高透明度
  • 第四部分, Sunshine Conversations :由于Zendesk Suite中的Sunshine Conversations已成为BAA的一部分,因此添加了整个部分 
  • 第 V 部分,Chat,number 3(专员工作区):少量措辞更正
  • 第 8 部分,移动应用程序,第 5-7 部分(恶意软件扫描、标记为密文、终端用户身份验证):已添加整个部分,以提高透明度

2023 年 2 月 24 日

  • 第一部分Support,第 3 项:移除了Support和 Chat IP 限制之间单独的区别,因为 UI 现已统一。
  • 第 I 部分Support,第 5 号:添加了关于未能满足要求的说明 
  • 第 I 部分Support,第 7 号:“订阅者不得”更改为“订阅者不应”。
  • 第四部分:Chat,第 2 条:明确禁止一切使用电邮从 Chat 导出数据的功能,且不仅限于记录副本和管道处理。 
  • 第 3 部分:消息传送:整个部分都添加到了帐户中,除了 Zendesk Business Associate Agreement(业务伙伴协议)的范围之外,还有 Zendesk 消息传送功能。

2021 年 7 月 9 日

  • 在关于专员工作区使用的责任的 Chat 部分添加了第 3 点。

2021 年 1 月 21 日

  • 添加数字 1.11 禁用CSAT,除非订阅者对调查中通过电邮发送的数据负责。 
  • 第 1.7 条注意事项允许订阅者更改查看权限,因为用户在其终端已获批准访问此类数据。
  • 已更新整个文档,以匹配文本中嵌入链接的公司 样式 ,而不是内嵌 URL(不影响配置内容)。

2020 年 8 月

  • 新增 Explore Enterprise,从而增加面板共享功能
  • 移除了对 Chat 附件的禁止( 现在包括Support身份验证要求)
  • 说明禁止在自定义字段中使用 ePHI 专门针对 Insights 使用情况而非全局
  • 在已部署服务的附加功能中添加了新组别,首次添加了“协作快捷对话”
  • 各种语法/格式编辑(与内容无关)

2020 年 7 月 13 日:

  • 对于通过服务使用短信(而不是原生使用短信进行产品内 2FA),已进行了明确说明。 *为避免疑义,第 10 条中有关短信的 ePHI 相关数据说明不适用于产品内 2FA 使用(如第 1.a 条中所述),因为此类功能仅发送一个数字字符串以进行身份验证。

2019 年 12 月 13 日 

  • 允许放弃专员 IP 限制,而用例不允许这种限制,只要对专员访问强制执行 MFA。

2019 年 12 月 17 日 

  • 允许终端用户在 Guide 中添加评论,前提是专员审阅此类评论并移除所有 PHI。

2019 年 11 月 6 日

  • 文章已更新,以反映订阅者可自行决定放弃或替换任何特定配置,前提是他们对此决定负责。

“订阅者未能实施并遵守下列任何特定配置,或下列任何系列所需的配置,应

订阅者自行承担风险并自行决定;且 Zendesk 及其员工、专员和关联公司不承担由于订阅者的此类故障而导致的对订户服务数据(包括任何电子版的“受保护的健康信息”)的未授权访问或不当使用或披露的任何责任。更新。 "

  • 其他更改包括
    • 1. 能够使用短信,只要订阅者承担所有责任以确保此类传输中不存在 PHI。
    • 2.只要订阅者自行负责确保此类附件中不存在 PHI,即可在 Chat 中使用附件。

2019 年 3 月 6 日 

  • 已更新并添加Zendesk Explore设置

2019 年 1 月 17 日

  •  已更新以禁用 Chat 中的附件。

翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性

如对翻译准确性有任何疑问,请以文章的英语版本为准。

已于 2025年1月28日 编辑 · Craig Lima

0

关注者

1

投票

0

评论


Craig Lima 进行了评论,

评论Zendesk policies and agreements

July 9th 2021 edit:

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

查看评论 · 已于 2021年7月09日 发布 · Craig Lima

0

关注者

0

投票

0

评论


Craig Lima 进行了评论,

评论Zendesk policies and agreements

January 21st, 2021

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

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

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

查看评论 · 已于 2021年1月21日 发布 · Craig Lima

0

关注者

0

投票

0

评论