Khi website gặp security incident, giao tiếp kém có thể làm sự cố phức tạp hơn: nhiều người tự ý thay đổi hệ thống, khách hàng nhận thông tin mâu thuẫn hoặc đội kỹ thuật bị gián đoạn bởi các yêu cầu cập nhật liên tục. Vì vậy incident communication cần có owner, cadence và nguyên tắc fact-based rõ ràng.
Mục tiêu là cung cấp đúng thông tin cho đúng đối tượng mà không biến hypothesis thành kết luận hoặc công bố dữ liệu chưa được xác minh.
Phân biệt communication nội bộ và bên ngoài
Nội bộ kỹ thuật
Cần chi tiết về incident ID, severity, scope, action, evidence và next owner để phối hợp xử lý.
Management/business owner
Cần impact, business function bị ảnh hưởng, quyết định cần phê duyệt, ETA của checkpoint tiếp theo và residual uncertainty.
Khách hàng/người dùng
Chỉ nên cung cấp thông tin đã xác minh, tác động mà họ cần biết và hành động họ cần thực hiện. Không nên phỏng đoán nguyên nhân khi investigation chưa đủ evidence.
Thiết lập một nguồn thông tin chính thức
Một incident owner hoặc communication owner nên chịu trách nhiệm phát hành status update. Các team khác cập nhật vào incident record thay vì tự gửi thông báo khác nhau.
Thông tin kỹ thuật chi tiết vẫn nằm trong Incident Timeline và evidence record, không nhất thiết xuất hiện trong thông báo public.
Communication log là evidence vận hành
Mỗi status update quan trọng nên có timestamp, người phát hành, audience và nội dung. Điều này giúp Post-Incident Review đánh giá liệu communication có làm chậm hoặc hỗ trợ response.
Communication Matrix theo severity
| Đối tượng | Nội dung | Khi nào cập nhật | Owner |
|---|---|---|---|
| Technical responders | Fact, hypothesis, action, blockers | Theo checkpoint/action quan trọng | Incident commander |
| Management | Impact, severity, decision, risk | Theo cadence đã thống nhất | Incident owner |
| Customer support | Message được duyệt + FAQ | Khi có customer impact | Communication owner |
| Customers/users | Confirmed impact + required action | Khi cần thiết theo policy/nghĩa vụ áp dụng | Authorized spokesperson |
| Provider/vendor | Technical evidence cần phối hợp | Khi scope liên quan service của họ | Technical owner |
Mẫu status update nội bộ
| Trường | Nội dung |
|---|---|
| Status | Investigating / Contained / Recovering / Monitoring |
| Severity | P1–P4 + lý do nếu thay đổi |
| Confirmed facts | Những gì evidence đã xác nhận |
| Current impact | Asset/function/user bị ảnh hưởng |
| Actions completed | Containment/recovery đã làm |
| Open questions | Hypothesis cần xác minh |
| Next actions | Owner + checkpoint tiếp theo |
Mẫu thông báo khách hàng theo nguyên tắc tối thiểu
Một thông báo có thể theo cấu trúc:
- Điều gì đang xảy ra: mô tả sự cố ở mức đã xác minh.
- Ảnh hưởng: chức năng hoặc nhóm người dùng bị tác động.
- Chúng tôi đang làm gì: containment/recovery ở mức phù hợp để công bố.
- Khách hàng cần làm gì: chỉ yêu cầu hành động nếu có căn cứ, ví dụ reset credential khi thực sự cần.
- Khi nào cập nhật tiếp: nêu checkpoint thay vì hứa thời gian recovery nếu chưa chắc.
Không nên nói gì khi investigation chưa đủ
- Khẳng định “không có dữ liệu bị ảnh hưởng” khi scope chưa đủ.
- Chỉ đích danh nguyên nhân/attacker khi mới là hypothesis.
- Hứa thời điểm khôi phục không có căn cứ.
- Đưa chi tiết kỹ thuật có thể làm tăng rủi ro đang active.
- Thay đổi message giữa các kênh mà không có owner phê duyệt.
Khi nào cần phối hợp pháp lý hoặc compliance?
Nếu incident có thể liên quan dữ liệu cá nhân, nghĩa vụ thông báo, hợp đồng, bảo hiểm hoặc cơ quan quản lý, cần chuyển cho người phụ trách pháp lý/compliance của tổ chức. Bài viết này không xác định nghĩa vụ pháp lý cụ thể vì yêu cầu thay đổi theo jurisdiction, loại dữ liệu và hợp đồng.
Handoff giữa communication và recovery
Khi website chuẩn bị go-live, message cần thống nhất với Go-Live Decision. Không nên thông báo “đã khắc phục hoàn toàn” nếu incident vẫn ở trạng thái monitoring hoặc RCA còn open.
Quality gate cho incident communication
- Mỗi message có owner/phê duyệt phù hợp.
- Fact và hypothesis được tách biệt.
- Impact mô tả đúng scope hiện tại.
- Không hứa timeline không có evidence.
- Required action của khách hàng rõ và có lý do.
- Update cadence hoặc checkpoint tiếp theo được nêu.
- Communication log được lưu trong incident record.
Sau closure, review message, escalation và stakeholder coordination trong Post-Incident Review để cải thiện runbook cho lần sau.