BDSGPHẠM VĂN THƯNHÀ SÁNG LẬP BDSG
ENTài khoản
Kết nối
Menu
Chuyển đổi số · Nội dung có hỗ trợ AI

Quản trị rủi ro CNTT: HĐQT quyết định và kiểm chứng thế nào?

Đăng ngày 25/10/2026

Mục lục bài nghiên cứu
Ảnh bìa bài: Quản trị rủi ro CNTT

Tóm tắt điều cần nhớ

Quản trị rủi ro CNTT ở cấp HĐQT cần làm rõ hậu quả đối với mục tiêu kinh doanh, người nhận trách nhiệm và căn cứ quyết định. Các khung tham khảo giúp tách vai trò, nhưng không thay bằng chứng thực tế. Nên thử một hồ sơ cụ thể trước khi mở rộng hệ thống báo cáo.

  • Nối rủi ro công nghệ với mục tiêu kinh doanh trước khi hỏi giải pháp.
  • Phân biệt vận hành, phản biện và kiểm chứng độc lập.
  • Giữ đường truy từ báo cáo tổng hợp về bằng chứng gốc.
  • Thử một phiếu trình có người nhận trách nhiệm và điều kiện xem lại.

HĐQT cần quyết định điều gì về công nghệ?

Một báo cáo có hàng chục cảnh báo chưa chắc giúp chọn được việc phải làm trước. Thử đặt tình huống giả định: bộ phận bán hàng muốn mở thêm kênh đặt hàng, còn đội kỹ thuật lo dịch vụ nhận đơn thường gián đoạn. Hai bên đang nói về cùng một khả năng mất đơn nhưng dùng hai ngôn ngữ. Cuộc họp cần nối chúng thành một quyết định có chủ thể, thay vì yêu cầu gửi thêm biểu đồ.

Ở đây, quản trị rủi ro CNTT được hiểu là cách tổ chức xác lập trách nhiệm và giám sát những bất định gắn với việc sử dụng công nghệ. Đó là cách diễn giải phục vụ bài viết. Phạm vi không chỉ gồm tấn công mạng: một hệ thống vận hành sai, quyết định đầu tư thiếu căn cứ hoặc phụ thuộc dịch vụ bên ngoài cũng có thể đe dọa mục tiêu doanh nghiệp.

Trang giới thiệu ISO/IEC 38500:2024 đặt việc sử dụng công nghệ trong phạm vi quản trị tổ chức, bao gồm cả sử dụng hiện tại và tương lai. ISO mô tả đối tượng áp dụng rộng, từ doanh nghiệp đến khu vực công, không giới hạn theo quy mô. Trang này cho biết bản 2024 đã thay bản 2015; bài chỉ đọc giới thiệu chính thức, không suy diễn các điều khoản trong tài liệu trả phí [1].

Chọn khung theo câu hỏi, tránh chất chồng nhãn

  • ISO/IEC 38500:2024: cách cơ quan quản trị nhìn việc dùng công nghệ; bài chỉ dùng giới thiệu chính thức [1].
  • Three Lines của IIA: phân biệt trách nhiệm và độc lập; là khung nghề nghiệp [2].
  • NIST IR 8286r1 và 8286Cr1: nối rủi ro mạng với bức tranh doanh nghiệp, không bao phủ mọi rủi ro [3].
  • COBIT qua hướng dẫn ISACA: nối mục tiêu quản trị với hoạt động quản lý, không tự chứng minh hiệu quả [4].

Một điểm cập nhật đáng chú ý: IIA công bố các tuyên bố lập trường mới ngày 8/7/2026, thay những tài liệu lập trường trước đó. Trang chính thức nhấn mạnh người đọc là hội đồng quản trị, sự phối hợp giữa vai trò và đóng góp của cả đảm bảo lẫn tư vấn. Bởi vậy, khi viện dẫn Three Lines cần ghi phiên bản đang dùng, không mặc định bản từng tải trước đây vẫn là mới nhất [5].

ISACA minh họa việc nối quản trị AI với các mục tiêu COBIT: EDM03 hướng đến tối ưu rủi ro ở cấp quản trị, còn APO12 hỗ trợ hoạt động quản lý rủi ro. Hướng dẫn cũng xét con người, thông tin, cơ cấu và văn hóa bên cạnh công nghệ. Đây là tài liệu nghề nghiệp của tổ chức có hoạt động đào tạo, chứng chỉ, không phải thử nghiệm chứng minh doanh nghiệp áp dụng sẽ đạt lợi nhuận cao hơn [4].

Bốn câu hỏi để chọn tài liệu cho quản trị rủi ro CNTT
Hình 1. Bản đồ câu hỏi do bài đề xuất để chọn điểm đọc; không phải phép quy đổi giữa các khung.

Ba tuyến trách nhiệm khác ba nhóm cùng ký

Theo tài liệu Three Lines năm 2026, quản lý vận hành nhận trách nhiệm rủi ro hằng ngày và thực hiện kiểm soát; các vai trò chuyên môn hỗ trợ, theo dõi và chất vấn; kiểm toán nội bộ cung cấp đảm bảo cùng tư vấn từ vị trí độc lập. Hội đồng giữ định hướng và giám sát, không được mô tả là một trong ba tuyến vận hành này [2].

Tài liệu nhấn mạnh độc lập cần cả vị trí tổ chức và biện pháp bảo vệ, gồm quyền báo cáo, tiếp cận bằng chứng, nguồn lực và xử lý nguy cơ tự xem xét việc mình làm. Đồng thời, độc lập không có nghĩa là cô lập khỏi trao đổi. Phân biệt này giúp tránh hai cực: kiểm toán điều hành thay quản lý hoặc kiểm toán đứng ngoài tới mức không hiểu hoạt động [2].

Trong ví dụ giả định về kênh nhận đơn, trưởng bộ phận kinh doanh có thể nhận trách nhiệm đối với việc giao dịch bị bỏ sót. Đội công nghệ thực hiện các kiểm soát được giao cho hệ thống. Bộ phận quản lý rủi ro hỏi căn cứ xếp mức ảnh hưởng, tính đủ của phương án dự phòng và cách ghi sự cố. Kiểm toán nội bộ chọn phạm vi đánh giá độc lập theo thẩm quyền của mình, không chỉ ký xác nhận bản tự khai.

Tách quyết định giám sát khỏi vận hành, phản biện và kiểm chứng
Hình 2. Sơ đồ phân việc của bài: điều hành, chất vấn và kiểm độc lập cùng cung cấp căn cứ cho quyết định; không sao chép sơ đồ Three Lines.

Từ sổ rủi ro kỹ thuật tới quyết định doanh nghiệp

NIST công bố IR 8286 bản sửa đổi thứ nhất vào tháng 12/2025, nối quản lý rủi ro an ninh mạng với quản lý rủi ro toàn doanh nghiệp. Sổ ghi nhận rủi ro là phương tiện chuyển thông tin giữa các cấp; việc ưu tiên phải liên hệ mục tiêu và bức tranh chung của tổ chức. Nguồn này bàn trọng tâm an ninh mạng, không bao phủ mọi rủi ro CNTT [3].

Tài liệu đi kèm 8286Cr1 phân biệt gom thông tin, chuẩn hóa rồi phân tích. Những dòng được tổng hợp cần truy ngược về sổ gốc qua mã nhận diện; các cấp cũng cần thống nhất trường dữ liệu và cách hiểu giá trị. Đọc phần hướng dẫn này cho thấy việc hợp nhất báo cáo đòi hỏi xử lý ý nghĩa của dữ liệu, không chỉ đưa các bảng tính vào một thư mục [6].

Để minh họa, giả định hai công ty con cùng đánh dấu một dịch vụ là đỏ. Ở đơn vị này, đỏ nghĩa là đã có gián đoạn đang ảnh hưởng khách; ở đơn vị kia, nó chỉ khả năng thiếu người hỗ trợ trong tương lai. Chép hai ô đỏ lên trang tổng hợp làm mất điều khác biệt quan trọng nhất. Người nhận cần biết đó là sự cố hiện hữu, kịch bản rủi ro hay chất lượng thông tin chưa đủ.

Một thiết kế báo cáo thực hành có thể giữ cả nguyên bản và bản đã chuẩn hóa. Khi quy đổi mức độ, ghi người thực hiện, căn cứ và điểm chưa tương thích. Không điền số không cho tổn thất chưa biết rồi cộng thành tổng chắc chắn. Tương tự, không cộng các ước tính cùng xuất phát từ một dịch vụ dùng chung mà chưa xét khả năng trùng lặp; đây là lưu ý phân tích của bài.

Phiếu trình cần làm lộ quyết định còn thiếu

Đề xuất dưới đây là mẫu làm việc riêng cho quản trị rủi ro CNTT, chưa được kiểm nghiệm như mô hình hoàn chỉnh. Mỗi phiếu chỉ chọn một kịch bản đủ rõ để thảo luận. Viết từ mục tiêu bị đe dọa trước khi nêu tên công cụ, sau đó chỉ ra điều kiện làm sự việc xảy ra, phạm vi ảnh hưởng và biện pháp đã có. Người chưa biết hệ thống vẫn phải hiểu tại sao cần đưa vấn đề lên cuộc họp.

  • Mục tiêu và kịch bản: hoạt động nào có thể không đạt, trong điều kiện nào.
  • Trách nhiệm: ai theo dõi, ai được chấp nhận phần rủi ro còn lại.
  • Bằng chứng: điều đã quan sát, giả định chưa kiểm và bất định.
  • Phương án: tiếp tục có điều kiện, giảm phạm vi, xử lý thêm hoặc dừng.
  • Mốc xem lại: thời điểm hoặc sự kiện buộc đánh giá lại.

Ví dụ giả định của bài: một doanh nghiệp phân phối phụ thuộc dịch vụ xác nhận thanh toán do đối tác cung cấp. Khi đường kết nối lỗi, đơn vẫn được nhận nhưng nhân viên chưa phân biệt được khoản đã thu. Chủ rủi ro không chỉ cần một cam kết sửa kết nối; họ phải xem quy trình xác minh, quyền giao hàng và việc thông báo cho khách trong thời gian chờ.

Phiếu trình có thể nêu phương án thu hẹp loại giao dịch được xử lý tự động, đồng thời ghi rõ phần việc chuyển sang người. Cần quan sát thời gian đối chiếu và số trường hợp chưa xác nhận, không chỉ thời gian máy chủ hoạt động. Các thước đo này là lựa chọn minh họa, chưa có ngưỡng dùng chung cho mọi doanh nghiệp hay kết luận mức thiệt hại tài chính.

Năm phần của phiếu rủi ro gắn quyết định với bằng chứng
Hình 3. Cấu trúc phiếu trình do bài đề xuất, không phải mẫu bắt buộc của ISO, IIA hay NIST.

Đọc thực hành tại Việt Nam với đúng mức tin cậy

Bộ quy tắc về quản trị công ty dành cho Việt Nam, bản 2026 hướng đến công ty đại chúng, có khuyến nghị vượt yêu cầu pháp luật tối thiểu. Nguyên tắc 6.5 đưa an ninh mạng, AI và kỹ thuật số vào bức tranh quản lý rủi ro chung, đồng thời đề cập việc HĐQT trao đổi, duyệt chiến lược và nhận báo cáo kiểm toán nội bộ. Bộ nguyên tắc không thay văn bản pháp luật khi có khác biệt [7].

Ở trang tự đánh giá công khai của PVCFC, doanh nghiệp cho biết HĐQT có danh mục vấn đề trọng yếu xem hằng tháng. Phần đối chiếu 6.5.2 còn mô tả xem xét báo cáo quản trị rủi ro hằng quý từ các đầu mối gồm kiểm toán nội bộ, ủy ban quản trị rủi ro cùng Tổng giám đốc. Đây là cách doanh nghiệp tự trình bày cơ chế, chưa phải đánh giá độc lập về hiệu lực từng kiểm soát [8].

Tài liệu thường niên 2025 của FPT, phần HĐQT, mô tả hoạt động tham mưu của Ủy ban Chính sách phát triển, gồm định hướng thị trường, đối tác, công nghệ và công cụ quản trị nội bộ có AI. Nguồn này giúp thấy một hình thức đưa vấn đề công nghệ vào trao đổi chiến lược. Vì là tự công bố của doanh nghiệp cung cấp dịch vụ công nghệ, không dùng nó làm bằng chứng nhân quả về hiệu quả quản trị [9].

Điều có thể học từ hai ví dụ là cách tìm dấu vết trách nhiệm và nhịp xem xét, không phải sao chép tên ủy ban. Khi đọc báo cáo của một công ty Việt Nam, hãy hỏi đó là mô tả chính sách, tự đánh giá hay kết quả kiểm chứng. Ba loại có giá trị khác nhau; trang công khai nhiều thông tin vẫn không tự chứng minh rằng mọi kịch bản quan trọng đã được kiểm.

Góc nhìn AI: hồ sơ rủi ro thay đổi thế nào?

Một đề xuất ứng dụng AI có thể bắt đầu như công cụ soạn văn bản, rồi dần được nối vào dữ liệu hoặc hành động của doanh nghiệp. Bởi vậy, hồ sơ cần ghi quyền thực tế tại thời điểm xem xét. Phân tích này của bài chú trọng sự thay đổi nhiệm vụ, thay vì chỉ hỏi hệ thống dùng mô hình của nhà cung cấp nào.

ISO/IEC 38507:2022 hướng dẫn cơ quan quản trị về việc sử dụng AI ở hiện tại và tương lai. Phần giới thiệu chính thức đặt đối tượng trong nhiều loại hình tổ chức; bài chưa đọc các điều khoản trả phí và không coi hướng dẫn là chứng nhận sản phẩm. Điểm tham chiếu ở đây là vai trò quản trị đối với việc dùng AI, không phải một danh sách nghĩa vụ pháp lý [10].

NIST AI RMF mô tả các chức năng: Govern; Map; Measure; Manage; tài liệu giải thích chúng không phải chuỗi bước bắt buộc hay bảng kiểm hoàn thành một lần. Trang Core cũng thông báo phiên bản 1.0 đang được sửa đổi. Đó là khung tham khảo, không phải thử nghiệm xác nhận mọi hệ thống áp dụng sẽ an toàn [11].

Trong tình huống giả định về trợ lý tổng hợp báo cáo cho HĐQT, người vận hành nên giữ đường dẫn tới tài liệu gốc và chỉ ra phần do máy tóm tắt. Người đọc cần phân biệt nội dung đã đối chiếu với suy luận chưa kiểm. Không giao cho chính trợ lý đó kết luận duy nhất rằng báo cáo do nó tạo ra là chính xác hoặc mọi biện pháp bảo vệ đang hoạt động tốt.

Khi công cụ được phép sửa dữ liệu hoặc kích hoạt giao dịch, phiếu trình phải được xem lại theo quyền mới. Cần xác định ai có thể ngắt hành động, khôi phục công việc và giải quyết hậu quả đối với người bị ảnh hưởng. Bài đề xuất những câu hỏi này cho thảo luận quản trị, cần điều chỉnh theo đánh giá chuyên môn; chúng không phân loại pháp lý thay cơ quan có thẩm quyền.

Quy mô quyết định cách tổ chức, không xóa trách nhiệm

Với doanh nghiệp nhỏ, không nên mặc định phải lập đủ những phòng chuyên môn như tập đoàn. Có thể bắt đầu bằng người phụ trách hoạt động, người hỗ trợ kỹ thuật và cách nhận ý kiến kiểm tra bên ngoài phù hợp. Tuy nhiên, khi một người kiêm nhiều vai, hồ sơ cần nêu phần nào họ đang tự đánh giá và khi nào phải xin người khác xem xét.

Doanh nghiệp vừa có thể gặp điểm nghẽn ở chỗ trách nhiệm đi qua nhiều bộ phận. Người mua dịch vụ, người giữ dữ liệu và người dùng kết quả thường không trùng nhau. Bài đề xuất thử phiếu trình trên một quy trình đi qua các nhóm này; nếu không tìm được chủ thể nhận phần rủi ro còn lại, bổ sung công cụ báo cáo chưa giải quyết được vấn đề tổ chức.

Ở tập đoàn và công ty lớn, nên quan sát phụ thuộc chung giữa các đơn vị. Mỗi công ty con có thể đánh giá việc của mình riêng lẻ, trong khi cùng dùng một nền tảng nhận diện hoặc nhà cung cấp. Khung tổng hợp nên giữ mã gốc và quan hệ giữa kịch bản. Phải tránh tính lặp tác động hoặc làm mất khác biệt về khách hàng, địa bàn và thời gian chịu gián đoạn.

Đối với doanh nghiệp nhà nước hay tổ chức khu vực công, cơ cấu và thẩm quyền phải bám văn bản áp dụng cho chính đơn vị. Không suy từ một khuyến nghị quốc tế rằng hội đồng có thể tự chuyển quyền phê duyệt. Trong mọi quy mô, nhịp xem lại nên theo mức thay đổi và mức ảnh hưởng; lịch minh họa của doanh nghiệp khác không phải lịch bắt buộc cho mình.

Mười câu hỏi để thử chất lượng một phiếu trình

Bộ câu hỏi sau do bài xây dựng để mở thảo luận, không phải phép đánh giá đã được kiểm định. Có thể dùng với một hồ sơ cụ thể trước khi áp dụng rộng. Mỗi câu cần trỏ tới một phần bằng chứng hoặc một quyết định còn thiếu, thay vì chỉ chọn ô có và không rồi tính điểm.

  • Câu 1: Mục tiêu kinh doanh nào chịu ảnh hưởng? Nếu chỉ có tên hệ thống, yêu cầu diễn giải hậu quả đối với hoạt động.
  • Câu 2: Kịch bản đang nói điều đã xảy ra hay điều có thể xảy ra? Tách phần xử lý sự cố khỏi ước tính tương lai.
  • Câu 3: Ai nhận trách nhiệm đối với hậu quả? Người quản lý máy móc chưa chắc được quyền chấp nhận ảnh hưởng tới khách hàng.
  • Câu 4: Căn cứ đánh giá được lấy lúc nào? Ghi thời điểm đo và điều gì đã thay đổi sau lần quan sát đó.
  • Câu 5: Những điều chưa biết nằm ở đâu? Không để số không hoặc ô xanh che mất thông tin chưa được kiểm tra.
  • Câu 6: Có phụ thuộc nào dùng chung với đơn vị khác? Chỉ ra đường liên hệ để tránh xem từng hồ sơ như độc lập.
  • Câu 7: Biện pháp đã được thử trong điều kiện nào? Phân biệt thiết kế trên giấy với kết quả quan sát khi thực hiện.
  • Câu 8: Người kiểm có đang xem lại chính việc mình làm? Nếu có, xác định cách bổ sung góc nhìn độc lập.
  • Câu 9: Quyết định hôm nay có giới hạn nào? Ghi phạm vi, điều kiện tiếp tục và người được phép thay đổi.
  • Câu 10: Điều gì khiến quyết định phải mở lại? Chọn sự kiện hoặc mốc xem xét, đừng chờ tới khi tổn hại rõ mới hỏi.
Chu trình ghi nhận, quyết định và xem lại rủi ro
Hình 4. Vòng xem lại do bài đề xuất: một quyết định cần có điều kiện và căn cứ để mở lại khi thực tế thay đổi.

Sai lầm khi dùng báo cáo để thay trách nhiệm

Sai lầm đầu tiên là giao toàn bộ rủi ro công nghệ cho giám đốc CNTT. Khi hậu quả liên quan chất lượng dịch vụ hoặc cách giao dịch với khách hàng, người phụ trách kinh doanh phải tham gia. Cách phân công nên thể hiện ai chuẩn bị căn cứ, ai thực hiện kiểm soát và ai được chấp nhận phần còn lại; một chữ ký chung không trả lời đủ.

Sai lầm tiếp theo là coi biểu mẫu của khung tham khảo như sự đảm bảo. Có mã rủi ro và báo cáo định kỳ giúp lần theo thông tin, nhưng không thay việc kiểm chất lượng giả định. Nếu các bộ phận dùng khác định nghĩa, báo cáo hợp nhất có thể tạo cảm giác thống nhất trong khi quyết định dựa trên những thước đo không tương thích.

Cuối cùng, đừng biến HĐQT thành nhóm duyệt từng thay đổi kỹ thuật. Cần có đường chuyển vấn đề vượt thẩm quyền hoặc giới hạn đã xác lập, đồng thời để người điều hành thực hiện trách nhiệm của họ. Bài không đưa ra một ngưỡng chung: mức nào phải trình cần được xác định theo cơ cấu, ngành, hậu quả và nghĩa vụ thật của tổ chức.

Hỏi đáp về quản trị rủi ro CNTT

Có cần một ủy ban công nghệ riêng không? Không thể kết luận chỉ từ tên khung tham khảo. Hãy xem hội đồng đang nhận vấn đề công nghệ ở đâu, có đủ năng lực phản biện và có đường tiếp cận căn cứ độc lập không. Việc lập hoặc phân công ủy ban phải phù hợp cơ cấu và thẩm quyền áp dụng; thêm tên gọi không tự khắc phục khoảng trống.

Ba tuyến có đồng nghĩa ba lần phê duyệt? Không nên hiểu như vậy. Ba tuyến phân biệt loại trách nhiệm và mức độc lập, không mô tả một dây chuyền cùng đóng dấu. Người vận hành vẫn phải nhận rủi ro công việc, còn phản biện và kiểm toán phải giữ vai trò của mình. Cần tránh biến phối hợp thành việc chờ nhau mà không ai chịu trách nhiệm cuối.

Có thể dùng điểm rủi ro từ phần mềm ngay không? Điểm có thể hỗ trợ sắp xếp thảo luận nếu hiểu dữ liệu và giả định phía sau. Trước khi sử dụng, hỏi cách tính, thời điểm cập nhật và những trường bị thiếu. Khi các đơn vị dùng định nghĩa khác, cần giữ khác biệt để xem xét, không ép mọi giá trị thành một thứ hạng có vẻ chính xác.

Rủi ro AI có cần sổ riêng? Có thể cần hồ sơ chuyên sâu cho từng hệ thống, nhưng vẫn phải nối tới người chịu trách nhiệm và rủi ro doanh nghiệp. Đừng để một danh sách AI nằm ngoài cuộc trao đổi về dữ liệu, vận hành và khách hàng. Thiết kế liên kết quan trọng hơn quyết định ban đầu rằng dùng chung hay tách một tệp.

Nên bắt đầu thay đổi báo cáo từ đâu? Chọn một rủi ro có quyết định đang chờ, thử viết đủ phiếu trình và mời các vai liên quan xem lại. Ghi những chỗ không có người nhận, không có căn cứ hoặc khác cách hiểu. Sửa các chỗ đó rồi mới nhân rộng; cách làm này là gợi ý của bài, không cam kết kết quả định lượng.

Kết luận

Quản trị rủi ro CNTT có ích khi đưa người có thẩm quyền tới một lựa chọn rõ, nhìn thấy phần bất định và biết lúc nào phải xem lại. Khung quốc tế giúp đặt câu hỏi; quyết định cụ thể vẫn cần căn cứ và trách nhiệm trong tổ chức. Một phiếu trình truy được nguồn thường là nơi bắt đầu phù hợp hơn việc lập thêm một bảng tổng hợp nhiều màu.

Nguồn và phương pháp

Bài gốc, không phải bản dịch; được biên soạn với hỗ trợ AI, đối chiếu ngày 25/10/2026. Đây là tổng hợp khung thực hành, không phải khảo sát hay nghiên cứu kiểm định tác động. Các ví dụ và phiếu trình là đề xuất của bài; hiệu quả của chúng chưa được kiểm chứng. Chỉ đọc trang giới thiệu của hai tiêu chuẩn ISO, các đoạn xác định trong tài liệu NIST, IIA và Bộ Nguyên tắc 2026; không nhận đã đọc toàn bộ ấn phẩm.

IIA, ISACA có hoạt động nghề nghiệp, đào tạo và chứng chỉ; FPT, PVCFC tự công bố thông tin. Không xem các nguồn đó là xác nhận độc lập về hiệu lực kiểm soát. Nội dung cung cấp thông tin chung, không phải tư vấn pháp lý, thuế hay tài chính; cần đọc tài liệu gốc và đối chiếu quy định áp dụng cho đơn vị.