ISO/IEC 27001：2022附录A新增的11个控制如下：
| 5 | 组织控制 | |
| 5.7 | 威胁情报 | 控制 与信息安全威胁相关的信息应被收集和被分析，以获得威胁情报。 |
| 5.23 | 使用云服务的信息安全 | 控制 应根据组织信息安全要求，为获取、使用、管理和退出云服务建立流程。 |
| 5.30 | 信息与通信技术（ICT）的业务连续性准备 | 控制 应基于业务连续性目标和信息与通信技术（ICT）连续性要求，策划信息与通信技术（ICT）的准备，并予以实施，保持和测试。 |
| 7 | 物理控制 | |
| 7.4 | 物理安全监视 | 控制 边界应被持续监视，以防止未授权的物理访问。 |
| 8 | 技术控制 | |
| 8.9 | 配置管理 | 控制 硬件、软件、服务和网络的配置(包括安全配置)应被建立文件化的清单，并予以实施、监视和评审。 |
| 8.10 | 信息删除 | 控制 存储在信息系统、设备或任何其他存储介质中的信息，当不再需要时应予以删除。 |
| 8.11 | 数据脱敏 | 控制 应根据组织访问控制的特定主题策略和其他相关特定主题的策略，以及业务需求，并考虑适用的法律，使用数据脱敏。 |
| 8.12 | 数据泄露防护 | 控制 数据泄露防护措施应应用于处理、存储或传输敏感信息的系统、网络和任何其他设备。 |
| 8.16 | 监视活动 | 控制 应监控网络、系统和应用程序的异常行为，并采取适当行动评估潜在的信息安全事件。 |
| 8.23 | 网页过滤 | 控制 应对外部网站的访问进行管理，以减少暴露于恶意内容。 |
| 8.28 | 安全编码 | 控制 安全编码原则应被应用于软件开发。 |
以上11项控制，虽然是ISO/IEC 27001：2022附录A新增控制，但并不是新的东西，实际上很多组织在实施信息安全管理的时候，这些控制都已经在采用了。
| 5.7 | 威胁情报 | 控制 与信息安全威胁相关的信息应被收集和被分析，以获得威胁情报。 |
控制解析：
- 威胁情报可分为三层：（1）战略威胁情报：不断变化的威胁情形（例如，攻击者或攻击类型）的高级别信息的交换；（2）战术威胁情报：关于攻击方法、工具和涉及的技术的信息；（3）操作威胁情报：具体攻击的细节，包括技术指标。
- 采用“5.7 威胁情报”控制，组织应考虑实施以下活动：（1）建立威胁情报收集的目标；（2）识别、评价和选择必要和适当的内部和外部信息来源，以便为收集威胁情报提供所需的信息；（3）从选定的来源收集信息，可以是内部和外部的;（4）处理收集到的信息，为分析做好准备（例如，转换、格式化或证实信息）；（5）分析信息，理解其与组织的关系和对组织的重要性;（6）以一种可以理解的形式，与相关人员进行沟通和共享收集的威胁情报；（7）通过实施流程，将从威胁情报来源收集的信息纳入组织的信息安全风险管理流程；（8）作为防火墙、入侵检测系统或反恶意软件解决方案等技术预防和检测控制的附加输入；（9）作为信息安全测试流程和技术的输入。
- 组织应在对等基础上与其他组织相互共享威胁情报，以提高整体威胁情报水平。
| 5.23 | 使用云服务的信息安全 | 控制 应根据组织信息安全要求，为获取、使用、管理和退出云服务建立流程。 |
控制解析：
- 组织应制定关于使用云服务的特定主题策略，并传达给相关方（例如，为组织提供云服务的供应商）；
- 组织应该定义并沟通组织打算如何管理与云服务使用相关的信息安全风险，可以在组织如何管理外部各方提供的服务的现有方法（见5.21和5.22）基础上扩展；
- 组织应明确组织和云服务提供商双方的信息安全责任，上方应签订相关的协议；
- 组织应明确：（1）与使用云服务有关的所有相关信息安全要求；（2）云服务选择标准和云服务使用范围；（3）与云服务的使用和管理相关的角色和职责；（4）哪些信息安全控制由云服务提供商管理，哪些由作为云服务客户的组织管理；（4）如何获取和利用云服务商提供的信息安全能力；（5）如何确保云服务供应商实施的信息安全控制；（6）当组织使用多个云服务，特别是来自不同云服务提供商的云服务时，如何管理服务中的控制、接口和变更；（7）处理与使用云服务有关的信息安全事件的程序；（7）组织监视、评审和评价持续使用云服务管理信息安全风险的方法；（8）如何改变或停止云服务的使用，包括云服务的退出策略。
- 云服务协议应解决组织的机密性、完整性、可用性和信息处理要求，并具有适当的云服务水平目标和云服务质量目标。
- 组织还应进行相关风险评估，以识别与使用云服务相关的风险。任何与使用云服务有关的残余风险都应明确识别，并由组织的适当管理人员签字确认接受保留。
- 云服务提供商与作为云服务客户的组织之间的协议应包括以下条款，以保护组织的数据和服务的可用性：（1）根据行业认可的架构和基础设施标准提供解决方案；（2）管理云服务的访问控制，以满足组织的需求；（3）实现恶意软件监控和保护解决方案；（4）在经批准的地点（例如，特定国家或地区）或在特定司法管辖范围内或受特定司法管辖范围内处理和存储组织的敏感信息；（5）在云服务环境中发生信息安全事件时提供专门的支持；（6）确保在将云服务进一步分包给外部供应商的情况下满足组织的信息安全需求（或禁止将云服务分包）；（7）支持本组织收集数字证据，同时考虑不同司法管辖区的数字证据的法律法规；（8）当组织想要退出云服务时，在适当的时间框架内提供适当的服务支持和可用性；（9）根据作为云服务客户的组织所使用的云服务提供商的能力，提供所需的数据和配置信息备份，并在适用时安全地管理备份；（10）在服务提供期间或服务终止时，提供并返回作为云服务客户的组织所拥有的信息，如配置文件、源代码和数据。
- 作为云服务客户的组织应考虑，协议是否应要求云服务提供商在对其向组织提供服务的方式进行变更的任何实质性客户影响之前，提前通知客户，包括：（1）影响或改变云服务提供的技术基础设施变更（例如，重新安置、重新配置或硬件或软件变更）;（2）在新的地理或法律管辖范围内处理或储存信息；（3）使用同等云服务提供商或其他分包商（包括更改现有方或使用新方）。
- 使用云服务的组织应与其云服务提供商保持密切联系。这些联系使双方能够相互交换有关使用云服务的信息安全的信息，包括云服务提供商和作为云服务客户的组织监测每项服务特性并向协议中所载承诺报告失败的机制。
- 有关云服务安全可以参考：ISO/IEC 17788、ISO/IEC 17789、ISO/IEC 22123-1、ISO/IEC 19941、ISO/IEC 27017、ISO/IEC 27018、ISO/IEC 27036-4、ISO/IEC 19086、ISO/IEC 19086-4等标准。
| 5.30 | 信息与通信技术（ICT）的业务连续性准备 | 控制 应基于业务连续性目标和信息与通信技术（ICT）连续性要求，策划信息与通信技术（ICT）的准备，并予以实施，保持和测试。 |
控制解析：
- ICT业务连续性准备是业务连续性管理和信息安全管理的一个重要组成部分，以确保在中断期间能够继续实现本组织的目标。
- ICT连续性要求是业务影响分析（BIA）的结果。BIA过程应使用影响类型和标准来评估由于交付产品和服务的业务活动中断而造成的长期影响。
- 根据BIA的产出和涉及ICT服务的风险评估，该组织应确定和选择ICT连续性战略，考虑中断之前、中断期间和中断之后的选项。
- 业务连续性策略可以包含一个或多个解决方案。应根据这些战略制定、实施和测试计划，以满足关键进程中断或故障后所需的ICT服务可用性水平和所需的时间框架。
- 组织应确保：（1）有一个适当的组织架构来准备、减轻和响应中断，并由具有必要的职责、权限和能力的人员提供支持；（2）ICT连续性计划（包括详细说明组织计划如何管理ICT服务中断的响应和恢复程序）如下：a) 通过演练和测试定期评价，b)和经管理层批准；（3）ICT连续性计划包括以下ICT连续性信息：a) 绩效和能力规范，以满足业务连续性要求和BIA中规定的目标；b) 每个优先信通技术服务的RTO和恢复这些组件的程序；c) 优先信息通信技术资源的RPO定义信息和恢复信息的程序。
- 管理ICT连续性是业务连续性要求的一个关键部分，涉及以下方面的可用性：（1）对ICT服务中断作出响应并从中断中恢复，无论中断的原因是什么；（2）确保所需的信息和通信技术服务支持优先活动的连续性；（3）在ICT服务中断发生之前，以及在检测到至少一个可能导致ICT服务中断的事件时，作出响应。
- 实施本控制要求可以进一步参考以下标准：ISO/IEC 27031、ISO 22301、ISO 22313和ISO/TS 22317。
| 7.4 | 物理安全监视 | 控制 边界应被持续监视，以防止未授权的物理访问。 |
控制解析：
- 物理场所应由监视系统进行监视，监视系统可包括警卫、入侵警报、闭路电视等视频监视系统和内部或由监视服务提供商管理的物理安全信息管理软件。
- 进入装有重要系统的建筑物的情况应持续监视，以侦测下列的非授权访问或可疑行为：（1）安装视像监控系统，例如闭路电视，以查看和记录进入机构内外敏感区域的情况；（2）根据相关适用标准安装，并定期测试接触，声音或运动探测器以触发入侵报警，如：a) 安装触点探测器，在任何可以触点形成或破裂的地方（如窗户、门和下面的物体），当触点形成或破裂时触发报警，以用作恐慌警报；b) 基于红外技术的运动探测器，当物体通过他们的视野时，就会触发警报；c) 安装对玻璃破碎声音敏感的传感器，用于触发报警，提醒保安人员；（3）用这些警报覆盖所有的外部门和可进入的窗户。无人居住的地区应始终保持警觉；还应为其他区域（例如，计算机或通讯室）提供掩护。
- 监控系统的设计应该保密，因为泄露会促进不被察觉的入侵。
- 监控系统应该被保护，防止未经授权的访问，以防止监控信息，如视频提要，被未经授权的人或被禁用的远程系统访问。
- 任何监控和记录机制的使用都应考虑当地的法律法规，包括数据保护和PII保护立法，特别是关于人员监控和记录视频保留期的监控。
| 8.9 | 配置管理 | 控制 硬件、软件、服务和网络的配置(包括安全配置)应被建立文件化的清单，并予以实施、监视和评审。 |
控制解析：
- 组织应定义过程和工具，并予以实施，以便强制执行已定义的配置（包括安全配置）。
- 角色、职责和程序应恰当，以确保所有配置变更得到合适的控制。
- 硬件、软件、服务和网络的安全配置的标准模板应被定义：（1）使用公开可用的指南（例如，来自供应商和独立安全组织的预定义模板）；（2）考虑所需的保护级别，以确定足够的安全级别；（3）支持组织的信息安全政策、特定主题的政策、标准和其他安全要求；（4）在组织环境下文考虑安全配置的可行性和适用性。
- 应该定期评审模板，并在需要处理新的威胁或漏洞时，或在引入新的软件或硬件版本时对模板进行更新。
- 建立硬件、软件、服务和网络安全配置的标准模板，应考虑以下因素：（1）最小化具有特权或管理员级访问权限的账户的数量；（2）禁用不必要的、未使用的或不安全的账户；（3）禁用或限制不必要的功能和服务；（4）限制访问强大的实用程序和主机参数设置；（5）同步时钟；（6）安装后立即更改供应商默认身份验证信息，如默认密码，并检查其他重要的默认安全相关参数；（7）在预设的不活动时间之后，自动注销计算设备的超时设施；（8）验证以满足的许可要求。
- 应记录已建立的硬件、软件、服务和网络配置，并维护所有配置更改的日志。这些记录应安全保存。这可以通过多种方式实现，例如，配置数据库或配置模板。
- 对配置的变更应遵循变更管理规程（见8.32）。
- 配置记录可以包含以下相关内容：（1）资产的最新所有者或联络点信息；（2）上次变更配置的日期；（3）配置模板版本；（4）与其他资产配置的关系。
- 应使用一套全面的系统管理工具（例如，维护工具、远程支持、企业管理工具、备份和恢复软件）监控配置，并应定期检查，以验证配置设置、评估密码强度和评估所执行的活动。可以将实际配置与定义的目标模板进行比较。任何偏差都应该被处理，通过自动执行定义的目标配置，或者通过手动分析偏差，然后采取纠正措施。
| 8.10 | 信息删除 | 控制 存储在信息系统、设备或任何其他存储介质中的信息，当不再需要时应予以删除。 |
控制解析：
- 实施本控制的目的是防止敏感信息的不必要暴露，并遵守有关删除信息的法律、法规、监管和合同要求。
- 敏感资料的保存时间不应超过所需的时间，以减少不良披露的风险。
- 删除系统、应用程序和服务的资料时，应考虑以下因素：（1）根据业务需求和考虑相关法律和法规，选择删除方法（例如，电子覆写或密码擦除)；（2）记录删除结果作为证据；（3）在使用信息删除服务提供商时，从服务提供商获取信息删除的证据。
- 组织委托第三方存储组织的信息，则组织应考虑将信息删除要求纳入第三方协议中，以便在此类服务终止期间和终止后强制执行。
- 根据组织关于数据保留的特定主题策略，并考虑到有关的法律和法规，敏感信息应在不再需要时予以删除：（1）配置系统，以便在不再需要时安全地销毁资料；（2）删除已废弃的版本、副本和临时文件；（2）使用批准的，安全的删除软件永久删除信息，以帮助确保信息不能通过专家或取证工具恢复；（3）使用经批准、认证的安全处置服务供应商；（4）使用适合于所要清除的储存媒体类型的清除机制（例如，对硬盘驱动器和其他磁性存储介质消磁）。
- 在使用云服务的情况下，组织应验证云服务提供商提供的删除方法是否可接受，如果可以，组织应使用该方法，或请求云服务提供商删除信息。这些删除过程应该按照特定于主题的策略自动执行。根据被删除信息的敏感度，日志可以跟踪或验证这些删除过程是否已经发生。
- 为避免敏感信息在设备送回供应商时无意中泄露，应在设备离开组织场所前移除辅助存储（例如，硬盘驱动器）和内存，以保护敏感信息。
- 考虑到某些设备（例如，智能手机）的安全删除只能通过销毁或使用这些设备内嵌的功能（例如，“恢复出厂设置”）来实现，组织应根据这些设备处理的信息分类选择合适的方法。
- 应采取7.14所述的控制措施，对存储设备进行物理销毁，同时删除存储设备所包含的信息。
- 关于云服务用户数据删除可以参考ISO/IEC 27017；个人身份信息（PII）删除可以参考ISO/IEC 27555。
| 8.11 | 数据脱敏 | 控制 应根据组织访问控制的特定主题策略和其他相关特定主题的策略，以及业务需求，并考虑适用的法律，使用数据脱敏。 |
控制解析：
- 实施本控制的目的是限制敏感资料（包括PII）的公开，并遵守法律、法规、监管及合同的要求。
- 如果敏感数据的保护（例如PII）是一个关注点，那么组织应该考虑使用数据脱敏、假名化或匿名化等技术来隐藏这些数据。
- 其他的一些数据脱敏技术：（1）加密（要求授权用户拥有密钥）；（2）空字符或删除字符（防止未授权用户看到完整的消息）；（3）不同的数字和日期；（4）替换（将一个值替换为另一个值，以隐藏敏感数据）；（5）用哈希值替换值。
- 关于保护公共云中的PII，可以参考ISO/IEC 27018；关于去识别技术的更多信息参考ISO/IEC 20889。
| 8.12 | 数据泄露防护 | 控制 数据泄露防护措施应应用于处理、存储或传输敏感信息的系统、网络和任何其他设备。 |
控制解析：
- 组织应考虑以下因素以降低数据泄漏的风险：（1）识别及分类分级资料以防止资料外泄（例如：个人资料、定价模式及产品设计）；（2）监视资料泄漏的途径（例如，电子邮件、档案传输、移动设备及移动储存设备）；（3）采取措施防止信息泄漏（例如，隔离包含敏感信息的电子邮件）。
- 数据泄密防护工具应被使用，以：（1）识别和监控有可能未经授权泄露的敏感信息（例如，用户系统上的非结构化数据）；（2）检测敏感信息的泄露（例如，当信息被上传至不可信的第三方云服务或通过电子邮件发送时）；（3）阻止暴露敏感信息的用户操作或网络传输（例如，阻止将数据库条目复制到电子表格中）。
- 如果需要数据导出，应该允许数据所有者批准导出，并让用户对他们的操作负责。
- 屏幕截图或照片应通过使用条款和条件、培训和审计加以解决。
- 在进行数据备份时，应采取措施确保敏感资料受到保护，例如，加密、存取控制和对保存备份的存储介质进行物理保护。
| 8.16 | 监视活动 | 控制 应监控网络、系统和应用程序的异常行为，并采取适当行动评估潜在的信息安全事件。 |
控制解析：
- 实施本控制的目的是检测异常行为和潜在的信息安全事件。
- 根据业务和信息安全需求，结合相关法律法规，确定监控范围和级别。监控记录应按规定的保存期限保存。
- 在监测系统中应考虑包括下列事项：（1）出站和入站网络、系统和应用程序流量；（2）系统、服务器、网络设备、监控系统、关键应用程序等其他设施的访问；（3）关键或管理级别的系统和网络配置文件；（4）来自安全工具的日志（例如，防病毒软件，入侵检测系统IDS，入侵防御系统IPS， web过滤器，防火墙，数据泄漏防护软件）；（5）与系统和网络活动有关的事件日志；（6）检查正在执行的程式码是否已获授权在系统内运行，并没有被窜改（例如，重新编译以添加额外的不需要的程式码）；（7）资源（例如，CPU、硬盘、内存、带宽）的使用及其性能。
- 组织应建立正常行为的基准，并根据这一基准监测异常行为。在确定基线时，应考虑以下因素：（1）在正常和高峰期检查系统的使用情况；（2）每个用户或用户组的通常访问时间、访问位置、访问频率。
- 应该使用监控工具进行持续监控。应根据组织的需要和能力，实时或定期进行监测。监控工具应该包括处理大量数据的能力，适应不断变化的威胁环境，并允许实时通知。这些工具还应该能够识别特定的签名和数据或网络或应用程序行为模式。
| 8.23 | 网页过滤 | 控制 应对外部网站的访问进行管理，以减少暴露于恶意内容。 |
控制解析：
- 实施本控制的目的是保护系统不被恶意软件入侵，并防止对未经授权的网络资源的访问。
- 组织应减少其人员访问含有非法信息或已知含有病毒或网络钓鱼材料的网站的风险。可以通过技术阻断有关网站的IP地址或域名来实现这一目的，一些浏览器和反恶意软件技术可以自动或手动配置来实施该功能。
- 组织应确定人员应该或不应该访问的网站类型。组织应考虑屏蔽以下类型的网站：（1）具有信息上传功能的网站，除非出于有效的商业原因被允许；（2）已知或怀疑有恶意网站（例如，散布恶意软件或网络钓鱼内容的网站）；（3）指挥和控制服务器；（4）从威胁情报获取的恶意网站（见5.7）；（5）分享非法内容的网站。
- 应就安全及适当使用网上资源，包括进入网络，对人员进行培训。培训应该包括组织的规则、提出安全问题的联络点，以及出于合法业务原因需要访问受限web资源时的例外过程。还应该对工作人员进行培训，以确保他们不会无视浏览器的任何提示，即网站不安全，但允许用户继续浏览。
| 8.28 | 安全编码 | 控制 安全编码原则应被应用于软件开发。 |
控制解析：
- 实施本控制的目的是确保软件的编写是安全的，从而减少软件中潜在的信息安全漏洞。
- 组织应该建立组织范围内的为安全编码提供良好的治理的过程。应建立并应用最低安全基线。此外，这种过程和治理应该被扩展，以覆盖来自第三方和开源软件的软件组件。
- 组织应监控现实世界的威胁和软件漏洞的最新建议和信息，通过持续改进和学习来指导组织的安全编码原则。这有助于确保实现有效的安全编码实践，以应对快速变化的威胁环境。
- 在新开发和重用场景中都应该使用安全编码原则。这些原则应应用于组织内部的开发活动以及组织向他人提供的产品和服务的开发活动。编码前的策划和先决条件应包括：（1）组织内部和外包代码开发所使用的安全编码的特定期望和认可原则；（2）导致信息安全漏洞的常见和历史编码实践和缺陷；（3）配置开发工具，例如，集成开发环境（IDE），以帮助执行安全代码的创建；（4）遵循开发工具和执行环境提供者发布的指导；（5）维护和使用更新的开发工具（例如，编译器）；（6）开发人员编写安全代码的资格；（7）安全设计和架构，包括威胁建模；（8）确保编码标准，并在相关情况下强制使用；（9）使用受控环境进行开发。
- 编码过程中需要考虑的因素应包括：（1）针对所使用的编程语言和技术的安全编码实践；（2）使用安全编程技术，例如，结对编程、重构、同行评审、安全迭代和测试驱动开发；（3）使用结构化程序设计技术；（4）记录代码并消除编程缺陷；（5）禁止使用不安全的设计技术（例如，使用硬编码密码、未经批准的代码示例和未经身份验证的web服务）。
- 测试应在开发期间和之后进行（见8.29）。
- 在软件运行之前，应评估以下内容：（1）攻击面和最小特权原则；（2）对最常见的编程错误进行分析，并记录这些错误已经得到了解决。
- 编码后的评审和维护：（1）更新应该被安全地打包和部署；（2）应处理报告的信息安全漏洞（见8.8）；（3）应该记录错误和可疑攻击，并定期检查日志，以便在必要时对代码进行调整；（4）源代码应受到保护，防止未经授权的访问和篡改（例如，使用配置管理工具，通常提供访问控制和版本控制等功能）。
- 如果使用外部工具和库，组织应该考虑：（1）确保对外部库进行管理（例如，通过维护使用的库及其版本的清单），并定期更新发布周期；（2）选择、授权和重用经过严格审查的组件，特别是身份验证和加密组件；（3）外部组件的许可证、安全性和历史记录；（4）确保软件的可维护性、可跟踪性和来源可靠、信誉良好；（5）开发资源和工件的足够长期可用性。
- 如果软件包需要修改，应考虑以下几点：（1）内置控制和完整性过程被破坏的风险；（2）是否需要获取供应商的同意；（3）从供应商处获得所需变更作为标准程序更新的可能性；（4）如果组织因软件变更而需要对软件的未来维护负责，会有什么影响；（5）与其他软件的兼容性。
