Từ bất định (uncertainty) đến kịch bản rủi ro có thể quản trị

Danh sách rủi ro có thể dài nhưng vẫn chưa giúp tổ chức biết điều gì cần ưu tiên. Bước Risk trong Chu trình Odin bắt đầu bằng câu hỏi: Điều gì không chắc chắn có thể ảnh hưởng đến mục tiêu đã xác định?

Ở đây, bất định chỉ phần thông tin, điều kiện hoặc kết quả chưa thể biết chắc. Quản trị rủi ro không dừng ở việc gọi tên điều chưa chắc chắn; cần mô tả nó thành một kịch bản gắn với mục tiêu để có thể đánh giá và xử lý.

ISO 31000:2018 mô tả rủi ro là ảnh hưởng của sự không chắc chắn lên mục tiêu. Cách diễn đạt thực hành của Odin Lab giúp cụ thể hóa mối liên hệ đó bằng chuỗi: Nguyên nhân → Sự kiện → Tác động. Chuỗi này là cấu trúc hỗ trợ phân tích, không thay thế định nghĩa hoặc yêu cầu riêng của tiêu chuẩn và quy định áp dụng.

Bước Risk trả lời câu hỏi gì?

Objective đã làm rõ mục tiêu, giá trị cần bảo vệ, phạm vi và tiêu chí thành công. Bước Risk dùng những thông tin đó để tìm các tình huống có thể làm kết quả lệch khỏi mục tiêu, hoặc tạo ra cơ hội cải thiện kết quả.

Risk không phải là danh sách mọi điểm yếu, sự cố đã xảy ra hay hệ thống đang vận hành. Một điểm yếu chỉ có ý nghĩa trong kịch bản khi ta hiểu nó có thể dẫn đến sự kiện nào và ảnh hưởng ra sao đến mục tiêu. Tương tự, một sự cố đã xảy ra là vấn đề hiện hữu cần được xử lý; bước Risk có thể dùng sự cố đó làm bằng chứng để xem xét các kịch bản tương lai.

Đầu ra của bước này là một tập hợp kịch bản đủ cụ thể để bước Assess đánh giá khả năng xảy ra, mức độ tác động và mức ưu tiên. Bước Risk chưa quyết định phương án xử lý hoặc chọn kiểm soát; những nội dung đó sẽ được xem xét ở các bước sau.

Cấu trúc kịch bản rủi ro

Thành phần	Câu hỏi gợi ý	Vai trò trong kịch bản
01 · Nguyên nhân	Điều kiện, thay đổi, điểm yếu hoặc phụ thuộc nào có thể tạo ra tình huống?	Mô tả bối cảnh hoặc yếu tố dẫn đến sự kiện.
02 · Sự kiện	Điều gì có thể xảy ra?	Nêu một diễn biến cụ thể, đủ rõ để có thể phân tích.
03 · Tác động	Mục tiêu nào có thể bị ảnh hưởng, và theo cách nào?	Nối sự kiện với hậu quả nghiệp vụ, khách hàng, tài chính, tuân thủ hoặc vận hành.

Nguyên nhân → Sự kiện → Tác động

Nguyên nhân không nhất thiết chỉ là lỗi kỹ thuật. Nó có thể là thay đổi cấu hình, quy trình chưa đầy đủ, năng lực vận hành, phụ thuộc nhà cung cấp, hành vi con người hoặc điều kiện bên ngoài. Sự kiện cần nói rõ điều gì có thể xảy ra, thay vì chỉ lặp lại nguyên nhân. Tác động cần chỉ ra mục tiêu cụ thể bị ảnh hưởng, thay vì dùng những cụm chung như “ảnh hưởng lớn” hoặc “gây thiệt hại”.

Ví dụ giả lập tại Odin Lab Bank

Tình huống minh họa — Odin Lab Bank (OLB) là ngân hàng giả lập phục vụ nghiên cứu và đào tạo. Giả sử mục tiêu đã xác nhận là khách hàng có thể thực hiện giao dịch chuyển tiền chính xác, nhận trạng thái rõ ràng và được phục vụ trong giới hạn liên tục đã phê duyệt.

Do thay đổi cấu hình tích hợp chưa được kiểm thử đầy đủ trên các tuyến phụ thuộc và chưa xác nhận phương án quay lui, một số yêu cầu chuyển tiền có thể được tiếp nhận nhưng trạng thái xử lý hoặc đối soát bị cập nhật chậm; điều này có thể khiến khách hàng chưa biết giao dịch đã hoàn tất hay chưa, làm tăng yêu cầu hỗ trợ và ảnh hưởng đến mục tiêu cung cấp dịch vụ chuyển tiền chính xác, rõ trạng thái và liên tục.

Có thể tách kịch bản trên thành ba phần:

• Nguyên nhân: thay đổi cấu hình, kiểm thử phụ thuộc chưa đầy đủ và phương án quay lui chưa được xác nhận.
• Sự kiện: yêu cầu được tiếp nhận nhưng trạng thái hoặc đối soát cập nhật chậm.
• Tác động: khách hàng khó xác định kết quả giao dịch; khối lượng hỗ trợ tăng; mục tiêu về tính chính xác, minh bạch và liên tục của dịch vụ có thể bị ảnh hưởng.

Đây là một giả thuyết để phân tích, không phải khẳng định sự cố đã xảy ra tại ngân hàng có thật. Ở bước Assess, nhóm sẽ kiểm tra căn cứ, đánh giá khả năng và tác động, xem xét kiểm soát hiện có rồi xác định mức ưu tiên.

Cách viết một kịch bản đủ rõ

1. Bắt đầu từ mục tiêu đã thống nhất. Nếu chưa chỉ ra mục tiêu nào bị ảnh hưởng, hãy quay lại làm rõ phạm vi hoặc mục tiêu trước khi viết rủi ro.
2. Ghi nhận điều kiện hoặc nguyên nhân có căn cứ. Dựa vào kiến trúc, quy trình, thay đổi, dữ liệu sự cố, kiểm thử, phụ thuộc và trao đổi với người vận hành. Phân biệt dữ kiện đã xác nhận với giả định cần kiểm chứng.
3. Mô tả sự kiện như một diễn biến. Nêu điều có thể xảy ra với dịch vụ, dữ liệu, giao dịch hoặc hoạt động; tránh biến sự kiện thành một nhãn mơ hồ như “cyber risk”.
4. Nêu tác động theo mục tiêu. Mô tả hậu quả có thể quan sát hoặc đánh giá được, như gián đoạn dịch vụ, giao dịch sai/chậm, dữ liệu không sẵn sàng, nghĩa vụ không được đáp ứng hoặc giảm niềm tin khách hàng.
5. Viết theo mức chi tiết vừa đủ. Một câu có thể gồm nhiều nguyên nhân hoặc tác động liên quan, nhưng nếu nó chứa nhiều sự kiện độc lập thì nên tách thành các kịch bản riêng.
6. Ghi rõ điều chưa biết. Nêu giả định, câu hỏi và nguồn bằng chứng cần kiểm tra để tránh trình bày suy đoán như sự thật.

Mẫu điền nhanh:

Do [nguyên nhân/điều kiện], [sự kiện] có thể xảy ra, dẫn đến [tác động lên mục tiêu].

Mẫu này giúp nhóm không bỏ sót mối liên hệ giữa bối cảnh, diễn biến và hậu quả. Nếu câu quá dài, có thể tách thành trường riêng trong sổ đăng ký rủi ro; điều quan trọng là giữ được mối nối giữa ba thành phần.

Những lỗi thường gặp

• Chỉ ghi một điểm yếu: “Thiếu giám sát” chưa nói sự kiện gì có thể xảy ra và mục tiêu nào chịu ảnh hưởng.
• Gộp nguyên nhân với sự kiện: “Do lỗi cấu hình” thường mới là nguyên nhân; cần làm rõ diễn biến có thể xảy ra sau đó.
• Viết tác động chung chung: “Ảnh hưởng hoạt động” khó giúp ưu tiên nếu không nêu dịch vụ, khách hàng hoặc kết quả nào bị ảnh hưởng.
• Nhầm rủi ro với sự cố hiện hữu: sự cố đang diễn ra cần được quản lý như vấn đề/sự kiện; đồng thời xem xét khả năng tái diễn hoặc lan rộng như các kịch bản rủi ro.
• Ghi nhận mọi điều không chắc chắn như nhau: chỉ đưa vào phạm vi những tình huống có liên hệ với mục tiêu và đủ quan trọng để đánh giá.
• Chốt phương án xử lý quá sớm: lựa chọn Accept, Avoid, Transfer hoặc Mitigate cần có kết quả Assess và thẩm quyền phù hợp.

Đầu ra và bước tiếp theo

Trước khi chuyển sang Assess, hồ sơ bước Risk nên có:

• mục tiêu và phạm vi mà kịch bản liên quan;
• mô tả nguyên nhân, sự kiện và tác động;
• nguồn dữ kiện, giả định và thông tin còn cần xác minh;
• liên kết đến quy trình, dịch vụ, hệ thống hoặc phụ thuộc liên quan;
• đầu mối nghiệp vụ/kỹ thuật cần tham gia phân tích tiếp theo.

Không cần biến bước Risk thành bài tập liệt kê vô hạn. Một tập kịch bản có liên hệ rõ với mục tiêu sẽ giúp bước Assess so sánh, ưu tiên và xác định nội dung cần tìm thêm bằng chứng.

Câu hỏi chuyển bước: Rủi ro nào thực sự quan trọng đối với mục tiêu, và căn cứ nào giúp xác định mức ưu tiên? Đó là nội dung của bước Assess.

Đọc tiếp: Bắt đầu từ mục tiêu: Xác định phạm vi và giá trị cần bảo vệ · Chu trình Odin – Từ rủi ro đến giá trị · Phương pháp ODIN · Khi nào dùng 4 bước, khi nào dùng 8 bước?

---

Tham chiếu

• ISO 31000:2018 — Risk management — Guidelines
• NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments

Bài viết trình bày cách thực hành của Odin Lab, không thay thế tiêu chuẩn hoặc quy định áp dụng tại từng tổ chức. Tình huống OLB trong bài là giả lập.

TURN RISK INTO VALUE.