Batch process - what should be tested? 701
-
Just looking for ideas regarding the types of controls that would be considered ‘key’ to test for batch processes such as scheduling and processing.
- do you think a key general control would include batch processing/scheduling?
- how many controls were identified? range from x-y
- is this more about change control to batch scheduling and processing?
- what have you seen?
- any other ideas
Thanks for your ideas.
-
We have an ITGC related to automated backup procedures. That is the only one we have related to batch processes and scheduling. We have several automated procedures that relate to ITGC’s but are executed on demand.
However I could envisage a situation where there were key Application controls related to batch processing and scheduling. Is this what you mean?
-
- In order to schedule you are usually scheduling through something, whether a system utility, vendor supplied software, or something homegrown. Look at how someone could gain access to this in order to schedule something. Access is key. Is access restricted and to whom? Some packages have multiple levels of security up to restricting who can access, from where, as well as what (to a degree such as userid but thats a pretty powerful control). Sometimes a utility may be turned off to general users by the administrator to encourage passing over this function to another party (i.e. so a critical process is not running under someones user account for them to blast away later).
Test- define a process as any user using a trivial non harmful arbitrary command (example unix ls or exit 0… windows dir or cd). How far can you go with the process? If you get an error message what error message did you get? What system gave you the error? - Scheduling system logs. This will show automated and manual executions or all activity from the scheduling system (if adhoc runs are sent through the scheduler the activity will be in logs as well as the id of the person who initiated it). You can have a ticketing system or audit trail requesting the activity and approving the activity to tie into the manual intervention.
Test- check for test1 in the logs. - Change tracking of scheduling definitions. Create/update/delete.
Test- check for test1 in the logs. Hopefully you named it something meaningful. - Once a task has been defined can it be temporarily altered? How. By whom. Is it tracked?
Have someone else attempt to temporarily alter test1. What can they change? Can they execute it? Is the change recorded? If the change is what is executed, again, change to an arbitrary command. - Do definitions go through peer review? You can require something showing creation/modify/delete passed through two sets of eyes.
I dont know if that helps.
- In order to schedule you are usually scheduling through something, whether a system utility, vendor supplied software, or something homegrown. Look at how someone could gain access to this in order to schedule something. Access is key. Is access restricted and to whom? Some packages have multiple levels of security up to restricting who can access, from where, as well as what (to a degree such as userid but thats a pretty powerful control). Sometimes a utility may be turned off to general users by the administrator to encourage passing over this function to another party (i.e. so a critical process is not running under someones user account for them to blast away later).