BUSN 3002 Auditing
4.1
Audit objective relating to database access is verify that database access authority and privileges are granted to users in accordance with their legitimate needs. Audit procedures for testing data access controls are:
Responsibility for authority tables and subschemas. The auditor should verify that database administration personnel retain exclusive responsibility for creating authority tables and designing user views. Evidence may come from three sources: (1) by reviewing company policy and job descriptions, which specify these technical responsibilities; (2) by examining programmer authority tables for access privileges to data definition language commands; and (3) through personal interviews with programmers and DBA personnel. Appropriate access authority. The auditor can select a sample of users and verify that their access privileges stored in the authority table are consistent with their job descriptions organizational levels.
Audit objective relating to database access is verify that database access authority and privileges are granted to users in accordance with their legitimate needs. Audit procedures for testing data access controls are:
Responsibility for authority tables and subschemas. The auditor should verify that database administration personnel retain exclusive responsibility for creating authority tables and designing user views. Evidence may come from three sources: (1) by reviewing company policy and job descriptions, which specify these technical responsibilities; (2) by examining programmer authority tables for access privileges to data definition language commands; and (3) through personal interviews with programmers and DBA personnel. Appropriate access authority. The auditor can select a sample of users and verify that their access privileges stored in the authority table are consistent with their job descriptions organizational levels.
You
are required to suggest:
Biometric controls. The auditor should evaluate the costs and benefits of biometric controls. Generally, these would be most appropriate where highly sensitive data are accessed by a very limited number of users.
Inference controls. The auditor should verify that database query controls exist to prevent unauthorized access via inference. The auditor can test controls by simulating access by a sample of users and attempting to retrieve unauthorized data via inference queries. Encryption controls. The auditor should verify that sensitive data, such as passwords, are properly encrypted. Printing the file contents to hard copy can do this.
4.2
Audit objective relating to database backup is verify that controls over the data resource are sufficient to preserve the integrity and physical security of the database. Audit procedures for testing database backup controls are:
The auditor should verify that backup is performed routinely and frequently to facilitate the recovery of lost, destroyed, or corrupted data without excessive reprocessing. Production databases should be copied at regular intervals. Backup policy should strike a balance between the inconvenience of frequent backup activities and the business disruption caused by excessive reprocessing that is needed to restore the database after a failure. The auditor should verify that automatic backup procedures are in place and functioning, and that copies of the database are stored off-site for further security.
5.1
The SDLC process is of interest to accountants and auditors for two reasons. First, the creation of an information system entails significant financial transactions. Conceptually, systems development is like any manufacturing process that produces a complex product through a series of stages. Such transactions must be planned, authorized, scheduled, accounted for, and controlled. Accountants are as concerned with the integrity of this process as they are with any manufacturing process that has financial resource implications. Because of their background, experience, and training, accountants and auditors are experts in financial transactions and thus can provide critical input into the system regarding controls, integrity, timeliness, and a number of other important aspects of financial transactions.
The second and more pressing concern for accountants and auditors is with the nature of the products that emerge from the SDLC. The quality of accounting information rests directly on the SDLC activities that produce accounting information systems. These systems deliver accounting information to internal and external users. The accountant’s responsibility is to ensure that the systems employ proper accounting conventions and rules, and possess adequate controls. Therefore, accountants are greatly concerned with the quality of the process that produces AIS. For example, a sales order system produced by a defective SDLC may suffer from serious control weaknesses that introduce errors into the financial accounting records, or provide opportunities for fraud. Accountants are involved in systems development in three ways. Firs, accountants are users. All systems that process financial transactions impact the accounting function in some way. Like all users, accountants must provide a clear picture of their problems and needs to the systems professionals. For example, accountants must specify accounting techniques to be used, internal control requirements (such as audit trails), and special algorithms (such as depreciation models).
Second, accountants participate in systems development as members of the development team. Their involvement often extends beyond the development of strictly AIS applications. Systems that do not process financial transactions directly may still draw from accounting data. The accountant may be consulted to provide advice or to determine if the proposed system constitutes an internal control risk. In all cases, the level of auditor participation is limited by independence issues in professional standards and ethics. Third, accountants are involved in systems development as auditors. Accounting information systems must be auditable. Some computer audit techniques require special features that need to be adesigned into the system during the SDLC. The auditor has a stake in all systems and should be involved early in their design, especially regarding their auditability, security, and controls.
5.2
Systems Planning
Auditors routinely examine the systems planning phase of the SDLC. Planning greatly reduces the risk that an organization has produced unneeded, inefficient, ineffective, and
fraudulent systems. Therefore, both internal and external auditors are interested in ensuring that adequate systems planning takes place.
Systems analysis
The firm’s auditors are stakeholders in the proposed system. Often advanced audit features cannot be easily added to existing systems. Therefore, the auditor should be involved in the needs analysis of the proposed system to determine if it is a good candidate for advanced audit features and, if so, which features are best suited for the system.
Conceptual systems design
The auditor is a stakeholder in all financial systems and, thus, has an interest in the conceptual design stage of the system. The auditability of a system depends in part on its design characteristics. Some computer auditing techniques require systems to be designed with special audit features that are integral to the system. These audit features must be specified at the conceptual design stage.
Evaluation and selection
The primary concern for auditors is that the economic feasibility of the proposed system is measured as accurately as possible. Specifically, the auditor should ensure five things: -Only escapable costs are used in calculations of cost savings benefits -Reasonable interest rates are used in measuring present values of cash flows. -One-time and recurring costs are completely and accurately reported. -Realistic useful lives are used in comparing competing projects. -Intangible benefits are assigned reasonable financial values. Errors, omissions, and misrepresentations in the accounting for such items can distort the analysis and may result in a materially flawed decision
System implementation
External auditors are prohibited by SOX legislation from direct involvement in systems implementation. However, as the preceding discussion has already suggested, the role of internal auditors in the detailed design and implementation phases should be significant. Being a stakeholder in all financial systems, internal auditors should lend their expertise to this process to guide and shape the finished system. Specifically, internal auditors may get involved in the following ways.
Provide technical expertise. The detailed design phase involves precise specifications of procedures, rules, and conventions to be used in the system. In the case of an AIS, these specifications must coply with GAAP, GAAS, SEC regulations and IRS codes. Failure to so comply can lead to legal exposure for the firm. For example, choosting the correct depreciation method or asset valuation technique requires a technical background not necessarily possessed by systems professionals. The auditor may provide this expertise to the systems design process
Specify documentation standards. In the implementation phase, the auditor plays a role in specifying system documentation. Since financial systems must periodically be audited, they must be adequately documented. The auditor should actively encourage adherence to effective documentation standards
Verify control adequacy and compliance with SOX. The AIS applications that emerge from the SDLC must possess adequate controls. In addition, compliance with SOX legislation requires management to certify the existence and effectiveness of those controls. During the implementation process, the internal audit function plays a key role in these verification and compliance activities.
System maintenance
Detect unauthorized program maintenance (which may have resulted in significant processing errors or fraud). Determine that (1) maintenance procedures protect applications from unauthorized changes, (2) applications are free from material errors, and (3) program libraries are protected from unauthorized access.
6.1
All members of the financial reporting community should be aware of XBRL, as it is an important information exchange technology. In the near future, XBRL will likely be the primary vehicle for delivering business reports to investors and regulators. Recent progress toward that end has been substantial both in the US and internationally. Some of these developments in summary:
-Since October 2005, US. banking regulators have required quarterly ‘call reports’ to be filed in XBRL. This requirement impacts more than 8.000 banks. -In April 2005, the SEC began a voluntary financial reporting program that allows registrants to supplement their required filings with exhibits using XBRL. -In September 2006, the SEC announced its new electronic reporting system to receive XBRL filings. The new system is called IDEA, short for interactive data electronic application.
-In May 2008, the SEC issued rules requiring large publicly held companies to adopt XBRL by December 15 to meet financial reporting requirements.
-Comparable developments to encourage or require XBRL have taken place internationally. Since early 2003, the Tokyo Stock Exchange has accepted XBRL information. In 2007, the Canadian Securities Administrators established a voluntary program to help the Canadian marketplace gain practical knowledge in preparing, filing, and using XBRL information. Regulators in China, Spain, the Netherlands, and the UK are requiring certain companies to use XBRL.
In addition, the use of XBRL will facilitate fulfilment of legal requirements stipulated in the Sarbanes-Oxley Act, which was passed in response to widespread concern and scepticism about financial-reporting standards. In particular, XBRL can play a role in facilitating earlier reporting of financial statements required under SOX legislation.
6.2
Although the potential benefits of XBRL and associated Web technologies have been extensively researched, less attention has been given to the potential control implications of using XBRL. There are three areas of specific concern, which are discussed here.
Taxonomy creation. Taxonomy may be generated incorrectly, which results in an incorrect mapping between data and taxonomy elements that could result in material misrepresentation of financial data. Controls must be designed and put in place to ensure the correct generation of XBRL taxonomies.
Taxonomy mapping error. The process of mapping the internal database accounts to the taxonomy tags needs to be controlled. Correctly generated XBRL tags may be incorrectly assigned to internal database accounts resulting in material misrepresentation of financial data.
Validation of instance documents. Once the mapping is complete and tags have been stored in the internal database, XBRL instance documents (reports) can be generated. Independent verification procedures need to be established to validate the instance documents to ensure that appropriate taxonomy and tags have been applied before posting to a web server.
No comments:
Post a Comment