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

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

Một phương pháp đơn giản để biến rủi ro thành quyết định

Khi nói đến quản trị rủi ro, chúng ta rất dễ bắt đầu bằng một danh sách rủi ro, một heatmap, một risk register hay một bộ kiểm soát. Nhưng đó chưa phải là điểm bắt đầu.

Câu hỏi đầu tiên nên là: Chúng ta đang cố đạt được hoặc bảo vệ điều gì?

Một rủi ro chỉ thực sự có ý nghĩa khi nó được đặt trong mối quan hệ với một mục tiêu. Nếu chưa xác định được mục tiêu cần đạt được, dịch vụ cần duy trì hay giá trị cần bảo vệ, rất khó xác định điều gì thực sự là rủi ro, rủi ro nào quan trọng và tổ chức cần đưa ra quyết định gì.

Đây là một trong những điều tôi thấy giá trị trong cách Dr David Hillson diễn giải risk management. Thay vì bắt đầu bằng một quy trình phức tạp, ông đưa quản trị rủi ro về những câu hỏi rất tự nhiên: Chúng ta muốn đạt điều gì? Điều gì có thể ảnh hưởng đến mục tiêu đó? Điều gì quan trọng nhất? Chúng ta sẽ làm gì? Hành động có hiệu quả không? Điều gì đã thay đổi? Và chúng ta học được gì?

Cách tiếp cận này cũng gần với nhiều nguyên tắc tôi học được từ CRISC của ISACA. Quản trị rủi ro công nghệ cần được đặt trong bối cảnh của business objectives, governance và risk context, trước khi đi sâu vào risk assessment, response, controls, monitoring và reporting.

Từ những nền tảng đó, kết hợp với góc nhìn thực hành về Technology Risk, GRC, Audit và Resilience, tôi sử dụng tại Odin Lab một chuỗi tám câu hỏi. Tôi gọi cách tiếp cận này là Odin Risk Management Method.

Mô hình gồm tám bước: Objective, Risk, Assess, Control, Evidence, Responsibility, Decision & Monitor, Learn. Đây không phải một tiêu chuẩn mới nhằm thay thế ISO 31000, COBIT, NIST hay ISACA CRISC. Tôi coi nó là một khung thực hành (applied practice framework) giúp đơn giản hóa cách tư duy và kết nối mục tiêu, rủi ro, kiểm soát, bằng chứng và trách nhiệm với quyết định quản trị.

1. Objective — Chúng ta đang cố đạt được hoặc bảo vệ điều gì?

Quản trị rủi ro không nên bắt đầu bằng threat, vulnerability hay control. Nó nên bắt đầu bằng objective.

Trong một ngân hàng số, objective có thể là duy trì một dịch vụ thanh toán trong mức độ sẵn sàng đã cam kết, bảo vệ tính bí mật và toàn vẹn của dữ liệu, đáp ứng nghĩa vụ pháp lý, duy trì khả năng phục hồi của một dịch vụ trọng yếu hoặc triển khai một công nghệ mới trong mức rủi ro mà tổ chức chấp nhận.

Điểm quan trọng là phải xác định được điều gì tạo ra giá trị hoặc cần được bảo vệ. CRISC cũng đặt strategy, goals and objectives cùng risk appetite và risk tolerance trong phạm vi Governance. Nếu objective không rõ, rất khó xác định risk đúng. Và nếu risk được xác định sai, những bước tiếp theo như assessment, control hay monitoring dù được thực hiện rất bài bản vẫn có thể đang tập trung vào sai vấn đề.

2. Risk — Điều gì có thể ảnh hưởng đến mục tiêu?

Khi objective đã rõ, câu hỏi tiếp theo là: Điều gì không chắc chắn có thể xảy ra và ảnh hưởng đến việc đạt mục tiêu đó?

Một lỗi phổ biến là mô tả risk quá chung chung, chẳng hạn “rủi ro hệ thống bị gián đoạn”. Cách diễn đạt này cho biết chủ đề nhưng chưa cung cấp đủ thông tin để phân tích và ra quyết định.

Một risk scenario hữu ích hơn cần thể hiện được quan hệ giữa nguyên nhân (cause), sự kiện (event) và tác động (impact). Ví dụ, tại ngân hàng giả lập Odin Lab Bank, có thể mô tả: Do một dependency công nghệ trọng yếu không sẵn sàng tại thời điểm cần chuyển đổi, dịch vụ thanh toán có thể không được phục hồi trong thời gian yêu cầu, dẫn đến vượt ngưỡng gián đoạn mà ngân hàng chấp nhận.

Cách mô tả này giúp risk chuyển từ một khái niệm chung thành một scenario có thể phân tích: nguyên nhân nằm ở dependency; sự kiện là quá trình phục hồi không đáp ứng yêu cầu; và tác động cuối cùng nằm ở business service.

3. Assess — Risk nào thực sự quan trọng?

Không phải mọi risk đều cần được xử lý giống nhau, trong khi nguồn lực của tổ chức luôn hữu hạn. Vì vậy, assessment phải giúp xác định risk nào thực sự cần sự chú ý và mức risk exposure hiện tại là bao nhiêu.

Tùy bối cảnh, assessment có thể xem xét likelihood hoặc frequency, impact, business criticality, threats, vulnerabilities, existing controls, inherent risk và residual risk. Đối với các dịch vụ trọng yếu, Business Impact Analysis cũng cung cấp những dữ liệu quan trọng về mức độ ảnh hưởng, dependency, RTO và RPO.

Tuy nhiên, mục tiêu của assessment không phải là tạo ra một risk score thật đẹp. Một con số hay một ô màu đỏ trên heatmap tự nó chưa tạo ra giá trị. Assessment chỉ thực sự hữu ích khi giúp người có trách nhiệm hiểu risk exposure, so sánh nó với risk appetite hoặc tolerance và có đủ thông tin để ra quyết định.

4. Control — Chúng ta sẽ làm gì?

Khi risk exposure vượt quá mức tổ chức có thể chấp nhận, cần lựa chọn response phù hợp. Tổ chức có thể chấp nhận, tránh, chuyển giao hoặc chia sẻ, hoặc giảm thiểu rủi ro tùy theo bối cảnh.

Nếu lựa chọn mitigation, câu hỏi quan trọng là control nào có khả năng làm thay đổi risk exposure theo hướng mong muốn. Với scenario gián đoạn dịch vụ ở trên, controls có thể bao gồm kiến trúc dự phòng, replication, backup và restore, monitoring, emergency access, recovery procedures, DR automation hoặc recovery testing.

Có control trên giấy chưa đủ. Control phải được thiết kế phù hợp với risk, được triển khai đúng và vận hành hiệu quả. Một control chỉ có giá trị khi nó thực sự góp phần làm thay đổi mức risk exposure mà tổ chức đang phải đối mặt.

5. Evidence — Làm sao biết control thực sự hoạt động?

Đây là điểm tôi muốn nhấn mạnh trong Odin Risk Management Method.

Một policy quy định phải backup không chứng minh rằng dữ liệu có thể restore. Một tài liệu DR mô tả hệ thống có site dự phòng không chứng minh rằng dịch vụ có thể phục hồi trong RTO. Một dashboard màu xanh cũng chưa đủ để khẳng định control effectiveness.

Vì vậy, câu hỏi cần đặt ra là: Bằng chứng nào chứng minh control được thiết kế phù hợp và đang hoạt động như kỳ vọng?

Evidence có thể là configuration, logs, monitoring data, tickets, approvals, control test results, backup/restore results, recovery exercise results, audit trails hoặc independent assessments. Quan trọng hơn, bằng chứng phải giúp trả lời được hai câu hỏi khác nhau: control có được thiết kế phù hợp với risk cần xử lý hay không (design effectiveness), và control có thực sự vận hành ổn định như thiết kế hay không (operating effectiveness).

Đó là lý do tôi chủ động đưa Evidence thành một bước độc lập. Nó tạo cầu nối giữa Risk Management, Controls, GRC và Audit & Assurance; đồng thời chuyển câu hỏi từ “Chúng ta có control không?” thành “Chúng ta có thể chứng minh control đó hiệu quả không?”.

Hình trên cũng cho thấy một điểm quan trọng: risk management và assurance không phải hai thế giới tách biệt. Risk giúp xác định điều gì cần bảo vệ và kiểm soát; evidence và assurance giúp xác nhận các kiểm soát đó có thực sự tạo ra mức độ tin cậy cần thiết hay không.

6. Responsibility — Ai chịu trách nhiệm?

Risk không thể được quản lý chỉ bởi Risk Department. Một risk scenario cần xác định rõ risk owner, control owner và action owner; đồng thời phải xác định người có đủ thẩm quyền để chấp nhận residual risk.

Risk Owner chịu trách nhiệm đối với risk và các quyết định liên quan. Control Owner chịu trách nhiệm đối với thiết kế, vận hành hoặc duy trì control. Action Owner chịu trách nhiệm thực hiện một hành động cụ thể. Trong những trường hợp cần chấp nhận residual risk, authority cũng phải được xác định tương ứng với mức độ rủi ro.

Nếu accountability không rõ, risk register rất dễ trở thành nơi ghi nhận những vấn đề mà nhiều người biết nhưng không ai thực sự sở hữu. Vì vậy, risk, control, action và decision đều cần một chủ thể chịu trách nhiệm rõ ràng.

7. Decision & Monitor — Chúng ta cần quyết định gì và điều gì đang thay đổi?

Đây là nơi risk management tạo ra giá trị thực sự.

Sau assessment, controls và evidence, câu hỏi quan trọng không còn chỉ là “Risk score là bao nhiêu?” mà phải chuyển thành “Chúng ta cần quyết định gì?”. Có thể cần chấp nhận risk, giảm thiểu thêm, chuyển giao, tránh, đầu tư thêm, thay đổi kiến trúc, tăng resilience hoặc chấp nhận residual risk trong một khoảng thời gian với các điều kiện cụ thể.

Nhưng một quyết định tốt vẫn chưa phải điểm kết thúc. Risk là động: technology thay đổi, threat landscape thay đổi, business objectives thay đổi, control có thể suy giảm hiệu quả và dependency mới có thể xuất hiện. Vì vậy, tổ chức cần tiếp tục theo dõi risk exposure, control effectiveness và service performance thông qua các chỉ báo phù hợp như KRI, KCI và KPI.

Risk management vì thế không kết thúc khi risk register được cập nhật. Nó chỉ thực sự tạo ra giá trị khi risk information được chuyển hóa thành management decision.

8. Learn — Chúng ta học được gì?

Môi trường thay đổi, công nghệ thay đổi, threats thay đổi và business objectives cũng thay đổi. Vì vậy, vòng quản trị cần có khả năng học.

David Hillson kết thúc chuỗi câu hỏi của risk process bằng một câu rất đơn giản: “What did we learn?” Đây cũng là bước rất dễ bị bỏ quên.

Sau một incident, control test, audit finding, DR exercise, near miss hay một quyết định chấp nhận risk, tổ chức cần xem lại điều gì đã hoạt động tốt, điều gì không hoạt động như kỳ vọng, giả định nào không còn đúng và những thay đổi nào cần đưa trở lại architecture, policy, process, controls hoặc training.

Nếu những bài học đó không quay trở lại vòng quản trị, tổ chức có nguy cơ tiếp tục quản lý rủi ro của ngày hôm qua bằng những kiểm soát của ngày hôm qua. Learn vì thế không phải là điểm kết thúc. Những gì học được có thể làm thay đổi context và thậm chí thay đổi chính objective, từ đó bắt đầu một vòng quản trị mới.

Từ phương pháp đến thực hành: một ví dụ tại Odin Lab Bank

Hãy áp dụng toàn bộ phương pháp vào một tình huống giả lập tại Odin Lab Bank.

Ngân hàng đặt mục tiêu duy trì dịch vụ thanh toán số trong ngưỡng sẵn sàng và gián đoạn đã được phê duyệt. Một risk scenario được xác định: dependency công nghệ trọng yếu có thể không sẵn sàng khi cần chuyển đổi sang môi trường dự phòng, khiến dịch vụ không phục hồi trong thời gian yêu cầu.

Sau khi đánh giá criticality, dependencies, likelihood, impact và existing controls, ngân hàng triển khai các resilience controls như kiến trúc dự phòng, replication, backup/restore, monitoring, emergency access, recovery runbook và DR automation. Tuy nhiên, việc các controls này tồn tại chưa đủ. Configuration, logs, restore tests và kết quả DR exercises phải cung cấp evidence về khả năng phục hồi thực tế.

Dựa trên assessment và evidence, residual risk được xác định và so sánh với risk appetite. Management khi đó mới có đủ thông tin để quyết định chấp nhận risk, tiếp tục giảm thiểu hay đầu tư thêm. KRI và KCI tiếp tục theo dõi sự thay đổi, còn kết quả incident, testing và exercises trở thành đầu vào cho vòng cải tiến tiếp theo.

Ví dụ này cho thấy sự khác biệt giữa ghi nhận rủi ro và quản trị rủi ro. Một bên kết thúc ở risk register; bên còn lại tiếp tục cho đến khi tổ chức có đủ evidence để đưa ra quyết định và học từ kết quả thực tế.

Risk management cuối cùng phải dẫn đến một quyết định

Odin Risk Management Method không nhằm tạo thêm một standard hay thay thế ISO 31000, COBIT, NIST, ISACA CRISC hoặc các framework quản trị khác. Đây là một applied practice framework mà Odin Lab sử dụng để kết nối những khái niệm đôi khi đang tồn tại riêng rẽ: business objectives, Technology Risk, controls, evidence, GRC, Audit & Assurance, Resilience và management decision.

Điều quan trọng nhất không phải tổ chức có bao nhiêu risk trong risk register, cũng không phải heatmap có bao nhiêu ô màu đỏ. Câu hỏi cuối cùng vẫn là: Thông tin về rủi ro có giúp tổ chức đưa ra quyết định tốt hơn không?

Risk management không nên kết thúc ở việc biết chúng ta có rủi ro gì. Nó phải giúp chúng ta biết cần làm gì, chứng minh việc đó có hiệu quả, xác định ai chịu trách nhiệm, theo dõi điều gì đang thay đổi và đưa ra quyết định tốt hơn.

Đó cũng là ý nghĩa của thông điệp mà Odin Lab theo đuổi: TURN RISK INTO VALUE.

Tài liệu tham khảo

Dr David Hillson, Seven Questions to Shape the Risk Process, Risk Doctor: risk-doctor.com.

ISACA, CRISC Exam Content Outline: isaca.org.

ISO, ISO 31000:2018 Risk Management — Guidelines: iso.org.

Odin Risk Management Method là khung thực hành do Odin Lab tổng hợp và phát triển để diễn giải và áp dụng các nguyên tắc quản trị rủi ro trong Banking Technology, Technology Risk, GRC, Audit, Resilience và AI. Đây không phải framework chính thức của Risk Doctor, ISACA, ISO, COBIT hay NIST.