信息安全技术 信息安全风险管理指导 征求意见稿

1GB/T31722-XXXX/ISO/IEC270信息安全技术信息安全风险管理指导本文件提供了信息安全风险管理指导，以帮助组织：——满足GB/T22080—xxxx有关应对信息安全风险活动的要求；——实施信息安全风险管理活动，特别是信息安全风险评估和处置。本文件适用于所有组织，无论其类型、规模或领域。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。ISO/IEC27000信息安全技术信息安全管理体系概述和词汇（Informationsecuritymanagementsystems—Overviewandvocabulary）注：GB/T29246—2017信息安全技术信息安全管理体系概述和词汇（ISO/IEC27003术语和定义GB/T29246—2013界定的以及下列术语和定义适用于本文件。ISO和IEC维护用于标准化的术语数据库，地址如下：——ISO在线浏览平台：/obp——IEC电子百科：信息安全风险相关术语3.1.1外部环境externalcontext组织寻求其目标实现所处的外部状况。[来源：GB/T23694—2013，，有修改]3.1.2内部环境internalcontext组织寻求其目标实现所处的内部状况。2GB/T31722-XXXX/ISO/IEC2——从资源和知识角度理解的能力（例如，资本、时间、人员、过）；[来源：GB/T23694—2013，，有修改]3.1.3风险risk不确定性对目标的影响。），注3：不确定性是指理解或知晓事态（3.1.11）及其后果（3.1.14）或可能性（3.1.13）的相关信息不足，甚至仅注4：风险通常以风险源（3.1.6）、潜在注5：在信息安全管理体系中，信息安全风险能表示为[来源：GB/T24353—2022，3.1，有修改]3.1.4风险场景riskscenario由最初的起因导致不期望后果（3.1.14）的事态序列或组合（3.1.11）。[来源：ISO17666:2016，3.1.13，有修改]3.1.5风险责任人riskowner具有管理风险(3.1.3)的责任和权限的个人或实体。[来源：GB/T23694—2013，]3.1.6风险源risksource可能单独或共同引发风险(3.1.3)的要素。[来源：GB/T24353—2022，3.4，有修改]3GB/T31722-XXXX/ISO/IEC2703.1.7风险准则riskcriteria评价风险（3.1.3）重要性的依据。[来源：GB/T23694—2013，，有修改]3.1.8风险偏好riskappetite组织愿意追求或保留的风险(3.1.3)数量和类型。[来源：GB/T23694—2013，，有修改]3.1.9威胁threat可能导致系统损坏或对组织造成危害的信息安全事件（3.1.12）的潜在因素。3.1.10脆弱性vulnerability可能被利用的资产或控制的弱点（3.1.16从而引起具有负面后果（3.1.14）的事态（3.1.11）。3.1.11事态event某些特定情形的产生或变化。[来源：GB/T24353—2022，3.5，有修改]3.1.12信息安全事件informationsecurityincident极有可能危害业务运行并威胁信息安全的单个或一系列不期望或意外的信息安全事态。3.1.13可能性likelihood某件事发生的概率。注1：在风险管理术语中，无论是以客观的或主观的、定性或定量的方式来定义、度量或确定，还是用一般词汇或），注2：“可能性（likelihood）”这一英语词汇在一些语言中没有直接与之对应的词汇，因此经常使用“概率险管理术语中，“可能性”有着与许多语言中使用的“概率”一词相同的解释，而不局限于英语中“概率”[来源：GB/T24353—2022，3.7]3.1.14后果consequence4GB/T31722-XXXX/ISO/IEC2某事态（3.1.11）对目标影响的结果。注1：后果可能是确定，也可能是不确定的，且对目标的影响可能是正面的，也可能是负面的；可能是直接的，也[来源：GB/T24353—2022，3.6，有修改]3.1.15风险级别levelofrisk风险的严重程度，以后果(3.1.14)和可能性(3.1.13)的组合来表达。[来源：GB/T23694—2013，，有修改]3.1.16控制control保持和/或改变风险(3.1.3)的措施。[来源：GB/T24353—2022，3.8，有修改]3.1.17残余风险residualrisk风险处置(3.2.7)之后仍然存在的风险(3.1.3)。[来源：GB/T23694—2013，，有修改]信息安全风险管理相关术语3.2.1风险管理过程riskmanagementprocess将管理政策、规程和操作方法系统地应用于沟通、咨询、环境建立以及识别、分析、评价、应对、监视和评审风险(3.1.3)的活动中。[来源：GB/T23694—2013，4.1，有修改]3.2.2风险沟通和咨询riskcommunicationandconsultation组织为提供、分享或获取信息，与相关方就风险（3.1.3）管理进行沟通的一系列持续和往复的过程。注2：咨询对问题进行决策或确定方向之前，在组织和其相关方之3.2.3风险评估riskassessment5GB/T31722-XXXX/ISO/IEC270包括风险识别(3.2.4)、风险分析(3.2.5)和风险评价(3.2.6)的全过程。[来源：GB/T23694—2013，4.4.1]3.2.4风险识别riskidentification发现、确认和描述风险（3.1.3）的过程[来源：GB/T23694—2013，4.5.1，有修改]3.2.5风险分析riskanalysis理解风险（3.1.3）性质、确定风险级别（3.1.15）的过程。[来源：GB/T23694—2013，4.6.1，有修改]3.2.6风险评价riskevaluation对比风险分析（3.2.5）结果和风险准则（3.1.7），以确定风险（3.1.3）和/或其重要性是否可以接受或可容忍的过程。[来源：GB/T23694—2013，4.7.1，有修改]3.2.7风险处置risktreatment处理风险（3.1.3）的过程——通过决定不开始或不再继续导致风险的活）；）；）；）；[来源：GB/T23694—2013，4.8.1，有修改]3.2.8风险接受riskacceptance承担特定风险(3.1.3)的知情决策。6GB/T31722-XXXX/ISO/IEC2[来源：GB/T23694—2013，，有修改]3.2.9风险分担risksharing与其他方就风险（3.1.3）分配达成协议的风险处置（3.2.7）形式。[来源：GB/T23694—2013，，有修改]3.2.10风险保留riskretention暂时接受某一特定风险(3.1.3)的潜在收益或损失。[来源：GB/T23694—2013，，有修改]4文件结构本文件结构如下。——第5章：信息安全风险管理。——第6章：环境建立。——第7章：信息安全风险评估过程。——第8章：信息安全风险处置过程。——第9章：运行。——第10章：利用相关ISMS过程。除了一般条款中给出的描述外，第7章至第10章给出的所有风险管理活动的表述结构如下：输入：识别任何实施该活动所需的信息。动作：描述活动。触发：提供关于何时开始行动的指导，例如，由于组织内部变化、根据计划或组织外部环境的变化。输出：识别实施该活动后得到的任何信息，以及该输出宜满足的任何准则。实施指导：提供有关实施行动、关键字和关键概念的指导。5信息安全风险管理信息安全风险管理过程信息安全风险管理过程见图1所示。注：该过程基于GB/T23694—2013中定7沟通与咨沟通与咨询(10.3监视与评审(10.5)(6章)是(8章)否否是(记录和报告)图1信息安全风险管理过程如图1所示，信息安全风险管理过程可以迭代地进行风险评估和/或风险处置活动。风险评估的迭代方法可在每次迭代时增加评估的深度和详细程度。当需要确保风险得到适当评估时，该迭代方法为在尽量减少识别控制所花费的时间和精力之间提供了良好平衡。环境建立是为信息安全风险管理或信息安全风险评估收集内部和外部环境相关的信息。如果风险评估能提供足够充分的信息来有效确定将风险调整到可接受水平所需的活动，则风险评估任务结束，随后进行风险处置。如果信息不充分，则宜再次进行风险评估。这可能涉及风险评估环境的变化(例如，范围修改)、相关领域专业知识的引入，或通过其他方式收集的能将风险调整到可接受水平所需的信息。(见图1中的“风险决策点1”)。风险处置包括以下迭代过程：——制定和选择风险处置选项；8GB/T31722-XXXX/ISO/IEC27005—评估处置的有效性；—如不可接受，则进一步处置。如，范围修改)和相关领域专门知识的引入。了解相关威胁或脆弱性的知险管理循环。个公司的信息技术部门),都能被视为ISMS中的“组织”。a)GB/T22080—xxxx的附录A;b)覆盖ISMS的其他标准；c)适用于特定领域(如金融、医疗健康)的其他标准；9GB/T31722-XXXX/ISO/IEC270d)特定的国际和/或国家法规；e)组织内部安全规则；f)合同或协议中的安全规则和控制；g)基于以往风险处置活动而实现的安全控制。任何不符合基本要求的情况都宜进行解释和说明。这些基本要求及其符合性宜作为可能性评估和风险处置的输入。应用风险评估组织能将风险评估嵌入在许多不同过程中执行，如项目管理、脆弱性管理、事件管理、问题管理，甚至是基于给定的已识别的特定主题的临时执行。无论风险评估如何执行，它们都宜完全涵盖ISMS范围内与组织相关的所有事项。风险评估宜帮助组织就管理影响其目标实现的风险做出决策。因此，这些决策宜以上述风险和控制为目标，若管理有效，将提高组织实现其目标的可能性。GB/T31496提供了关于ISMS环境和通过风险评估了解的事项的更多信息。建立和维护信息安全风险准则6.4.1概述GB/T22080—xxxx，6.1.2a)要求组织定义其风险准则，即组织评估风险严重程度的依据，以便其识别风险并做出风险决策。GB/T22080—xxxx规定了组织建立并维护信息安全风险准则的要求，包括：a)风险接受准则；b)信息安全风险评估实施准则。一般而言，设定风险准则宜考虑：——可能影响结果和目标（包括有形和无形）的不确定性的性质和类型；——如何定义、预测和衡量后果和可能性；——与时间相关的因素；——测量方法的一致性；——如何确定风险级别；——如何考虑多种风险的组合和排列；——组织的能力。更多关于风险准则的考虑见附录A。6.4.2风险接受准则在风险评估中，宜使用风险接受准则来确定风险是否可接受。在风险处置中，风险接受准则能用于确定拟定的风险处置是否足以达到可接受的风险级别，或者是否需要进一步的风险处置。组织宜定义风险接受级别，在制定过程中宜考虑：a)信息安全风险接受准则与组织通用风险接受准则之间的一致性；b)识别具有作出风险接受决策权限的管理级别；c)风险接受准则能包括多个阈值，风险接受决策权限能分配给不同的管理级别；d)风险接受准则能仅基于可能性和后果，也能扩展到考虑预期损失和控制成本之间的成本/收益平衡；GB/T31722-XXXX/ISO/IEC2e)不同的风险接受准则能适用于不同类别的风险（例如，可能导致违反法律法规的风险通常不予保留；若接受风险是合同要求的结果，则考虑接受风险）；f)风险接受准则能包括进一步额外处置的要求（例如，如果批准并承诺采取行动措施实现一组选定的控制，以在规定的时间内达到可接受的水平，即使风险水平超过了风险接受准则，也可以在短期内保留风险）；g)风险接受准则宜根据组织愿意追求或保留的风险数量和类型的风险偏好来定义；h)风险接受准则能是绝对的，或是有条件的，这取决于相关环境。制定风险接受准则，宜考虑以下影响因素：——组织目标；——组织机会；——法律法规；——运行活动；——技术约束；——财务约束；——过程；——供应商关系；——人为因素（如隐私相关）。上述影响因素并不详尽。组织宜基于环境考虑影响因素。在实践中，简单的接受准则（是/否）并不总是足够的。在许多情况下，可以在特定的风险级别（可能性和后果的特定组合）上做出是否接受风险的决定。然而，在某些情况下，有必要设置极端后果的接受阈值（无论其可能性如何或极高可能性的阈值（无论后果如何），对组织影响的主要结果来自于其中之一。例如，接受一个导致公司的股票价值消失的罕见事态，或接受由于需要控制频繁且轻微的策略违规而造成资源不断消耗，宜主要考虑基于哪个因素对组织的影响具有主导作用。因此，在理想情况下，风险接受准则宜包括分别考虑可能性和后果，以及管理成本，而不仅仅将风险级别视为可能性和后果的组合。具有激进风险偏好的组织可以设定更高的接受阈值，从而比一个风险偏好较低的组织接受更多的风险。这使组织避免因采用过多的信息安全控制而出现过度控制，从而降低组织实现其目标的能力。风险接受准则可能因风险预期存在的时间而有所不同（例如，风险可能与临时或短期活动相关联）。当信息安全风险管理的环境发生变化时，风险准则宜被评审和必要的更新。示例：一个小型公司最初能有一个激进的风险偏好，但风险接受准则宜由经授权的管理级别批准。6.4.3信息安全风险评估实施准则概述风险评估准则规定了如何根据风险的后果、可能性和风险级别来确定风险严重程度。信息安全风险评估准则宜考虑风险管理活动的适当性。达成上述，宜考虑：a)信息的分级级别；b)信息的数量和集中度；c)使用信息的业务过程的战略价值；d)信息及其相关资产的关键程度；e)可用性、保密性和完整性对运营和业务的重要程度；GB/T31722-XXXX/ISO/IEC270f)相关方（如最高管理层）的期望和看法；g)商誉和声誉损失等负面后果；h)与组织的风险准则保持一致。风险评估准则，或用于定义风险评估准则的正式基准，宜被标准化，以用于组织所有类型的风险评估，这能促进与多项业务领域相关风险的沟通、比较和集合。信息安全风险评估准则主要包括：——后果；——可能性；——风险级别。注：本子章节涉及GB/T22080—xxxx的6.1.后果准则GB/T22080—xxxx关注的是在ISMS范围内，由于信息的保密性、完整性和可用性的保护或损失而造成直接或间接的后果。后果准则的制定和规范，宜根据信息保密性、完整性和可用性的损失，对组织或个人造成的损害、损失或危害程度来确定。在定义后果准则时，宜特别考虑：a)伤亡，或对个人或团队的伤害；b)自由、尊严或隐私权的损失；c)员工和智力资本（技能和专业知识）的损失；d)内部或第三方运行受损（例如，损害业务功能或过程）；e)对计划和完成时限的影响；f)业务和财务价值的损失；g)业务优势或市场份额的损失；h)对公众信任度或声誉的损害；i)违反法律法规或规章制度要求；j)违反合同或服务级别；k)对相关方的不利影响；l)对环境的负面影响，污染。后果准则定义了组织如何对潜在信息安全事态的严重程度进行归类。组织有必要将后果进行分类，并明确定义和描述每类后果。通常，根据组织的内部和外部环境，不同组织的后果准则是不同的。示例1：组织在一个财政年度内，准备核销的最高额度与同期被迫注销清算的最低金额，能通过以货币形式量化组具体环境的范围能被分为若干个后果类别，其数量和分布宜取决于组织风险认知和偏好.货币后果标度通常以对数标度表示，例如，十进制或10的幂次方(例如，100到1000；1到10000等)，但是也能使用更适合组织环境的替代量化方案。由于组织的不同领域或部门起初以不同的方式表示后果，而不是严格使用货币的形式，所以如果这些不同的表达方式可以交叉引用到一个通用的锚定标度，可确保不同领域级别大致相等的后果能相互正确比较。这种方法宜执行跨领域的风险集合。示例2：数据安全性受损以及可能影响个人隐私的情况，可能导致ISMS范围内信息的保密性、完整性或可用性的损失。这也可能导致违反数据保护法律法规。潜在后果的范围从信息损失、信息相注：本子章节涉及GB/T22080—xxxx，6.1.可能性准则确定可能性准则取决于以下方面：GB/T31722-XXXX/ISO/IEC2a)意外或自然事态；b)相关信息或与信息相关的资产遭受威胁的程度；c)组织的脆弱性被利用的程度；d)技术故障；e)人为行为或疏漏。可能性能用概率（在给定的时间范围内事态发生的几率）或用频率（在给定的时间范围内发生的理论平均数）来表示。在沟通时，通常使用频率相关的术语表示可能性，而在执行可能性集合时，只用概率术语表示可能性。可能性准则宜覆盖预期事态可能性的可预测可管理的范围。当超出可行的可管理限制时，通常仅须承认其已超出种种限制，以作出充分的风险管理决策（指定为极端情况）。如果设限的标度太宽，通常会导致过于粗糙的量化，并可能导致评估出现错误。典型案例是当上限范围内的增量幅度非常大时，可能性的值会落在指数标度上限。尽管几乎任何事情都是“可能的”，但宜重点关注与组织环境和其ISMS范围最相关的风险源的可能性。注：本子章节涉及GB/T22080—xxxx的6.1.确定风险级别准则风险级别量化的目的是帮助风险责任人决定是否保留或以其他方式处置风险，并对风险处置优先级进行排序。对特定风险的评估级别宜有助于组织确定解决风险的紧迫程度。根据实际情况，宜考虑固有的风险级别（不考虑任何控制或当前的风险级别（考虑到任何已实施控制的有效性）。组织宜制定风险等级，同时考虑：a)后果准则和可能性准则；b)信息安全事态在战略、战术和运行层面的后果（这能定义为最坏情况或其它术语，只要组织一致的使用同一基准）；c)法律和法规要求以及合同约定的义务；d)超出组织范围的风险，包括对第三方不可预见的影响。风险级别准则对评价已分析的风险是必要的。风险级别准则能是定性的（例如，非常高、高、中、低）或定量的（例如，在给定的时间段内以货币损失预期值、伤亡或市场份额的损失表示）。示例：风险能量化为年度损失预期值，即下一年无论使用定量还是定性的准则，评价标度宜最终锚定为所有相关方能理解的基准标度，风险分析和风险评价宜至少包括对基准标度的定期正式校准，以确保结果的有效性、一致性和可比性。若采用定性方法，任何定性标度的级别都宜清晰可辨，其增量都宜明确定义，每个级别的定性描述宜用客观语言表示，级别不宜重叠。当使用不同的标度时（例如，处理不同业务领域的风险），宜有一个等价关系，以保证结果的可比性。注：本子章节涉及GB/T22080—xxxx的6.1.选择适当的方法一般来说，信息安全风险管理的途径和方法宜与组织管理其他风险的途径和方法相一致。所选择的方法宜文件化。根据GB/T22080—xxxx的6.1.2b)，要求ISMS范围内的组织确保重复的信息安全风险评估将产生一致、有效和可比较的结果。这意味着所选的方法宜确保结果具有以下性质。——一致性：在同一环境下，不同人或同一（组）人在不同时间评估相同的风险宜产生相似的结果。——可比性：宜定义风险评估准则，以确保对具有相同级别的不同风险进行评估时产生可比较的结7.1概述a)风险识别，是发现、辨别和描述风险的过程(风险识别的更多细节见7.2);态发生的可能性、该事态产生后果的可能性以及后果严重程度的考虑(c)风险评价，是将风险分析结果与风险准则进行比较以确险评价的更多细节见7.4)。风险评估过程宜基于充分详细设计的方法(见6.5)和工具，以尽可能产生一致的、有效的和可重GB/T22080—xxxx并没有强制要触发：风险责任人、相关方、和/或专家发现，或找出新的或发生改变的事态，或可GB/T31722-XXXX/ISO/IEC2b)基于资产的方法：识别由资产、威胁和脆弱性描述的运行场景。基于事态的方法，其基本概念是通过对事态和后果的评价来识别和评估风险。事态和后果一般能通过发现最高管理层、风险责任人的关切点以及在确定组织环境时所识别的要求(GB/T22080—xxxx的第4章）来确定。访谈最高管理层和组织中的业务过程负责人，能帮助识别风险相关的事态和后果，以及风险责任人。基于事态的方法能建立高级别或战略场景，不必花费大量时间进行详细层级的资产识别。这使得组织的风险处置聚焦于重大风险。使用这种方法进行事态评价能利用那些风险长期不变的历史数据，并允许相关方参与以达到其目标。但是，当历史数据不可用或不可靠时，基于专家知识和经验的建议或对风险源的调查，能有助于风险评价。基于资产的方法，其基本概念是通过对资产、威胁和脆弱性的检查来识别和评估风险。资产是对组织有价值的任何东西，因此需要保护。识别资产时宜将构成信息系统的、需要保护的活动、过程和信息考虑在内。根据资产的类型、优先级、依赖关系及与风险源和组织相关方的相互影响，可识别主要资产和支撑性资产。威胁利用资产的脆弱性损害相应信息的保密性、完整性和/或可用性。如果能穷举ISMS范围内所有资产、威胁和脆弱性的有效组合，那么理论上能识别所有的风险。为进一步进行风险评估，宜编制与信息和信息处理设施相关的资产清单。基于资产的方法能针对特定资产的威胁和脆弱性，并允许组织在详细层级上确定具体的风险处置。关于两种方法的更多信息，见附录A。原则上，这两种方法只在启动识别的层级上存在差异。两种方法都能描述相同的风险场景，例如信息资产位于详细级，而业务暴露位于整体级。使用基于事态的评估来识别起作用的风险源，通常需要从场景的整体级向下深入到详细级，而基于资产的评估通常从资产向上延伸到场景，以提供后果累积的可见性。风险识别是十分关键的，因为在此阶段未被识别出的风险将不会包含在后续的分析中。风险识别宜考虑风险，无论其来源是否在组织控制下，甚至没有明确的特定来源。尤其在评估复杂风险场景时，宜进行迭代式的风险评估。首轮评估宜侧重于高层级的观察，后续多轮宜关注更多的详细级，直到识别出风险的根本原因。任何其他风险识别方法都能被运用，只要确保产生一致的、有效的和可比较的结果，满足GB/T22080—xxxx的6.1.2b)的要求。信息安全风险管理不宜受限于如何结构化、分组、整合、拆分或描述风险的主观性或限制性的观点。风险可能表现为重叠的，或者是其他风险的子集或特定实例。然而，出于风险处置的目的，宜对个别风险的控制与更广泛的风险或整合风险分开考虑和确定。示例1：2个风险出现重叠的例子1）办公总部存在火灾风险2）火灾风险影响在办公总部财务部门以及其具体风险实例1）发生数据丢失事件2）发生个人数据丢失事件。第二个风险是第一个风险的特定实例，它相对于第一个实例很可能具有不同属除非风险在所处的组织环境层面彼此具有一定关联性，否则不宜进行风险整合。在规划处置方案时，有必要将为总体风险管理预算而整合的风险分开考虑，可能需要不同的控制来管理它们。为了评估组织的总体风险级别，几个独立风险事态能整合为一项整体风险，但是由于这些事态需要不同的控制来管理风险，因此为进行风险处置，宜分别识别和考虑这些风险。风险（可能性和后果的组合）不能总是直接整合。7.2.2风险责任人识别GB/T31722-XXXX/ISO/IEC270输入：已识别的风险列表。动作：风险宜与风险责任人关联。触发：存在下面情况时有必要识别风险责任人：——从未进行过风险责任人识别工作；——风险所在的相关业务领域人员发生变更。输出：相关风险的风险责任人列表。实施指导：风险责任人可包括最高管理层、安全委员会、流程责任人、职能责任人、部门经理和资产责任人。组织宜使用组织层面的风险评估过程（如果已建立）来识别风险责任人，否则宜定义识别风险责任人的准则。这些准则宜考虑风险责任人：——对风险负责且有权管理这些风险，即他们宜在组织中有职位允许其行使权限；——理解当前的事项且知情决策（例如，关于如何处置风险）。风险级别及风险所属的资产能作为识别风险责任人的基础。该分配宜作为风险评估过程的一部分进行。注：本子章节涉及GB/T22080—xxxx的6.1.信息安全风险分析7.3.1概述风险分析的目的是确定风险级别。GB/T24353—2022在GB/T22080中作为一个通用模型被参考。GB/T22080—xxxx的6.1.2要求对于每个已识别的风险进行风险分析，通过评估其导致的后果及其发生的可能性来确定风险级别。基于风险发生的后果及可能性的风险分析技术有：a)定性分析，使用限定属性的标度(如高、中、低）；b)定量分析，使用数值的标度(如货币成本、发生的频率或概率）；c)半定量分析，使用具有指定值的定性标度。风险分析宜针对那些在管理有效时能提高组织实现其目标可能性的风险和控制。风险评估很容易花费大量的时间，尤其是评估风险的可能性及后果。为了对风险管理进行有效的决策，对风险的可能性及后果进行初步和简要的评估即可。7.3.2潜在后果评估输入：已识别的相关事态或风险场景的列表，包括对风险源、业务过程、业务目标和后果准则的识别。此外，还包括所有现有控制列表，以及控制的有效性、实现和使用状况。动作：宜识别和评估因未能充分保护信息的保密性、完整性或可用性而造成的后果。触发：以下情况有必要进行评估:——从未进行过相关评估工作；——“风险识别”产生的列表发生变更；——风险责任人或相关方已经变更他们希望指定后果的（计量）单位；或——已确定的影响后果的范围或环境发生变更。输出：与风险场景相关的潜在后果列表，这些后果与资产或事态相关，取决于所用的方法。实施指导：信息的安全未能得到充分保护，将导致信息的保密性、完整性或可用性受到损失。信息的保密性、完整性或可用性受到损失会对组织及目标产生进一步后果。通过考虑相关信息的保密性、完整性或可用性受到损失时可能发生的情况，从信息安全后果开始自下而上进行后果分析。通常情况下，风险责任人能预估事态的后果。宜考虑以下因素：GB/T31722-XXXX/ISO/IEC2——预估（或者凭经验预测）由于中断或干扰运行的事态造成的损失（包括时间或数据——预估或感知后果严重程度（如用货币来表示）；——恢复成本，这取决于恢复由组织内部（风险责任人团队）完成，还是需要引入外部实体。7.3.3可能性评估输入：已识别的相关事态或风险场景的列表，包括风险源、业务过程、业务目标和可能性准则。此外，还包括所有现有控制及其有效性、实现和使用状况的列表。动作：宜利用已建立的可能性准则来评估和阐述可能场景或实际场景发生的可能性。触发：与后果评估一样，在确定风险级别时，可能性评估是风险评估过程中的一个关键活动。在以下情况下，有必要进行可能性评估：——从未进行过相关评估；——已确定的影响可能性的范围或环境发生变更；——已实现的控制中发现脆弱性；——控制有效性测试/审计导致非预期的结果；——威胁环境发现了变更（如新的威胁主体/来源）。输出：事态或风险场景列表，辅以这些事态或风险场景发生的可能性。实施指导：完成风险场景识别后，需使用定性或定量分析技术对每个风险场景发生的可能性及其发生后果进行分析。评估可能性并非易事，宜采用不同的方式表示。这需要考虑风险源出现的频率或者它们（如脆弱性）被利用的难易程度。包括：——风险源可能性的经验和适用的统计数据；——故意的风险源：动机[如攻击的可行性（成本/收益）]和能力（如潜在攻击者的技能水平）的程度会随着时间而改变，如犯罪集团、恐怖组织或外国情报组织等潜在攻击者可用的资源和影响，以及信息对潜在攻击者的吸引力和潜在攻击者对脆弱性的了解程度；——意外的风险源：地理因素（如靠近危险的设施或活动），极端天气、火山活动、地震、洪水、海啸等自然灾害的可能性，以及可能带来人为错误和设备故障的因素；——已知的弱点和任何补偿性控制，无论是单独的还是整合的；——现有控制及其降低已知弱点的有效性。可能性评估本质上是不确定的，不仅因为不能完全了解尚未发生的评估对象，还因为可能性是一个统计测度，并不能直接代表某个事态。评估不确定性的三个基本来源是：——人为不确定性，源于评估者在具有多变性启发式决策中形成的判断；——方法不确定性，源于不可避免使用简化了的事态建模工具；——系统性的不确定性，与预期事态自身有关，源于知识不足（尤其是当证据有限或风险源随时间而变化时）。为提高可能性评估的可靠性，组织宜考虑使用：a)团队评估而非个人评估；b)外部来源，例如信息安全违规报告；c)与组织方法相适应的区间和分辨率的标度；d)明确的频次，如“一年一次”而不是“很少发生”。当评估事态发生的可能性时，重要的是要识别独立事态和关联事态的区别。事态间相互依赖的可能性取决于它们之间的关系（例如，如果第一个事态发生，则第二个事态可能是不可避免的所以无须分别评估它们的可能性。相互独立事态的可能性对其造成后果的可能性是必要因素。GB/T31722-XXXX/ISO/IEC270为了避免不必要的评估复杂性，重要的是识别风险场景中的事态之间的关联关系，并要首先评估相互独立事态发生的可能性。信息安全事态产生业务后果的可能性，通常取决于几个潜在的、较低级别的、起促成作用的事态及其后果。从整合独立评估的起促进作用的低级别事态的可能性出发，比试图在单个高级别事态评估中评价业务后果的可能性更为有效。注：本子章节涉及GB/T22080—xxxx的.4风险级别确定输入：风险场景的列表，包括与资产或事态相关的后果及可能性（定量或定性）。动作：风险级别宜结合所有相关风险场景的可能性评估及后果评估来确定。触发：如需评价信息安全风险，则须确定风险级别。输出：已赋予风险级别值的风险列表。实施指导：风险级别能通过多种方式来确定。它通常是确定为所有相关风险场景的可能性评估及后果评估的组合。可选择的计算方式包括资产价值以及可能性和后果。此外，计算方式不一定是线性的，例如它可能是可能性的平方与后果相结合。在任何情况下风险级别都宜使用中建立的准则来确定。注：本子章节涉及GB/T22080—xxxx的6.1.信息安全风险评价7.4.1风险分析结果与风险准则比较输入：风险准则列表和已赋予风险级别值的风险列表。动作：风险级别宜与风险评价准则相比较，特别是与风险接受准则进行比较。触发：如果排序信息安全风险处置优先级，有必要比较风险分析结果与风险准则。输出：有关风险管理的额外行动的决策建议列表。实施指导：一旦风险被识别，且对其可能性及后果的严重程度进行了赋值，组织宜利用风险接受准则来决定风险是否能接受。如果风险不能接受，则宜进行风险处置优先级排序。评价风险时，组织宜将已评估的风险与建立评估环境时定义的风险准则进行比较。风险评价决策宜基于已评估风险与已定义接受准则的比较，理想情况下考虑风险评估的可信度。在某些情况下，如频繁发生且后果相对较弱的事态，考虑其在某些目标时间段内的累积效应而不是单独考虑每个事态的风险可能是有益的，因为这样能真实体现总体风险状况。在确定需要处置的风险和不需要处置的风险之间没有明确的界限。在特定情况下，使用单一的可接受风险级别区分可接受和不可接受的风险，并不总是合适的。在某些情况下，通过纳入额外参数（如潜在控制的成本和有效性），在准则中增加灵活性要素，这可能更有效。风险级别可基于风险责任人、业务专家和技术专家的共识进行验证。重要的是，风险责任人根据目标评估结果对其所负责的风险有深入的理解。因此，宜调查已确定的风险级别和风险责任人认为的风险级别存在的任何差异，以确定哪一个更接近实际情况。7.4.2风险处置优先级排序输入：风险与风险准则的比较结果列表。动作：宜考虑已确定的风险级别，对列表中的风险进行处置优先级排序。触发：如果要处置信息安全风险，有必要对已分析的风险进行处置优先级排序。输出：风险优先级列表，包括导致这些风险的风险场景。实施指导：风险评价利用风险分析获得的对风险的理解，为决定下一步采取的措施提出建议。这些建议宜包括：—是否需要风险处置；—根据评估的风险级别确定的风险处置优先顺序。用于风险优先级排序的风险准则宜考虑组织的目标、合同要求和法律法规以及相关方的意见。在风险评价活动中对风险进行优先级排序主要基于风险接受准则。8信息安全风险处置过程信息安全风险处置的输入是风险评估过程的结果，即基于风险准则而得到的风险处置优先级排序的风险集合。该过程的输出是依据风险处置计划[见GB/T22080—xxxx的6.1.3e]]得出的一套必要的信息安全控制(见GB/T22080—xxxx的6.1.3b)],这些控制将被部署或相互增强。通过上述方式，风险处置计划的有效性是为了改变组织面临的信息安全风险，以使其达到组织所能接受的准则。8.2选择适合的信息安全风险处置选项输入：风险优先级列表，包括导致这些风险的事态或风险场景。动作：宜选择风险处置的选项。触发：如果无风险处置计划或计划不完整，则有必要选择适合的信息安全风险处置选项。输出：风险优先级列表，包括已选择的风险处置选项。实施指导：风险处置的选项包括：—风险规避，通过决定不开始或不继续会引起风险的活动；——风险改变，通过改变事态发生的可能性、后果，或改变后果的严重程度；—风险保留，通过知情选择；—风险分担，通过与其他相关方分担内部或外部责任(例如，通过保险分担后果);在风险分担的情况下，至少需要一项控制来改变可能性或后果，但组织要将实施这项控制的责任委托给另一方。选择风险处置选项(无论是单独的还是在其他控制环境下)宜基于风险评估的结果、实施这些选项的预期支出和预期收益。风险处置宜根据所定义的风险级别、时间限制和必要的实施顺序，以及7.4中确定的风险评价输出进行优先级排序。在选择选项时，宜考虑受影响方对特定风险的理解，以及与其沟通该风险的最适当方式。8.3确定实现信息安全风险处置选项所需的所有控制输入：风险优先级列表，包括已选择的风险处置选项。GB/T31722-XXXX/ISO/IEC270动作：从适当的来源选择控制集，从已选的控制集中基于已选风险处置选项（如风险改变、风险保留、风险规避和风险分担）确定处置风险所需的所有控制。触发：ISMS符合性；管理信息安全风险。输出：所有必要的控制。实施指导：宜特别关注必要控制的确定。每项控制宜通过询问以下问题来检查以确定是否必要：——这项控制对风险可能性或后果的影响；——这项控制以何种方式保持风险级别。只有对风险的影响不是微乎其微的控制才宜被选定为“必要的”。对评估为需要处置的每项风险，宜采用一项或多项控制。控制集有多种来源。可参见GB/T22080—xxxx的附录A、具体行业实践指南（例如，ISO/IEC27其他国家、地区、行业控制集。组织也可确定一个或多个自定义控制（见GB/T31496—2023)。如果已定义自定义控制，则该控制的描述宜明确和客观地描述该控制是什么以及如何运行。在适当和适用的情况下，该描述通常包括以下方面：——是否是文件化的控制；——谁是控制责任人；——如何被监视；——如何被证明；——任何例外；——控制运行的频率；——控制的容差；——如果作用不明显，说明该控制存在的原因。如果控制超出容差，则该控制不能有效地管理已识别的风险。监视，每周向首席信息官发送绩效报告。”如果自定义控制也用于支持组织的控制保证报告，那么这种详细的控制描述方法是有用的。然而更重要的是，控制的描述宜对组织人员有意义，并帮助他们在管理这些控制和相关风险时做出决策。已确定的控制能包括新的尚未实施的控制，或包括组织正使用的控制。然而，已经运行的控制不宜自动纳入风险评估中，因为：——该控制对管理一个或多个信息安全风险是不必要的；——该控制能在某种程度上帮助管理一个或多个信息安全风险，但不足够有效，从而不能纳入风险评估或由ISMS管理；——该控制当前正在运行的原因与信息安全无关（如质量、效率、有效性或符合性）；——该控制当前正在运行，但从信息安全的角度来看可以被移除，因为其没有产生足够影响以证明其可作为必要的控制而继续存在。如果控制用于除信息安全风险管理以外的其他目的，宜注意确保该控制的管理能实现信息安全目标和非信息安全目标。从现有控制集（例如，GB/T22080—xxxx的附录A或具体行业控制列表）确定控制时，控制的描述宜与管理风险所需的内容相匹配，并准确反映控制是什么或宜是什么。如果整体上是使用现有控制集（例如，GB/T22080—xxxx的附录A或具体行业控制列表），但控制集未包含一个准确描述的必要控制，则宜考虑定义一个自定义控制。控制类型可分为预防、检测和纠正。a)预防控制：旨在防止可能导致一个或多个后果的信息安全事态发生的控制。GB/T31722-XXXX/ISO/IEC2b)检测控制：旨在检测信息安全事态发生的控制。c)纠正控制：旨在限制信息安全事态后果的控制。控制类型描述了控制是否已经实施或打算实施，以预防或检测事态或对事态后果进行响应。将控制分为预防、检测和纠正的作用在其使用，以确保风险处置计划的建立对控制失效具有弹性。预防、检测和纠正控制的合理组合可以是：——如果预防控制失效，宜使用检测控制以降低风险；——如果检测控制失效，宜使用纠正控制以降低风险；——预防控制宜降低一定要使用纠正控制的可能性。在使用控制时，组织宜首先确定是否有可能检测到事态的发生。如果可行的话，宜实施检测控制。如果不能检测到事态，检测控制可能就无效，则无法判断预防控制是否起作用。示例4：如果不确定计算机是否已经成为“僵尸网络”一部分，则无法知道用于阻止其成为僵检测控制能在适当的情况下发挥作用，但它们仍可能是无效的。一般来说，在能绕过检测控制或未根据通知采取适宜的措施时，检测控制最终是无效的。接下来宜依赖纠正控制。如果检测控制失效，则可能导致一个或多个非预期后果。实施纠正控制能有助于限制这些后果。尽管纠正控制在后果发生后就会生效，但通常需要在事态发生前就做好部署。示例6：硬盘加密无法防止笔记本电脑被盗或随后尝试提取数据。但是，控制的分类不是绝对的，而取决于描述控制使用时的环境。示例7：备份不能防止发生可能导致数据丢失的事态（例如，磁盘头碰损或笔记本电脑丢失），但它确实有助于减轻后果。因此，一些组织认为这是纠正控制，而不是预防控制。同样，加密并不能确定应对风险控制的顺序依赖于各种因素，能使用多种技术。由各个风险责任人来决定控制的投入成本和风险发生时预估后果之间的平衡。对现有控制的识别能确定这些控制是否超出当前需求。在删除冗余或不必要的控制（特别是那些维护成本较高的控制）之前宜进行成本效益分析。由于控制能相互影响，删除冗余控制可能会降低整体的安全性。除非是管理一个或多个已识别的信息安全风险的必要控制，否则不宜包括在风险处置中。控制宜对已识别的信息安全风险的后果或可能性产生影响。如果使用控制的原因与信息安全无关，则不宜纳入风险处置。宜考虑已实施但有已知弱点的控制。如果对有弱点的控制所管理的所有风险经评估均在接受准则范围内，则无需改进控制。即使控制没有完全有效地运行，但不总是需要改进以使其完全有效。不宜假定所有的控制都一定能完全有效地运行，组织才能够成功地管理其风险。可指定每个单独控制的对失效的容差，低于该限度，可认为控制不足以有效地管理已识别的风险。只要控制在容差内运行，就不需要任何改进。注：本子章节涉及GB/T22080—xxxx的比较确定的控制与GB/T22080—xxxx附录A中的控制输入：所有必要的控制（见8.3)。动作：将所有必要的控制与GB/T22080—xxxx的附录A中列出的控制进行比较。触发：如果制定风险处置计划，则有必要识别任何缺失的控制。输出：适用于风险处置的所有控制。GB/T22080—xxxx的6.1.3c),要求组织将其确定实施风险处置选项所需的控制与GB/T22080—xxxx的附录A所列控制进行比较。其目的是作为安全检查来验证风险输入：适用于风险处置的所有控制(见8.4)。根据GB/T22080—xxxx的6.本活动的目的是制定计划，以处置风险优先级列表中的具体风险集(见第7章)。风险处置计划是一种改变风险的计划，以使其符合组织的风险接受准则(见6.4.2)。在风险处置的环境下，“计划”GB/T31722-XXXX/ISO/IEC2不仅识别必要的控制，还需要描述控制彼此之间及与环境如何相互作用以改变风险。在实践中，两者都能使用。一旦控制到位，项目计划除了作为历史记录以外不再有其它利用价值，而设计计划仍然有用。每个需要处置的风险都宜在一个风险处置计划中得到处置。组织能选择制定多个风险处置计划并一同实施以满足风险处置所有要求。这些计划可以按照信息所处位置（例如，一个计划用于数据中心，另一个计划用于移动计算等）、资产（例如，不同计划用于不同资产类别）或者事态（例如，风险评估使用基于事态的方法）进行组织。在制定风险处置计划时，组织宜考虑以下事项：——与风险级别和处置紧急程度相关的优先级；——不同类型的控制（如预防、检测和纠正）或其组合是否适用；——是否需要等待同一资产上的某项控制实现后才能实施下一项控制；——控制实施的时间和控制完全运行并有效的时间之间是否存在延迟。对于每个已处置的风险，风险处置计划宜包括以下信息：——选择该处置选项的理由，包括预期获得的收益；——负责批准和实施计划的人；——拟采取的措施；——包含意外事件在内的所需资源；——绩效指标；——约束；——所需的报告和监视；——措施期望的实施时间和完成时间；——实现状态。风险处置计划中的措施宜根据风险级别和处置紧急程度进行优先级排序。风险级别越高，并在某些情况下风险发生的频率越高，控制则越早实现。对于风险处置计划中所列的每个风险，宜跟踪详细的实施信息，包括且不限于：——风险责任人和实施负责人的姓名；——实施日期或时间表；——为测试实施结果而计划开展的控制活动；——实现状态；——成本级别（投资、运行）。注：本子章节涉及GB/T22080—xxxx的8.6.2风险责任人的批准输入：风险处置计划。动作：风险责任人批准风险处置计划。触发：风险处置计划需要批准。输出：经批准的风险处置计划。实施指导：信息安全风险处置计划一经制定，宜得到风险责任人的批准。风险责任人还宜决定是否接受残余的信息安全风险。该决定宜基于已确定的风险接受准则。风险责任人宜理解风险评估结果、风险处置计划和残余风险，以便他们能正确履责。注：本子章节涉及GB/T22080—xxxx的8.6.3接受残余信息安全风险GB/T31722-XXXX/ISO/IEC270输入：已批准的风险处置计划和风险接受准则。动作：确定残余风险是否可接受。触发：组织决定是否保留残余风险。输出：可接受的残余风险。实施指导：为了确定残余风险，风险处置计划宜纳入到对残余风险可能性和后果的后续评估中。宜根据控制是否能降低可能性或后果，或者二者都可降低，以及风险是否被处置到残余水平，来考虑风险处置计划中所建议的控制及其有效性。然后，由风险责任人考虑残余风险的级别，以确定残余风险是否可接受。风险处置计划宜描述如何处理已评估的风险，以使其满足风险接受准则。某些情况下，残余风险级别并不总是符合风险接受准则，因为所应用的准则没有考虑到当时的情况。示例：需要保留风险可能存在争议，因为风险能带来重要的商业机然而，并不总是能够及时修订风险接受准则。在这种情况下，风险责任人能保留那些不符合现有接受准则的风险。如果有必要，风险责任人宜明确解释风险，并包括该决定的合理性说明。在最终决定接受风险之前，要有一个获得各方认可的风险处置的过程。重要的是风险责任人要审查和批准所提出的风险处置计划和由此产生的残余风险，并记录与此类批准相关的任何条件。根据风险评估过程和风险接受准则，可能要求比风险责任人拥有更高权限的管理者来同意接受风险。实施风险处置计划需要一定时间。如果有在可接受时间内降低风险的可落实的计划，风险准则允许风险级别可以在给定的程度上超过期望的阈值。风险接受决策要考虑风险处置计划的时间跨度，以及风险处置实施进度是否与计划保持一致。一些风险随时间发生变化（无论这种变化是否是因为风险处置计划的实施）。风险接受准则考虑这点并给出风险接受阈值，该阈值取决于组织暴露于已评估风险的时长。注：本子章节涉及GB/T22080—xxxx的9运行执行信息安全风险评估过程输入：有关信息安全风险评估过程的文件，包括风险评估以及风险接受准则。动作：宜根据第7章执行风险评估过程。触发：组织按计划的时间间隔或根据事态评估风险的需要。输出：被评价的风险。实施指导：GB/T22080—xxxx的6.1中定义和应用的信息安全风险评估过程宜整合到组织运行中，并宜在计划的时间间隔或提出或发生重大变更时执行。信息安全风险评估过程宜考虑GB/T22080—xxxx的6.1.2a)中建立的准则。执行风险评估的时间间隔宜与ISMS相适应。当ISMS(或其环境)发生重大变化或威胁环境发生变化(例如，新型信息安全攻击)时，组织宜确定这种变化是否需要进行额外的信息安全风险评估。在制定例行风险评估计划时，组织宜考虑适用于其通用的业务过程和相关预算周期的任何日程。评估之前，对其有效性进行评估。在这种情况下，宜对风险评估活动作出如下安排：a)及时提出风险处置建议，以申请资金；b)根据预算分配结果进行重新评估；c)在采购活动和建议得到实施后，再进行下次例行评估。9.2执行信息安全风险处置过程输入：被评价的风险。动作：风险处置过程宜按照第8章执行。触发：组织按计划的时间间隔或基于事态来处置风险的需要。输出：保留或接受的残余风险。实施指导：GB/T22080—xxxx的8.3规定了组织实施其风险处置计划的要求。8.6中包含的考虑因素也与本条款有关。输入：关于组织及其内部和外部环境的信息。动作：宜考虑所有相关数据，以识别并描述影响信息安全风险管理和相关方要求的内部和外部事项。触发：GB/T22080—xxxx规定的建立信息安全目标的信息要求。输出：影响信息安全风险管理的风险相关内部和外部事项。实施指导：组织宜对可能影响ISMS的重要事项(无论该事项是积极的或是消极的)有着高层(例如，战略层)的理解。组织宜进一步了解与其目的相关的并影响其实现ISMS预期结果能力的内部和外部事项。预期结果宜通过应用风险管理过程、理解哪些风险得到充分管理，来确保信息的保密性、完整性和可用性。为了可靠地识别风险，组织宜足够详细地理解自身的运行情况。这意味着组织宜收集与组织内部和外部环境、相关方及其要求有关的信息(见GB/T22080—xxxx的4.1和4.2)。组织在尝试评估其信息安全风险或任何其他可能影响ISMS预期结果的风险之前宜收集这些信息(见GB/T22080—xxxx的6.1.1)。组织宜考虑所有内部和外部风险源。组织对于其对立方的理解要高度结合其利益。在组织的信息安全风险评估中，宜考虑不完全包含在ISMS范围内的服务或活动的接口。如何考虑影响信息安全的其他相关因素取决于组织所选的风险识别和分析方法。组织的信息安全目标(见GB/T22080—xxxx的6.2)能限制风险接受准则(例如，风险的接受级别是由不同业务活动有关的潜在回报决定的)。此外，信息安全方针能限制风险处置选项(例如，某些风险处置选项可以被该方针排除)。10.2领导和承诺输入：需要批准或认可的信息安全风险评估结果或处置结果的信息。动作：适当级别的管理层宜考虑与信息安全风险相关的结果，以决定或批准进一步的措施。触发：GB/T22080—xxxx要求适当级别的管理层参与所有与信息安全风险相关的活动。输出：与信息安全风险相关的决策或认可。实施指导：最高管理层负责管理风险，并宜领导和推动风险评估，包括：GB/T31722-XXXX/ISO/IEC270——确保分配必要的资源来管理风险；——在组织的适当层级内分配与风险管理相关的权限、职责和责任；——与适宜的相关方进行沟通。沟通和咨询输入：通过风险管理过程识别的风险，及其原因、后果和可能性的信息。动作：有关风险及其原因、后果、可能性和所采取控制的信息宜与外部和内部相关方进行沟通，或从外部和内部相关方处获取。触发：GB/T22080—xxxx要求的此类沟通。输出：相关方对组织的信息安全风险管理过程和结果的理解和持续了解。实施指导：沟通和咨询活动旨在通过与风险责任人和其他相关方交换和（或）分享风险信息的方式，就如何管理风险达成一致。这些信息包括但不限于风险的存在、性质、形式、可能性、后果、重要性、处置和接受程度。GB/T22080—xxxx的6.1.2c)2)，要求识别信息安全风险责任人。风险责任可能会被故意混淆或隐藏。即使可以识别风险责任人，他们可能不愿承认对其承担的风险负责，让他们参与风险管理过程可能也很困难。宜有一个已定义的沟通规程，来告知风险责任人其风险责任。GB/T22080—xxxx的6.1.3f)，要求风险责任人批准风险处置计划，并决定是否接受残余风险。风险责任人与负责实施ISMS的工作人员之间的沟通是一项重要的活动。宜就如何通过与风险责任人以及其他相关方和决策者交换和/或分享风险信息来管理风险达成一致。这些信息包括但不限于风险的存在、性质、形式、可能性、重要性、风险的处理和接受程度。沟通宜是双向的。根据风险的性质和敏感性，可能需要将风险、及其评估和处置的有关信息限制在“按需知晓”的范围内，只提供给那些负责识别、评估和处置风险的人员。风险沟通宜按照“按需知晓”的原则进行控制，考虑不同相关方所要求的详细程度，与风险责任人或潜在责任人进行协商，以避免公开更敏感的风险及其相关的已知弱点。由于有关的相关方对风险或正在讨论的事项，在假设、概念、需求、事项和关注方面的差异，各方对风险的看法可能会有所不同。相关方可能根据其对风险的感知来判断风险的接受程度，这对于确保相关方对风险和收益的看法能够被识别和文件化，并清楚地理解和解决根本原因尤为重要。有关风险的沟通和咨询能提升相关方对当前事项的参与度，并使相关方对决策和结果负责。随着准则的制定、风险评估方法的选择，与相关方的沟通和咨询也能提高相关方对其责任的理解。相关方质疑其帮助设计过程的结果可能性较小。因此，他们接受结果和支持措施计划的可能性通常会增加。如果相关方是管理者，则能做出实现风险管理目标和提供必要资源的承诺。宜进行风险沟通，以便：——为组织风险管理的结果提供保证；——收集风险信息；——分享风险评估结果，提出风险处置计划；——避免或减少由于风险责任人和相关方之间缺乏相互理解而导致信息安全违规的发生及后果；——支持风险责任人；——获取新的信息安全知识；——与其他方协调并规划响应措施，以减少任何事件的后果；——赋予风险责任人和具有合法风险利益的其他各方责任感；——提高意识。组织宜为正常运行和紧急情况制定风险沟通计划，宜持续进行风险沟通和咨询活动。GB/T31722-XXXX/ISO/IEC2主要风险责任人和有关相关方之间的协调可以通过成立委员会来实现，该委员会可以讨论风险、风险的优先级、适当的处置以及接受情况。可自愿与外部第三方开展风险沟通，以实现更好的风险管理、响应协调或意识，在某些情况下，监管机构或业务合作伙伴也可能要求进行风险沟通。与组织内适当的公共关系或沟通部门进行合作，以协调与风险沟通相关的所有任务是重要的。这在触发危机沟通时至关重要，如响应特定事件。文件化信息10.4.1概述GB/T22080—xxxx规定要求组织保留有关风险评估过程（见GB/T22080—xxxx的6.1.2)和结果（见GB/T22080—xxxx的8.2)、风险处置过程（见GB/T22080—xxxx的6.1.3）和结果（GB/T22080—xxxx的8.3）的文件化信息。10.4.2过程的文件化信息输入：组织根据第7章和第8章所定义的信息安全风险评估和处置过程的知识。动作：有关信息安全风险评估和处置过程的信息宜被文件化并保留。触发：GB/T22080—xxxx要求关于信息安全风险评估和处置过程的文件化信息。输出：相关方（例如，认证机构）所要求或组织确定的，为证实信息安全风险评估过程或信息安全风险处置过程的有效性所必需的文件化信息。实施指导：有关信息安全风险评估过程的文件化信息宜包括：a)风险准则（包括风险接受准则和执行信息安全风险评估的准则）；b)对结果的一致性、有效性和可比性的推理；c)风险识别方法的描述（包括风险责任人的识别）；d)对信息安全风险分析方法的描述（包括对潜在后果、实际发生可能性和由此产生的风险级别的评价）；e)对结果与风险准则的比较方法和风险处置中的风险优先级排序方法的描述。有关信息安全风险处置过程的文件化信息宜包含以下描述：——选择适当的信息安全风险处置选项的方法；——确定必要控制的方法；——如何使用GB/T22080—xxxx的附录A，来确定必要的控制没有被不经意间忽略；——如何产生风险处置计划；——如何获得风险责任人的批准。10.4.3结果的文件化信息输入：信息安全风险评估和处置结果。动作：宜记录和保留有关信息安全风险评估和处置结果的信息。触发：GB/T22080—xxxx要求关于信息安全风险评估和处置结果的文件化信息。输出：关于信息安全风险评估和处置结果的文件化信息。实施指导：GB/T31722-XXXX/ISO/IEC270由于组织需要按计划的时间间隔，或当重大变更提出或发生时进行风险评估，因此至少宜有一个可作为证据的风险评估实施时间安排，且按照该时间安排进行风险评估。如果提出变更或已经发生变更，则宜有证据表明已实施了相关风险评估。此外，组织宜解释为什么变更是重要的或不重要的。有关信息安全风险评估结果的文件化信息宜包括：a)已识别的风险、其后果和可能性；b)风险责任人；c)应用风险接受准则的结果；d)风险处置的优先级。还建议记录风险决策的理由，以便从个别案例的错误中学习并促进持续改进。有关信息安全风险处置结果的文件化信息宜包括：——必要控制的识别；——在适当和可用的情况下，表明这些必要的控制可改变风险来满足组织风险接受准则的证据。监视和评审10.5.1概述组织的监视过程（见GB/T22080—xxxx的9.1）宜包括风险评估和风险处置过程的所有方面，其目a)确保风险处置在设计和运行上都是有效、高效和经济的；b)获取改进后续风险评估的信息；c)分析事件（包括未遂事件）、变化、趋势、成功和失败，并从中吸取教训；d)监测内部和外部环境的变化，包括风险准则和风险本身的变化，这可能需要修订风险处置和优先级；e)识别新出现的风险。所保留的、源自风险管理活动的风险场景可以转换为监视场景，以确保有效的监视过程。A.2.7中给出了有关监视场景的更多详细信息。注：本子章节涉及GB/T22080—10.5.2监视和评审影响风险的因素输入：从风险管理活动中获得的所有风险信息。动作：宜监视和评审风险及其因素（即资产价值、后果、威胁、脆弱性、发生的可能性），以便早期识别出组织内部的任何变化，并维护风险整体状况的概述。触发：评审组织的方针和所发现的、当前运行或威胁环境的任何变化。输出：将风险管理与组织的业务目标和风险接受准则持续保持一致。实施指导：GB/T22080—xxxx的9.1要求组织评价其信息安全绩效和ISMS有效性。根据该要求，组织宜将其风险处置计划作为绩效评价的主要依据。为此，组织宜首先定义一个或多个信息需求，例如，最高管理层希望了解组织抵御威胁的能力。然后，将其作为顶层规范，组织宜确定所需的测度以及如何组合这些测度，以满足信息需求。风险不是静态的。事件场景、资产价值、威胁、脆弱性、可能性和后果可能会在没有任何迹象的情况下突然发生变化。宜进行持续监视，以发现这些变化。这可借助于能够提供有关新威胁或脆弱性信息的外部服务。组织宜确保持续监视相关因素，例如：a)新的风险源，包括新报告的信息技术脆弱性；b)风险管理范围内的新资产；c)资产价值的必要更改，例如，由于业务要求发生变化；GB/T31722-XXXX/ISO/IEC2d)已识别的脆弱性，确定其是否暴露于新的或重现的威胁之中；e)现有技术或新技术使用模式的变化，这可能会带来新的攻击机会；f)法律法规的变更；g)风险偏好的变化以及对现在可接受和不再可接受的认知的变化；h)发生在组织内部和外部的信息安全事件。新的风险源、可能性的变化或后果的变化可能加大先前评估的风险。对低风险和保留风险的评审宜分别检查每项风险，并将所有此类风险作为一个整体进行检查，以评估其潜在的累积后果。如果风险不再属于低风险或可接受的风险类别，则宜使用8.2中的一个或多个选项进行处理。事件发生的可能性及其相应后果的影响因素可能会发生变化，处置选项的适用性或成本的影响因素也会发生变化。影响组织的重大变化，宜作为实施更详细评审的理由。宜定期重复实施风险监视活动，并宜定期评审所选的风险处置选项。新的威胁、新的脆弱性、可能性的变化或后果的变化，可能会加大先前评估为低风险的风险。对低风险和保留风险的评审宜分别考虑每项风险，并将所有此类风险作为一个整体，以评估其潜在的累积后果。如果风险不属于低风险或可接受的风险类别，则宜使用第8章中的一种或多种选项进行处置。威胁发生的可能性及其相应后果的影响因素可能会发生变化，处置选项的适用性或成本的影响因素也会发生变化。影响组织的重大变化，宜作为实施更详细评审的理由。宜定期重复实施风险监视活动，并宜定期评审所选的风险处置选项。风险监视活动的结果可以输入到其他风险评审活动中。根据GB/T22080—xxxx中第8章的要求，组织宜定期评审所有风险，并当重大变更提出或发生时评审所有风险。注：本子章节涉及GB/T22080—管理评审输入：信息安全风险评估结果、信息安全风险处置计划的状态。动作：宜评审信息安全风险评估结果和信息安全风险处置计划的状态，以确认残余风险满足风险接受准则，并且风险处置计划对所有相关风险及其风险处置选项做出了安排。触发：评审活动日程安排的一部分。输出：风险接受准则和信息安全风险评估实施准则的变更，更新后的信息安全风险处置计划或适用性说明。注：本子章节涉及GB/T22080—纠正措施输入：风险处置计划被证明是无效的，即在处置计划完成后，残余风险仍将保持在不可接受的水平。动作：修订并实施风险处置计划，将残余风险调整到可接受的水平。触发：修订风险处置计划的决定。输出：修订后的风险处置计划及其实施。实施指导：通过内部或外部审核，或通过监视和绩效指标，可以发现与风险处置计划有效性相关的不符合。宜修改处置计划以反映：——信息安全风险处置过程的结果；——计划的逐步实施（例如，按规范、按设计、按构造实施控制）；——识别实施控制的困难（例如，技术或财务问题、与诸如隐私等内部或外部因素的不一致）。在某些情况下，即使处置计划完成后的残余风险是可接受的，用户也会拒绝使用或试图规避相应的控制，这是因为控制的易用性不足（例如，不符合人体工程学、太复杂或太长）导致其没有被用户所接受。GB/T31722-XXXX/ISO/IEC270组织宜评审修改后的处置计划的有效性。注：本子章节涉及GB/T22080—持续改进输入：从风险管理活动中获得的所有风险信息。动作：宜持续监视、评审并在必要时改进信息安全风险管理过程。触发：组织从信息安全风险管理过程的经验总结中寻求改进和成长。输出：信息安全风险管理过程与组织的业务目标是持续相关的或对过程的更新。实施指导：为确保信息安全风险管理过程是合适的，有必要持续监视和评审所建立的环境、风险评估结果、风险处置结果和管理计划与环境之间的相关性和适宜性。组织宜确保信息安全风险管理过程和相关活动在当前情况下是适宜的，并得到遵循。任何商定的过程改进，或改进过程符合性所需的行动，宜通知具有相应职责的管理人员。宜向这些管理人员提供保障，以确保他们：不会忽视或低估任何风险或风险要素，会采取必要的措施并做出决策，以形成切合实际的风险认知并提供风险应对能力。宜注意的是，变更管理过程宜不断地向风险管理过程提供反馈，以确保信息系统变更后能够及时考虑所改变的风险，甚至是调整风险评估活动，以恰当地评估信息系统。此外，组织宜定期验证测量风险的准则。该验证宜确保在信息安全风险管理过程中，所有的要素仍然有效且与业务目标、战略和策略相一致，并且充分考虑了业务环境的变化。该监视和评审活动宜包括（但不限于）：——法律和内外部环境；——竞争环境；——风险评估方法；——资产价值和类别；——后果准则；——可能性准则；——风险评价准则；——风险接受准则；——总成本；——必要的资源。组织宜确保评审风险时，风险评估和风险处置资源是持续可用的，以处理新的或改变的威胁或脆弱性并相应地向管理层提出建议。风险管理监视可能导致调整或增加所使用的方法、方法论或工具，这具体取决于：——组织风险管理的成熟度；——已识别的变更；——风险评估迭代；——信息安全风险管理过程的目标（例如，业务连续性、事件恢复能力、合规性）；——信息安全风险管理过程的对象（例如，组织、业务部门、信息过程及其技术实现、应用、与互联网的连接）。与风险评估和风险处置范围相关的风险管理周期见5.2。注：本子章节涉及GB/T22080—GB/T31722-XXXX/ISO/IEC2（资料性）支持风险评估过程的技术示例A.1信息安全风险准则A.1.1风险评估相关准则A.1.1.1风险评估的一般考虑通常情况下，个人的不确定性会主导性地影响信息安全风险评估，不同的分析师在解释可能性和后果标度程度时会表现出不同的不确定性倾向。基准标度宜将后果、可能性和风险类别与共同明确规定的目标价值联系起来，尽可能用定量方法所特有的、以货币计量的经济损失和有限时间内估计的发生频率等来表示。特别是在采用定性方法的情况下，风险分析师宜根据锚定的基准标度进行培训和定期实践，以保持其判断的标定。A.1.1.2定性方法A.后果标度表A.1给出了后果标度示例。表A.1后果标度示例和/或：政府部门难以甚至没有能力确保履行监管职能或完成和/或：对人身和财产安全造成严重后果（健康危机、重组织无法确保开展全部或部分业务活动，可能对人身和财产安全造成严重后果。组织很可能无法克服这种情况（其生存受到威胁），其经营所在地区的活动或政府部门可组织活动能力严重下降，可能对人身和财产安全造成重大后果。组织可以克服严重困难的情况（以严重降级的模式运行），但不会对组织活动能力下降，但不会对人身和财产安全造成后果。尽没有对运营、活动能力或人身和财产安全造成后果。组织可毫无困难的克服这种情况A.可能性标度表A.2和表A.4给出了表示可能性标度的可选方法示例。可能性能用表A.2中的概率项或表A.4中的频率项来表示。概率表示风险事态在指定时间段内发生的平均可能性，而频率表示风险事态在指定时间段GB/T31722-XXXX/ISO/IEC270内预计平均发生的次数。由于这两种方法只是从两个不同的角度表达同一事情，因此两种方法均能使用，这取决于组织认为哪种方式对给定的风险类别最为方便。但是，如果这两种方法在同一组织内都被用作可选方案，重要的是，