安全域：数据处理安全和隐私
此安全域旨在确保从 Microsoft 365 使用的任何数据在传输和静态中都受到充分保护。 此域还确保 ISV 根据 GDPR (一般数据保护条例) 和 HIPAA (1996) 的健康保险可移植性和责任法案，确保 ISV 满足消费者 (数据主体) 隐私问题。
传输中的数据
Microsoft 365 开发的应用/加载项的连接要求需要通过公用网络（特别是 Internet）进行通信。 因此，传输中的数据必须受到适当的保护。 本部分介绍通过 Internet 保护数据通信。
控制编号 1
请提供以下所有项的证据：
验证 TLS 配置是否为 TLS1.2 或更高版本。
将保留和维护受信任的密钥和证书的清单。
意向：TLS
此子点旨在确保安全传输组织使用的 Microsoft 365 数据。 TLS 配置文件配置用于定义 TLS 特定要求，以帮助确保流量受到中间人攻击的安全。
指南：TLS
证明这一点的最简单方法是针对所有 Web 侦听器（包括在非标准端口上运行的任何侦听器）运行 Qualys SSL 服务器测试 工具。
请记得勾选“不要在板上显示结果”选项，这会阻止将 URL 添加到网站。
可以通过提供单个检查的证据来演示 TLS 配置文件配置要求。 若要提供特定设置（例如禁用 TLS 压缩）的证据，可以使用配置设置、脚本和软件工具。
示例证据：TLS
以下屏幕截图显示了 Qualys 针对 webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net 的 SSL 扫描结果。
协议部分显示 TLS1.2 是唯一支持/启用的协议。
注意：认证分析师将检查扫描的完整输出，以确认满足 TLS 配置文件配置要求的所有要求。 预期将为公开的所有终结点提供扫描，这些终结点 (IP 地址和 URL) 在范围内的后端环境。 根据提供的证据，分析师可能会进行自己的Qualys扫描。
示例证据：TLS
以下屏幕截图显示了 Azure 应用服务中 TLS 的配置设置，后跟通过 PowerShell 进行的 TLS 枚举。
意向：密钥和证书
此子点的目的是确保维护受信任的密钥和证书的综合清单，涉及识别依赖于这些加密元素的各种系统、服务和应用程序。
指南：密钥和证书
证据必须证明存在并维护受信任的密钥和证书的清单。 此外，可以提供用于存储实际密钥和证书的工具的适用证据，例如 Azure 密钥保管库、HashiCorp 保管库机密、Confluence Cloud 等。
示例证据：密钥和证书
以下屏幕截图显示密钥和证书清单在 Confluence Cloud 中维护。
以下屏幕截图显示了已批准的受信任密钥和证书列表。 它包括证书、密钥、密码和安装它们的系统等详细信息。
以下屏幕截图来自 HashiCorp 保管库。 清单列表中概述和记录的证书将存储在此联机保管库中。 HashiCorp Vault 是用于机密管理、加密即服务以及特权访问管理的开源工具。
以下屏幕截图是联机保管库中存储的实际证书和密钥的摘录。
注意：预期密钥的存储位置具有适当的访问控制。 如果私钥泄露，则有人可能会使用合法证书欺骗服务器。
示例证据：密钥和证书
还可以使用 Microsoft 365 Defender 维护受信任密钥和证书的清单，它提供清单功能，如下一张屏幕截图所示。
下一个屏幕截图显示了证书的详细信息。
请注意：这些示例不是全屏屏幕截图，你将需要使用任何 URL、登录用户以及时间和日期戳提交全屏屏幕截图，以便进行证据审查。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
控制编号 2
请提供以下所有项的证据：
显示对处理 Web 请求的所有面向公众的服务禁用 TLS 压缩，以防止犯罪 (压缩比率信息泄漏使) 变得容易。
验证是否在所有站点中启用 TLS HSTS 并将其配置为 180 天。
意向：TLS
(CVE-2012-4929) ) 攻击的 CRIME (压缩比信息泄漏变得容易，是压缩安全套接字层 (SSL) /传输层安全性 (TLS) 协议中的漏洞。 因此，行业建议禁用 SSL 压缩。
HTTP 严格传输安全 (HSTS) 是一种安全机制，旨在通过名为“Strict-Transport-Security”的 HTTPS 响应标头字段强制 TLS 连接来保护网站免受中间人攻击。
指南：TLS
这可以通过 Qualys SSL 实验室工具证明。 示例证据：TLS
以下屏幕截图显示 SSL/TLS 压缩已禁用。
下一个屏幕截图显示已启用 HSTS。
注意：认证分析师将查看完整输出，以确认满足 TLS 配置文件配置要求的所有要求 (请提供完整扫描输出) 的屏幕截图。 根据提供的证据，分析师可能会进行自己的Qualys扫描。
可用于检查 HSTS 是否已启用的其他工具包括“HTTP 标头 Spy”和
securityheaders.com，如以下示例所示。 其他证据
可以提供安全标头的配置设置（特别是 HSTS）等屏幕截图，以进一步演示公共占用空间的安全状况。
接下来的屏幕截图显示了 Azure Front Door 配置以及为重写标头而实现的规则集。
下一个屏幕截图显示了执行的安全标头扫描以及所有安全标头都已实现，而不仅仅是 HSTS。
注意：如果使用 Qualys SSL 扫描程序或安全标头，则预期会提供完整的报告以供审阅。
静态数据
当 ISV 存储从 Microsoft 365 平台使用的数据时，需要适当保护数据。 本部分介绍数据库和文件存储中存储的数据的保护要求。
控制措施 3
使用 AES、Blowfish、TDES 等加密算法以及 128 位和 256 位的加密密钥大小，提供可证明的证据，证明静态数据已按照加密配置文件要求进行加密。
意向：
已知一些较旧的加密算法包含一些加密弱点，这增加了威胁参与者在不知道密钥的情况下解密数据的可能性。 因此，此控制的目的是确保仅使用行业接受的加密算法来保护存储的 M365 数据。
指南：
可以通过屏幕截图提供证据，其中显示了用于保护数据库和其他存储位置中的 M365 数据的加密。 证据应证明加密配置符合 Microsoft 365 认证的 加密配置文件配置要求 。
示例证据：
下一个屏幕截图显示在 Contoso 数据库上启用了 TDE (透明数据加密) 。 第二个屏幕截图显示了Microsoft文档页 ，其中显示了 SQL 数据库、SQL 托管实例和 Azure Synapse Analytics 的透明数据加密 ，其中显示了 AES 256 加密用于 Azure TDE。
请注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
示例证据：
以下屏幕截图显示了为 Blob 和文件配置了加密的 Azure 存储。 下一个屏幕截图显示了静态 数据的 azure 存储加密 Microsoft文档页，其中显示了 Azure 存储使用 AES-256 进行加密。
数据保留、备份和处置
如果 ISV 使用并存储Microsoft 365 数据，则如果威胁参与者破坏 ISV 环境，则存在数据泄露的风险。 为了最大程度地降低这种风险，组织应仅保留提供服务所需的数据，而不应保留将来“可能”使用的数据。 此外，数据应仅保留一段时间，前提是需要提供捕获数据所针对的服务。 应定义数据保留并与用户通信。 一旦数据超过定义的保留期，则必须安全地删除此保留期，以便无法重新构造或恢复数据。
控制措施 4
请提供已正式确定并记录已批准的数据保留期的证据。
意向：
记录和遵循的保留策略不仅对于履行某些法律义务（例如，数据隐私立法）非常重要，例如（但不限于）欧盟 GDPR) (一般数据保护条例和英国 DPA 2018 (数据保护法) ，还限制组织风险。 通过了解组织的数据要求以及企业执行其职能所需的数据时长，组织可以确保在数据有用性过期后正确处理数据。 通过减少存储的数据量，组织可以减少发生数据泄露时公开的数据量。 这将限制整体影响。
通常，组织会存储数据，因为最好只是以防万一。 但是，如果组织不需要数据来执行其服务或业务功能，则不应存储数据，因为这样会不必要地增加组织的风险。
此控制的目的是确认组织已为所有相关类型的数据正式建立并记录了已批准的数据保留期。 这不仅涉及指定存储不同类型的数据的持续时间，还涉及概述数据删除或过期后存档的过程。
指南：
提供完整的数据保留策略，其中明确详细说明数据 (必须涵盖所有数据类型) 应保留多长时间，以便业务能够执行其业务功能。
示例证据：
下一个屏幕截图显示了 Contoso 的数据保留策略。
注意：这些屏幕截图显示了策略/流程文档的快照。 期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
控制措施 5
演示数据仅在定义的保留期内保留，如控制 4 中所述。
意向：
此控件的意图只是验证是否满足定义的数据保留期。 如前所述，组织可能有法律义务来达到此要求，但也需要保留数据，并在必要时保留数据，以帮助降低发生数据泄露时对组织的风险。 这可确保数据既不会保留太长时间，也不会过早删除，这两者都可能带来不同性质的风险（法律、操作或安全相关）。
指南：
(或通过屏幕共享) 提供屏幕截图证据，显示存储在所有不同数据位置（例如数据库、文件共享、存档等）中存储的数据 (，) 不超过定义的数据保留策略。 示例可以是以下屏幕截图：
具有日期字段的数据库记录（按最早的记录顺序搜索）和/或
显示保留期内时间戳的文件存储位置 注意：应在屏幕截图中修订任何个人/敏感的客户数据。
示例证据：
以下证据显示了一个 SQL 查询，该查询显示数据库表的内容在“DATE_TRANSACTION”字段中按升序排序，以显示数据库中最早的记录。 这表明数据小于两个月，不会超过定义的保留期。
注意：这是一个测试数据库，因此其中没有大量历史数据。
注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
控制措施 6
演示了在数据保留期后安全删除数据的过程。
意向：
此控件的目的是确保用于删除超过保留期的数据的机制是安全的。 有时可以恢复已删除的数据;因此，删除过程需要足够可靠，以确保数据在删除后无法恢复。
指南：
如果删除过程以编程方式完成，请提供用于执行此操作的脚本的屏幕截图。 如果按计划执行，请提供显示计划的屏幕截图。 例如，用于删除文件共享中的文件的脚本可以配置为 CRON 作业，显示计划和执行的脚本的 CRON 作业的屏幕截图;并提供显示所用命令的脚本。
示例证据：
这是一个简单的脚本，可用于删除基于日期 -WHERE DateAdd 为 -30 天保留的所有数据记录，这将清除超过所选数据保留日期 30 天的所有保留记录。 请注意，我们需要脚本：运行作业和结果的证据。
请注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
示例证据：
以下屏幕截图取自控制 4) 的 Contoso 数据保留策略 (– 此屏幕截图显示了用于数据销毁的过程。
注意：此屏幕截图显示了策略/流程文档的快照。 期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
示例证据：
在此示例中，已在 Azure 中创建 Runbook 和相应的计划，以安全地删除自数据记录保留策略到期后的 30 天内创建的结束日期的记录。 此作业设置为每月在每月最后一天运行。
下一个屏幕截图显示，Runbook 已编辑以查找记录，并且删除命令不在视图中，如脚本。
注意：必须查看这些屏幕截图的完整 URL 和用户名，并且 ISV 需要显示删除前记录计数的屏幕截图和删除后记录计数的屏幕截图。
这些屏幕截图纯粹是可以采用的不同方法的示例。
控制措施 7
请提供证据，证明：
自动备份系统已到位，并配置为在计划时间执行备份。
备份信息根据备份计划过程进行测试，并定期还原，以确认数据的可靠性和完整性。
实施适当的访问控制和保护机制 (即不可变备份) ，以确保备份/系统快照受到保护，防止未经授权的访问，并确保备份数据的机密性、完整性和可用性。
意向：
此控制的目的是确认组织是否具有自动备份系统，该系统配置为在预定的时间执行备份。
指南：
请提供备份解决方案中的配置设置的屏幕截图，显示正在按计划的时间段/时间间隔执行备份。 如果备份计划由解决方案自动完成，则可以通过提供供应商文档来支持这一点。
示例证据：
以下屏幕截图适用于 Azure Database for MySQL，这是一个托管实例。 它指示已完成第一个自动备份。
下一张屏幕截图是在经过一段时间后拍摄的，显示已完成进一步的完整备份。 灵活服务器上的备份基于快照，在创建服务器后立即计划第一个快照备份，并且每天执行一次进一步的快照备份。
下一个屏幕截图显示了联机文档的快照，其中概述了备份频率和自动备份功能。
意向：
此控制的目的是证明备份信息不仅按计划生成，而且是可靠的，并随着时间的推移保持其完整性。 为了实现此目标，将对备份数据执行定期测试。
指南：
满足此控制的证据将取决于组织的备份数据测试过程和过程。 可以提供证据，显示成功测试备份以及历史测试完成记录。
示例证据：
以下屏幕截图显示存在并维护备份计划和还原过程，并且为所有适用的系统定义了备份配置，包括 Confluence 平台中执行备份的频率。
下一个屏幕截图显示了每个适用系统的备份测试历史记录页。 请注意，在表右侧，每个测试都引用了 JIRA 票证。
接下来的四个屏幕截图显示了从快照还原 Azure Database for MySQL 的端到端过程。 使用“快速还原”选项，我们可以启动 SQL 数据库的还原过程。
以下屏幕截图显示了可在其中自定义还原的配置页。
选择要从中还原数据库的目标位置、网络和快照后，我们可以启动部署。 观察数据库实例现在称为“test”。
总共五分钟后，SQL 数据库已成功从备份快照中完全还原，如下所示。
测试完成后，根据创建 JIRA 票证的过程，记录备份测试和所执行还原的详细信息。 这可确保历史数据可用于符合性目的，并且存在完整的记录以供在发生事件或灾难时进行评审，使组织能够执行根本原因分析。
意向：
从前面的控件开始，应实现访问控制，以仅对负责备份数据的单个用户进行访问。 通过限制访问，可以限制执行未经授权的更改的风险，从而引入不安全的更改。 应采取最低特权方法来保护备份。
若要正确保护数据，组织需要了解其环境/系统消耗的数据以及数据存储的位置。 一旦完全理解和记录了这一点。
然后，组织不仅能够实施适当的数据保护，而且还能够合并数据所在的位置，以便更有效地实施保护。 此外，将数据合并到尽可能少的位置时，实现足够的 RBAC (基于角色的访问控制) 以根据需要限制对尽可能少的员工的访问要容易得多。
指南：
应从系统/技术提供证据，证明对备份和备份解决方案的访问权限，以及已批准访问列表的支持文档。
示例证据：
在以下屏幕截图中可以看到，访问控制是在数据库实例上实现的，以基于作业角色限制仅对授权人员的访问权限。
示例证据：
Azure SQL 数据库和 Azure SQL 托管实例的自动备份由 Azure 管理，其完整性是 Azure 平台的责任：用户无权访问它们，并且它们是静态加密的，不可能受到勒索软件攻击。 它们也会复制到其他区域进行保护。
数据访问管理
数据访问需要限制为所需的人数，以减少数据被恶意或意外泄露的可能性。 对数据和加密密钥的访问应限制为具有合法业务需要的用户才能完成其工作角色。 应实施一个记录良好且完善的访问请求流程。 对数据和加密密钥的访问应遵循最低特权原则。
控制措施 8
提供证据来证明有权访问数据和/或加密密钥的个人列表：
维护，包括每个人的业务理由。
已根据其工作职能所需的访问权限获得正式批准。
使用审批中概述的权限进行配置。
意向：
组织应将数据和加密密钥的访问限制为尽可能少的员工。 此控制的目的是确保员工对数据和/或加密密钥的访问仅限于具有明确业务需要的员工进行上述访问。
指南：
内部系统的文档或屏幕截图，其中记录了有权访问数据和/或加密密钥的所有员工，以及应为这些员工提供访问权限的业务理由。 认证分析师将使用此列表对下一个控件的用户进行采样。
示例证据：
以下文档显示了具有数据访问权限的用户的记录列表和业务理由。
注意：此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档。
意向：
授予对数据和/或加密密钥的访问权限的过程需要包括批准，以确保其工作职能需要个人的访问权限。 这可确保没有真正访问理由的员工不会获得不必要的访问权限。
指南：
通常，为上一个控件提供的证据可以帮助支持此控件。 如果未对提供的文档进行正式批准，则证据可能包括在 Azure DevOps 或 Jira 等工具中提出和批准访问的更改请求。
示例证据：
此组图像显示为控制 (i) 创建和批准的 Jira 票证，以授予或拒绝对敏感数据和/或加密密钥的访问权限。 此图像演示了在 Jira 中创建一个请求，以在系统后端环境中获得 Sam Daily 加密密钥的批准。 这是作为获得书面授权的下一步完成的。
这表明，授予 Sam Daily 访问权限的请求已由 Jon Smith 从管理层批准。 (请注意，审批必须来自有权允许更改请求的人员，不能是其他开发人员) 。
上一个演示了 Jira 中此过程的工作流。 请注意，除非已完成审批过程，否则不能将任何内容添加为“完成”，因为审批过程是自动化的，因此无法绕过。
项目板现在显示，已批准 Sam Daily 访问加密密钥。 以下积压工作显示了 Sam Daily 的请求审批以及分配了执行该工作的人员。
为了满足此控件的要求，必须显示所有这些屏幕截图或类似/等效证据，并说明你已满足控制要求。
请注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
示例证据：
在下一个示例中，已为用户请求了对生产数据库的管理员访问权限和完全控制权限。 请求已发送以供审批，如图像右侧所示，且已批准，如左侧所示。
下一个图像指示已批准访问权限，并已按操作进行签名。
请注意：在前面的示例中，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
Intent
此子点的意图是确认数据和/或加密密钥访问已按照文档所述进行配置。
指南：
可以通过屏幕截图提供证据，其中显示了授予采样个人的数据和/或加密密钥访问权限。 证据必须涵盖所有数据位置。
示例证据：
此屏幕截图显示授予用户“John Smith”的权限，该权限是交叉的
根据上一个控件的证据，针对此同一用户的审批请求引用。
请注意：以下示例不是全屏屏幕截图，你需要提交全屏屏幕截图，其中包含任何 URL、登录用户以及用于证据审查的时间和日期戳。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
控制编号 9
提供证据，证明：
维护与共享数据的所有第三方的列表。
与使用数据的所有第三方签订了数据共享协议。
意向：
当第三方用于存储或处理Microsoft 365 数据时，这些实体可能会带来重大风险。 组织应制定良好的第三方尽职调查和管理流程，以确保这些第三方安全地存储/处理数据，并确保它们将履行任何可能承担的法律义务，例如，作为 GDPR 规定的数据处理者。
组织应维护与以下部分或全部共享数据的所有第三方的列表：
) 提供哪些服务 () (
共享的数据
共享数据的原因
关键联系信息 (，即主要联系人、违规通知联系人、DPO 等 )
合同续订/到期
法律/合规性义务 (，即 GDPR、HIPAA、PCI DSS、FedRAMP 等 )
指南：
提供文档，详细说明共享Microsoft 365 数据的所有第三方。
注意：如果未使用第三方，则需要由高级领导团队成员以书面形式确认 (电子邮件) 。
示例证据：
请注意： - 在前面的示例中未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
示例证据：
以下屏幕截图显示了高级领导团队成员的电子邮件示例，其中确认没有第三方用于处理Microsoft 365 数据。
请注意： - 在这些示例中未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的完整屏幕截图。
意向：
如果 M365 数据与第三方共享，请务必正确安全地处理数据。 数据共享协议必须到位，以确保第三方仅根据需要处理数据，并了解其安全义务。 组织安全性仅与最薄弱的环节一样强大。 此控制的目的是确保第三方不会成为组织的薄弱环节。
指南：
提供与第三方签订的数据共享协议。
示例证据：
下一个屏幕截图显示了数据共享协议的简单示例。
注意：应共享完整协议，而不是屏幕截图。
隐私
隐私合规性和信息管理对于保护个人权利并确保负责任的数据处理至关重要。 组织若要建立有效的隐私信息系统，他们需要了解自己持有的个人数据以及处理和存储此类数据的目的。 组织应映射信息流及其处理方式，并认识到可能会发生多种不同类型的处理。
控制编号 10
你的组织是否拥有隐私信息管理 (PIM) 系统建立、实施和维护：
通过策略或其他形式的文档/计算机化系统来保持领导承诺，了解如何维护隐私信息管理工作以实现系统机密性和完整性。
确定维护系统的每个人（包括 PII 处理器和控制器）的角色、职责和权限。
意向：
这一点的目的是确保存在“隐私文化”，并通过有效的隐私治理计划得到组织领导层的支持。 组织的管理层必须通过其既定的文档和流程来证明存在有效的隐私管理系统，这些流程符合组织的战略目标，并在组织的上下文和情况中建立，并确保隐私管理系统嵌入业务流程中。
指南：
提供组织的既定文档，概述了隐私信息管理 (PIM) 策略和程序，就证明了这一点。 认证分析师将对此进行审查，以确保控制范围内提供的所有信息都得到解决。
示例证据：
以下屏幕截图显示了 PIM 策略的快照。
请注意：期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
Intent
责任是数据保护法中的关键原则之一，因为它使组织能够通过实施适当而有效的策略、程序和流程，最大程度地降低与其处理个人数据相关的风险。 这些措施必须与风险成正比，风险可能因处理或传输的数据量、其敏感度和使用技术而异。 为此，每个员工必须知道谁负责隐私管理系统的各个要素，以确保成功实施。 通过以明确定义的方式概述角色、职责和权限的既定文档，并适当分配这些角色，组织可以确保其隐私管理系统有效。
指南：
通过提供组织的既定文档来证明这一点，其中概述了每个相关人员的角色、职责和权限。 认证分析师将对此进行审查，以确保控制范围内提供的所有信息都得到解决。
示例证据：
接下来的屏幕截图显示了 PIM 策略的快照，其中显示了包含已批准员工列表的策略部分。
请注意：期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
控制编号 11
提供过程证据，以证明：
PII 最小化正在进行中。
PII 去标识和删除是在处理期结束时完成的。
PII 传输的控制措施已到位，包括任何机密性。
在表示同意的情况下，存在从一个国家/地区转移到另一个国家/地区的 PII 记录。
意向：PII
PII (个人身份信息) 最小化的目的是确保组织仅收集、使用和保留在组织上下文和业务理由内实现特定目的所需的最小个人数据量。 处理个人数据时，组织必须确定实现该目标/任务所需的最少数据量，并确保存储的数据不超过所需的最低数据量。 通过尽量减少不必要的个人数据的处理和存储，组织可确保降低与数据滥用、未经授权的访问和数据泄露相关的风险级别。
准则：PII
如果通过自动化平台或手动管理过程完成，则可以通过用于最大程度地减少个人信息使用的解决方案的配置设置来提供证据，然后应将最小化过程的证据和所发生过程记录的证据提供给分析员审查。
示例证据：PII
以下屏幕截图显示，安排了一次重复的每月会议，其中将审查组织内在该时间段内收到的所有新数据，并在适用的情况下删除认为不必要的任何个人信息。
在下一个屏幕截图中，是一个已填写的用户注册表单示例，用于在平台中加入新客户。
后续屏幕截图显示，根据 PII 最小化会议和评审，认为不再需要表单中收集的某些敏感信息来向用户提供服务。 在下一个图像中，已删除裁判的 PII，以及电子邮件地址 (预期是每个组织都有保留或删除该信息的业务理由) 。
请注意：上一个是一个潜在方案的示例。 它绝不是全面的，在提供证据时，应明确演示最小化 PII 的过程，并应用于组织的特定上下文。
意向：数据隐私
此子点的意图是多方面的，涵盖多种技术和不同的概念，但总体目标是通过确保整个组织的数据隐私得到增强，使组织符合数据保护法规。
从去标识（即删除可用于从数据中识别个人的特定信息）开始，目的是确保任何被视为敏感的信息（如电子邮件地址、出生日期等）通过各种技术（如假名化或屏蔽) ）更改/转换 (，使其无法直接链接到个人。 此过程的目的不仅在于保留数据的效用，还旨在确保降低与数据滥用、未经授权的访问和数据泄露相关的风险级别。
组织应在处理期结束时定义数据保留并删除不必要的数据。 数据超过定义的数据保留期后，必须安全地删除它，以确保无法重新构造或恢复数据。 在发生数据泄露时，根据需要保留数据有助于降低组织的风险。 这可确保数据既不会保留太长时间，也不会过早删除，这两者都可能带来不同性质的风险（法律、操作或安全相关）。
准则：数据隐私
可以通过配置机制和/或技术来提供证据，该机制和/或技术用于确保根据控制要求匿名和删除 PII 数据。
示例证据：数据隐私
下一个屏幕截图中显示的示例使用 Azure 数据工厂的内置数据匿名化模板，该模板是模板库的一部分，它允许我们在匿名其内容的同时，将一组文本文件从一个位置移动到另一个位置。 它表明 Azure 中存在用于 PII 匿名化的数据工厂。
下一个屏幕截图显示了 PII 匿名化管道的配置。 它利用在 Azure 应用服务上使用 Presidio 的代码，将 Presidio 作为 Azure 数据工厂管道中的 HTTP REST 终结点调用，同时将每个文件分析和存储为 Azure Blob 存储。
以下屏幕截图显示了管道步骤和逻辑。
最终屏幕截图演示了成功运行管道以匿名化 PII。
请注意：上一个是一个潜在方案的示例。 它绝不是全面的，在提供证据时，匿名 PII 的过程应明确展示，并应适用于组织的特定背景。
示例证据：数据隐私
以下屏幕截图演示了一个示例，该示例通过为保存 PII 的 Azure 中的存储帐户启用生命周期管理策略来解决在处理期结束时删除 PII 的问题。
下一个屏幕截图演示了为预定义时间段设置的保留期，在此时间段后会自动删除数据。
请注意：上一个是一个潜在方案的示例。 它绝不是全面的，在提供证据时，删除 PII 数据的过程和适用的特定保留期应明确展示，并应用于组织的特定上下文。
示例证据：数据隐私
最终屏幕截图演示了数据生命周期管理保留策略，用于跨组织内的各个位置（如 SharePoint、OneDrive、设备、邮箱等）传输和存储 PII 数据。此策略是使用 Microsoft Purview 启用的。 保留策略配置为在预定义的保留期过后自动删除任何 PII。
请注意：上一个是一个潜在方案的示例。 它绝不是全面的，在提供证据时，删除 PII 数据的过程和适用的特定保留期应明确展示，并应用于组织的特定上下文。
意向：控件
此子点的目的是确保组织在处理和传输过程中具有适当的技术和管理/操作安全措施来保护 PII。 强调机密性是指通过技术和管理控制措施（例如静态和传输中的数据加密、记录的访问控制列表和定期审核）来保护数据免受未经授权的访问和泄露。
指南：控件
可以通过保护机制的配置设置来提供证据，这些机制用于确保 PII 数据符合控制要求进行保护。 此类机制可能包括访问控制、RBAC、加密、数据丢失防护等。
免责声明：提供的示例演示了一些可能的情况，其中应用了控件以确保 PII 受到保护。 请注意，保护机制的类型取决于组织的上下文以及 PII 的使用、存储方式等。
示例证据：加密
以下示例演示在存储 PII 的存储位置对 PII 进行加密，以及在传输过程中通过 Web 应用程序/平台进行加密，用户可在其中输入存储在应用程序后端中的个人信息。
屏幕截图演示了存储位置的静态数据默认加密。
请注意，如果默认使用的平台和你自己的加密未执行加密
密钥正在使用中，那么预期是这些密钥已得到充分保护，并提供证据来证明这一点。
第二张屏幕截图显示，在传输过程中为收集 PII 的应用程序强制实施 TLS1.2。
示例证据：访问控制
以下屏幕截图从网络角度来看，仅允许授权/批准的 IP 范围（即安全公司网络）访问 PII 存储位置。
下一个屏幕截图显示了 Azure PIM 的示例，以及具有合格分配的用户列表。 通过使用实时 (JIT) 访问，它允许用户在有限的时间内获得对特权角色或资源的临时访问权限，从而降低特权用户被入侵的风险，或者对环境、数据位置等进行更改的风险。
示例证据：PII 传输和泄露防护
这些屏幕截图显示Microsoft Purview 数据丢失防护 (DLP) ，这是一个集成平台，允许组织从单个集中位置管理其 DLP 策略。
可在下面看到已启用“英国 PII 数据”策略。 这样可以防止用户在通过受支持的 Web 浏览器访问时向特定网站提供敏感数据，包括个人电子邮件、生成 AI 提示、社交媒体网站等。 这可确保随着所有工作场所设备/用户都应用组织策略，降低员工的潜在机密性违规或未经授权披露 PII 的风险。
下一个屏幕截图 () 提供了策略的全面概述，包括策略的应用范围。 策略设置为 SharePoint、设备、OneDrive 等位置中的所有帐户。
上一张和下面的屏幕截图显示 DLP 策略设置为防止用户复制和粘贴敏感信息，例如个人身份信息 (PII)
从组织的内部数据库到支持浏览器上的个人电子邮件帐户、聊天机器人和社交媒体网站。
意向：记录
此子点的意图是双重的：它确保有效的记录管理到位，以促进数据管理和数据保护，同时确保法律合规性和问责制，因为在不同国家/地区传输个人身份信息涉及导航不同的法律要求。 ) (在启动 PII 传输之前，组织必须确保其获得数据主体 (其所属) 的明确同意。 获取的同意记录将验证传输的授权。 传输 () 记录还应包含传输、风险评估、数据保护影响和保留期的其他详细信息。
指南：记录
可以为 PII 传输记录和表示同意的记录提供的证据将取决于如何在组织级别实施传输过程和记录管理。 这可以包括同意是通过平台、服务的条款和条件，还是通过每个用户填写的同意形式获得。 提供的证据必须表明，存在一段时间内完成的转移的历史记录、跟踪方式，以及获得明确同意的记录。
示例证据：记录
下一个屏幕截图显示了组织服务用户之一填写的同意表单的示例。 我们可以看到，用户提供了对条件的明确同意、确认和理解。
以下屏幕截图显示存在 PII 传输的历史记录，并包括正在交换的特定 PII 数据、传输目的、来源国家/地区、目标国家/地区、传输中的数据保护、审批等详细信息。
请注意：上一个是一个潜在方案的示例，它绝不是全面的，在提供证据时，应清楚地演示传输 PII 数据、记录管理等的过程，并应用于组织的特定上下文。
GDPR
大多数组织都将处理可能是欧洲公民 (数据主体) 数据的数据。 在处理任何数据主体的数据时，组织将需要满足 GDPR) (一般数据保护条例。 这适用于数据控制者 (你直接捕获上述数据) 或数据处理者， (你代表数据控制器) 处理这些数据。 虽然本节不涵盖整个法规，但它涉及 GDPR 的一些关键要素，以帮助获得组织认真对待 GDPR 的一些保证。
控制编号 12
提供证明：
数据主体能够提高 SAR。
验证 (ISV) 在响应 SAR 请求时是否能够识别数据主体数据的所有位置。
备份有一个保留期，允许删除请求通过 SA 删除数据的客户端，因为删除一段时间内的滚动备份 (最早的备份删除/重写) 的生命周期。
意向：
GDPR 包括处理数据主体数据的组织必须履行的特定义务。 第12条中包括组织 (SCR) 管理主体访问请求的义务，该条款第12.3条规定，数据控制者在收到特区后一个月对请求作出回应。 如有必要，仅当有理由这样做时，才允许再延长两个月。 即使组织充当数据处理者，仍需要这样做来帮助客户 (数据控制者) 履行其 SAR 义务。
指南：
请提供记录的用于处理 SAR 的过程。 示例证据：
以下示例演示了用于处理 SAR 的记录过程。
注意：此屏幕截图显示了策略/流程文档，ISV 希望共享实际的支持策略/过程文档。
意向：
此控制的目的是确保组织有一个可靠的机制来识别所有数据主体的数据。 这可能是一个手动过程，因为所有数据存储都记录良好，或者可以使用其他工具来确保所有数据都作为 SAR 过程的一部分进行定位。
指南：
可以通过提供所有数据位置的列表和记录过程来提供证据，以搜索所有数据位置以获取数据。 这将包括搜索数据所需的任何命令，即，如果包含 SQL 位置，则会详细说明特定的 SQL 语句，以确保正确找到数据。
示例证据：
下一张屏幕截图是上一个 SAR 过程的代码片段，其中显示了如何查找数据。
下面的四个图像显示了如何查询 ISV 数据位置，并使用存储资源管理器向下钻取到需要从存储中删除以符合 SAR 请求的文件或 Blob。
注意：这些示例不是全屏屏幕截图，你需要提交全屏屏幕截图，其中包含任何 URL、登录用户以及用于证据审查的时间和日期戳。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
此查询确认正在使用的存储帐户。 可以使用 Resource Graph Explorer (Kusto) 或 PowerShell 查询和删除存储、Blob 和/或文件， (请参阅下一个) 。
请注意： - 对于本部分中的示例，未使用完整屏幕截图，但所有 ISV 提交的证据屏幕截图必须是显示 URL、任何登录用户和系统时间和日期的全屏屏幕截图。
下图显示了在客户端的 Blob 容器中找到的数据，这些数据需要删除，下面显示了删除或软删除 blob 中信息的操作。
请注意：示例不是全屏屏幕截图，你需要提交全屏屏幕截图，其中包含任何 URL、登录用户以及用于证据审查的时间和日期戳。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
意向：
此控件的目的是证明备份存在正式保留期，其设计方式适用于根据 SAR 删除数据。 保留框架应允许在定义的时间段内逐步淘汰旧备份，确保最终从所有备份中删除由于 SAR 而删除的任何数据。 这对于使组织的备份和数据保留做法与 SAR 产生的义务保持一致，从而满足有关擦除权的法规要求至关重要。
指南：
可以通过显示备份配置设置的屏幕截图来提供证据，该设置演示了执行备份的时间段和方法。 重点应放在备份频率周期上。
示例证据：
以下屏幕截图是 Azure Database for MySQL（托管实例）中的配置设置的代码片段。
在屏幕截图中可以看到，备份保留期设置为 28 天。
根据备份部分，我们知道灵活服务器上的备份是基于快照的，创建服务器后立即计划第一个快照备份，并且每天执行一次进一步的快照备份。
28 天的备份保留期与备份频率相结合意味着，当满足 SAR 时，滚动备份将持续最多 27 天，并按保留期强制实施减少，直到删除所有这些用户数据。
控制措施 13
请提供隐私声明，其中应包含所有必需的元素，如下所示：
实体详细信息 (名称、地址等 )
正在处理的个人数据类型的详细信息。
详细说明个人数据将保留多长时间。
处理个人数据的合法性的详细信息。
数据主体权利的详细信息：
知情权
数据主体的访问权限
擦除权限
限制处理的权利
数据可移植性权限
对象权限
与自动决策相关的权利，包括分析
意向：
GDPR 第 13 条包括获取个人数据时必须提供给数据主体的特定信息。 此控制的目的是确保组织数据隐私声明向数据主体提供第 13 条中包含的一些关键信息。
指南：
这通常通过提供数据隐私声明来提供。 认证分析师将对此进行审查，以确保在控制范围内提供的所有信息都包含在数据隐私声明中。
示例证据：
接下来的屏幕截图显示了隐私策略的快照。
请注意：这些示例不是全屏屏幕截图，你将需要使用任何 URL、登录用户以及时间和日期戳提交全屏屏幕截图，以便进行证据审查。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
隐私声明的图像显示了包含 GDPR 第 13 条的在线隐私策略示例。
以下是可与前面显示的隐私声明结合使用的数据保护策略。
上一张 Azure 图像显示了如何配置 Azure 以满足 GDPR 对存储在后端环境中的数据的符合性要求。 可以自定义或构建的 Azure 蓝图) 策略 (允许 ISV 确保正确存储客户端数据，并且只能由指定的指标访问。 此外，警报设置为确保合规性，并将在合规性管理器仪表板上显示不合规的数据或用户访问权限。
请注意：前面的示例不是全屏屏幕截图，你需要提交全屏屏幕截图，其中包含任何 URL、登录用户以及用于证据审查的时间和日期戳。 如果你是 Linux 用户，可以通过命令提示符完成此操作。
HIPAA (健康保险可移植性和责任法案)
1996年《健康保险可移植性和责任法案》 (HIPAA) 是一项适用于美国公民和医疗保健组织的联邦立法。 值得注意的是，这项立法还涵盖美国境外处理美国公民医疗数据的任何组织。 这项立法的出台授权美国卫生和公众服务部部长 (HHS) 制定保护某些健康信息的隐私和安全法规。 某些组织可能会处理可能受保护的健康信息 (ePHI) ，这意味着通过电子媒体传输、在电子媒体中维护或以任何其他形式或媒体传输或维护的个人身份健康信息。 在处理任何数据主体的运行状况数据时，组织需要满足 HIPAA 要求。
HIPAA 有两项立法需要考虑：“隐私规则”或“个人身份健康信息隐私标准”，其中概述了保护某些健康信息的国家标准，以及“保护电子保护健康信息的安全标准”，也称为“安全规则”。 后者建立了一套国家安全标准，以保护以电子形式持有或传输的某些健康信息。
从高级概述中，“安全规则”是“隐私规则”所提供的保护的实际实现。 它概述了“被涵盖实体”必须实施的技术和非技术措施，以确保个人“电子保护健康信息” (电子PHI) 的安全。 虽然本节不涵盖整个法规，但它涉及 HIPAA 的一些关键要素，以帮助获得一些保证，即组织符合要求，并且组织正在保护其处理的运行状况信息。
控制编号 14
请提供可证明的证据，证明：
组织中针对员工、承包商等的 HIPAA 和 HIPAA 处理存在策略。
ISV 确保其创建、接收、维护或传输的 ePHI 的机密性、完整性和可用性。
防范对 ePHI 安全性或完整性的任何合理预期威胁和危害。
意向：
此子点的意图是确保组织已建立协议，作为管理健康信息、处理紧急情况和服务中断以及员工访问健康信息和培训的标准程序。 此外，组织应维护和概述这些管理安全措施，作为其 HIPAA 安全计划的一部分。 这是遵守 HIPAA 法规的一个重要方面。
指南：
提供该组织的既定文件，概述 HIPAA 政策和程序，就证明了这一点。 认证分析师将对此进行审查，以确保控制范围内提供的所有信息都得到解决。
示例证据：
屏幕截图显示了 HIPAA 策略的快照。 请注意：期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
注意：ISV 期望共享实际的综合支持策略/过程文档，而不只是提供屏幕截图。
意向：
为了了解此子点的意图并确保符合安全规则，“涵盖的实体”必须首先知道在 § 164.304 下如何定义保密性、完整性和可用性条款：
保密性：“未向未经授权的人员或进程提供或披露数据或信息的属性。
完整性：“未以未经授权的方式更改或销毁数据或信息的属性。
可用性：“授权人员可按需访问和使用数据或信息的属性。
此要求的意图是组织在 IT 基础结构中实施技术安全措施/措施，例如访问、审核、完整性和传输控制，以确保 ePHI 机密性，同时保持其完整性和对授权用户的可用性。
指南：
可以通过保护机制的配置设置来提供证据，这些机制用于确保 ePHI 数据符合控制要求的安全。 此类机制可能包括访问控制、紧急访问过程、RBAC、加密等。
示例证据：访问和完整性控制
下一个屏幕截图显示，有权处理 ePHI 存储位置的个人的授权访问列表存在，并在 HIPAA 策略文档中维护。 此外，在批准的清单列表后面的屏幕截图中，可以看到，整个群集的写入访问权限有限，只有管理员和数据库维护分析师能够在群集上读取和写入。
从 Atlas Mongo 中的一个 ePHI 存储数据库拍摄的下一个屏幕截图显示，只有授权用户才具有记录的访问权限，并且所有帐户都具有唯一的用户 ID 以确保责任。
第一个屏幕截图显示了 ePHI 的主存储位置/数据库群集。
第二张屏幕截图演示已批准的用户仅记录了角色和访问权限。
接下来的两个屏幕截图显示分配的每个角色以及与上述访问审批一致的所有关联权限的更精细视图。
每个自定义角色都有一组权限和访问范围。
最后，下一张屏幕截图从网络角度来看，仅允许授权的 IP 范围（即安全公司网络）访问群集。
示例证据：审核控制
这些屏幕截图显示了为数据库群集实现日志记录和警报。 第一个屏幕截图显示已启用警报。 请注意，预期提供的证据还会显示根据组织的需求/实现设置的警报规则。 第二个屏幕截图显示正在启用数据库审核。
下一个屏幕截图显示正在记录的数据库群集的访问历史记录。 预期是基于审核日志设置警报，任何不符合预定义条件的未经授权的访问都会触发警报。
最后两个屏幕截图显示为数据库群集生成了审核日志，并且可以导出日志进行分析。
请注意，预期需要有一个流程来分析生成的审核日志，还必须提供评审过程的证据。 如果以编程方式实现，则必须提供日志引入到所用平台/日志记录解决方案的配置设置的屏幕截图，以及规则的屏幕截图以供查看。
示例证据：加密和传输控制
接下来的屏幕截图演示了存储位置的静态数据默认加密。 请注意，如果默认使用的平台未执行加密，并且自己的加密密钥正在使用中，则预期这些密钥已得到充分保护，并提供证据来证明这一点。
接下来的两个屏幕截图演示了存储位置的传输中的数据默认加密。 第一个屏幕截图演示了数据 API 已启用“读取和写入”权限。
终结点的 SSL 扫描表明传输中的数据是通过 TLS 1.2 加密的。
示例证据：可用性和恢复控制
下一个屏幕截图演示了跨三个区域复制数据库群集以确保可用性。 默认情况下，此操作由 Mongo Atlas 完成。 此外，备份已启用并且处于活动状态。
以下屏幕截图显示了群集的备份仪表板，其中还演示了已创建快照。
接下来的两个屏幕截图演示了备份策略，可以在不同的时间点执行计划备份， (PIT) 。
下面指示快照和时间点还原 (PIT) 都有保留策略。
意向：
此子点的意图与安全规则一致，该规则旨在确保灵活性和可伸缩性，以便“涵盖的实体”可以实施适合实体规模、组织结构及其特定风险以及风险偏好的策略、过程和技术解决方案。 从实际角度来看，这意味着实施的适当安全措施将取决于“所涵盖实体”业务的性质及其规模和资源。
对于每个组织来说，必须进行全面的风险分析，以发现 e-PHI 的机密性、完整性和可用性的潜在风险和漏洞。 然后，通过此风险分析，组织可以实施适当的安全控制来缓解这些已识别的风险。
指南：
可以通过风险分析输出提供证据。 如果通过联机平台执行和维护风险分析，则应提供整个输出的屏幕截图。
示例证据：
接下来的屏幕截图显示风险评估过程的快照，然后是执行的风险分析，以确定控制措施正确实现的程度，并按预期方式运行以保护 ePHI。 第二张屏幕截图显示了风险评估中确定的风险的风险分析，以及为降低风险级别而实施的补偿控制和缓解措施。
示例 1 - HIPAA 策略中风险评估过程的快照，以及执行的风险分析
注意：此屏幕截图显示了风险分析文档的快照，这只是一个示例，ISV 希望共享实际文档，而不只是提供屏幕截图。
示例 2 - HIPAA 策略中的风险评估过程的屏幕截图，以及执行的风险分析 (在 Confluence Cloud Platform 中维护)
第二张屏幕截图显示了风险评估中确定的风险的风险分析，以及为降低风险级别而实施的补偿控制和缓解措施。 可以看到，这在 Confluence 云平台中存在并得到维护。
控制编号 15
请提供 (ISV) 的证据：
防止隐私规则不允许的此类信息的合理预期使用或披露;和
确保员工遵守安全规则。
164.308 下的数据备份和灾难恢复计划 () (7) (ii) (A) 和 164.308 () (7) (ii) (B) 。
Intent
隐私规则定义了法律涵盖哪些受保护健康信息 (PHI) ，并禁止对 PHI 的不当使用和披露。 此子点的意图是，组织必须将电子 PHI 的访问和使用限制为仅那些出于授权目的需要电子 PHI 的人员，并且他们必须遵守必要的最低规则，该规则要求他们仅使用或披露实现其预期目的所需的最小电子 PHI 量。
必须结合技术措施和行政保障措施来限制 ePHI 的使用，并确保降低 ePHI 的披露风险。
指南：
提供的证据需要显示技术安全措施，例如用于保护电子 PHI 的技术和机制，以及组织控制如何检查此类数据的访问和移动。
示例证据：
接下来的屏幕截图显示Microsoft Purview 数据丢失防护 (DLP) ，这是一个集成平台，允许组织从单个集中位置管理其 DLP 策略。
在下面可以看到，启用了“U.S. HIPAA 增强”策略，这可以防止用户在通过受支持的 Web 浏览器访问时将敏感数据粘贴到特定网站，包括个人电子邮件、生成 AI 提示、社交媒体网站等。
下一个屏幕截图提供了策略的更全面概述，包括应用策略的范围。 策略设置为 SharePoint、设备、OneDrive 等位置中的所有帐户。
选择“编辑策略”选项时，将显示特定可用配置的更精细视图。
接下来的两个屏幕截图显示了应用策略必须满足的内容定义和条件。
该策略涵盖各种敏感数据类型以及一组分类器。
下一部分显示配置为在满足上述屏幕截图中显示的条件时执行的操作。
以下屏幕截图显示 DLP 策略设置为阻止其用户将敏感信息（例如个人身份信息 (PII) ）从组织内部数据库复制和粘贴到其个人电子邮件帐户、聊天机器人和受支持的浏览器上的社交媒体网站。
最后，将用户通知配置为在用户处理 ePHI 数据时通知用户并为其提供指导。
以下屏幕截图显示了用于在事件发生时生成警报的配置面板。
意向：
此子点的意图是组织必须培训其员工如何安全、适当地处理电子 PHI，并且必须强制实施策略和过程以确保符合安全规则。
指南：
提供的证据需要证明 HIPAA 培训是关于如何处理 ePHI 的，并且存在出勤和训练完成记录。 在适用的情况下，可使用策略文档和培训材料支持此功能。
示例证据：
以下示例演示了可以提交的潜在证据，以证明根据策略进行适当的 HIPAA 训练。
下一张屏幕截图显示了 HIPAA 策略的快照，其中包含一个概述训练要求的特定部分。 请注意，这只是一个示例，而不是一个全面的文档/实现，预期 ISV 将具有适用于其组织的既定流程。
示例 1 - 通过管理过程进行 HIPAA 用户培训
在下一个屏幕截图中，课程概述幻灯片显示了课程目标的摘要。 如果培训是内部构建的，则必须提供培训材料以供审阅，请注意，必须提交完整的材料，而不仅仅是摘要的屏幕截图。
以下屏幕截图显示了参与培训的员工的出勤记录。 该记录还显示及格分数以及下一个训练计划日期。
第二个示例演示了如何使用 Microsoft 365 Defender 来设置和启动训练活动。
示例 2 - 通过 Microsoft 365 Defender 攻击模拟平台 (所有用户) 的 HIPAA 用户培训
上一张屏幕截图显示了 HIPAA 安全培训活动、总持续时间（分钟）以及完成状态。 下一张屏幕截图概述了已向其分配培训的用户，以及显示成功完成的训练状态。
示例 3 - 通过 Microsoft 365 Defender 攻击模拟平台 (单个用户) 进行 HIPAA 用户培训
虽然上一个示例侧重于演示所有用户已完成年度培训活动，但最后一个示例显示有针对性的证据，证明一名员工已完成。
在前面的两个屏幕截图中可以看到，一旦启动培训活动，每个员工都会收到一封电子邮件，确认培训分配和截止日期，以及分配的模块、持续时间等。
使用电子邮件通知中提供的链接，以下屏幕截图显示了用户的“培训分配”页和两个现已完成的模块。
意向：
根据 HIPAA 安全规则，数据备份计划和灾难恢复计划对于处理电子受保护健康信息 (ePHI) 的任何“涵盖实体”是必需的。 此类计划是应急策略的一部分，旨在确保在发生紧急情况或其他损坏包含 ePHI 的系统的情况时，ePHI 的可用性和安全性。
数据备份计划的意图是创建和维护 ePHI 的可检索的相同副本，这还应包括定期测试备份，以确保可以恢复数据。 灾难恢复计划的意图是在发生灾难时还原任何可能丢失的数据，这应指定还原对数据的访问权限所必须执行的步骤，包括应如何从备份还原文件。
指南：
请提供灾难恢复计划/过程的完整版本，其中应涵盖备份计划和恢复计划。 如果处于数字版本，请提供实际的 PDF/Word 文档，或者，如果此过程是通过联机平台进行维护的，请提供 PDF 导出，或者如果由于平台限制而无法导出，请提供涵盖整个策略的屏幕截图。
示例证据：
下一张屏幕截图显示了 HIPAA 安全策略的快照，其中包含常规和高级备份过程以及灾难恢复计划的概述。
注意：此屏幕截图显示了策略/流程文档的快照，这只是一个示例，ISV 希望共享实际的综合性支持策略/过程文档，而不只是提供屏幕截图。
书籍
Murdoch D. (2018) Blue Team 手册：事件响应版本：网络安全事件响应响应者的精简现场指南。 第 2 版，发布者：CreateSpace Independent Publishing Platform。
参考
行动欺诈网络犯罪报告提供于： https://www.actionfraud.police.uk/ (访问时间：2023 年 12 月 10 日) 。
欧盟。 (2021) 适用于数据控制器的 GDPR 清单，请参阅： https://gdpr.eu/checklist/ (访问时间：2023 年 12 月 10 日) 。
Microsoft. (2018) 事件日志记录 (Windows Installer) 的可用位置： 事件日志记录 (访问时间：03/05/2024) 。
积极技术。 (2020) 如何实现安全软件开发，请参阅： https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/ (访问：2023 年 12 月 10 日) 。
) 2016 年 4 月 27 日欧洲议会和欧盟理事会第 2016/679 号欧盟第 2016/679 号条例 (条例，关于在处理个人数据和此类数据自由移动方面保护自然人，以及废除指令 95/46/EC (2016 年 2016 年 4 月 27 日与欧洲经济区相关的一般数据保护条例) () (文本) ，请参阅： https://www.legislation.gov.uk/eur/2016/679/contents (访问时间：2023/12/10) 。
安全指标。 (2020) PCI DSS 合规性安全指标指南。 发布时间： https://info.securitymetrics.com/pci-guide-2020 (访问时间：2023 年 12 月 10 日) 。
Williams J. OWASP 风险排名在： https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (访问： 12/10/2023) .
夸利斯 (2014) SSL 实验室：信任 (T) 的新级别和不匹配 (M) 问题，网址为： https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-不匹配问题 (访问时间：2023 年 12 月 10 日) 。
NIST SP800-61r2：计算机安全事件处理指南，请参阅： https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (访问时间：2023 年 12 月 10 日) 。
Google Cloud (访问时间：10/10/2023) 。
灾难恢复计划位于： https://www.sans.org/white-papers/1164/ (访问时间：2023 年 10 月 10 日) 。
https://github.com/ 访问 (：10/10/23) 。
安全策略模板位于： https://www.sans.org/information-security-policy/ (访问时间：10/10/23) 。
https://www.openedr.com/ (访问时间：02/10/23) 。
https://www.atlassian.com/software/confluence 访问 (：10/10/23) 。
https://www.atlassian.com/software/jira (访问时间：28/09/23) 。
业务连续性计划 (BCP) 表顶部练习模板，位于： https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (访问时间：10/10/23) 。
HIPAA 安全规则 | HHS.gov (摘要 ：18/10/2023) 。
数字时代的健康信息隐私法：HIPAA 不适用 - PMC (nih.gov) (访问：2023 年 10 月 18 日) 。
HIPAA 的用途是什么？ Update 2023 (hipaajournal.com) 访问 (：18/10/2023) 。
什么被视为 HIPAA 下的 PHI？ 2023 更新 (hipaajournal.com) 访问 (：18/10/2023) 。
HIPAA 策略和过程 (hipaajournal.com) 访问 (：18/10/2023) 。
设计 HIPAA 策略 & 管理策略 |已访问短划线解决方案 (dashsdk.com) (：18/10/2023) 。
/ 法律信息研究所 (cornell.edu) 访问 (：18/10/2023) 。
什么是 HIPAA 合规性？ HIPAA 法律 & 规则 |Proofpoint UK 访问 (：18/10/2023) 。
HIPAA 安全规则、法规和标准 (training-hipaa.net) 访问 (：18/10/2023) 。
HIPAA 安全规则 | HHS.gov (摘要 ：18/10/2023) 。
SP 800-66 Rev. 1，关于实施健康保险可移植性和责任法案的介绍性资源指南 (HIPAA) 安全规则 |中国证监会 (nist.gov) (访问时间：2023/10/18) 。
安全规则 | HHS.gov 访问 (：18/10/2023) 。
https://www.hipaajournal.com/hipaa-encryption-requirements (访问时间：19/10/2023) 。
https://www.hipaajournal.com/hipaa-privacy-rule/ (访问时间：19/10/2023) 。
https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (访问时间：19/10/2023) 。
https://www.restore.co.uk/Records/Services/Magnetic-Tape-Storage (访问时间：19/10/2023) 。
https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (访问时间： 19/10/2023) 。
配置加密 — MongoDB 手动 (访问时间：19/10/2023) 。
https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (访问时间：19/10/2023) 。
Microsoft Community Hub (访问时间：24/10/2023) 。
|美国法律 |LII / 法律信息研究所> (cornell.edu) (访问时间：24/10/2023) 。
https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (访问时间：2023/10/24) 。
我们应何时提供隐私信息？ |ICO 访问 (：08/11/2023) 。
我们应该如何起草隐私信息？ |ICO 访问 (：08/11/2023) 。
问责框架 |ICO (访问时间：08/11/2023) 。
ISO 27001 要求 5.1 - 领导 & 承诺 | ISMS.online (访问：08/11/2023) 。
联机浏览平台 (OBP) (iso.org) 访问 (：08/11/2023) 。
条款 5.3 组织角色、职责和授权 - ISO 培训 (访问：08/11/2023) 。
5.3 角色、责任和权限 (iso9001help.co.uk) (访问：08/11/2023) 。
原则 (c) ：数据最小化 |ICO (访问时间：08/11/2023) 。
使用敏感数据保护在大规模数据集中取消标识和重新标识 PII|云体系结构中心 |Google Cloud (访问时间：08/11/2023) 。
取消识别敏感数据 |敏感数据保护文档 |Google Cloud (访问时间：08/11/2023) 。
数据安全指南 |ICO (访问时间：08/11/2023) 。
国际数据传输 |ICO (访问时间：08/11/2023) 。
记录管理和安全性 |ICO (访问时间：08/11/2023) 。
ISO 27701 - 隐私信息管理 (访问时间：08/11/2023) 。
ISO 27701 隐私信息管理系统 (PIMS) | ISMS.Online (访问时间：08/11/2023) 。
从Microsoft文档拍摄的图像/文本
https://www.sans.org/information-security-policy/ (访问时间：) 21/02/18。
获取行为分析和异常检测 (访问：03/05/24) 。
什么是 Azure Monitor 警报？ (访问时间：03/05/24) 。
(访问时间：03/05/24) 。
管理和响应 Microsoft Defender for Cloud 中的安全警报 (访问：03/05/24) 。
管理和响应 Microsoft Defender for Cloud 中的安全警报 (访问：03/05/24) 。
https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (访问时间：09/10/23) 。
SQL 数据库、SQL 托管实例和 Azure Synapse Analytics 的透明数据加密 (访问时间：03/05/24) 。
快速入门：创建策略分配以识别不合规的资源 (访问：03/05/24) 。
为 Azure SQL 数据库配置高级威胁防护 (访问时间：03/05/24) 。
Azure Database for MySQL 灵活服务器中的备份和还原 (访问时间：03/05/24) 。
证书清单 (已访问：03/05/24) 。
Azure Database for MySQL 中的备份和还原 (访问时间：03/05/24) 。
https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (访问：08/11/2023) 。