Xác định Audit Universe và lựa chọn các lĩnh vực IT ưu tiên kiểm toán.

Chọn đơn vị kiểm toán theo câu hỏi có thể kết luận

Một đối tượng trong Audit Universe có thể là quy trình, dịch vụ, hệ thống, đơn vị hoặc lĩnh vực rủi ro. Tổ chức cần lựa chọn cách cấu trúc phù hợp với hoạt động. Không có một danh sách IT bắt buộc chung cho mọi doanh nghiệp; mô hình phải giúp nối mục tiêu, rủi ro và phạm vi có thể kiểm tra.

Đơn vị quá rộng khiến khó xác định câu hỏi và bằng chứng. “Toàn bộ IT” có thể phù hợp mô tả tổng thể nhưng không đủ để hoạch định một cuộc cụ thể. Ngược lại, tách mỗi thiết bị thành một đơn vị làm danh mục lớn mà không phản ánh cơ chế dùng chung. Cần chọn mức chi tiết đủ để quyết định công việc có ý nghĩa.

Danh mục cũng không đồng nghĩa kế hoạch năm. Audit Universe thể hiện các đối tượng có thể xem; kế hoạch lựa chọn một số công việc theo rủi ro, nhu cầu đảm bảo và nguồn lực. Nếu chỉ ghi những lĩnh vực chắc chắn sẽ làm trong kỳ, tổ chức khó nhìn phần còn ngoài bao phủ và căn cứ cho các lựa chọn sau.

Nội dung kiểm toán IT giúp đội ngũ thiết kế các đơn vị theo mục tiêu kiểm toán. Mỗi đối tượng nên trả lời được ai sở hữu hoạt động, kết quả nào cần bảo vệ và loại kết luận nào có thể hình thành. Tên gọi chỉ hữu ích khi những điều này đã rõ.

Nối dịch vụ kinh doanh với nền tảng và kiểm soát dùng chung

Một dịch vụ có thể phụ thuộc ứng dụng, dữ liệu, danh tính, hạ tầng và nhà cung cấp. Các quan hệ đó cần được mô tả ở mức phục vụ kế hoạch. Nếu chỉ nhìn theo phòng ban, kiểm toán có thể xem từng phần nhưng bỏ sót điểm giao nhận khiến hoạt động bị gián đoạn hoặc kiểm soát không được thực hiện.

Ví dụ, quyền của ứng dụng được chủ nghiệp vụ phê duyệt nhưng thông tin nghỉ việc đến từ nhân sự và một phần tài khoản do đối tác quản trị. Cuộc kiểm toán riêng của IT cần biết các phụ thuộc này để xác định phạm vi và đầu mối. Ranh giới tổ chức không nên được dùng như lý do mặc định loại các điều kiện cần cho kết luận.

Những kiểm soát tập trung như danh tính, thay đổi hoặc sao lưu có thể phục vụ nhiều dịch vụ. Audit Universe cần cho thấy mối liên hệ để tránh lặp toàn bộ công việc tại từng ứng dụng. Tuy nhiên, cơ chế tập trung hiệu lực chưa tự chứng minh phần cấu hình hoặc quy trình riêng của từng dịch vụ đều phù hợp.

Một mô hình thực hành có thể dùng danh mục đơn vị cùng bản đồ quan hệ. Danh mục giữ chủ trách nhiệm và đặc điểm; bản đồ chỉ ra phụ thuộc hoặc kiểm soát chung. Không cần làm sơ đồ chi tiết của mọi kết nối nếu chúng không hỗ trợ lựa chọn phạm vi, nhưng các quan hệ có tác động quan trọng không nên bị bỏ qua.

Cách nhìn quản lý dịch vụ IT giúp hiểu luồng và các đầu mối. Kiểm toán có thể sử dụng danh mục dịch vụ hiện có rồi kiểm tra tính đầy đủ, thay vì tự xây một hệ thống tên khác khiến các bên khó đối chiếu thông tin và duy trì khi hoạt động thay đổi.

Giữ dữ liệu đủ cho ưu tiên và theo dõi bao phủ

Thông tin tối thiểu nên phục vụ những câu hỏi kế hoạch. Với mỗi đối tượng, cần mục tiêu hoạt động, chủ trách nhiệm, dữ liệu hoặc dịch vụ liên quan, mức thay đổi và những rủi ro chính. Kết quả kiểm toán hoặc đánh giá đã có cần ghi phạm vi và thời điểm, để biết phần nào còn phù hợp và phần nào chưa được xem.

Danh mục kỹ thuật là một nguồn nhưng cần được đối chiếu với nghiệp vụ, mua sắm và quan hệ cung cấp. Một SaaS mua bởi đơn vị khác có thể không nằm trong dữ liệu hạ tầng của IT. Nếu chỉ lấy một nguồn, Audit Universe có thể đầy đủ với tài sản nội bộ mà thiếu dịch vụ đang xử lý thông tin quan trọng.

Các thông tin chưa chắc cần được đánh dấu và có người xác minh. Một đối tượng ít dữ liệu không tự là ít rủi ro. Kiểm toán có thể cần công việc sơ bộ để hiểu điều kiện trước khi đánh giá độ ưu tiên. Cách này giữ quyết định khỏi bị ảnh hưởng bởi việc một lĩnh vực báo cáo tốt hơn lĩnh vực khác.

Bảng là đề xuất trường thông tin, không phải biểu mẫu chính thức bắt buộc. Tổ chức nên bắt đầu vừa đủ và bổ sung khi dữ liệu thực sự phục vụ quyết định. Thu nhiều trường mà không có người duy trì sẽ làm danh mục nhanh lỗi thời và giảm khả năng sử dụng.

Mỗi đối tượng cần có mã hoặc cách nhận diện ổn định, nhất là khi tên dịch vụ đổi. Lịch sử phạm vi và quan hệ phải đủ để đối chiếu kết quả các kỳ. Nếu đổi tên tạo một dòng mới nhưng không nối với đối tượng cũ, kế hoạch có thể hiểu sai về thời gian chưa được kiểm toán.

Thử cấu trúc bằng một hành trình có phụ thuộc

Trong tình huống giả định, doanh nghiệp vận hành dịch vụ đặt hàng qua ứng dụng nội bộ, cổng đối tác và kho dữ liệu. Audit Universe ban đầu có từng hệ thống nhưng không có dịch vụ đặt hàng hoặc mối liên hệ giữa chúng. Nhóm dự định kiểm toán theo lịch hạ tầng, trong khi các giao dịch đang phụ thuộc điểm giao nhận dữ liệu mới.

Khi đi theo một giao dịch mẫu, nhóm thấy thông tin được tạo tại cổng đối tác, chuyển qua tích hợp rồi phục vụ quyết định trong ứng dụng. Kiểm soát đối soát nằm ở nghiệp vụ, còn vận hành kết nối nằm tại IT. Nếu mỗi cuộc chỉ xem một hệ thống, điều kiện giúp phát hiện dữ liệu thiếu có thể không được kiểm tra đầy đủ.

Chức năng kiểm toán bổ sung góc nhìn dịch vụ và quan hệ, không xóa mọi đơn vị kỹ thuật. Một số kiểm soát chung được giữ để đánh giá tập trung; phần giao nhận dữ liệu được xác định như phạm vi cần xem theo hoạt động. Cấu trúc mới giúp giải thích công việc nào tạo kết luận về dịch vụ và công việc nào về nền tảng.

Sau thử, nhóm rà những dịch vụ khác có kiểu phụ thuộc tương tự. Không mặc nhiên kết luận chúng có cùng sai lệch, nhưng dùng dấu hiệu để kiểm tra độ đầy đủ của danh mục. Tình huống giả định cho thấy Audit Universe cần được thử bằng công việc thật, không chỉ xác nhận đủ số tài sản từ một nguồn dữ liệu.

Đánh giá ưu tiên mà không để mô hình điểm thay xét đoán

Sau khi có danh mục, nhóm dùng tiêu chí rủi ro và nhu cầu đảm bảo để so sánh. Tác động, thay đổi, kết quả trước và khoảng trống hiểu biết là các đầu vào có thể xem. Cần ghi nguồn cùng giả định để biết vì sao mức ưu tiên được chọn và điều gì có thể làm nó khác đi.

Các đối tượng không nhất thiết có cùng kích thước hay độ phức tạp. So điểm tổng mà không hiểu cấu trúc có thể làm một quy trình rộng luôn cao hơn một kiểm soát nhỏ nhưng có tác động rất lớn. Nhóm phải rà cách chấm và xét những trường hợp cần tách hoặc kết hợp phạm vi để tạo quyết định hợp lý.

The IIA hướng dẫn lập kế hoạch dựa trên rủi ro, còn tổ chức lựa chọn cách xây danh mục hỗ trợ. Audit Universe không nên trở thành bài tập điền điểm tự động rồi chốt lịch. Giá trị nằm ở khả năng nhìn các đối tượng trong mối liên hệ với mục tiêu và những phần cần được đảm bảo.

Nội dung quản lý rủi ro IT giúp làm rõ các kịch bản và tiêu chí. Kiểm toán dùng thông tin quản lý như đầu vào, đồng thời kiểm tra mức tin cậy và giữ xét đoán của mình. Một rủi ro chưa được ghi trong sổ hiện hành vẫn có thể xuất hiện khi hiểu thêm hoạt động.

Duy trì danh mục khi doanh nghiệp thay đổi

Mua dịch vụ mới, thay nhà cung cấp hoặc chuyển nền tảng đều có thể ảnh hưởng Audit Universe. Cần xác định ai nhận thông tin và điều kiện nào kích hoạt cập nhật. Danh mục chỉ được rà khi lập kế hoạch năm có thể không phản ánh một phụ thuộc quan trọng vừa xuất hiện giữa kỳ.

Chủ quản lý hoạt động xác nhận thông tin, còn chức năng kiểm toán chịu trách nhiệm cách cấu trúc và dùng cho kế hoạch. Không giao toàn bộ việc duy trì cho nhóm kỹ thuật nếu dữ liệu cần gồm mục tiêu và rủi ro nghiệp vụ. Mặt khác, kiểm toán cũng không nên tạo danh mục tách biệt hoàn toàn các nguồn tổ chức đang sử dụng.

Năng lực quản lý IT giúp cung cấp thông tin có bối cảnh và phối hợp chủ dịch vụ. Khi Audit Universe được duy trì theo hoạt động, chức năng kiểm toán có nền tảng để chọn đúng câu hỏi, nhìn phần chưa bao phủ và điều chỉnh kế hoạch trước những thay đổi có ý nghĩa.

Bài viết liên quan

• Xây dựng kế hoạch kiểm toán IT dựa trên rủi ro thay vì kiểm tra dàn trải.
• Thiết lập mục tiêu, phạm vi và tiêu chí cho một cuộc kiểm toán nội bộ IT.
• Kiểm toán IT General Controls: Quyền truy cập, thay đổi hệ thống và vận hành IT.
• Kiểm toán hoạt động sao lưu, khôi phục dữ liệu và khả năng duy trì kinh doanh liên tục.

Nguồn tham khảo

1. The IIA — Developing a Risk-Based Internal Audit Plan, 2nd Edition, 2025
2. The IIA — Global Internal Audit Standards, 2024
3. ISACA — IT Audit Resources