I. MỤC TIÊU, ĐỊNH HƯỚNG CHUYỂN ĐỔI SỐ TRONG HOẠT ĐỘNG KIỂM TOÁN NỘI BỘ

Công nghệ số, chuyển đổi số trong Cách mạng công nghiệp lần thứ tư (CMCN 4.0) là xu hướng tất yếu trong tất cả các lĩnh vực của đời sống xã hội hiện nay, là đòi hỏi khách quan cho sự phát triển của mỗi quốc gia, mỗi ngành, nghề và lĩnh vực hoạt động của nền kinh tế. Trong quá trình phát triển Chính phủ điện tử (E-Government) của các quốc gia trên thế giới và Việt Nam cũng không là ngoại lệ, đặc biệt, trong bối cảnh đại dịch Covid-19 đã tạo ra thách thức lớn, đồng thời cũng là cơ hội thúc đẩy mạnh mẽ hơn việc chuyển đổi số.

Đối với hoạt động của IB, chuyển đổi số cũng là một mục tiêu và được định hướng phát triển trên tất cả các mặt hoạt động kinh doanh của IB nhằm triển khai quyết liệt các Nghị quyết của Đảng, Chính phủ về công nghệ số, chuyển đổi số, góp phần nâng cao chất lượng, hiệu quả, đóng góp vào nền kinh tế số nói chung của Việt Nam.

Là đơn vị với chức năng tham mưu xây dựng và duy trì hệ thống kiểm soát nội bộ, thực hiện kiểm toán nội bộ các hoạt động của IB, những năm vừa qua, cùng với xu thế hội nhập và tăng cường ứng dụng công nghệ trong hoạt động nghiệp vụ, kiểm toán nội bộ, IB cũng đã có những định hướng và triển khai các giải pháp cụ thể về ứng dụng công nghệ số và kiểm toán việc ứng dụng công nghệ số tại IB. Trên cơ sở đó, đưa ra mục tiêu, định hướng đối với kiểm toán nội bộ trong chiến lược chuyển đổi số của IB để hoàn thành sứ mệnh “đảm bảo” và “gia tăng giá trị” vào hiệu quả hoạt động của IB.

1. Chuyển đổi số và tác động của chuyển đổi số đối với hoạt động kiểm toán nội bộ

Công nghệ số, chuyển đổi số đã và đang làm thay đổi về phương pháp, cách thức triển khai thực hiện hoạt động kiểm toán nói chung và kiểm toán nội bộ nói riêng. Kiểm toán 4.0 sẽ dựa trên công nghệ được thúc đẩy bởi sự phát triển của CMCN 4.0 để thu thập thông tin tài chính, phi tài chính và phân tích, mô hình hóa nhằm mục đích cung cấp sự đảm bảo một cách có hiệu quả. Với việc ứng dụng công nghệ đã giúp nâng cao khả năng tự động hóa các thủ tục kiểm toán, mở rộng phạm vi kiểm toán, rút ngắn thời gian thực hiện và cuối cùng là cải thiện chất lượng kiểm toán; đồng thời, làm thay đổi tiêu chuẩn, nguyên tắc, công nghệ và nhận thức của kiểm toán viên. Đặc biệt, công nghệ số, chuyển đổi số cũng là nhân tố làm thay đổi môi trường, bối cảnh phát sinh rủi ro, các loại rủi ro cũng như việc tác động đến hành vi điều chỉnh nguồn lực để thực hiện kiểm toán đối với các rủi ro này.

Theo nghiên cứu được thực hiện bởi Viện Kiểm toán nội bộ quốc tế và Tổ chức kiểm toán nội bộ trong năm 2021 về yêu cầu chuyển đổi số trong kiểm toán - thích ứng trước khủng hoảng nhằm đánh giá tác động của dịch bệnh Covid - 19 đối với hoạt động kiểm toán, trong đó tập trung vào câu hỏi việc ứng dụng công nghệ hỗ trợ thực hiện kiểm toán đang diễn ra như thế nào, 47% các đơn vị tham gia điều tra đã sử dụng phần mềm quản lý kiểm toán hoặc quản trị, rủi ro và tuân thủ (GRC) trước ngày 01/01/2020 và 22% lập kế hoạch triển khai phần mềm quản lý kiểm toán hoặc GRC vào năm 2021 cho thấy, sự chuyển đổi số đã được kiểm toán nội bộ ngày càng coi trọng. Bên cạnh việc ứng dụng phần mềm quản lý kiểm toán, là sự dịch chuyển sang các giải pháp về điện toán đám mây đối với hoạt động lưu trữ, quản lý thông tin phục vụ kiểm toán.

Theo Chuẩn mực kiểm toán nội bộ quốc tế (IIA) số 1210.A3: "Kiểm toán viên nội bộ phải có đủ kiến thức về các rủi ro và kiểm soát quan trọng liên quan đến công nghệ thông tin cũng như các kỹ thuật kiểm toán dựa trên công nghệ có sẵn để thực hiện công việc được giao". Vì vậy, rõ ràng, việc được trang bị và cập nhật kiến thức về công nghệ 4.0, về phân tích dữ liệu, về chuyển đổi số là những điều kiện cần thiết của kiểm toán 4.0.

Theo nghiên cứu của Haassan và các đồng sự (2021), chuyển đổi số đã ảnh hưởng đến kiểm toán nội bộ theo nhiều cách, cụ thể như sau: (1) Lập kế hoạch kiểm toán nội bộ: Cần xem xét các yếu tố về công nghệ, kết nối, tự động. (2) Kỹ năng kiểm toán: Những kỹ năng quan trọng hơn trong kỷ nguyên kỹ thuật số cần được trang bị cho kiểm toán viên, gồm: Thuyết trình, thông tin kỹ thuật số, kỹ năng phân tích dữ liệu nâng cao. (3) Phương pháp kiểm toán nội bộ thay đổi theo hướng: Chia sẻ dữ liệu: Sử dụng các công cụ như Microsoft SharePoint cho phép chia sẻ tài liệu trong bản trình bày ảo và thông tin, dữ liệu được lưu trữ bằng điện toán đám mây. Phân tích: Kỹ năng phân tích thông tin, dữ liệu sẽ trở nên cần thiết và quan trọng hơn, không chỉ phân tích dữ liệu tài chính; Công bố kết quả kiểm toán: Sử dụng PowerPoint và các công cụ kỹ thuật để trình bày và truyền đạt kết quả kiểm toán. (4) Chi phí kiểm toán: Chuyển đổi số trong kiểm toán nội bộ cũng có thể góp phần giảm chi phí kiểm toán, thông qua quy trình tự động hóa, giúp tiết kiệm các chi phí in ấn hay góp phần giảm thời gian thực hiện kiểm toán tại đơn vị khi công tác thu thập kiểm soát thông tin, dữ liệu nội bộ được thực hiện từ xa dễ dàng hơn. Rõ ràng, chuyển đổi số trong CMCN 4.0 đã tác động đến các mặt hoạt động kiểm toán nội bộ trên cả cách thức thực hiện, các loại rủi ro cần quan tâm, nội dung kiểm toán và cả cách thức truyền đạt kết quả kiểm toán.

2. Mục tiêu, định hướng của kiểm toán nội bộ của IB trong thực hiện Kế hoạch chuyển đổi số

Bằng cách trả lời hai câu hỏi: “Bằng cách nào kiểm toán nội bộ có thể hỗ trợ quá trình chuyển đổi số cho tổ chức của mình?” và “Kiểm toán nội bộ thực hiện chuyển đổi số như thế nào?”, kiểm toán nội bộ NHNN đang tiếp tục xây dựng chiến lược chuyển đổi số nhằm thúc đẩy sự phát triển của chính mình và đóng góp tích cực hơn cho quá trình chuyển đổi số tại NHNN, cụ thể:

2.1 Tập trung đào tạo kỹ năng 4.0 cho người làm công tác kiểm toán nội bộ. Thực hiện chuyển đổi số và nâng cao kỹ năng về sử dụng công nghệ trong các hoạt động nghiệp vụ cho đội ngũ nhân viên kiểm toán/người làm công tác kiểm toán nội bộ là một trong những mục tiêu lớn trong Kế hoạch chuyển đổi số của IB. Đối với kiểm toán viên nội bộ, những kỹ năng về phân tích dữ liệu nâng cao, công nghệ 4.0 và các công nghệ mới trong lĩnh vực tài chính số và kỹ năng phân tích rủi ro công nghệ là những vấn đề rất cần được quan tâm đào tạo, tạo điều kiện để kiểm toán viên nội bộ có thể vận hành thuần thục các phần mềm nghiệp vụ, làm chủ công nghệ để có thể khai thác, sử dụng trong quá trình thu thập thông tin, phân tích, đánh giá bằng chứng kiểm toán, nâng cao hiệu suất làm việc với độ chính xác, tin cậy cao, đồng thời là cơ sở tiến tới thực hiện kiểm toán từ xa và kiểm toán, đánh giá rủi ro ứng dụng công nghệ hiệu quả.

2.2 Coi trọng đánh giá rủi ro công nghệ và tăng cường công tác kiểm toán công nghệ thông tin, công nghệ cao và kiểm toán Fintech

Chuyển đổi số đang diễn ra mạnh mẽ trong các hoạt động nghiệp vụ của IB xuất phát từ yêu cầu nội tại trong hoạt động quản lý của IB và Chính phủ điện tử, gồm xử lý văn bản hành chính, chỉ đạo điều hành; thông tin báo cáo; thanh toán điện tử; thị trường tiền tệ, quản lý dự trữ ngoại hối, phát hành và lưu thông tiền tệ... Chuyển đổi kỹ thuật số đã mở ra cơ hội mới để kiểm toán công nghệ thông tin đóng một vai trò lớn, tích cực, quan trọng hơn nữa trong chiến lược kiểm toán của IB.

Chuyển đổi số, công nghệ số trước hết đặt ra rất nhiều những thay đổi trong các quy định về Chính phủ điện tử, chuyển đổi số, an toàn thông tin và đòi hỏi phải được triển khai, tuân thủ nghiêm túc: Luật An ninh mạng; Luật An toàn thông tin mạng; ứng dụng công nghệ thông tin trong cơ quan nhà nước; xây dựng chính phủ điện tử; Nghị định về quản lý, kết nối và chia sẻ dữ liệu số của cơ quan nhà nước; kế hoạch ứng dụng công nghệ thông tin, chuyển đổi số của IB…

Do đó, chuyển đổi số đã đặt ra thách thức lớn đối với chức năng của kiểm toán nội bộ cho Ban Lãnh đạo IB trong việc bảo đảm các quy định, chiến lược, kế hoạch được triển khai thực hiện nghiêm túc, đầy đủ, đúng hạn; bảo đảm các giải pháp an ninh bảo mật, chống lại nguy cơ tấn công mạng, ăn cắp thông tin, gián đoạn hệ thống được triển khai đầy đủ.

Chính vì vậy, kiểm toán công nghệ thông tin tại IB đã được ưu tiên tập trung nguồn lực nhằm đảm bảo tính an toàn, bảo mật cho quá trình chuyển đổi số tại IB, bao gồm: (1) Cập nhật thường xuyên các quy định, chiến lược, kế hoạch mới để thiết kế nội dung kiểm toán ứng dụng công nghệ thông tin có trọng tâm, trọng điểm. (2) Kiểm toán việc xây dựng và phân loại hệ thống thông tin nghiệp vụ theo các cấp độ quan trọng; các kế hoạch bảo đảm an toàn thông tin theo cấp độ được cập nhật, bổ sung liên tục. (3) Kiểm toán tính liên tục, sao lưu và phục hồi dữ liệu của các hệ thống thông tin quan trọng: Thanh toán điện tử, hệ thống ngân hàng lõi, thị trường tiền tệ. (4) Kiểm toán việc triển khai diễn tập trên hệ thống của IB. (5) Kiểm toán an toàn bảo mật từ phía người dùng cuối cùng: Rà soát cung cấp tài khoản định danh và quyền truy cập vào các phần mềm nghiệp vụ đúng nhiệm vụ được giao; cài đặt phần mềm chống mã độc; cập nhật các bản vá lỗi phần mềm; an toàn mã khóa bảo mật khi sử dụng phần mềm nghiệp vụ; tách biệt phần mềm nghiệp vụ cấp độ cao với mạng Internet. (6) Kiểm toán tính an toàn bảo mật của bên thứ ba khi cung cấp hàng hóa, dịch vụ công nghệ thông tin cho IB. (7) Lựa chọn đưa vào kế hoạch hằng năm để kiểm toán các dự án chuyển đổi số quan trọng như: Trang bị hệ thống an ninh bảo mật, bảo trì bảo đảm tính liên tục cho hệ thống thông tin quan trọng.

Tuy nhiên, những thách thức về nhân sự kiểm toán công nghệ cao, về sự xuất hiện của các công nghệ mới ở nhiều lĩnh vực trong hoạt động của IB cũng như các rủi ro công nghệ mới xuất hiện đã đặt ra bài toán chiến lược, đòi hỏi định hướng về đào tạo nhân sự thực hiện kiểm toán công nghệ cao, coi trọng việc đánh giá rủi ro công nghệ cao và việc phân bổ nguồn lực cho thực hiện kiểm toán các dự án chuyển đổi số quan trọng tại IB là những định hướng chiến lược của IB.

2.3 Tăng cường ứng dụng công nghệ trong hoạt động kiểm toán nội bộ

Hiện nay, việc ứng dụng công nghệ thông tin trong quản lý hoạt động kiểm toán nội bộ của IB được thực hiện trên nhiều khía cạnh: Việc tiếp nhận, xử lý thông tin qua hệ thống quản lý văn bản điều hành (Edoc); việc khai thác, theo dõi, giám sát thông tin phục vụ kiểm toán qua các hệ thống thông tin, phần mềm nghiệp vụ được triển khai tại IB (chứng khoán, quỹ, dược phẩm và bất động sản...); việc thực hiện kiểm toán tự động trên phần mềm quản trị kiểm toán TeamMate chuyên dùng cho kiểm toán. Thực tế, việc ứng dụng công nghệ vào kiểm toán nội bộ tại IB bắt đầu triển khai.

II. KIỂM TOÁN HỆ THỐNG THÔNG TIN KẾ TOÁN VÀ BÁO CÁO TÀI CHÍNH

Khái niệm/giải thích từ ngữ về lĩnh vực kiểm toán HTTT

HTTT là một cấu trúc có tổ chức chứa thông tin, bao gồm các thành phần như phần cứng, phần mềm, dữ liệu, quy trình và con người. HTTT được thiết kế để thu thập, lưu trữ, xử lý và truyền tải thông tin.

1.1 HTTT kế toán (Accounting Information System): HTTT kế toán không chỉ có các phần mềm kế toán như Misa, Fast mà còn có các phần mềm liên quan nhằm phục vụ cho bộ phận kế toán tài chính trong IB. Theo Trang, 2023, hệ thống AIS bao gồm "tài liệu, số liệu tài chính kế toán. Các loại thông tin thường gặp nhất là: (1) Bảng chấm công nhân viên ; (2) Thông tin thuế lưu trữ ;(3) Đơn đề nghị, hóa đơn mua và bán hàng;(4) Báo cáo thanh toán của KH, đối tác; (5) Dữ liệu kiểm kê hàng hóa. Các loại dữ liệu này tồn tại trong hệ thống bằng các đoạn mã hóa tương tự như ngôn ngữ truy vấn cấu trúc SQL. Sau khi truy xuất tại đầu ra, kế toán viên có thể sử dụng để hoàn thiện BCTC, bảng tiền lương… "

Kiểm toán CNTT là quá trình đánh giá và đảm bảo tính hiệu quả của các HTTT và quản lý rủi ro liên quan đến việc sử dụng CNTT trong tổ chức. Nó bao gồm việc đánh giá tính hợp lệ của dữ liệu, bảo mật, sự phân tán, khả năng sẵn sàng và tính đúng đắn của hệ thống.

Big Data là thuật ngữ dùng để miêu tả khối lượng lớn dữ liệu cấu trúc và không cấu trúc, được tạo ra từ nhiều nguồn khác nhau và trong một tốc độ khá nhanh. Nó thường đòi hỏi sự phân tích và xử lý bằng các công nghệ và phương pháp tiên tiến để khai thác ra thông tin hữu ích.

1.2 Sự khác biệt lớn nhất giữa dữ liệu lớn và dữ liệu thông thường, chúng ta cần sơ lược qua dữ liệu cấu trúc và phi cấu trúc. Song hành với khả năng chưa từng thấy của dữ liệu lớn trong kinh doanh thì những thông tin họ bí mật thu thập từ KH bắt đầu được đưa vào vòng nghi vấn: Với khối lượng dữ liệu lớn cùng tính chất nhạy cảm của các dữ liệu thu được như thông tin cá nhân, địa chỉ,v..v.. các nhà quản lý có đang thực hiện các công tác phù hợp để bảo vệ HTTT trước các rủi ro tiềm tàng như đánh cắp dữ liệu, hacker, rò rỉ dữ liệu, và hơn hết chính là bảo vệ chính các KH của mình.

Ví dụ về dữ liệu có cấu trúc bao gồm ngày, tên, địa chỉ, số thẻ tín dụng, v.v. Lợi ích của chúng gắn liền với tính dễ sử dụng và truy cập, trong khi điểm yếu của nó là dữ liệu không linh hoạt. Nói ngắn gọn, dữ liệu cấu trúc là các dữ liệu mà bạn có thể dễ phân loại được nó. Giả sử đối với dữ liệu "Nguyễn Văn A - 16 tuổi - Sinh viên”. Dữ liệu này cung cấp rõ ràng các thông tin về Họ tên, Tuổi, Nghề nghiệp của mẫu nghiên cứu.

Ví dụ về dữ liệu phi cấu trúc bao gồm văn bản, hoạt động trên thiết bị di động, bài đăng trên mạng xã hội, dữ liệu cảm biến Internet of Things (IoT), v.v. Lợi ích của chúng liên quan đến lợi thế về định dạng, tốc độ và dung lượng lưu trữ. Hầu hết những dữ liệu này chúng ta khó có thể phân loại nó dưới dạng bảng vì mỗi mẫu có một đặc điểm khác nhau, ví dụ như trong hàng ngàn comment trên mạng xã hội, chúng ta sẽ khó phân loại nó để phục vụ cho quá trình phân tích dưới dạng dữ liệu thô mà phải tìm cách để biến đổi dữ liệu về cùng một dạng để sử dụng. Qua đó ta thấy, dữ liệu phi cấu trúc là các loại dữ liệu mà không tuân theo cấu trúc dữ liệu truyền thống, ví dụ như dữ liệu văn bản, email, hình ảnh, video, âm thanh, tài liệu PDF, dữ liệu mạng xã hội, dữ liệu IoT (Internet of Things), vv. Big Data –bao gồm cả dữ liệu phi cấu trúc và dữ liệu có cấu trúc, thường không thể được lưu trữ trong các cơ sở dữ liệu quan hệ truyền thống và cần các công nghệ khác như NoSQL hoặc Hadoop để quản lý và xử lý.

Giả sử với dữ liệu là một "Trạng thái” (Status): "Hôm nay là một ngày đẹp trời” được đăng bởi anh A ngày #/#/####, chúng ta sẽ không phân loại được nó theo cách truyền thống như với các dữ liệu dạng bảng. Còn với dữ liệu được ví dụ ở phần dữ liệu cấu trúc, ta có thể dễ dàng phân loại được dữ liệu này đưa cho ta thông tin gì.

Nắm bắt được sự bành trướng của dữ liệu phi cấu trúc đi lên cùng với sự phát triển của mạng xã hội, các DN đã chi ra hàng chục nghìn đô để mua các HTTT lớn như Oracle, MySQL hay phổ biến nhất hiện nay là SAP để lưu trữ các thông tin này. Kết quả là chúng ta sẽ thấy khi chúng ta search trên google về một bữa tiệc thì tất cả các trang web bắt đầu đề xuất các sản phẩm thời trang, làm đẹp, khi ta di chuyển tới vùng ôn đới thì các dữ liệu địa lý này giúp các nhà kinh doanh áo ấm quảng cáo sản phẩm của mình vì họ biết là chúng ta là một KH tiềm năng của họ trong thời điểm đó, với dữ liệu địa lý đó.

A. KIỂM TOÁN CÔNG NGHỆ THÔNG TI

Kiểm toán công nghệ thông tin (KT CNTT) đóng vai trò quan trọng trong việc bảo vệ người dùng. Khi các tổ chức sử dụng các hệ thống thông tin (HTTT) và dữ liệu, chúng ta cần đảm bảo rằng, chúng đáp ứng được các yêu cầu về bảo mật, tính toàn vẹn và sẵn sàng sử dụng. KT CNTT giúp đảm bảo rằng, các hệ thống và dữ liệu được bảo vệ đúng cách, các thông tin và dữ liệu quan trọng không bị thất lạc hoặc bị tấn công và hệ thống sẵn sàng sử dụng được khi cần thiết

FSCP là viết tắt của "Financial Statement Closing Process" - quá trình lên BCTC, đây là một quá trình quan trọng trong chu kỳ kế toán của một IB. Trong quá trình này, các thông tin tài chính được thu thập, phân tích và xử lý để tạo ra BCTC của IB.

1. Theo ISA 330, các quy định và hướng dẫn được đưa ra về việc

lập kế hoạch và thực hiện các thủ tục kiểm toán, ở bước lập kế hoạch kiểm toán, kiểm toán viên cần lập kế hoạch kiểm toán bằng cách xác định mức độ rủi ro của công việc kiểm toán, định hình phạm vi kiểm toán, đánh giá tài chính, và xác định các lớp giao dịch quan trọng (SCOTs) cần được kiểm tra. Tiếp đó theo ISA 315, những lớp giao dịch này cần được xác định dựa trên đánh giá của kiểm toán viên về tính quan trọng của chúng đối với BCTC, cũng như mức độ rủi ro liên quan đến chúng. Vì vậy công việc này sẽ được thực hiện bởi đội kiểm toán BCTC.

Để xác định SCOT, kiểm toán viên thường sử dụng các phương pháp và tiêu chuẩn kiểm toán để đánh giá các lớp giao dịch trong hệ thống tài chính của IB. Nếu sau quá trình kiểm tra, kiểm toán viên phát hiện ra các sai sót hoặc bất thường trong các lớp giao dịch quan trọng, họ sẽ đánh giá tính hiệu quả các biện pháp kiểm soát và đưa ra các khuyến nghị để cải thiện quy trình và chính sách của IB.

Phân tích hệ thống tài chính của DN: Kiểm toán viên phải tìm hiểu cách thức hoạt động của hệ thống tài chính của DN, bao gồm các quy trình, chính sách, thủ tục, các phần mềm hỗ trợ, hồ sơ giao dịch và các tài liệu liên quan. 2. Xác định các lớp giao dịch quan trọng: Kiểm toán viên phải xác định các lớp giao dịch quan trọng nhất, được thực hiện bởi DN. Các lớp giao dịch này thường liên quan đến những khoản chi phí và thu nhập lớn, những giao dịch đặc biệt hoặc các giao dịch có rủi ro cao.

Xác định tần suất và phạm vi kiểm tra: Sau khi xác định các lớp giao dịch quan trọng, kiểm toán viên sẽ xác định tần suất và phạm vi kiểm tra cho mỗi lớp giao dịch này. Tần suất và phạm vi kiểm tra phụ thuộc vào mức độ quan trọng và rủi ro của mỗi lớp giao dịch.

Giả sử kiểm toán viên đang thực hiện kiểm toán cho một công ty sản xuất, với một lớp giao dịch quan trọng là "Chi phí sản xuất". Để xác định SCOT, kiểm toán viên sẽ thực hiện các bước sau: (1) Phân tích hệ thống tài chính của công ty, bao gồm quy trình sản xuất, chính sách chi phí, hồ sơ giao dịch và các tài liệu liên quan. (2) Xác định lớp giao dịch quan trọng - SCOT là "Chi phí sản xuất", bao gồm các chi phí như nguyên vật liệu, nhân công, máy móc và thiết bị sản xuất. (3) Xác định tần suất và phạm vi kiểm tra cho SCOT "Chi phí sản xuất", phụ thuộc vào mức độ quan trọng và rủi ro của từng loại chi phí. Ví dụ, kiểm toán viên có thể quyết định kiểm tra toàn bộ hồ sơ cho chi phí nguyên vật liệu, kiểm tra chứng từ liên quan đến chi phí nhân công và kiểm tra các hợp đồng mua bán máy móc và thiết bị sản xuất để đảm bảo tính chính xác và đầy đủ của thông tin tài chính được báo cáo.

2. Vai trò của CNTT trong hoạt động kinh doanh

CNTT làm cơ sở cho hoạt động kinh doanh và tài chính dưới nhiều hình thức khác nhau, từ việc sử dụng các công cụ như Microsoft Excel đến viêc sử dụng các ứng dụng CNTT phức tạp hơn, được lập trình sẵn nhưng IB có thể cấu hình lại theo ý mình, chẳng hạn như phần mềm SAP. Ngoài ra, còn có các phần mềm IB có thể mua theo các thiết lập có sẵn của bên cung cấp, hoặc có thể tuỳ chỉnh các cài đặt cho phù hợp với nhu cầu sử dụng của IB mình. Từ bước này, kiểm toán CNTT phân tích HTTT của IB để làm căn cứ đưa ra quyết định chiến lược kiểm toán phù hợp. Theo đó, có các mô hình tổ chức HTT như sau: (1) IB sử dụng hoàn toàn các thiết lập từ nhà cung cấp và các thay đổi kiểm soát bởi nhà cung cấp thì kiểm toán CNTT phải thu thập dữ liệu từ nhà cung cấp HTTT cho KH, không phải từ bộ phận IT của KH. (2) IB tự thiết lập các cài đặt của mình, kiểm toán CNTT sẽ tiến hành phỏng vấn bộ phận IT của IB KH cũng như kiểm tra các kiểm soát mà KH đang có trên hệ thống của họ. (3) IB sử dụng cả thiết lập từ nhà cung cấp (thuê ngoài) và có bộ phận IT riêng, KT CNTT tiến hành đánh dấu các kiểm soát được thực hiện ở bộ phận IT thuê ngoài và bộ phận IT nội bộ để thực hiện các thủ tục kiểm soát phù hợp và phỏng vấn đúng nhân sự chịu trách nhiệm cho từng kiểm soát (PIC – Person in charge).

3. Vai trò của Big Data trong kiểm toán CNTT

Việc bốc mẫu dựa trên các dữ liệu IB cung cấp tiềm ẩn rủi ro dữ liệu bị chỉnh sửa, vì vậy, kiểm toán CNTT sẽ thực hiện bốc mẫu và kiểm tra trên chính dữ liệu thô lấy từ tầng database. INTOSAI (International Organization of Supreme

Audit Institutions - Tổ chức Quốc tế của Các Cơ quan Kiểm toán Tối cao) đã đưa ra kết luận trong báo cáo "Development Overview of Big Data Audits from 2016 to 2021" (Tổng quan về việc sự phát triển trong việc kiểm toán Big Data từ năm 2016 - 2021) rằng việc kiểm toán trên Big Data, thay vì các dữ liệu từ tầng ứng dụng như truyền thống, giúp cho kiểm toán CNTT có cái nhìn tổng quan về hệ thống kiểm soát nội bộ của doanh nghiệp. Nhờ công tác thực hiện kiểm toán trên dữ liệu thô, INTOSAI đã rút ra được các thống kê có giá trị như sau: (1) Độ chính xác thấp của dữ liệu thu thập và độ trễ dữ liệu lớn (tốc độ tải dữ liệu kém).(2) Kỹ thuật không đủ và thiếu sự chú trọng vào việc thiết lập nền tảng dữ liệu(3) Mô hình chia sẻ dữ liệu không hoàn thiện, nhà quản lý chưa đáp ứng đầy đủ. (4) Việc kiểm toán Big Data chưa hiệu quả trong việc nâng cao tính đáng tin cậy và dự đoán rủi ro.

Với các insightii mà INTOSAI đã đưa ra, chúng ta sẽ cùng phân tích một cuộc kiểm toán CNTT cho một IB có thu thập Big Data để phục vụ cho hoạt động sản xuất kinh doanh để đối chiếu và rút ra những điểm giống và khác, từ đó, đưa ra các giải pháp từ góc nhìn của KT CNTT để cải thiện hiệu quả kiểm soát và nâng cao chất lượng KT CNTT.

KT CNTT cũng đóng vai trò quan trọng trong việc đảm bảo rằng các tổ chức tuân thủ các quy định pháp lý liên quan đến việc sử dụng và bảo mật dữ liệu. Việc sử dụng dịch vụ công nghệ thông tin cũng đang trở nên phổ biến hơn bao giờ hết, đồng thời cũng tăng cao nguy cơ về bảo mật thông tin. Vì vậy, KT CNTT đóng vai trò quan trọng trong việc đảm bảo rằng các dịch vụ công nghệ thông tin được cung cấp với mức độ an toàn và đảm bảo cao nhất, giúp bảo vệ người dùng khỏi các mối đe dọa mạng và tấn công từ các kẻ tấn công trên mạng.

4. Hệ thống thông tin và các thành phần CNTT

Mối quan hệ giữa hoạt động quản lý, tác nghiệp và HTTT: HTTT bao gồm con người, các quy trình và thiết bị CNTT tương tác với nhau để thu thập, xử lý, lưu trữ dữ liệu và cung cấp thông tin cho người sử dụng liên quan.

Ví dụ sau đây sẽ làm rõ về mối quan hệ giữa hoạt động quản lý, tác nghiệp và HTTT:

Qua quy trình điển hình cách HTTT tham gia vào quy trình hoạt động kinh doanh trên, chúng ta thấy những phần có tương tác với HTTT, đây mới là những phần mà sẽ được KT CNTT thu thập bằng chứng và kiểm tra. Cụ thể là ở các bước (2), (3), (4), (5), (6), (8), (9), (10).

5. Môi trường CNTT

Môi trường CNTT bao gồm ba khái niệm chính: môi trường thực, môi trường phát triển ứng dụng và môi trường kiểm thử ứng dụng: (1) Môi trường thực là bao gồm phần cứng và phần mềm mà người dùng sử dụng để thực hiện các tác vụ trong hệ thống; (2) Môi trường phát triển ứng dụng là môi trường để lập trình viên phát triển các ứng dụng phần mềm; (3) Môi trường kiểm thử ứng dụng là môi trường để kiểm tra, đánh giá và xác nhận tính đúng đắn của ứng dụng phần mềm trước khi được triển khai vào môi trường thực.

Trong kỹ thuật phần mềm, thuật ngữ "môi trường CNTT" đề cập đến các thành phần phần cứng, phần mềm và mạng lưới khác nhau cần thiết để hệ thống công nghệ thông tin hoạt động. Điều này bao gồm môi trường thực, bao gồm các máy tính và các thiết bị vật lý khác, cùng với môi trường phát triển và môi trường kiểm thử, đó là các công cụ và nền tảng phần mềm cho phép các nhà phát triển tạo ra và kiểm thử các ứng dụng phần mềm. Môi trường phát triển cung cấp các công cụ và tài nguyên cần thiết cho lập trình viên để viết và biên dịch mã nguồn phần mềm, trong khi môi trường kiểm thử cung cấp các công cụ để kiểm thử và gỡ lỗi mã nguồn phần mềm." (Trần & Nguyễn, 2018)

6. Thành phần môi trường CNTT

Trước khi tìm hiểu thành phần môi trường CNTT, chúng ta phải nắm rõ khái niệm về phần mềm và phần mềm con - hay còn gọi với thuật ngữ phần mềm thành phần. Phần lớn trong các DN, một phần mềm lớn không hoàn toàn sản xuất ra các thông tin sử dụng cho BCTC. Bên cạnh đó để sử dụng hiệu quả nguồn lực hữu hạn của cuộc kiểm toán (thời gian, nhân sự), phạm vi kiểm toán CNTT tại IB nhúng vào quy trình sẽ chỉ nằm trong các phần mềm con và các thành phần quan trọng, rủi ro cao có liên quan tới các lớp giao dịch quan trọng (Significant Classifications Of. Transactions - SCOTs) và các quy trình để đóng sổ và lên BCTC (Financial Statement Closing Process - FCSP).

Môi trường CNTT có rất nhiều phần mềm thành phần, một phần mềm sẽ bao gồm có mã nguồn đóng vai trò là những dòng code để hướng dẫn máy tính làm theo, logo, hướng dẫn sử dụng và thư viện. Phần mềm thành phần có nghĩa là những phần mềm con trong một phần mềm lớn, nó đóng vai trò thực hiện những nhiệm vụ nhỏ hơn trong một phần mềm lớn phức tạp hơn. Giả sử về vai trò của phần mềm thành phần như sau:

Trong ngành tài chính ngân hàng, một phần mềm lớn có thể là hệ thống quản lý ngân hàng (core banking system), và một phần mềm con trong hệ thống này có thể là phần mềm quản lý tài sản (asset management software). Phần mềm quản lý tài sản có chức năng giúp ngân hàng quản lý và theo dõi các tài sản của KH, từ đó có thể đưa ra các quyết định về đầu tư, rủi ro và lợi nhuận. Phần mềm này có thể được tích hợp vào hệ thống quản lý ngân hàng và sử dụng chung một cơ sở dữ liệu để đảm bảo tính toàn vẹn và độ chính xác của thông tin.

Những thành phần môi trường CNTT quan trọng trong một cuộc kiểm toán gồm có:

Ứng dụng CNTT: Giúp người dùng trực tiếp thực hiện nhiệm vụ nào đó, ví dụ như trình duyệt web, trò chơi.

IT Application là một loại phần mềm được thiết kế để giải quyết các vấn đề kinh doanh thông qua sử dụng công nghệ thông tin. IT application bao gồm các chức năng khác nhau như quản lý dữ liệu, xử lý và phân tích dữ liệu, và cung cấp thông tin đến người dùng cuối. Nó được sử dụng rộng rãi trong các lĩnh vực như tài chính, bán lẻ, y tế, giáo dục và sản xuất (Rahayu & Widjaja, 2018).

Cơ sở dữ liệu - Database: DB là tập hợp các dữ liệu 1 cách có tổ chức, được lưu trữ trên máy chủ. Theo Friedman và Smale (2015), "DB là một tập hợp các dữ liệu có tổ chức được lưu trữ trong một hoặc nhiều máy chủ, cho phép các ứng dụng và người dùng truy xuất và thao tác trên chúng thông qua các giao thức cụ thể.”

Hệ điều hành - Operating System: Theo bài báo của Liu và cộng sự (2018), OS đóng vai trò quan trọng trong việc quản lý các tài nguyên phần cứng của máy tính như bộ nhớ, bộ xử lý, ổ đĩa cứng, và các thiết bị ngoại vi khác. Nó cũng cung cấp các dịch vụ cho các chương trình ứng dụng khác để truy cập tài nguyên phần cứng và tương tác với người dùng. Ta có thể hiểu đơn giản OS là một trung gian cầu nối giữa phần cứng và phần mềm, chúng giúp phần cứng và phần mềm có thể tương tác với nhau và đáp ứng các yêu cầu của người sử dụng.

Phần mềm mạng - Network Software - giúp tăng cường tính bảo mật, hiệu quả hoạt động, và quản lý hệ thống mạng một cách nhanh chóng và thuận tiện hơn.

Network software là một loại phần mềm được sử dụng để điều khiển và quản lý các kết nối mạng. Nó bao gồm nhiều thành phần khác nhau như phần mềm định tuyến, phần mềm tường lửa, phần mềm giám sát mạng, phần mềm quản lý và phân phối tài nguyên, và nhiều ứng dụng khác. Sử dụng network software có thể giúp tăng cường hiệu suất mạng, bảo mật hệ thống, và quản lý tài nguyên mạng một cách hiệu quả.

B. TỔNG QUAN VỀ QUY TRÌNH QUẢN LÝ THAY ĐỔI

Việc tìm hiểu các quy trình CNTT của thực thể quản lý các thay đổi chương trình (chẳng hạn như sửa lỗi hoặc thực hiện việc cải thiện hệ thống) đối với các ứng dụng CNTT liên quan đến SCOTS và FSCP giúp kiểm toán CNTT hiểu được rủi ro của việc thay đổi chương trình trái phép hoặc không phù hợp.

Đối với các loại thay đổi tạo nên rủi ro cho DN, nó có thể gây ra hậu quả là các ứng dụng CNTT sẽ xử lý dữ liệu sai cách đối với các dữ liệu thuộc SCOT và FSCP. Vì vậy, kiểm toán CNTT phải tìm hiểu các quy trình mà DN xây dựng để kiểm soát rủi ro từ các loại thay đổi lên chương trình ứng dụng như sau: (1) Phát triển hoặc mua lại chương trình - phát triển và triển khai CNTT cho ứng dụng, công cụ mới hoặc giao diện cho các ứng dụng CNTT. (2) Thay đổi chương trình - những thay đổi được thực hiện đối với ứng dụng CNTT, báo cáo được tạo bằng phần mềm viết báo cáo, công cụ (khi được kiểm soát bởi bộ phận CNTT) hoặc giao diện, bất kể nơi lưu trữ chương trình nào, v.v... (3) Thay đổi cấu hình tuân theo quy trình quản lý thay đổi - Cấu hình ảnh hưởng đến cách một ứng dụng hoặc công cụ xử lý thông tin hoặc hỗ trợ các chức năng CNTT có liên quan và các tính năng nào được kích hoạt.

1. Tổng quan về quy trình quản lý truy cập

Ở quy trình kiểm toán cho kiểm soát này, kiểm toán CNTT phải tìm hiểu cách một DN quản lý truy cập cho các thành phần môi trường CNTT để bổ trợ cho sự duy trì tính trung thực của dữ liệu sử dụng cho các lớp giao dịch quan trọng và quá trình đóng sổ kế toán.

Các khía cạnh quan trọng trong quản lý quyền truy cập là: (1) Cách DN thiết lập và duy trì cài đặt bảo mật cho quyền truy cập phù hợp đối với các thành phần môi trường CNTT liên quan tới cuộc kiểm toán. (2) Cách thực thể quản lý việc cho phép và quản lý quyền truy cập vào các ứng dụng CNTT và các thành phần CNTT liên quan.

Quy trình và cơ chế cấp quyền - authentication được sử dụng để xác định liệu một cá nhân hoặc dịch vụ CNTT đang cố gắng truy cập vào môi trường CNTT được phê duyệt quyền truy cập đó trước khi truy cập vào môi trường CNTT của DN.

Việc truy cập đó có thể là đang cố gắng truy cập vào : (1) Ứng dụng CNTT và dữ liệu trong ứng dụng. (2) Các cơ sở dữ liệu khác (bao gồm data warehouse - kho lưu trữ dữ liệu được sử dụng cho việc phân tích và lên báo cáo). (3) Cài đặt bảo mật hoặc thông tin định danh người dùng, các phần mềm và thông tin liên quan đến mạng máy tính (các phần mềm quản lý mạng, phần mềm bảo mật mạng, thông tin về cấu trúc mạng, các thông tin đăng nhập cho người dùng truy cập vào mạng, các thông tin kết nối mạng, v.v.) (4) Hệ điều hành. (5) Các thành phần CNTT khác.

Access path (tạm dịch: lộ trình truy cập) trong kiểm toán CNTT là quy trình truy cập mà người dùng sử dụng để đăng nhập và truy cập vào hệ thống của DN. Đây thường là quá trình đăng nhập vào mạng của DN và sau đó đăng nhập vào ứng dụng, cơ sở dữ liệu hoặc hệ điều hành. Người dùng thường phải nhập các thông tin xác thực như tên đăng nhập và mật khẩu để tiếp cận các tài nguyên này.

Access path bắt đầu từ bước: (1) Người dùng nhập ID người dùng và mật khẩu để xác thực vào mạng của đơn vị; (2) Người dùng nhập ID người dùng và mật khẩu riêng biệt để xác thực vào ứng dụng, cơ sở dữ liệu hoặc hệ điều hành.

Việc sử dụng mã thông báo phần mềm hoặc thiết bị mã thông báo (ví dụ: SecureID, PingID) đang trở nên phổ biến hơn, đôi khi kết hợp với mật khẩu ở cấp ứng dụng hoặc cơ sở dữ liệu. Authentication path:

Authentication path (tạm dịch: lộ trình xác thực), là quy trình xác thực người dùng để truy cập vào HTTT của một DN. Nó thường bao gồm việc nhập thông tin đăng nhập, chẳng hạn như tên người dùng và mật khẩu, để xác minh danh tính của người dùng. Quá trình định danh này được điều khiển bởi các cài đặt bảo mật được thiết lập trên hệ thống và quy định các yêu cầu cụ thể để truy cập vào các chức năng của ứng dụng và dữ liệu được lưu trữ trong cơ sở dữ liệu liên quan.

Authentication path được kích hoạt bởi các thiết lập bảo mật. Chúng cũng xác định độ nghiêm ngặt của các yêu cầu để truy cập các chức năng trong ứng dụng và dữ liệu được lưu trữ trong cơ sở dữ liệu liên quan. Do đó, quá trình thiết lập và duy trì các thiết lập bảo mật phù hợp là thường quan trọng đối với cuộc kiểm toán.

Dưới đây là một ví dụ về access path cơ bản là trang web của một công ty tài chính. Quá trình xác thực này có 2 authentication path dễ thấy như sau: (1) Authentication path 1: Người dùng có thể truy cập vào trang web bằng cách nhập ID người dùng và mật khẩu của họ để xác thực với mạng của công ty. (2) Authentication path 2: Sau đó, họ sẽ phải nhập một ID người dùng và mật khẩu khác để xác thực với ứng dụng của công ty.

2. Tổng quan về quy trình quản lý quyền user

Một yếu tố quan trọng trong việc giải quyết các rủi ro liên quan đến việc sử dụng CNTT trong xử lý các giao dịch tài chính của một tổ chức là đảm bảo mỗi người dùng, bao gồm cả nhân viên IT, chỉ được cấp quyền truy cập cần thiết để thực hiện chức năng công việc của họ, mà không quá phạm vi hoặc quá nhiều quyền hạn. Điều này đảm bảo mỗi người chỉ có thể truy cập vào những thông tin và chức năng liên quan đến công việc của họ, từ đó giảm thiểu nguy cơ lạm dụng thông tin hay vi phạm bảo mật. Khái niệm này được gọi là least privilege - quyền tối thiểu.

Quá trình cung cấp quyền truy cập thông thường bao gồm các bước: Yêu cầu (1), Duyệt yêu cầu (2), Thực hiện yêu cầu (3). [PN1]

Quá trình gỡ bỏ quyền truy cập người dùng có thể bao gồm một thông báo từ HR, báo cáo hàng ngày hoặc hàng tuần từ nhân viên an ninh CNTT về người dùng không còn cần truy cập, hoặc thông báo từ khu vực kinh doanh.

2.1 Có ít nhất 2 nhóm người sử dụng môi trường CNTT:

a) Phần lớn người sử dụng - business user , là những người sử dụng có quyền truy cập vào hệ thống nhưng không phải nhân sự phòng IT. Business user là những người nhập thông tin vào hệ thống, xử lý các giao dịch và phân tích dữ liệu các giao dịch cho mục đính BCTC.

b) Nhóm người sử dụng còn lại là các nhân sự phòng CNTT. Trong bộ phận CNTT của mỗi DN luôn được chia ra thành các nhóm nhỏ hơn. Những nhóm nhỏ trong bộ phận CNTT có các quyền khác nhau như: (1) Thiết lập và duy trì quyền truy cập vào các ứng dụng CNTT. (2) Thay đổi và cập nhật các chương trình ứng dụng CNTT. (3) Bảo trì môi trường thực (bao gồm hệ điều hành, phần cứng máy tính và các cơ sở hạ tầng khác). (4) Bảo trì dữ liệu và cơ sở dữ liệu.

Thông thường, các SCOT owner hoặc các quản lý đơn vị kinh doanh khác chịu trách nhiệm xác định tính phù hợp của quyền truy cập của người dùng hoặc quyền truy cập của các con bot RPA do người dùng kiểm soát đến các ứng dụng CNTT và đảm bảo rằng các quyền truy cập này tuân theo việc phân tách trách nhiệm phù hợp. Trong đó:

c) SCOT owner : thường là một chức vụ trong phòng CNTT hoặc người/bộ phận trong tổ chức không thuộc phòng CNTT nhưng được có trách nhiệm quản lý và giám sát một quy trình kinh doanh cụ thể, là người quản lý và giám sát các quy trình hoặc lớp giao dịch quan trọng trong DN, đảm bảo rằng quy trình và các giao dịch đó đáp ứng các yêu cầu về tách biệt nhiệm vụ và tuân thủ các quy định. Nhiệm vụ của các SCOT owner là xác định tính phù hợp của quyền truy cập của người dùng và bot, đảm bảo rằng tách biệt nhiệm vụ được thực hiện đúng cách và giám sát quy trình cấp và thu hồi quyền truy cập. Họ là người phê duyệt cho các truy cập đó.

d) RPA bot : User-controlled RPA bot là một phần mềm tự động hóa (bot) được lập trình để thực hiện các tác vụ lặp đi lặp lại và có thể được điều khiển bởi người sử dụng. Điều này có nghĩa là người dùng có khả năng quản lý, điều khiển hoặc chỉnh sửa bot để đảm bảo rằng nó thực hiện các tác vụ đúng cách và tuân thủ các quy định an toàn thông tin được áp dụng. Ví dụ về một user-controlled RPA bot là một bot được sử dụng để tự động hóa việc nhập dữ liệu vào một hệ thống quản lý KH của một công ty, được thiết lập và điều khiển bởi một nhân viên kinh doanh của công ty.

Thông thường, nhân viên CNTT sẽ thiết lập, duy trì và loại bỏ các quyền truy cập được chấp thuận sau một khoảng thời gian. Nhân viên CNTT cũng thường hỗ trợ quá trình xác nhận định kỳ - periodic user review (PUV) về tính phù hợp của quyền truy cập đến các ứng dụng CNTT và môi trường CNTT bằng cách cung cấp danh sách truy cập để được xem xét và sửa đổi quyền truy cập theo yêu cầu từ trưởng bộ phận CNTT.

Cuối cùng, KT CNTT sẽ đi tìm hiểu quy trình xác thực qua các nhân sự này nhằm xác định các thành phần CNTT liên quan đến quy trình quản lý truy cập người dùng.

3. Tổng quan về quy trình quản lý vận hành CNTT

3.1 Quản lý và lên lịch chạy tự động các tác vụ (Job Scheduling and Monitoring)

Thông thường, phần yêu cầu dữ liệu cho quy trình [PN2] này bao gồm: (1) Quản lý và lên lịch chạy tự động các tác vụ (vd: tác vụ tính lãi tự động cho các khoản tiền gửi). (2) Sao lưu dữ liệu định kỳ. (3) Phục hồi dữ liệu sau sự cố (DRP – Disaster Recovery Plan).

Tuy nhiên, bản chất của cả 3 đầu mục này đều là lên lịch và quản lý các job được thiết lập trong hệ thống. Các nhà tạo lập chính sách tại EY đã tinh gọn quy trình quản lý vận hành khi nêu ra phần tổng quan có thể được sử dụng cho cả 3 hạng mục cần kiểm toán ở quy trình này. Theo đó, khi nhân sự phòng IT sẽ chịu trách nhiệm cho việc: (1) Lên lịch chạy tự động cho các chương trình là một phần của ứng dụng hoặc công cụ CNTT. (2) Giám sát để đảm bảo các chương trình chạy tự động đã được thực hiện thành công. (1) Xử lý các vấn đề nảy sinh.

Nhân sự vận hành CNTT có thể chạy các phần mềm hỗ trợ cho việc duy trì môi trường CNTT hoặc dữ liệu. Khi nhân sự CNTT chịu trách nhiệm cho việc: (1) Lên lịch chạy các chương trình là một phần của những ứng dụng/công cụ CNTT quan trọng. (2) Giám sát các chương trình đã được thực hiện thành công và xử lý các chương trình chạy thất bại.

Kiểm toán CNTT phải tìm hiểu quy trình thiết lập, giám sát và xử lý các vấn đề xảy ra trong quá trình xử lý dữ liệu. Khi các cá nhân không thuộc phòng CNTT kiểm soát thời gian vận hành các chức năng của máy tính sử dụng các phần mềm tự động lập lịch như Windows Tasks Scheduler, các rủi ro có thể xảy ra trong quy trình này có thể là: (1) Các chức năng máy tính không được lên lịch chạy đúng cách. (2) Các chức năng máy tính chạy thất bại (không hoàn thành).

Khi đó, kiểm toán CNTT có trách nhiệm phải kiểm tra lại các hành động tiếp theo của PIC từ DN xem họ có động thái xử lý và có xử lý được các sự cố xảy ra hay không.

3.2 Ma trận thử nghiệm kiểm soát ITGCS

3.2.1 Mô phỏng Quy trình quản lý thay đổi dạng [PN3] Thác nước (Waterfall)

MÔ PHỎNG QUY TRÌNH QUẢN LÝ THAY ĐỔI DẠNG THÁC NƯỚC

Quá trình thực hiện các thay đổi trên các ứng dụng IT , báo cáo và các chương trình giao diện thường liên quan đến yêu cầu thay đổi để cải tiến tính năng hoặc báo cáo mới, hoặc để khắc phục sự cố xử lý hoặc báo cáo.

Quá trình thay đổi trong các ứng dụng CNTT , báo cáo và các chương trình giao diện thường bao gồm yêu cầu thay đổi cho một tính năng hoặc báo cáo mới hoặc để sửa một vấn đề xử lý hoặc báo cáo. Yêu cầu thay đổi sau đó được đánh giá khả thi. Đánh giá này có thể bao gồm liên lạc với nhà cung cấp phần mềm, liên lạc với một tổ chức lập trình bên thứ ba mà không phải là nhà cung cấp phần mềm hoặc liên lạc với nhân viên lập trình của tổ chức. Các thông số kỹ thuật chi tiết được phát triển và đồng ý bởi các khu vực kinh doanh bị ảnh hưởng. Các phê duyệt có thể được ghi chép, thông thường phụ thuộc vào tính quan trọng của sự thay đổi và việc một bên thứ ba sẽ lập trình sự thay đổi hay không. Tiếp theo đó, quá trình phát triển phần mềm được thực hiện trong một môi trường tồn tại đặc biệt cho phát triển phần mềm. Thường thì, một đơn vị duy trì ít nhất ba loại môi trường xử lý bao gồm môi trường phát triển, kiểm thử và môi trường thực.

Sau khi các nhà phát triển hài lòng với các thay đổi , thường sẽ tiến hành kiểm thử CNTT. Kiểm thử này có thể bao gồm kiểm thử riêng lẻ của các chương trình đã được thay đổi, kiểm thử cách thức hoạt động của các chương trình mới hoặc đã sửa đổi với các chương trình không thay đổi liên quan và khả năng của các chương trình mới để xử lý khối lượng giao dịch dự kiến. Nếu kiểm thử CNTT được hoàn thành với kết quả đạt yêu cầu, kiểm thử chấp nhận của người sử dụng (User Acceptance Testing - UAT) sẽ được tiến hành (UAT: kiểm thử được thực hiện bởi người dùng từ phía kinh doanh, họ đã quen thuộc với cách thức hoạt động của các thay đổi đối với mục đích kinh doanh). Kiểm thử này dẫn đến việc chấp nhận thay đổi đáp ứng yêu cầu hoặc trả lại cho các nhà phát triển để tiếp tục làm việc.

Sau khi kiểm thử (UAT) thành công , thường sẽ tiến hành xem xét tài liệu phát triển và kiểm thử bởi quản lý kinh doanh của khu vực bị ảnh hưởng bởi thay đổi và bởi nhân viên CNTT chịu trách nhiệm cho môi trường xử lý. Sự chấp thuận cuối cùng cho sự thay đổi được chứng nhận bằng chữ ký của quản lý kinh doanh và quản lý khối CNTT.

Thay đổi sau đó sẽ được chuyển sang môi trường thực, ưu tiên bởi những người không thuộc về đội ngũ phát triển để đảm bảo quá trình được minh bạch. Trong trường hợp các nhà phát triển ứng dụng có thể truy cập vào môi trường thực, các hoạt động của họ nên được ghi nhật ký (logged) và được xem xét và chấp thuận bởi các cá nhân có đủ kiến thức để phán xét, đồng thời, cá nhân này không có quyền truy cập vào môi trường thực. Một số tổ chức thực hiện đánh giá sau triển khai để xác nhận rằng sự thay đổi đang hoạt động như dự kiến trong môi trường thực. Việc đánh giá này, nếu được thực hiện đúng thời hạn, có thể phát hiện ra các lỗi do các thay đổi không thích hợp, thực hiện sai hoặc chưa được kiểm tra đầy đủ.

3.3 Walkthrough quy trình quản lý thay đổi

Rủi ro 1: Các chương trình mới hoặc các thay đổi vào chương trình hiện có, bao gồm cả báo cáo và giao diện, không hoạt động như mong đợi.

Thủ tục kiểm soát: Thay đổi lên các ứng dụng CNTT được kiểm tra mức độ phù hợp bởi nhân sự không thuộc phòng CNTT và/hoặc nhân sự phòng CNTT trước khi triển khai trên môi trường thực

Thử nghiệm kiểm soát: Yêu cầu một mẫu thay đổi chương trình trong giai đoạn kiểm toán (1/1/2022 – 31/12/2022) có bằng chứng thực hiện kiểm thử UAT bởi các cấp quản lý không thuộc phòng CNTT và phòng CNTT.

Kết luận: Đối với rủi ro này, đội kiểm toán CNTT đã thu thập được biên bản ghi lại kết quả buổi kiểm thử UAT test, trong đó người thực hiện kiểm soát gồm có: người yêu cầu ở phòng ban A và các phòng ban liên quan. Có thể thấy kiểm soát này đã được DN thực hiện đúng như quy trình, KT CNTT đánh giá kiểm soát này hiệu quả.

Rủi ro 2: Các chương trình mới hoặc các thay đổi vào chương trình hiện có, bao gồm cả báo cáo và giao diện, không phù hợp với DN hoặc môi trường CNTT của DN.

Thủ tục kiểm soát : Các thay đổi này được phê duyệt bởi các cấp quản lý sau khi kiểm tra và trước khi triển khai vào môi trường thực.

Thử nghiệm kiểm soát : Yêu cầu một mẫu thay đổi đã được phê duyệt bởi cấp quản lý trước khi triển khai vào môi trường thực trong giai đoạn kiểm toán (1/1/2022 – 31/12/2022).

Người thực hiện kiểm soát : CBO của tổ chức.

Kết luận : Mẫu thay đổi được cung cấp có sự phê duyệt của CBO tổ chức trước khi được triển khai lên môi trường thực. Kiểm toán CNTT đánh giá kiểm soát này hiệu quả.

Rủi ro 3 : Nhà phát triển có thể đưa vào môi trường thực phần mềm trái phép/chưa được kiểm tra

Thủ tục kiểm soát : Môi trường thực, bao gồm cả những công cụ đưa chương trình vào môi trường thực, chỉ có thể được truy cập bởi một giới hạn các cá nhân thích hợp nhưng không có trách nhiệm phát triển phần mềm.

Thử nghiệm kiểm soát: Yêu cầu ma trận quyền từ KH, kiểm tra quyền của

nhà phát triển phần mềm đối với các thay đổi được đưa lên môi trường thực (có giới hạn quyền hạn của họ hay không).

Kết luận : DN không thực hiện thủ tục kiểm soát rủi ro này. Kiểm toán CNTT không đánh giá thêm. Kết luận cho quy trình quản lý thay đổi tại DN: Không hiệu quả

3.4 Thử nghiệm kiểm soát cho Quy trình quản lý thay đổi

3.3,1 Đối với trường hợp thay đổi này được thực hiện bởi bên thứ ba

Rủi ro giả định 1: Thay đổi tới chương trình cung cấp bởi bên thứ ba không hoạt động như mong muốn.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(1) Thay đổi lên chương trình đã được thử nghiệm bởi DN và/hoặc người dùng CNTT, được đánh giá là phù hợp trước khi đưa thay đổi vào môi trường thực.	- Thu thập danh sách toàn bộ các thay đổi tới các chương trình liên quan trong giai đoạn kiểm tra. Chọn một mẫu thay đổi từ danh sách và điều tra bằng chứng thay đổi đã được kiểm tra bởi DN hoặc nhân sự IT một cách phù hợp
(2) Thay đổi lên chương trình đã được xác thực kịp thời trước khi được triển khai	- Thu thập danh sách các thay đổi trong các chương trình liên quan được áp dụng quy trình trong suốt thời gian kiểm thử. Chọn một mẫu trong danh sách và điều tra bằng chứng là việc xác thực đã được thực hiện kịp thời trước khi triển khai.

Rủi ro giả định 2: Thay đổi vào chương trình được cung cấp bởi bên thứ 3 là không phù hợp cho DN hoặc cho môi trường CNTT.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(3) Thay đổi lên chương trình được phê duyệt bởi DN và/hoặc quản lý của khối CNTT, được đánh giá là phù hợp trước khi triển khai trên môi trường thực.	- Thu thập danh sách toàn bộ các thay đổi tới các chương trình liên quan trong giai đoạn kiểm tra. Chọn một mẫu thay đổi từ danh sách và điều tra bằng chứng thay đổi đã được duyệt bởi DN và quản lý khối CNTT trước khi triển khai vào môi trường thực.

Đối với trường hợp chương trình mới hoặc thay đổi tới ứng dụng CNTT, chương trình giao diện hoặc chương trình báo cáo được lập trình sử dụng phần mềm viết báo cáo do nhân sự CNTT của DN tạo ra.

Rủi ro giả định 3: Chương trình/thay đổi mới tới các chương trình sẵn có, bao gồm cả báo cáo và giao diện, không hoạt động như mong muốn.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(4) Chương trình hoặc thay đổi mới tới các chương trình sẵn có đã được kiểm tra bởi DN và/hoặc các nhân sự khác trong phòng CNTT mà không phải là các nhà phát triển của chính các thay đổi này, được đánh giá là phù hợp trước khi triển khai trên môi trường thực.	- Thu thập danh sách toàn bộ các thay đổi tới các chương trình liên quan trong giai đoạn kiểm tra. Chọn một mẫu thay đổi từ danh sách và điều tra bằng chứng đã được kiểm tra bởi người dùng không chuyên và/hoặc nhân sự trong phòng CNTT nhưng không tham gia vào quá trình lập trình các thay đổi này.
(5)Thay đổi lên chương trình đã được xác thực kịp thời trước khi được triển khai	- Thu thập danh sách các thay đổi trong các chương trình liên quan được áp dụng quy trình trong suốt thời gian kiểm thử. Chọn một mẫu trong danh sách và điều tra bằng chứng là việc xác thực đã được thực hiện kịp thời trước khi triển khai.

Rủi ro giả định 4 : Chương trình/thay đổi mới tới các chương trình sẵn có, bao gồm cả báo cáo và giao diện, không phù hợp cho DN hoặc môi trường CNTT của DN.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(3) Thay đổi lên chương trình được phê duyệt bởi DN và/hoặc quản lý của khối CNTT sau khi kiểm thử và trước khi triển khai trên môi trường thực.	- Thu thập danh sách toàn bộ các thay đổi tới các chương trình liên quan trong giai đoạn kiểm tra. Chọn một mẫu thay đổi từ danh sách và điều tra bằng chứng thay đổi đã được duyệt bởi DN và quản lý khối CNTT sau khi kiểm thử và trước khi triển khai trên môi trường thực.

Rủi ro giả định 5: Phần mềm thu thập thông tin phê duyệt không hoạt động như mong đợi (ví dụ: không định tuyến các thay đổi đến người phê duyệt thích hợp)

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(4) Phần mềm thu thập thông tin phê duyệt gửi chính xác yêu cầu tới người phê duyệt

- Quan sát quá trình yêu cầu được đưa đi phê duyệt tới đúng người phê duyệt một cách chính xác và phù hợp trong thời gian thực.

- Quan sát rằng không có yêu cầu không được đưa đi phê duyệt nếu:

+ Không có người phê duyệt.

+ Địa chỉ email của người phê duyệt sai.

+ Người phê duyệt đã rời khỏi tổ chức.

Rủi ro giả định 6: Phần mềm thu thập thông tin phê duyệt thay đổi không được cấu hình đúng.

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(5) Quyền truy cập tới ma trận quyền (PHỤ LỤC 9) trong phần mềm thu thập thông tin phê duyệt được giới hạn cho chỉ những người phù hợp.

- Quan sát quá trình yêu cầu được đưa đi phê duyệt tới đúng người phê duyệt một cách chính xác và phù hợp trong thời gian thực.

(6) Ma trận quyền phê duyệt trong phần mềm thu thập thông tin phê duyệt được xác thực mỗi năm một lần

- Điều tra các tài liệu minh chứng cho việc xác thực ma trận phê duyệt theo năm có diễn ra trong kỳ kiểm toán. Xác định liệu những người phê duyệt không phù hợp (không xuất hiện trong ma trận phê duyệt hoặc đã rời tổ chứ, v.v.) có được xác định và chỉnh sửa lại trong ma trận phê duyệt không.

- Đánh giá liệu tần suất xác thực ma trận quyền phê duyệt có thích hợp không.

Rủi ro giả định 7: Nhà phát triển có thể triển khai những chương trình trái phép hoặc không được kiểm tra vào môi trường thực.

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(7) DN giới hạn số người được phép triển khai thay đổi vào môi trường thực cũng như quyền được sử dụng các phần mềm bổ trợ cho việc triển khai thay đổi vào môi trường thực. Những người này không được thuộc nhóm phát triển phần mềm.

- Lấy danh sách toàn bộ các ID của người dùng có quyền truy cập vào môi trường thực và các công cụ bổ trợ cho quá trình này. Định danh người dùng có ID trong danh sách đó, sử dụng sơ dồ tổ chức, miêu tả công việc của họ và các thông tin khác để đánh giá mức độ phù hợp.

(8) Các thay đổi vào chương trình (bao gồm giao diện và báo cáo) được triển khai vào môi trường thực bởi nhà phát triển phải được logged (lưu lại) nhằm so sánh với yêu cầu và phê duyệt cho các thay đổi này bởi ngời không thể truy cập vào để thực hiện các thay đổi này.

- Thu thập toàn bộ lịch sử ghi nhận những lần thay đổi lên chương trình (bao gồm giao diện và báo cáo) đối với các báo cáo có liên quan.

- Kiểm tra cài đặt cho việc ghi nhận để xác thực rằng tất các thay đổi liên quan đã được bao hàm.

- Xác định rằng thay đổi này là từ một nguồn phù hợp.

- Điều tra danh sách đề xác định các khoảng trống (gaps) khả nghi (ví dụ như DN này thường có 2 tới 3 thay đổi trong mỗi tháng, nhưng tháng này có nhiều hơn hoặc không có gì cả).

- Phỏng vấn KH để tìm hiểu nguyên nhân của mẫu ngoại lệ.

Đối với một mẫu thay đổi, kiểm tra từ bước yêu cầu tới bước phê duyệt để đảm bảo các bước này đã được so sánh và đánh giá bởi nhân sự của tổ chức

Rủi ro giả định 8 : Công cụ dùng để tự động triển khai thay đổi lên môi trường thực dựa trên thông báo từ phần mềm thu thập thông tin phê duyệt không hoạt động như mong đợi. (Không triển khai lên môi trường thực đúng tệp tin)

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(9) Công cụ triển khai lên môi trường thực đã triển khai đúng tệp tin khi nhận được thông báo từ công cụ thu thập thông tin phê duyệt.	- Quan sát cách vận hành của việc phê duyệt một thay đổi được gây ra bởi sự di chuyển cũng những tệp tin thích hợp vào môi trường thực.

Rủi ro giả định 9: Thay đổi cấu hình liên quan tới bảo mật môi trường

thực là không phù hợp hoặc bị thay đổi sai.

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(10) Các thay đổi lên cấu hình quan trọng được ghi nhận và khớp với sự uỷ quyền của người không thể thay đổi cấu hình đang được giám sát.

- Kiểm tra các cài đặt tạo nhật ký để xác định xem chúng có bao gồm cấu hình trọng yếu không.

- Xác định và đánh giá độ phù hợp của các cá nhân có thể thay đổi cài đặt ghi nhận nhật ký.

- Đối với một mẫu trong các thay đổi, điều tra bằng chứng liệu ghi nhận nhật ký có đúng với những thay đổi đã được phê duyệt cho quy trình thay đổi cấu hình không.

Kiểm tra xem các thiết lập cấu hình quan trọng đã phù hợp chưa.

(11) Các thiết lập cấu hình quan trọng được xác thực mỗi năm một lần.

- Điều tra các tài liệu liên quan tới việc xác thực. Xác định xem đối với có cấu hình nào được cài đặt không phù hợp, DN đã có động thái chỉnh sửa và hậu quả của lỗi cài đặt đó đã được đánh giá chưa

- Điều tra bằng chứng rằng các thiết lập quan trọng đã phù hợp.

3.3.2 Mô phỏng quy trình quản lý truy cập kiểm soát truy cập luận lý – Logical Access Path

Logical process path là một khái niệm trong lĩnh vực quản lý quy trình và công nghệ thông tin. Nó dùng để mô tả các bước hoặc chuỗi các hành động logic mà thông tin hoặc dữ liệu đi qua trong quá trình xử lý hoặc thực hiện một quy trình, từ đầu đến cuối.

Trong viễn cảnh của một tổ chức hoặc hệ thống, logical process path giúp hiểu rõ các bước, quy trình và luồng dữ liệu từ khi nó nhập vào hệ thống cho đến khi nó được xử lý, lưu trữ hoặc xuất ra kết quả. Điều này giúp tăng cường hiệu quả, định rõ trách nhiệm của từng giai đoạn và xác định vị trí có thể xuất hiện các vấn đề hoặc điểm yếu trong quy trình để cải thiện và tối ưu hóa hoạt động của tổ chức.

4. Thử nghiệm kiểm soát cho Quy trình quản lý truy cập

4.1 Quy trình quản lý các thiết lập bảo mật [PN4]

Rủi ro giả định 1: Các thiết lập bảo mật quan trọng không phù hợp để hạn chế quyền truy cập với chỉ những đối tượng được chỉ định hoặc các thiết lập này không còn thích hợp qua thời gian.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(1) Yêu cầu sử dụng mật khẩu đủ độ dài và độ phức tạp để truy cập các ứng dụng IT, cơ sở dữ liệu và các thành phần môi trường IT liên quan khác.	- Điều tra và thu thập bằng chứng đặc điểm yêu cầu của mật khẩu được đùng để đăng nhập vào các ứng dụng CNTT, CSDL và các thành phần CNTT khác. Đánh giá cài đặt mật khẩu về tính phù hợp. Sau đây là các cài đặt mật khẩu được đề xuất bởi IB: - Độ dài tối thiểu 8 ký tự. - Tần suất thay đổi mật khẩu bắt buộc (90 ngày) Số lượng mật khẩu phải được dùng trước khi được dùng lại một mật khẩu là tối thiểu 10 lần - Mật khẩu phải phức tạp (có chữ hoa, thường, có số và ký tự đặc biệt). Xác định xem liệu các quy định mật khẩu có được áp dụng cho tất cả các tài khoản người dùng, bao gồm các tài khoản được sử dụng bởi nhân sự CNTT
(2) Mật khẩu đăng nhập thất bại 5 lần phải được khoá ít nhất 30 phút	- Kiểm tra cài đặt khóa tài khoản để đảm bảo tính hợp lý
(3) Xác thực đa yếu tố - Multifactor Authentication (MFA) được sử dụng bởi tất cả các user đăng nhập từ xa (ngoài văn phòng)	- Quan sát việc đăng nhập từ xa để xác định liệu MFA có được yêu cầu hay không. Tìm hiểu và điều tra cài đặt được yêu cầu để MFA hoạt động.
(4) Mật khẩu mặc định (mật khẩu có sẵn khi nhận tài khoản) đã được thay đổi hoặc tài khoản không thay đổi mật khẩu ban đầu này đã bất hoạt	- Quan sát việc thử đăng nhập vào ứng dụng IT hoặc các thành phần môi trường IT liên quan bằng ID và mật khẩu mặc định của hệ thống hoặc kiểm tra bằng bằng chứng khác rằng các tài khoản mặc định đã bị vô hiệu hóa hoặc các mật khẩu đã được thay đổi từ giá trị mặc định. Kiểm tra quy trình của đơn vị để xác định và thay đổi các mật khẩu này, đặc biệt khi trang thiết bị hoặc phần mềm mới được cài đặt hoặc cập nhật.
(5) Các cài đặt bảo mật quan trọng khác ngoài mật khẩu được thiết lập với các giá trị phù hợp với môi trường và mức độ rủi ro (giả sử đối với các DN có rủi ro cao bị đánh cắp thông tin thì phải trang bị bảo mật cao cho toàn bộ HTTT của mình)	- Điều tra và thu thập bằng chứng các thiết lập quan trọng cho các thành phần của HTTT bên cạnh mật khẩu. Đánh giá mức độ phù hợp của các chế độ cài đặt.

Rủi ro giả định 2: Các cài đặt bảo mật quan trọng không còn phù hợp qua thời gian.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(6) Mật khẩu và các cài đặt bảo mật khác được xác thực định kỳ đối chiếu với các cài đặt phù hợp được định nghĩa bởi chính sách.	- Lấy mẫu một thời kỳ và điều tra bằng chứng có sự so sánh giữa đặc điểm mật khẩu và các cài đặt bảo mật quan trọng trong chính sách. - Xác định xem liệu có bất kỳ cài đặt mật khẩu khách so với những gì chính sách yêu cầu. - Nếu có chênh lệch, DN có sửa lỗi không Đánh giá mức độ phù hợp về tần suất xác thực.
(7) Thay đổi tới các cài đặt bảo mật quan trọng được ghi lại. Lịch sử ghi nhận được xem lại bởi những cá nhân có đủ khả năng đánh giá nhưng không thể thay đổi các cài đặt họ đang thẩm định. Các thay đổi chỉ bởi những người có đủ quyền để thực hiện chúng. Nếu có lỗi sai, các hành động sửa sai phải được thực hiện	- Điều tra cài đặt tạo nên lịch sử ghi nhận để xác định liệu chúng có bao gồm cấu hình chủ chốt. Xác định và đánh giá độ phù hợp cảu các cá nhân có thể thay đổi cài đặt của công cụ ghi nhận (log). - Lấy mẫu một thời kỳ và điều tra bằng chứng các ghi nhận log đã được review bởi người có khả năng thẩm định nhưng không thể thay đổi cài đặt này.
(8) Công cụ thu thập thông tin thông báo quản trị viên qua email khi có thay đổi cài đặt. Các quản trị viên sẽ điều tra thay đổi nay và thực hiện các hành động cần thiết.	- Điều tra điều kiện để các công cụ này gửi cảnh báo và đánh giá tính đầy đủ và phù hợp của chúng. - Giả lập các sự cố để kiểm tra liệu các cảnh bảo có thực sự được gửi đi không. - Đối với một mẫu thông báo, tham luận cách đối tượng được điều tra và giải quyết như thế nào bởi các quản trị viên phù hợp. Điều tra bằng chứng của việc giải quyết.

Rủi ro giả định 3: Phần mềm được sử dụng để giám sát các cài đặt không được cấu hình hoặc duy trì để phát hiện các thay đổi trong các cài đặt bảo mật quan trọng.

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(9) Công cụ giám sát đã được cấu hình để phát hiện các thay đổi trong các cài đặt bảo mật quan trọng. Điều này đảm bảo rằng các thay đổi này có thể được phát hiện kịp thời và được kiểm tra tính hợp lệ của chúng.

- Kiểm tra điều kiện để công cụ giám sát gửi cảnh báo và đánh giá tính đầy đủ và thích hợp của chúng.

- Yêu cầu đơn vị tái hiện các sự kiện mà cảnh báo nên được gửi. Xác định xem liệu cảnh báo đã được gửi hay chưa

(10) Các thiết lập của công cụ giám sát được xác minh định kỳ.

- Kiểm tra tài liệu của một mẫu biên bản xác minh. Xác định xem các vấn đề đã xác định có được giải quyết đúng cách hay không.

- Thực hiện lại các biên bản xác minh, nếu cần thiết.

Đánh giá tính thích hợp của tần suất các biên bản xác minh.

Rủi ro giả định 4: Quyền truy cập để thay đổi cấu hình của phần mềm giám sát là không thích hợp.

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(10) Truy cập để thay đổi các cấu hình trong các công cụ giám sát được hạn chế một cách thích hợp.

- Kiểm tra điều kiện để công cụ giám sát gửi cảnh báo và đánh giá tính đầy đủ và thích hợp của chúng.

- Thu thập và kiểm tra danh sách các ID có thể thay đổi các cấu hình để đánh giá tính thích hợp.”

4.2 Quy trình quản lý người dùng truy cập [PN5]

Rủi ro giả định 1 : Yêu cầu truy cập của nhân viên IT và nhân sự không chuyên đối với các thành phần liên quan đến môi trường IT không thích hợp.

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(11) Trước khi cho phép truy cập thì yêu cầu truy cập đó phải được phê duyệt bởi nhân sự có đủ tư cách phê duyệt.

- Thu thập danh sách các ID người dùng cho việc truy cập được thêm vào các ứng dụng IT liên quan và các thành phần môi trường IT liên quan, từ đầu kỳ kiểm toán đến ngày kiểm tra. Xác định danh sách này có đầy đủ không. Chọn một mẫu các ID người dùng từ danh sách và kiểm tra chứng cứ cho thấy việc truy cập được thêm vào đã được ủy quyền bởi một người phù hợp trước khi cấp truy cập. Đánh giá xem việc truy cập này có hợp lý không, dựa trên chức danh hoặc trách nhiệm công việc của người dùng.

Rủi ro giả định 2 : Phần mềm thu thập phê duyệt không hoạt động như mong đợi (ví dụ, không định tuyến thay đổi đến người phê duyệt thích hợp)

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(12) Thiết bị thu thập thông tin xác nhận chấp thuận định tuyến yêu cầu đến người phê duyệt đúng cách.

- Quan sát rằng yêu cầu được gửi cho người phê duyệt đúng và phù hợp khi sự kiện kích hoạt xảy ra.

- Quan sát rằng không có chuyển tiếp yêu cầu được thực hiện khi:

+ Không có người phê duyệt nào được chỉ định trong bảng định tuyến để xử lý yêu cầu

+ Địa chỉ email của người phê duyệt sai

+ Người phê duyệt đã rời khỏi tổ chức.

Rủi ro giả định 3: Phần mềm thu thập thông tin phê duyệt quyền truy cập không được cấu hình đúng.

Thủ tục kiểm soát (giả định)

Thử nghiệm kiểm soát (giả định)

(13) Quyền truy cập để thay đổi ma trận phê duyệt trong công cụ thu thập phê duyệt được giới hạn cho những cá nhân thích hợp

- Thu thập và kiểm tra danh sách các ID có thể thay đổi ma trận duyệt của công cụ thu thập phê duyệt. Xác định cái ID này có phù hợp để phê duyệt không.

(14) Ma trận phê duyệt trong công cụ thu thập phê duyệt được xác minh ít nhất mỗi năm một lần.

- Kiểm tra tài liệu của một phiếu xác minh được thực hiện trong thời gian kiểm toán. Xác định xem các người phê duyệt không tuân thủ kỳ vọng đã được xác định và thay thế hay không.

Đánh giá tần suất xác minh để đảm báo tính phù hợp của hoá đơn chứng từ.

Rủi ro giả định 4: Quyền truy cập được cấp không giống với quyền truy cập được phê duyệt

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(15) Sau khi thiết lập quyền truy cập thì phải kiểm tra lại xem quyền đó có đúng chưa.	- Nếu một báo cáo về quyền truy cập được cấp cho một khoảng thời gian được sử dụng làm cơ sở cho kiểm soát, xác minh tính đầy đủ của báo cáo đó. Lấy tài liệu cho một mẫu kiểm tra. Thực hiện lại kiểm soát đó.
(16) Quyền truy cập thích hợp tới các ứng dụng CNTT, thành phần môi trường CNTT, bao gồm các công cụ, được xác minh định kỳ bởi nhân sự quản lý phù hợp.

Rủi ro giả định 5: Quyền truy cập không được huỷ bỏ kịp thời

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(17) Một quản trị viên an toàn thông tin sẽ huỷ bỏ quyền truy cập của người dùng đã rời khỏi DN hoặc những người đã thay đổi chức vụ công việc gần đây.	- Thu thập danh sách các cá nhân nghỉ việc/đổi việc trong kì kiểm toán. Xác định tính đầy đủ của danh sách. - Chọn mẫu một cá nhân, kiểm tra lịch sử truy cập để xác định liệu các quyền truy cập có họ có được huỷ bỏ từ ngày nghỉ việc/thay đổi vị trí không.
(18) Một công cụ tự động loại bỏ quyền truy cập kịp thời của các người dùng rời khỏi tổ chức hoặc thay đổi nhiệm vụ, chức năng dựa trên thông báo từ phòng nhân sự, từ hệ thống nhân sự hoặc từ người giám sát/quản lý của người đó.	- Phỏng vấn để xác định các công cụ tự động đó sẽ tương tác dữ liệu với những ứng dụng CNTT và các phần tử CNTT liên quan nào. Nếu không phải tất cả, xác định cụ thể phần tử nào/ứng dụng nào không tương tác và xác định các biện pháp kiểm soát khác được áp dụng cho ứng dụng đó. - Duyệt thông tin để tìm hiểu cách những người chịu trách nhiệm vận hành công cụ xử lý liên kết với tất cả các ứng dụng IT và thành phần môi trường IT liên quan. Xác định cách những người này giải quyết các ứng dụng mới và các thành phần môi trường IT khác được thêm vào theo thời gian. Cân nhắc xem liệu cần có thêm rủi ro và kiểm soát nào. - Kiểm tra cài đặt của công cụ để xác định những tín hiệu gì kích hoạt hành động loại bỏ quyền truy cập và quyền truy cập vào thành phần môi trường IT nào bị ảnh hưởng; cân nhắc rằng ngày chấm dứt đôi khi là những ngày đã qua, và cách thức ngày quá khứ có thể ảnh hưởng đến hoạt động của ITGC.

Rủi ro giả định 6: Quyền truy cập không còn phù hợp qua thời gian

Thủ tục kiểm soát (giả định

Thử nghiệm kiểm soát (giả định)

(19) Quyền truy cập vào các ứng dụng IT liên quan và các thành phần hỗ trợ môi trường IT, bao gồm công cụ, được xác minh định kỳ bởi các nhân viên quản lý thích hợp

- Đối với một số giai đoạn được chọn mẫu mà việc xác nhận tính thích hợp của quyền truy cập đã được thực hiện, thu thập tài liệu xác nhận.

- Xác định cách mà người phối hợp đánh giá biết rằng tất cả người dùng liên quan đã được bao gồm trong quá tình xác nhận và tất cả các yêu cầu xác nhận đã nhận được phản hồi.

- Thực hiện lại các hoạt động được thực hiện bởi người phối hợp đánh giá. Xác định xem thông tin truy cập cung cấp có đủ để cho người đánh giá quyết định thông thái hay không.

Đối với một mẫu các người trả lời yêu cầu thay đổi, kiểm tra quyền truy cập hiện tại để xác định các thay đổi đã được thực hiện. Đánh giá số lượng yêu cầu thay đổi và xem xét ảnh hưởng của nó đến việc hoạt động thích hợp của các quy trình truy cập.

4.3 Walkthrough quy trình quản lý truy cập

Rủi ro 1 : Yêu cầu truy cập cho nhân sự phòng IT và nhân sự khác vào các thành phần môi trường CNTT là không phù hợp.

Thủ tục kiểm soát : Các quyền truy cập phải được phê duyệt bởi người phù hợp trước khi cấp quyền.

Thử nghiệm kiểm soát: Yêu cầu KH cung cấp bằng chứng phê duyệt bởi nhân sự cấp quản lý, đồng thời đối chiếu quyền của nhân sự phê duyệt này trong ma trận phân quyền xem vai trò của người này có phù hợp để phê duyệt hay không.

Mẫu được cấp thể hiện các thông tin sau: Họ tên người dùng: Nguyen P. Quoc; Phòng ban: CNTT; ID người dùng: (không được cung cấp vì lý do bảo mật); Ngày yêu cầu: 5/12/2023; Vị trí cần cấp quyền: Kỹ sư phần mềm; Được phê duyệt bởi: (không xác định được)

Kết luận : Với bằng chứng kiểm toán được cung cấp như trên về một mẫu tạo mới người dùng, đội kiểm toán ghi nhận dù các cấp quản lý đã được thông báo về người dùng mới, đội không thể xác định được chức vụ của người phê duyệt. Kiểm toán CNTT đánh giá kiểm soát này không hiệu quả.

Rủi ro 2 : Quyền truy cập không khớp với quyền được phê duyệt

Rủi ro 4 : Quyền truy cập không còn phù hợp qua thời gian. Đây là hai rủi ro có thể được kiểm soát bởi cùng một thủ tục kiểm soát bên dưới.

Thủ tục kiểm soát: Độ chính xác của quyền truy cập vào các ứng dụng IT liên quan và các thành phần môi trường hỗ trợ IT, bao gồm các công cụ, được xác minh định kỳ bởi nhân viên quản lý thích hợp

Thử nghiệm kiểm soát: Kiểm tra biên bản review phân quyền định kỳ trong giai đoạn kiểm toán (1/1/2022 – 31/12/2022).

Kết luận: Sau khi kiểm tra bằng chứng kiểm toán được cung cấp như trên, đội kiểm toán ghi nhân khách hàng (KH) này không thực hiện rà soát phân quyền định kỳ. KT CNTT đánh giá kiểm soát này không đánh giá, không cần kiểm tra

Rủi ro 3 : Quyền truy cập không được chấm dứt kịp thời

Thủ tục kiểm soát : Quản trị viên bảo mật loại bỏ quyền truy cập của người

dùng nghỉ việc hoặc thay đổi trách nhiệm công việc trong vài ngày kể từ khi sự kiện xảy ra.

Thử nghiệm kiểm soát: Thu thập danh sách các cá nhân nghỉ việc/đổi việc

trong kì kiểm toán. Xác định tính đầy đủ của danh sách. Chọn mẫu một cá nhân, kiểm tra lịch sử truy cập để xác định liệu các quyền truy cập có họ có được huỷ bỏ từ ngày nghỉ việc/thay đổi vị trí không.

Kết luận : Dù đã yêu cầu dữ liệu, đội KT ghi nhận KH này không thực hiện thủ tục này.

Kiểm toán CNTT đánh giá kiểm soát này không đánh giá, không cần kiểm tra thêm

Rủi ro 5 : Người sử dụng môi trường CNTT không phải người dùng được định sẵn do cài đặt xác thực và bảo mật không đầy đủ.

Thủ tục kiểm soát : Các cài đặt mật khẩu được thực hiện để truy cập vào ứng dụng và hạ tầng hỗ trợ.

Thử nghiệm kiểm soát: Điều tra và thu thập bằng chứng đặc điểm yêu cầu của mật khẩu được đùng để đăng nhập vào các ứng dụng CNTT, CSDL và các thành phần CNTT khác. Đánh giá cài đặt mật khẩu về tính phù hợp

Đội kiểm toán tiến hành thu thập thiết lập mật khẩu của KH để so sánh với thiết lập mật khẩu được đề xuất bởi IB.

Thông số mật khẩu	Chính sách mật khẩu của IB	Khuyến nghị của EY	Đánh giá
Độ dài mật khẩu tối thiểu	Tối thiểu 8 ký tự	6 - 8 kí tự	Hiệu quả
Đăng nhập lần đầu bằng mật khẩu mặc định	Có thực hiện	Có thực hiện	Hiệu quả
Độ phức tạp mật khẩu	Có thực hiện	Có thực hiện	Hiệu quả
Tần suất bắt buộc thay đổi mật khẩu	90 ngày (chỉ khi thời hạn quá hạn bắt buộc được người dùng tự thiết lập)	60 – 90 ngày	Không hiệu quả
Số lần đăng nhập thất bại trước khi khoá tạm thời tài khoản	10 lần	5 lần	Hiệu quả
Người dùng có thể tự tạo mật khẩu	Có thực hiện	Có thực hiện	Hiệu quả
Số lượng mật khẩu phải sử dụng trước khi có thể sử dụng lại mật khẩu đó	Không xác định	5	Không hiệu quả
Thời gian chờ kết thúc phiên không hoạt động	180 phút	30 phút	Hiệu quả
Logging của các lần đăng nhập không thành công	Có thực hiện	Có thực hiện	Hiệu quả

Kết luận : thiết lập mật khẩu của IB không hiệu quả vì không thoả mãn được thiết lập tối thiểu theo EY GAM. Kết luận cho quy trình quản lý truy cập tại IB: Không hiệu quả.

4.3 Quy trình quản lý vai trò [PN6]

Rủi ro giả định 1: Các quyền truy cập theo nhiệm vụ và chức năng của nhân sự có vấn đề về phân quyền và có thể dẫn đến kết quả các ứng dụng CNTT xử lý dữ liệu sai.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(20) Việc thay đổi quyền truy cập trong các vai trò được chấp thuận bởi các cá nhân thích hợp trước khi thay đổi được thực hiện	- Lấy danh sách đầy đủ các thay đổi vai trò trong khoảng thời gian kiểm tra. Đối với tất cả hoặc một mẫu thay đổi, kiểm tra bằng chứng cho thấy những thay đổi vai trò này đã được phê duyệt bởi một người quản lý phù hợp. Đánh giá các thay đổi vai trò để xem liệu có đưa ra những vấn đề liên quan đến phân chia nhiệm vụ hay không.

(21) Sự kết hợp các chức năng/vai trò được xem xét để đảm bảo tính phù hợp của chúng ít nhất một lần một năm.	- Đối với một số kỳ để xác thực tính phù hợp của quyền truy cập được gán cho các vai trò, thu thập tài liệu của các đợt đánh giá. Xác định tất cả các vai trò liên quan đã được bao gồm trong quy trình xác thực và tất cả các yêu cầu xác thực đã nhận được phản hồi. -Đối với một số mẫu role, thảo luận cơ sở cho các kết luận với những người đánh giá. Đánh giá tính thích hợp của quyền truy cập được bao gồm. Nếu cần, phỏng vấn KH để tìm hiểu nguyên nhân. - Đối với bất kỳ sửa đổi nào về vai trò, xác định xem các thay đổi được yêu cầu đã được thực hiện hay chưa.

4.4 Quy trình thay [PN7] đổi dữ liệu trực tiếp

Rủi ro giả định 1: Có những thay đổi dữ liệu trực tiếp không phù hợp được thực hiện. (Những thay đổi này có mức độ rủi ro cao hơn khi việc sử dụng thay đổi dữ liệu trực tiếp là thường xuyên trong quá trình xử lý các giao dịch liên quan đến BCTC)

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(21) Việc thay đổi dữ liệu trực tiếp được phê duyệt bởi một người thích hợp khác ngoài người yêu cầu thay đổi.	Đối với một số lượng mẫu các thay đổi trực tiếp trên dữ liệu, kiểm tra tính phù hợp của quá trình phê duyệt. Thảo luận với người phê duyệt về cơ sở của họ để phê duyệt những thay đổi đó. Hỏi về những thay đổi mà họ không phê duyệt và cơ sở cho những quyết định đó.
(22) Việc kiểm thử của một thay đổi sử dụng chương trình được thực hiện trước khi chạy chương trình đó trong môi trường thực.	Đối với một số lượng mẫu thay đổi dữ liệu trực tiếp được thực hiện bằng cách sử dụng một chương trình, kiểm tra bằng cách xem xét bằng chứng về quá trình kiểm thử. Đánh giá tính đầy đủ của quá trình kiểm thử đó.
(23) Xác minh độ chính xác của thay đổi một cách kịp thời sau khi triển khai.	Kiểm tra cho một mẫu các thay đổi dữ liệu trực tiếp, xem xét chứng cứ về việc xác nhận sau triển khai. Xem xét tính thích hợp của khoảng thời gian giữa triển khai thay đổi và việc xác nhận.
(24) Việc thay đổi dữ liệu trực tiếp được ghi nhận lại và so sánh với yêu cầu và phê duyệt cho các thay đổi này bởi người không có quyền truy cập vào để thực hiện các thay đổi này.	Thu thập nhật ký thay đổi dữ liệu trực tiếp cho giai đoạn kiểm tra. Kiểm tra cài đặt nhật ký để xác nhận tất cả các cơ sở dữ liệu liên quan được bao gồm. Kiểm tra danh sách để tìm các khoảng trống rõ ràng (ví dụ như một tháng không có thay đổi dữ liệu trực tiếp trong khi tất cả các tháng khác đều chứa nhiều thay đổi như vậy) và hỏi về nguyên nhân của các khoảng trống đó. Đối với một số thay đổi, kiểm tra các yêu cầu và phê duyệt liên quan. Xác định xem các người đánh giá có quyền truy cập để thực hiện các thay đổi hay không.

C. MÔ PHỎNG QUY TRÌNH QUẢN LÝ VẬN HÀNH

1.Thử nghiệm kiểm soát cho Quy trình quản lý vận hành CNTT

Rủi ro giả định 1: Các tác vụ chạy tự động (job) không được lên lịch đúng.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(1) Thay đổi trong môi trường thực cho các tác vụ chạy tự động được xác thực mởi một nhân sự vận hành khác trước khi tác vụ đó được lên lịch chạy tự động	Đối với một mẫu job chạy tự động thu thập được, xác định liệu một nhân viên vận hành khác đã xác minh tính chính xác của thay đổi trước khi lịch trình được sử dụng trong môi trường thực chưa.
(2) Định kì mỗi tháng, lịch job chạy tự động hiện tại được so sánh với lịch của tháng trước. Các thay đổi phải được xác định và đồng ý bởi các tài liệu có liên quan.	Đối với một mẫu các tháng được chọn ngẫu nhiên, kiểm tra tài liệu so sánh. Thực hiện lại việc xác định các thay đổi. Kiểm tra bằng chứng cho thấy các thay đổi được đồng ý với tài liệu hỗ trợ. Kiểm tra tài liệu hỗ trợ để xem xét tính thích hợp của các thay đổi.

Rủi ro giả định 2: Các chương trình không được thực hiện hoàn tất không được giải quyết hoặc không được giải quyết một cách thích hợp.

Thủ tục kiểm soát (giả định)	Thử nghiệm kiểm soát (giả định)
(3) Nhân sự phòng CNTT giám sát việc thực hiện các tác vụ này và thực hiện hành động thích hợp để giải quyết các vấn đề phát sinh	Đối với một mẫu job chạy tự động thu thập được, xác định liệu một nhân viên vận hành khác đã xác minh tính chính xác của thay đổi trước khi lịch trình được sử dụng trong môi trường thực chưa.

(3) Những tác vụ thất bại không được giải quyết hoặc không được giải quyết một cách thích hợp

10. Tổng hợp kết quả và phát hành thư quản lý

10.1. Tổng hợp kết quả

Sau khi kiểm toán hoàn tất, bao gồm kiểm tra kiểm soát tổng thể của CNTT và tính đầy đủ của dữ liệu bút toán, kiểm toán viên sẽ tiến hành đánh giá lại hiệu quả của quy trình kiểm toán. Việc này bao gồm xác định tính hợp lý của quy trình, đảm bảo các bước kiểm toán thực hiện đáp ứng được các mục tiêu kiểm toán ban đầu. Qua cuộc kiểm toán CNTT cho IB nhận thấy một số đặc điểm như sau trong hệ thống kiểm soát CNTT: (1) Quy trình quản lý thay đổi: Có phê duyệt đủ các bước từ phê duyệt request tới kiểm thử và phê duyệt trước khi triển khai vào môi trường thực. Tuy nhiên, IB vẫn chưa có giới hạn quyền cho nhà phát triển phần mềm, rủi ro tiềm ẩn về việc nhà phát triển đưa các thay đổi bất lợi cho IB vào môi trường thực cao. (2) Quy trình quản lý truy cập: Mặc dù có một đội ngũ lớn trong việc duy trì và quản lý 3 hệ thống, IB vẫn còn đang rất lỏng lẻo trong khâu kiểm soát quyền hạn của các nhân viên phòng IT. Toàn bộ các kiểm soát MA không đạt yêu cầu. (3) Quy trình quản lý vận hành: không hiệu quả

10.2 Phát hành thư [PN1] quản lý

Thư quản lý đóng vai trò là một báo cáo tóm tắt các phát hiện chính. Đối với IB, thư quản lý đề cập đến các rủi ro tiềm ẩn và đưa ra các khuyến nghị như sau: (1) Cần xây dựng và cải thiện các chính sách, quy trình và thủ tục CNTT. Tuy IB đã có các quy định hoàn chỉnh, nhưng chưa có các kiểm soát tuân thủ theo quy trình đang được áp dụng tại IB. Việc này có thể dẫn đến nguy cơ tăng cao về sự không nhất quán trong các hoạt động tại công ty. Do đó, khuyến nghị của KT là công ty nên cập nhật lại các chính sách và thủ tục để phù hợp hơn với quy trình hiện tại, đồng thời các quy định cần được ban hành bởi người có thẩm quyền liên quan và được cấp cao phê chuẩn. (2) Cần rà soát và kiểm tra định kỳ các quy trình thay đổi. Hiện tại, IB chưa có sự rà soát định kỳ các thay đổi, dẫn đến các hoạt động thay đổi không được hiệu quả và có thể không phù hợp với quy định mà vẫn được tiến hành. Do đó, khuyến nghị IB cần thực hiện rà soát định kỳ các thay đổi trong năm tài chính.

- Về quy trình truy cập, KT nhận thấy hệ thống đang có nhiều lỗ hổng lớn khi quy trình phê duyệt, tạo mới user và huỷ quyền user chưa có người phê duyệt rõ ràng, chưa có biên bản/bằng chứng phê duyệt được kí/xác nhận bởi người thích hợp.

- Cần ghi nhận danh sách các sự cố trong quy trình vận hành. Hiện tại, IB chưa ghi nhận danh sách các sự cố, dẫn đến khó khăn trong việc rà soát các sự cố và tìm ra nguyên nhân dẫn đến chúng. Đặc biệt, thiếu cơ sở để tổng hợp dữ liệu để đưa ra các giải pháp cải thiện hệ thống. Do đó, khuyến nghị công ty nên ghi nhận danh sách các sự cố và cung cấp các thông tin chi tiết thủ công hoặc trên hệ thống. Như vậy, dựa trên quy trình của IB, KT rút ra các rủi ro và các thủ tục kiểm soát tương ứng, qua đó yêu cầu các bằng chứng kiểm toán để thực hiện thử nghiệm kiểm soát, đánh giá lại toàn bộ quy trình và đưa ra hàm ý cho cả KT và IB nhằm cải thiện hiệu quả hoạt động của IB đối với HTTT.

11. Walkthrough quy trình quản lý vận hành

Rủi ro 1 : Các vấn đề phần cứng hoặc phần mềm dẫn đến mất mát dữ liệu hoặc không thể xử lý dữ liệu một cách chính xác

Thủ tục kiểm soát: Các tập tin cơ sở dữ liệu được sao lưu định kỳ. Bất kỳ sự cố nào trong quá trình sao lưu sẽ được giải quyết phù hợp dựa trên SLA (hợp đồng với nhà cung cấp)

Thử nghiệm kiểm soát: Yêu cầu một mẫu sự cố sao lưu nếu có trong giai đoạn kiểm toán (1/1/2022 – 31/12/2022), kiểm tra bằng chứng có hành động giải quyết sự cố từ nhân sự phù hợp.

Màn hình chụp lịch sao lưu dữ liệu từ KH

Kết luận: Vì KH không cung cấp đủ thông tin cho EY để biết được loại sao lưu nào được thực hiện (sao lưu đầy đủ/từng phần) hoặc nhật ký kết quả sao lưu, KT CNTT không thể đưa ra ý kiến đánh giá hiệu quả của kiểm soát này.

Rủi ro 2 : Các tác vụ không được lên lịch chính xác theo thoả thuận

Thủ tục kiểm soát : Trước khi lịch chạy tác vụ tự động được sử dụng, các thay đổi lịch chạy tác vụ phải được xác nhận bởi một nhân viên vận hành khác thuộc DN

Thử nghiệm kiểm soát: Yêu cầu các hạng mục job DN đang có trên toàn bộ 3 hệ thống và nhân sự có liên quan, kiểm tra bằng chứng có sự xác nhận của nhân viên vận hành khác nhằm đảm bảo quy tắc phân quyền.

Sau đây là một mẫu về batch job được thực hiện trong hệ thống X. [PN2]

Hạng mục liên quan	Miêu tả công việc	Tần suất thực hiện	Người chịu trách nhiệm
Food	Quét tất cả các chuyến đi với trạng thái giao hàng: 1 - bắt đầu, 5 - đã xử lý, 18 - sắp giao hàng, 19 - đánh dấu hoàn thành, 20 - đánh dấu thất bại.	Mỗi 5 phút	Trưởng Nhóm Kỹ Thuật Sản Phẩm - Thực phẩm
Transport	Quét các chuyến đi có trạng thái là 1 và 14 (tài xế không bắt đầu chuyến đi) và thời gian diễn ra hơn 8 giờ.	Mỗi 5 phút	Trưởng Nhóm Kỹ Thuật Sản Phẩm - Sản phẩn vận tải
- End trips by changing status to 11
Delivery Insurance & Transport Insurance	Quét các chuyến đi có ID và trạng thái = 3	Mọi ngày sau 00:00	Trưởng Nhóm Kỹ Thuật Sản Phẩm - Chương Trình KH Thân Thiết & Bảo Hiểm
- Change status to 5
(Tác vụ hệ thống)	Chèn tất cả các chuyến đi ẩn danh có số tiền < 200k	Mọi ngày sau 00:00	Kỹ sư phần mềm cấp cao
- Calculate invoice amount and send request to Viettel Offline for invoice issuance

Màn hình bằng chứng các lịch chạy tự động đã được thực hiện thành công

.

Kết luận : Sau khi kiểm tra mẫu dữ liệu màn hình chụp của KH, đội kiểm toán nhận thấy các tác vụ có ghi nhận lịch sử giám sát, có người phụ trách (tác giả giấu tên vì lý do bảo mật) khác với nhân sự set up job và toàn bộ các tác vụ được chạy thành công, không có tác vụ được lên lịch vào ngày 31/12/2022 còn sót lại/thất bại.

Rủi ro 3: Những tác vụ thất bại không được giải quyết hoặc không được giải quyết một cách thích hợp

Thủ tục kiểm soát: Nhân viên CNTT giám sát trạng thái của tác vụ tự động và thực hiện các hành động phù hợp để giải quyết các vấn đề phát sinh.

Thử nghiệm kiểm soát: Yêu cầu một mẫu sự cố job nếu có trong giai đoạn kiểm toán (1/1/2022 – 31/12/2022), kiểm tra bằng chứng có hành động giải quyết sự cố từ nhân sự phù hợp.

Mẫu sự cố trong quá trình chạy tác vụ tự động

Với sự hỗ trợ của Trưởng Bộ phận Giám sát HTTT, đội kiểm toán đã nhận được một mẫu về quản lý sự cố trong năm 2022 gồm các thông tin liên quan như sau:

Người yêu cầu: Không xác định được

Sự cố bắt đầu: 15:34 ngày 19 tháng 12 năm 2022 Sự cố kết thúc: 17:42 ngày 19 tháng 12 năm 2022 Tiêu đề yêu cầu: EOP-92 Surge bị vô hiệu hóa

Giải quyết bởi: Quản lý sự cố (do chính sách bảo mật, KH không cung cấp thông tin về người đảm nhiệm ngoài vị trí của họ.)

Được cập nhật lần cuối bởi: Ông Vi Lê - Trưởng nhóm vận hành sản phẩm liên kết.

Kết luận : Với bằng chứng thể hiện sự cố đã được giải quyết bởi nhân sự phù hợp, đội KT CNTT đánh giá hiệu quả kiểm soát hiệu quả.

Tuy DN hiện đang thực hiện hiệu quả một số kiểm soát nhưng để ra ý kiến hiệu quả cho toàn bộ quy trình thì tất cả các kiểm soát đều phải hiệu quả. Qua đó, KT CNTT kết luận về kiểm soát vận hành CNTT như sau.

Kết luận cho quy trình quản lý vận hành tại DN: Không hiệu quả.

III. ĐÁNH GIÁ ĐIỂM MẠNH, ĐIỂM YẾU CỦA IB VÀ KIỂM TOÁN

1. Đối với IB

Điểm mạnh của IB: IB có sự hợp tác với kiểm toán và có quy trình quản lý CNTT tương đối tốt so với các chuẩn mực mà IB đang theo đuổi như: (1) Hệ thống chuyển đổi số: Oracle Netsuite Project Management; Autodesk Docs; Autodesk Build; Oracle Big Data; BIM Tools (Cài đặt tại từng máy); BIM Collaborate Pro; (2) Website Vimefulland: Oracle Netsuite; Amazon Simple Storage Service; Google Map Tiles API; QWEB; Cordova; Autodesk Docs

Điểm yếu của IB: Qua cuộc kiểm toán CNTT cho IB, có thể thấy sự tương đồng rõ rệt giữa các khó khăn mà IB này đang gặp phải với Big Data trùng khớp với insight của INTOSAI khi IB có những lổ hổng bảo mật trong việc phân quyền quản lý, phê duyệt và phát triển phần mềm.

Điều này có thể thấy rõ nhất qua quy trình quản lý truy cập hoàn toàn không hiệu quả, các nhà quản lý chưa hiểu rõ tầm quan trọng của việc phân quyền trong nội bộ bộ phận IT mà để các nhân sự kiêm nhiệm nhiều vai trò, có nhiều đặc quyền, vì vậy rủi ro là rất cao khi một nhân sự nắm cả quyền phát triển phần mềm lẫn thay đổi sau triển khai lên môi trường thực. Quy trình quản lý truy cập cũng chính là quy trình quan trọng nhất và liên đới tới 2 quy trình còn lại. Khi quyền hành của các nhân sự không được phân định rõ ràng và minh bạch, IB sẽ khó có thể giám sát và quản lý các PIC cho từng phần hành trong trường hợp xảy ra sự cố hoặc lỗi, từ đó giải quyết vấn sai trọng tâm. Ngoài ra, vấn đề còn nằm ở phòng tài chính. Sự phân bổ chi phí giữa các hạng mục đang có nhiều chênh lệch hoặc không tương xứng.

2. Đối với Khối kiểm toán nội bộ

Điểm mạnh, KT có sự phân chia công việc rõ ràng giữa phạm vi công việc của kiểm toán công nghệ thông tin và kiểm toán báo cáo tài chính. Kiểm toán công nghệ thông tin có chiến lược kiểm toán chặt chẽ và phù hợp với cuộc kiểm toán khi yêu cầu bằng chứng kiểm toán phù hợp với các thủ tục kiểm soát tương ứng với các rủi ro tiềm tàng trong quy trình của khách hàng. Điểm yếu, có thể thấy rõ trong cuộc kiểm toán này, đội Oracle Netsuite Việt Nam theo rất sát hướng dẫn của hãng Oracle Netsuite. Tuy nhiên, một số điểm yếu mà quy trình này đang có là EY đang phân bổ nguồn lực không hợp lý.

3. Hàm ý:

Đối với IB, Kết lại phần trên, IB đón sóng công nghệ khi đầu tư rất mạnh tay vào HTTT hàng đầu thế giới như Oracle Netsuite, Autodesk, Amazon Simple Storage Service tuy nhiên, việc hoàn thiện các hệ thống đó không chỉ đơn thuần là có cho IB các hệ thống lớn nhất mà còn là đội ngũ nhân viên của IB có khả năng quản lý và kiểm soát các hệ thống đó hiệu quả. IB nên có một buổi training giữa nhân sự phòng IT, phòng tài chính, phòng nhân sự với các chuyên gia an ninh mạng từ KT để có thể đưa ra giải pháp cuối cùng nhằm giải bài toán chi phí và bài toán phân quyền đang làm HT KSNB của IB suy yếu. Đối với KT: Trong cuộc kiểm toán này, không có nhiều bằng chứng kiểm toán để thu thập, quy trình thêm (ITRA Involvement) đội KT CNTT vào mỗi cuộc kiểm toán đang phụ thuộc phần lớn vào kiểm toán BCTC khiến cho đội CNTT không nắm bắt được sự cần thiết của việc kiểm toán CNTT. Để giải quyết điểm yếu này, IB nên xem xét lại về toàn bộ các bước và thêm vào một bước để các nhân sự chủ chốt của 2 bên có một buổi họp ngắn về sự cần thiết để ITRA tham gia vào mỗi cuộc kiểm toán nhằm để KT CNTT có thể tập trung vào các phần có rủi ro lớn hơn và phân bổ nguồn lực thời gian, chi phí, con người hợp lý hơn. Tuy nhiên, trong cuộc kiểm toán CNTT, phát hiện lỗ hổng bảo mật và quản lý truy cập không hiệu quả, gây rủi ro và khó khăn trong giám sát và quản lý.

3. Dữ liệu có cấu trúc và Dữ liệu phi cấu trúc

Dữ liệu có cấu trúc bao gồm ngày, tên, địa chỉ, số thẻ tín dụng, v.v. Lợi ích của chúng gắn liền với tính dễ sử dụng và truy cập, trong khi điểm yếu của nó là dữ liệu không linh hoạt. Nói ngắn gọn, dữ liệu cấu trúc là các dữ liệu mà người sử dụng có thể dễ phân loại được nó. Dữ liệu này cung cấp rõ ràng các thông tin về Họ tên, Tuổi, Nghề nghiệp của mẫu nghiên cứu.

Dữ liệu phi cấu trúc bao gồm văn bản, hoạt động trên thiết bị di động, bài đăng trên mạng xã hội, dữ liệu cảm biến Internet of Things (IoT), v.v. Lợi ích của chúng liên quan đến lợi thế về định dạng, tốc độ và dung lượng lưu trữ. Hầu hết những dữ liệu này khó có thể phân loại nó dưới dạng bảng vì mỗi mẫu có một đặc điểm khác nhau, ví dụ như trong hàng ngàn comment trên mạng xã hội, sẽ khó phân loại nó để phục vụ cho quá trình phân tích dưới dạng dữ liệu thô mà phải tìm cách để biến đổi dữ liệu về cùng một dạng để sử dụng. Qua đó ta thấy, dữ liệu phi cấu trúc là các loại dữ liệu mà không tuân theo cấu trúc dữ liệu truyền thống, ví dụ như dữ liệu văn bản, email, hình ảnh, video, âm thanh, tài liệu PDF, dữ liệu mạng xã hội, dữ liệu IoT (Internet of Things), vv. Big Data –bao gồm cả dữ liệu phi cấu trúc và dữ liệu có cấu trúc, thường không thể được lưu trữ trong các cơ sở dữ liệu quan hệ truyền thống và cần các công nghệ khác như NoSQL hoặc Hadoop để quản lý và xử lý.

Nắm bắt được sự bành trướng của dữ liệu phi cấu trúc đi lên cùng với sự phát triển của mạng xã hội, IB đã đầu tư HTTT lớn như Oracle, MySQL hay phổ biến nhất hiện nay là SAP để lưu trữ các thông tin này. Kết quả là sẽ thấy khi search trên google về một dich vụ thì tất cả các trang website bắt đầu đề xuất các sản phẩm thời trang, làm đẹp, khi ta di chuyển tới vùng ôn đới thì các dữ liệu địa lý này giúp các nhà kinh doanh áo ấm quảng cáo sản phẩm của mình vì họ biết là một KH tiềm năng của họ trong thời điểm đó, với dữ liệu địa lý đó.

5. Thành phần môi trường CNTT

Trước khi tìm hiểu thành phần môi trường CNTT, phải nắm rõ khái niệm về phần mềm và phần mềm con - hay còn gọi với thuật ngữ phần mềm thành phần. Phần lớn trong IB, một phần mềm lớn không hoàn toàn sản xuất ra các thông tin sử dụng cho BCTC. Bên cạnh đó, để sử dụng hiệu quả nguồn lực hữu hạn của cuộc kiểm toán (thời gian, nhân sự), phạm vi kiểm toán CNTT tại KT nhúng vào quy trình sẽ chỉ nằm trong các phần mềm con và các thành phần quan trọng, rủi ro cao có liên quan tới các lớp giao dịch quan trọng (Significant Classifications Of Transactions - SCOTs) và các quy trình để đóng sổ và lên BCTC (Financial Statement Closing Process - FCSP).

Môi trường CNTT có rất nhiều phần mềm thành phần. Sẽ bao gồm có mã nguồn đóng vai trò là những dòng code để hướng dẫn máy tính làm theo, logo, hướng dẫn sử dụng và thư viện. Phần mềm thành phần có nghĩa là những phần mềm con trong một phần mềm lớn, nó đóng vai trò thực hiện những nhiệm vụ nhỏ hơn trong một phần mềm lớn phức tạp hơn. Giả sử về vai trò của phần mềm thành phần như sau:

Trong ngành tài chính ngân hàng, một phần mềm lớn có thể là hệ thống quản lý ngân hàng (core banking system), và một phần mềm con trong hệ thống này có thể là phần mềm quản lý tài sản (asset management software). Phần mềm quản lý tài sản có chức năng giúp ngân hàng quản lý và theo dõi các tài sản của KH, từ đó có thể đưa ra các quyết định về đầu tư, rủi ro và lợi nhuận. Phần mềm này có thể được tích hợp vào hệ thống quản lý ngân hàng và sử dụng chung một cơ sở dữ liệu để đảm bảo tính toàn vẹn và độ chính xác của thông tin.

Những thành phần môi trường CNTT quan trọng trong một cuộc kiểm toán gồm có: Ứng dụng CNTT, giúp người dùng trực tiếp thực hiện nhiệm vụ nào đó, ví dụ như trình duyệt web, trò chơi. IT Application là một loại phần mềm được thiết kế để giải quyết các vấn đề kinh doanh thông qua sử dụng công nghệ thông tin. IT application bao gồm các chức năng khác nhau như quản lý dữ liệu, xử lý và phân tích dữ liệu, và cung cấp thông tin đến người dùng cuối. Nó được sử dụng rộng rãi trong các lĩnh vực như tài chính, bán lẻ, y tế, giáo dục và sản xuất.

Cơ sở dữ liệu - Database : DB là tập hợp các dữ liệu 1 cách có tổ chức, được lưu trữ trên máy chủ. DB là một tập hợp các dữ liệu có tổ chức được lưu trữ trong một hoặc nhiều máy chủ, cho phép các ứng dụng và người dùng truy xuất và thao tác trên chúng thông qua các giao thức cụ thể.” Hệ điều hành - Operating System:

Theo bài báo của Liu và cộng sự, OS đóng vai trò quan trọng trong việc quản lý các tài nguyên phần cứng của máy tính như bộ nhớ, bộ xử lý, ổ đĩa cứng, và các thiết bị ngoại vi khác. Nó cũng cung cấp các dịch vụ cho các chương trình ứng dụng khác để truy cập tài nguyên phần cứng và tương tác với người dùng. Ta có thể hiểu đơn giản OS là một trung gian cầu nối giữa phần cứng và phần mềm, chúng giúp phần cứng và phần mềm có thể tương tác với nhau và đáp ứng các yêu cầu của người sử dụng.

Phần mềm mạng - Network Software - giúp tăng cường tính bảo mật, hiệu quả hoạt động, và quản lý hệ thống mạng một cách nhanh chóng và thuận tiện hơn. Network software là một loại phần mềm được sử dụng để điều khiển và quản lý các kết nối mạng. Nó bao gồm nhiều thành phần khác nhau như phần mềm định tuyến, phần mềm tường lửa, phần mềm giám sát mạng, phần mềm quản lý và phân phối tài nguyên, và nhiều ứng dụng khác. Sử dụng network software có thể giúp tăng cường hiệu suất mạng, bảo mật hệ thống, và quản lý tài nguyên mạng một cách hiệu quả.

IV. QUY ĐỊNH VỀ CHUẨN MỰC KIỂM TOÁN VIÊN

1. Phạm vi áp dụng

1.1. Chuẩn mực kiểm toán này quy định và hướng dẫn trách nhiệm của kiểm toán viên và doanh nghiệp kiểm toán (sau đây gọi là “kiểm toán viên”) trong việc thiết kế và thực hiện các biện pháp xử lý đối với các rủi ro có sai sót trọng yếu mà kiểm toán viên đã xác định và đánh giá khi thực hiện kiểm toán báo cáo tài chính theo Chuẩn mực kiểm toán Việt Nam số 315.

1.2. Kiểm toán viên và doanh nghiệp kiểm toán (sau đây gọi là “kiểm toán viên”) phải tuân thủ các quy định và hướng dẫn của Chuẩn mực này trong quá trình thực hiện kiểm toán báo cáo tài chính.

Đơn vị được kiểm toán (khách hàng) và các bên sử dụng kết quả kiểm toán phải có những hiểu biết cần thiết về các quy định và hướng dẫn của Chuẩn mực này để phối hợp công việc với kiểm toán viên và doanh nghiệp kiểm toán, cũng như xử lý các mối quan hệ liên quan đến các thông tin đã được kiểm toán.

2. Mục tiêu

Mục tiêu của kiểm toán viên và doanh nghiệp kiểm toán là thu thập đầy đủ bằng chứng kiểm toán thích hợp liên quan đến các rủi ro có sai sót trọng yếu đã được đánh giá, thông qua việc thiết kế và thực hiện các biện pháp xử lý phù hợp đối với các rủi ro này.

3. Giải thích thuật ngữ

Trong các chuẩn mực kiểm toán Việt Nam, các thuật ngữ dưới đây được hiểu như sau:

3.1. Thử nghiệm cơ bản: Là thủ tục kiểm toán được thiết kế nhằm phát hiện các sai sót trọng yếu ở cấp độ cơ sở dẫn liệu. Các thử nghiệm cơ bản bao gồm:

3.1.1. Kiểm tra chi tiết (các nhóm giao dịch, số dư tài khoản và thông tin thuyết minh);

3.1.2. Thủ tục phân tích cơ bản.

3.2. Thử nghiệm kiểm soát: Là thủ tục kiểm toán được thiết kế nhằm đánh giá tính hữu hiệu của hoạt động kiểm soát trong việc ngăn ngừa, hoặc phát hiện và sửa chữa các sai sót trọng yếu ở cấp độ cơ sở dẫn liệu.

A. NỘI DUNG CHUẨN MỰC

1. Yêu cầu

1.1. Biện pháp xử lý tổng thể

Kiểm toán viên phải thiết kế và thực hiện các biện pháp xử lý tổng thể đối với các rủi ro có sai sót trọng yếu đã được đánh giá ở cấp độ báo cáo tài chính (xem hướng dẫn tại đoạn A1 - A3 Chuẩn mực này).

1.2. Thủ tục kiểm toán đối với rủi ro có sai sót trọng yếu đã được đánh giá ở cấp độ cơ sở dẫn liệu

1.2.1. Kiểm toán viên phải thiết kế và thực hiện các thủ tục kiểm toán tiếp theo với nội dung, lịch trình và phạm vi dựa vào kết quả đánh giá rủi ro có sai sót trọng yếu ở cấp độ cơ sở dẫn liệu (xem hướng dẫn tại đoạn A4 - A8 Chuẩn mực này).

1.2.2. Khi thiết kế các thủ tục kiểm toán tiếp theo, kiểm toán viên phải:

a. Xem xét các lý do đánh giá rủi ro có sai sót trọng yếu ở cấp độ cơ sở dẫn liệu cho từng nhóm giao dịch, số dư tài khoản và thông tin thuyết minh, bao gồm:

- Khả năng xảy ra sai sót trọng yếu do các đặc tính cụ thể của các nhóm giao dịch, số dư tài khoản, hoặc thông tin thuyết minh có liên quan (rủi ro tiềm tàng);

- Liệu việc đánh giá rủi ro có xem xét đến các kiểm soát có liên quan hay không (rủi ro kiểm soát), và nếu có, kiểm toán viên phải thu thập bằng chứng kiểm toán để xác định xem các kiểm soát có hoạt động hiệu quả không (có nghĩa là: kiểm toán viên dự định dựa vào tính hữu hiệu của hoạt động kiểm soát để xác định nội dung, lịch trình và phạm vi của các thử nghiệm cơ bản) (xem hướng dẫn tại đoạn A9 - A18 Chuẩn mực này);

b. Mức độ rủi ro được kiểm toán viên đánh giá càng cao thì càng phải thu thập bằng chứng kiểm toán thuyết phục hơn (xem hướng dẫn tại đoạn A19 Chuẩn mực này).

1.3. Thử nghiệm kiểm soát

1.3.1. Kiểm toán viên phải thiết kế và thực hiện các thử nghiệm kiểm soát để thu thập đầy đủ bằng chứng kiểm toán thích hợp về tính hữu hiệu của hoạt động kiểm soát có liên quan nếu:

a. Khi đánh giá rủi ro có sai sót trọng yếu ở cấp độ cơ sở dẫn liệu, kiểm toán viên kỳ vọng rằng các kiểm soát hoạt động hiệu quả (nghĩa là: kiểm toán viên có ý định dựa vào tính hữu hiệu của hoạt động kiểm soát để xác định nội dung, lịch trình và phạm vi của các thử nghiệm cơ bản); hoặc

b. Nếu chỉ thực hiện các thử nghiệm cơ bản thì không thể cung cấp đầy đủ bằng chứng kiểm toán thích hợp ở cấp độ cơ sở dẫn liệu (xem hướng dẫn tại đoạn A20 - A24 Chuẩn mực này).

1.3.2. Khi thiết kế và thực hiện thử nghiệm kiểm soát, kiểm toán viên càng tin tưởng vào tính hữu hiệu của hoạt động kiểm soát thì càng phải thu thập bằng chứng kiểm toán thuyết phục hơn (xem hướng dẫn tại đoạn A25 Chuẩn mực này).

Nội dung và phạm vi của thử nghiệm kiểm soát

1.3.3. Khi thiết kế và thực hiện thử nghiệm kiểm soát, kiểm toán viên phải:

a. Thực hiện các thủ tục kiểm toán khác kết hợp với thủ tục phỏng vấn nhằm thu thập bằng chứng kiểm toán về tính hữu hiệu của hoạt động kiểm soát, gồm:

- Các kiểm soát đã được thực hiện như thế nào tại các thời điểm liên quan trong suốt giai đoạn được kiểm toán;

- Các kiểm soát có được thực hiện nhất quán hay không;

- Các kiểm soát được ai thực hiện và thực hiện bằng cách nào (xem hướng dẫn tại đoạn A26 - A29 Chuẩn mực này)

b. Xác định liệu các kiểm soát được thử nghiệm có phụ thuộc vào các kiểm soát khác không (kiểm soát gián tiếp) và, nếu có, liệu có cần thiết thu thập bằng chứng kiểm toán chứng minh tính hữu hiệu của các hoạt động kiểm soát gián tiếp đó hay không (xem hướng dẫn tại đoạn A30 - A31 Chuẩn mực này).

1.4. Lịch trình thử nghiệm kiểm soát

1.4.1. Kiểm toán viên phải thực hiện thử nghiệm kiểm soát cho một thời điểm cụ thể, hoặc cho cả giai đoạn mà kiểm toán viên dự định dựa vào các kiểm soát đó, theo quy định tại đoạn 12 và 15 dưới đây, để đưa ra cơ sở thích hợp cho sự tin cậy của kiểm toán viên vào các kiểm soát đó (xem hướng dẫn tại đoạn A32 Chuẩn mực này).

Sử dụng bằng chứng kiểm toán thu thập được trong giai đoạn giữa kỳ

1.4.2. Nếu kiểm toán viên thu thập bằng chứng kiểm toán về tính hữu hiệu của hoạt động kiểm soát trong giai đoạn giữa kỳ, kiểm toán viên phải:

a. Thu thập bằng chứng kiểm toán về những thay đổi quan trọng trong các kiểm soát xảy ra sau giai đoạn giữa kỳ;

b. Xác định bằng chứng kiểm toán bổ sung cần thu thập cho giai đoạn còn lại (xem hướng dẫn tại đoạn A33 - A34 Chuẩn mực này).

Sử dụng bằng chứng kiểm toán thu thập được từ các cuộc kiểm toán trước

1.4.3. Để xác định xem việc sử dụng bằng chứng kiểm toán về tính hữu hiệu của hoạt động kiểm soát đã có từ các cuộc kiểm toán trước có phù hợp hay không và để xác định khoảng thời gian trước khi tiến hành lại thử nghiệm kiểm soát, kiểm toán viên phải xem xét những vấn đề sau:

a. Tính hữu hiệu của các thành phần khác của kiểm soát nội bộ, bao gồm môi trường kiểm soát, việc giám sát các kiểm soát và quy trình đánh giá rủi ro của đơn vị;

b. Các rủi ro phát sinh từ các đặc tính của kiểm soát, cho dù kiểm soát đó được thực hiện thủ công hay tự động;

c. Tính hữu hiệu của các kiểm soát chung về công nghệ thông tin;

d. Tính hữu hiệu của kiểm soát và việc thực hiện kiểm soát đó của đơn vị, bao gồm nội dung và mức độ của các sai lệch trong việc thực hiện kiểm soát đã ghi nhận trong các cuộc kiểm toán trước, và liệu có thay đổi nào về nhân sự có ảnh hưởng đáng kể đến việc thực hiện kiểm soát đó hay không;

e. Liệu việc không thay đổi một kiểm soát cụ thể có gây rủi ro khi hoàn cảnh đã thay đổi hay không;

f. Rủi ro có sai sót trọng yếu và mức độ tin cậy vào các kiểm soát (xem hướng dẫn tại đoạn A35 Chuẩn mực này).

1.4.4. Nếu kiểm toán viên dự định sử dụng bằng chứng kiểm toán về tính hữu hiệu của hoạt động kiểm soát cụ thể đã thu thập được từ cuộc kiểm toán trước, kiểm toán viên phải chứng minh rằng các bằng chứng đó vẫn còn giá trị bằng cách thu thập bằng chứng kiểm toán về việc liệu có phát sinh những thay đổi đáng kể trong các kiểm soát đó kể từ sau cuộc kiểm toán trước hay không. Kiểm toán viên phải thu thập bằng chứng này bằng cách thực hiện phỏng vấn kết hợp với quan sát hoặc điều tra, để xác nhận sự hiểu biết về các kiểm soát cụ thể đó, và:

a. Nếu có những thay đổi ảnh hưởng đến sự phù hợp của bằng chứng kiểm toán đã thu thập từ cuộc kiểm toán trước, kiểm toán viên phải thực hiện thử nghiệm kiểm soát trong cuộc kiểm toán hiện tại (xem hướng dẫn tại đoạn A36 Chuẩn mực này);

b. Nếu không có thay đổi nào, kiểm toán viên phải thực hiện thử nghiệm kiểm soát ít nhất một lần trong ba cuộc kiểm toán liên tục, và phải thực hiện thử nghiệm đối với một số kiểm soát trong mỗi cuộc kiểm toán để tránh tình trạng phải tiến hành thử nghiệm tất cả các kiểm soát mà kiểm toán viên dự định tin cậy vào trong một cuộc kiểm toán duy nhất mà không thực hiện thử nghiệm bất kỳ kiểm soát nào trong hai cuộc kiểm toán tiếp theo (xem hướng dẫn tại đoạn A37 - A39 Chuẩn mực này).

1.5. Các kiểm soát đối với rủi ro đáng kể

1.5.1. Nếu kiểm toán viên dự định tin cậy vào các kiểm soát đối với một rủi ro mà kiểm toán viên xác định là rủi ro đáng kể, kiểm toán viên phải thử nghiệm các kiểm soát đó trong giai đoạn hiện tại.

Đánh giá tính hữu hiệu của hoạt động kiểm soát

1.5.2. Khi đánh giá tính hữu hiệu của hoạt động kiểm soát liên quan, kiểm toán viên phải đánh giá liệu các sai sót được phát hiện từ các thử nghiệm cơ bản có cho thấy các kiểm soát không hoạt động hiệu quả hay không. Tuy nhiên, nếu các thử nghiệm cơ bản không phát hiện ra sai sót thì không có nghĩa là các kiểm soát có liên quan đến cơ sở dẫn liệu được thử nghiệm là hiệu quả (xem hướng dẫn tại đoạn A40 Chuẩn mực này).

1.5.3. Nếu phát hiện những sai lệch trong các kiểm soát mà kiểm toán viên dự định tin cậy vào, kiểm toán viên phải thực hiện những cuộc phỏng vấn cụ thể để tìm hiểu về những vấn đề này cũng như những hậu quả tiềm tàng, và phải xác định (xem hướng dẫn tại đoạn A41 Chuẩn mực này):

a. Các thử nghiệm kiểm soát đã thực hiện có cung cấp cơ sở thích hợp để kiểm toán viên tin cậy vào các kiểm soát đó hay không;

b. Có cần thực hiện các thử nghiệm kiểm soát bổ sung hay không; hoặc

c. Các rủi ro có khả năng xảy ra sai sót có cần được xử lý bằng cách áp dụng các thử nghiệm cơ bản hay không.

1.6. Thử nghiệm cơ bản

1.6.1. Cho dù kết quả đánh giá rủi ro có sai sót trọng yếu như thế nào, kiểm toán viên phải thiết kế và thực hiện các thử nghiệm cơ bản đối với từng nhóm giao dịch, số dư tài khoản và thông tin thuyết minh trọng yếu (xem hướng dẫn tại đoạn A42 - A47 Chuẩn mực này).

1.6.2. Kiểm toán viên phải xem xét có cần thực hiện các thủ tục xác nhận từ bên ngoài như các thử nghiệm cơ bản hay không (xem hướng dẫn tại đoạn A48 - A51 Chuẩn mực này).

Thử nghiệm cơ bản liên quan đến quy trình khóa sổ kế toán lập báo cáo tài chính

1.6.3. Thử nghiệm cơ bản của kiểm toán viên phải bao gồm các thủ tục kiểm toán liên quan đến quy trình khóa sổ kế toán lập báo cáo tài chính, như sau:

a. Đối chiếu số liệu trên báo cáo tài chính với số liệu trên sổ kế toán;

b. Kiểm tra các bút toán trọng yếu và các điều chỉnh khác được thực hiện trong quá trình lập và trình bày báo cáo tài chính (xem hướng dẫn tại đoạn A52 Chuẩn mực này).

1.7. Thử nghiệm cơ bản đối với các rủi ro đáng kể

Nếu kiểm toán viên đã xác định rủi ro có sai sót trọng yếu đã được đánh giá ở cấp độ cơ sở dẫn liệu là rủi ro đáng kể thì kiểm toán viên phải thực hiện các thử nghiệm cơ bản để xử lý rủi ro này. Nếu chỉ thực hiện thử nghiệm cơ bản đối với một rủi ro đáng kể thì thử nghiệm cơ bản phải bao gồm kiểm tra chi tiết (xem hướng dẫn tại đoạn A53 Chuẩn mực này).

1.8. Lịch trình thực hiện thử nghiệm cơ bản

1.8.1. Nếu thực hiện thử nghiệm cơ bản tại thời điểm kiểm toán giữa kỳ, để cung cấp cơ sở hợp lý cho việc mở rộng các kết luận kiểm toán từ giữa kỳ cho đến cuối kỳ, kiểm toán viên phải bao quát cả giai đoạn còn lại bằng cách (xem hướng dẫn tại đoạn A54 - A57 Chuẩn mực này):

a. Thực hiện các thử nghiệm cơ bản kết hợp với các thử nghiệm kiểm soát cho giai đoạn từ giữa kỳ đến cuối kỳ; hoặc

b. Chỉ thực hiện các thử nghiệm cơ bản bổ sung nếu kiểm toán viên xác định rằng như vậy là đủ.

1.8.2. Khi đánh giá rủi ro có sai sót trọng yếu tại thời điểm giữa kỳ, nếu phát hiện các sai sót không mong đợi thì kiểm toán viên phải đánh giá liệu có cần điều chỉnh việc đánh giá rủi ro liên quan và điều chỉnh nội dung, lịch trình hoặc phạm vi dự kiến của các thử nghiệm cơ bản cho giai đoạn còn lại hay không (xem hướng dẫn tại đoạn A58 Chuẩn mực này).

1.9. Mức độ đầy đủ của việc trình bày và thuyết minh báo cáo tài chính

Kiểm toán viên phải thực hiện các thủ tục kiểm toán để đánh giá liệu việc trình bày tổng thể báo cáo tài chính, bao gồm các thông tin thuyết minh liên quan, có phù hợp với khuôn khổ về lập và trình bày báo cáo tài chính được áp dụng hay không (xem hướng dẫn tại đoạn A59 Chuẩn mực này).

1.10. Đánh giá tính đầy đủ và thích hợp của bằng chứng kiểm toán

1.10.1. Căn cứ vào các thủ tục kiểm toán đã thực hiện và bằng chứng kiểm toán thu thập được, trước khi đưa ra kết luận về cuộc kiểm toán, kiểm toán viên phải xem xét việc đánh giá rủi ro có sai sót trọng yếu ở cấp độ cơ sở dẫn liệu có còn phù hợp hay không (xem hướng dẫn tại đoạn A60 - 61 Chuẩn mực này).

1.10.2. Kiểm toán viên phải đưa ra kết luận về tính đầy đủ, thích hợp của bằng chứng kiểm toán đã thu thập. Khi đưa ra ý kiến kiểm toán, kiểm toán viên phải xem xét tất cả bằng chứng kiểm toán liên quan, bất kể bằng chứng này chứng thực hay mâu thuẫn với các cơ sở dẫn liệu của báo cáo tài chính (xem hướng dẫn tại đoạn A62 Chuẩn mực này).

1.10.3. Nếu chưa thu thập được đầy đủ bằng chứng kiểm toán thích hợp liên quan đến một cơ sở dẫn liệu trọng yếu của báo cáo tài chính, kiểm toán viên phải cố gắng thu thập thêm bằng chứng kiểm toán. Nếu không thể thu thập được đầy đủ bằng chứng kiểm toán thích hợp, kiểm toán viên phải đưa ra ý kiến kiểm toán ngoại trừ hoặc từ chối đưa ra ý kiến về báo cáo tài chính.

1.11. Tài liệu, hồ sơ kiểm toán

1.11.1. Theo quy định tại đoạn 08 - 11 và hướng dẫn tại đoạn A6 Chuẩn mực kiểm toán Việt Nam số 230, kiểm toán viên phải lập và lưu lại trong hồ sơ kiểm toán:

a. Biện pháp xử lý tổng thể đối với các rủi ro có sai sót trọng yếu đã được đánh giá ở cấp độ báo cáo tài chính và nội dung, lịch trình, phạm vi các thủ tục kiểm toán tiếp theo đã thực hiện;

b. Mối liên hệ giữa các thủ tục kiểm toán đó với các rủi ro đã được đánh giá ở cấp độ cơ sở dẫn liệu;

c. Kết quả của các thủ tục kiểm toán, kể cả các kết luận, nếu các thủ tục này không rõ ràng (xem hướng dẫn tại đoạn A63 Chuẩn mực này).

1.11.2. Nếu kiểm toán viên dự định sử dụng bằng chứng kiểm toán về tính hữu hiệu của hoạt động kiểm soát thu thập được từ các cuộc kiểm toán trước, kiểm toán viên phải ghi chép trong hồ sơ kiểm toán các kết luận trên cơ sở tin cậy vào các kiểm soát đã được thử nghiệm trong cuộc kiểm toán trước.

1.11.3. Tài liệu, hồ sơ kiểm toán phải chứng minh rằng các số liệu trên báo cáo tài chính đã được đối chiếu khớp với các số liệu trên sổ kế toán.

B. HƯỚNG DẪN ÁP DỤNG

Khi thực hiện Chuẩn mực này cần tham khảo Chuẩn mực kiểm toán Việt Nam số 200.

1. Biện pháp xử lý tổng thể

(hướng dẫn đoạn 05 Chuẩn mực này)

1.1. Biện pháp xử lý tổng thể đối với các rủi ro có sai sót trọng yếu đã được đánh giá trong báo cáo tài chính có thể bao gồm:

1.1.1. Nhấn mạnh với nhóm kiểm toán về sự cần thiết phải duy trì thái độ hoài nghi nghề nghiệp;

1.1.2. Bổ nhiệm các thành viên nhóm kiểm toán có kinh nghiệm hoặc có kỹ năng chuyên môn đặc biệt, hoặc sử dụng chuyên gia;

1.1.3. Tăng cường giám sát;

1.1.4. Kết hợp các yếu tố không thể dự đoán trước khi lựa chọn các thủ tục kiểm toán tiếp theo cần thực hiện;

1.1.5. Thực hiện những thay đổi chung đối với nội dung, lịch trình và phạm vi các thủ tục kiểm toán, ví dụ: thực hiện các thử nghiệm cơ bản vào giai đoạn cuối kỳ thay vì giữa kỳ, hoặc thay đổi nội dung của các thủ tục kiểm toán nhằm thu thập được bằng chứng kiểm toán thuyết phục hơn.

1.2. Hiểu biết của kiểm toán viên về môi trường kiểm soát của đơn vị có ảnh hưởng đến việc đánh giá rủi ro có sai sót trọng yếu trong báo cáo tài chính và do đó cũng ảnh hưởng đến biện pháp xử lý tổng thể. Môi trường kiểm soát hữu hiệu có thể cho phép kiểm toán viên tin tưởng hơn vào kiểm soát nội bộ và độ tin cậy của bằng chứng kiểm toán bắt nguồn từ bên trong đơn vị và do đó, cho phép kiểm toán viên thực hiện một số thủ tục kiểm toán vào giai đoạn giữa kỳ thay vì cuối kỳ. Tuy nhiên, các khiếm khuyết trong môi trường kiểm soát lại có ảnh hưởng ngược lại, ví dụ, kiểm toán viên có thể thực hiện các thủ tục sau đối với môi trường kiểm soát không hiệu quả:

1.2.1. Thực hiện thêm các thủ tục kiểm toán vào giai đoạn cuối kỳ thay vì giai đoạn giữa kỳ;

1.2.2. Thu thập thêm bằng chứng kiểm toán từ các thử nghiệm cơ bản;

1.2.3. Mở rộng phạm vi kiểm toán ra nhiều địa điểm hơn.

1.3. Việc xem xét những vấn đề trên có ảnh hưởng quan trọng đến phương pháp tiếp cận chung của kiểm toán viên, ví dụ, tập trung vào thử nghiệm cơ bản (phương pháp cơ bản) hoặc phương pháp kết hợp thử nghiệm kiểm soát với thử nghiệm cơ bản (phương pháp kết hợp).

2. Thủ tục kiểm toán đối với rủi ro có sai sót trọng yếu đã được đánh giá ở cấp độ cơ sở dẫn liệu

Nội dung, lịch trình và phạm vi của các thủ tục kiểm toán tiếp theo (hướng dẫn đoạn 06 Chuẩn mực này)

2.1. Đánh giá của kiểm toán viên về các rủi ro phát hiện được ở cấp độ cơ sở dữ liệu cung cấp cơ sở nhằm lựa chọn phương pháp kiểm toán thích hợp để thiết kế và thực hiện các thủ tục kiểm toán tiếp theo. Ví dụ, kiểm toán viên có thể xác định rằng:

2.1.1. Chỉ cần thực hiện thử nghiệm kiểm soát, kiểm toán viên cũng có thể đưa ra biện pháp xử lý hiệu quả đối với rủi ro có sai sót trọng yếu đã được đánh giá cho một cơ sở dẫn liệu cụ thể;

2.1.2. Chỉ cần thực hiện các thử nghiệm cơ bản là phù hợp đối với các cơ sở dẫn liệu cụ thể, do đó, kiểm toán viên bỏ qua ảnh hưởng của các kiểm soát khi đánh giá rủi ro liên quan. Việc bỏ qua này có thể là do các thủ tục đánh giá rủi ro của kiểm toán viên đã không xác định được bất kỳ kiểm soát hữu hiệu nào liên quan đến cơ sở dẫn liệu, hoặc do việc thử nghiệm kiểm soát không hiệu quả, làm cho kiểm toán viên không có ý định dựa vào tính hữu hiệu của hoạt động kiểm soát để xác định nội dung, lịch trình và phạm vi của các thử nghiệm cơ bản; hoặc

2.1.3. Phương pháp kết hợp thử nghiệm kiểm soát và thử nghiệm cơ bản là một phương pháp hữu hiệu.

Tuy nhiên, theo quy định tại đoạn 18 Chuẩn mực này, dù lựa chọn phương pháp nào thì kiểm toán viên vẫn phải thiết kế và thực hiện các thử nghiệm cơ bản cho từng nhóm giao dịch, số dư tài khoản và thông tin thuyết minh trọng yếu.

2.2. Nội dung của một thủ tục kiểm toán phản ánh mục tiêu của thủ tục đó (ví dụ, thử nghiệm kiểm soát hoặc thử nghiệm cơ bản) và loại thủ tục (ví dụ, kiểm tra, quan sát, phỏng vấn, xác nhận, tính toán lại, thực hiện lại hay thủ tục phân tích). Nội dung của thủ tục kiểm toán là vấn đề quan trọng nhất cần xác định sau khi đã đánh giá rủi ro.

2.3. Lịch trình của thủ tục kiểm toán là thời điểm tiến hành thủ tục kiểm toán, giai đoạn hoặc thời điểm mà bằng chứng kiểm toán được áp dụng.

2.4. Phạm vi của thủ tục kiểm toán là số lượng thủ tục kiểm toán cần thực hiện, ví dụ cỡ mẫu hay số lần quan sát một kiểm soát.

2.5. Việc thiết kế và thực hiện các thủ tục kiểm toán tiếp theo, mà nội dung, lịch trình và phạm vi của các thủ tục này được xác định dựa trên cơ sở đánh giá rủi ro có sai sót trọng yếu ở cấp độ cơ sở dẫn liệu, cung cấp mối liên kết rõ ràng giữa các thủ tục kiểm toán tiếp theo và việc đánh giá rủi ro của kiểm toán viên.

Thủ tục kiểm toán trên cơ sở đánh giá rủi ro ở cấp độ cơ sở dẫn liệu (hướng dẫn đoạn 07a. Chuẩn mực này)

Nội dung

2.6. Các rủi ro được kiểm toán viên đánh giá có thể ảnh hưởng đến cả loại thủ tục kiểm toán cần thực hiện và việc kết hợp các thủ tục kiểm toán. Ví dụ, khi kiểm toán viên đánh giá có rủi ro cao, ngoài việc kiểm tra tài liệu, kiểm toán viên có thể xác nhận với một bên thứ ba về sự đầy đủ của các điều khoản hợp đồng. Ngoài ra, các thủ tục kiểm toán nhất định có thể thích hợp đối với một số cơ sở dẫn liệu này hơn là đối với các cơ sở dẫn liệu khác. Ví dụ, liên quan đến doanh thu, các thử nghiệm kiểm soát có thể là biện pháp thích hợp nhất để xử lý rủi ro có sai sót về cơ sở dẫn liệu “tính đầy đủ”, trong khi các thử nghiệm cơ bản lại có thể là biện pháp thích hợp nhất để xử lý rủi ro có sai sót về cơ sở dẫn liệu “tính phát sinh”.

2.7. Khi xác định nội dung thủ tục kiểm toán, kiểm toán viên cần xem xét lý do đánh giá rủi ro. Ví dụ, nếu một rủi ro được đánh giá là thấp chỉ do đặc trưng riêng của nhóm giao dịch mà không xem xét đến các kiểm soát liên quan thì kiểm toán viên có thể xác định rằng chỉ cần thực hiện các thủ tục phân tích cơ bản cũng có thể cung cấp đầy đủ bằng chứng kiểm toán thích hợp. Ngược lại, nếu rủi ro được đánh giá là thấp do kiểm soát nội bộ hiệu quả, và kiểm toán viên dự định sẽ thiết kế các thử nghiệm cơ bản căn cứ vào hiệu quả kiểm soát, thì kiểm toán viên sẽ thực hiện các thử nghiệm kiểm soát theo quy định tại đoạn 08a. Chuẩn mực này. Ví dụ cho trường hợp này là các nhóm giao dịch tương đối đồng nhất, không phức tạp, được xử lý thường xuyên và được hệ thống thông tin của đơn vị kiểm soát.

Lịch trình

2.8. Kiểm toán viên có thể thực hiện thử nghiệm kiểm soát hoặc thử nghiệm cơ bản ở thời điểm kiểm toán giữa kỳ hay cuối kỳ. Rủi ro có sai sót trọng yếu càng cao thì kiểm toán viên càng cần phải thực hiện các thủ tục cơ bản gần hoặc tại thời điểm cuối kỳ hơn là vào thời điểm trước đó, hoặc thực hiện các thủ tục kiểm toán mà không cần thông báo trước về nội dung và thời gian (ví dụ, thực hiện các thủ tục kiểm toán tại một số địa điểm được chọn mà không thông báo trước). Điều này đặc biệt thích hợp khi lựa chọn các thủ tục kiểm toán để xử lý rủi ro có gian lận. Ví dụ, khi phát hiện rủi ro cố ý gây sai sót hoặc thao túng số liệu, kiểm toán viên có thể kết luận rằng các thủ tục kiểm toán để mở rộng các kết luận kiểm toán từ thời điểm kiểm toán giữa kỳ đến cuối kỳ sẽ không hiệu quả.

2.9. Việc thực hiện các thủ tục kiểm toán vào thời điểm trước khi kết thúc kỳ kế toán có thể giúp kiểm toán viên phát hiện sớm các vấn đề quan trọng và do đó có thể giải quyết các vấn đề đó với sự hỗ trợ của Ban Giám đốc đơn vị được kiểm toán hoặc thiết kế phương pháp kiểm toán hiệu quả để giải quyết các vấn đề này.

2.10. Một số thủ tục kiểm toán nhất định chỉ có thể được thực hiện vào giai đoạn cuối kỳ hoặc sau giai đoạn cuối kỳ, ví dụ:

2.10.1. Đối chiếu số liệu trên báo cáo tài chính với số liệu trên sổ kế toán;

2.10.2. Kiểm tra các khoản mục được điều chỉnh trong quá trình lập và trình bày báo cáo tài chính;

2.10.3. Các thủ tục kiểm toán để xử lý rủi ro mà tại thời điểm cuối kỳ, đơn vị được kiểm toán lại ký kết những hợp đồng bán hàng không minh bạch hoặc có các giao dịch không được quyết toán.

2.11. Quyết định của kiểm toán viên về thời điểm thực hiện các thủ tục kiểm toán chịu ảnh hưởng của các yếu tố liên quan, bao gồm:

2.11.1. Môi trường kiểm soát;

2.11.2. Thời điểm có thông tin thích hợp (ví dụ, dữ liệu trong các tệp điện tử sau đó có thể bị điều chỉnh, hoặc các thủ tục cần quan sát có thể chỉ diễn ra tại những thời điểm nhất định);

2.11.3. Bản chất của rủi ro (ví dụ, nếu có rủi ro doanh thu bị khai tăng để đáp ứng các mức lợi nhuận kỳ vọng bằng cách tạo ra những hợp đồng bán hàng giả mạo sau khi kết thúc kỳ kế toán, kiểm toán viên có thể kiểm tra các hợp đồng hiện có vào thời điểm kết thúc kỳ kế toán);

2.11.4. Giai đoạn hoặc thời điểm liên quan đến bằng chứng kiểm toán.

Phạm vi

2.12. Kiểm toán viên xác định phạm vi của thủ tục kiểm toán được xét đoán là cần thiết sau khi cân nhắc mức trọng yếu, các rủi ro được đánh giá và mức độ đảm bảo mà kiểm toán viên dự kiến đạt được. Khi kiểm toán viên đạt được mục đích nhờ thực hiện kết hợp các thủ tục kiểm toán thì phạm vi của mỗi thủ tục được xem xét riêng rẽ. Nói chung, kiểm toán viên cần mở rộng phạm vi các thủ tục kiểm toán nếu rủi ro có sai sót trọng yếu tăng lên. Ví dụ, để xử lý rủi ro có sai sót trọng yếu do gian lận, kiểm toán viên có thể cần tăng cỡ mẫu hoặc thực hiện các thủ tục phân tích cơ bản ở mức độ chi tiết hơn. Tuy nhiên, việc mở rộng phạm vi thủ tục kiểm toán chỉ có hiệu quả nếu bản thân thủ tục kiểm toán là phù hợp với rủi ro đặc thù.

2.13. Việc sử dụng các kỹ thuật kiểm toán với sự hỗ trợ của máy tính (CAATs) có thể cho phép kiểm tra nhiều giao dịch điện tử và dữ liệu trong các tài khoản điện tử. Kỹ thuật này có thể hữu ích khi kiểm toán viên quyết định điều chỉnh phạm vi kiểm tra, ví dụ khi xử lý rủi ro có sai sót trọng yếu do gian lận. Các kỹ thuật này có thể được sử dụng để chọn mẫu từ các tệp tin điện tử chính để phân loại thành các giao dịch đặc thù hoặc kiểm tra tổng thể thay vì kiểm tra mẫu.

Lưu ý khi kiểm toán các đơn vị trong lĩnh vực công

2.14. Khi kiểm toán các đơn vị trong lĩnh vực công, các quy định của Kiểm toán Nhà nước và bất kỳ yêu cầu kiểm toán đặc biệt nào khác có thể ảnh hưởng đến quyết định của kiểm toán viên về nội dung, lịch trình và phạm vi của các thủ tục kiểm toán tiếp theo.

Lưu ý khi kiểm toán các đơn vị nhỏ

2.15. Đối với các đơn vị nhỏ, kiểm toán viên có thể không xác định được nhiều hoạt động kiểm soát, hoặc đơn vị có thể có rất ít tài liệu thể hiện sự tồn tại hoặc vận hành của các hoạt động kiểm soát đó. Trong trường hợp này, việc thực hiện các thủ tục kiểm toán tiếp theo mà chủ yếu là thử nghiệm cơ bản sẽ có thể hiệu quả hơn. Tuy nhiên, trong một số trường hợp hãn hữu, kiểm toán viên sẽ không thể thu thập được đầy đủ bằng chứng kiểm toán thích hợp nếu không có các hoạt động kiểm soát hay những thành phần khác của kiểm soát.

Đánh giá mức độ rủi ro cao (hướng dẫn đoạn 07b. Chuẩn mực này)

2.16. Khi cần thu thập bằng chứng kiểm toán thuyết phục hơn do mức độ rủi ro được đánh giá cao hơn, kiểm toán viên có thể tăng số lượng bằng chứng, hoặc thu thập bằng chứng thích hợp hơn hoặc đáng tin cậy hơn, bằng cách tập trung thu thập bằng chứng từ bên thứ ba hoặc thu thập bằng chứng chứng thực từ một số nguồn độc lập.

Thử nghiệm kiểm soát

Thiết kế và thực hiện thử nghiệm kiểm soát (hướng dẫn đoạn 08 Chuẩn mực này)

2.17. Các thử nghiệm kiểm soát chỉ được thực hiện đối với những kiểm soát mà kiểm toán viên xác định rằng được thiết kế phù hợp để ngăn chặn hoặc phát hiện và sửa chữa một sai sót trọng yếu trong một cơ sở dẫn liệu. Nếu các kiểm soát khác nhau về cơ bản được thực hiện tại những thời điểm khác nhau trong giai đoạn được kiểm toán thì mỗi kiểm soát đó phải được xem xét riêng.

2.18. Việc kiểm tra tính hữu hiệu của hoạt động kiểm soát khác với việc tìm hiểu và đánh giá về mặt thiết kế và thực hiện của các kiểm soát đó. Tuy nhiên, kiểm toán viên vẫn có thể sử dụng các loại thủ tục kiểm toán giống nhau để kiểm tra. Vì thế, kiểm toán viên có thể quyết định cách kiểm tra hiệu quả là kiểm tra tính hữu hiệu của hoạt động kiểm soát đồng thời với việc đánh giá về mặt thiết kế và xác định rằng các kiểm soát đó đã được thực hiện.

2.19. Mặc dù một số thủ tục đánh giá rủi ro có thể không được thiết kế để làm thử nghiệm kiểm soát nhưng các thủ tục đó cũng có thể cung cấp bằng chứng kiểm toán về tính hữu hiệu của hoạt động kiểm soát và, do đó, đóng vai trò như thử nghiệm kiểm soát. Ví dụ, các thủ tục đánh giá rủi ro của kiểm toán viên có thể bao gồm:

2.19.1. Phỏng vấn về việc sử dụng dự toán của Ban Giám đốc;

2.19.2. Quan sát việc Ban Giám đốc so sánh chi phí dự tính và chi phí thực tế hàng tháng;

2.19.3. Kiểm tra các báo cáo để phát hiện biến động giữa số liệu thực tế với kế hoạch.

Các thủ tục kiểm toán này không chỉ cung cấp những hiểu biết về công tác lập kế hoạch của đơn vị và liệu kế hoạch đó đã được thực hiện hay chưa, mà còn có thể cung cấp bằng chứng kiểm toán về tính hữu hiệu của quy trình lập kế hoạch của đơn vị trong việc ngăn ngừa và phát hiện các sai sót trọng yếu trong phân loại chi phí.

2.20. Kiểm toán viên có thể thiết kế một thử nghiệm kiểm soát để thực hiện đồng thời với việc kiểm tra chi tiết cùng một giao dịch. Mặc dù mục tiêu của thử nghiệm kiểm soát khác với mục tiêu của kiểm tra chi tiết nhưng có thể thực hiện đồng thời cả hai thủ tục này đối với cùng một giao dịch, gọi là “thử nghiệm kép”. Ví dụ, kiểm toán viên có thể thiết kế và đánh giá các kết quả kiểm tra một hóa đơn nhằm xác định xem hóa đơn đó đã được phê duyệt hay chưa, đồng thời cung cấp bằng chứng kiểm toán chi tiết về giao dịch đó. Thử nghiệm kép được thiết kế và đánh giá bằng cách xem xét riêng rẽ mỗi mục tiêu kiểm toán nêu trên.

2.21. Theo đoạn 30 Chuẩn mực kiểm toán Việt Nam số 315, trong một số trường hợp, kiểm toán viên có thể nhận thấy rằng không thể thiết kế các thử nghiệm cơ bản một cách hiệu quả mà bản thân các thử nghiệm này cung cấp đầy đủ bằng chứng kiểm toán thích hợp ở cấp độ cơ sở dẫn liệu. Tình huống này có thể xảy ra khi một đơn vị điều hành hoạt động kinh doanh bằng công nghệ thông tin và không ghi lại hoặc không lưu trữ bằng tài liệu mà chỉ thông qua hệ thống công nghệ thông tin. Trong trường hợp này, kiểm toán viên phải thực hiện các thử nghiệm kiểm soát có liên quan theo yêu cầu trong đoạn 08b. Chuẩn mực này.

Bằng chứng kiểm toán và độ tin cậy dự tính (hướng dẫn đoạn 09 Chuẩn mực này)

2.22. Kiểm toán viên có thể đạt được mức độ đảm bảo cao hơn về tính hữu hiệu của hoạt động kiểm soát khi phương pháp kiểm toán chủ yếu sử dụng thử nghiệm kiểm soát, đặc biệt là khi không thể thu thập đầy đủ bằng chứng kiểm toán thích hợp chỉ từ các thử nghiệm cơ bản.

Nội dung và phạm vi của thử nghiệm kiểm soát

Các thủ tục kiểm toán khác kết hợp với thủ tục phỏng vấn (hướng dẫn đoạn 10a. Chuẩn mực này)

2.23. Chỉ thực hiện thủ tục phỏng vấn thôi thì không đủ để kiểm tra tính hữu hiệu của các kiểm soát, do đó, kiểm toán viên cần thực hiện các thủ tục kiểm toán khác kết hợp với phỏng vấn. Thủ tục phỏng vấn kết hợp với kiểm tra hoặc thực hiện lại có thể cung cấp sự đảm bảo cao hơn so với việc kết hợp thủ tục phỏng vấn và quan sát vì quan sát chỉ phù hợp tại thời điểm diễn ra giao dịch.

2.24. Nội dung của một kiểm soát cụ thể sẽ ảnh hưởng đến loại thủ tục cần thực hiện để thu thập bằng chứng kiểm toán về tính hoạt động hữu hiệu của kiểm soát đó. Ví dụ, nếu tính hoạt động hữu hiệu được chứng minh dưới hình thức văn bản thì kiểm toán viên có thể quyết định kiểm tra tài liệu của đơn vị để thu thập bằng chứng kiểm toán về tính hoạt động hữu hiệu đó. Tuy nhiên, đối với các kiểm soát khác, tài liệu về hoạt động có thể sẽ không có sẵn hoặc không thích hợp. Ví dụ, có thể không có tài liệu về hoạt động của một số yếu tố của môi trường kiểm soát như việc phân quyền, phân nhiệm, hoặc không có tài liệu về một số loại hoạt động kiểm soát như các hoạt động kiểm soát được xử lý bằng máy tính. Trong trường hợp này, kiểm toán viên có thể thu thập bằng chứng về tính hoạt động hữu hiệu bằng cách phỏng vấn kết hợp với các thủ tục kiểm toán khác, như quan sát hoặc sử dụng các kỹ thuật kiểm toán với sự hỗ trợ của máy tính.

Phạm vi của thử nghiệm kiểm soát

2.25. Kiểm toán viên có thể phải mở rộng phạm vi thử nghiệm đối với một kiểm soát khi cần thu thập bằng chứng kiểm toán thuyết phục hơn về tính hữu hiệu của kiểm soát đó. Ngoài mức độ tin cậy vào các kiểm soát, kiểm toán viên có thể xem xét các vấn đề sau khi xác định phạm vi của thử nghiệm kiểm soát:

2.25.1. Tần suất thực hiện kiểm soát của đơn vị trong suốt giai đoạn;

2.25.2. Khoảng thời gian trong giai đoạn kiểm toán mà kiểm toán viên tin cậy vào tính hữu hiệu của hoạt động kiểm soát;

2.25.3. Tỷ lệ sai lệch dự kiến của một kiểm soát;

2.25.4. Tính thích hợp và độ tin cậy của bằng chứng kiểm toán cần thu thập về tính hữu hiệu của hoạt động kiểm soát ở cấp độ cơ sở dẫn liệu;

2.25.5. Phạm vi của bằng chứng kiểm toán cần thu thập được từ các thử nghiệm kiểm soát khác liên quan đến cơ sở dẫn liệu đó.

Chuẩn mực kiểm toán Việt Nam số 530 quy định và hướng dẫn chi tiết hơn về phạm vi thử nghiệm.

2.26. Do tính nhất quán vốn có của quy trình xử lý công nghệ thông tin, kiểm toán viên có thể không cần phải mở rộng phạm vi thử nghiệm đối với một kiểm soát tự động. Một kiểm soát tự động sẽ được thực hiện một cách nhất quán nếu chương trình (bao gồm các bảng biểu, tệp tin hay dữ liệu cố định được sử dụng trong chương trình) không thay đổi. Nếu kiểm toán viên xác định là một kiểm soát tự động vận hành đúng như dự kiến (việc xác định có thể được thực hiện tại thời điểm bắt đầu thực hiện kiểm soát hoặc một thời điểm khác) thì kiểm toán viên có thể xem xét thực hiện các thử nghiệm để xác định rằng kiểm soát đó tiếp tục vận hành hiệu quả. Các thử nghiệm đó có thể bao gồm việc xác định:

2.26.1. Các thay đổi của chương trình sẽ không được thực hiện khi chưa có sự kiểm soát thích hợp đối với các thay đổi đó;

2.26.2. Phiên bản chính thức của chương trình được sử dụng để xử lý giao dịch;

2.26.3. Các kiểm soát chung khác có liên quan được thực hiện hiệu quả.

Các thử nghiệm này cũng có thể bao gồm việc xác định rằng những thay đổi của chương trình chưa được triển khai, như trường hợp đơn vị sử dụng các gói phần mềm ứng dụng mà không chỉnh sửa hoặc bảo trì các phần mềm này. Ví dụ, kiểm toán viên có thể kiểm tra hồ sơ quản trị về an ninh công nghệ thông tin để thu thập được bằng chứng kiểm toán cho thấy chưa có sự truy cập trái phép nào trong suốt giai đoạn.

Thử nghiệm đối với các kiểm soát gián tiếp (hướng dẫn đoạn 10b. Chuẩn mực này)

2.27. Trong một số trường hợp, kiểm toán viên có thể cần thu thập bằng chứng kiểm toán để chứng minh tính hữu hiệu của hoạt động kiểm soát gián tiếp. Ví dụ, khi kiểm toán viên quyết định kiểm tra tính hữu hiệu của việc người sử dụng soát xét báo cáo ngoại lệ về việc bán hàng vượt hạn mức nợ cho phép, thì việc soát xét của người sử dụng và các hoạt động liên quan sau đó là các kiểm soát được kiểm toán viên xác định là liên quan trực tiếp. Các kiểm soát đối với tính chính xác của thông tin trong báo cáo (ví dụ, kiểm soát chung về công nghệ thông tin) được coi là các kiểm soát gián tiếp.

2.28. Do tính nhất quán vốn có của quy trình xử lý công nghệ thông tin, bằng chứng kiểm toán về việc thực hiện một ứng dụng kiểm soát tự động, khi được xem xét kết hợp với các bằng chứng kiểm toán về tính hữu hiệu của hoạt động kiểm soát chung của đơn vị (đặc biệt là các kiểm soát đối với sự thay đổi), cũng có thể cung cấp bằng chứng kiểm toán quan trọng về tính hữu hiệu của hoạt động kiểm soát đó.

Lịch trình thử nghiệm kiểm soát

Khoảng thời gian tin cậy dự tính (hướng dẫn đoạn 11 Chuẩn mực này)

2.29. Bằng chứng kiểm toán chỉ liên quan đến một thời điểm vẫn có thể là đầy đủ cho mục đích kiểm toán, ví dụ khi thử nghiệm kiểm soát đối với việc kiểm kê hàng tồn kho của đơn vị vào cuối kỳ kế toán. Mặt khác, nếu kiểm toán viên dự định dựa vào một kiểm soát trong cả giai đoạn, kiểm toán viên cần thực hiện các thử nghiệm có khả năng cung cấp bằng chứng kiểm toán về việc kiểm soát đó được thực hiện hiệu quả tại những thời điểm liên quan trong giai đoạn đó. Những thử nghiệm loại này có thể bao gồm thử nghiệm đối với việc giám sát các kiểm soát của đơn vị.

Sử dụng bằng chứng kiểm toán thu thập được trong giai đoạn giữa kỳ (hướng dẫn đoạn 12b. Chuẩn mực này)

2.30. Khi xác định bằng chứng kiểm toán bổ sung cần thu thập về các kiểm soát được thực hiện trong giai đoạn từ giữa kỳ đến cuối kỳ, kiểm toán viên cần xem xét các yếu tố bao gồm:

2.31.1. Mức độ nghiêm trọng của các rủi ro có sai sót trọng yếu đã được đánh giá ở cấp độ cơ sở dẫn liệu;

2.31.2. Các kiểm soát cụ thể đã được thử nghiệm trong giai đoạn giữa kỳ, cũng như những thay đổi quan trọng đối với các kiểm soát đó kể từ khi được thử nghiệm, kể cả những thay đổi về hệ thống thông tin, quy trình xử lý và nhân sự;

2.31.3. Mức độ thu thập được bằng chứng kiểm toán về tính hữu hiệu của các hoạt động kiểm soát đó;

2.31.4. Khoảng thời gian còn lại của giai đoạn kiểm toán;

2.31.5. Phạm vi thử nghiệm cơ bản mà kiểm toán viên dự định giảm bớt dựa vào mức độ tin cậy của các kiểm soát;

2.31.6. Môi trường kiểm soát.

2.32. Kiểm toán viên có thể thu thập bằng chứng kiểm toán bổ sung bằng cách thực hiện thử nghiệm kiểm soát cho giai đoạn còn lại hoặc kiểm tra công tác giám sát các kiểm soát của đơn vị được kiểm toán.

Sử dụng bằng chứng kiểm toán thu thập được từ các cuộc kiểm toán trước (hướng dẫn đoạn 13 Chuẩn mực này)

2.33. Trong một số trường hợp nhất định, bằng chứng kiểm toán thu thập được từ các cuộc kiểm toán trước cũng có thể cung cấp bằng chứng cho cuộc kiểm toán hiện tại nếu kiểm toán viên thực hiện các thủ tục kiểm toán để chứng minh các bằng chứng kiểm toán năm trước vẫn tiếp tục phù hợp cho cuộc kiểm toán hiện tại. Ví dụ, khi thực hiện cuộc kiểm toán trước, kiểm toán viên đã xác định là một kiểm soát tự động của đơn vị đã vận hành như dự kiến thì trong cuộc kiểm toán hiện tại, kiểm toán viên có thể thu thập bằng chứng kiểm toán để xác định liệu có thay đổi nào trong kiểm soát tự động này có thể ảnh hưởng đến hiệu quả kiểm soát hay không, thông qua việc phỏng vấn Ban Giám đốc và kiểm tra sổ theo dõi để xác định các kiểm soát nào đã bị thay đổi. Bằng chứng kiểm toán về những thay đổi này có thể giúp kiểm toán viên quyết định tăng hoặc giảm bằng chứng kiểm toán cần thu thập trong giai đoạn hiện tại để đánh giá tính hữu hiệu của hoạt động kiểm soát.

Các kiểm soát đã thay đổi kể từ các cuộc kiểm toán trước (hướng dẫn đoạn 14a. Chuẩn mực này)

2.34. Các thay đổi có thể làm ảnh hưởng đến tính thích hợp của bằng chứng kiểm toán đã thu thập được từ các cuộc kiểm toán trước, làm cho các bằng chứng này không còn tiếp tục được kiểm toán viên tin cậy trong cuộc kiểm toán hiện tại. Ví dụ, các thay đổi trong hệ thống cho phép đơn vị nhận một báo cáo mới từ hệ thống có thể không ảnh hưởng đến tính thích hợp của bằng chứng kiểm toán đã thu thập được từ cuộc kiểm toán trước nhưng các thay đổi làm cho dữ liệu được cộng lũy kế hoặc được tính toán theo một cách khác sẽ ảnh hưởng đến tính thích hợp của bằng chứng kiểm toán đó.

Các kiểm soát không thay đổi kể từ các cuộc kiểm toán trước (hướng dẫn đoạn 14b. Chuẩn mực này)

2.35. Kiểm toán viên cần sử dụng xét đoán chuyên môn để quyết định liệu có thể tiếp tục tin tưởng vào những bằng chứng kiểm toán đã thu thập được trong các cuộc kiểm toán trước đối với các kiểm soát sau:

2.35.1. Các kiểm soát không có sự thay đổi kể từ lần thử nghiệm cuối cùng;

2.35.2. Các kiểm soát không làm giảm bớt rủi ro đáng kể.

Kiểm toán viên cũng sử dụng xét đoán chuyên môn để xác định khoảng thời gian thích hợp để kiểm tra lại các kiểm soát, tuy nhiên theo quy định tại đoạn 14b. Chuẩn mực này, việc này cần được thực hiện ít nhất một lần trong 3 năm liên tục.

2.36. Nói chung, rủi ro có sai sót trọng yếu càng cao, hoặc mức độ tin cậy vào kiểm soát càng lớn, thì thời gian giữa các lần kiểm tra (nếu có) càng ngắn. Các yếu tố có thể rút ngắn thời gian kiểm tra lại một kiểm soát, hoặc làm cho kiểm toán viên quyết định không tin cậy vào bằng chứng kiểm toán thu thập được từ các cuộc kiểm toán trước, bao gồm:

2.36.1. Môi trường kiểm soát yếu kém;

2.36.2. Sự yếu kém của công tác giám sát các kiểm soát;

2.36.3. Các kiểm soát liên quan có một yếu tố quan trọng được thực hiện thủ công;

2.36.4. Thay đổi nhân sự có ảnh hưởng đáng kể đến việc ứng dụng một kiểm soát;

2.36.5. Tình hình thay đổi dẫn đến sự cần thiết phải thay đổi về kiểm soát;

2.36.6. Yếu kém trong các kiểm soát chung về công nghệ thông tin.

2.37. Khi kiểm toán viên dự định tin cậy vào bằng chứng kiểm toán thu thập được từ các cuộc kiểm toán trước đối với một số kiểm soát, việc kiểm tra một số trong các kiểm soát đó ở từng cuộc kiểm toán sẽ cung cấp thông tin chứng thực về tính hữu hiệu liên tục của môi trường kiểm soát. Việc này giúp kiểm toán viên quyết định liệu có thể tin cậy vào bằng chứng kiểm toán đã thu thập được từ các cuộc kiểm toán trước hay không.

Đánh giá tính hữu hiệu của hoạt động kiểm soát (hướng dẫn đoạn 16 - 17 Chuẩn mực này)

2.38. Một sai sót trọng yếu được kiểm toán viên phát hiện là dấu hiệu rõ ràng về sự tồn tại của một khiếm khuyết nghiêm trọng trong kiểm soát nội bộ.

2.39. Khái niệm tính hữu hiệu của hoạt động kiểm soát vẫn cho thấy có thể có những sai lệch trong cách thức triển khai các kiểm soát của đơn vị. Những sai lệch đó có thể do các yếu tố như thay đổi nhân sự chủ chốt, sự dao động đáng kể về số lượng giao dịch theo mùa vụ và các nhầm lẫn chủ quan. Tỷ lệ sai lệch được phát hiện, đặc biệt là khi so với tỷ lệ sai lệch dự kiến, có thể cho thấy không thể tin cậy vào kiểm soát để giảm rủi ro ở cấp độ cơ sở dẫn liệu xuống mức độ mà kiểm toán viên đánh giá.

Thử nghiệm cơ bản (hướng dẫn đoạn 18 Chuẩn mực này)

2.40. Theo quy định tại đoạn 18 Chuẩn mực này, kiểm toán viên cần thiết kế và thực hiện các thử nghiệm cơ bản cho mỗi nhóm giao dịch, số dư tài khoản và thông tin thuyết minh trọng yếu, cho dù kết quả đánh giá rủi ro có sai sót trọng yếu như thế nào. Quy định này xuất phát từ thực tế là: a. việc đánh giá rủi ro của kiểm toán viên là mang tính xét đoán, do đó kiểm toán viên có thể không phát hiện ra tất cả các rủi ro có sai sót trọng yếu; và b. có những hạn chế tiềm tàng trong kiểm soát nội bộ, bao gồm việc Ban Giám đốc khống chế kiểm soát.

Nội dung và phạm vi thử nghiệm cơ bản

2.41. Tùy theo tình hình, kiểm toán viên có thể xác định rằng:

2.41.1 Chỉ thực hiện các thủ tục phân tích cơ bản là đủ để giảm rủi ro kiểm toán xuống mức thấp có thể chấp nhận được. Ví dụ: khi kiểm toán viên đánh giá rủi ro dựa vào bằng chứng kiểm toán thu thập được từ thử nghiệm kiểm soát;

2.41.2. Chỉ có kiểm tra chi tiết là thích hợp;

2.41.3. Việc kết hợp thủ tục phân tích cơ bản và kiểm tra chi tiết là thích hợp nhất để xử lý rủi ro đã được đánh giá.

2.42. Thủ tục phân tích cơ bản thường được áp dụng cho số lượng lớn các giao dịch có thể dự đoán theo thời gian. Chuẩn mực kiểm toán Việt Nam số 520 quy định và hướng dẫn về việc áp dụng thủ tục phân tích trong việc kiểm toán.

2.43. Kiểm toán viên cần xem xét bản chất của rủi ro và cơ sở dẫn liệu khi thiết kế kiểm tra chi tiết. Ví dụ, khi kiểm tra chi tiết liên quan đến cơ sở dẫn liệu “tính hiện hữu” hoặc “tính phát sinh”, kiểm toán viên có thể lựa chọn số liệu từ các khoản mục đã có trong báo cáo tài chính và thu thập bằng chứng kiểm toán thích hợp. Mặt khác, khi kiểm tra chi tiết liên quan đến cơ sở dẫn liệu “tính đầy đủ”, kiểm toán viên có thể cần lựa chọn số liệu từ những khoản mục sẽ phải có trong báo cáo tài chính và kiểm tra xem các khoản mục đó đã được trình bày trong báo cáo tài chính hay chưa.

2.44. Do việc đánh giá rủi ro có sai sót trọng yếu cần xem xét đến kiểm soát nội bộ, kiểm toán viên sẽ cần mở rộng phạm vi thử nghiệm cơ bản khi kết quả thử nghiệm kiểm soát là không thỏa đáng. Tuy nhiên, việc mở rộng phạm vi của một thủ tục kiểm toán chỉ thích hợp khi thủ tục kiểm toán đó có liên quan đến rủi ro cụ thể.

2.45. Khi thiết kế kiểm tra chi tiết, phạm vi kiểm tra thường được xem xét như là việc lựa chọn cỡ mẫu. Tuy nhiên, kiểm toán viên cần xem xét những vấn đề khác liên quan, như liệu có phương pháp nào hiệu quả hơn để lựa chọn các phần tử kiểm tra hay không (xem đoạn 10 Chuẩn mực kiểm toán Việt Nam số 500).

Xem xét sự cần thiết phải thực hiện thủ tục xác nhận từ bên ngoài (hướng dẫn đoạn 19 Chuẩn mực này)

2.46. Thủ tục xác nhận từ bên ngoài thường được thực hiện khi thu thập bằng chứng kiểm toán về các cơ sở dẫn liệu liên quan đến các số dư tài khoản và các yếu tố kèm theo, tuy nhiên không nhất thiết giới hạn ở các khoản mục này. Ví dụ, kiểm toán viên có thể yêu cầu xác nhận từ bên ngoài về các điều khoản hợp đồng, hoặc các giao dịch giữa đơn vị với các bên khác. Thủ tục xác nhận từ bên ngoài cũng có thể được thực hiện để thu thập bằng chứng kiểm toán về việc không có các điều kiện nhất định. Ví dụ, kiểm toán viên có thể yêu cầu xác nhận rằng không có “thoả thuận phụ” nào liên quan đến cơ sở dẫn liệu về tính đúng kỳ của doanh thu. Thủ tục xác nhận từ bên ngoài cũng có thể cung cấp bằng chứng kiểm toán thích hợp để xử lý rủi ro có sai sót trọng yếu đã được đánh giá trong các trường hợp như:

2.46.1. Số dư tài khoản ngân hàng và các thông tin khác liên quan đến quan hệ với ngân hàng;

2.46.2. Số dư các khoản phải thu và các điều khoản hợp đồng;

2.46.3. Hàng tồn kho do bên thứ ba nắm giữ tại kho bảo thuế để xử lý hoặc hàng ký gửi;

2.46.4. Giấy chứng nhận quyền sử dụng đất do luật sư hoặc người cho vay giữ để bảo quản hoặc để đảm bảo khả năng thanh toán;

2.46.5. Các khoản đầu tư do bên thứ ba nắm giữ để bảo vệ an toàn, hoặc mua trên sàn chứng khoán nhưng chưa được nhận vào ngày lập Bảng cân đối kế toán;

2.46.6. Các khoản vay, bao gồm các điều khoản thanh toán và các điều khoản giới hạn;

2.46.7. Số dư các khoản phải trả và các điều khoản hợp đồng.

2.47. Mặc dù các xác nhận từ bên ngoài có thể cung cấp bằng chứng kiểm toán thích hợp đối với một số cơ sở dẫn liệu nhất định nhưng các xác nhận này lại cung cấp bằng chứng kiểm toán không mấy thích hợp đối với một số cơ sở dẫn liệu khác. Ví dụ, xác nhận từ bên ngoài có thể cung cấp bằng chứng kiểm toán về sự tồn tại của các khoản phải thu nhưng không cung cấp bằng chứng về khả năng thu hồi các khoản phải thu đó.

2.48. Kiểm toán viên có thể xác định rằng thủ tục xác nhận từ bên ngoài được thực hiện cho một mục đích nhất định cũng có thể giúp thu thập bằng chứng kiểm toán về các vấn đề khác. Ví dụ, yêu cầu xác nhận về các số dư tài khoản ngân hàng thường bao gồm yêu cầu cung cấp thông tin liên quan đến các cơ sở dẫn liệu khác của báo cáo tài chính. Việc xem xét các vấn đề này có thể ảnh hưởng đến quyết định của kiểm toán viên về việc có thực hiện các thủ tục xác nhận từ bên ngoài hay không.

2.49. Các yếu tố có thể giúp kiểm toán viên xác định có thực hiện các thủ tục xác nhận từ bên ngoài như các thử nghiệm kiểm toán cơ bản hay không, bao gồm:

2.49.1. Hiểu biết của bên xác nhận về vấn đề cần xác nhận: thông tin phản hồi có thể đáng tin cậy hơn nếu được một người của bên xác nhận có hiểu biết cần thiết về thông tin cần xác nhận;

2.49.2. Khả năng hoặc sự sẵn sàng phản hồi của bên xác nhận, ví dụ bên xác nhận:

- Có thể không nhận trách nhiệm đối với việc phản hồi một yêu cầu xác nhận;

- Có thể thấy việc phản hồi tốn quá nhiều chi phí và thời gian;

- Có thể lo lắng về trách nhiệm pháp lý từ việc phản hồi;

- Có thể hạch toán giao dịch bằng các loại tiền tệ khác; hoặc

- Có thể hoạt động trong một môi trường mà việc phản hồi các yêu cầu xác nhận không phải là vấn đề quan trọng của các hoạt động hàng ngày.

Trong trường hợp đó, bên xác nhận có thể không phản hồi, phản hồi một cách thiếu trách nhiệm hoặc có thể cố gắng hạn chế độ tin cậy của phản hồi.

2.49.3. Sự khách quan của bên xác nhận: nếu bên xác nhận là bên liên quan của đơn vị thì việc phản hồi cho các yêu cầu xác nhận có thể có độ tin cậy thấp hơn.

Thử nghiệm cơ bản liên quan đến quy trình khóa sổ kế toán lập báo cáo tài chính (hướng dẫn đoạn 20b. Chuẩn mực này)

2.50. Nội dung và phạm vi kiểm tra của kiểm toán viên đối với các bút toán và điều chỉnh khác phụ thuộc vào tính chất và mức độ phức tạp của quy trình lập báo cáo tài chính của đơn vị và các rủi ro có sai sót trọng yếu liên quan.

Thử nghiệm cơ bản đối với các rủi ro đáng kể (hướng dẫn đoạn 21 Chuẩn mực này)

2.51. Đoạn 21 Chuẩn mực này yêu cầu kiểm toán viên phải thực hiện các thử nghiệm cơ bản để xử lý các rủi ro mà kiểm toán viên đã xác định là rủi ro đáng kể. Bằng chứng kiểm toán dưới hình thức xác nhận từ bên ngoài mà kiểm toán viên nhận trực tiếp từ các bên xác nhận phù hợp có thể giúp kiểm toán viên thu thập bằng chứng kiểm toán có độ tin cậy cao cần thiết để xử lý rủi ro có sai sót trọng yếu đáng kể do gian lận hoặc nhầm lẫn. Ví dụ, nếu kiểm toán viên nhận thấy Ban Giám đốc đang chịu áp lực phải đạt được các mức lợi nhuận kỳ vọng thì có thể xảy ra rủi ro Ban Giám đốc thổi phồng doanh thu bằng cách ghi nhận các khoản doanh thu không phù hợp với điều khoản của hợp đồng bán hàng, hoặc bằng cách phát hành hoá đơn trước khi giao hàng. Trong trường hợp này, kiểm toán viên có thể thiết kế các thủ tục xác nhận từ bên ngoài để xác nhận các số dư chưa thanh toán, đồng thời xác nhận các chi tiết trong hợp đồng bán hàng, bao gồm thời điểm, các điều khoản về giao hàng và quyền trả lại hàng. Ngoài ra, để hỗ trợ cho việc thực hiện thủ tục xác nhận từ bên ngoài, kiểm toán viên có thể phỏng vấn các nhân sự không làm công tác tài chính của đơn vị về những thay đổi trong hợp đồng bán hàng và các điều khoản giao hàng.

Lịch trình thực hiện thử nghiệm cơ bản (hướng dẫn đoạn 22 - 23 Chuẩn mực này)

2.52. Trong hầu hết các trường hợp, bằng chứng kiểm toán từ các thử nghiệm cơ bản đã thu thập được từ cuộc kiểm toán trước hầu như không cung cấp bằng chứng nào cho cuộc kiểm toán hiện tại. Tuy nhiên, vẫn có trường hợp ngoại lệ, ví dụ, một công văn của cơ quan thuế thu thập được trong cuộc kiểm toán trước có liên quan đến xử lý vi phạm về thuế thu nhập cá nhân không bị thay đổi có thể vẫn thích hợp cho kỳ kiểm toán hiện tại. Trong trường hợp này, việc sử dụng bằng chứng kiểm toán từ các thử nghiệm cơ bản của cuộc kiểm toán trước có thể vẫn thích hợp với cuộc kiểm toán hiện tại nếu bằng chứng đó và vấn đề có liên quan về cơ bản không thay đổi, và kiểm toán viên đã thực hiện các thủ tục kiểm toán để chứng minh các bằng chứng kiểm toán từ các cuộc kiểm toán trước vẫn tiếp tục phù hợp cho cuộc kiểm toán hiện tại.

Sử dụng bằng chứng kiểm toán thu thập được trong giai đoạn giữa kỳ (hướng dẫn đoạn 22 Chuẩn mực này)

2.53. Trong một số trường hợp, kiểm toán viên có thể thấy hiệu quả khi thực hiện thử nghiệm cơ bản tại thời điểm kiểm toán giữa kỳ và so sánh, đối chiếu các thông tin liên quan đến số dư cuối kỳ với thông tin so sánh tại thời điểm giữa kỳ để:

2.53.1. Phát hiện các số liệu bất thường;

2.53.2. Điều tra các số liệu bất thường (nếu có);

2.53.3. Thực hiện thủ tục phân tích cơ bản hoặc kiểm tra chi tiết cho giai đoạn từ giữa kỳ đến cuối kỳ.

2.54. Việc thực hiện thử nghiệm cơ bản tại thời điểm kiểm toán giữa kỳ mà không có thêm các thủ tục bổ sung cho giai đoạn sau sẽ làm tăng rủi ro trong việc kiểm toán viên không phát hiện ra các sai sót có thể có tại thời điểm cuối kỳ. Rủi ro này sẽ càng tăng khi giai đoạn còn lại càng dài. Khi cân nhắc sự cần thiết của việc thực hiện thử nghiệm cơ bản ở giai đoạn giữa kỳ, kiểm toán viên cần xem xét các yếu tố sau:

2.54.1. Môi trường kiểm soát và các kiểm soát liên quan khác;

2.54.2. Mức độ sẵn có của thông tin cần thiết cho các thủ tục kiểm toán của kiểm toán viên vào giai đoạn sau ;

2.54.3. Mục tiêu của thử nghiệm cơ bản;

2.54.4. Rủi ro có sai sót trọng yếu đã được đánh giá;

2.54.5. Tính chất của nhóm giao dịch hoặc số dư tài khoản và các cơ sở dẫn liệu liên quan;

2.54.6. Khả năng của kiểm toán viên khi thực hiện các thử nghiệm cơ bản thích hợp hoặc kết hợp thử nghiệm cơ bản với thử nghiệm kiểm soát để bao quát toàn bộ giai đoạn còn lại, nhằm làm giảm rủi ro xảy ra sai sót vào giai đoạn cuối kỳ chưa được kiểm toán viên phát hiện.

2.55. Những yếu tố sau đây có thể ảnh hưởng đến quyết định của kiểm toán viên về việc liệu có thực hiện thủ tục phân tích cơ bản cho giai đoạn từ giữa kỳ đến cuối kỳ hay không:

2.55.1. Số dư cuối kỳ của các nhóm giao dịch hoặc một tài khoản cụ thể có được dự báo một cách hợp lý về giá trị, biến động tương đối và thành phần của số dư cuối kỳ hay không;

2.55.2.Các thủ tục phân tích và điều chỉnh các nhóm giao dịch hoặc số dư tài khoản tại thời điểm giữa kỳ và thực hiện khóa sổ kế toán của đơn vị có phù hợp hay không;

2.55.3. Hệ thống thông tin liên quan đến việc lập và trình bày báo cáo tài chính có cung cấp đầy đủ thông tin liên quan đến các số dư cuối kỳ và các giao dịch trong giai đoạn còn lại để cho phép kiểm toán viên điều tra về:

a. Các giao dịch hoặc bút toán bất thường phát sinh tại hoặc gần thời điểm cuối kỳ;

b. Nguyên nhân khác của các biến động đáng kể, hoặc biến động dự kiến đã không xảy ra;

c. Những thay đổi về thành phần của các nhóm giao dịch hoặc số dư tài khoản.

Các sai sót được phát hiện tại thời điểm kiểm toán giữa kỳ (hướng dẫn đoạn 23 Chuẩn mực này)

2.56. Nếu kiểm toán viên kết luận rằng nội dung, lịch trình hoặc phạm vi dự kiến của các thử nghiệm cơ bản cho giai đoạn còn lại cần được điều chỉnh do phát hiện ra những sai sót ngoài dự kiến tại thời điểm giữa kỳ, thì tại thời điểm cuối kỳ, kiểm toán viên cần mở rộng hoặc lặp lại các thủ tục đã thực hiện tại thời điểm giữa kỳ.

3. Mức độ đầy đủ của việc trình bày và thuyết minh báo cáo tài chính

(hướng dẫn đoạn 24 Chuẩn mực này)

Khi đánh giá việc trình bày tổng thể báo cáo tài chính, kể cả các thuyết minh liên quan, kiểm toán viên cần đánh giá xem từng báo cáo có phản ánh việc phân loại và mô tả thích hợp các thông tin tài chính và hình thức, cách sắp xếp, nội dung báo cáo tài chính và các thuyết minh kèm theo hay không. Những nội dung này có thể bao gồm thuật ngữ sử dụng, số lượng các thông tin, số liệu chi tiết đưa ra, việc phân loại các khoản mục trong báo cáo và cơ sở trình bày thông tin.

4. Đánh giá tính đầy đủ và thích hợp của bằng chứng kiểm toán

(hướng dẫn đoạn 25 - 27 Chuẩn mực này)

4.1. Công việc kiểm toán báo cáo tài chính là một quá trình mang tính tích lũy và cập nhật thường xuyên. Khi thực hiện thủ tục kiểm toán theo kế hoạch đã lập, bằng chứng kiểm toán thu thập được có thể làm cho kiểm toán viên phải thay đổi nội dung, lịch trình hoặc phạm vi các thủ tục kiểm toán khác. Thông tin mà kiểm toán viên thu thập được có thể có sự khác biệt đáng kể so với thông tin được sử dụng làm cơ sở cho việc đánh giá rủi ro. Ví dụ:

Mức độ sai sót mà kiểm toán viên phát hiện khi thực hiện thử nghiệm cơ bản có thể làm thay đổi xét đoán chuyên môn của kiểm toán viên về đánh giá rủi ro và có thể cho thấy khiếm khuyết nghiêm trọng trong kiểm soát nội bộ;

Kiểm toán viên có thể nhận thấy sự thiếu nhất quán trong sổ kế toán, những bằng chứng mâu thuẫn hoặc bị bỏ sót;

Các thủ tục phân tích được thực hiện trong giai đoạn soát xét tổng thể của cuộc kiểm toán có thể cho thấy rủi ro có sai sót trọng yếu chưa được phát hiện trước đó.

Trong trường hợp này, kiểm toán viên có thể cần đánh giá lại các thủ tục kiểm toán đã lập kế hoạch dựa trên việc xem xét lại các rủi ro đã được đánh giá đối với tất cả hoặc một số nhóm giao dịch, số dư tài khoản, hoặc thông tin thuyết minh trên báo cáo tài chính và những cơ sở dẫn liệu có liên quan. Đoạn 31 Chuẩn mực kiểm toán Việt Nam số 315 hướng dẫn chi tiết hơn về việc xem xét lại đánh giá rủi ro của kiểm toán viên.

4.2. Kiểm toán viên không được cho rằng gian lận hoặc nhầm lẫn chỉ là cá biệt. Do vậy, kiểm toán viên cần cân nhắc xem việc phát hiện ra sai sót sẽ có ảnh hưởng như thế nào đến các rủi ro có sai sót trọng yếu đã được đánh giá để xác định xem liệu đánh giá còn phù hợp hay không.

4.3. Xét đoán chuyên môn của kiểm toán viên về tính đầy đủ và thích hợp của bằng chứng kiểm toán chịu ảnh hưởng của các yếu tố sau:

Mức độ nghiêm trọng của sai sót tiềm tàng trong cơ sở dẫn liệu và khả năng xảy ra ảnh hưởng trọng yếu, riêng rẽ hoặc tổng hợp với các sai sót tiềm tàng khác đối với báo cáo tài chính;

Tính hữu hiệu của các biện pháp xử lý và các kiểm soát của Ban Giám đốc đơn vị đối với các rủi ro này;

Kinh nghiệm tích lũy được từ các cuộc kiểm toán trước đây liên quan đến các sai sót tiềm tàng tương tự;

Kết quả thực hiện các thủ tục kiểm toán, kể cả việc liệu các thủ tục kiểm toán đó có phát hiện được các trường hợp gian lận hoặc nhầm lẫn hay không;

Nguồn gốc và độ tin cậy của thông tin sẵn có;

Tính thuyết phục của bằng chứng kiểm toán;

Hiểu biết của kiểm toán viên về đơn vị và môi trường của đơn vị, trong đó có kiểm soát nội bộ.

5. Tài liệu, hồ sơ kiểm toán [PN1]

(hướng dẫn đoạn 28 Chuẩn mực này)

Hình thức và phạm vi của tài liệu, hồ sơ kiểm toán là vấn đề thuộc về xét đoán chuyên môn của kiểm toán viên và chịu ảnh hưởng của tính chất, quy mô và mức độ phức tạp của đơn vị được kiểm toán cũng như của kiểm soát nội bộ của đơn vị, tính sẵn có của thông tin trong đơn vị, phương pháp và kỹ thuật kiểm toán được sử dụng