Q010 — Khi nào một rủi ro có thể đóng, và chúng ta phải học gì từ nó?

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

Đóng Risk không phải là xóa một dòng khỏi Risk Register.

Trong Q009, chúng ta đã nói về Monitoring: sau khi đã ra quyết định, tổ chức vẫn phải theo dõi để biết Risk đang tốt lên hay xấu đi.

Nhưng rồi sẽ đến một thời điểm khác.

Một remediation đã hoàn thành. Control đã được cải thiện. Evidence cho thấy Risk giảm xuống. Một issue đã được xử lý. Hoặc một Risk không còn phù hợp vì hệ thống, quy trình hay Objective đã thay đổi.

Lúc đó một câu hỏi rất thực tế xuất hiện:

Khi nào chúng ta có thể đóng Risk?

Và một câu hỏi quan trọng hơn:

Sau khi đóng, chúng ta đã học được gì?

Trong Odin Risk Management Method:

Objective → Risk → Assess → Control → Evidence → Responsibility → Decision & Monitor → Learn

Learn là bước cuối của một vòng, nhưng đồng thời cũng là điểm bắt đầu cho vòng tiếp theo.

1. Một Risk không nên được đóng chỉ vì Action đã hoàn thành

Đây là một nhầm lẫn rất phổ biến.

Một Action đã hoàn thành không có nghĩa Risk đã biến mất.

Ví dụ, một cấu hình đã được sửa, một server đã được nâng cấp, một automation workflow đã được triển khai hoặc một policy đã được ban hành. Tất cả đều có thể là những Action hợp lệ.

Nhưng câu hỏi cần hỏi sau đó là: Risk đã thay đổi thế nào?

Nếu Action hoàn thành nhưng Control chưa vận hành ổn định, Evidence chưa đủ hoặc Residual Risk vẫn cao, Risk chưa nên được đóng.

Action Closed ≠ Risk Closed

Trong Odin Method, một Action chỉ có giá trị khi nó giúp thay đổi Control, tạo ra Evidence tốt hơn và cuối cùng làm thay đổi Risk.

2. Đóng Risk cần dựa trên kết quả, không chỉ dựa trên tiến độ

Một Risk có thể xem xét đóng khi có đủ căn cứ để kết luận rằng trạng thái hiện tại đã phù hợp với Objective và mức Risk chấp nhận được.

Có thể kiểm tra qua một số câu hỏi đơn giản: Control đã được triển khai chưa? Control có thực sự hoạt động không? Evidence có đủ và còn hiệu lực không? Residual Risk hiện tại là bao nhiêu? Risk có nằm trong Appetite/Tolerance không? Có Action quan trọng nào còn mở không? Có Trigger nào cho thấy Risk cần tiếp tục theo dõi riêng không? Ai có quyền quyết định việc đóng?

Điểm quan trọng là “Done” không phải trạng thái kỹ thuật. Nó là một Decision. Và Decision đó phải có căn cứ.

3. Có nhiều cách một Risk “kết thúc”

Không phải Risk nào cũng kết thúc theo cùng một cách.

Risk đã được xử lý đủ. Controls được cải thiện, Evidence tốt và Residual Risk đã nằm trong mức chấp nhận được. Risk có thể được đóng như một item riêng và chuyển sang monitoring thông thường.

Risk đã được Accept. Risk vẫn tồn tại, nhưng tổ chức quyết định chấp nhận mức còn lại. Trong trường hợp này, “đóng” không có nghĩa Risk biến mất; nó có thể được chuyển sang trạng thái Accepted / Monitored.

Risk không còn tồn tại. Ví dụ, một hệ thống đã decommission, một quy trình đã bị loại bỏ hoặc một hoạt động tạo ra Risk không còn được thực hiện. Khi Risk source không còn, Risk có thể được retire.

Risk đã chuyển thành vấn đề khác. Một Risk đôi khi trở thành Incident, Issue, Audit Finding, Control Deficiency hoặc một Risk mới có bản chất khác. Trong trường hợp đó, không nên đơn giản đóng dòng cũ rồi mất dấu. Cần giữ được mối liên hệ để biết Risk ban đầu đã đi đâu.

4. Case Odin Lab Bank: Recovery Risk có thể đóng chưa?

Tiếp tục với Digital Payment Service của Odin Lab Bank.

Trong các bài trước, OLB có một Recovery Risk: dịch vụ có thể không phục hồi trong RTO đã được phê duyệt.

Ban đầu, DR exercise cho thấy infrastructure và data recovery thành công nhưng tổng recovery time vẫn hơi vượt mục tiêu do một bước thủ công. OLB quyết định Accept có điều kiện và triển khai automation để giảm thời gian phục hồi.

Sau ba tháng, automation đã được triển khai, recovery workflow được chuẩn hóa, hai lần test liên tiếp đạt RTO, critical transaction được xác nhận, không có exception nghiêm trọng và Evidence đã được Risk Owner review.

Lúc này câu hỏi không còn là: “Automation đã làm xong chưa?”

Recovery Risk còn cần được quản lý như một Risk riêng nữa không?

Nếu Residual Risk đã nằm trong tolerance, Risk có thể được đóng khỏi danh sách remediation đang mở. Nhưng các Control như DR test, recovery monitoring và automation health vẫn phải tiếp tục vận hành.

Đóng Risk không có nghĩa đóng luôn Control.

Odin Lab Bank là mô hình giả lập dùng để minh họa phương pháp; tình huống và số liệu trong bài không đại diện cho một ngân hàng thực tế.

5. Learn bắt đầu từ việc hỏi “Tại sao chuyện này đã xảy ra?”

Nếu Learn chỉ là ghi một dòng “lesson learned” rồi lưu file, bước cuối của Risk Management sẽ không tạo ra nhiều giá trị.

Một bài học tốt cần đi sâu hơn. Không chỉ hỏi chuyện gì đã xảy ra, mà còn hỏi tại sao chúng ta không nhìn thấy sớm hơn, Control nào đã hoạt động tốt, Control nào chỉ tồn tại trên giấy, Evidence nào đã giúp phát hiện vấn đề, assumption nào trước đây sai, Decision nào đã đúng và Decision nào đáng lẽ phải được đưa ra sớm hơn.

Learn không phải để tìm người sai. Nó để cải thiện hệ thống.

6. Bài học chỉ có giá trị khi quay trở lại hệ thống quản trị

Một bài học nếu chỉ nằm trong biên bản họp thì rất dễ bị quên.

Trong Odin Method, Learn phải quay trở lại các bước trước đó.

Nếu Objective chưa rõ, cập nhật Service Criticality hoặc Business Impact. Nếu Risk Scenario mô tả chưa đúng, sửa Risk Statement. Nếu Assessment thiếu yếu tố quan trọng, cải thiện phương pháp đánh giá. Nếu Control yếu, redesign Control. Nếu Evidence chưa đủ, bổ sung test hoặc data source. Nếu Ownership không rõ, điều chỉnh Responsibility. Nếu Decision chậm, xem lại Decision Rights hoặc Escalation. Nếu Monitoring phát hiện quá muộn, bổ sung KRI, Threshold hoặc Trigger.

Learn → Improve → Next Cycle

Nếu không có bước này, tổ chức có thể giải quyết cùng một loại Risk nhiều lần mà vẫn không trưởng thành hơn.

7. Khi nào có thể nói một Risk thực sự đã “đóng”?

Trong Odin Method, một Risk chỉ nên được coi là đóng khi ba điều cùng đúng.

Risk đã được xử lý ở mức phù hợp. Residual Risk nằm trong mức chấp nhận được hoặc Risk source không còn.

Evidence đủ để chứng minh. Không chỉ dựa vào lời xác nhận rằng “đã xử lý xong”, mà phải có Evidence cho thấy kết quả thực tế.

Decision đã được đưa ra bởi đúng người. Risk Owner hoặc cấp có thẩm quyền đã xác nhận trạng thái cuối cùng.

Sau đó, nếu Risk vẫn còn yếu tố cần theo dõi, nó phải được chuyển sang monitoring phù hợp.

Lesson phải được chuyển thành một thay đổi cụ thể.

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

Q010 hoàn thành bước thứ 8: Learn.

Và như vậy, 10 bài đầu tiên đã đưa người đọc đi qua toàn bộ logic của Odin Risk Management Method: Objective, Risk, Assess, Control, Evidence, Responsibility, Decision, Monitor và Learn.

Điểm quan trọng là chu trình không dừng lại ở Learn. Bài học mới lại quay trở về Objective, Risk, Control và cách ra quyết định của vòng tiếp theo.

Đó chính là lý do Odin Method được thiết kế như một cycle of learning and decision, không phải checklist tuyến tính.

Kết luận

Một Risk không nên được đóng chỉ vì deadline đã hết. Không nên được đóng chỉ vì remediation đã báo “Done”. Và càng không nên được đóng chỉ để Risk Register trông đẹp hơn.

Risk chỉ nên đóng khi Risk đã được xử lý đến mức phù hợp, Evidence đủ, Residual Risk đã được hiểu, đúng người đã ra quyết định và bài học đã được đưa trở lại hệ thống quản trị.

Đóng Risk là kết thúc một hồ sơ. Learn là làm cho vòng tiếp theo tốt hơn.

Đó là lúc Risk Management thực sự chuyển từ việc xử lý vấn đề sang xây dựng năng lực tổ chức.

TURN RISK INTO VALUE.

Đọc tiếp trong ODIN 101

← Q009: Sau khi đã quyết định, làm sao biết rủi ro đang tốt lên hay xấu đi?

Bắt đầu từ Q001: Quản trị rủi ro thực sự bắt đầu từ đâu?

Đọc tiếp → Q011: Một tổ chức có thể chấp nhận rủi ro đến mức nào?

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

Tài liệu tham khảo

ISO 31000:2018 — Risk Management — Guidelines — Monitoring, Review, Recording and Reporting.

ISACA / CRISC — Risk Monitoring, Risk Response, Risk Ownership và lessons from risk events.

COBIT 2019 — Performance Monitoring, Governance Information và Continual Improvement.

NIST Cybersecurity Framework 2.0 — Improvement và lessons learned trong Govern, Identify, Respond và Recover.