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

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

Monitoring không phải để tạo thêm dashboard. Monitoring để biết khi nào phải hành động.

Ở Q008, chúng ta đã đi đến một bước quan trọng: với một Risk, tổ chức sẽ tránh, giảm thiểu, chia sẻ/chuyển giao hay chấp nhận.

Nhưng ra quyết định chưa phải là kết thúc.

Giả sử hôm nay chúng ta chấp nhận một Risk vì mức rủi ro còn lại vẫn trong giới hạn cho phép. Ba tháng sau, lượng giao dịch tăng mạnh, hệ thống có thêm một dependency mới hoặc một Control bắt đầu hoạt động kém đi.

Quyết định cũ có còn phù hợp không?

Đó là lý do trong Odin Risk Management Method, Decision luôn đi cùng Monitor:

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

Monitor không đơn giản là “theo dõi”. Nó phải giúp trả lời một câu hỏi rất thực tế:

Có điều gì đang thay đổi khiến chúng ta cần xem lại quyết định trước đây không?

1. Đừng chỉ nhìn Risk Score

Một Risk Register có thể ghi Risk Level: Medium. Ba tháng sau vẫn là Medium. Nhìn qua, có vẻ không có gì thay đổi.

Nhưng thực tế phía sau con số đó có thể rất khác: số lượng khách hàng tăng, giao dịch tăng, hệ thống vừa thay đổi, một nhà cung cấp gặp sự cố, một Control có thêm nhiều exception, hoặc một sự cố thực tế cho thấy Impact lớn hơn chúng ta từng nghĩ.

Risk Score chỉ cho chúng ta biết Risk đang được đánh giá thế nào tại một thời điểm. Nó không nhất thiết cho biết Risk đang đi theo hướng nào.

Risk đang tốt lên, giữ nguyên hay đang xấu đi?

2. Risk thường thay đổi vì bốn thứ rất quen thuộc

Không cần một mô hình quá phức tạp để bắt đầu Monitoring. Chỉ cần để ý bốn nhóm thay đổi.

Objective thay đổi. Một dịch vụ trở nên quan trọng hơn thì cùng một sự cố cũng có thể tạo ra hậu quả lớn hơn trước.

Môi trường Risk thay đổi. Threat mới xuất hiện, vulnerability mới được phát hiện, hệ thống có thêm dependency hoặc vendor thay đổi dịch vụ.

Control thay đổi. Backup vẫn chạy nhưng lâu rồi chưa restore thử. MFA vẫn tồn tại nhưng số exception tăng. DR site vẫn có nhưng production đã thay đổi rất nhiều kể từ lần test gần nhất.

Evidence thay đổi. Một test mới, một incident mới hay một audit finding mới có thể cho thấy những gì chúng ta từng tin là đúng nay không còn đúng nữa.

Vì vậy Monitor thực chất là việc liên tục hỏi: Objective, Risk, Control hay Evidence có gì thay đổi không?

3. KPI, KRI và KCI có thể hiểu rất đơn giản

Ba thuật ngữ này thường làm Risk Monitoring trở nên khó hiểu hơn mức cần thiết.

KPI — Key Performance Indicator cho biết dịch vụ đang chạy thế nào. Ví dụ: Availability có đạt không? Transaction có thành công không? Recovery mất bao lâu?

KRI — Key Risk Indicator cho biết Risk có dấu hiệu tăng lên không. Ví dụ: Critical vulnerability quá hạn có tăng không? Replication lag có xảy ra thường xuyên hơn không? Có nhiều dependency chưa được recovery test không?

KCI — Key Control Indicator cho biết Control đang hoạt động tốt không. Ví dụ: Restore test có thành công không? MFA coverage còn đủ không? Automated recovery workflow có chạy ổn định không?

Một cách nhớ đơn giản: KPI nhìn Performance. KRI nhìn Risk. KCI nhìn Control.

Ba góc nhìn này bổ sung cho nhau. Một service vẫn có thể đang chạy tốt trong khi Risk bên dưới đang tăng. Đó là lý do dashboard “toàn màu xanh” chưa chắc đã đồng nghĩa với mọi thứ đang an toàn.

4. Case Odin Lab Bank: một Risk đã được Accept thì theo dõi gì?

Hãy tiếp tục với Digital Payment Service của Odin Lab Bank.

Trong Q008, giả sử OLB chấp nhận tạm thời một Recovery Risk. Kết quả DR exercise cho thấy Infrastructure đã phục hồi, Data đã restore, Critical transaction đã chạy lại, nhưng tổng thời gian phục hồi vẫn hơi vượt RTO vì một bước thủ công.

OLB quyết định chấp nhận Risk này trong ba tháng trong khi tiếp tục cải tiến automation.

Nếu sau đó Risk Register chỉ ghi Status: Accepted thì chưa đủ.

Risk Owner vẫn cần nhìn một vài tín hiệu rất đơn giản: Recovery Time đang giảm hay tăng? Số bước manual còn bao nhiêu? Replication có phát sinh exception không? Từ lần DR test trước tới nay hệ thống có bao nhiêu thay đổi lớn? Các recovery test nhỏ gần đây có còn thành công không? Có incident hoặc near miss nào mới không?

Nếu các tín hiệu này bắt đầu xấu đi, OLB không cần đợi đủ ba tháng mới xem xét lại. Risk có thể cần được mở lại ngay.

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. Một chỉ số chỉ thực sự hữu ích khi biết lúc nào phải hành động

Giả sử OLB theo dõi số lần replication lag vượt mức cho phép. Nếu chỉ báo cáo Tháng này: 4 lần thì người quản lý vẫn phải hỏi: “4 lần thì sao?”

Vì vậy Monitoring cần có Threshold — ngưỡng.

Có thể hiểu đơn giản: Green — tiếp tục theo dõi; Amber — cần kiểm tra; Red — phải đánh giá lại Risk.

Điều quan trọng không phải màu sắc. Điều quan trọng là mỗi mức phải dẫn tới một hành động. Amber có thể yêu cầu Control Owner kiểm tra nguyên nhân. Red có thể yêu cầu Risk Owner đánh giá lại Residual Risk và đưa vấn đề lên cấp có thẩm quyền.

Ngoài Threshold còn có Trigger — sự kiện kích hoạt. Ví dụ: critical incident, DR test thất bại, thay đổi kiến trúc lớn, thay đổi quan trọng từ vendor hoặc business volume tăng mạnh.

Risk Review nên xảy ra khi Risk thay đổi, không chỉ khi lịch nhắc đến hạn.

6. Đừng chỉ nhìn màu xanh, hãy nhìn xu hướng

Giả sử RTO cho phép là 60 phút. Kết quả bốn lần gần nhất là 35 → 39 → 44 → 49 phút.

Tất cả đều dưới 60 phút. Nếu dashboard chỉ có một đèn xanh thì cả bốn lần đều giống nhau.

Nhưng nhìn vào Trend, chúng ta sẽ thấy một điều rất khác: Recovery Time đang xấu dần.

Một Risk Monitoring View tốt nên giúp thấy bốn thứ: hiện tại đang ở đâu, đang tốt lên hay xấu đi, ngưỡng nằm ở đâu và điều gì sẽ khiến chúng ta phải hành động.

Khi dữ liệu đã có trong monitoring platform, ITSM, CMDB, IAM, vulnerability management hay DR orchestration, nhiều indicator hoàn toàn có thể được cập nhật tự động. Lúc đó Risk Monitoring không còn phụ thuộc hoàn toàn vào việc mỗi quý mở Excel và hỏi các đơn vị cập nhật.

7. Monitor cuối cùng phải dẫn tới một hành động

Theo dõi mà không thay đổi bất kỳ quyết định nào thì rất dễ trở thành reporting.

Nếu mọi thứ vẫn ổn, tiếp tục theo dõi. Nếu Control yếu đi, Control Owner phải xử lý. Nếu Risk Exposure tăng, Risk Owner phải đánh giá lại. Nếu Risk vượt Tolerance, cần Action hoặc Escalation. Nếu bối cảnh đã thay đổi đủ lớn, Decision trước đây cũng phải được xem lại.

Monitor → Phát hiện thay đổi → Đánh giá lại → Hành động → Quyết định lại

Đây chính là điểm làm Odin Method trở thành một chu trình, thay vì một bài Risk Assessment làm xong rồi để đó.

Monitor không phải để biết thêm thông tin. Monitor để biết khi nào phải thay đổi hành động hoặc quyết định.

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

Q008 tập trung vào Decision. Q009 hoàn thiện phần Monitor.

Trong chu trình Odin: Objective → Risk → Assess → Control → Evidence → Responsibility → Decision & Monitor → Learn.

Monitor giúp chúng ta nhận ra khi Risk đã khác so với lúc Decision được đưa ra.

Nhưng vẫn còn một bước cuối cùng. Sau một incident, một DR exercise, một remediation hay một quyết định đã thực hiện, tổ chức cần hỏi:

Chúng ta học được gì và lần sau cần làm khác đi điều gì?

Đó sẽ là Q010 — Learn, bài hoàn thành vòng đầu tiên của Odin Risk Management Method.

Kết luận

Một Risk đã được Accept không có nghĩa là đã xong. Một Control hôm nay hoạt động tốt không có nghĩa nó sẽ luôn tốt. Một Decision hôm nay hợp lý không có nghĩa vài tháng sau vẫn hợp lý.

Monitoring tốt giúp chúng ta nhận ra điều gì đang thay đổi trước khi nó trở thành vấn đề lớn.

Monitoring không phải để tạo thêm dashboard. Monitoring để biết khi nào phải hành động.

TURN RISK INTO VALUE.

Đọc tiếp trong ODIN 101

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

Tiếp theo → Q010: Khi nào một Risk có thể đóng, và chúng ta phải học gì từ nó?

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

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

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

Tài liệu tham khảo

ISACA / CRISC — Risk Monitoring, Key Risk Indicators, Control Monitoring và Risk Reporting.

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

COBIT 2019 — Governance and Management Objectives, Performance Monitoring và Risk Management.

NIST Cybersecurity Framework 2.0 — Govern, Detect và Continuous Improvement outcomes.