Q008 — Khi đối mặt với rủi ro, nên tránh, giảm, chia sẻ hay chấp nhận?

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

Risk Response không phải là chọn một nhãn; đó là quyết định quản trị dựa trên mục tiêu, bằng chứng và mức rủi ro còn lại.

Trong Q007, chúng ta đã làm rõ ai chịu trách nhiệm về Risk, ai chịu trách nhiệm về Control, ai thực hiện Action và ai có quyền ra quyết định.

Nhưng khi trách nhiệm đã rõ, tổ chức vẫn phải trả lời một câu hỏi quan trọng hơn:

Với Risk này, chúng ta thực sự sẽ làm gì?

Đó là bài toán Risk Response — Ứng phó rủi ro.

Trong thực tế, rất nhiều Risk Register có Risk Score, Heatmap, Owner và Controls nhưng vẫn thiếu một quyết định rõ ràng. Risk được đánh giá là “High”, một số Actions được mở, nhưng tổ chức chưa thực sự xác định mình đang tránh, giảm thiểu, chia sẻ/chuyển giao hay chấp nhận Risk đó.

Tại Odin Lab, Risk Response không được xem là một bước tách biệt để chọn từ danh sách phương án. Nó là kết quả của toàn bộ chu trình:

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

Nói cách khác, muốn chọn đúng Risk Response, trước hết phải hiểu đúng mục tiêu, Risk, mức độ Risk, Control hiện có, Evidence và người có trách nhiệm.

1. Không phải mọi Risk đều cần bị loại bỏ

Mục tiêu của Risk Management không phải đưa mọi Risk về zero.

Nếu tổ chức cố loại bỏ toàn bộ Risk, tổ chức cũng có thể loại bỏ luôn cơ hội đổi mới, mở rộng hoặc tạo ra giá trị mới.

Một sản phẩm ngân hàng số mới có thể tạo thêm Technology Risk, Cyber Risk hoặc Third-party Risk. Nhưng nếu Business Value đủ lớn và Risk vẫn nằm trong phạm vi có thể quản trị, việc chấp nhận một phần Risk có thể hoàn toàn hợp lý.

Mức Risk nào có thể chấp nhận được để vẫn đạt Objective?

Trong thực hành, Risk thường được xử lý theo một số hướng chính: Avoid — Tránh, Mitigate — Giảm thiểu, Share / Transfer — Chia sẻ hoặc chuyển giao, và Accept — Chấp nhận. Trong một số trường hợp, tổ chức còn có thể chủ động nhận thêm Risk để theo đuổi Value hoặc Opportunity.

Response phù hợp là response giúp đạt Objective với mức Risk có thể chấp nhận được.

2. Risk Response phải bắt đầu từ Objective

Đây là điểm rất quan trọng trong Odin Method. Không nên bắt đầu bằng câu “Risk này màu đỏ, vậy phải Mitigate”, cũng không nên bắt đầu bằng “Risk này điểm thấp, vậy Accept”.

Hai Risk có cùng Risk Score nhưng có thể yêu cầu hai quyết định hoàn toàn khác nhau nếu chúng ảnh hưởng đến những Objective khác nhau. Một Risk ảnh hưởng trực tiếp tới critical service có thể cần đầu tư mạnh để giảm xuống. Một Risk khác cùng điểm số nhưng ảnh hưởng nhỏ, dễ phục hồi hoặc nằm trong tolerance có thể được chấp nhận.

Vì vậy Risk Score chỉ là một tín hiệu. Trong Odin Method, điểm xuất phát luôn là Objective — Chúng ta đang cố đạt được hoặc bảo vệ điều gì?

Từ đó mới đi tiếp qua Risk, Assess, Control, Evidence và Responsibility trước khi tới Decision & Monitor.

3. Tránh, giảm, chia sẻ hay chấp nhận khác nhau thế nào trong thực tế?

Avoid — Tránh. Phù hợp khi hoạt động tạo ra Risk không còn hợp lý hoặc không thể đưa Risk về mức chấp nhận được. Ví dụ, một tính năng mới yêu cầu xử lý dữ liệu nhạy cảm nhưng kiến trúc hiện tại không thể bảo vệ phù hợp. Thay vì cố thêm nhiều Controls vào một thiết kế không phù hợp, tổ chức có thể trì hoãn, thay đổi phạm vi hoặc không triển khai tính năng đó.

Mitigate — Giảm thiểu. Đây là hướng phổ biến nhất trong Technology Risk. Tổ chức bổ sung hoặc cải thiện Controls như redundancy, MFA, segmentation, monitoring, automation, restore test, DR exercise hoặc hardening để làm giảm Risk. Nhưng Mitigate không nên được hiểu là “càng nhiều Control càng tốt”. Một Control chỉ có giá trị khi nó thực sự làm thay đổi Risk và có Evidence chứng minh được hiệu quả.

Share / Transfer — Chia sẻ hoặc chuyển giao. Một phần hậu quả của Risk có thể được chia sẻ hoặc chuyển giao thông qua contract, insurance, outsourcing, SLA hoặc các cơ chế tài chính và pháp lý phù hợp. Tuy nhiên, Share/Transfer hiếm khi làm Risk biến mất hoàn toàn. Một nhà cung cấp cloud có thể chịu trách nhiệm về một phần infrastructure, nhưng ngân hàng vẫn phải chịu trách nhiệm với khách hàng, service outcome và nghĩa vụ quản trị của mình.

Transfer một phần trách nhiệm không đồng nghĩa với chuyển toàn bộ Risk ra khỏi tổ chức.

Accept — Chấp nhận. Đây là quyết định giữ lại Residual Risk. Nhưng Accept không có nghĩa là “không làm gì”. Risk cần được hiểu đủ rõ, Controls và Evidence phải được xem xét, Residual Risk phải được đánh giá, đúng cấp thẩm quyền phải phê duyệt và Risk tiếp tục được Monitor.

Risk Acceptance là một quyết định quản trị; bỏ mặc Risk không phải là Risk Acceptance.

4. Case Odin Lab Bank: Recovery Risk nên xử lý thế nào?

Hãy tiếp tục với Digital Payment Service tại Odin Lab Bank. Objective là bảo đảm dịch vụ có thể phục hồi trong RTO đã được phê duyệt.

Sau một DR exercise, Evidence cho thấy hạ tầng dự phòng sẵn sàng, dữ liệu restore thành công, application và các dependency chính hoạt động, critical transaction được xác nhận, nhưng tổng recovery time vẫn cao hơn mục tiêu do một bước vận hành thủ công.

Risk đã giảm đáng kể, nhưng chưa biến mất. Lúc này OLB không nên kết luận đơn giản rằng “gần đạt RTO rồi, Accept”, cũng không nên mặc định “không đạt RTO thì phải Mitigate bằng mọi giá”.

Nếu xử lý thêm có hiệu quả và hợp lý, OLB có thể chọn Mitigate bằng cách tự động hóa bước thủ công hoặc thay đổi recovery workflow. Nếu phần Risk còn lại nhỏ và nằm trong tolerance, OLB có thể Accept có điều kiện với review date, monitoring, trigger và remediation action nếu cần. Nếu Risk vượt tolerance hoặc vượt thẩm quyền, Risk phải được Escalate tới đúng Decision Authority.

Nếu một phần dependency thuộc nhà cung cấp, OLB có thể Share/Transfer một phần Risk thông qua SLA, contractual obligation hoặc cơ chế bồi thường.

Điểm quan trọng là Response không xuất phát từ cảm giác “gần đạt rồi”. Nó phải dựa trên Evidence + Residual Risk + Appetite/Tolerance + Cost + Feasibility + Authority.

5. Một quyết định Risk tốt phải cân bằng bốn yếu tố

Objective. Response có giúp bảo vệ hoặc đạt Objective không? Một Control có thể rất mạnh về security nhưng nếu làm dịch vụ không thể vận hành hiệu quả thì chưa chắc tạo ra Value.

Residual Risk. Sau response, Risk còn lại là gì? Đây mới là mức Risk cần được quản trị.

Cost & Feasibility. Việc giảm Risk thêm có đáng với chi phí, độ phức tạp và thời gian triển khai hay không? Một response có thể chỉ giảm Risk rất ít nhưng tạo thêm nhiều operational burden.

Authority. Ai có quyền chấp nhận mức Risk còn lại? Risk Owner có thể đề xuất, nhưng không phải Risk nào cũng nằm trong quyền chấp nhận của Risk Owner.

Bốn góc nhìn này giúp Risk Response chuyển từ một bài tập compliance thành một quyết định quản trị thực sự.

6. Chấp nhận Risk phải có thời hạn và điều kiện xem xét lại

Risk Acceptance không nên là một quyết định vô thời hạn. Risk Exposure thay đổi theo thời gian. Hệ thống thay đổi. Threat thay đổi. Business volume tăng. Control có thể suy giảm. Dependency có thể thay đổi.

Vì vậy một Risk được Accept nên có ít nhất Review Date, Monitoring, Trigger và Escalation Rule.

Ví dụ, OLB có thể Accept một Recovery Risk trong ba tháng trong khi remediation đang được triển khai. Nhưng nếu trong thời gian đó xảy ra incident, RTO tiếp tục bị vượt, Control Effectiveness giảm hoặc Business Impact tăng, Risk phải được xem xét lại ngay.

Acceptance không phải dấu chấm hết. Nó là một Decision có điều kiện và phải được Monitor.

7. Risk Response phải tạo ra một trạng thái quản trị rõ ràng

Sau Assessment, Controls, Evidence và Responsibility, Risk không nên tồn tại lâu trong trạng thái Open — đang xem xét.

Cần xác định rõ hướng xử lý: Avoid, Mitigate, Share / Transfer, Accept hoặc Escalate lên đúng cấp thẩm quyền.

Nhưng tên response vẫn chưa đủ. Một quyết định tốt phải ghi rõ ai quyết định, Evidence nào hỗ trợ, Residual Risk là gì, Actions nào còn mở, Review Date khi nào và Trigger nào buộc phải xem xét lại.

Đây là cách biến Risk Response từ một cột trong Risk Register thành một phần thực sự của Governance.

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

Trong Odin Method: Objective → Risk → Assess → Control → Evidence → Responsibility → Decision & Monitor → Learn.

Q008 tập trung vào Decision & Monitor. Nhưng Decision không phải là một bước độc lập đứng cuối quy trình. Nó là kết quả của toàn bộ chu trình trước đó.

Không hiểu Objective thì khó biết Risk nào đáng quan tâm. Không Assess thì khó biết Risk quan trọng đến đâu. Không hiểu Control thì không biết Risk đã được xử lý thế nào. Không có Evidence thì không biết Control có hiệu quả không. Không rõ Responsibility thì không biết ai phải hành động và ai có quyền quyết định.

Và nếu không có Decision, toàn bộ quá trình Risk Management chỉ dừng lại ở việc mô tả vấn đề.

Risk Response không phải chọn một nhãn. Đó là quyết định dựa trên Evidence để cân bằng Risk và Value.

Sau Decision, Odin Method vẫn chưa kết thúc. Risk phải tiếp tục được Monitor. Và khi điều kiện thay đổi, tổ chức phải quay lại các bước trước đó để đánh giá lại. Đó chính là lý do Odin Method được thiết kế như một chu trình, không phải một workflow tuyến tính chỉ chạy một lần.

Kết luận

Khi đối mặt với Risk, tổ chức có thể tránh, giảm thiểu, chia sẻ, chuyển giao hoặc chấp nhận. Trong một số trường hợp, tổ chức còn có thể chủ động nhận thêm Risk để theo đuổi Opportunity và Value.

Điều quan trọng không phải nhớ tên các response. Điều quan trọng là hiểu Objective nào đang cần bảo vệ, Residual Risk còn lại là gì, Evidence nói gì về Control Effectiveness, Risk có nằm trong Appetite/Tolerance không, chi phí xử lý thêm có hợp lý không và ai có quyền quyết định.

Một Risk tốt không kết thúc bằng một Risk Score. Nó phải dẫn tới:

một quyết định có căn cứ, đúng thẩm quyền, có điều kiện theo dõi và có khả năng thay đổi khi bối cảnh thay đổi.

TURN RISK INTO VALUE.

Đọc tiếp trong ODIN 101

← Q007: Khi rủi ro xảy ra, ai thực sự chịu trách nhiệm?

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

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

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

Tài liệu tham khảo

ISACA / CRISC — Risk Response, Risk Ownership, Residual Risk và Risk Acceptance.

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

COBIT 2019 — Governance, Accountability và Decision Rights.

NIST Cybersecurity Framework 2.0 — Govern và Risk Management Outcomes.