IT audit practice communication and practice discussion ii it audit practice operation details

1. IT audit ideology.
When it comes to thinking, it may cause many people to yawn. In fact, it is a pity that people who really talk about these things can analyze such things.
From the perspective of auditing alone, auditing can be generally said to be aimed at a business process. check whether there are appropriate internal control measures to ensure that the process follows or is close to the ideal idea.
The same is true for the IT audit application control checks. For a certain data stream or business flow in each system, from input, to internal processing, to output, check whether there is sufficient internal control to ensure that it is successfully completed according to the established route. This is the core of this idea.
After discovering that a node has a major internal control risk, what should we do and how to communicate with each other.
2. IT audit process.
I found that most of the IT audit books and courseware only focus on the risk points to be checked, and there is little detail on how to start from the project to the check, based on my own experience. It applies not only to application control, but also to the entire IT audit project process.
How can I check application control? The manager said one day that we have a project for the xxx system. Can you do it? I must have heard of it.
With such a simple command, you must go back and do a bunch of complicated things.
First, we need to clarify our ideas for this project. What are the results that the leader wants: Are there any vulnerabilities in the fund system? Check whether the business of the core system can communicate normally? Or is it worthwhile to continue investing in the target system to be transformed? This is the first one to conduct it audits and focuses on the fight. In addition to leadership requirements, there are several other issues, such as where you know the system is faulty (for example, too many people complain about which part of the system always reports an error and is stuck) the system determines where problems may occur (for example, the logical judgment at the interface with the external system ), there are also the most important features of the system (such as the payment logic judgment and approval flow judgment of the fund system ).
Secondly, while we know what to do, collect and read the detailed requirement development documentation, O & M change documentation, data structure, business and logic flowchart, topology diagram, user manual, production environment front-end account, it is best to have the account and test of each link of the Test System system background database permissions, to facilitate walk-through testing and white box testing. These get, start to the most painful understanding of the system. In this step, we need to break down the actual operations on the front-end, the background data logic, and the business practices involved.
Third, remove eight of the target system functions. The functional modules are separated in detail and placed in each row of Excel. A variety of functions are mixed in one module, which also indicates segmentation. This facilitates the design of risk matrices.
Fourth, we started to design the risk matrix. Simply put, we scored each feature block in terms of business focus, risk size, and risk possibility on the premise of understanding the above items, in the end, we will obtain a matrix chart that will be checked.
Fifth, start construction based on the matrix.
If you have time, it is best to design a detailed risk point for each module to be checked. Then check according to the risk points one by one.
Next, we need to use audit knowledge. For example, you need to check the Internal Control establishment and implementation of an approval flow. First, check whether an approval flow is set up. From the user manual and outline design, check whether the approval flow is complete and meets business needs. Used to determine whether the business logic is faulty. Then we need to check whether the built-in approval flow function is consistent with the detailed requirement document. Used to determine whether the control in the system is consistent with the design. Then we can see the benefits of having the background database permissions. The foreground inputs, processes, and outputs data for operations, and the background displays the analysis data in each step. Finally, we check whether the specific business approval data configured by the user based on the approval flow function in the production environment meets the ideal business needs in the previous requirements document. Pass tests, conformity tests, white boxes, and black boxes can all be used.