Q015 — Càng nhiều Control có luôn làm ít Risk hơn?

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

Nhiều Control hơn chưa chắc tốt hơn.

Khi một Risk được đánh giá là cao, phản ứng khá tự nhiên là bổ sung thêm Control:

• Thêm bước phê duyệt;
• Thêm checklist;
• Thêm người kiểm tra;
• Thêm báo cáo;
• Thêm Evidence.

Sau một thời gian, tổ chức có thể có rất nhiều Control nhưng Risk vẫn chưa thực sự được kiểm soát. Quy trình lại chậm hơn, chi phí tăng và người thực hiện bắt đầu tìm cách “đi vòng” vì Control quá phức tạp.

Vì vậy, câu hỏi quan trọng không phải là:

Chúng ta có bao nhiêu Control?

Mà là:

Control có thực sự làm thay đổi Risk theo hướng mong muốn hay không?

Nội dung chính

1. Control tồn tại không có nghĩa Risk đã được kiểm soát.
2. Quá nhiều Control cũng có thể tạo Risk mới.
3. Case OLB: Recovery Process có nhiều Control nhưng vẫn chậm.
4. OLB chuyển từ “thêm Control” sang Control Rationalization.
5. Ít Control hơn nhưng Risk được kiểm soát tốt hơn.
6. Control tốt phải đồng thời bảo vệ Risk và hỗ trợ Objective.
7. Control Optimization chính là một cách Turn Risk into Value.

1. Control tồn tại không có nghĩa Risk đã được kiểm soát

Một Control có thể tồn tại đầy đủ trên giấy nhưng không thực sự hiệu quả.

Ví dụ:

• Checklist có nhưng người thực hiện chỉ tick cho đủ;
• Approval có nhưng người phê duyệt không đủ thông tin để quyết định;
• Dashboard có nhưng không cho biết Risk đang tăng hay giảm;
• Log được lưu nhưng không có ai review;
• Bằng chứng tồn tại nhưng không chứng minh được Control đã vận hành đúng.

Đây là khác biệt giữa Control Activity và Control Effectiveness.

Một tổ chức có thể có rất nhiều hoạt động kiểm soát nhưng assurance thực tế vẫn thấp.

Control không được đánh giá bằng việc nó tồn tại. Control phải được đánh giá bằng việc nó làm thay đổi Risk như thế nào.

Liên quan: Q005 — Một kiểm soát tốt phải làm thay đổi rủi ro như thế nào?

2. Quá nhiều Control cũng có thể tạo ra Risk mới

Một Control luôn có chi phí.

Không chỉ là chi phí tài chính, mà còn có thể làm tăng:

• Thời gian xử lý;
• Độ phức tạp;
• Số điểm hand-off;
• Số dependency;
• Khối lượng Evidence;
• Khả năng phát sinh lỗi thao tác;
• Thời gian ra quyết định.

Ví dụ, một thay đổi nhỏ phải qua sáu lớp approval có thể giảm Risk sai thay đổi, nhưng lại làm tăng Risk do phản ứng quá chậm.

Một Recovery Process có quá nhiều bước kiểm tra thủ công có thể tạo cảm giác “an toàn”, nhưng Recovery Time lại vượt RTO.

Một hệ thống có nhiều Control vì vậy chưa chắc là hệ thống được kiểm soát tốt.

Nó có thể chỉ là một hệ thống được kiểm soát nhiều.

Control cũng có thể trở thành nguồn tạo Risk nếu nó làm tăng Complexity và Friction quá mức cần thiết.

3. Case OLB: Recovery Process có nhiều Control nhưng vẫn chậm

Hãy xem tình huống tại Odin Lab Bank (OLB).

OLB vận hành Digital Payment Service, một dịch vụ cần được phục hồi trong thời gian xác định khi xảy ra Disruption.

Để giảm Recovery Risk, OLB đã bổ sung khá nhiều Control.

Trước tối ưu, quy trình có:

• Nhiều checklist theo từng nhóm;
• Nhiều approval thủ công;
• Nhiều bước pre-check;
• Nhiều điểm xác nhận sau Recovery;
• Evidence nằm rải rác trong ticket, email, log và file checklist;
• Một số bước phụ thuộc mạnh vào kinh nghiệm cá nhân.

Nhìn vào Control Inventory, quy trình có vẻ rất chặt.

Nhưng qua các Recovery Test, OLB phát hiện:

• Recovery Time vẫn cao;
• Một số bước kiểm tra bị lặp;
• Nhiều Control cùng kiểm tra một Risk;
• Evidence phân tán;
• Người thực hiện phải chuyển qua nhiều hệ thống;
• Residual Risk vẫn đáng kể.

Vấn đề lúc này không còn là thiếu Control.

Vấn đề là Control chưa được thiết kế xoay quanh Risk thực sự cần kiểm soát.

4. OLB chuyển từ “thêm Control” sang Control Rationalization

Thay vì tiếp tục bổ sung checklist, OLB thực hiện Control Rationalization — hợp lý hóa và tối ưu Control.

Mỗi Control được review bằng bốn câu hỏi.

1. Control này đang xử lý Risk nào?

Nếu không thể chỉ ra Risk cụ thể mà Control cần làm thay đổi, Control đó cần được xem lại.

2. Control này có trùng với Control khác không?

Nếu hai Control cùng xử lý một Risk, tại cùng một điểm và cùng mục đích, có thể không cần giữ cả hai.

3. Có Evidence chứng minh Control đang hoạt động không?

Nếu không có Evidence, tổ chức khó biết Control có hiệu quả hay chỉ tồn tại trên tài liệu.

4. Control có làm Objective chậm đi quá mức không?

Nếu Cost, Speed hoặc Complexity tăng quá lớn so với Risk Reduction tạo ra, thiết kế Control cần được tối ưu.

Kết quả review tại OLB

• Hợp nhất các approval trùng lặp;
• Loại bỏ checklist không còn cần thiết;
• Tự động hóa các pre-check phù hợp;
• Tập trung Evidence về một workflow;
• Giảm số manual hand-off;
• Giữ human approval tại những điểm thực sự cần judgment;
• Liên kết từng Control quan trọng với Risk cụ thể.

Đây không phải là “cắt Control”.

Đây là giữ đúng Control cần thiết.

5. Ít Control hơn nhưng Risk được kiểm soát tốt hơn

Sau tối ưu, Recovery Process của OLB đơn giản hơn.

Nhưng câu hỏi quan trọng là:

Risk có thực sự giảm không?

OLB không kết luận dựa trên cảm nhận mà dựa trên Evidence.

Một số chỉ số có thể theo dõi

• Recovery Time;
• Tỷ lệ automated task thành công;
• Số manual intervention;
• Số lỗi thao tác;
• Số bước approval;
• Tỷ lệ Recovery Test đạt RTO;
• Số Control exception;
• Residual Risk sau test.

Nếu dữ liệu cho thấy:

• Recovery Time giảm;
• Lỗi thao tác giảm;
• Control quan trọng vẫn hoạt động;
• Evidence đầy đủ hơn;
• Residual Risk nằm trong ngưỡng chấp nhận;

Thì OLB có thể kết luận:

Ít Control hơn nhưng Control đúng hơn có thể làm Risk thấp hơn.

Đây là sự khác biệt giữa Control Quantity và Control Quality.

Liên quan: Q006 — Làm thế nào để chứng minh một Control thực sự hoạt động?

6. Control tốt phải đồng thời bảo vệ Risk và hỗ trợ Objective

Objective của OLB không phải là:

“Có càng nhiều Control càng tốt.”

Objective là:

Phục hồi Digital Payment Service đúng thời gian, ổn định và có thể kiểm chứng.

Một Control tốt vì vậy phải đạt đồng thời bốn điều kiện.

1. Gắn với Objective

Control phải giúp bảo vệ hoặc hỗ trợ Objective.

2. Xử lý đúng Risk

Phải rõ Control đang làm giảm Cause, Likelihood, Impact hay tăng khả năng Detect/Recover.

3. Có Evidence

Tổ chức phải có khả năng chứng minh Control đã hoạt động.

4. Không tạo Friction quá mức

Control không nên làm tăng Cost, Time hoặc Complexity lớn hơn giá trị Risk Reduction mà nó tạo ra.

Có thể cô đọng thành:

Objective → Risk → Control → Evidence → Balance

Trong đó Balance là cân bằng giữa:

• Risk Reduction;
• Cost;
• Speed;
• Resilience;
• Operational Complexity.

7. Control Optimization chính là một cách Turn Risk into Value

Khi OLB tối ưu Control, giá trị tạo ra không chỉ là Risk thấp hơn.

Recovery có thể trở nên:

• Nhanh hơn;
• Ổn định hơn;
• Ít phụ thuộc cá nhân hơn;
• Dễ kiểm chứng hơn;
• Dễ audit hơn;
• Dễ tự động hóa hơn;
• Dễ mở rộng sang nhiều dịch vụ hơn.

Đây chính là logic của Q014 — Khi nào Risk thực sự được chuyển thành Value?

Risk Management tạo thêm Value khi giúp tổ chức đạt Objective:

• Faster — Nhanh hơn;
• More Sustainable — Bền vững hơn;
• Expanded Value — Mở rộng được giá trị.

Vì vậy, Control Optimization không phải một hoạt động hành chính nhằm giảm số lượng Control.

Nó là quá trình:

Giữ đúng những Control thực sự tạo Risk Reduction và Value.

Kết luận

Càng nhiều Control không có nghĩa càng ít Risk.

Một hệ thống có thể có rất nhiều Control nhưng vẫn yếu nếu:

• Control trùng lặp;
• Control không xử lý đúng Risk;
• Control không có Evidence;
• Control tạo quá nhiều Friction;
• Hoặc Control tồn tại nhưng không thực sự vận hành hiệu quả.

Ngược lại, một tập Control nhỏ hơn nhưng được thiết kế đúng có thể mang lại assurance tốt hơn.

Vì vậy, thay vì hỏi:

“Còn thiếu Control nào nữa không?”

Hãy hỏi:

“Control nào thực sự cần thiết để đạt Objective với mức Risk phù hợp?”

Đó là bước chuyển từ:

Control Accumulation → Control Rationalization → Control Optimization

Và cuối cùng:

Risk Reduction → Better Objective → Value

TURN RISK INTO VALUE.

Tóm tắt Q015 trong 30 giây

• Nhiều Control hơn chưa chắc Risk thấp hơn.
• Control trùng lặp có thể làm tăng Complexity và Cost.
• Control phải gắn với Objective và Risk cụ thể.
• Effectiveness phải được chứng minh bằng Evidence.
• Control Rationalization không phải “cắt Control”.
• Mục tiêu là Control đúng và đủ.
• Control tốt phải đồng thời hỗ trợ Risk Reduction, Speed và Resilience.

Odin Lab Bank (OLB) là mô hình giả lập phục vụ nghiên cứu và đào tạo.

Đọc tiếp trong ODIN 101

← Q014: Khi nào Risk thực sự được chuyển thành Value?

Tiếp theo — Q016: Một Risk Score cao có luôn cần ưu tiên trước?

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

Đọc tiếp → Q016: Rủi ro cao nhất có phải luôn được ưu tiên xử lý trước?

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

Tài liệu tham khảo

• ISO 31000:2018 — Risk Management — Guidelines
• COSO ERM — Enterprise Risk Management: Integrating with Strategy and Performance
• ISACA / CRISC — Risk Response, Control Design, Risk Monitoring
• COBIT — Governance and Management Objectives, Controls and Assurance