此安全域旨在确保从 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分析”，其中显示了 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 号 - 个人数据
提供证据，证明你的组织：
) 维护收集、处理和存储的所有个人数据的最新清单，包括每个数据元素的用途。
B) 将数据收集表单设计为仅包含业务目的所需的字段，并适当地实现必需字段和可选字段。
C) 制定并强制实施策略，以指定可收集的个人数据的类型及其使用目的。
D) 允许用户选择退出处理或广泛呈现其个人非业务基本数据。
意向：
此控件的意图是确保遵守与数据收集相关的数据隐私，确保捕获数据有理由，并且对收集数据的内容和原因保持透明。 同样重要的是， (数据主体的用户) 能够选择退出处理。
指南：
此控制措施可以证明如下：
) 提供组织的“处理活动记录” (RoPA) 的当前版本， (请参阅 GDPR 第 30 条) 或类似文档，其中详细介绍了数据元素，以及处理 ( () 的用途，请参阅 GDPR 第 5.1.b 条) 。
在大多数情况下，这将是可从 OneTrust) 等工具中提取的 Excel 电子表格 (。
如果文件太大或包含敏感数据，则可以提供摘录，其中显示了给定数据样本的所有数据字段，只要证据可以保证 RoPA 已到位，就可以部分编辑这些数据字段。
不符合：记录不存在、非常陈旧/过时或缺少关键字段。
B) 为了“数据最小化” (请参阅 GDPR 第 5.1.c 条) ，请提供用于获取数据的所有表单，无论是在线还是使用平板电脑或类似设备 (，例如在会议) 或论文中。 这些可以是空白/模板。
不符合：表单具有不必要的必填字段，这些字段对于预期的处理目的而言是不必要的。 例如，要求提供电话号码、年龄或性别，以通过电子邮件或邮寄地址发送小册子。
C) 为了“合法、公平和透明” (请参阅 GDPR 第 5.1.a 条) 面向员工) 的隐私策略 (，) 面向用户/客户的隐私声明 (必须到位。 通常，隐私声明应在组织的网站上公开提供。
不符合：策略不存在或缺少关键元素。
关键元素：
隐私策略/通知：信息收集和使用、处理的数据元素、处理 () 的目的、处理的合法性、向其他国家/地区的数据传输、数据主体权利、数据存储和保留。
D) 有关选择退出机制 (通常位于网页上的 GDPR 第 4.11条、GDPR 第 6条和 GDPR 第 7 条) 。 检查用户需要遵循的导航才能访问该页面 (例如，是否易于查找？) 。
不符合：没有明确的选择退出功能，或“通用”选择退出，没有粒度。
示例证据：
对于 ) ：
对于 B) ：
对于 C) ：
对于 D) ：
控制编号 11 - 用户感知
提供用户了解以下事项的证据：
有权访问其数据的)
B) 谁有权访问他们正在处理的空间
C) 谁可以通过共享或数据流访问其数据，以便他们做出明智的决策。
意向：
此控制的目的是演示数据保护“透明度”原则， (请参阅 GDPR 第 5.1.a 条) 。
指南：
为了证明这是理想情况，某种形式的用户确认 (例如，阅读隐私策略) 应到位并记录。
实际上，只有员工隐私策略 () 、用户和客户的隐私声明 () ，就以下内容提供了足够的详细信息：
- 与 (处理者、子处理者、第三方、承包商等 ) 共享个人数据。
不符合：不存在确认，或者不存在隐私策略/隐私声明。
示例证据：
OR
控制第 12 号 - 数据处理协议 (DVA)
提供数据处理协议的证据，该协议应包含所有已批准的第三方/子处理者的列表。
意向：
为了确保你与数据主体保持透明，确保他们了解哪些第三方/子处理者可以访问其数据，他们在处理 (数据控制者、数据处理者) 所扮演的角色、各自的职责和安全机制。
此外，如果共享数据涉及根据 GDPR) (向欧盟以外的地区传输数据，则确保传输是合法的机制细节。 (请参阅 GDPR 第 5 条 和 GDPR 第 44-50 条)
对于 GDPR，要处理的区域必须满足以下条件之一：
- 成为欧盟成员国。
- 欧盟委员会认为提供“适当的保障措施”。 可在此处找到当前列表： 非欧盟国家的数据保护充分性
截至 2025年 6 月 13 日：
- 成为数据隐私框架 (DPF) 的一部分，并在此处列出： 数据隐私框架
- () 制定具有约束力的公司规则。
- Standard合同条款 (SCC) 到位。
指南：
证据可以通过对现有子处理者 (DPA) 的数据处理协议进行采样。 在某些情况下，组织可能没有 DVA，但会有合同的附录或“隐私条款”。
不符合：
- 缺少 3 个rd 方/子处理器的列表。
- 未提供有关接收国的详细信息。
- 国家/地区未列为“适当国家/地区”，并且没有到位的 BCR 或 SCC。
示例证据：
此示例显示了来自 IAPP 的示例 DPA，或者证据可能是列出与其共享数据的各方的相关文档。
此外，检查欧盟以外的数据传输机制。
控制第 13 号 - 数据保护影响评估 (DPIA)
提供组织 (DPIA) 进行数据保护影响评估的证据
OR
提供与此隐私评审相关的数据隐私和保护相关的评估名称。
意向：
此控制的目的是确保你对个人权利和自由的潜在风险进行评估，特别是与引进新技术或现有技术的新用途相关的风险。 (请参阅 GDPR 第 35 条)
指南：
将通过查看最新的 DPIA 或相关评估文档来评估此控制。
不符合：
DPIA 应具有以下元素：
- 标识对 DPIA 的需求。
- 描述设想的处理，包括范围、上下文和目的 () 。
- 评估必要性和相称性。
- 识别和评估风险。
- 识别降低风险的措施。
- 记录的结果。
如果缺少上述任何内容，或者只是在敷衍级别执行，则此控件可以标记为不符合。
示例证据：
DPIA 的完整模板可以在 ICO 的网站上找到 dpia-template.docx
控制措施 14 - 生物识别数据
应用程序是否与生物识别数据交互？ 如果是，
提供证据，证明生物识别数据已通过法律审查，受到保护，并告知用户选择加入/退出生物识别数据收集。
意向：
此控制措施有意确保对生物识别数据的充分保护，根据 GDPR 第 9 条 ，生物识别数据被归类为特殊类别的数据。 生物识别数据的使用经过了合法性分析。
指南：
生物识别数据的使用必须经过法律审查，因此需要将其作为证据收集的一部分提供。 如果不存在，请请求 (用于检查其就绪情况的模板) 。
不符合：
有关处理生物特征数据的法律审查应包含以下内容：
- 处理 (以下一个或多个) 的法律依据：
| 同意 | 合同的履行 | 其他法律义务 |
|---|---|---|
| 同意 | 合同的履行 | 其他法律义务 |
| 切身利益 | 公共利益 | 合法利益 |
- 列出处理生物识别数据的有效条件 (以下一个或多个) ：
| 用户的显式同意 | 就业或社会保障 |
|---|---|
| 用户的显式同意 | 就业或社会保障 |
| 保护切身利益 | 合法活动 |
| 个人数据显然由数据主体公开 | 法律索赔的建立、行使或辩护 |
| 重大公共利益 | 预防医学或职业医学 |
| 公众对公共卫生领域的兴趣 | 出于公共利益、科学或历史研究的存档目的 |
- 考虑使用替代项，而不是生物识别数据。
如果缺少上述任何内容，或者只是在敷衍级别执行，则此控件可以标记为不符合。
示例证据：
源:
- GDPR 第 9 条 – 特殊类别数据的处理： GDPR 第 9 条 – 特殊类别个人数据的处理 - 一般数据保护条例 (GDPR)
- ICO“我们如何合法处理生物识别数据？”： 我们如何合法处理生物识别数据？ |ICO
控制编号 15 - Data Insights
提供证据，证明指标仅显示聚合和匿名数据，而没有单独的可识别数据。 租户应能够配置其首选聚合级别下限，产品允许的绝对最小值为 5。
意向：
此控制的目的是确保在整个数据生命周期内实现并维护匿名和假名化数据的状态。 (请参阅
指南：
为了帮助证明此控制已到位，应通过 GUI 或 CLI 提供证据来证明：
- 聚合级别的最低限制的用户级配置。
- 指标示例。
评估用户是否可以为其首选聚合级别配置阈值，使其至少为 5。 证据应证明指标样本中仅存在匿名。
不符合：
- 用户无法将其聚合级别自定义为至少 5 个，或者典型用户无法期望这样做所需的技术技能。
- 指标示例中存在个人数据;例如：姓名、姓氏、ID、客户号码、电话号码、电子邮件地址、邮政地址、银行详细信息、近亲等。
示例证据：
配置设置的屏幕截图，其中显示了特定详细信息。
收集的指标示例。 也许询问实现匿名的过程。
GDPR
大多数组织都将处理可能是欧洲公民 (数据主体) 数据的数据。 在处理任何数据主体的数据时，组织将需要满足 GDPR) (一般数据保护条例。 这适用于数据控制者 (你直接捕获上述数据) 或数据处理者， (你代表数据控制器) 处理这些数据。 虽然本节不涵盖整个法规，但它涉及 GDPR 的一些关键要素，以帮助获得组织认真对待 GDPR 的一些保证。
控制编号 16
提供证明遵守数据主体权利的证据，方法是显示：
) 主题访问请求 (SAR) 协助：
确认数据主体有权访问其个人数据的文档，并且可以将主题访问请求 (SAR) 提交到你的组织。
B) 数据发现和 SAR 履行：
证明组织有能力在所有系统和存储库中查找和检索与个人数据主体相关的所有个人数据，以响应 SAR。
意向：
此控制的目的是确保为数据主体提供适当的机制，以便对组织持有的个人数据提出请求，并确保对合法请求的履行是彻底的。 (请参阅 GDPR 第 15 条) 。
指南：
) 隐私声明应包含有关如何进行 SAR 的详细信息，该 SAR 可能使用以下方法：
- 使用组织提供的 Web 表单
- 使用组织提供的电子邮件地址
- 使用组织提供的电话号码/Webchat
- 使用监管局 (例如英国的 ICO)
请求方法到位的证据;屏幕捕获应已足够。
B) RoPA 或类似文档可用于标识与数据主体有关的个人数据所在的位置，无论是数字数据，还是作为物理) (备案系统的一部分。
或者，电子发现练习可以实现相同的结果。
请求用于履行 SAR 的过程/工作流的证据，并说明如何确定该过程是彻底的，不会错过任何与数据主体相关的个人数据。
不符合：
) 通常 (隐私声明) 中未在组织的网站上提供任何信息。
B) 证据表明收集个人数据的过程并不彻底，或者可能缺乏技术细节 (例如，没有为) 的数据库提供名称/位置。
示例证据：
A) 以下是可以提供哪些证据来涵盖点 A) 的示例。
– Web 窗体：
来源： 主题访问请求 - 英国警方护理
- Email地址/电话号码：
来源： 哪个？隐私策略 - 哪些？
- Webchat：
- 通过监管机构 (，例如 ICO) ：
B) 提供的证据，详细说明工作流或流程说明，具有足够的技术细节，这可以合理地用于履行 SAR。
第 17 号控制措施
提供隐私声明，其中应包含所有必需的元素，如下所示：
A) 组织的标识和联系人详细信息以及数据保护专员 (DPO) （如果适用）。
B) 组织处理的个人数据类型 (姓名、姓氏、客户号码、电子邮件地址、电话号码等 ) 。 此外，个人数据来源 (例如个人数据来自) ，以防组织未直接从数据主体处获取这些数据。
C) 处理个人数据的目的 () 。
D) 处理个人数据的合法依据 (包括相关) 的合法权益。
E) 组织与其共享个人数据的各方。
F) 个人数据将保留多长时间的详细信息。
G) 数据主体权利的详细信息：
知情权
访问权
纠正权
擦除权限
限制处理的权利
数据可移植性权限
对象权限
与自动决策相关的权利，包括分析
H) 有关向第三国传输个人数据的详细信息以及采取的安全措施。
我) 向监管机构提出投诉的权利， (提供监管机构的联系方式，例如英国的ICO) 。
意向：
目的是根据 GDPR 第 3 章，通过包括上述要素和原则，确保已发布的隐私声明包含足够的详细信息。
指南：
根据 Control 10.c，必须发布涵盖 Microsoft 365 认证中包含的服务的隐私声明。 本隐私声明必须包含上面突出显示的要素和原则。
不符合：
请参阅 Control 10.c。
示例证据：
请参阅 Control 10.c。
HIPAA (健康保险可移植性和责任法案)
1996年《健康保险可移植性和责任法案》 (HIPAA) 是一项适用于美国公民和医疗保健组织的联邦立法。 值得注意的是，这项立法还涵盖美国境外处理美国公民医疗数据的任何组织。 这项立法的出台授权美国卫生和公众服务部部长 (HHS) 制定保护某些健康信息的隐私和安全法规。 某些组织可能会处理可能受保护的健康信息 (ePHI) ，这意味着通过电子媒体传输、在电子媒体中维护或以任何其他形式或媒体传输或维护的个人身份健康信息。 在处理任何数据主体的运行状况数据时，组织需要满足 HIPAA 要求。
HIPAA 有两项立法需要考虑：“隐私规则”或“个人身份健康信息隐私标准”，其中概述了保护某些健康信息的国家标准，以及“保护电子保护健康信息的安全标准”，也称为“安全规则”。 后者建立了一套国家安全标准，以保护以电子形式持有或传输的某些健康信息。
从高级概述中，“安全规则”是“隐私规则”所提供的保护的实际实现。 它概述了“所涵盖实体”为确保个人“电子受保护健康信息” (电子PHI) 安全而必须实施的技术和非技术措施。 虽然本节不涵盖整个法规，但它涉及 HIPAA 的一些关键要素，以帮助获得一些保证，即组织符合要求，并且组织正在保护其处理的运行状况信息。
控制编号 18
请提供可证明的证据，证明：
组织中针对员工、承包商等的 HIPAA 和 HIPAA 处理存在策略。
ISV 确保其创建、接收、维护或传输的 ePHI 的机密性、完整性和可用性。
防范对 ePHI 安全性或完整性的任何合理预期威胁和危害。
意向：
此子点的意图是确保组织已建立协议，作为管理健康信息、处理紧急情况和服务中断以及员工访问健康信息和培训的标准程序。 此外，组织应维护和概述这些管理安全措施，作为其 HIPAA 安全计划的一部分。 这是遵守 HIPAA 法规的一个重要方面。
指南：
提供该组织的既定文件，概述 HIPAA 政策和程序，就证明了这一点。 认证分析师将对此进行审查，以确保控制范围内提供的所有信息都得到解决。
示例证据：
屏幕截图显示了 HIPAA 策略的快照。 请注意：期望 ISV 共享实际的支持策略/过程文档，而不只是提供屏幕截图。
注意：ISV 期望共享实际的综合支持策略/过程文档，而不只是提供屏幕截图。
意向：
为了了解此子点的意图并确保符合安全规则，“涵盖的实体”必须首先知道在 § 164.304 下如何定义保密性、完整性和可用性条款：
保密性：“未向未经授权的人员或进程提供或披露数据或信息的属性。
完整性：“未以未经授权的方式更改或销毁数据或信息的属性。
可用性：“授权人员可按需访问和使用数据或信息的属性。
此要求的意图是组织在 IT 基础结构中实施技术安全措施/措施，例如访问、审核、完整性和传输控制，以确保 ePHI 机密性，同时保持其完整性和对授权用户的可用性。
指南：
可以通过保护机制的配置设置来提供证据，这些机制用于确保 ePHI 数据符合控制要求的安全。 此类机制可能包括访问控制、紧急访问过程、RBAC、加密等。
示例证据：访问和完整性控制
下一个屏幕截图显示，有权处理 ePHI 存储位置的个人的授权访问列表存在，并在 HIPAA 策略文档中维护。 此外，在批准的清单列表后面的屏幕截图中，可以看到，整个群集的写入访问权限有限，只有管理员和数据库维护分析师能够在群集上读取和写入。
从 Atlas Mongo 中的一个 ePHI 存储数据库拍摄的下一个屏幕截图显示，只有授权用户才具有记录的访问权限，并且所有帐户都具有唯一的用户 ID 以确保责任。
第一个屏幕截图显示了 ePHI 的main存储位置/数据库群集。
第二张屏幕截图演示已批准的用户仅记录了角色和访问权限。
接下来的两个屏幕截图显示分配的每个角色以及与上述访问审批一致的所有关联权限的更精细视图。
每个自定义角色都有一组权限和访问范围。
最后，下一张屏幕截图从网络角度来看，仅允许授权的 IP 范围（即安全公司网络）访问群集。
示例证据：审核控制
这些屏幕截图显示了为数据库群集实现日志记录和警报。 第一个屏幕截图显示已启用警报。 请注意，预期提供的证据还会显示根据组织的需求/实现设置的警报规则。 第二个屏幕截图显示正在启用数据库审核。
下一个屏幕截图显示正在记录的数据库群集的访问历史记录。 预期是基于审核日志设置警报，任何不符合预定义条件的未经授权的访问都会触发警报。
最后两个屏幕截图显示为数据库群集生成了审核日志，并且可以导出日志进行分析。
请注意，预期需要有一个流程来分析生成的审核日志，还必须提供评审过程的证据。 如果以编程方式实现，则必须提供日志引入到所用平台/日志记录解决方案的配置设置的屏幕截图，以及规则的屏幕截图以供查看。
示例证据：加密和传输控制
接下来的屏幕截图演示了存储位置的静态数据默认加密。 请注意，如果默认使用的平台未执行加密，并且自己的加密密钥正在使用中，则预期这些密钥已得到充分保护，并提供证据来证明这一点。
接下来的两个屏幕截图演示了存储位置的传输中的数据默认加密。 第一个屏幕截图演示了数据 API 已启用“读取和写入”权限。
终结点的 SSL 扫描表明传输中的数据是通过 TLS 1.2 加密的。
示例证据：可用性和恢复控制
下一个屏幕截图演示了跨三个区域复制数据库群集以确保可用性。 默认情况下，此作由 Mongo Atlas 完成。 此外，备份已启用并且处于活动状态。
以下屏幕截图显示了群集的备份仪表板，其中还演示了已创建快照。
接下来的两个屏幕截图演示了备份策略，可以在不同的时间点执行计划备份， (PIT) 。
下面指示快照和时间点还原 (PIT) 都有保留策略。
意向：
此子点的意图与安全规则一致，该规则旨在确保灵活性和可伸缩性，以便“涵盖的实体”可以实施适合实体规模、组织结构及其特定风险以及风险偏好的策略、过程和技术解决方案。 从实际角度来看，这意味着实施的适当安全措施将取决于“所涵盖实体”业务的性质及其规模和资源。
对于每个组织来说，必须进行全面的风险分析，以发现电子PHI的机密性、完整性和可用性的潜在风险和漏洞。 然后，通过此风险分析，组织可以实施适当的安全控制来缓解这些已识别的风险。
指南：
可以通过风险分析输出提供证据。 如果通过联机平台执行和维护风险分析，则应提供整个输出的屏幕截图。
示例证据：
接下来的屏幕截图显示风险评估过程的快照，然后是执行的风险分析，以确定控制措施正确实现的程度，并按预期方式运行以保护 ePHI。 第二张屏幕截图显示了风险评估中确定的风险的风险分析，以及为降低风险级别而实施的补偿控制和缓解措施。
示例 1 - HIPAA 策略中风险评估过程的快照，以及执行的风险分析
注意：此屏幕截图显示了风险分析文档的快照，这只是一个示例，ISV 希望共享实际文档，而不只是提供屏幕截图。
示例 2 - HIPAA 策略中的风险评估过程的屏幕截图，以及执行的风险分析 (在 Confluence Cloud Platform 中维护)
第二张屏幕截图显示了风险评估中确定的风险的风险分析，以及为降低风险级别而实施的补偿控制和缓解措施。 可以看到，这在 Confluence 云平台中存在并得到维护。
第 19 号控制措施
请提供 (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。
References
行动欺诈网络犯罪报告提供于： 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.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) 。
我们应何时提供隐私信息？ |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) 。
使用敏感数据保护在大规模数据集中取消标识和重新标识 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) 。