Odin Lab · ODIN 101 — Digital Trust & Resilience

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

Odin Lab

Một Risk có thể có nhiều người tham gia nhưng Ownership không được mơ hồ. Q007 phân biệt Risk Owner, Control Owner, Action Owner và Decision Authority qua case Odin Lab Bank.

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

Quản trị rủi ro chỉ thực sự vận hành khi trách nhiệm được gắn đúng người, đúng việc và đúng thẩm quyền.

Trong Q006, chúng ta đã đi đến một nguyên tắc quan trọng: Control phải tạo ra Evidence và Evidence phải hỗ trợ Decision. Nhưng khi Evidence cho thấy một Control yếu, một Action quá hạn hoặc Residual Risk vẫn cao, tổ chức sẽ ngay lập tức gặp câu hỏi tiếp theo:

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

Đây là bước Responsibility — Trách nhiệm trong Odin Risk Management Method.

Trong thực tế, một rủi ro công nghệ hiếm khi chỉ liên quan đến một người hoặc một đội. Business quan tâm tới dịch vụ. Infrastructure vận hành nền tảng. Security quản lý một số Controls. Risk theo dõi mức độ rủi ro. Audit đánh giá độc lập. Management có quyền chấp nhận hoặc yêu cầu xử lý thêm.

Nếu các vai trò này không được phân biệt rõ, rất dễ xảy ra tình trạng nhiều người cùng tham gia nhưng không ai thực sự sở hữu kết quả cuối cùng.

1. “Owner” không có nghĩa là người làm mọi việc

Một trong những nhầm lẫn phổ biến trong Risk Register là gán người tổng hợp báo cáo, đội Risk hoặc một đầu mối vận hành làm “Owner” chỉ vì họ đang theo dõi vấn đề.

Ownership không có nghĩa là người đó phải trực tiếp thực hiện tất cả công việc. Nó có nghĩa là người đó chịu trách nhiệm về outcome thuộc phạm vi của mình và phải bảo đảm vấn đề được xử lý, theo dõi hoặc đưa lên đúng cấp khi cần.

Người thực hiện công việc không phải lúc nào cũng là người chịu trách nhiệm cuối cùng.

2. Risk Owner chịu trách nhiệm về Risk và kết quả cuối cùng

Risk Owner — Chủ rủi ro là người chịu trách nhiệm bảo đảm Risk được hiểu, đánh giá, xử lý và theo dõi trong phạm vi thẩm quyền.

Risk Owner cần hiểu Risk đang ảnh hưởng đến Objective nào, mức Risk hiện tại, các Controls quan trọng, Residual Risk còn lại và khi nào cần treatment, acceptance hoặc escalation.

Risk Owner không nhất thiết trực tiếp cấu hình firewall, vận hành backup hay thực hiện DR test. Nhưng Risk Owner phải bảo đảm rằng các Controls và Actions liên quan đủ để quản lý Risk, đồng thời đưa Risk lên đúng cấp quyết định nếu mức còn lại vượt ngưỡng chấp nhận.

3. Control Owner chịu trách nhiệm để Control thực sự hoạt động

Control Owner — Chủ kiểm soát chịu trách nhiệm về thiết kế, triển khai, vận hành và bằng chứng của một Control cụ thể.

Trọng tâm của Control Owner là Control Objective, phạm vi áp dụng, cách vận hành, exception, Evidence và Control Effectiveness.

Một Risk có thể có nhiều Controls và vì vậy có nhiều Control Owners khác nhau. Ví dụ một Recovery Risk có thể liên quan tới replication, infrastructure recovery, emergency access và DR exercise. Mỗi Control có thể do một owner khác nhau chịu trách nhiệm.

Điểm quan trọng là không để việc “nhiều Control Owners” biến thành “không ai chịu trách nhiệm về Risk tổng thể”.

4. Action Owner chịu trách nhiệm hoàn thành một hành động cụ thể

Action Owner — Chủ hành động chịu trách nhiệm hoàn thành một remediation action cụ thể với deadline và đầu ra rõ ràng.

Ví dụ Evidence cho thấy restore test đang vượt RTO. Một Action có thể được mở để tối ưu recovery workflow, loại bỏ một bước thủ công hoặc tự động hóa một phần quy trình. Người được giao hoàn thành Action đó là Action Owner.

Khi Action đóng, Risk vẫn có thể tồn tại. Control vẫn cần tiếp tục vận hành. Risk Owner vẫn chịu trách nhiệm đánh giá Residual Risk.

Đây là lý do Risk Owner, Control Owner và Action Owner không nên được dùng thay thế cho nhau.

Q007 Odin Lab - Phân biệt Risk Owner, Control Owner, Action Owner và Decision Authority
Hình 1. Phân biệt Risk Owner, Control Owner, Action Owner và Decision Authority để tránh nhầm lẫn giữa người thực hiện và người chịu trách nhiệm cuối cùng.

5. Case Odin Lab Bank: một Risk, nhiều Owner

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

Risk đang được theo dõi là: dịch vụ thanh toán số có thể không phục hồi đúng RTO khi xảy ra sự cố nghiêm trọng.

Risk Owner có thể là Digital Payment Service Owner, vì người này chịu trách nhiệm về outcome của dịch vụ và mức Residual Risk liên quan.

Control Owners có thể gồm Database/Replication Owner cho replication và restore; Infrastructure Recovery Owner cho recovery environment; IAM Owner cho emergency access; và Resilience/Recovery Exercise Owner cho recovery coordination và DR exercise.

Nếu một recovery step làm tăng thời gian phục hồi, một nhóm kỹ thuật có thể được giao Action để tối ưu bước đó. Người chịu trách nhiệm hoàn thành remediation này là Action Owner.

Khi Evidence mới được tạo ra sau remediation, Risk Owner sử dụng Evidence đó để đánh giá lại Residual Risk. Nếu Risk vẫn vượt tolerance, vấn đề phải được đưa tới đúng Decision Authority — Cấp có thẩm quyền quyết định.

Q007 Odin Lab - Một rủi ro nhiều Control Owners nhưng Risk Owner phải rõ ràng
Hình 2. Một Risk có thể có nhiều Control Owners, nhưng Risk Owner phải rõ ràng để bảo đảm service outcome, remediation, Evidence và Decision được nối thành một chuỗi thống nhất.

6. RACI hữu ích nhưng không thay thế Accountability

RACI là một công cụ hữu ích để mô tả ai Responsible, Accountable, Consulted và Informed. Tuy nhiên, một bảng RACI đẹp không tự động tạo ra governance tốt.

Vấn đề vẫn còn nếu có quá nhiều người cùng Accountable, decision rights không rõ, Risk Acceptance Authority chưa được xác định hoặc Action quá hạn nhưng không có escalation.

RACI giúp mô tả vai trò. Governance phải làm rõ ai có quyền và nghĩa vụ quyết định.

Trong quản trị rủi ro, trách nhiệm chỉ thực sự có ý nghĩa khi gắn với thẩm quyền, deadline, Evidence và cơ chế escalation.

7. Responsibility phải dẫn tới Decision

Một mô hình Responsibility tốt phải giúp Risk di chuyển được qua toàn bộ vòng đời quản trị.

Nếu Control thất bại, Control Owner phải xử lý hoặc báo cáo. Nếu cần remediation, Action Owner phải có deadline và deliverable. Nếu Residual Risk vượt tolerance, Risk Owner phải escalation. Và nếu Risk cần được chấp nhận, quyết định phải thuộc đúng cấp có thẩm quyền.

Ownership rõ ràng → Evidence tốt hơn → Quyết định nhanh hơn.

Responsibility rõ ràng không nhằm tìm người chịu lỗi. Mục tiêu là bảo đảm Risk được xử lý đúng người, đúng lúc và không bị mắc kẹt giữa các nhóm chức năng.

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

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

Q007 tập trung vào Responsibility. Evidence chỉ tạo ra giá trị khi có người chịu trách nhiệm đọc, đánh giá và hành động dựa trên Evidence đó.

Đây cũng là điểm nối từ Controls & Evidence sang Governance & GRC: Risk không được quản lý chỉ bằng công cụ hay checklist, mà bằng cấu trúc trách nhiệm và quyền quyết định rõ ràng.

Kết luận

Một Risk có thể liên quan tới rất nhiều người. Nhưng sự tham gia rộng không được phép làm mờ Ownership.

Risk Owner chịu trách nhiệm về Risk và Residual Risk. Control Owner chịu trách nhiệm để Control hoạt động. Action Owner chịu trách nhiệm hoàn thành remediation. Decision Authority chịu trách nhiệm cho quyết định nằm trong phạm vi thẩm quyền.

Trách nhiệm rõ ràng không phải để tìm người chịu lỗi. Nó giúp Risk được xử lý và Decision được đưa ra đúng lúc.

TURN RISK INTO VALUE.

Đọc tiếp trong ODIN 101

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

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

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

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

Tài liệu tham khảo

ISACA — CRISC Exam Content Outline.

COBIT 2019 — Governance and Management Objectives.

IIA — The Three Lines Model.

ISO 31000:2018 — Risk Management — Guidelines.

← Về trang chủ

3 bình luận cho “Q007 — Khi rủi ro xảy ra, ai thực sự chịu trách nhiệm?”

Để lại một bình luận

Bình luận được duyệt trước khi hiển thị. Email không công khai. Vui lòng không gửi thông tin nội bộ, dữ liệu khách hàng hoặc thông tin nhạy cảm.