在安全事件发生后的最初几小时内，您无法全面了解发生了什么。您的团队可能仍在努力了解哪个帐户已泄露、访问了哪些数据、攻击者达到了什么程度，或者事件是否仍在持续。
在您进行调查的同时，立即就会面临行动压力。员工听到各种片段信息，需要知道该做什么。与此同时，客户可能会注意到服务中断、可疑活动或异常的密码重置请求。业务合作伙伴可能会询问他们的系统或数据是否涉及其中，而领导层需要决定由谁发言、可以确认什么，以及何时沉默本身会成为风险。
安全事件沟通之所以困难，是因为企业必须在掌握所有答案之前保持透明，但又要有足够的信息，不能靠猜测。发送过早的沟通可能会造成混乱，但如果发送过晚，则可能损害信任、延缓保护行动，并引发监管问题。
小型和中型企业中小型企业不太可能已经制定或演练了他们的事件响应套餐，这可能会导致额外的混乱。即使对于有套餐的大型企业，技术步骤也可能已经记录在案：遏制事件、重置访问、保留证据、恢复系统。沟通可能会被留到以后，直到事件突然升级或发生变化。
为事件做准备的一部分是了解谁需要听取您的消息、他们需要知道什么、谁批准消息，以及如何在调查仍在进行时清晰地传达事实。
Proton Pass for Business 如何提供帮助
沟通规划应纳入事件响应
事件响应通常被描述为一个技术过程，但真实的事件很快就会变成跨职能的。 IT 团队可能遏制威胁，但领导层、法务、客户支持、人力资源、沟通和运营部门都需要了解正在发生什么，以及他们可以说什么。
NCSC 关于网络事件中的有效沟通（新窗口）的指南——这是一项远远超出英国范围的通用最佳实践——明确指出了这一点：组织通常优先考虑技术响应，而将沟通置于次要位置，尽管沟通会影响员工、客户、利益相关者和媒体在危机期间对组织的看法。
并非每个事件都需要公开声明。但企业应提前知道由谁决定沟通内容、谁批准对外消息、谁与客户沟通，以及谁负责监管报告。
一个强大的数据违反响应套餐需要包含沟通层面。这应包括实用详细信息：
- 联系人列表
- 草稿模板
- 审批路线
- 法律审查
- 客户支持谈话要点
- 监管机构通知责任
- 记录已发送的内容、发送时间及接收对象。
您的响应双轨结构
事件响应需要两条轨道：技术响应和沟通响应。它们并行运行，事件负责人/响应负责人将两者连接起来。
| 左侧轨道：技术响应 | 右侧轨道：沟通响应 |
| 遏制事件 | 更新内部团队 |
| 保护受影响的帐户 | 通知受影响的客户或合作伙伴 |
| 保留证据 | 评估监管机构通知 |
| 恢复系统 | 随着事实变化保持消息一致 |
这使您能够构建响应结构，并确保在团队成员承担不同任务时协作持续进行。
从受众出发，而非公告
当一条消息试图服务于所有人时，安全事件沟通就会失败。员工、客户、合作伙伴和监管机构需要不同级别的详细信息，因为他们需要做出不同的决定。
您的内部团队首先需要明确
他们不需要所有详细信息——尤其是在调查仍在进行时——但他们确实需要明确哪些已确认、现在该做什么以及谁在领导响应。这意味着要知道应避免使用哪些系统或帐户、立即采取什么行动，以及哪些问题仍未解决。
员工还需要知道不该做什么。例如：
- 不要公开讨论该事件
- 不要在批准的流程之外重置凭证
- 不要用临时编造的解释联系客户
- 不要在未经指导的情况下转发可疑消息。
客户和合作伙伴需要知道他们受到了怎样的影响
他们想知道自己的数据、访问权限、付款、服务或运营是否受到影响。良好的客户通知应说明：
- 已知信息
- 可能涉及哪些类型的数据
- 企业正在采取什么措施
- 客户现在应该做什么（如有）
- 他们可以从哪里获取更新
语气应平实直接。客户也不需要事无巨细的细节，他们只需要足够的信息来保护自己。
监管机构需要事实记录
向相关监管机构（英国的 ICO（新窗口），以及每个欧盟成员国的国家数据保护机构）提交的 GDPR 违规通知不是营销消息，也不是安抚客户的说明。它需要是对所发生事件、受影响对象以及您正在采取的措施的事实记录。我们将在下面关于通知监管机构的部分中详细介绍具体应包含的内容。
内部沟通内容
您的员工也是应对工作的一部分，即使他们不在事件响应团队中。一支困惑的团队可能会意外制造更多混乱、分享不准确的信息，或拖慢遏制进度。反之，一支信息充分的团队可以帮助保护帐户、引导客户前往正确的频道，并避免猜测蔓延。
内部安全事件公告应涵盖：
- 用平实的语言清晰总结目前已经确认的情况
- 哪些系统、帐户、团队或数据可能受到影响
- 企业目前正在采取什么措施
- 员工应立即做什么
- 谁可以对外沟通
- 更新将发布在哪里
- 如何报告相关可疑活动
有些内容不应包含在内：攻击途径、根本原因分析和具体漏洞在事件仍在进行时通常不会在内部分享，事后也往往不会分享，因为这些详细信息可能会帮助其他攻击者、带来法律风险，或暴露尚未关闭的缺口。
第一封内部消息不需要回答所有问题，它需要建立秩序。例如，员工可能需要仅通过经过批准的流程重置密码、避免使用特定系统、保留可疑电子邮件，或在响应团队完成审查之前停止使用共享凭证。
对照密码管理最佳实践评估现有的访问控制也至关重要。在事件期间，过时或非正式的凭证分享可能会加大了解哪些信息已泄露的难度。
Proton 的数据泄露防护和企业数据泄露预防指南解释了分层控制如何在泄露发生前减少风险暴露。安全的凭证管理就是其中一层，因为它可以帮助企业了解存在哪些帐户、谁可以访问这些帐户，以及需要快速更改什么。
如何通知客户发生违规
向客户发送数据泄露通知更为困难，因为它涉及声誉和法律方面的责任。人们可能会担心身份盗用、帐户被盗、金融欺诈或私人信息泄露。他们也可能对公司的未能阻止事件感到不满。
一封好的客户消息应该诚实而不引起恐慌。它应避免技术术语，但要清晰明了。客户需要了解涉及了哪些数据、这会带来什么风险，以及他们接下来应该做什么。
一个有用的结构是：
- 发生了什么，以适合客户的详细程度说明
- 企业何时获悉
- 哪些信息或服务可能受到影响
- 企业已采取哪些措施
- 客户现在应该做什么
- 企业将如何提供更新
- 客户如有问题可以联系谁
如果调查仍在进行中，应披露这一情况。准确和透明有助于恢复信任。对影响保持公开并不需要披露会帮助他人重复攻击的技术细节。
对于严重事件，客户可能需要实用指导：更改密码、启用 MFA、警惕网络钓鱼电子邮件、联系银行，以及忽略声称来自公司的消息，除非这些消息通过官方频道发送。通知应使这些步骤易于理解。
何时以及如何通知监管机构
并非每起安全事件都需要向监管机构报告。根据英国和欧盟 GDPR，可报告的违规取决于个人数据泄露是否可能对人们的权利和自由构成风险。
ICO 的个人数据泄露指南（新窗口）反映了英国和欧盟 GDPR 的共同要求：组织必须在获悉后无不当延迟地报告应通报的违规，且不得晚于 72 小时。迟报需要说明延迟原因。
这 72 小时的窗口期可能会带来压力，尤其是在调查尚未完成时。GDPR 认可组织可能无法在最初的 72 小时内掌握所有详细信息，因此可以分阶段提供信息，只要后续更新无不当延迟地提供即可。
向相关监管机构（英国的 ICO，或欧盟的国家数据保护机构）提交的通知通常应包括：
- 个人数据泄露的性质
- 受影响个人的类别和大致人数
- 受影响个人数据记录的类别和大致数量
- DPO 或其他联系点的姓名和联系人详情
- 违规可能造成的后果
- 已采取或拟采取的处理措施
ICO 还提供一个集中页面，用于报告违规（新窗口），并将组织引导至适当的报告流程。
对于受影响的个人，门槛有所不同。如果个人数据泄露可能对人们的权利和自由构成高风险，则必须无不当延迟地通知他们。在这种情况下，即使是小型企业，法律、隐私和领导团队也应尽早参与。
在需要之前准备好消息
最糟糕的沟通流程设计时机就是在事件发生期间。发布需要更新和更改的声明或指导毫无益处。
这就是为什么在需要之前准备好消息的结构很有帮助。不是最终的措辞，因为每起事件都会不同，而是结构：谁需要批准消息、必须包含哪些详细信息、更新将记录在哪里，以及谁负责每个受众。
一套简单的沟通工具包就能让第一个小时不那么混乱。它可以包括：
- 内部事件通告模板
- 客户通知模板
- 合作伙伴或供应商更新模板
- 客户支持谈话要点
- 监管机构通知清单
- 已批准的发言人名单
- 法务、IT、隐私、管理层和传播部门的升级联系人
- 用于记录所有更新和决策的地方
当速度和准确性都至关重要时，做好准备能为团队提供一个安全的起点。事先备好的模板能让团队把更多注意力放在事件的事实上：发生了什么、谁受到影响、已经采取了哪些措施，以及人们接下来需要做什么。
Proton Pass for Business 如何提供帮助
安全事件沟通取决于事实。企业在事件发生前对访问的管理越清晰，就越容易解释发生了什么、可能受到影响的是什么，以及已经更改了什么。
像 Proton Pass for Business 这样的企业密码管理器可帮助团队减少与凭证相关的风险暴露。员工可以生成强密码，将其存储在已加密的密码保险库中，使用自动填充，安全地分享凭证，管理通行密钥，并使用内置的双因素身份验证。管理员可以应用密码策略，查看活动日志，通过基于角色的控制管理访问，并通过SCIM 和 SSO 集成支持预配。
在事件发生期间，这些功能可以帮助企业更有信心地采取行动。如果员工帐户已泄露，管理员可以审查访问情况，识别可能需要轮换的共享凭证，强制执行更强的身份验证，并减少对通过聊天或电子表格复制的密码的依赖。
使用企业密码管理器，在泄露事件发生之前就做好响应准备。
