Bắt đầu từ mục tiêu: Xác định phạm vi và giá trị cần bảo vệ

Danh sách rủi ro có thể rất đầy đủ mà vẫn chưa giúp tổ chức biết điều gì cần ưu tiên. Điều thường bị bỏ qua là câu hỏi đứng trước việc nhận diện rủi ro: mục tiêu nào đang cần đạt được hoặc bảo vệ?

Trong Chu trình Odin, đó là bước Objective — Xác định mục tiêu. Bước này làm rõ mục đích, giá trị cần bảo vệ, phạm vi và tiêu chí thành công trước khi chuyển sang nhận diện rủi ro. Nếu điểm xuất phát mơ hồ, các bước đánh giá và kiểm soát về sau dễ đi đúng quy trình nhưng tập trung sai vấn đề.

ISO 31000:2018 định nghĩa rủi ro gắn với “ảnh hưởng của sự không chắc chắn lên mục tiêu”. Vì vậy, mục tiêu không chỉ là phần mở đầu của hồ sơ; nó là căn cứ để hiểu rủi ro có ý nghĩa gì với tổ chức. Nguồn: ISO.

Objective làm rõ điều gì?

Một mục tiêu hữu ích mô tả kết quả mà tổ chức muốn đạt được hoặc duy trì, trong bối cảnh cụ thể. Với quản trị rủi ro CNTT, mục tiêu có thể liên quan đến dịch vụ, dữ liệu, nghĩa vụ tuân thủ, trải nghiệm khách hàng, khả năng phục hồi hay một thay đổi công nghệ.

“Nâng cao an toàn hệ thống” thường chưa đủ cụ thể để định hướng đánh giá. “Duy trì khả năng khách hàng hoàn tất giao dịch chuyển tiền với trạng thái chính xác, được bảo vệ và có thể đối soát” cho biết rõ hơn điều gì tạo ra giá trị và điều gì có thể bị ảnh hưởng.

Bước Objective chưa kết luận rủi ro nào cao, cũng chưa chọn kiểm soát. Nó thống nhất điểm đến và ranh giới để các bước tiếp theo đánh giá đúng điều cần quan tâm.

Năm câu hỏi cần trả lời

1. Kết quả nào cần đạt hoặc duy trì?

Viết bằng ngôn ngữ kết quả nghiệp vụ hoặc dịch vụ, tránh bắt đầu bằng tên dự án, sản phẩm hay một giải pháp kỹ thuật đã định sẵn.

2. Giá trị nào cần bảo vệ hoặc tạo ra?

Xem xét khách hàng, dữ liệu, tài sản, tính liên tục, nghĩa vụ pháp lý, uy tín và năng lực vận hành. Chỉ chọn những giá trị thực sự liên quan đến mục tiêu đang xem xét.

3. Phạm vi và các phụ thuộc nằm ở đâu?

Xác định dịch vụ, quy trình, hệ thống, dữ liệu, đơn vị và bên thứ ba liên quan; nêu rõ điểm bắt đầu, điểm kết thúc và những gì nằm ngoài phạm vi. Một dịch vụ có thể phụ thuộc vào định danh, kết nối, xử lý giao dịch, đối soát, hỗ trợ vận hành hoặc nhà cung cấp.

4. Thành công được nhận biết bằng tiêu chí nào?

Chọn tiêu chí có thể kiểm tra, chẳng hạn giao dịch được ghi nhận chính xác, trạng thái được thông báo rõ, dịch vụ duy trì trong giới hạn đã phê duyệt, hoặc yêu cầu tuân thủ được đáp ứng. Mức ngưỡng cụ thể phải do chủ dịch vụ và cấp có thẩm quyền xác định theo bối cảnh; không nên tự đặt con số nếu chưa có căn cứ.

5. Ai sở hữu mục tiêu và ai quyết định?

Xác định chủ dịch vụ hoặc người chịu trách nhiệm về kết quả, các bên cần tham gia xác nhận phạm vi, và thẩm quyền quyết định khi có đánh đổi giữa chi phí, tốc độ, trải nghiệm, an toàn và mức rủi ro.

Ví dụ giả lập tại Odin Lab Bank

Tình huống minh họa — Odin Lab Bank (OLB) là ngân hàng giả lập phục vụ nghiên cứu và đào tạo. Giả sử OLB đang xem xét một dịch vụ chuyển tiền số. Trước khi liệt kê sự cố hay điểm yếu kỹ thuật, nhóm cần thống nhất mục tiêu:

Khách hàng có thể khởi tạo và hoàn tất giao dịch chuyển tiền chính xác, an toàn, nhận được trạng thái rõ ràng và được phục vụ trong giới hạn liên tục đã phê duyệt.

Từ mục tiêu đó, nhóm làm rõ các giá trị cần bảo vệ: tiền và dữ liệu giao dịch, tính chính xác của ghi nhận, khả năng tiếp cận dịch vụ, niềm tin khách hàng và việc đáp ứng nghĩa vụ áp dụng. Phạm vi có thể bao gồm các bước từ xác thực khách hàng đến xử lý, ghi nhận và thông báo kết quả; các phụ thuộc cần được xác nhận cùng chủ dịch vụ. Tiêu chí thành công và ngưỡng chấp nhận do OLB giả lập quy định trong hồ sơ dịch vụ.

Ví dụ này không mô tả một ngân hàng hay hệ thống có thật. Nó cho thấy mục tiêu nghiệp vụ giúp lựa chọn phạm vi cần xem xét; ở bước Risk, nhóm mới xác định điều gì có thể làm mục tiêu không đạt được.

Đầu ra của bước Objective

Trước khi chuyển bước, một bản ghi ngắn nên có tối thiểu:

• Mục tiêu: kết quả cần đạt hoặc duy trì.
• Giá trị cần bảo vệ: khách hàng, dịch vụ, dữ liệu, tài chính, tuân thủ hoặc uy tín có liên quan.
• Phạm vi: quy trình, hệ thống, dữ liệu, đơn vị và phụ thuộc; cùng các ranh giới hoặc ngoại lệ.
• Tiêu chí thành công: cách nhận biết mục tiêu đang được đáp ứng và căn cứ đặt ngưỡng.
• Trách nhiệm và thẩm quyền: chủ mục tiêu, bên xác nhận và người quyết định các đánh đổi.
• Bối cảnh cần lưu ý: các giả định, thời hạn, thay đổi đang diễn ra và yêu cầu áp dụng.

Đầu ra này không phải hồ sơ rủi ro hoàn chỉnh. Nó là điểm tựa để bước Risk xây dựng các kịch bản có liên hệ trực tiếp với mục tiêu.

Những nhầm lẫn thường gặp

• Bắt đầu bằng công nghệ: xác định giải pháp trước khi thống nhất kết quả cần đạt khiến mục tiêu bị thu hẹp theo công cụ.
• Viết mục tiêu quá rộng: “bảo đảm an toàn CNTT” không giúp phân biệt điều gì trọng yếu trong một phạm vi cụ thể.
• Đồng nhất mục tiêu với chỉ tiêu kỹ thuật: thời gian hoạt động của máy chủ có thể là tín hiệu vận hành, nhưng chưa tự chứng minh khách hàng hoàn thành được giao dịch.
• Bỏ qua phụ thuộc và ranh giới: chỉ xem một ứng dụng trong khi kết quả phụ thuộc nhiều quy trình hoặc dịch vụ khác sẽ tạo ra phạm vi đánh giá thiếu.
• Để trống người quyết định: tiêu chí và đánh đổi không có chủ sở hữu sẽ khó được xác nhận hoặc duy trì khi bối cảnh thay đổi.

Bàn giao sang bước Risk

Khi mục tiêu, giá trị, phạm vi và tiêu chí thành công đã được xác nhận, bước tiếp theo là hỏi: Điều gì không chắc chắn có thể ảnh hưởng đến mục tiêu này?

Hãy mô tả mỗi kịch bản sao cho có thể phân tích và hành động — theo cấu trúc thực hành của Odin Lab: Nguyên nhân → Sự kiện → Tác động. Cấu trúc này giúp nối bối cảnh với kết quả có thể xảy ra; không thay thế cách diễn đạt hoặc yêu cầu riêng của từng tiêu chuẩn.

Xem toàn bộ Chu trình Odin – Từ rủi ro đến giá trị · Xem Phương pháp ODIN

Bạn cũng có thể đọc tình huống giả lập áp dụng Chu trình Odin cho gián đoạn dịch vụ ngân hàng số và Q001 — Quản trị rủi ro thực sự bắt đầu từ đâu?.

---

Tham chiếu

• ISO 31000:2018 — Risk management — Guidelines
• NIST SP 800-30 Rev. 1 — Guide for Conducting Risk Assessments

Bài viết trình bày phương pháp thực hành của Odin Lab, không thay thế tiêu chuẩn hoặc quy định áp dụng tại từng tổ chức.

TURN RISK INTO VALUE.