Kiểm toán công nghệ thông tin là gì? Phạm vi, quy trình và tiêu chí đánh giá

Kiểm toán công nghệ thông tin là hoạt động đánh giá độc lập, dựa trên bằng chứng về cách doanh nghiệp quản trị, vận hành và kiểm soát hệ thống thông tin. Mục tiêu là xác định dữ liệu có được bảo vệ, xử lý chính xác và sẵn sàng phục vụ hoạt động hay không, đồng thời xem xét mức độ tuân thủ và hiệu quả sử dụng nguồn lực công nghệ.

Phạm vi kiểm tra có thể bao gồm hạ tầng, phần mềm, cơ sở dữ liệu, quyền truy cập, quản lý thay đổi, sao lưu, khôi phục và dịch vụ thuê ngoài. Khác với kiểm thử xâm nhập tập trung vào khả năng khai thác điểm yếu, kiểm toán xem xét cả thiết kế kiểm soát và hiệu quả vận hành thực tế trong kỳ đánh giá.

Quy trình thường bắt đầu bằng xác định mục tiêu, phạm vi và rủi ro; tiếp đến là thu thập hồ sơ, phỏng vấn, kiểm tra dữ liệu và thử nghiệm kiểm soát. Các phát hiện được phân loại theo mức độ ảnh hưởng, lập báo cáo kiến nghị và theo dõi khắc phục. Tiêu chí đối chiếu cần phù hợp với chính sách, nghĩa vụ áp dụng và mục tiêu kinh doanh. Kết quả giúp doanh nghiệp ưu tiên xử lý thiếu sót; việc hoàn tất khắc phục cần được xác minh bằng bằng chứng thực tế.

Kiểm toán công nghệ thông tin là gì và khác kiểm toán tài chính thế nào?

Kiểm toán công nghệ thông tin (CNTT) đánh giá độc lập, dựa trên bằng chứng, việc quản trị hệ thống thông tin và kiểm soát rủi ro. Phạm vi gồm quyền truy cập, thay đổi phần mềm, sao lưu, dữ liệu và nhà cung cấp. Hoạt động này xem xét cả thiết kế lẫn hiệu quả vận hành của kiểm soát trong kỳ. Khác với đánh giá bảo mật và kiểm thử xâm nhập, vốn tập trung vào điểm yếu hoặc khả năng khai thác, kiểm toán CNTT đối chiếu kiểm soát với tiêu chí xác định. Kiểm toán tài chính nhằm đưa ra ý kiến về báo cáo tài chính. Hai lĩnh vực giao nhau khi hệ thống xử lý dữ liệu kế toán, nhưng kết quả kiểm toán CNTT không thay thế ý kiến đó.

Khái niệm kiểm toán công nghệ thông tin và đối tượng được kiểm tra

Kiểm toán công nghệ thông tin (CNTT) là hoạt động đánh giá có hệ thống, độc lập và dựa trên bằng chứng đối với cách tổ chức quản trị, vận hành và kiểm soát hệ thống thông tin. Kiểm toán viên xác định tiêu chí đánh giá, thu thập bằng chứng, so sánh với thực tế và đưa ra nhận định về mức độ kiểm soát rủi ro. Tiêu chí có thể xuất phát từ chính sách nội bộ, yêu cầu pháp lý, hợp đồng hoặc một khuôn khổ kiểm soát được tổ chức lựa chọn. Không có một danh mục kiểm tra áp dụng giống nhau cho mọi cuộc kiểm toán: phạm vi phải gắn với mục tiêu, hệ thống và rủi ro cụ thể.

Đối tượng được kiểm tra không chỉ là máy chủ hay phần mềm. Một cuộc kiểm toán có thể xem xét quy trình phê duyệt quyền truy cập, việc phân tách nhiệm vụ, lịch sử thay đổi chương trình, cấu hình cơ sở dữ liệu, cơ chế sao lưu và khôi phục, nhật ký hoạt động hoặc cách nhà cung cấp dịch vụ xử lý dữ liệu. Với hệ thống thuê ngoài hay điện toán đám mây, kiểm toán viên cần làm rõ trách nhiệm kiểm soát thuộc về tổ chức hay nhà cung cấp; không thể mặc nhiên coi việc thuê dịch vụ là đã chuyển giao toàn bộ rủi ro.

Trọng tâm chuyên môn là phân biệt thiết kế kiểm soát với hiệu quả vận hành. Quy trình yêu cầu phê duyệt trước khi cấp quyền có thể được thiết kế hợp lý, nhưng vẫn không hiệu quả nếu quyền thường xuyên được cấp trước rồi mới phê duyệt bổ sung. Để kiểm tra, kiểm toán viên xác định tổng thể giao dịch trong kỳ, chọn mẫu phù hợp và đối chiếu yêu cầu, thời điểm phê duyệt, cấu hình quyền cùng nhật ký hệ thống. Bằng chứng cần đủ tin cậy: một ảnh chụp màn hình tại thời điểm kiểm tra thường không chứng minh được kiểm soát đã vận hành nhất quán suốt nhiều tháng.

• Kiểm soát chung về CNTT: quản lý tài khoản, quyền đặc quyền, thay đổi hệ thống, vận hành và sao lưu.
• Kiểm soát ứng dụng: kiểm tra dữ liệu đầu vào, quy tắc tính toán, phê duyệt giao dịch và đối chiếu dữ liệu đầu ra.
• Dữ liệu và tích hợp: tính đầy đủ, chính xác của luồng dữ liệu giữa các ứng dụng và khả năng truy vết thay đổi.
• Con người và bên thứ ba: trách nhiệm thực hiện kiểm soát, giám sát nhà cung cấp và xử lý ngoại lệ.

Phân biệt kiểm toán công nghệ thông tin, đánh giá bảo mật và kiểm thử xâm nhập

Ba hoạt động này có thể sử dụng chung một số thông tin nhưng trả lời những câu hỏi khác nhau. Kiểm toán CNTT đối chiếu kiểm soát với tiêu chí xác định trước, thường đánh giá cả thiết kế lẫn việc vận hành trong một giai đoạn. Đánh giá bảo mật tập trung vào mức độ bảo vệ và các điểm yếu về kỹ thuật, cấu hình hoặc quy trình; phạm vi có thể rộng hoặc hẹp tùy mục tiêu. Kiểm thử xâm nhập mô phỏng hành vi tấn công trong phạm vi và thời gian được cho phép để xác minh khả năng khai thác, thay vì chỉ liệt kê lỗ hổng có thể tồn tại.

Ví dụ, kiểm thử xâm nhập có thể chứng minh một tài khoản bị chiếm quyền thông qua lỗi cấu hình. Kiểm toán sẽ xem xét thêm vì sao cấu hình đó được triển khai, ai phê duyệt thay đổi, hoạt động rà soát định kỳ có phát hiện được lỗi hay không và các trường hợp tương tự có tồn tại trong kỳ. Ngược lại, một đợt kiểm thử không khai thác được lỗ hổng không chứng minh rằng phân quyền, sao lưu hay quản lý thay đổi đang hoạt động hiệu quả: kết quả thử nghiệm còn phụ thuộc phạm vi, kỹ thuật và thời điểm thực hiện.

• Kết quả đánh giá bảo mật hoặc kiểm thử xâm nhập có thể là đầu vào để kiểm toán viên xác định rủi ro và chọn mẫu.
• Phát hiện kiểm toán cần nêu rõ tiêu chí, thực trạng, nguyên nhân, tác động và kiến nghị có thể thực hiện.
• Mức độ nghiêm trọng phải xét cả khả năng xảy ra lẫn hậu quả đối với hệ thống và mục tiêu của tổ chức.

Mối liên hệ giữa kiểm toán công nghệ thông tin và độ tin cậy của báo cáo tài chính

Kiểm toán tài chính hướng đến việc đưa ra ý kiến về báo cáo tài chính theo khuôn khổ lập báo cáo áp dụng. Kiểm toán CNTT xem xét các hệ thống và kiểm soát trong phạm vi được giao; bản thân kết quả kiểm toán CNTT không thay thế ý kiến về báo cáo tài chính. Hai hoạt động giao nhau khi ứng dụng tạo, xử lý, chuyển hoặc lưu dữ liệu kế toán. Khi đó, sai sót trong quyền truy cập, chương trình hay giao diện truyền dữ liệu có thể ảnh hưởng đến tính đầy đủ, chính xác và đúng kỳ của số liệu.

Chẳng hạn, doanh thu từ hệ thống bán hàng được chuyển tự động sang sổ cái. Nếu quy tắc ghi nhận bị sửa mà không được phê duyệt, số tiền hoặc kỳ ghi nhận có thể sai dù nhân viên không nhập sai chứng từ. Kiểm toán viên cần tìm hiểu ai được sửa quy tắc, thay đổi được kiểm thử và phê duyệt ra sao, hệ thống ghi nhận nhật ký thế nào, và tổng giao dịch giữa hai hệ thống có được đối chiếu. Việc đối chiếu chỉ có giá trị khi người thực hiện điều tra và xử lý các chênh lệch đáng kể.

Trong trường hợp dự kiến dựa vào kiểm soát tự động, kiểm toán viên tài chính thường phải xem xét các kiểm soát chung về CNTT liên quan, đặc biệt là quyền truy cập và quản lý thay đổi. Một phép tính tự động có thể được thiết kế đúng, nhưng khó dựa vào kết quả của nó trong cả kỳ nếu người dùng có thể tự ý sửa công thức hoặc can thiệp dữ liệu mà không để lại dấu vết đáng tin cậy. Ngược lại, khi kiểm soát không đủ tin cậy, kiểm toán viên có thể cần điều chỉnh cách thức, thời điểm hoặc phạm vi thủ tục kiểm tra trực tiếp số liệu.

• Quyền truy cập: rà soát tài khoản đặc quyền, tài khoản đã nghỉ việc và quyền vừa tạo vừa phê duyệt giao dịch.
• Thay đổi chương trình: đối chiếu yêu cầu thay đổi với bằng chứng kiểm thử, phê duyệt và triển khai thực tế.
• Báo cáo hệ thống: kiểm tra tham số lọc, tính đầy đủ và độ chính xác trước khi sử dụng làm bằng chứng kiểm toán.

Kiểm toán viên tài chính có thể sử dụng công việc của chuyên gia CNTT để hiểu hệ thống và kiểm tra những kiểm soát chuyên sâu. Tuy nhiên, họ vẫn cần đánh giá năng lực, tính khách quan, phạm vi và mức độ phù hợp của công việc với mục tiêu kiểm toán tài chính. Một báo cáo CNTT ghi nhận hệ thống “an toàn” theo phạm vi bảo mật riêng chưa đủ để khẳng định dữ liệu doanh thu là đầy đủ, hoặc các kiểm soát liên quan đến số liệu đã vận hành hiệu quả trong toàn bộ kỳ được kiểm toán.

Kiểm toán công nghệ thông tin đánh giá những mục tiêu nào?

Kiểm toán công nghệ thông tin đánh giá ba nhóm mục tiêu: bảo vệ thông tin, kiểm soát nội bộ và hiệu quả sử dụng công nghệ. Trước hết, kiểm toán viên xem xét dữ liệu có được bảo mật, duy trì tính chính xác và sẵn sàng khi cần, kể cả sau sự cố. Tiếp đó, họ xác định các kiểm soát có được thiết kế phù hợp, vận hành nhất quán và đáp ứng nghĩa vụ pháp lý, hợp đồng, chính sách áp dụng. Cuối cùng, chi phí, năng lực hệ thống, chất lượng dịch vụ và hiệu quả đầu tư được đối chiếu với nhu cầu kinh doanh. Kết luận dựa trên bằng chứng giúp doanh nghiệp ưu tiên khắc phục rủi ro, cải thiện hoạt động và sử dụng nguồn lực hợp lý.

Đánh giá tính bảo mật, toàn vẹn và sẵn sàng của thông tin

Ba mục tiêu cốt lõi của kiểm toán công nghệ thông tin là bảo mật, toàn vẹn và sẵn sàng. Kiểm toán viên đánh giá từng mục tiêu theo từng hệ thống, loại dữ liệu và quy trình nghiệp vụ, thay vì áp dụng cùng một mức kiểm soát cho mọi tài sản. Điểm khởi đầu thường là xác định dữ liệu nào có tính nhạy cảm, hệ thống nào hỗ trợ hoạt động thiết yếu và hậu quả nếu thông tin bị lộ, sai lệch hoặc không thể truy cập. Từ đó, kiểm toán viên đối chiếu các biện pháp hiện có với mức rủi ro doanh nghiệp chấp nhận.

• Bảo mật: Xem xét cách phân loại dữ liệu, cấp và thu hồi quyền truy cập, quản lý tài khoản đặc quyền, xác thực đa yếu tố, mã hóa và quản lý khóa. Việc bật xác thực đa yếu tố không đủ để kết luận kiểm soát hữu hiệu nếu tài khoản quản trị, tài khoản truy cập từ xa hoặc một nhóm người dùng quan trọng vẫn được miễn áp dụng. Kiểm toán viên cũng xem xét nhật ký truy cập có được giám sát để phát hiện hành vi bất thường hay không.
• Toàn vẹn: Kiểm tra khả năng ngăn ngừa và phát hiện dữ liệu bị sửa trái phép hoặc sai lệch trong quá trình nhập, xử lý và truyền giữa các hệ thống. Bằng chứng có thể gồm quy tắc kiểm tra dữ liệu đầu vào, đối soát số liệu, phân tách nhiệm vụ, lịch sử thay đổi và cơ chế phê duyệt trước khi cập nhật dữ liệu trọng yếu. Với hệ thống tích hợp, cần kiểm tra cả các giao dịch lỗi, giao dịch bị xử lý lặp và cách xử lý ngoại lệ.
• Sẵn sàng: Đánh giá giám sát hệ thống, sao lưu, dự phòng, ứng phó sự cố và khả năng khôi phục sau gián đoạn. Kiểm toán viên không chỉ xác nhận bản sao lưu tồn tại mà còn xem kết quả khôi phục thử, phạm vi dữ liệu được phục hồi và thời gian thực tế để đưa dịch vụ trở lại hoạt động.

Đối với dịch vụ thiết yếu, các mục tiêu RTO (thời gian khôi phục mục tiêu) và RPO (mức mất dữ liệu tối đa có thể chấp nhận, tính theo thời gian) cần xuất phát từ phân tích tác động kinh doanh. Nếu doanh nghiệp đặt RPO là một giờ nhưng chỉ sao lưu mỗi ngày, thiết kế hiện tại khó đáp ứng mục tiêu đó. Kiểm toán viên cần đối chiếu mục tiêu đã phê duyệt với cấu hình, kết quả diễn tập và các phụ thuộc thực tế như đường truyền, nhà cung cấp dịch vụ hoặc nhân sự vận hành.

Xác định hiệu lực kiểm soát nội bộ và mức độ tuân thủ

Một kiểm soát được mô tả đầy đủ trong quy trình vẫn có thể không xử lý được rủi ro, hoặc không được thực hiện nhất quán. Vì vậy, kiểm toán phân biệt hiệu lực thiết kế với hiệu lực vận hành. Hiệu lực thiết kế trả lời câu hỏi: nếu thực hiện đúng, kiểm soát có ngăn ngừa hoặc phát hiện rủi ro đủ kịp thời không? Hiệu lực vận hành trả lời câu hỏi: trong giai đoạn được kiểm toán, kiểm soát có thực sự được thực hiện bởi người phù hợp, đúng tần suất và có bằng chứng đáng tin cậy không?

Chẳng hạn, quy trình yêu cầu phê duyệt trước khi cấp quyền truy cập. Kiểm toán viên sẽ kiểm tra người phê duyệt có thẩm quyền hay không, quyền được cấp có phù hợp công việc không, và tài khoản của nhân viên nghỉ việc có được thu hồi kịp thời không. Với quyền cấp khẩn cấp, cần xem thời hạn hiệu lực, việc ghi nhận lý do và bước rà soát sau cấp quyền. Nếu các trường hợp khẩn cấp thường xuyên bỏ qua phê duyệt, đó không còn là ngoại lệ đơn lẻ mà có thể là dấu hiệu quy trình chưa phù hợp thực tế vận hành.

Phạm vi đánh giá còn bao gồm những kiểm soát công nghệ thông tin chung tác động đến nhiều ứng dụng: quản lý thay đổi, vận hành hệ thống, quản lý truy cập và xử lý sự cố. Ví dụ, khi kiểm tra thay đổi phần mềm, kiểm toán viên đối chiếu yêu cầu thay đổi với kết quả kiểm thử, phê duyệt triển khai và nhật ký đưa phiên bản lên môi trường sản xuất. Một thay đổi đã được phê duyệt nhưng không được kiểm thử phù hợp vẫn có thể gây lỗi xử lý dữ liệu hoặc gián đoạn dịch vụ.

Để kết luận về hiệu lực vận hành, kiểm toán viên cần xác định đầy đủ tổng thể giao dịch hoặc sự kiện trong kỳ, chọn mẫu phù hợp với mục tiêu kiểm tra và truy vết từng mẫu đến bằng chứng gốc. Phỏng vấn người phụ trách giúp hiểu quy trình, nhưng không thay thế được nhật ký hệ thống, phiếu yêu cầu, biên bản rà soát hoặc kết quả thực hiện. Khi phát hiện sai lệch, cần làm rõ nguyên nhân, phạm vi ảnh hưởng, thời gian tồn tại và có hay không kiểm soát khác giúp giảm rủi ro.

Đánh giá tuân thủ phải dựa trên nghĩa vụ thực sự áp dụng: quy định pháp luật, yêu cầu của cơ quan quản lý, hợp đồng với khách hàng, chính sách nội bộ và các cam kết doanh nghiệp đã đưa ra. Một tiêu chuẩn tự nguyện không mặc nhiên là yêu cầu pháp lý; ngược lại, doanh nghiệp có thể phải đáp ứng một điều khoản cụ thể của tiêu chuẩn nếu đã cam kết trong hợp đồng. Báo cáo kiểm toán nên nêu rõ tiêu chí đối chiếu, bằng chứng, sai lệch và rủi ro tương ứng để đơn vị được kiểm toán có cơ sở khắc phục.

Đánh giá hiệu quả sử dụng nguồn lực và khả năng hỗ trợ hoạt động kinh doanh

Kiểm toán công nghệ thông tin không chỉ tập trung vào điểm yếu bảo mật hoặc vi phạm quy trình. Kiểm toán hoạt động còn đánh giá liệu chi phí, nhân lực và năng lực kỹ thuật có được sử dụng hợp lý để đáp ứng nhu cầu kinh doanh hay không. Một hệ thống vận hành ổn định nhưng có chi phí tăng nhanh, sử dụng năng lực thấp hoặc phụ thuộc quá lớn vào thao tác thủ công vẫn có thể cần cải thiện. Ngược lại, chi phí thấp không đồng nghĩa với hiệu quả nếu thời gian gián đoạn và rủi ro phục hồi tăng lên.

• Chi phí và tài sản công nghệ: Đối chiếu giấy phép đã mua với mức sử dụng thực tế, xác định phần mềm trùng chức năng, tài nguyên đám mây không còn cần thiết và chi phí duy trì hệ thống cũ. Việc đánh giá cần tính cả chi phí chuyển đổi, đào tạo và rủi ro vận hành, không chỉ so sánh giá mua.
• Năng lực và chất lượng dịch vụ: Xem xét xu hướng sử dụng tài nguyên vào giờ cao điểm, tốc độ phản hồi, tỷ lệ đáp ứng cam kết dịch vụ và thời gian khắc phục sự cố. Các số liệu cần gắn với trải nghiệm của người dùng và mức độ quan trọng của từng dịch vụ; giá trị trung bình tốt có thể che khuất các đợt suy giảm nghiêm trọng vào thời điểm cao điểm.
• Danh mục đầu tư công nghệ: Xem xét dự án có mục tiêu kinh doanh rõ ràng, người chịu trách nhiệm, lợi ích dự kiến và tiêu chí nghiệm thu hay không. Kiểm toán viên cũng đánh giá việc theo dõi lợi ích sau triển khai, thay vì chỉ xác nhận dự án hoàn thành đúng ngân sách.

Chỉ số đánh giá phải được đặt trong bối cảnh cụ thể. Chẳng hạn, thời gian khắc phục sự cố trung bình có thể giảm, nhưng điều đó chưa chứng minh dịch vụ tốt hơn nếu số sự cố nghiêm trọng tăng hoặc các sự cố tồn đọng không được xử lý. Tương tự, cắt giảm máy chủ dự phòng có thể giúp giảm chi phí trước mắt nhưng làm giảm khả năng đáp ứng mục tiêu khôi phục. Kiểm toán viên cần xem xét đồng thời chi phí, chất lượng dịch vụ và rủi ro, rồi làm rõ sự đánh đổi để ban quản lý quyết định trên cơ sở đầy đủ.

Các loại kiểm toán công nghệ thông tin trong doanh nghiệp

Kiểm toán công nghệ thông tin trong doanh nghiệp được phân loại theo mục đích sử dụng kết quả, nghĩa vụ cần đáp ứng và rủi ro cần đánh giá. Kiểm toán nội bộ hỗ trợ quản trị rủi ro, còn kiểm toán độc lập cung cấp kết quả cho các bên liên quan trong phạm vi xác định. Kiểm toán tuân thủ đối chiếu quy định, hợp đồng và chính sách với kiểm soát thực tế. Kiểm toán hoạt động xem xét hiệu quả sử dụng nguồn lực; kiểm toán chuyên đề đi sâu vào hệ thống hoặc rủi ro trọng yếu. Mọi loại hình đều cần bằng chứng có thể truy xuất, kết luận đúng phạm vi và kiến nghị khắc phục khả thi.

Kiểm toán nội bộ và kiểm toán độc lập theo mục đích sử dụng kết quả

Kiểm toán nội bộ hỗ trợ hội đồng quản trị, ủy ban kiểm toán và ban điều hành đánh giá cách doanh nghiệp quản trị rủi ro công nghệ. Phạm vi thường được xác định từ kế hoạch kiểm toán dựa trên rủi ro: hệ thống nào quan trọng đối với doanh thu, dữ liệu nào nhạy cảm, thay đổi nào có thể làm gián đoạn hoạt động. Kiểm toán viên nội bộ có thể xem xét cả thiết kế kiểm soát lẫn việc kiểm soát có thực sự vận hành trong một giai đoạn hay không. Chẳng hạn, quy định yêu cầu phê duyệt quyền quản trị là thiết kế kiểm soát; hồ sơ cấp quyền và nhật ký phê duyệt mới cho thấy kiểm soát đã được thực hiện.

Kiểm toán độc lập do tổ chức hoặc cá nhân bên ngoài thực hiện theo một nhiệm vụ xác định. Người sử dụng kết quả có thể là khách hàng doanh nghiệp, nhà đầu tư, cơ quan quản lý hoặc kiểm toán viên báo cáo tài chính. Vì vậy, trước khi bắt đầu cần làm rõ đối tượng được kiểm toán, tiêu chí đánh giá, kỳ đánh giá và hình thức báo cáo. Trong kiểm toán báo cáo tài chính, việc xem xét kiểm soát công nghệ thường tập trung vào các hệ thống ảnh hưởng đến số liệu kế toán, như quản lý quyền truy cập, thay đổi chương trình và vận hành xử lý dữ liệu; đây không mặc nhiên là đánh giá toàn diện an ninh mạng của doanh nghiệp.

Hai hình thức khác nhau về bên sử dụng báo cáo và yêu cầu độc lập, nhưng đều phải dựa trên bằng chứng đầy đủ, thích hợp và có thể truy xuất. Một bản chụp cấu hình tại ngày kiểm tra có thể chứng minh trạng thái hiện tại, song chưa đủ để khẳng định kiểm soát đã hoạt động liên tục suốt năm. Kiểm toán viên cần đối chiếu cấu hình với nhật ký, phiếu yêu cầu, phê duyệt và các ngoại lệ trong kỳ. Khi chọn mẫu, phải xác định tổng thể, thời gian lấy mẫu và cách xử lý trường hợp thiếu hồ sơ; không nên chỉ chọn các giao dịch do đơn vị được kiểm toán đề xuất.

• Với kiểm toán nội bộ: bộ phận kiểm toán cần có vị trí báo cáo phù hợp và tránh tự kiểm toán hoạt động mà mình trực tiếp thiết kế hoặc vận hành.
• Với kiểm toán độc lập: phạm vi và mức độ bảo đảm phải được nêu rõ; ý kiến về một hệ thống không tự động áp dụng cho mọi hệ thống khác.
• Với tự đánh giá: nhóm công nghệ có thể dùng bảng kiểm và kiểm tra trước để khắc phục sai sót, nhưng tự đánh giá không thay thế sự bảo đảm độc lập khi hợp đồng hoặc quy định yêu cầu.

Kiểm toán tuân thủ theo quy định, hợp đồng và chính sách tổ chức

Kiểm toán tuân thủ trả lời câu hỏi doanh nghiệp có đáp ứng những nghĩa vụ thực sự áp dụng hay không. Nguồn yêu cầu có thể là quy định pháp luật, điều kiện cấp phép, hợp đồng với khách hàng, cam kết với nhà cung cấp hoặc chính sách nội bộ đã phê duyệt. Kiểm toán viên không nên dùng một danh sách kiểm tra chung cho mọi đơn vị: cùng là dữ liệu cá nhân, nhưng trách nhiệm của doanh nghiệp có thể khác nhau theo vai trò xử lý dữ liệu, loại dữ liệu và phạm vi dịch vụ cam kết.

Bước đầu là lập ma trận nghĩa vụ – kiểm soát – bằng chứng. Với mỗi yêu cầu, ma trận cần ghi rõ văn bản hoặc điều khoản nguồn, phiên bản, ngày có hiệu lực, đơn vị chịu trách nhiệm, hệ thống liên quan, kiểm soát đáp ứng và hồ sơ cần thu thập. Cách làm này giúp tránh hai sai lệch phổ biến: kiểm tra theo một yêu cầu đã hết hiệu lực hoặc kết luận không tuân thủ đối với hệ thống nằm ngoài phạm vi áp dụng. Nếu nhiều nguồn yêu cầu khác nhau về thời hạn hoặc cách thực hiện, doanh nghiệp phải xác định nghĩa vụ áp dụng cho từng dịch vụ thay vì giả định một chính sách chung luôn đáp ứng tất cả.

Việc kiểm tra phải đi từ câu chữ của yêu cầu đến thực tế vận hành. Ví dụ, hợp đồng yêu cầu thông báo sự cố bảo mật trong một thời hạn nhất định thì không đủ để xác nhận doanh nghiệp có quy trình ứng phó. Cần kiểm tra thời điểm phát hiện, phân loại, chuyển cấp, phê duyệt và gửi thông báo qua hồ sơ sự cố thực tế; nếu chưa có sự cố, có thể xem hồ sơ diễn tập nhưng phải nêu rõ giới hạn của bằng chứng. Tương tự, cam kết xóa dữ liệu sau khi chấm dứt hợp đồng cần được đối chiếu với dữ liệu trên hệ thống chính, bản sao lưu và bên xử lý thuê ngoài.

• Đối với quyền truy cập: đối chiếu danh sách nhân sự nghỉ việc với thời điểm khóa tài khoản, kể cả tài khoản đặc quyền và quyền trên dịch vụ đám mây.
• Đối với lưu giữ dữ liệu: kiểm tra thời hạn áp dụng, cấu hình xóa và cơ chế xử lý trường hợp phải tạm giữ dữ liệu theo nghĩa vụ khác.
• Đối với nhà cung cấp: xác minh điều khoản bảo mật, quyền kiểm tra, trách nhiệm thông báo sự cố và bằng chứng giám sát trong suốt thời gian sử dụng dịch vụ.

Kiểm toán hoạt động và kiểm toán chuyên đề theo hệ thống hoặc rủi ro

Kiểm toán hoạt động đánh giá công nghệ có sử dụng nguồn lực hợp lý, vận hành hiệu quả và đáp ứng mục tiêu kinh doanh hay không. Việc mua thêm hạ tầng để xử lý hệ thống chậm có thể kém kinh tế nếu nguyên nhân thực tế là truy vấn chưa tối ưu. Vì vậy, kiểm toán viên cần liên hệ chi phí với nhu cầu sử dụng, công suất, mức dịch vụ và tác động đến người dùng. Các chỉ số như thời gian khôi phục dịch vụ, tỷ lệ thay đổi gây sự cố hoặc thời gian xử lý yêu cầu hỗ trợ chỉ có ý nghĩa khi cách đo nhất quán và dữ liệu nguồn đáng tin cậy.

Kiểm toán chuyên đề tập trung vào một hệ thống hoặc một nhóm rủi ro có tác động lớn, chẳng hạn nền tảng thanh toán, quản lý định danh, an toàn đám mây, khôi phục sau thảm họa hoặc triển khai phần mềm mới. Phạm vi nên được thu hẹp đủ để kiểm tra sâu luồng dữ liệu, điểm tích hợp, quyền quản trị và các kiểm soát phụ thuộc lẫn nhau. Cách tiếp cận này đặc biệt hữu ích sau sự cố nghiêm trọng, thay đổi kiến trúc, sáp nhập hệ thống hoặc khi đối tác nêu yêu cầu bảo đảm cụ thể.

Chẳng hạn, với chuyên đề khôi phục sau thảm họa, kiểm toán viên không chỉ xác nhận rằng doanh nghiệp có bản sao lưu. Cần kiểm tra hệ thống quan trọng đã được xác định đầy đủ chưa, mục tiêu thời gian khôi phục (RTO) và điểm khôi phục dữ liệu (RPO) có phù hợp nhu cầu kinh doanh không, bản sao lưu có được bảo vệ khỏi sửa xóa trái phép không và kết quả thử nghiệm khôi phục có đạt mục tiêu không. Một cuộc diễn tập chỉ khôi phục máy chủ nhưng không kiểm tra kết nối ứng dụng hoặc tính toàn vẹn dữ liệu chưa chứng minh được dịch vụ có thể hoạt động trở lại.

• Xác định nguyên nhân gốc: nhiều tài khoản không được thu hồi đúng hạn có thể bắt nguồn từ việc hệ thống nhân sự không gửi sự kiện nghỉ việc kịp thời, thay vì các lỗi xử lý riêng lẻ.
• Lượng hóa tác động: nêu hệ thống, dữ liệu, thời gian gián đoạn hoặc nhóm người dùng có thể bị ảnh hưởng; phân biệt rủi ro tiềm ẩn với thiệt hại đã xảy ra.
• Kiến nghị có thể thực hiện: chỉ rõ chủ sở hữu, biện pháp khắc phục, thời hạn và cách kiểm tra lại hiệu lực; tránh đề xuất chung chung như “tăng cường bảo mật”.

Phạm vi kiểm toán công nghệ thông tin gồm những thành phần nào?

Phạm vi kiểm toán công nghệ thông tin được xác định theo mục tiêu kiểm toán, rủi ro trọng yếu và ranh giới hệ thống, thay vì chỉ dựa vào danh sách thiết bị hoặc phần mềm. Trước khi thực hiện, kiểm toán viên cần xác định đơn vị được kiểm toán, kỳ đánh giá, quy trình nghiệp vụ liên quan, địa điểm xử lý dữ liệu và các bên thứ ba tham gia. Phạm vi cũng cần nêu rõ hệ thống nào được kiểm tra trực tiếp, hệ thống nào chỉ được xem xét thông qua báo cáo của nhà cung cấp và những giới hạn tiếp cận có thể ảnh hưởng đến kết luận.

Kiểm toán quản trị công nghệ, hạ tầng, mạng và dịch vụ đám mây

Ở cấp quản trị, kiểm toán viên đánh giá việc phân công trách nhiệm phê duyệt, vận hành và giám sát; cách ghi nhận rủi ro công nghệ; mức độ phù hợp của ngân sách với nhu cầu bảo mật, duy trì dịch vụ; và quy trình báo cáo cho lãnh đạo. Bằng chứng có thể gồm chiến lược công nghệ, chính sách, biên bản họp, danh mục rủi ro, chỉ số mức dịch vụ và hồ sơ theo dõi biện pháp khắc phục. Điểm cần kiểm tra không chỉ là tài liệu có tồn tại, mà còn là quyết định có được thực thi, theo dõi và điều chỉnh khi điều kiện thay đổi hay không.

Ở cấp kỹ thuật, phạm vi thường bắt đầu từ danh mục tài sản đầy đủ và còn hiệu lực, sau đó đi vào cấu hình máy chủ, thiết bị đầu cuối, thiết bị mạng, hệ thống định danh và công cụ giám sát. Kiểm toán viên có thể chọn mẫu tài khoản đặc quyền, bản vá quá hạn, cấu hình tường lửa hoặc cảnh báo bảo mật để đối chiếu giữa chính sách và thực tế. Việc đánh giá cần xem xét cả khả năng phát hiện, xử lý và xác nhận đã khắc phục điểm yếu, thay vì chỉ kiểm tra sự hiện diện của phần mềm bảo mật.

• Mạng và truy cập: kiểm tra phân đoạn mạng, quy tắc kết nối, xác thực đa yếu tố, quyền truy cập từ xa và quy trình thu hồi quyền khi nhân sự chuyển vị trí hoặc nghỉ việc.
• Vận hành liên tục: đối chiếu lịch sao lưu với kết quả sao lưu thực tế; kiểm tra việc thử khôi phục và mức đáp ứng mục tiêu thời gian, điểm khôi phục đã xác định.
• Đám mây: xác định tài khoản, dịch vụ và vùng triển khai thuộc phạm vi; kiểm tra quyền quản trị, cấu hình lưu trữ, mã hóa, nhật ký và cảnh báo chi phí bất thường.

Với dịch vụ đám mây, mô hình trách nhiệm chia sẻ phải được cụ thể hóa theo từng dịch vụ. Nhà cung cấp có thể chịu trách nhiệm bảo vệ hạ tầng vật lý, nhưng doanh nghiệp vẫn phải quản lý tài khoản, dữ liệu và nhiều cấu hình bảo mật. Chứng nhận hoặc báo cáo kiểm soát của nhà cung cấp không thay thế việc kiểm tra các kiểm soát thuộc trách nhiệm doanh nghiệp.

Kiểm toán ứng dụng, cơ sở dữ liệu và luồng xử lý thông tin

Kiểm toán ứng dụng nên xuất phát từ giao dịch và quy tắc nghiệp vụ trọng yếu: ai được tạo, sửa, phê duyệt hoặc hủy giao dịch; điều kiện nào khiến giao dịch bị từ chối; và dữ liệu được chuyển tiếp đến đâu. Kiểm toán viên đối chiếu tài liệu thiết kế, cấu hình hiện hành và mẫu giao dịch thực tế để đánh giá tính đầy đủ, chính xác, hợp lệ của quá trình xử lý. Những kiểm soát quan trọng gồm kiểm tra dữ liệu đầu vào, giới hạn phê duyệt, ngăn giao dịch trùng, đối soát kết quả và xử lý ngoại lệ.

Đối với cơ sở dữ liệu, cần phân biệt quyền của người dùng nghiệp vụ, tài khoản dịch vụ và tài khoản quản trị. Kiểm toán viên xem xét việc cấp quyền theo nhu cầu công việc, rà soát quyền định kỳ, quản lý mật khẩu hoặc khóa bí mật, mã hóa dữ liệu nhạy cảm và ghi nhật ký hoạt động có rủi ro cao. Nhật ký chỉ hữu ích khi được lưu giữ đủ lâu, bảo vệ khỏi sửa đổi trái phép và có người theo dõi các dấu hiệu bất thường.

• Đầu vào: chọn mẫu giao dịch hợp lệ và giao dịch bị từ chối để xác định quy tắc kiểm tra có hoạt động đúng thiết kế.
• Xử lý và giao diện: đối chiếu số bản ghi, tổng giá trị và thời điểm truyền giữa hệ thống nguồn, hàng đợi hoặc tệp trung gian và hệ thống đích.
• Đầu ra và ngoại lệ: kiểm tra báo cáo đối soát, danh sách bản ghi lỗi, trách nhiệm xử lý và bằng chứng xác nhận sau khi truyền lại.

Với các luồng xử lý nhiều bước, kiểm toán viên cần theo dấu một mẫu giao dịch từ lúc phát sinh đến khi được ghi nhận cuối cùng. Cách tiếp cận này giúp phát hiện dữ liệu bị bỏ sót, nhân đôi hoặc thay đổi ngoài quy trình. Mục tiêu là xác định tính đáng tin cậy của dữ liệu xuyên suốt vòng đời xử lý, không chỉ tại một hệ thống riêng lẻ.

Kiểm toán phát triển hệ thống, quản lý thay đổi và nhà cung cấp công nghệ

Phạm vi phát triển hệ thống bao gồm việc xác định yêu cầu nghiệp vụ, đánh giá tác động bảo mật, thiết kế, kiểm thử, phê duyệt triển khai và nghiệm thu. Kiểm toán viên đối chiếu một mẫu thay đổi từ yêu cầu ban đầu đến phiên bản đã đưa vào sử dụng, nhằm xác định khả năng truy vết giữa yêu cầu, mã nguồn, kết quả kiểm thử và quyết định phê duyệt. Cần xem xét việc phân tách môi trường phát triển, kiểm thử và sản xuất; hạn chế quyền chỉnh sửa mã; cũng như cơ chế bảo vệ thông tin nhạy cảm trong dữ liệu kiểm thử.

Đối với thay đổi thông thường, kiểm tra cần làm rõ đánh giá rủi ro, kế hoạch triển khai, phương án quay lui và bằng chứng kiểm thử trước khi phát hành. Thay đổi khẩn cấp có thể được triển khai theo quy trình rút gọn, nhưng vẫn cần ghi nhận người cho phép, lý do khẩn cấp, phạm vi tác động và rà soát sau triển khai. Việc chỉ có phiếu thay đổi không đủ để chứng minh kiểm soát vận hành hiệu quả nếu nội dung phê duyệt thiếu cụ thể hoặc được bổ sung sau mà không có giải trình.

• Quản lý mã nguồn: xem xét quyền hợp nhất mã, cơ chế rà soát độc lập, lịch sử thay đổi và việc xử lý các phát hiện bảo mật trước khi phát hành.
• Nhà cung cấp: kiểm tra thẩm định ban đầu, nghĩa vụ bảo mật trong hợp đồng, cam kết mức dịch vụ, thời hạn thông báo sự cố và cách giám sát kết quả thực hiện.
• Chấm dứt hợp tác: đánh giá phương án xuất dữ liệu, chuyển giao tri thức, thu hồi quyền truy cập và xác nhận xóa dữ liệu theo thỏa thuận.

Ranh giới kiểm toán cần ghi rõ hệ thống, nhân sự và hồ sơ của nhà cung cấp mà kiểm toán viên có thể tiếp cận. Nếu chỉ có báo cáo do bên thứ ba cung cấp, cần xem xét kỳ báo cáo, phạm vi dịch vụ, ngoại lệ được nêu và các kiểm soát doanh nghiệp phải tự thực hiện trước khi sử dụng làm bằng chứng.

Tiêu chuẩn và khung tham chiếu trong kiểm toán công nghệ thông tin

Kiểm toán công nghệ thông tin cần phân biệt ba câu hỏi: kiểm toán được thực hiện như thế nào, quản trị công nghệ cần đạt mục tiêu gì và biện pháp kiểm soát nào phù hợp với rủi ro cụ thể. ITAF chủ yếu hỗ trợ câu hỏi thứ nhất; COBIT hỗ trợ xác định mục tiêu quản trị, quản lý; còn ISO/IEC 27001 và các khung an toàn thông tin giúp xây dựng tiêu chí kiểm soát. Chúng có thể bổ trợ nhau, nhưng không thay thế pháp luật, nghĩa vụ hợp đồng hoặc phạm vi nhiệm vụ đã được phê duyệt.

ITAF định hướng thực hành nghề nghiệp kiểm toán và bảo đảm công nghệ thông tin

ITAF của ISACA cung cấp chuẩn mực và hướng dẫn cho hoạt động kiểm toán, bảo đảm công nghệ thông tin. Trọng tâm của khung là chất lượng và tính nhất quán của quá trình kiểm toán: kiểm toán viên phải có đủ năng lực, duy trì tính khách quan, lập kế hoạch phù hợp với rủi ro, thu thập bằng chứng đáng tin cậy và báo cáo kết luận có căn cứ. ITAF không quy định rằng mọi doanh nghiệp phải sử dụng cùng một cấu hình tường lửa, chu kỳ đổi mật khẩu hoặc tần suất rà soát quyền.

Khi lập kế hoạch, kiểm toán viên cần xác định rõ đối tượng, phạm vi, giai đoạn được kiểm tra và tiêu chí đánh giá. Chẳng hạn, với nhiệm vụ kiểm toán quản lý truy cập hệ thống tài chính, phạm vi phải làm rõ có bao gồm tài khoản quản trị cơ sở dữ liệu, tài khoản dịch vụ, môi trường đám mây và nhà cung cấp vận hành thuê ngoài hay không. Tiếp đó là đánh giá rủi ro để ưu tiên những quyền có thể thay đổi dữ liệu tài chính, vô hiệu hóa nhật ký hoặc cấp quyền cho người khác.

• Thiết kế thủ tục kiểm toán: phân biệt kiểm tra thiết kế kiểm soát — quy trình có yêu cầu phê duyệt và phân tách nhiệm vụ hay không — với kiểm tra vận hành — các yêu cầu cấp quyền thực tế có được phê duyệt đúng người, đúng thời điểm hay không.
• Thu thập và đối chiếu bằng chứng: kết hợp danh sách quyền trích xuất trực tiếp từ hệ thống, phiếu yêu cầu, dữ liệu nhân sự và nhật ký hoạt động. Cần ghi nhận nguồn, thời điểm trích xuất, khoảng thời gian bao phủ và cách kiểm tra tính đầy đủ của dữ liệu; lời giải thích của đơn vị được kiểm toán không nên là bằng chứng duy nhất.
• Lấy mẫu và lập hồ sơ: xác định tổng thể giao dịch, phương pháp chọn mẫu và lý do ưu tiên mẫu rủi ro cao. Hồ sơ phải cho phép người soát xét hiểu kiểm toán viên đã kiểm tra gì, phát hiện ngoại lệ nào và vì sao bằng chứng hỗ trợ kết luận.

Phát hiện kiểm toán nên nêu tiêu chí, thực trạng, nguyên nhân, tác động và kiến nghị. Ví dụ, phát hiện “cấp quyền chậm thu hồi” cần chỉ rõ số tài khoản ngoại lệ trên tổng số đã kiểm tra, thời gian tồn tại của quyền, mức quyền liên quan và khả năng bị khai thác. Kiến nghị phải có đơn vị chịu trách nhiệm và mốc khắc phục khả thi. Kiểm toán viên cũng cần bảo vệ dữ liệu nhạy cảm thu được trong quá trình kiểm tra, đặc biệt khi trích xuất danh sách người dùng hoặc nhật ký chứa thông tin cá nhân.

COBIT hỗ trợ xây dựng tiêu chí đánh giá quản trị và kiểm soát công nghệ

COBIT 2019 của ISACA giúp liên kết mục tiêu doanh nghiệp, mục tiêu công nghệ và các mục tiêu quản trị, quản lý cần đánh giá. Khung phân biệt hoạt động quản trị trong nhóm EDM với các hoạt động quản lý thuộc APO, BAI, DSS và MEA. Sự phân biệt này quan trọng: ban lãnh đạo có thể đã phê duyệt mức chấp nhận rủi ro, nhưng bộ phận vận hành vẫn phải chứng minh các thay đổi, quyền truy cập và sự cố được xử lý theo mức đó.

Thay vì dùng toàn bộ COBIT như danh sách kiểm tra, kiểm toán viên bắt đầu từ một rủi ro cụ thể rồi lựa chọn mục tiêu liên quan. Với rủi ro thay đổi ứng dụng gây sai lệch dữ liệu, BAI06 – Quản lý thay đổi CNTT là một điểm tham chiếu phù hợp. Tiêu chí chi tiết cần được đối chiếu với chính sách nội bộ, kiến trúc hệ thống và yêu cầu pháp lý hoặc hợp đồng trước khi đưa vào chương trình kiểm toán.

• Trách nhiệm: ai đề xuất, đánh giá tác động, phê duyệt, triển khai và xác nhận kết quả thay đổi? Có cơ chế xử lý khi một cá nhân phải đảm nhiệm nhiều vai trò hay không?
• Kiểm soát trước triển khai: thay đổi có bằng chứng kiểm thử, kế hoạch quay lui và đánh giá ảnh hưởng đến bảo mật, tích hợp hoặc dữ liệu tài chính không? Người phê duyệt có đủ thẩm quyền không?
• Thay đổi khẩn cấp: điều kiện nào cho phép bỏ qua quy trình thông thường, ai được phép kích hoạt và việc rà soát sau triển khai được thực hiện, ghi nhận như thế nào?
• Giám sát: nhật ký triển khai có được đối chiếu với danh sách yêu cầu thay đổi để phát hiện thay đổi không có hồ sơ? Ngoại lệ lặp lại có được phân tích nguyên nhân không?

Các mục tiêu khác có thể được lựa chọn theo rủi ro: APO13 cho quản lý an toàn thông tin, DSS05 cho dịch vụ bảo mật và MEA02 cho giám sát hệ thống kiểm soát nội bộ. Khi đánh giá hiệu quả, không chỉ đếm số chính sách đã ban hành. Cần xem tỷ lệ ngoại lệ trên tổng thể phù hợp, mức độ nghiêm trọng, xu hướng qua các kỳ và bằng chứng cho thấy người phụ trách đã xử lý nguyên nhân gốc. Một quy trình được mô tả đầy đủ chưa chắc đã vận hành hiệu quả.

ISO/IEC 27001 và các khung kiểm soát an toàn thông tin trong xác định tiêu chí kiểm toán

ISO/IEC 27001:2022 quy định yêu cầu đối với hệ thống quản lý an toàn thông tin (ISMS), bao gồm xác định bối cảnh và phạm vi, đánh giá và xử lý rủi ro, hỗ trợ vận hành, đánh giá kết quả và cải tiến. Phụ lục A cung cấp danh mục kiểm soát tham chiếu; ISO/IEC 27002:2022 giải thích sâu hơn về các kiểm soát đó. Không phải mọi kiểm soát trong Phụ lục A đều mặc nhiên áp dụng cho mọi tổ chức. Kiểm toán viên cần xem cách tổ chức xác định kiểm soát cần thiết, lý do chọn hoặc loại trừ và tình trạng triển khai trong Tuyên bố áp dụng (Statement of Applicability).

Muốn biến một yêu cầu tổng quát như “kiểm soát quyền truy cập” thành tiêu chí kiểm tra, cần xác định đối tượng, hành động, thời hạn và bằng chứng. Ví dụ, tổ chức có thể quy định chủ sở hữu hệ thống phê duyệt quyền quản trị trước khi cấp; quyền được rà soát hằng quý; quyền của người nghỉ việc được thu hồi theo thời hạn nội bộ; ngoại lệ phải được chấp thuận và có ngày hết hiệu lực. Các mốc thời gian này là tiêu chí do tổ chức xác lập theo rủi ro, không nên trình bày như con số bắt buộc chung của ISO/IEC 27001.

• Đánh giá thiết kế: đối chiếu chính sách truy cập với kết quả đánh giá rủi ro, phân loại dữ liệu và phân công chủ sở hữu. Kiểm tra quy trình có bao quát tài khoản đặc quyền, tài khoản dịch vụ và quyền do nhà cung cấp nắm giữ không.
• Đánh giá vận hành: so khớp tài khoản thực tế với dữ liệu nhân sự, hồ sơ phê duyệt, kết quả rà soát định kỳ và nhật ký sử dụng quyền. Kiểm tra riêng những trường hợp chuyển vị trí, nghỉ việc hoặc được cấp quyền tạm thời.
• Đánh giá ngoại lệ: xác định quyền cấp ngoài quy trình có được ghi nhận rủi ro, phê duyệt bởi người có thẩm quyền, áp dụng biện pháp bù đắp và thu hồi khi hết hạn hay không.

NIST Cybersecurity Framework 2.0 có thể bổ sung góc nhìn theo các chức năng Govern, Identify, Protect, Detect, Respond và Recover, nhất là khi phạm vi kiểm toán trải từ quản trị rủi ro đến ứng phó sự cố. Với dịch vụ đám mây, tiêu chí còn phải phản ánh phân chia trách nhiệm giữa doanh nghiệp và nhà cung cấp: báo cáo bảo đảm của nhà cung cấp không chứng minh rằng doanh nghiệp đã cấu hình đúng quyền người dùng hoặc giám sát cảnh báo của mình. Tương tự, chứng nhận ISO/IEC 27001 chỉ liên quan đến phạm vi ISMS được chứng nhận; trước khi sử dụng làm bằng chứng, kiểm toán viên phải kiểm tra phạm vi, thời hạn hiệu lực và những hệ thống thực sự được bao phủ.

Quy trình kiểm toán công nghệ thông tin được thực hiện thế nào?

Quy trình kiểm toán công nghệ thông tin bắt đầu bằng việc xác định mục tiêu, phạm vi và tiêu chí; khảo sát hệ thống, đánh giá rủi ro để lập kế hoạch kiểm tra. Kiểm toán viên thu thập bằng chứng, kiểm tra tính đầy đủ của dữ liệu, chọn mẫu phù hợp và đánh giá cả thiết kế lẫn hiệu quả vận hành của các kiểm soát. Những ngoại lệ phải được xác minh với đơn vị liên quan trước khi kết luận. Báo cáo nêu rõ thực trạng, nguyên nhân, tác động và kiến nghị khả thi; sau đó theo dõi tiến độ khắc phục, kiểm tra lại bằng chứng để xác nhận kiểm soát hoạt động hiệu quả.

Khảo sát hệ thống, đánh giá rủi ro và lập kế hoạch kiểm toán

Kiểm toán công nghệ thông tin bắt đầu bằng việc xác định mục tiêu, phạm vi và tiêu chí đánh giá. Nhóm kiểm toán cần làm rõ ai sử dụng kết quả, quyết định nào sẽ dựa vào báo cáo, kỳ được kiểm tra và những hệ thống nào có thể ảnh hưởng đáng kể đến hoạt động hoặc dữ liệu của tổ chức. Phạm vi phải nêu rõ hệ thống tại chỗ, dịch vụ đám mây, ứng dụng thuê ngoài, môi trường sản xuất và các bên liên quan; đồng thời ghi nhận những hạn chế như không được truy cập dữ liệu cá nhân ở dạng rõ hoặc không được thử nghiệm trực tiếp trên hệ thống sản xuất.

Ở bước khảo sát, kiểm toán viên thu thập sơ đồ kiến trúc, danh mục tài sản, luồng dữ liệu, ma trận phân quyền, quy trình vận hành, hợp đồng dịch vụ và báo cáo kiểm toán trước đây. Phỏng vấn chủ sở hữu hệ thống, bộ phận an toàn thông tin, quản trị hạ tầng và người phụ trách nghiệp vụ giúp xác định hệ thống thực sự được vận hành như thế nào, thay vì chỉ dựa vào tài liệu quy định. Những thay đổi lớn trong kỳ, sự cố bảo mật, thời gian gián đoạn dịch vụ và mức độ phụ thuộc vào nhà cung cấp cần được ghi nhận vì có thể làm thay đổi trọng tâm kiểm toán.

Đánh giá rủi ro nên xem xét cả khả năng xảy ra và mức độ tác động đối với tính bảo mật, toàn vẹn và sẵn sàng của thông tin. Chẳng hạn, một ứng dụng xử lý thanh toán có thể cần ưu tiên kiểm tra quyền truy cập đặc quyền và tính toàn vẹn giao dịch; hệ thống sao lưu trọng yếu cần ưu tiên khả năng khôi phục, không chỉ sự tồn tại của bản sao lưu. Kiểm toán viên phân biệt rủi ro vốn có trước kiểm soát với rủi ro còn lại sau khi xem xét các kiểm soát hiện hành. Không nên đánh giá một kiểm soát là hiệu quả chỉ vì chính sách đã được ban hành.

Chương trình kiểm toán chuyển từng rủi ro ưu tiên thành thủ tục có thể thực hiện và kiểm chứng. Một kế hoạch đủ cụ thể thường xác định:

• Mục tiêu kiểm tra: ví dụ, quyền quản trị chỉ được cấp cho người có nhu cầu công việc và được rà soát định kỳ.
• Tiêu chí: chính sách nội bộ, điều khoản hợp đồng, yêu cầu pháp luật áp dụng hoặc khung kiểm soát được tổ chức lựa chọn.
• Tổng thể và thời kỳ: danh sách tài khoản, thay đổi hệ thống, sự cố hoặc giao dịch phát sinh trong khoảng thời gian được đánh giá.
• Thủ tục và nguồn bằng chứng: tài liệu cần nhận, cách đối chiếu dữ liệu, người cung cấp và thời hạn hoàn thành.

Kế hoạch cũng quy định cách cấp quyền truy cập cho kiểm toán viên, mã hóa và lưu giữ bằng chứng, thời hạn xóa dữ liệu sau kiểm toán, đầu mối phối hợp và cơ chế báo cáo khẩn. Nếu phát hiện dấu hiệu xâm nhập đang diễn ra hoặc nguy cơ mất dữ liệu nghiêm trọng, kiểm toán viên cần thông báo theo quy trình đã thống nhất mà không chờ đến báo cáo cuối kỳ. Mọi thử nghiệm có thể ảnh hưởng hệ thống sản xuất phải được phê duyệt trước về phạm vi và phương thức thực hiện.

Thu thập bằng chứng, chọn mẫu và kiểm tra thiết kế, vận hành kiểm soát

Bằng chứng kiểm toán có thể gồm chính sách, phiếu phê duyệt, cấu hình xuất từ hệ thống, nhật ký truy cập, dữ liệu giao dịch, biên bản họp, quan sát trực tiếp và kết quả thực hiện lại một thủ tục. Độ tin cậy của bằng chứng phụ thuộc vào nguồn gốc, tính đầy đủ và khả năng đối chiếu. Một ảnh chụp màn hình tại thời điểm kiểm toán không tự chứng minh cấu hình đã duy trì suốt cả năm; lời giải thích trong phỏng vấn cũng cần được xác minh bằng nhật ký, lịch sử cấu hình hoặc hồ sơ phê duyệt phù hợp.

Trước khi chọn mẫu, kiểm toán viên cần kiểm tra tính đầy đủ và chính xác của tổng thể. Ví dụ, danh sách thay đổi lấy từ công cụ quản lý yêu cầu nên được đối chiếu với lịch sử triển khai hoặc nhật ký kho mã nguồn để phát hiện thay đổi ngoài quy trình. Dữ liệu xuất ra cần ghi nhận thời điểm trích xuất, bộ lọc, phạm vi hệ thống và người thực hiện. Với bằng chứng nhạy cảm, chỉ thu thập các trường dữ liệu cần thiết; che hoặc mã hóa thông tin cá nhân khi không cần xem ở dạng rõ.

Kiểm tra thiết kế kiểm soát trả lời câu hỏi: nếu được thực hiện đúng, kiểm soát có đủ khả năng ngăn ngừa hoặc phát hiện rủi ro hay không? Ví dụ, quy trình cấp quyền yêu cầu phê duyệt nhưng không quy định ai được quyền phê duyệt chính tài khoản đặc quyền thì có thể chưa được thiết kế đầy đủ. Kiểm tra vận hành kiểm soát đi xa hơn: đối với các trường hợp phát sinh trong kỳ, việc phê duyệt có xảy ra trước khi cấp quyền không, người phê duyệt có phù hợp không và quyền được cấp có khớp yêu cầu đã duyệt không?

Cách chọn mẫu phụ thuộc tần suất kiểm soát, quy mô tổng thể, mức rủi ro và mục tiêu kiểm tra. Một cuộc rà soát quyền thực hiện hằng quý cần được xem xét theo các kỳ rà soát; kiểm soát áp dụng cho từng yêu cầu thay đổi đòi hỏi chọn từ tập yêu cầu phát sinh. Kiểm toán viên có thể kết hợp mẫu đại diện với các trường hợp rủi ro cao như thay đổi khẩn cấp, tài khoản dùng chung, truy cập ngoài giờ hoặc người dùng đã nghỉ việc. Cỡ mẫu không nên được chọn theo một con số cố định cho mọi kiểm soát; phương pháp và lý do chọn mẫu phải được lưu trong hồ sơ làm việc.

Khi kiểm tra quản lý thay đổi, kiểm toán viên có thể lần theo từng thay đổi từ yêu cầu, đánh giá tác động, phê duyệt, kiểm thử đến triển khai và phương án quay lui. Với sao lưu, cần kiểm tra lịch chạy, cảnh báo thất bại, vị trí lưu và kết quả thử khôi phục; chỉ thấy trạng thái “sao lưu thành công” chưa chứng minh dữ liệu có thể phục hồi trong thời gian nghiệp vụ yêu cầu. Với nhật ký bảo mật, cần xem sự kiện quan trọng có được ghi nhận, bảo vệ khỏi sửa đổi, giám sát và xử lý kịp thời hay không.

Ngoại lệ phát hiện trong mẫu phải được xác minh trước khi kết luận: đó là sai sót thực tế, dữ liệu trích xuất thiếu, hay trường hợp được áp dụng quy trình ngoại lệ hợp lệ? Tùy tính chất và tần suất sai lệch, kiểm toán viên có thể mở rộng mẫu hoặc thực hiện thủ tục bổ sung. Không suy rộng kết quả của mẫu chọn có chủ đích thành tỷ lệ sai lệch của toàn bộ tổng thể nếu phương pháp chọn mẫu không hỗ trợ suy luận đó.

Xác nhận phát hiện, lập báo cáo và theo dõi khắc phục

Trước khi phát hành báo cáo, nhóm kiểm toán trao đổi từng phát hiện với người phụ trách để kiểm tra dữ kiện, phạm vi ảnh hưởng và tiếp nhận bằng chứng bổ sung. Một phát hiện cần trình bày rõ tiêu chí – thực trạng – nguyên nhân – tác động – mức rủi ro – kiến nghị. Ví dụ, thay vì viết “quản lý tài khoản chưa tốt”, báo cáo nên nêu số tài khoản không được thu hồi đúng hạn trong tổng thể đã kiểm tra, thời gian tồn tại, loại quyền liên quan và nguy cơ truy cập trái phép. Sự bất đồng của đơn vị được kiểm toán cần được ghi nhận và xem xét trên cơ sở bằng chứng, không tự động làm phát hiện bị loại bỏ.

Kiến nghị nên giải quyết nguyên nhân gốc và có thể triển khai được: tự động hóa thông báo nghỉ việc, xác định người chịu trách nhiệm thu hồi quyền, thiết lập thời hạn xử lý và đối soát định kỳ giữa nhân sự với hệ thống định danh. Kế hoạch khắc phục cần có chủ sở hữu, mốc hoàn thành, biện pháp tạm thời nếu chưa thể sửa ngay và cách chứng minh kết quả. Khi theo dõi, kiểm toán viên kiểm tra bằng chứng triển khai và thử nghiệm lại một khoảng thời gian vận hành phù hợp. Việc cập nhật quy trình hoặc đánh dấu công việc “hoàn thành” không thay thế được bằng chứng rằng kiểm soát mới đã hoạt động hiệu quả.

Các kiểm soát và rủi ro thường được kiểm tra khi kiểm toán công nghệ thông tin

Kiểm toán công nghệ thông tin không chỉ xác nhận rằng doanh nghiệp có quy trình, mà còn đánh giá kiểm soát được thiết kế phù hợp và vận hành nhất quán trong kỳ kiểm toán hay không. Kiểm toán viên thường xác định hệ thống trọng yếu, dữ liệu cần bảo vệ và các quy trình nghiệp vụ phụ thuộc vào hệ thống đó trước khi chọn mẫu. Bằng chứng đáng tin cậy cần cho thấy ai thực hiện, thực hiện khi nào, theo thẩm quyền nào và kết quả ra sao.

Quyền truy cập quá mức, tài khoản không được thu hồi và thiếu phân tách nhiệm vụ

Rủi ro truy cập phát sinh khi người dùng có quyền vượt quá nhiệm vụ, vẫn giữ quyền sau khi chuyển vị trí hoặc nghỉ việc, hoặc sử dụng tài khoản có đặc quyền mà không thể truy vết cá nhân. Phạm vi kiểm tra cần bao gồm ứng dụng nghiệp vụ, cơ sở dữ liệu, hệ điều hành, dịch vụ đám mây và công cụ quản trị liên quan. Quyền được hiển thị trên một ứng dụng chưa chắc phản ánh đầy đủ quyền thực tế: người dùng có thể nhận quyền gián tiếp qua nhóm, vai trò kế thừa hoặc tài khoản dịch vụ.

Đối với quy trình cấp và thu hồi quyền, kiểm toán viên đối chiếu dữ liệu nhân sự với danh sách tài khoản, chọn mẫu trường hợp tuyển dụng, điều chuyển và nghỉ việc để kiểm tra thời điểm cập nhật quyền. Hồ sơ cấp quyền cần thể hiện yêu cầu, người phê duyệt có thẩm quyền, vai trò được cấp và thời điểm thực hiện. Khi phát hiện tài khoản của nhân sự đã nghỉ việc còn hoạt động, cần xác định tài khoản có thể đăng nhập hay không, đã phát sinh hoạt động sau ngày nghỉ việc chưa và hệ thống có kiểm soát khác ngăn truy cập không. Chỉ nhìn trạng thái “hoạt động” mà không kiểm tra khả năng sử dụng thực tế có thể dẫn đến kết luận thiếu chính xác.

• Tài khoản đặc quyền: xác định chủ sở hữu, mục đích sử dụng, cơ chế xác thực mạnh, phạm vi quyền và khả năng ghi nhận phiên quản trị. Tài khoản dùng chung cần có biện pháp quy trách nhiệm cho từng lần sử dụng.
• Rà soát quyền định kỳ: kiểm tra người quản lý hoặc chủ hệ thống có thực sự đánh giá quyền theo công việc hiện tại, thay vì phê duyệt hàng loạt mà không xem xét ngoại lệ.
• Quyền cấp tạm thời: kiểm tra thời hạn hết hiệu lực, việc thu hồi sau khi hoàn thành công việc và dấu vết sử dụng trong thời gian được cấp.

Trong quy trình tài chính, phân tách nhiệm vụ hạn chế khả năng một cá nhân vừa tạo giao dịch vừa che giấu sai phạm. Ma trận xung đột quyền cần được xây dựng theo chức năng thực tế, chẳng hạn tạo nhà cung cấp, sửa thông tin tài khoản ngân hàng, lập lệnh thanh toán và phê duyệt thanh toán. Kiểm toán viên không chỉ xem tên vai trò mà còn kiểm tra các tổ hợp quyền một người đang nắm giữ. Nếu nhân sự ít khiến việc phân tách hoàn toàn không khả thi, kiểm soát bù đắp có thể là người độc lập rà soát thay đổi thông tin nhà cung cấp và đối chiếu thanh toán. Ngoại lệ phải có lý do, người phê duyệt, thời hạn và bằng chứng giám sát.

Thay đổi hệ thống không được phê duyệt, cấu hình sai và thiếu nhật ký giám sát

Thay đổi chương trình, quy tắc tính toán, giao diện tích hợp hoặc cấu hình hạ tầng có thể làm sai số liệu nghiệp vụ ngay cả khi hệ thống vẫn hoạt động bình thường. Kiểm toán viên thường lấy danh sách triển khai từ công cụ quản lý mã nguồn, pipeline triển khai hoặc nhật ký nền tảng, rồi đối chiếu với phiếu thay đổi. Cách làm này giúp phát hiện thay đổi đã triển khai nhưng không xuất hiện trong danh sách yêu cầu được cung cấp.

Với từng mẫu, bằng chứng cần cho thấy yêu cầu nghiệp vụ, đánh giá tác động, kết quả kiểm thử, phê duyệt trước triển khai và xác nhận sau triển khai. Các thay đổi đối với tham số tính thuế, hạn mức hoặc công thức báo cáo cần được kiểm thử bằng tình huống cụ thể, bao gồm trường hợp biên và dữ liệu bất thường. Kiểm toán viên cũng xem người viết mã có thể tự phê duyệt và tự đưa thay đổi vào môi trường vận hành hay không. Đối với thay đổi khẩn cấp, việc triển khai trước phê duyệt thông thường có thể được chấp nhận theo quy trình riêng, nhưng vẫn cần ghi nhận lý do, kiểm thử phù hợp và rà soát độc lập sau triển khai.

Cấu hình sai thường liên quan đến cổng dịch vụ mở không cần thiết, tài khoản mặc định, quyền lưu trữ công khai, chính sách mật khẩu yếu hoặc cơ chế mã hóa bị tắt. Việc kiểm tra cần so sánh cấu hình thực tế với cấu hình chuẩn đã phê duyệt, đồng thời xem xét ngoại lệ theo mục đích sử dụng của từng hệ thống. Một cấu hình đạt chuẩn tại thời điểm triển khai có thể không còn phù hợp khi kiến trúc, mối đe dọa hoặc yêu cầu nghiệp vụ thay đổi.

Đối với nhật ký, kiểm toán viên cần xác định những sự kiện quan trọng có được ghi nhận hay không: đăng nhập thất bại, sử dụng quyền quản trị, thay đổi cấu hình, truy cập dữ liệu nhạy cảm và lỗi xử lý giao dịch. Sau đó cần kiểm tra tính đồng bộ thời gian, thời hạn lưu giữ, quyền xem và xóa nhật ký, cũng như cơ chế chuyển nhật ký đến nơi lưu trữ được bảo vệ. Nhật ký chỉ hỗ trợ phát hiện khi có quy tắc cảnh báo phù hợp, người nhận cảnh báo và hồ sơ cho thấy cảnh báo đã được phân loại, điều tra, xử lý. Một cảnh báo lặp lại nhưng không được xử lý có thể cho thấy kiểm soát tồn tại trên giấy tờ nhưng không vận hành hiệu quả.

Sao lưu không được kiểm thử, dữ liệu sai lệch và gián đoạn dịch vụ

Kiểm tra sao lưu cần bắt đầu từ yêu cầu khôi phục của từng dịch vụ. RPO thể hiện mức mất dữ liệu tối đa có thể chấp nhận, còn RTO là thời gian tối đa để khôi phục dịch vụ. Tần suất sao lưu và phương án phục hồi phải phù hợp với hai mục tiêu này: sao lưu hằng ngày khó đáp ứng RPO một giờ nếu không có cơ chế bổ sung. Kiểm toán viên xác định dữ liệu, cấu hình, khóa cần thiết và các thành phần tích hợp có nằm trong phạm vi sao lưu hay không; đồng thời xem việc mã hóa, hạn chế quyền truy cập và bảo vệ bản sao trước hành vi sửa xóa trái phép.

Có thông báo sao lưu thành công không đồng nghĩa với khả năng phục hồi. Bằng chứng kiểm thử cần thể hiện dữ liệu đã được khôi phục ở môi trường phù hợp, ứng dụng đọc và xử lý được dữ liệu, kết quả được đối chiếu, cùng thời gian khôi phục thực tế. Nếu chỉ khôi phục một tệp đơn lẻ, kiểm thử đó chưa chứng minh được khả năng phục hồi toàn bộ quy trình nghiệp vụ. Khi đánh giá rủi ro mã độc tống tiền, cần xem liệu kẻ tấn công có thể dùng cùng quyền quản trị để xóa cả dữ liệu vận hành lẫn bản sao lưu hay không.

Đối với tính chính xác dữ liệu, kiểm soát ứng dụng cần bao phủ giao dịch từ lúc tiếp nhận đến khi ghi nhận và báo cáo. Kiểm toán viên có thể đối chiếu tổng số bản ghi, tổng giá trị đầu vào–đầu ra, kiểm tra giao dịch bị từ chối và theo dõi cách xử lý bản ghi lỗi. Với hệ thống tích hợp, mã định danh duy nhất và cơ chế chống xử lý trùng đặc biệt quan trọng khi giao dịch được gửi lại sau lỗi mạng. Các chênh lệch đối soát cần có người phụ trách, thời hạn xử lý và bằng chứng điều chỉnh được phê duyệt; việc “xóa lỗi” khỏi hàng đợi mà không giải thích nguyên nhân không phải là xử lý đầy đủ.

Kế hoạch duy trì hoạt động phải xét đến chuỗi phụ thuộc giữa ứng dụng, cơ sở dữ liệu, mạng, dịch vụ xác thực, nhân sự và nhà cung cấp. Một máy chủ được khôi phục đúng hạn vẫn không tạo ra dịch vụ sử dụng được nếu kết nối đến hệ thống thanh toán hoặc nhân sự vận hành không sẵn sàng. Kiểm toán viên xem kết quả diễn tập, sự cố thực tế, các điểm nghẽn được phát hiện và tiến độ khắc phục sau diễn tập. Mức độ kiểm thử nên tương ứng với tác động của gián đoạn đối với từng quy trình nghiệp vụ.

Báo cáo kiểm toán công nghệ thông tin gồm những nội dung nào?

Báo cáo kiểm toán công nghệ thông tin nêu mục tiêu, phạm vi, kỳ kiểm toán, tiêu chí, phương pháp và nguồn bằng chứng. Những giới hạn như thiếu nhật ký hoặc không thể tiếp cận nhà cung cấp cần được ghi rõ cùng ảnh hưởng đến kết luận; thiếu bằng chứng không chứng minh kiểm soát hiệu quả.

Mỗi phát hiện cần trình bày thực trạng so với tiêu chí, bằng chứng có thể truy vết, nguyên nhân, tác động và mức rủi ro. Kiến nghị cần xử lý rủi ro trước mắt lẫn nguyên nhân gốc, kèm người chịu trách nhiệm, thời hạn và tiêu chí đóng phát hiện. Sau khi thực hiện, việc khắc phục cần được xác minh bằng bằng chứng và thử lại kiểm soát khi phù hợp.

Mô tả phạm vi, tiêu chí, phương pháp và giới hạn kiểm toán

Phần mở đầu cần xác định mục tiêu kiểm toán dưới dạng câu hỏi có thể trả lời bằng bằng chứng, chẳng hạn: “Quyền truy cập của nhân viên nghỉ việc có được thu hồi trong thời hạn quy định không?”. Báo cáo phải nêu rõ đơn vị được kiểm toán, hệ thống và dữ liệu liên quan, các địa điểm hoặc môi trường được xem xét, cùng kỳ kiểm toán và ngày chốt dữ liệu. Với hệ thống dùng dịch vụ đám mây, cần phân biệt trách nhiệm của doanh nghiệp với trách nhiệm của nhà cung cấp; không nên mặc nhiên xem việc kiểm toán cấu hình do doanh nghiệp quản lý là đã bao phủ toàn bộ hạ tầng của nhà cung cấp.

Tiêu chí kiểm toán là căn cứ để đánh giá thực tế, có thể đến từ quy định pháp luật áp dụng, hợp đồng, chính sách nội bộ, yêu cầu kiểm soát đã được phê duyệt hoặc một khuôn khổ chuyên môn. Báo cáo nên ghi tên tài liệu, phiên bản, điều khoản và thời điểm có hiệu lực. Nếu sử dụng ISO/IEC 27001, COBIT hoặc một khuôn khổ khác làm tài liệu tham chiếu, cần chỉ rõ yêu cầu nào được áp dụng cho từng phát hiện; việc viện dẫn tên khuôn khổ không đồng nghĩa doanh nghiệp đã được đánh giá phù hợp toàn bộ khuôn khổ đó.

Phương pháp cần được mô tả đủ để người đọc hiểu kết luận được hình thành như thế nào:

• Thu thập bằng chứng: phỏng vấn, xem xét quy trình, trích xuất cấu hình, nhật ký, danh sách tài khoản, phiếu yêu cầu thay đổi và biên bản xử lý sự cố.
• Kiểm tra vận hành: đối chiếu dữ liệu từ các nguồn độc lập, tái thực hiện một bước kiểm soát hoặc chọn mẫu giao dịch trong kỳ để xác định kiểm soát có được thực hiện thực tế hay không.
• Chọn mẫu: nêu tổng thể, cách chọn, cỡ mẫu và khoảng thời gian. Không suy rộng tỷ lệ sai sót của mẫu ra toàn bộ tổng thể nếu thiết kế chọn mẫu không cho phép suy luận đó.
• Bảo toàn bằng chứng: ghi nguồn, thời điểm trích xuất, người cung cấp và các bước xử lý dữ liệu; hạn chế đưa mật khẩu, dữ liệu cá nhân hoặc thông tin nhạy cảm không cần thiết vào bản báo cáo phổ biến rộng.

Giới hạn kiểm toán cần được gắn với ảnh hưởng cụ thể đối với kết luận. Ví dụ, nếu nhật ký chỉ lưu 30 ngày trong khi kỳ đánh giá dài sáu tháng, kiểm toán viên có thể đánh giá cấu hình lưu giữ nhật ký hiện tại nhưng không thể xác nhận đầy đủ việc giám sát trong những tháng không còn dữ liệu. Tương tự, không được tiếp cận trực tiếp nhà cung cấp, không có quyền kiểm tra một hệ thống hoặc không được phép thử nghiệm trên môi trường vận hành đều phải được ghi nhận. Báo cáo nên phân biệt trường hợp “không phát hiện sai lệch trong các thủ tục đã thực hiện” với “không tồn tại sai lệch”. Thiếu bằng chứng không phải bằng chứng rằng kiểm soát đã hoạt động hiệu quả.

Trình bày phát hiện bằng bằng chứng, nguyên nhân, tác động và mức độ rủi ro

Mỗi phát hiện nên có mã tham chiếu và cấu trúc nhất quán: tiêu chí – thực trạng – bằng chứng – nguyên nhân – tác động – mức rủi ro. Cách viết này giúp người đọc kiểm tra được khoảng cách giữa yêu cầu và thực tế. Chẳng hạn, thay vì nhận xét “quản lý quyền yếu”, báo cáo có thể nêu: trong danh sách 120 nhân viên nghỉ việc từ ngày 01/01 đến 30/06, kiểm toán viên đối chiếu hồ sơ nhân sự với dữ liệu định danh trích xuất ngày 05/07 và phát hiện 4 tài khoản vẫn ở trạng thái hoạt động sau thời hạn thu hồi quyền 24 giờ theo quy trình nội bộ. Đây là ví dụ minh họa; số liệu trong báo cáo thực tế phải truy vết được về bằng chứng gốc.

Bằng chứng cần thể hiện cả mức độ tin cậy và bối cảnh. Một ảnh chụp màn hình tại thời điểm kiểm tra có thể chứng minh trạng thái tài khoản lúc đó, nhưng chưa đủ để xác định tài khoản đã hoạt động liên tục từ ngày nghỉ việc. Để làm rõ diễn biến, cần xem thêm lịch sử thay đổi trạng thái, nhật ký đăng nhập và hồ sơ yêu cầu thu hồi quyền nếu các nguồn này còn sẵn có. Trước khi phát hành, kiểm toán viên nên trao đổi phát hiện với đơn vị được kiểm toán để xác nhận dữ kiện và tiếp nhận bằng chứng bổ sung, nhưng không vì thế mà thay thế đánh giá độc lập bằng lời giải thích chưa được chứng minh.

Phân tích nguyên nhân gốc phải đi xa hơn biểu hiện của sai sót. Bốn tài khoản tồn đọng có thể bắt nguồn từ việc bộ phận nhân sự gửi thông báo thủ công, hệ thống định danh không nhận được sự kiện nghỉ việc hoặc không có người theo dõi trường hợp xử lý thất bại. Tác động cần phân biệt nguy cơ với sự kiện đã xảy ra: tài khoản còn hoạt động tạo cơ hội truy cập trái phép, nhưng không được khẳng định đã có truy cập trái phép nếu nhật ký và bằng chứng khác không xác nhận điều đó.

Việc xếp hạng rủi ro nên dựa trên tiêu chí thống nhất của tổ chức, bao gồm:

• Khả năng xảy ra: thời gian tài khoản còn hiệu lực, khả năng đăng nhập từ bên ngoài và dấu hiệu sử dụng sau khi nhân viên nghỉ việc.
• Mức ảnh hưởng: quyền hạn của tài khoản, loại dữ liệu có thể tiếp cận và khả năng tác động đến hệ thống trọng yếu.
• Mức độ phơi nhiễm và kiểm soát bù đắp: tài khoản có quyền quản trị hay không, có xác thực đa yếu tố, giám sát truy cập hoặc biện pháp hạn chế đăng nhập nào đang hoạt động.

Báo cáo nên nêu mức rủi ro trước và sau khi xét kiểm soát hiện có, nếu phương pháp đánh giá của tổ chức sử dụng hai mức này. Quy tắc chấm điểm, giả định và lý do xếp hạng phải đủ rõ để người quản lý ưu tiên xử lý, thay vì chỉ dựa vào nhãn “cao” hoặc “nghiêm trọng”.

Đề xuất biện pháp khắc phục, người chịu trách nhiệm và thời hạn thực hiện

Kiến nghị cần xử lý đồng thời rủi ro trước mắt và nguyên nhân gốc. Với tài khoản chưa được thu hồi, hành động tức thời là xác minh chủ tài khoản, vô hiệu hóa quyền không còn hợp lệ và kiểm tra dấu hiệu sử dụng bất thường trong phạm vi nhật ký còn lưu. Về lâu dài, doanh nghiệp có thể tích hợp dữ liệu nghỉ việc từ hệ thống nhân sự sang nền tảng quản trị định danh, cảnh báo khi việc thu hồi thất bại và đối soát định kỳ giữa danh sách nhân sự với danh sách tài khoản. Kiến nghị phải xét tính khả thi về kỹ thuật, nguồn lực và sự phụ thuộc vào bên thứ ba.

Kế hoạch hành động của từng phát hiện nên ghi:

• Chủ sở hữu chịu trách nhiệm: một cá nhân hoặc chức danh có quyền điều phối việc khắc phục; nêu các bộ phận phối hợp khi cần.
• Công việc và mốc thời gian: biện pháp tạm thời, giải pháp lâu dài, hạn hoàn thành và các mốc trung gian đối với công việc kéo dài.
• Tiêu chí đóng phát hiện: bằng chứng dự kiến, chẳng hạn cấu hình luồng tự động, kết quả thử nghiệm trường hợp nghỉ việc, nhật ký cảnh báo và kết quả đối soát trong một khoảng thời gian xác định.

Sau hạn thực hiện, việc xác nhận không nên chỉ dựa vào thông báo “đã khắc phục”. Người theo dõi cần kiểm tra bằng chứng triển khai và, khi phù hợp, thử lại hiệu quả vận hành của kiểm soát. Nếu doanh nghiệp chọn chấp nhận rủi ro, báo cáo phải ghi rõ rủi ro còn lại, lý do, thời hạn xem xét lại và người phê duyệt đúng thẩm quyền. Chấp nhận rủi ro không thay thế nghĩa vụ tuân thủ các yêu cầu bắt buộc áp dụng.

Kiểm toán viên công nghệ thông tin cần kiến thức và năng lực gì?

Kiểm toán viên công nghệ thông tin cần hiểu hệ thống, bảo mật, quy trình nghiệp vụ và kiểm soát nội bộ để xác định rủi ro đối với dữ liệu, giao dịch. Họ đánh giá quyền truy cập, thay đổi hệ thống, khả năng phục hồi và hiệu quả vận hành của kiểm soát. Kỹ năng phân tích dữ liệu, xác minh bằng chứng và làm rõ ngoại lệ giúp đưa ra kết luận có cơ sở. Báo cáo cần nêu tình trạng, nguyên nhân, tác động và hướng khắc phục khả thi. Đạo đức, tính độc lập và bảo mật giúp duy trì sự khách quan trong kiểm toán. Chứng chỉ CISA cung cấp nền tảng chuyên môn nhưng không thay thế kinh nghiệm và xét đoán thực tế.

Kiến thức về hệ thống, bảo mật, quy trình nghiệp vụ và kiểm soát nội bộ

Kiểm toán viên công nghệ thông tin không nhất thiết phải vận hành thành thạo mọi nền tảng, nhưng cần hiểu hệ thống đủ sâu để xác định dữ liệu đi qua đâu, ai có thể tác động đến dữ liệu và kiểm soát nào ngăn ngừa hoặc phát hiện sai sót. Khi đánh giá một ứng dụng quản lý đơn hàng, chẳng hạn, họ cần lần theo dữ liệu từ lúc nhân viên nhập đơn, hệ thống kiểm tra hạn mức tín dụng, kho xác nhận giao hàng cho đến khi doanh thu được ghi nhận và chuyển sang báo cáo quản trị hoặc báo cáo tài chính.

Nền tảng kỹ thuật quan trọng bao gồm kiến trúc ứng dụng, hệ điều hành, mạng, cơ sở dữ liệu, giao diện tích hợp, dịch vụ đám mây và cơ chế ghi nhật ký. Kiểm toán viên cần phân biệt tài khoản người dùng với tài khoản dịch vụ; hiểu quyền truy cập được cấp trực tiếp hay thông qua nhóm; biết một thay đổi mã nguồn phải trải qua những bước nào trước khi triển khai. Với môi trường đám mây, cần làm rõ mô hình trách nhiệm chia sẻ: nhà cung cấp bảo vệ phần hạ tầng thuộc trách nhiệm của họ, còn khách hàng vẫn phải quản lý cấu hình, danh tính, dữ liệu và nhiều hoạt động giám sát của mình.

Kiến thức bảo mật phải gắn với kịch bản rủi ro cụ thể, thay vì chỉ dừng ở danh sách công nghệ. Các nội dung thường cần xem xét gồm:

• Quản lý truy cập: quy trình cấp, thay đổi và thu hồi quyền; xác thực đa yếu tố; tài khoản đặc quyền; rà soát quyền định kỳ.
• Quản lý thay đổi: phê duyệt yêu cầu, thử nghiệm, phân tách môi trường phát triển và sản xuất, kiểm soát thay đổi khẩn cấp.
• Vận hành và khả năng phục hồi: giám sát sự cố, sao lưu, kiểm thử khôi phục, quản lý bản vá và xử lý lỗ hổng.
• Bảo vệ dữ liệu: phân loại dữ liệu, mã hóa, giới hạn truy xuất và kiểm soát việc truyền dữ liệu giữa các hệ thống.

Hiểu biết nghiệp vụ giúp xác định mức độ quan trọng của một điểm yếu kỹ thuật. Quyền sửa thông tin tài khoản ngân hàng của nhà cung cấp không đơn thuần là “quyền quá rộng”: nếu cùng một người có thể sửa thông tin và phê duyệt thanh toán, rủi ro chuyển tiền sai đối tượng tăng lên. Kiểm toán viên phải đối chiếu cấu hình quyền với nguyên tắc phân tách nhiệm vụ, luồng phê duyệt thực tế và các kiểm soát bù đắp, chẳng hạn bước xác minh độc lập khi thay đổi tài khoản nhận tiền.

Kiến thức kiểm soát nội bộ còn giúp phân biệt thiết kế kiểm soát với hiệu quả vận hành. Một quy định yêu cầu quản lý phê duyệt mọi thay đổi có thể được thiết kế hợp lý, nhưng chưa vận hành hiệu quả nếu nhiều thay đổi đã triển khai trước khi được phê duyệt. Ngược lại, không nên kết luận kiểm soát thất bại chỉ từ một ảnh chụp cấu hình khi chưa xác định thời điểm áp dụng, phạm vi hệ thống và bằng chứng về các kiểm soát liên quan.

Kỹ năng phân tích dữ liệu, kiểm tra bằng chứng và viết báo cáo kiểm toán

Phân tích dữ liệu cho phép kiểm toán viên kiểm tra toàn bộ tập giao dịch hoặc tập trung vào những trường hợp có rủi ro cao. Họ có thể truy vấn tài khoản không đăng nhập trong thời gian dài nhưng vẫn giữ quyền quản trị; đối chiếu nhân sự đã nghỉ việc với danh sách người dùng còn hiệu lực; tìm thay đổi cấu hình ngoài khung giờ bảo trì; hoặc phát hiện hóa đơn trùng số, trùng số tiền và nhà cung cấp. Tuy nhiên, một ngoại lệ do công cụ phát hiện chưa tự động trở thành phát hiện kiểm toán: trường hợp đó cần được xác minh trong bối cảnh nghiệp vụ.

Trước khi phân tích, kiểm toán viên phải đánh giá dữ liệu đầu vào. Cần xác định báo cáo được trích từ hệ thống nào, bao phủ khoảng thời gian nào, có loại trừ bản ghi hay trạng thái nào không và người tạo báo cáo có thể chỉnh sửa kết quả hay không. Việc đối chiếu tổng số bản ghi, tổng giá trị hoặc các trường khóa với nguồn độc lập giúp kiểm tra tính đầy đủ và chính xác. Nếu dùng ảnh chụp màn hình, tệp xuất hoặc báo cáo do đơn vị được kiểm toán cung cấp, cần ghi nhận ngày tạo, tham số truy vấn và phiên bản dữ liệu để người khác có thể tái thực hiện phép kiểm tra.

Một cuộc kiểm tra có thể kết hợp nhiều phương pháp:

• Phỏng vấn và quan sát: tìm hiểu quy trình thực tế, nhưng không chỉ dựa vào lời mô tả để kết luận kiểm soát đã vận hành.
• Kiểm tra hồ sơ: đối chiếu yêu cầu, phê duyệt, nhật ký hệ thống và bằng chứng hoàn tất tại cùng một thời điểm hoặc giao dịch.
• Chọn mẫu: xác định tổng thể, kỳ kiểm toán, tiêu chí chọn và lý do cỡ mẫu phù hợp với mục tiêu kiểm tra.
• Thực hiện lại: tự tính toán, đối chiếu hoặc kiểm tra cách hệ thống áp dụng một quy tắc, khi điều kiện truy cập và phạm vi cho phép.

Khi phát hiện ngoại lệ, kiểm toán viên cần trao đổi với chủ sở hữu quy trình để xác minh nguyên nhân và tác động. Ví dụ, một thay đổi ngoài giờ có thể là xử lý sự cố đã được cho phép; câu hỏi kiểm toán là việc phê duyệt, thử nghiệm và rà soát sau triển khai có đáp ứng quy định hay không. Hồ sơ làm việc cần thể hiện tiêu chí đánh giá, bằng chứng, thủ tục đã thực hiện và cơ sở đưa ra nhận định, đồng thời bảo vệ dữ liệu nhạy cảm được thu thập.

Báo cáo kiểm toán tốt trình bày rõ tình trạng, nguyên nhân, rủi ro và hành động khắc phục khả thi. Thay vì chỉ viết “quyền truy cập chưa phù hợp”, báo cáo nên nêu nhóm quyền nào đang được cấp, đối tượng nào chịu ảnh hưởng, khả năng thực hiện thao tác gì và vì sao kiểm soát hiện tại chưa đủ. Kiến nghị cần có người chịu trách nhiệm, thời hạn dự kiến và cách xác nhận việc khắc phục; mức độ ưu tiên phải dựa trên tác động và khả năng xảy ra, không chỉ dựa vào số lượng ngoại lệ.

Đạo đức nghề nghiệp, tính độc lập và vai trò của chứng chỉ CISA

Kiểm toán viên thường tiếp cận dữ liệu nhân sự, thông tin khách hàng, cấu hình bảo mật và kế hoạch xử lý sự cố. Vì vậy, họ phải tuân thủ phạm vi truy cập được giao, chỉ thu thập bằng chứng cần thiết, lưu trữ an toàn và không chia sẻ thông tin ngoài những người có thẩm quyền. Tính bảo mật không cho phép che giấu phát hiện quan trọng; thông tin phải được báo cáo đúng kênh, đúng phạm vi và theo quy định áp dụng.

Tính khách quan đòi hỏi kiểm toán viên đánh giá cả bằng chứng ủng hộ lẫn bằng chứng trái với giả định ban đầu. Nếu từng thiết kế, vận hành hoặc phê duyệt một kiểm soát, họ có thể đối mặt với rủi ro tự kiểm tra khi được giao đánh giá kiểm soát đó. Tổ chức cần công bố xung đột lợi ích và áp dụng biện pháp phù hợp, chẳng hạn giao phần việc cho kiểm toán viên khác hoặc thực hiện rà soát độc lập. Kiểm toán viên cũng cần nêu rõ giới hạn phạm vi khi không tiếp cận được hệ thống, dữ liệu hoặc bằng chứng cần thiết, thay vì đưa ra mức độ bảo đảm vượt quá công việc đã thực hiện.

CISA là chứng chỉ nghề nghiệp do ISACA cấp, tập trung vào kiểm toán, quản trị, quản lý rủi ro, vận hành và bảo vệ tài sản thông tin. Việc đạt và duy trì chứng chỉ gắn với các yêu cầu do tổ chức cấp chứng chỉ quy định, bao gồm kinh nghiệm liên quan, đạo đức nghề nghiệp và giáo dục chuyên môn liên tục. Kiến thức CISA giúp kiểm toán viên có khung tư duy và thuật ngữ chung, nhưng chứng chỉ không thay thế kinh nghiệm thực tế, xét đoán nghề nghiệp và sự am hiểu hệ thống được kiểm toán.

Câu hỏi thường gặp về kiểm toán công nghệ thông tin

Kiểm toán công nghệ thông tin (CNTT) đánh giá liệu các kiểm soát đối với hệ thống, dữ liệu và quy trình vận hành có được thiết kế phù hợp và hoạt động hiệu quả hay không. Phạm vi có thể bao gồm quản lý truy cập, thay đổi chương trình, sao lưu, ứng phó sự cố và quản lý nhà cung cấp. Các câu hỏi dưới đây giúp doanh nghiệp xác định cách triển khai phù hợp với mức độ rủi ro của mình.

Doanh nghiệp nào cần thực hiện kiểm toán công nghệ thông tin?

Doanh nghiệp nên ưu tiên kiểm toán khi sự cố CNTT có thể làm gián đoạn hoạt động, gây thiệt hại tài chính, lộ dữ liệu hoặc ảnh hưởng đáng kể đến khách hàng. Những trường hợp cần đặc biệt chú ý gồm:

• Xử lý dữ liệu cá nhân, thông tin tài chính, hồ sơ sức khỏe hoặc bí mật kinh doanh.
• Phụ thuộc vào hệ thống lõi như ngân hàng số, thương mại điện tử, ERP hoặc nền tảng cung cấp dịch vụ liên tục.
• Có nhiều hệ thống tích hợp, tài khoản đặc quyền hoặc nhà cung cấp tham gia vận hành.

Nhu cầu kiểm toán tăng sau khi chuyển lên đám mây, sáp nhập, thay đổi hệ thống lõi hoặc xảy ra sự cố. Doanh nghiệp nhỏ không nhất thiết phải kiểm toán toàn bộ hệ thống: có thể bắt đầu từ quy trình có khả năng gây thiệt hại lớn nhất, chẳng hạn quyền quản trị, sao lưu và thanh toán.

Kiểm toán công nghệ thông tin có bắt buộc với mọi doanh nghiệp không?

Không có một nghĩa vụ kiểm toán CNTT giống nhau cho mọi doanh nghiệp. Yêu cầu cụ thể phụ thuộc vào ngành nghề, khu vực pháp lý, loại dữ liệu được xử lý, quy định của cơ quan quản lý và cam kết với khách hàng hoặc đối tác. Một số doanh nghiệp cần cung cấp kết quả đánh giá kiểm soát theo hợp đồng, dù không có yêu cầu kiểm toán chung áp dụng cho toàn bộ hoạt động.

Cần phân biệt nghĩa vụ tuân thủ với việc tự nguyện kiểm toán để quản trị rủi ro. Doanh nghiệp nên lập danh mục yêu cầu áp dụng, xác định hệ thống và đơn vị chịu trách nhiệm, rồi đối chiếu từng yêu cầu với bằng chứng cần có. Chứng nhận theo một tiêu chuẩn hoặc kết quả kiểm thử bảo mật riêng lẻ không mặc nhiên thay thế mọi cuộc kiểm toán mà pháp luật hay hợp đồng yêu cầu.

Bao lâu nên kiểm toán công nghệ thông tin một lần?

Tần suất nên được xác định theo mức độ quan trọng của hệ thống, tốc độ thay đổi và lịch sử sự cố, thay vì áp dụng một lịch cố định cho mọi nội dung. Nhiều doanh nghiệp đưa hệ thống trọng yếu vào kế hoạch đánh giá hằng năm; các mảng ít rủi ro hơn có thể luân phiên trong kế hoạch nhiều năm. Khi triển khai hệ thống mới, thay đổi kiến trúc đáng kể, chuyển nhà cung cấp hoặc xảy ra sự cố nghiêm trọng, nên đánh giá bổ sung mà không chờ đến kỳ tiếp theo.

Giữa hai kỳ kiểm toán, bộ phận phụ trách vẫn cần theo dõi chỉ số cảnh báo và tiến độ khắc phục. Với mỗi phát hiện, nên ghi rõ người chịu trách nhiệm, hạn xử lý, biện pháp tạm thời và bằng chứng xác nhận hoàn tất. Việc đóng phát hiện cần dựa trên kiểm tra lại, không chỉ dựa vào thông báo đã sửa.

Chi phí và thời gian kiểm toán công nghệ thông tin phụ thuộc vào yếu tố nào?

Chi phí và tiến độ chủ yếu phụ thuộc vào phạm vi, độ sâu kiểm thử và khả năng tiếp cận bằng chứng. Kiểm toán quyền truy cập của một ứng dụng khác đáng kể với việc đánh giá nhiều trung tâm dữ liệu, môi trường đám mây và nhà cung cấp. Số địa điểm, số hệ thống, kỳ dữ liệu cần kiểm tra, mức độ tự động hóa và yêu cầu sử dụng chuyên gia chuyên sâu cũng ảnh hưởng đến nguồn lực.

Ở giai đoạn lập kế hoạch, hai bên nên thống nhất mục tiêu, tiêu chí đánh giá, hệ thống thuộc phạm vi, phương pháp lấy mẫu, thời kỳ xem xét và sản phẩm bàn giao. Hồ sơ được lập chỉ mục tốt giúp giảm thời gian tìm kiếm, nhưng không thay thế việc xác minh độc lập. Nếu bằng chứng thiếu hoặc không đáng tin cậy, kiểm toán viên có thể phải mở rộng mẫu, thực hiện thủ tục thay thế hoặc nêu giới hạn phạm vi trong báo cáo.

Doanh nghiệp cần chuẩn bị hồ sơ và quyền truy cập gì trước kiểm toán?

Nên chỉ định đầu mối cho từng hệ thống và chuẩn bị danh mục tài sản, sơ đồ luồng dữ liệu, chính sách, danh sách người dùng và quyền đặc quyền, yêu cầu cấp hoặc thu hồi quyền, phiếu thay đổi, nhật ký vận hành, kết quả sao lưu, biên bản thử khôi phục và hồ sơ sự cố. Tài liệu cần thể hiện kiểm soát đã vận hành trong thời kỳ được kiểm tra, không chỉ là quy trình được ban hành trên giấy.

• Cấp quyền cho kiểm toán viên theo nguyên tắc tối thiểu cần thiết, ưu tiên chỉ đọc, giới hạn thời gian và ghi nhật ký truy cập.
• Thống nhất cách trích xuất dữ liệu, đối chiếu tính đầy đủ của mẫu và lưu dấu thời điểm thu thập.
• Che hoặc loại bỏ dữ liệu cá nhân, mật khẩu và khóa bí mật khi chúng không cần thiết cho mục tiêu kiểm toán.

Bằng chứng nhạy cảm cần được truyền, lưu trữ và hủy theo thỏa thuận bảo mật; tránh gửi tệp qua kênh không được phê duyệt.

Kiểm toán công nghệ thông tin có làm gián đoạn hoạt động hệ thống không?

Phỏng vấn, xem hồ sơ, phân tích bản xuất dữ liệu và truy vấn chỉ đọc thường có thể thực hiện với ảnh hưởng hạn chế. Tuy nhiên, ngay cả truy vấn chỉ đọc cũng có thể tạo tải lớn nếu chạy trên cơ sở dữ liệu sản xuất; vì vậy cần thống nhất giới hạn truy vấn, thời điểm thực hiện và đầu mối giám sát.

Đối với quét lỗ hổng, thử tải hoặc thử khai thác, doanh nghiệp và nhóm thực hiện phải xác định phạm vi được phép, mức độ tác động, cửa sổ bảo trì và phương án dừng hoặc khôi phục trước khi bắt đầu. Có thể ưu tiên môi trường thử nghiệm hoặc kiểm tra cấu hình khi phù hợp. Kiểm toán không trao quyền tự ý thử khai thác hệ thống đang phục vụ khách hàng.

Kiểm toán công nghệ thông tin có bảo đảm hệ thống không bị tấn công không?

Không. Kết luận kiểm toán chỉ áp dụng cho mục tiêu, phạm vi, thời kỳ và bằng chứng đã xem xét. Việc lấy mẫu có thể không phát hiện mọi sai sót; lỗ hổng mới, thay đổi cấu hình hoặc hành vi tấn công phát sinh sau thời điểm kiểm tra vẫn có thể tạo rủi ro. Kiểm toán cũng không đồng nghĩa với kiểm thử xâm nhập: một bên tập trung đánh giá kiểm soát và bằng chứng vận hành, bên kia tìm cách xác định khả năng khai thác trong phạm vi được cho phép.

Giá trị thực tế của kiểm toán là chỉ ra kiểm soát nào thiếu, vận hành chưa nhất quán hoặc chưa có bằng chứng, sau đó giúp lãnh đạo ưu tiên nguồn lực theo mức độ ảnh hưởng và khả năng xảy ra.

Học công nghệ thông tin hay kế toán có thể làm kiểm toán viên công nghệ thông tin không?

Cả hai nền tảng đều phù hợp, nhưng cần bổ sung nhóm kiến thức còn thiếu. Người học CNTT nên học kiểm soát nội bộ, quản trị rủi ro, phương pháp lấy mẫu và cách liên hệ sự cố hệ thống với báo cáo, vận hành hoặc tuân thủ. Người học kế toán cần hiểu cơ sở dữ liệu, kiến trúc ứng dụng, quản lý định danh, nhật ký, hạ tầng đám mây và các nguyên tắc an toàn thông tin.

Trong thực hành, kiểm toán viên phải xác định tiêu chí đánh giá, phỏng vấn để hiểu quy trình, kiểm tra bằng chứng, phân biệt thiếu thiết kế kiểm soát với kiểm soát vận hành không hiệu quả, rồi viết phát hiện nêu rõ rủi ro và căn cứ. Chứng chỉ nghề nghiệp có thể hỗ trợ hệ thống hóa kiến thức, nhưng không thay thế kinh nghiệm làm việc có hướng dẫn, tư duy hoài nghi nghề nghiệp và việc cập nhật công nghệ liên tục.

Câu hỏi thường gặp về kiểm toán công nghệ thông tin

Kiểm toán nội bộ hoặc bên ngoài đánh giá độc lập; bộ phận liên quan sở hữu kiểm soát, lãnh đạo giám sát rủi ro. Phạm vi gồm quản trị, hạ tầng, hệ thống thông tin, kiểm soát chung, kiểm soát ứng dụng và dịch vụ thuê ngoài. Kiểm toán viên xác minh tài liệu, dữ liệu, quan sát và thử nghiệm; kết hợp kiểm tra toàn bộ với chọn mẫu theo rủi ro. Chứng nhận ISO/IEC 27001 không thay thế kiểm toán đối với rủi ro chưa được bao phủ. Dữ liệu nhạy cảm chỉ được truy cập ở mức cần thiết. Phát hiện được xếp hạng theo rủi ro, đối chiếu phản hồi và giao chủ sở hữu khắc phục. Chỉ đóng phát hiện sau khi xác minh hiệu quả biện pháp xử lý.

Ai chịu trách nhiệm thực hiện kiểm toán công nghệ thông tin trong doanh nghiệp?

Kiểm toán nội bộ hoặc đơn vị kiểm toán bên ngoài thực hiện đánh giá theo mục tiêu, phạm vi và tiêu chí đã được phê duyệt. Chủ sở hữu quy trình và bộ phận công nghệ chịu trách nhiệm thiết kế, vận hành kiểm soát, cung cấp bằng chứng và khắc phục thiếu sót. Ban điều hành phân bổ nguồn lực; hội đồng quản trị hoặc ủy ban kiểm toán giám sát các rủi ro trọng yếu. Cần phân biệt rõ người đánh giá độc lập với người sở hữu kiểm soát: kiểm toán viên có thể kiến nghị giải pháp nhưng không nên trực tiếp vận hành giải pháp đó.

Kiểm toán công nghệ thông tin khác kiểm toán hệ thống thông tin như thế nào?

Hai thuật ngữ thường được dùng gần nghĩa, nhưng phạm vi có thể khác theo từng tổ chức. Kiểm toán hệ thống thông tin thường tập trung vào hệ thống tạo lập, xử lý, lưu trữ và cung cấp thông tin; kiểm toán công nghệ thông tin có thể bao quát thêm quản trị công nghệ, hạ tầng, an ninh mạng và dịch vụ thuê ngoài. Tên gọi không tự xác định nội dung công việc. Kiểm toán viên cần đối chiếu văn bản giao nhiệm vụ, mục tiêu, hệ thống liên quan, kỳ đánh giá và tiêu chí kiểm toán trước khi lập chương trình thử nghiệm.

Kiểm soát công nghệ thông tin chung và kiểm soát ứng dụng khác nhau ở đâu?

Kiểm soát công nghệ thông tin chung tạo nền tảng đáng tin cậy cho nhiều hệ thống, chẳng hạn quản lý quyền truy cập đặc quyền, thay đổi chương trình, vận hành tác vụ và sao lưu. Kiểm soát ứng dụng gắn với một luồng xử lý cụ thể: chặn hóa đơn trùng, kiểm tra hạn mức hoặc đối soát dữ liệu đầu vào với kết quả xử lý. Khi đánh giá kiểm soát ứng dụng tự động, kiểm toán viên còn phải xem ai được sửa cấu hình, mã nguồn hoặc bảng tham số. Nếu các thay đổi đó thiếu phê duyệt và giám sát, kết quả xử lý khó được coi là đáng tin cậy.

Kiểm toán viên thu thập và xác minh bằng chứng bằng cách nào?

Phương pháp thường gồm kiểm tra tài liệu, phỏng vấn, quan sát, trích xuất dữ liệu và thực hiện lại kiểm soát. Ví dụ, để kiểm tra việc thu hồi quyền, kiểm toán viên đối chiếu ngày nghỉ việc từ hồ sơ nhân sự với thời điểm vô hiệu hóa tài khoản và nhật ký định danh. Bằng chứng cần phù hợp với mục tiêu, kỳ kiểm toán và tổng thể được đánh giá. Ảnh chụp màn hình tại một thời điểm không chứng minh kiểm soát vận hành liên tục; dữ liệu trích xuất cũng cần được kiểm tra về nguồn, điều kiện lọc và tính đầy đủ.

Kiểm toán công nghệ thông tin kiểm tra toàn bộ dữ liệu hay chọn mẫu?

Kiểm toán viên có thể kết hợp hai cách. Phân tích dữ liệu cho phép rà soát toàn bộ giao dịch hoặc tài khoản theo quy tắc xác định, như tìm quyền truy cập sau ngày nghỉ việc. Tuy nhiên, kiểm tra toàn bộ bản ghi không đồng nghĩa với bảo đảm phát hiện mọi sai sót: kết quả còn phụ thuộc dữ liệu đầu vào và logic truy vấn. Với kiểm soát thủ công, kiểm toán viên thường chọn mẫu theo tần suất vận hành, mức rủi ro và đặc điểm tổng thể. Báo cáo cần nêu rõ phạm vi kiểm tra và giới hạn suy luận từ mẫu.

Hệ thống thuê ngoài và dịch vụ đám mây có thuộc phạm vi kiểm toán không?

Có, nếu dịch vụ hỗ trợ quy trình hoặc dữ liệu thuộc mục tiêu kiểm toán. Bằng chứng có thể gồm hợp đồng, cam kết mức dịch vụ, báo cáo bảo đảm độc lập và cấu hình do doanh nghiệp quản lý. Khi xem báo cáo của nhà cung cấp, cần kiểm tra thời kỳ được đánh giá, dịch vụ nằm trong phạm vi, ngoại lệ và các kiểm soát khách hàng phải tự thực hiện. Với đám mây, nhà cung cấp bảo vệ một phần hạ tầng không có nghĩa doanh nghiệp đã quản lý tốt tài khoản, phân quyền, khóa mã hóa, cấu hình lưu trữ hoặc giám sát nhật ký.

Doanh nghiệp đã có chứng nhận ISO/IEC 27001 có cần kiểm toán công nghệ thông tin không?

Vẫn có thể cần. Chứng nhận ISO/IEC 27001 liên quan đến hệ thống quản lý an toàn thông tin trong phạm vi chứng nhận và tại các thời điểm đánh giá tương ứng. Một cuộc kiểm toán công nghệ thông tin có thể xem xét mục tiêu khác, như tính chính xác của giao dịch tài chính, cấu hình ứng dụng hoặc hiệu quả kiểm soát tại nhà cung cấp. Doanh nghiệp nên kiểm tra phạm vi và thời hạn chứng nhận, sử dụng kết quả đánh giá như một nguồn thông tin, rồi thực hiện thử nghiệm bổ sung đối với những rủi ro chưa được bao phủ.

Kiểm toán viên được phép truy cập dữ liệu nhạy cảm đến mức nào?

Quyền truy cập phải tuân theo nguyên tắc cần biết và tối thiểu cần thiết để đạt mục tiêu kiểm toán. Nên ưu tiên dữ liệu đã che định danh, báo cáo tổng hợp hoặc kết quả truy vấn do người có thẩm quyền thực hiện, nếu vẫn đủ giá trị chứng minh. Trường hợp cần dữ liệu gốc, phải xác định rõ người phê duyệt, mục đích sử dụng, kênh truyền, nơi lưu, quyền truy cập, thời hạn lưu giữ và cách xóa. Kiểm toán viên cũng cần tránh đưa dữ liệu nhạy cảm không cần thiết vào giấy tờ làm việc hoặc báo cáo.

Phát hiện kiểm toán được phân loại mức độ rủi ro như thế nào?

Mức độ rủi ro thường dựa trên khả năng xảy ra và tác động, đồng thời xét số hệ thống bị ảnh hưởng, độ nhạy dữ liệu, thời gian tồn tại của thiếu sót và hiệu quả kiểm soát bù đắp. Chẳng hạn, tài khoản quản trị của nhân sự đã nghỉ việc có thể nghiêm trọng hơn tài khoản chỉ có quyền đọc. Kiểm toán viên cần phân biệt rủi ro tiềm tàng với rủi ro còn lại sau kiểm soát, mô tả tình huống có thể xảy ra và giải thích cơ sở xếp hạng theo thang đánh giá thống nhất.

Doanh nghiệp cần làm gì khi không đồng ý với phát hiện kiểm toán?

Đơn vị được kiểm toán nên phản hồi bằng bằng chứng có thể xác minh: nhật ký hệ thống, hồ sơ phê duyệt, cấu hình hiệu lực trong kỳ hoặc tài liệu về kiểm soát bù đắp. Cần chỉ rõ phần nào của phát hiện chưa chính xác: tình trạng, nguyên nhân, phạm vi hay mức rủi ro. Kiểm toán viên phải đánh giá lại khách quan và sửa kết luận nếu bằng chứng mới làm thay đổi nhận định. Nếu vẫn bất đồng, báo cáo có thể ghi nhận quan điểm quản lý, bằng chứng liên quan và lý do kiểm toán viên giữ nguyên kết luận.

Ai chịu trách nhiệm khắc phục sai sót sau kiểm toán công nghệ thông tin?

Chủ sở hữu quy trình hoặc hệ thống chịu trách nhiệm lập kế hoạch và xác nhận biện pháp khắc phục đáp ứng nhu cầu nghiệp vụ; bộ phận công nghệ, an toàn thông tin hoặc nhà cung cấp triển khai phần việc được giao. Kế hoạch nên nêu nguyên nhân gốc, hành động cụ thể, người chịu trách nhiệm, mốc hoàn thành và biện pháp kiểm soát tạm thời nếu chưa thể xử lý ngay. Ban quản lý phê duyệt nguồn lực và quyết định việc chấp nhận rủi ro còn lại. Kiểm toán viên theo dõi tiến độ nhưng giữ vai trò đánh giá độc lập.

Làm thế nào để xác nhận kiến nghị kiểm toán đã được thực hiện hiệu quả?

Trạng thái “đã hoàn thành” chỉ là thông tin từ đơn vị thực hiện, không thay thế thử nghiệm xác minh. Kiểm toán viên cần đối chiếu giải pháp với nguyên nhân gốc và kiểm tra bằng chứng phù hợp: xác nhận tài khoản đã bị vô hiệu hóa, lấy mẫu các lần cấp quyền sau thay đổi hoặc chứng kiến phục hồi dữ liệu từ bản sao lưu. Nếu kiểm soát mới được triển khai, cần phân biệt đã thiết kế và đưa vào sử dụng với đã vận hành hiệu quả trong một khoảng thời gian. Phát hiện chỉ nên đóng khi bằng chứng đáp ứng tiêu chí đã xác định.