A proper, complete set of audit working papers is imperative to back up the audit findings. However there is a fine line between over-documenting and not documenting adequately. It is better to ere on the side of over documentation.
The documentation should be done in line with the Audit Plan. The references in the audit plan must be reflected in the suffix of documents reference so that they may be easily cross-referenced. The following are a minimum of different templates that should be developed in order to record the audit details.
Index Sheet for Whole File.
A Lead Schedule for each section.
Individual Control Schedule.
Interview Sheets.
Test Results
Agendas/Minutes of meetings
Testing Documentation.
The Index Sheet enables the person reviewing the file to quickly establish the completeness of the audit, as a comparison with the Audit Program will ensure if all the controls have been audited, and scanning of the index will ensure that a complete set of documents exists for each of the controls.
The Lead Schedule is the covering sheet of the working papers pertaining to a section that is being tested for. This may be subdivided into several medium risks each with multiple controls.
A Lead Schedule may consist of the section, the major risks. e.g. input (data capture) is not ensuring that data is accurately, effectively and completely captured.
The Individual Schedule can take different forms in accordance with the risk that is being tested for. If a screen mask for capturing data is being tested this document could take the form of a table listing the fields, the test(s) that is applied to it whether the results were positive or negative and a field for comment.
A Detailed Schedule may consist of the fields in the screen mask to be tested. (This is not required at all times but can be useful in a case such as the one listed below.) The tests to be performed to establish the adequacy of a date field an the detailed risk i.e. date fields are not adequately tested.
An example of the tests for a date may be:
Is the date tested against a calendar to ensure that it is a valid date? i.e. for day/month/year.
Does it only accept dates that are present or future?
Does it validate this against the current date on the workstation?
Is the workstation date always validated against the server date on startup?
Is there a limited window/period of valid dates? (this depends of the application)
Does it take the information entered and convert it to the right format?
Does this field need to be mandatory? If so is it mandatory does the screen prevent further input until the date is captured?
The Index Sheet enables the person reviewing the file to quickly establish the completeness of the audit, as a comparison with the audit program will ensure if all the controls have been audited, and scanning of the index will ensure that a complete set of documents exists for each of the controls.
The Lead Schedule is the covering sheet of the working papers pertaining to a section that is being tested for. This may be subdivided into several medium risks each with multiple controls.
A Lead Schedule may consist of the section, the major risks. e.g. input (data capture) is not ensuring that data is accurately, effectively and completely captured.
The Individual Schedule can take different forms in accordance with the risk that is being tested for. If a screen mask for capturing data is being tested this document could take the form of a table listing the fields, the test(s) that is applied to it whether the results were positive or negative and a field for comment.
A Detailed Schedule may consist of the fields in the screen mask to be tested. (This is not required at all times but can be useful in a case such as the one listed below.) The tests to be performed to establish the adequacy of a date field an the detailed risk i.e. date fields are not adequately tested.
An example of the tests for a date may be:
Is the date tested against a calendar to ensure that it is a valid date? i.e. for day/month/year.
Does it only accept dates that are present or future?
Does it validate this against the current date on the workstation?
Is the workstation date always validated against the server date on startup?
Is there a limited window/period of valid dates? (this depends of the application)
Does it take the information entered and convert it to the right format?
Does this field need to be mandatory? If so is it mandatory does the screen prevent further input until the date is captured?
The Individual Schedule can take different forms in accordance with the risk that is being tested for. If a screen mask for capturing data is being tested this document could take the form of a table listing the fields, the test(s) that is applied to it whether the results were positive or negative and a field for comment.
A Detailed Schedule may consist of the fields in the screen mask to be tested. (This is not required at all times but can be useful in a case such as the one listed below.) The tests to be performed to establish the adequacy of a date field an the detailed risk i.e. date fields are not adequately tested.
An example of the tests for a date may be:
Is the date tested against a calendar to ensure that it is a valid date? i.e. for day/month/year.
Does it only accept dates that are present or future?
Does it validate this against the current date on the workstation?
Is the workstation date always validated against the server date on startup?
Is there a limited window/period of valid dates? (this depends of the application)
Does it take the information entered and convert it to the right format?
Does this field need to be mandatory? If so is it mandatory does the screen prevent further input until the date is captured?
Information Request Form
Select the items that apply, and then let us know how to contact you.
Send service literature Please could develop Audit Working Paper template for our firm. Please contact me
