Thiết kế và triển khai quản trị công nghệ thông tin dựa trên COBIT 2019
1. Tổng quan
Định nghĩa: COBIT 2019 là khung (framework) của ISACA dùng để thiết kế, vận hành và đánh giá hệ thống quản trị (governance) và hệ thống quản lý (management) nhằm giúp thông tin và công nghệ (I&T) của doanh nghiệp tạo ra giá trị cho các bên liên quan.
Trong doanh nghiệp, công nghệ thông tin đã vượt ra khỏi vai trò chức năng hỗ trợ đơn thuần là vận hành hệ thống để trở thành năng lực kinh doanh gắn trực tiếp với sản phẩm, quy trình nghiệp vụ, trải nghiệm khách hàng và tuân thủ quy định. Tuy nhiên, chỉ riêng việc bộ phận công nghệ cung cấp dịch vụ nhanh chóng không bảo đảm được hiệu quả đầu tư. Cần gắn kết với quyết định điều hành các câu hỏi như: ưu tiên khoản đầu tư công nghệ nào, chấp nhận rủi ro đến mức nào, ai chịu trách nhiệm về sự cố và vi phạm thông tin cá nhân, và kiểm soát các nhà cung cấp bên ngoài ra sao.
COBIT 2019 không tìm cách giải quyết vấn đề này bằng một sản phẩm cụ thể hay một danh mục kiểm soát duy nhất. Trước hết, khung này nắm bắt chiến lược, mục tiêu, rủi ro, môi trường pháp lý, phương thức áp dụng công nghệ và quy mô của doanh nghiệp, sau đó ưu tiên hóa 40 mục tiêu quản trị và quản lý cùng các thành phần cho phù hợp với hoàn cảnh doanh nghiệp. Do đó, COBIT 2019 phù hợp với cách tiếp cận tập trung vào các rủi ro và dòng giá trị quan trọng hơn là cách một tổ chức nhỏ áp dụng mọi mục tiêu ở cùng một mức độ.
Quản trị và quản lý khác nhau về chiều trách nhiệm. Quản trị là hoạt động của hội đồng quản trị và ban điều hành cấp cao nhằm đánh giá yêu cầu của các bên liên quan, định hướng, và giám sát hiệu quả cũng như tình trạng tuân thủ. Quản lý là hoạt động của ban điều hành và người thực thi nhằm lập kế hoạch, xây dựng, vận hành và cải tiến theo định hướng đã xác định. Nếu nhầm lẫn hai lĩnh vực này, sẽ phát sinh vấn đề như hội đồng quản trị trực tiếp xử lý các yêu cầu (ticket) vận hành, hoặc người thực thi tự quyết định thứ tự ưu tiên đầu tư.
Từ góc nhìn của Kỹ sư chuyên nghiệp (Professional Engineer), cốt lõi của COBIT 2019 không phải là tuyên bố đã áp dụng khung mà là sự kết nối giữa ra quyết định và kiểm soát. Cần chuyển đổi mục tiêu kinh doanh thành mục tiêu I&T, gắn mục tiêu với quy trình và trách nhiệm, và lưu lại việc thực hiện kiểm soát thành bằng chứng có thể đo lường. Ngoài ra, tài liệu phục vụ kiểm toán và quy trình vận hành phục vụ chất lượng dịch vụ thực tế phải cùng hoạt động trong một hệ thống thống nhất.
Bài viết này trình bày các nguyên tắc và mô hình cốt lõi của COBIT 2019, các yếu tố thiết kế, hệ thống mục tiêu, quy trình triển khai, mối quan hệ với các tiêu chuẩn khác và những điểm cần cân nhắc khi áp dụng thực tế, ở mức độ của một bài thi tự luận.
2. Cấu trúc cơ bản của hệ thống quản trị COBIT 2019
A. Phân tách quản trị và quản lý
Quản trị chịu trách nhiệm về câu hỏi “làm gì và tại sao”. Hội đồng quản trị hoặc ban điều hành cấp cao đánh giá và quyết định danh mục đầu tư, mức chấp nhận rủi ro, định hướng tuân thủ và phân bổ nguồn lực. Ban điều hành đưa ra định hướng để các quyết định đó nhất quán với chiến lược của tổ chức, đồng thời liên tục giám sát hiệu quả và rủi ro so với kế hoạch.
Quản lý chịu trách nhiệm về câu hỏi “thực thi định hướng đã quyết định như thế nào”. Các hoạt động như thiết kế kiến trúc, thực hiện dự án, vận hành dịch vụ, ký hợp đồng với nhà cung cấp và xử lý sự cố thuộc về lĩnh vực này. Người quản lý phải cụ thể hóa các tiêu chí về hiệu quả, rủi ro và tuân thủ do cơ quan quản trị đưa ra thành kế hoạch và kiểm soát trong công việc hằng ngày.
Sự phân biệt này không đơn thuần là chia sơ đồ tổ chức thành hai phần. Ví dụ, khi thúc đẩy chuyển đổi lên đám mây, hội đồng quản trị quyết định giá trị chiến lược và phạm vi chấp nhận rủi ro của việc chuyển đổi, còn ban điều hành xây dựng kiến trúc mục tiêu, ngân sách và lộ trình. Nhóm vận hành thực hiện việc di chuyển (migration) và giám sát thực tế, nhưng nhóm vận hành không được tự ý thay đổi việc có chấp nhận rủi ro kinh doanh hay không.
Giữa quản trị và quản lý phải có phản hồi. Khi kết quả quản lý cho thấy vượt chi phí, gia tăng sự cố hay vi phạm quy định, người quản lý báo cáo nguyên nhân và phương án, còn cơ quan quản trị điều chỉnh lại mục tiêu cũng như hạn mức nguồn lực và rủi ro. Nếu chỉ tồn tại báo cáo một chiều, mục tiêu sẽ tách rời khỏi thực tế, vì vậy các chỉ số và cuộc họp ra quyết định phải có cấu trúc tuần hoàn.
B. Mô hình cốt lõi COBIT và năm miền
Mô hình cốt lõi của COBIT 2019 cung cấp một mô hình tham chiếu chung nhưng không áp đặt cùng một bộ kiểm soát cho mọi doanh nghiệp. Mục đích của mô hình là cung cấp một ngôn ngữ chung và cấu trúc có thể truy vết. Doanh nghiệp lấy cấu trúc này làm điểm xuất phát để chọn các mục tiêu quan trọng, và với những mục tiêu cần thiết thì xác định mức năng lực mục tiêu và bằng chứng kiểm soát.
flowchart TB
S[Yêu cầu các bên liên quan·chiến lược kinh doanh] --> G[Thiết kế hệ thống quản trị]
G --> EDM[EDM<br/>Đánh giá·Định hướng·Giám sát]
G --> APO[APO<br/>Liên kết·Lập kế hoạch·Tổ chức]
G --> BAI[BAI<br/>Xây dựng·Mua sắm·Triển khai]
G --> DSS[DSS<br/>Cung cấp·Dịch vụ·Hỗ trợ]
G --> MEA[MEA<br/>Giám sát·Đánh giá·Thẩm định]
EDM --> V[Giá trị·rủi ro·nguồn lực·hiệu quả]
APO --> BAI
BAI --> DSS
DSS --> MEA
MEA --> EDM
V --> S
EDM (Evaluate, Direct and Monitor) là miền tập hợp các mục tiêu quản trị. Miền này đánh giá yêu cầu của các bên liên quan, định hướng các phương án chiến lược và giám sát hiệu quả cũng như tình trạng tuân thủ. Đầu ra của EDM không phải là danh sách công việc vận hành mà là các quyết định của ban điều hành về định hướng đầu tư, chấp nhận rủi ro, sử dụng nguồn lực và minh bạch với các bên liên quan.
APO (Align, Plan and Organize) là miền quản lý liên kết thông tin và công nghệ với chiến lược, cơ cấu, nhân lực và chuỗi cung ứng của tổ chức. Chiến lược, kiến trúc doanh nghiệp, đổi mới, danh mục đầu tư, ngân sách, rủi ro, bảo mật, dữ liệu và kế hoạch nhân lực được kết nối với nhau. Điểm mấu chốt là không dừng lại ở việc lập kế hoạch mà phải bố trí nguồn lực và trách nhiệm thực tế để kế hoạch có thể thực thi.
BAI (Build, Acquire and Implement) là miền mua sắm, phát triển và thay đổi giải pháp để đưa vào nghiệp vụ một cách ổn định. Miền này bao gồm chương trình và dự án, yêu cầu, thay đổi, tài sản, cấu hình và quản lý tri thức. Nếu kiểm soát ở BAI yếu, sẽ phát sinh khoảng trống về chất lượng, bảo mật và khả năng truy vết giữa lập kế hoạch và vận hành.
DSS (Deliver, Service and Support) chịu trách nhiệm vận hành dịch vụ hằng ngày. Miền này bao gồm vận hành, yêu cầu dịch vụ và sự cố, vấn đề, tính liên tục, dịch vụ bảo mật và kiểm soát quy trình nghiệp vụ. Chỉ số vận hành không chỉ là tỷ lệ hoạt động (uptime) đơn thuần mà phải gắn với thời gian phục hồi, tỷ lệ tái diễn, tác động đến người dùng và chất lượng phát hiện, ứng phó bảo mật.
MEA (Monitor, Evaluate and Assess) là miền kiểm tra kiểm soát nội bộ, yêu cầu bên ngoài, hiệu quả và mức độ phù hợp. Miền này phân biệt tự đánh giá với đảm bảo độc lập và xác nhận xem các phát hiện đã thực sự được khắc phục xong hay chưa. Chỉ viết báo cáo kiểm toán thì không thể đạt được mục đích; các biện pháp cải tiến phải được phản ánh trở lại vào quyết định quản trị.
| Miền | Vai trò | Câu hỏi tiêu biểu |
|---|---|---|
| EDM | Quản trị | Ai quyết định định hướng về đầu tư, rủi ro và hiệu quả? |
| APO | Liên kết·lập kế hoạch | Kết nối chiến lược với nguồn lực I&T và kiến trúc như thế nào? |
| BAI | Xây dựng·thay đổi | Xây dựng giải pháp theo tiêu chí nào và đưa vào nghiệp vụ ra sao? |
| DSS | Vận hành·hỗ trợ | Cung cấp dịch vụ và phục hồi sự cố ở mức nào? |
| MEA | Đánh giá·đảm bảo | Đánh giá và cải tiến bằng chứng về hiệu quả và tuân thủ ra sao? |
Các miền trong bảng không phải là sự phân chia phòng ban theo trình tự. Ví dụ, yêu cầu bảo vệ thông tin cá nhân bắt đầu từ kế hoạch rủi ro và bảo mật ở APO, tiếp nối sang kiểm soát thiết kế và thay đổi ở BAI, được vận hành qua kiểm soát truy cập và ứng phó sự cố ở DSS, và được kiểm chứng bằng đánh giá tuân thủ ở MEA. Dù phân công người phụ trách theo miền, vẫn phải thiết kế cả đầu vào, đầu ra giữa các mục tiêu và các điểm bàn giao trách nhiệm.
3. Nguyên tắc và thành phần của COBIT 2019
A. Nguyên tắc của hệ thống quản trị
COBIT 2019 nhấn mạnh: quản trị có hệ thống và linh động để đáp ứng yêu cầu của các bên liên quan, phân tách quản trị và quản lý, góc nhìn đầu-cuối (end-to-end) bao trùm mọi chức năng của doanh nghiệp, một khung tích hợp duy nhất, góc nhìn toàn diện (holistic) và thiết kế tùy biến theo nhu cầu. Các nguyên tắc này không hẳn là danh mục kiểm tra mà là những góc nhìn không được bỏ sót khi thiết kế.
Góc nhìn toàn diện cảnh báo suy nghĩ rằng chỉ cần xây dựng quy trình tốt là kiểm soát sẽ vận hành. Nếu quy trình không có người chịu trách nhiệm, ủy ban không ra quyết định, thiếu dữ liệu cần thiết, hoặc hành vi của các thành viên mâu thuẫn với hệ thống khen thưởng, thì quy trình đã được văn bản hóa sẽ không dẫn đến kết quả thực tế. Kỹ sư chuyên nghiệp phải phân tích không chỉ thủ tục mà cả cơ cấu tổ chức, luồng thông tin, văn hóa và năng lực.
Góc nhìn đầu-cuối không giới hạn quản trị I&T trong hoạt động chất lượng nội bộ của bộ phận IT. Trong môi trường mà đơn vị kinh doanh tự mua SaaS, đối tác xử lý dữ liệu và kênh khách hàng gọi API, rủi ro I&T vượt ra ngoài ranh giới tổ chức. Chỉ khi bao gồm cả quản trị doanh nghiệp, quy trình nghiệp vụ và chuỗi cung ứng bên ngoài thì trách nhiệm ra quyết định mới khớp với vị trí thực tế của rủi ro.
Nguyên tắc thiết kế tùy biến giảm bớt sự lãng phí của cách “áp dụng toàn bộ COBIT”. Quy định và rủi ro an ninh mạng của tổ chức tài chính khác với rủi ro công nghệ vận hành (OT) của ngành sản xuất, và tốc độ của một startup cũng khác với cơ chế kiểm soát phân tách của một tập đoàn lớn. Ngay cả cùng một mục tiêu, mức năng lực yêu cầu, tần suất bằng chứng, cấp phê duyệt và mức độ tự động hóa cũng có thể khác nhau.
B. Bảy thành phần của hệ thống quản trị
Hệ thống quản trị bao gồm: nguyên tắc và chính sách, quy trình, cơ cấu tổ chức, thông tin, dịch vụ·hạ tầng·ứng dụng, con người·kỹ năng·năng lực, và văn hóa·đạo đức·hành vi. Một số tài liệu dịch tên các thành phần theo cách khác, nhưng điểm cốt lõi là không giải thích quản trị chỉ bằng quy trình.
Nguyên tắc, chính sách và khung tạo ra ranh giới cho việc ra quyết định. Chúng phải được cụ thể hóa thành các quy tắc giúp thành viên có thể tự phán đoán, như chính sách sử dụng đám mây, chính sách phân loại dữ liệu, tiêu chí quản lý thay đổi và tiêu chí thuê ngoài. Nếu chính sách chỉ dừng ở tuyên bố, sẽ không có tiêu chí ngoại lệ và phê duyệt, dẫn đến gia tăng cách diễn giải tùy tiện tại hiện trường.
Quy trình xác định các hoạt động có thể lặp lại cùng với đầu vào, đầu ra và kiểm soát nhằm đạt mục tiêu. Mức độ trưởng thành của quy trình không được đánh giá bằng độ dày tài liệu mà bằng việc công việc thực tế có được tái hiện, ngoại lệ có được ghi nhận và kết quả có được đo lường hay không. Luồng phê duyệt tự động và dấu vết trên ticket là phương tiện giúp việc thực thi quy trình trở nên hữu hình.
Cơ cấu tổ chức là sự bố trí quyền ra quyết định và trách nhiệm. Nếu quyền hạn của hội đồng quản trị, ủy ban rủi ro, ủy ban dữ liệu, ủy ban kiến trúc, CISO, CIO và chủ sở hữu sản phẩm của đơn vị kinh doanh bị chồng chéo hoặc bỏ trống, tốc độ kiểm soát sẽ chậm lại. Khi xây dựng RACI, cần phân biệt người thực hiện và người phê duyệt, đồng thời làm rõ người có thẩm quyền chấp nhận rủi ro cuối cùng.
Thông tin là nhiên liệu cho quản trị vận hành. Nếu tình trạng danh mục đầu tư, sổ đăng ký rủi ro, thông tin tài sản và cấu hình, SLA, chỉ số sự cố và kết quả kiểm toán sử dụng các định nghĩa khác nhau, độ tin cậy của báo cáo lên ban điều hành sẽ giảm. Cần xác định chủ sở hữu dữ liệu, tiêu chí chất lượng, chu kỳ cập nhật, thời hạn lưu trữ và chuẩn hóa công thức tính chỉ số.
Dịch vụ, hạ tầng và ứng dụng là các nguồn lực công nghệ tạo ra giá trị thực tế. Không chỉ nhìn vào tính sẵn sàng mà cần định nghĩa khả năng phục hồi, tính bảo mật, khả năng mở rộng, khả năng tương tác và hiệu quả chi phí thành mức dịch vụ. Khi danh mục dịch vụ được kết nối với dữ liệu quản lý cấu hình, có thể nhanh chóng xác định phạm vi ảnh hưởng của sự cố và rủi ro thay đổi.
Con người, kỹ năng và năng lực là khả năng thực hiện các kiểm soát đã được lên kế hoạch. Ví dụ, dù đã có chính sách bảo mật đám mây, nếu năng lực của người thiết kế IAM, người phân tích nhật ký và người ứng phó sự cố còn thiếu thì kiểm soát chỉ mang tính hình thức. Điều quan trọng không phải là tỷ lệ hoàn thành đào tạo mà là việc thực hiện vai trò thực tế, kết quả diễn tập, và khả năng luân phiên, thay thế.
Văn hóa, đạo đức và hành vi quyết định việc né tránh kiểm soát và chậm trễ báo cáo. Trong một văn hóa che giấu sự cố, chỉ số tỷ lệ hoạt động có thể trông tốt nhưng rủi ro tiềm ẩn vẫn tích tụ. Cần có môi trường mà việc báo cáo sai sót dẫn đến học hỏi và cải tiến, cùng hệ thống khen thưởng đánh giá bảo mật và thông tin cá nhân song song với tiến độ bàn giao.
C. Các tầng mục tiêu và thực hành quản lý
Mỗi mục tiêu quản trị và quản lý được cụ thể hóa bằng mục đích, chỉ số liên quan, thực hành thực hiện, trách nhiệm và mối quan hệ đầu vào-đầu ra. Mục tiêu không kết thúc một cách trừu tượng như “tăng cường bảo mật”, mà phải mô tả trạng thái trong đó dịch vụ bảo mật được cung cấp và giám sát phù hợp với mức rủi ro và chính sách đã phê duyệt.
Thực hành thực hiện là các hoạt động chi tiết cần tiến hành để đạt mục tiêu. Ví dụ, ở mục tiêu quản lý thay đổi, việc phân loại yêu cầu thay đổi, phân tích tác động, phê duyệt, kiểm thử, triển khai, rà soát sau triển khai và thủ tục ngoại lệ cho thay đổi khẩn cấp phải được kết nối. Nếu lưu lại hồ sơ phê duyệt, kết quả kiểm thử, nhật ký triển khai và rà soát sau triển khai làm bằng chứng cho hoạt động, có thể hỗ trợ đồng thời cả kiểm toán lẫn cải tiến vận hành.
Chỉ số của mục tiêu phải phân biệt khối lượng hoạt động với kết quả. Chỉ tăng số buổi đào tạo hay số lần rà soát chưa chắc đã giảm được sự cố. Vì vậy, bên cạnh tỷ lệ thực hiện kiểm soát, cần đặt các chỉ số kết quả như tỷ lệ sự cố tái diễn, tỷ lệ thay đổi không được phê duyệt, thời gian khắc phục lỗ hổng trung bình và thời gian ảnh hưởng đến dịch vụ.
4. Yếu tố thiết kế và thiết kế quản trị tùy biến
A. Ý nghĩa của yếu tố thiết kế
Yếu tố thiết kế (design factor) của COBIT 2019 là các giá trị đầu vào dùng để điều chỉnh thứ tự ưu tiên và mức năng lực mục tiêu thay vì áp dụng đồng loạt hệ thống quản trị của doanh nghiệp. Phạm vi ban đầu được xác định dựa trên chiến lược và mục tiêu, hồ sơ rủi ro và các vấn đề liên quan đến I&T, sau đó được tinh chỉnh khi xét đến môi trường mối đe dọa, yêu cầu tuân thủ, vai trò của IT, mô hình nguồn lực (sourcing), phương pháp triển khai, chiến lược áp dụng công nghệ và quy mô doanh nghiệp.
Yếu tố thiết kế không phải là điểm khảo sát đơn thuần. Mỗi giá trị phải có căn cứ. Ví dụ, nếu đánh giá môi trường mối đe dọa là cao, cần gắn với các bằng chứng như các cuộc tấn công gần đây, tài sản bị phơi nhiễm, thông tin tình báo mối đe dọa và xu hướng tấn công theo ngành. Nếu chọn mô hình nguồn lực chủ yếu thuê ngoài, cần rà soát cùng lúc quyền kiểm toán trong hợp đồng, bên xử lý thứ cấp, mức dịch vụ và kế hoạch chấm dứt, chuyển giao.
B. Quy trình làm việc thiết kế
flowchart LR
A[Nắm bắt chiến lược·mục tiêu doanh nghiệp] --> B[Chẩn đoán rủi ro·vấn đề I&T]
B --> C[Xác định phạm vi ban đầu<br/>chiến lược·mục tiêu·rủi ro·vấn đề]
C --> D[Tinh chỉnh<br/>mối đe dọa·tuân thủ·vai trò IT·nguồn lực·phương pháp·áp dụng·quy mô]
D --> E[Giải quyết xung đột ưu tiên giữa các mục tiêu]
E --> F[Chốt mức năng lực mục tiêu·trách nhiệm·lộ trình]
F --> G[Vận hành·đo lường·đảm bảo độc lập]
G --> H[Thay đổi·sự cố·điều chỉnh chiến lược]
H --> A
Bước đầu tiên là hiểu chiến lược và mục tiêu của doanh nghiệp. Cần phân tích xem các biểu hiện chiến lược như hiệu quả chi phí, tăng trưởng, niềm tin khách hàng, tuân thủ quy định và khả năng chống chịu đòi hỏi những kết quả gì từ I&T. Nếu ở bước này chỉ nhìn vào danh sách dự án hiện tại của bộ phận IT, có thể chỉ dừng ở mức hợp thức hóa các dự án đã khởi động, vì vậy phải xuất phát từ kết quả kinh doanh và kỳ vọng của các bên liên quan.
Bước thứ hai là xác định phạm vi ban đầu. Thông qua chiến lược, mục tiêu doanh nghiệp, hồ sơ rủi ro và các vấn đề I&T hiện tại, thu hẹp lại các mục tiêu quan trọng. Ví dụ, trong một tổ chức mà dịch vụ tài chính số là cốt lõi, nếu sự cố xác thực và vi phạm thông tin cá nhân là rủi ro chính thì thứ tự ưu tiên của các mục tiêu về bảo mật, tính liên tục, sự cố và dữ liệu có thể được nâng lên.
Bước thứ ba là tinh chỉnh. Phương thức kiểm soát của cùng một mục tiêu sẽ khác nhau tùy vào việc đó có phải ngành chịu quản lý chặt không, IT có phải là cốt lõi của kinh doanh không, có phụ thuộc phần lớn vào đám mây bên ngoài không, có triển khai nhanh theo Agile/DevOps không, và có áp dụng công nghệ mới theo hướng tiên phong không. Nếu quy mô doanh nghiệp nhỏ, có thể kiêm nhiệm vai trò, nhưng phải nêu rõ các kiểm soát thay thế cho việc rà soát chéo và tính độc lập.
Bước cuối cùng là giải quyết xung đột ưu tiên. Tăng cường phê duyệt bảo mật sẽ làm chậm tốc độ triển khai, còn tăng thời gian lưu trữ dữ liệu vừa làm tăng sự thuận tiện cho phân tích vừa làm tăng rủi ro thông tin cá nhân. Không được che giấu xung đột mà phải ghi lại các giả định về rủi ro, chi phí và giá trị, đồng thời quyết định người chấp nhận rủi ro cuối cùng và thời điểm rà soát.
C. Sản phẩm đầu ra khi áp dụng yếu tố thiết kế
Kết quả của hội thảo thiết kế không nên chỉ là một bảng điểm mà phải là một bản thiết kế quản trị. Tối thiểu cần bao gồm liên kết giữa mục tiêu doanh nghiệp và mục tiêu I&T, danh sách mục tiêu ưu tiên, mức năng lực mục tiêu, tổ chức chịu trách nhiệm, kiểm soát cốt lõi, bằng chứng, chi phí dự kiến và lộ trình theo từng giai đoạn.
| Sản phẩm đầu ra | Nội dung cốt lõi | Điểm rà soát |
|---|---|---|
| Báo cáo chẩn đoán bối cảnh | Chiến lược·quy mô·rủi ro·quy định·vấn đề hiện tại | Đã phân biệt sự thật và ý kiến chưa? |
| Thứ tự ưu tiên mục tiêu | Các mục tiêu trọng tâm trong 40 mục tiêu và lý do | Có căn cứ về rủi ro·giá trị không? |
| Định nghĩa mức năng lực | Mức hiện tại và mức mục tiêu theo từng mục tiêu | Có kế hoạch khả thi để nâng mức không? |
| Ma trận trách nhiệm | Vai trò của HĐQT·ban điều hành·thực thi·nhà cung cấp | Người chấp nhận rủi ro đã rõ ràng chưa? |
| Danh mục kiểm soát·bằng chứng | Hoạt động·chỉ số·phê duyệt·nhật ký·báo cáo | Bằng chứng có được tạo tự động không? |
| Lộ trình thực hiện | Cải tiến nhanh, xây dựng trung hạn, cải tiến liên tục | Đã phản ánh sự phụ thuộc và ngân sách chưa? |
Nếu không phân biệt mức hiện tại với mức mục tiêu, sẽ chỉ còn lại tuyên bố “đạt mức trưởng thành 4”. Khi xác định mức mục tiêu, cần rà soát đồng thời yêu cầu tối thiểu theo luật, tác động kinh doanh, hiệu quả giảm rủi ro, năng lực cần thiết và khả năng tự động hóa. Thay vì mặc nhiên gán mức cao nhất cho các mục tiêu rủi ro cao, cần giải thích để ban điều hành hiểu chi phí nâng mức và rủi ro còn lại.
5. Mức năng lực mục tiêu và đo lường hiệu quả
A. Diễn giải mức năng lực
Năng lực quy trình trong COBIT 2019 là góc nhìn để đánh giá mức độ thực hiện hoạt động và mức độ quản lý, đo lường, cải tiến. Ở mức thấp, công việc có thể phụ thuộc vào kinh nghiệm cá nhân, nhưng mức càng cao thì tính chuẩn hóa, đo lường, dự báo và cải tiến liên tục càng được tăng cường. Điều cần xem không phải bản thân con số mà là tổ chức có thể lặp lại kết quả một cách ổn định hay không.
Đánh giá mức năng lực không được quyết định chỉ dựa trên việc có tài liệu hay không. Cần kiểm tra xem chính sách, hồ sơ thực hiện, kiểm thử mẫu, phỏng vấn, xu hướng chỉ số, xử lý ngoại lệ và biện pháp cải tiến có nhất quán với nhau hay không. Nếu có chính sách nhưng thay đổi không được phê duyệt vẫn lặp lại, thì mức tài liệu và mức thực thi khác nhau, và sự chênh lệch đó phải được phản ánh vào kết luận kiểm toán và kế hoạch cải tiến.
Cách nâng mức hiện tại không chỉ là tăng nhân lực. Có thể nhúng các công việc lặp lại vào hệ thống như API chuẩn và kiểm chứng chính sách tự động, cổng phê duyệt trong pipeline triển khai, nhật ký tập trung và danh mục dịch vụ. Tuy nhiên, tự động hóa có thể lan truyền nhanh một chính sách sai, nên cần thiết kế đồng thời cả việc rà soát thay đổi chính sách và khả năng quay lui (rollback).
B. Phân tầng chỉ số
Quản lý hiệu quả cần chia chỉ số thành các tầng: chỉ số cho ban điều hành, chỉ số quản lý và chỉ số vận hành. Ban điều hành nhìn vào giá trị kinh doanh, mức độ phơi nhiễm rủi ro, tuân thủ quy định và khả năng phục hồi của dịch vụ cốt lõi; người quản lý nhìn vào độ lệch của dự án, dịch vụ và nhà cung cấp. Người vận hành sử dụng các chỉ số thực thi như thời gian ứng phó từng sự cố, triển khai thất bại và khắc phục lỗ hổng.
Ví dụ, chỉ số “tính sẵn sàng dịch vụ 99.9%” nếu chỉ tính bằng trung bình toàn tháng là chưa đủ. Cần phân biệt tính sẵn sàng trong khung giờ giao dịch quan trọng, tác động của sự cố đến khách hàng, việc đạt mục tiêu phục hồi và gián đoạn do thay đổi có kế hoạch. Ngay cả cùng một chỉ số, nếu định nghĩa và mẫu số khác nhau thì việc so sánh giữa các phòng ban sẽ bị bóp méo, nên công thức tính phải được quản lý tập trung.
Chỉ số rủi ro không chỉ nhìn vào số sự kiện đã xảy ra. Cần bao gồm các chỉ số dẫn dắt (leading indicator) như tỷ lệ tài sản quan trọng chưa áp dụng xác thực đa yếu tố, mức phơi nhiễm phần mềm đã hết hỗ trợ, thời gian khắc phục trung bình lỗ hổng rủi ro cao, tỷ lệ diễn tập phục hồi thành công và tỷ lệ chưa hoàn thành kiểm tra nhà cung cấp. Khi xem đồng thời chỉ số sau sự cố và chỉ số phòng ngừa, có thể sớm phát hiện chiều hướng gia tăng của rủi ro.
C. Đảm bảo độc lập và tự đánh giá
Người quản lý thực hiện tự đánh giá thường xuyên, còn kiểm toán nội bộ độc lập hoặc đảm bảo từ bên thứ ba rà soát sự thiên lệch của tự đánh giá và tính thích đáng của thiết kế kiểm soát. Hai hoạt động này không cạnh tranh với nhau. Nếu tự đánh giá chính xác, phạm vi đảm bảo độc lập có thể tập trung vào các lĩnh vực rủi ro cao.
Kết quả đảm bảo không dừng lại ở phép nhị phân đạt/không đạt mà phải bao gồm mức độ nghiêm trọng của rủi ro, tác động nghiệp vụ, khả năng tái diễn, người chịu trách nhiệm khắc phục và thời hạn. Không đóng phát hiện chỉ dựa trên báo cáo đã khắc phục xong mà phải kiểm thử lại và kiểm chứng tính hiệu lực. Các phát hiện lặp lại có thể là vấn đề trong thiết kế mục tiêu, tổ chức và quy trình hơn là sai sót của từng người phụ trách.
6. Quy trình triển khai và mô hình vận hành
A. Chuẩn bị và xác định phạm vi
Bước đầu tiên của triển khai không phải là đào tạo về khung mà là xác định vấn đề và mục đích. Cần làm rõ các động lực như chi phí quá cao, sự cố lặp lại, phát hiện từ kiểm toán quản lý nhà nước, dự án thất bại và phụ thuộc vào nhà cung cấp, đồng thời ước tính tác động kinh doanh nếu không giải quyết. Người bảo trợ không nên giới hạn ở một mình CIO mà cần có sự tham gia của những người phụ trách kinh doanh, rủi ro, tài chính và bảo mật.
Phạm vi có thể là toàn doanh nghiệp hoặc một dịch vụ cốt lõi. Nếu ngay từ đầu xử lý cả 40 mục tiêu trên toàn doanh nghiệp, sự phản kháng tại hiện trường và gánh nặng tài liệu sẽ lớn. Ngược lại, nếu quá hẹp có thể bỏ sót rủi ro của các hệ thống lân cận và nhà cung cấp, vì vậy cần xác định ranh giới dựa trên chuỗi giá trị dịch vụ và luồng dữ liệu.
B. Chẩn đoán hiện trạng và mô hình mục tiêu
Trong chẩn đoán hiện trạng, trước tiên cần xác định các tài sản sẵn có như ITIL, ISO/IEC 27001, ISO/IEC 38500, PMBOK, kiểm soát nội bộ và hệ thống quản lý bảo vệ thông tin cá nhân. Thay vì xây dựng COBIT thành một hệ thống kiểm soát riêng biệt, trùng lặp, cách hiệu quả hơn là liên kết các hoạt động hiện có với các mục tiêu COBIT.
Ví dụ, quy trình quản lý sự cố của ITIL có thể liên kết với DSS02, còn đánh giá rủi ro và kiểm soát truy cập của hệ thống quản lý bảo mật thông tin có thể liên kết với APO12·APO13 và DSS05. Không chỉ đối chiếu tên gọi mà phải so sánh ý đồ của mục tiêu, trách nhiệm, tần suất thực hiện, bằng chứng và khoảng trống.
Phân tích khoảng trống (gap analysis) sẽ hữu ích nếu chia thành khoảng trống tài liệu, khoảng trống thực thi và khoảng trống hiệu quả. Khoảng trống tài liệu là trạng thái không có chính sách, thủ tục và vai trò; khoảng trống thực thi là trạng thái có thủ tục nhưng không được thực hiện. Khoảng trống hiệu quả là trạng thái có thực hiện nhưng không đạt được mức giảm rủi ro hoặc hiệu quả dịch vụ mong muốn, và có thể cần thiết kế lại tự động hóa, nguồn lực và giá trị mục tiêu.
C. Thực hiện theo giai đoạn và quản lý thay đổi
Các nhiệm vụ cải tiến nhanh được chọn từ những lĩnh vực có rủi ro cao và dễ đo lường hiệu quả. Ví dụ, các nhiệm vụ như rà soát tài khoản đặc quyền, diễn tập phục hồi cho dịch vụ quan trọng, chặn thay đổi không được phê duyệt, hết hạn quyền truy cập của nhà cung cấp bên ngoài và chỉ định chủ sở hữu dữ liệu cốt lõi có thể kiểm tra kết quả trong chu kỳ ngắn.
Các nhiệm vụ trung hạn là nền tảng kết nối nhiều tổ chức như danh mục dịch vụ, quản lý cấu hình, sổ đăng ký rủi ro tích hợp, bảng điều khiển hiệu quả và tự động hóa chính sách. Những nhiệm vụ này không thể chỉ xây dựng về mặt công nghệ mà phải xác định đồng thời định nghĩa dữ liệu, trách nhiệm, phê duyệt ngoại lệ và chi phí vận hành.
Quản lý thay đổi không kết thúc bằng việc phát tài liệu đào tạo. Cần giải thích cho bộ phận nghiệp vụ lý do phải phê duyệt và ghi nhận thông qua tác động nghiệp vụ, đồng thời mang lại trải nghiệm rằng quy trình mới nhanh hơn hoặc an toàn hơn trước. Nếu đánh giá và khen thưởng không phản ánh kết quả về chất lượng, bảo mật và phục hồi, tổ chức có thể quay lại hành vi chỉ coi trọng tiến độ bàn giao.
7. Tình huống: Quản trị kênh số của một công ty tài chính
Giả sử một công ty tài chính mở rộng kênh cho vay trên di động, đồng thời áp dụng đám mây và dịch vụ AI bên ngoài. Mục tiêu kinh doanh là rút ngắn thời gian thẩm định và nâng cao sự tiện lợi cho khách hàng, nhưng rò rỉ thông tin cá nhân, thiên lệch của mô hình, sự cố dịch vụ, ủy thác lại cho bên thứ ba và vi phạm quy định trở thành các rủi ro chính.
Trước hết, cơ quan quản trị quyết định mức độ tự động hóa và các nghiệp vụ cần con người rà soát. Chức năng hỗ trợ trong đó AI phát hiện hồ sơ thiếu sót và chức năng quyết định cuối cùng việc phê duyệt tín dụng có mức sai sót cho phép và trách nhiệm khác nhau, nên không gộp chung vào cùng một kiểm soát. Các trường hợp thay đổi mô hình và dữ liệu ảnh hưởng đến kết quả thẩm định được định nghĩa là thay đổi trọng yếu.
Ở giai đoạn APO, thiết kế phân loại dữ liệu, đánh giá rủi ro, điều kiện đối với nhà cung cấp bên ngoài, nguyên tắc quản lý mô hình và mức dịch vụ. Ở giai đoạn BAI, đưa vào yêu cầu việc thu thập thông tin cá nhân tối thiểu, khả năng giải thích và nhật ký kiểm toán, đồng thời đặt rà soát độc lập đối với thay đổi mô hình và API. Ở giai đoạn DSS, vận hành xử lý sự cố, tai nạn, khiếu nại và phát hiện sai (false positive), còn ở giai đoạn MEA, định kỳ đánh giá bằng chứng về hiệu năng mô hình và tuân thủ quy định.
Chỉ số vận hành không chỉ là thời gian phê duyệt trung bình. Cần xem đồng thời tính sẵn sàng của kênh, tỷ lệ tạm hoãn thẩm định, tỷ lệ chuyển sang rà soát thủ công, chênh lệch sai số theo từng nhóm khách hàng, dấu hiệu bất thường trong truy cập thông tin cá nhân, vi phạm SLA của nhà cung cấp và kết quả diễn tập phục hồi. Nếu tốc độ đã cải thiện nhưng sai số ở một nhóm khách hàng cụ thể tăng lên thì không thể coi là đã đạt mục tiêu quản trị.
Điều quan trọng trong tình huống này không phải là áp dụng thật nhiều mục tiêu COBIT. Điều quan trọng là xác định giá trị và rủi ro cốt lõi của kinh doanh, rồi kết nối các mục tiêu giảm thiểu rủi ro đó với trách nhiệm và bằng chứng. Cách thiết kế tương tự có thể áp dụng cho dịch vụ công, công nghệ vận hành trong sản xuất và nền tảng dữ liệu y tế, nhưng giá trị của các yếu tố thiết kế và mức năng lực mục tiêu phải khác nhau.
8. So sánh COBIT 2019 với các tiêu chuẩn và khung liên quan
COBIT 2019 cung cấp cấu trúc tổng thể của quản trị và quản lý, trong khi các tiêu chuẩn khác cung cấp hướng dẫn sâu hơn cho một mục đích hoặc lĩnh vực cụ thể. Vì vậy, thay vì chọn một và bỏ phần còn lại, cách thực tế hơn là xem COBIT là cấu trúc liên kết và đánh giá ở cấp trên, rồi bố trí các kiểm soát chi tiết của các tiêu chuẩn hiện có vào các mục tiêu.
| Phân loại | COBIT 2019 | ISO/IEC 27001 | ITIL 4 | ISO/IEC 38500 |
|---|---|---|---|---|
| Mục đích chính | Hệ thống quản trị·quản lý I&T | Hệ thống quản lý bảo mật thông tin | Quản lý dịch vụ IT | Nguyên tắc quản trị IT doanh nghiệp |
| Phạm vi | Giá trị·rủi ro·nguồn lực·hiệu quả và toàn bộ vòng đời | Rủi ro và kiểm soát bảo mật thông tin | Tạo giá trị và vận hành dịch vụ | Đánh giá·định hướng·giám sát ở cấp HĐQT |
| Điểm mạnh | Tích hợp yếu tố thiết kế·mục tiêu·năng lực·đảm bảo | Cấu trúc ISMS có thể chứng nhận | Thực hành vận hành dịch vụ và dòng giá trị | Làm rõ trách nhiệm của người ra quyết định cao nhất |
| Cách áp dụng | Ưu tiên hóa rồi áp dụng tùy biến | Lựa chọn kiểm soát dựa trên rủi ro | Kết hợp các thực hành quản lý dịch vụ | Ban điều hành ra quyết định theo nguyên tắc |
Khác biệt giữa COBIT và ISO/IEC 27001 không phải là hơn kém mà là mức độ trừu tượng và mục đích. Ngoài bảo mật, COBIT còn kết nối đầu tư, kiến trúc, danh mục, dự án, vận hành và đảm bảo. ISO/IEC 27001 mạnh trong việc quản lý rủi ro bảo mật thông tin và chứng minh sự cải tiến liên tục của hệ thống quản lý, nên có thể cung cấp kiểm soát chi tiết và bằng chứng đánh giá cho các mục tiêu bảo mật và rủi ro của COBIT.
COBIT và ITIL 4 cũng không cạnh tranh nhau. ITIL cụ thể hóa các thực hành quản lý dịch vụ để dịch vụ đồng tạo ra giá trị, còn COBIT điều chỉnh từ góc độ quản trị để việc quản lý dịch vụ đó phù hợp với mục tiêu doanh nghiệp và định hướng về rủi ro, tuân thủ. Khi kết nối chỉ số quản lý sự cố của ITIL với báo cáo hiệu quả và rủi ro của COBIT, cải tiến vận hành sẽ được đưa lên thành quyết định điều hành.
ISO/IEC 38500 nhấn mạnh nguyên tắc rằng hội đồng quản trị phải đánh giá, định hướng và giám sát IT. Tiêu chuẩn này có thể liên kết tự nhiên với miền EDM của COBIT, nhưng COBIT mở rộng các nguyên tắc đó đến mức mục tiêu quản lý, thành phần, năng lực và bằng chứng. Kỹ sư chuyên nghiệp phải hợp nhất trách nhiệm và các cơ quan họp để không tạo ra các ủy ban trùng lặp và báo cáo kép.
9. Chuyên sâu: Áp dụng COBIT trong thời đại đám mây và AI
Trong môi trường đám mây, dù tài sản không nằm trong trung tâm dữ liệu của tổ chức thì trách nhiệm quản trị cũng không mất đi. Cần ghi rõ trong hợp đồng và quy trình vận hành về cấu hình và nhật ký của phần mềm dạng dịch vụ, vị trí xử lý dữ liệu, cấu trúc thầu phụ, việc hoàn trả và xóa dữ liệu khi chấm dứt, và trách nhiệm phục hồi. Mô hình trách nhiệm chia sẻ chỉ giải thích ranh giới trách nhiệm giữa nhà cung cấp và khách hàng, không phải là căn cứ để khách hàng ủy thác quyết định chấp nhận rủi ro cho nhà cung cấp.
Trong hệ thống AI, thay đổi dữ liệu và mô hình diễn ra liên tục. Do đó, bằng chứng vận hành kết nối phiên bản dữ liệu và mô hình, việc thực hiện đánh giá, thay đổi prompt và chính sách, rà soát của con người, sự cố và rollback quan trọng hơn các tài liệu phê duyệt tĩnh. Khi kết nối model card, datasheet, model registry và kết quả red team với các mục tiêu của APO·BAI·DSS·MEA, có thể nâng cao đồng thời tính minh bạch và kiểm soát vận hành.
Trong môi trường DevOps và Agile, cách chặn mọi thay đổi bằng sự phê duyệt chậm chạp của ủy ban là không hiệu quả. Cần phân loại thay đổi dựa trên rủi ro và nhúng kiểm thử tự động, kiểm chứng chính sách, phê duyệt triển khai, khả năng quan sát (observability) và rollback vào pipeline. Với thay đổi rủi ro cao, áp dụng phê duyệt tách biệt và rà soát sau triển khai, còn thay đổi lặp lại rủi ro thấp có thể xử lý như thay đổi chuẩn đã được phê duyệt trước.
Tính bền vững cũng có thể trở thành một yếu tố thiết kế của quản trị I&T. Cần phản ánh điện năng trung tâm dữ liệu, chi phí suy luận của mô hình, tuổi thọ thiết bị, dữ liệu thải bỏ và rủi ro môi trường, xã hội của chuỗi cung ứng vào danh mục đầu tư và chỉ số hiệu quả. Nếu chỉ cắt giảm tài nguyên để tiết kiệm chi phí, khả năng phục hồi và bảo mật có thể xấu đi, vì vậy cần quản lý với mục tiêu cân bằng giữa carbon, chi phí, chất lượng dịch vụ và rủi ro.
10. Những điểm cần cân nhắc và hàm ý
A. Ưu tiên tính hiệu lực của ra quyết định hơn việc áp dụng khung
Nếu chứng nhận COBIT hay số lượng tài liệu trở thành mục đích, hiện trường sẽ cảm thấy mệt mỏi vì kiểm soát, còn ban điều hành lại không thấy được rủi ro thực tế. Cần chọn trước các dịch vụ cốt lõi và luồng dữ liệu, đồng thời làm rõ mong muốn cải thiện quyết định nào. Các hạng mục của khung được sử dụng như một ngôn ngữ chung để giải thích quyết định và rủi ro.
B. Thiết kế đồng thời trách nhiệm và quyền hạn
Nếu chỉ định người chịu trách nhiệm mà không trao quyền về ngân sách, nhân lực và quyền dừng, thất bại kiểm soát sẽ bị quy về vấn đề cá nhân. Cần phân biệt người chấp nhận rủi ro, người vận hành kiểm soát, người rà soát độc lập và người phụ trách phía nhà cung cấp, đồng thời thử nghiệm đường ra quyết định khi xảy ra sự cố hoặc thay đổi quy định. RACI không chỉ bao gồm trách nhiệm mà còn cả phán quyết cuối cùng và điều kiện leo thang (escalation).
C. Nhúng bằng chứng vào luồng công việc
Cách thu thập bằng chứng ngay trước kỳ kiểm toán làm tăng khả năng bỏ sót và thao túng. Ticket, kho mã nguồn, nhật ký triển khai, rà soát truy cập, giám sát dịch vụ, kết quả đào tạo và diễn tập cần được tạo và lưu trữ tự động trong quá trình làm việc bình thường. Ngay cả bằng chứng tự động cũng chỉ đáng tin cậy khi quản lý được độ chính xác của dữ liệu nguồn, quyền truy cập và thời hạn lưu trữ.
D. Công khai thứ tự ưu tiên dựa trên rủi ro và rủi ro còn lại
Kế hoạch quản lý mọi mục tiêu ở mức cao nhất đã bỏ qua các ràng buộc về chi phí và tốc độ. Cần trình bày để ban điều hành hiểu được căn cứ quyết định ưu tiên, mức năng lực mục tiêu, ngân sách và rủi ro còn lại dự kiến. Rủi ro còn lại đã được chấp nhận phải kèm thời hạn và điều kiện tái đánh giá, không được tạo ra sự miễn trừ vĩnh viễn chỉ bằng cụm từ “thấp”.
E. Đưa chuỗi cung ứng và ranh giới tổ chức vào quản trị
SaaS, đám mây, mã nguồn mở, API AI bên ngoài và nhà phát triển thầu phụ ảnh hưởng trực tiếp đến hiệu quả và rủi ro I&T của doanh nghiệp. Không chỉ kiểm tra quyền kiểm toán trong hợp đồng mà cần kiểm chứng vị trí và truy cập dữ liệu, thông báo lỗ hổng, báo cáo sự cố, thay đổi thầu phụ, chấm dứt và chuyển giao dịch vụ, cũng như kiểm thử phục hồi. Kết quả kiểm soát nhà cung cấp cũng phải được kết nối với sổ đăng ký rủi ro nội bộ và báo cáo hiệu quả.
F. Xây dựng cấu trúc rà soát và học hỏi liên tục
Khi chiến lược, quy định, mối đe dọa và phương thức áp dụng công nghệ thay đổi, yếu tố thiết kế và thứ tự ưu tiên mục tiêu cũng thay đổi. Ngoài rà soát định kỳ, cần định nghĩa các sự kiện như sự cố nghiêm trọng, mua bán và sáp nhập, chuyển đổi lên đám mây, thay đổi mô hình AI và sửa đổi quy định làm tác nhân kích hoạt thiết kế lại. Quản trị không phải là một dự án hoàn thành một lần mà là năng lực vận hành phản ứng với thay đổi.
Tài liệu tham khảo
- ISACA, “COBIT®| Control Objectives for Information Technologies®” — https://www.isaca.org/resources/cobit
- ISACA, “COBIT 2019 and COBIT 5 Comparison: Governance System Design” — https://www.isaca.org/resources/news-and-trends/industry-news/2020/cobit-2019-and-cobit-5-comparison
- ISACA, “New COBIT 2019 Resources Help Organizations Design and Implement Tailored Governance Systems” — https://www.isaca.org/about-us/newsroom/press-releases/2018/new-cobit-2019-resources-help-organizations-design-and-implement-tailored-governance-systems
- ISACA, “Designing Your Organization’s Custom COBIT” — https://www.isaca.org/resources/news-and-trends/industry-news/2019/designing-your-organizations-custom-cobit
- ISACA, “Defining Target Capability Levels in COBIT 2019” — https://www.isaca.org/resources/news-and-trends/industry-news/2019/defining-target-capability-levels-in-cobit-2019-a-proposal-for-refinement
Tóm tắt một câu: COBIT 2019 là khung tùy biến phản ánh chiến lược, rủi ro, quy định và môi trường công nghệ của doanh nghiệp thành các yếu tố thiết kế, qua đó kết nối quản trị và quản lý I&T với mục tiêu, trách nhiệm, bằng chứng và hiệu quả.