Q003 — Làm thế nào để mô tả rủi ro rõ ràng và không mơ hồ?

Odin Lab | ODIN 101 — Digital Trust & Resilience
Banking Technology • Risk • GRC • Audit • Resilience • AI

Một câu rủi ro tốt phải phân biệt được Nguyên nhân – Rủi ro – Hậu quả

Trong Q001, chúng ta bắt đầu từ mục tiêu. Trong Q002, chúng ta phân biệt Threat, Vulnerability và Risk.

Đến Q003, câu hỏi thực tế hơn là: Làm thế nào để viết một rủi ro sao cho người khác đọc vào hiểu đúng ngay từ đầu?

Đây là vấn đề tưởng đơn giản nhưng lại xuất hiện rất thường xuyên trong Risk Register. Nhiều câu được gọi là “rủi ro” thực chất chỉ là nguyên nhân, điểm yếu, sự cố đã xảy ra hoặc hậu quả.

Dr David Hillson chỉ ra rất rõ điều này khi ông nói về cách mô tả rủi ro một cách rõ ràng và không mơ hồ: một rủi ro phải thể hiện được sự không chắc chắn và mối quan hệ hệ quả.

Nói đơn giản hơn, một câu rủi ro tốt phải cho người đọc biết: Vì sao điều đó có thể xảy ra? Điều gì có thể xảy ra? Và nếu xảy ra thì hậu quả là gì?

Tại Odin Lab, tôi sử dụng cấu trúc: Nguyên nhân → Rủi ro → Hậu quả, và diễn đạt thành câu: Bởi vì [Nguyên nhân], [Rủi ro] có thể xảy ra, dẫn đến [Hậu quả].

1. Tại sao nhiều câu “rủi ro” lại viết sai?

Một lỗi rất phổ biến là lấy hậu quả để gọi là rủi ro. Ví dụ: “Dịch vụ bị gián đoạn.” Đây chưa phải một câu rủi ro tốt. Nó chủ yếu mô tả hậu quả.

Một lỗi khác là lấy nguyên nhân làm rủi ro. Ví dụ: “Máy chủ đã hết hỗ trợ.” Đây là một tình trạng đã biết, một sự thật hiện hữu. Nó không có yếu tố không chắc chắn.

Hoặc: “Tài khoản quản trị chưa có MFA.” Đây là một điểm yếu hay thiếu biện pháp kiểm soát. Những câu này đều có giá trị, nhưng chúng không phải chính sự kiện rủi ro cần quản lý.

Theo cách diễn giải của David Hillson, rủi ro nằm ở giữa nguyên nhân và hậu quả. Đó là phần chưa chắc chắn.

2. Nguyên nhân là điều chúng ta đã biết

Nguyên nhân là một tình trạng, điều kiện hoặc thực tế đang tồn tại. Ví dụ: hệ điều hành đã hết hỗ trợ; đội ngũ còn thiếu kinh nghiệm; một dịch vụ chỉ có một nhà cung cấp; dữ liệu dự phòng chưa được kiểm thử gần đây; tài khoản quản trị chưa có xác thực đa yếu tố.

Các điều này đã tồn tại tại thời điểm chúng ta đánh giá. Chúng không phải là rủi ro. Chúng là lý do khiến một sự kiện không mong muốn có thể xảy ra.

3. Rủi ro phải là một sự kiện không chắc chắn

Đây là phần trung tâm. Một rủi ro phải có tính có thể xảy ra, nhưng chưa chắc chắn xảy ra. Vì vậy trong câu mô tả nên có các từ như có thể, có khả năng, có nguy cơ.

Ví dụ: “Hệ thống có thể không phục hồi được khi cần chuyển đổi.” Đây là một sự kiện chưa xảy ra và có tính không chắc chắn. Hoặc: “Tài khoản quản trị có thể bị chiếm quyền.” Đây cũng là một sự kiện rủi ro.

Nếu câu mô tả chỉ nói về một điều đã biết chắc chắn, thì đó thường chưa phải là risk event.

4. Hậu quả là điều xảy ra sau rủi ro

Hậu quả trả lời câu hỏi: Nếu rủi ro xảy ra thì sao?

Ví dụ: dịch vụ khách hàng bị gián đoạn; giao dịch thất bại; dữ liệu bị truy cập trái phép; không đáp ứng yêu cầu phục hồi; phát sinh tổn thất tài chính; ảnh hưởng uy tín; hoặc không đáp ứng yêu cầu pháp lý.

Đây là kết quả xuất hiện sau khi sự kiện rủi ro xảy ra. Một điểm quan trọng trong cách tiếp cận của David Hillson là: khi hậu quả đã xảy ra thì thường đã quá muộn để gọi đó là quản trị rủi ro. Quản trị rủi ro phải tập trung vào sự kiện chưa chắc chắn ở giữa, trước khi hậu quả xảy ra.

5. Công thức rất đơn giản để viết Risk Statement

Cấu trúc David Hillson đề xuất có thể diễn đạt rất tự nhiên bằng tiếng Việt:

Bởi vì [Nguyên nhân], [Rủi ro] có thể xảy ra, dẫn đến [Hậu quả].

Ví dụ: Bởi vì đội ngũ còn thiếu kinh nghiệm, quá trình thiết kế có thể mất nhiều thời gian hơn dự kiến, dẫn đến chậm tiến độ bàn giao.

Ba phần rất rõ: nguyên nhân là đội ngũ thiếu kinh nghiệm; rủi ro là quá trình thiết kế có thể mất nhiều thời gian hơn dự kiến; hậu quả là chậm tiến độ bàn giao. Điều đáng chú ý là rủi ro nằm ở giữa.

6. Áp dụng tại Odin Lab Bank

Giả sử Odin Lab Bank có một dịch vụ thanh toán số quan trọng. Trong quá trình rà soát, đội công nghệ phát hiện dữ liệu tại site dự phòng chưa được kiểm thử đầy đủ sau một thay đổi lớn.

Nếu ghi: “Rủi ro: dữ liệu dự phòng chưa được kiểm thử”, thì chưa chính xác. Đây là nguyên nhân hoặc điểm yếu.

Nếu ghi: “Rủi ro: dịch vụ thanh toán bị gián đoạn”, thì lại đang mô tả hậu quả.

Câu đầy đủ hơn nên là: Bởi vì dữ liệu tại site dự phòng chưa được kiểm thử đầy đủ sau thay đổi, dữ liệu có thể không ở trạng thái sử dụng được khi cần chuyển đổi, dẫn đến dịch vụ thanh toán không phục hồi trong thời gian yêu cầu và làm gián đoạn giao dịch khách hàng.

Lúc này ba phần đã rõ: nguyên nhân là dữ liệu dự phòng chưa được kiểm thử đầy đủ; rủi ro là dữ liệu có thể không sử dụng được khi cần chuyển đổi; hậu quả là dịch vụ không phục hồi đúng thời gian và giao dịch khách hàng bị gián đoạn.

7. Vì sao phải tách rõ ba phần?

Việc tách Nguyên nhân – Rủi ro – Hậu quả không chỉ để câu chữ đẹp hơn. Nó giúp chúng ta quản lý đúng đối tượng.

Nguyên nhân thường là điều kiện đã tồn tại. Hậu quả là điều xảy ra sau cùng. Còn rủi ro là sự kiện chưa chắc chắn ở giữa.

Ví dụ, nguyên nhân là đội ngũ ít kinh nghiệm. Ta không thể ngay lập tức biến họ thành chuyên gia. Hậu quả là trễ tiến độ. Khi đã trễ rồi thì đã muộn. Nhưng ở giữa, rủi ro là quá trình thiết kế có thể mất nhiều thời gian hơn dự kiến. Đây mới là phần có thể tác động thông qua đào tạo, review thiết kế, mẫu chuẩn, hỗ trợ chuyên gia hoặc thay đổi cách tổ chức công việc.

8. Áp dụng với rủi ro an toàn thông tin

Giả sử Odin Lab Bank có một tài khoản quản trị chưa sử dụng xác thực đa yếu tố.

Câu chưa tốt: “Rủi ro: tài khoản admin chưa có MFA.” Đây là nguyên nhân hoặc điểm yếu.

Câu tốt hơn: Bởi vì tài khoản quản trị chưa được bảo vệ bằng xác thực đa yếu tố, tài khoản có thể bị chiếm quyền khi thông tin đăng nhập bị lộ, dẫn đến truy cập trái phép vào hệ thống quan trọng, thay đổi cấu hình hoặc ảnh hưởng tới dữ liệu.

9. Áp dụng với rủi ro nhà cung cấp

Giả sử dịch vụ thanh toán của Odin Lab Bank phụ thuộc vào một nhà cung cấp duy nhất.

Câu quá chung: “Rủi ro nhà cung cấp.” Không đủ.

Câu rõ hơn: Bởi vì dịch vụ thanh toán phụ thuộc vào một nhà cung cấp duy nhất, nhà cung cấp có thể bị gián đoạn kéo dài mà không có phương án thay thế kịp thời, dẫn đến dịch vụ thanh toán không đáp ứng mức độ sẵn sàng đã cam kết và làm gián đoạn giao dịch khách hàng.

10. Đừng nhầm Risk với Issue

Một nguyên tắc đơn giản: nếu sự việc đã xảy ra, đó thường không còn là Risk nữa. Nó đã trở thành Issue hoặc Incident.

Ví dụ: “Database đã down 30 phút.” Đây là incident. Còn: “Database có thể gặp sự cố và không phục hồi trong RTO.” Đây là risk.

Phân biệt này rất quan trọng vì cách quản lý cũng khác nhau: Incident cần xử lý. Issue cần khắc phục. Risk cần đánh giá và chuẩn bị response trước khi xảy ra.

11. Một Risk Statement tốt phải giúp chúng ta quản lý được

Một câu rủi ro tốt không dừng ở việc mô tả. Nó phải giúp chúng ta trả lời tiếp: khả năng xảy ra là bao nhiêu; hậu quả nghiêm trọng đến đâu; biện pháp kiểm soát nào đang có; có cần thêm kiểm soát không; bằng chứng nào chứng minh kiểm soát hoạt động; ai chịu trách nhiệm; và mức rủi ro còn lại có chấp nhận được không.

Nếu câu risk viết mơ hồ, những câu hỏi phía sau cũng sẽ mơ hồ. Đó là lý do chất lượng Risk Register bắt đầu từ chất lượng Risk Statement.

12. Kết nối với Odin Risk Management Method

Cách viết này rất phù hợp với Odin Risk Management Method. Trong Q001, chúng ta có: Objective → Risk → Assess → Control → Evidence → Responsibility → Decision & Monitor → Learn.

Ở Q003, chúng ta đang làm rõ riêng bước Risk. Một câu Risk tốt cần bắt đầu từ Objective, sau đó mô tả Nguyên nhân → Rủi ro → Hậu quả. Khi câu risk đã rõ, ta mới có thể bước sang đánh giá, kiểm soát, bằng chứng, trách nhiệm và quyết định.

13. Năm câu hỏi trước khi đưa một risk vào Risk Register

1. Mục tiêu hoặc dịch vụ nào đang được bảo vệ?
2. Nguyên nhân nào đang tồn tại?
3. Sự kiện không chắc chắn nào có thể xảy ra?
4. Nếu xảy ra thì hậu quả là gì?
5. Câu này có đủ rõ để đánh giá và quyết định biện pháp xử lý không?

Nếu chưa trả lời được năm câu này, Risk Statement có thể chưa đủ rõ.

14. Mối liên hệ với các chuẩn quốc tế

Cách tiếp cận trên phù hợp với tinh thần của các chuẩn và phương pháp quản trị rủi ro phổ biến. ISO 31000 đặt risk trong mối quan hệ với uncertainty và objectives. CRISC của ISACA nhấn mạnh xây dựng và đánh giá các risk scenarios, xem xét khả năng xảy ra, tác động, kiểm soát và residual risk. NIST SP 800-30 tiếp cận risk assessment qua threat events, vulnerabilities, likelihood và impacts. ISO/IEC 27005 hướng dẫn việc nhận diện, phân tích, đánh giá và xử lý rủi ro an toàn thông tin.

Odin Lab không tạo ra một định nghĩa mới thay thế các chuẩn này. Chúng tôi đưa cách tiếp cận đó về một câu dễ nhớ hơn:

Bởi vì [Nguyên nhân], [Rủi ro] có thể xảy ra, dẫn đến [Hậu quả].

Kết luận

Một câu rủi ro tốt không cần dài. Nhưng nó phải rõ.

Điều quan trọng nhất là không nhầm lẫn: Nguyên nhân không phải là Rủi ro. Hậu quả không phải là Rủi ro. Rủi ro là sự kiện không chắc chắn nằm giữa Nguyên nhân và Hậu quả.

Vì vậy, thay vì viết “Hệ thống bị gián đoạn”, hãy hỏi: Vì sao có thể xảy ra? Điều gì có thể xảy ra? Nếu xảy ra thì hậu quả là gì?

Đây là một kỹ thuật rất nhỏ, nhưng nó có thể tạo ra khác biệt rất lớn giữa một Risk Register mang tính hành chính và một Risk Register thực sự giúp tổ chức ra quyết định.

TURN RISK INTO VALUE.

Đọc tiếp trong ODIN 101

← Q002: Threat, Vulnerability và Risk khác nhau như thế nào?

Đọc tiếp → Q004: Đánh giá rủi ro thế nào để không biến thành trò chấm điểm?

Xem toàn bộ ODIN 101 — Digital Trust & Resilience →

Tài liệu tham khảo

Dr David Hillson — How can we describe risks clearly and unambiguously?, RiskDoctorVideo.

ISACA — CRISC Exam Content Outline.

ISO 31000:2018 — Risk Management — Guidelines.

ISO/IEC 27005:2022 — Guidance on managing information security risks.

NIST SP 800-30 Rev.1 — Guide for Conducting Risk Assessments.