Robot Schedule and Sarbanes-Oxley (SOX) Compliance

 

Introduction

The Sarbanes-Oxley Act requires that the procedures used by the IT department must be audited annually to ensure they have a good system in place for generating accurate and reliable financial reports. An independent auditor must certify that the organization’s internal controls and procedures are effective. Companies began complying in November 2004.

Because so many companies rely on their IT systems to generate their financial reporting, the auditors must be able to follow transactions through the system. Most IT departments already have control points in their procedures, but they aren’t clearly documented. The new regulations are forcing IT to identify these controls, be able to test them, and demonstrate their effectiveness.

A number of frameworks are available for approaching compliance with these requirements, but a commonly used framework in the IT industry is CobiT (Control Objectives for Information and related Technology). CobiT provides objectives for control of IT processes. The remainder of this paper discusses how Robot Schedule addresses the CobiT areas of General Controls and Delivery Support.

General Controls

Auditing Job Information

Using Robot Schedule auditing, you have the ability to display a job’s run date and time; why the job ran; changes to the job; and see when the job was created and deleted. Auditing captures the before and-after image of the job. If necessary, you can revert to the original job setup. See the section: "Auditing Job Information in Robot Schedule," below, for more information.

Product Security

The security features in Robot Schedule allow you to define which users have access to the Robot Schedule product. You can grant users View or Change authority to one job or all jobs. You also decide who can run your jobs and you can restrict the menus your users can access. Note: Fortra follows IBM’s rule of authority: If a user has *ALLOBJ authority, the user can access all files, bypassing Robot Schedule security. See the section: "Robot Schedule Security," below, for more information.

Delivery Support

Batch Processing

Controlling batch processing is vital because your critical financial reporting runs in batch. Robot Schedule helps you monitor and control batch processes in several ways.

Auditors want you to produce reports of abends from each shift of operations; have restart and recovery procedures in place for critical business processes; maintain processing continuity from shift to shift; and deliver service level requirements.

Robot Schedule documents abnormal end of jobs, has built-in restart procedures, builds online lists of processing rules that extend from one shift to the next, and can notify you when jobs are late. Robot Schedule has always had these capabilities, but they become increasingly important in meeting your Sarbanes-Oxley requirements.

Summary

Sarbanes-Oxley is here to stay. IT is responsible for computer operations and the control of the computer operations environment. Auditors consider manual operations as higher risk as they are more difficult—and more costly—to audit. Automated operations through the Robot products provide better controls and the tools for demonstrating these controls.

Auditing Job Information in Robot Schedule

Robot Schedule includes an auditing menu that allows you to start and end auditing; and set up, display, and delete the audit log. Start auditing using option 2 on the Robot Schedule Audit menu. If you updated Robot Schedule from R09M15 (or earlier) to version R09M16 (or later) and auditing was never ended, you must end and restart the auditing to capture changes to new files.

You can use the audit log to find out who created a new job, who changed the job setup, who changed the command within the job and see what the old command was before the change, why a job ran (reactivity), and who performed a DO on a job. For examples, see below. For detailed information about the audit log, see the Robot Schedule User Guide.

You can display and/or print the audit log spooled file (RBT536P) to find what you’re looking for. Be sure to enter a starting and ending date and time for the audit log to narrow your search: If a job was changed since the last time it ran, enter a date and time range starting with the last run prior to the change; enter the date you noticed the change as the ending date. For example:

RBTDSPAUDL FROMTIME(100104 103000) TOTIME(101404 235900) OUTPUT(*PRINT)

You also can enter WRKSPLF on a command line and display the RBT563P spooled file. Search the spooled file for keywords such as job name, date, action, fields, etc. The first few pages of the report list the field names with a brief description and are followed by the actual audit log.

Search for the job, then find the Insert action. This is an example of a new job, HKNEWJOB, that was created by user HEATH on 05/05/14 at 12:05:22.

05/05/14 12:44:46 RBTROB Update RBT201 QPADEV0009/HEATH/037917

KYTIME 000000000035 000000000035

JOBNAM HKNEWJOB2

PROGDS new job - audit testing

JOBTYP C

05/05/14 12:44:55 RBTCMD Insert RBT292 QPADEV0009/HEATH/037917

CMDKEY HKNEWJOB2

CMDSEQ 001

CMERRC 2

EXCMD SNDMSG MSG[this is a new job] TOUSR(HEATH)

05/05/14 12:05:22 RBTCMD Insert RBT292 QPADEV0009/HEATH/036287

CMDKEY HKNEWJOB

CMDSEQ 001

CMERRC 2

EXCMD SNDMSG MSG(HELLO) TOUSR(HEATH)

Search for the job name, then find the Update action. This is an example of when a job’s scheduled time was changed from 1300 to 1500 by user HEATH on 05/05/14.

05/05/14 12:06:10 RBTROB Update RBT201 QPADEV0009/HEATH/036287

KYTIME 000000000019 000000000019

JOBNAM HKNEWJOB HKNEWJOB

PROGDS delete delete

TIMES3 1300 1500

Find out who changed a command and what the command was before the change (before and after image):

Search for the job name or command, then find the Update action. This is an example of a job SNDMSG command that was changed to send different text to a different user. It was changed on 05/06/14 by HKUSER.

05/06/14 11:23:15 RBTCMD Update RBT292 QPADEV0009/HKUSER/036332

CMDKEY HKNEWJOB HKNEWJOB

CMDSEQ 001 001

EXCMD-Bef SNDMSG MSG(HELLO) TOUSR(HEATH)

EXCMD-Aft SNDMSG MSG('HELLO - NEW TEXT') TOUSR(JOHN)

Find out why a job ran (cause: reactivity):

Search for the reactive job name, then find the Update action. Below is an example of a reactive job that ran because it received a status of 'C' from the dependent (prerequisite) job, HKDEP, which ran at 0800.

05/07/14 8:00:00 RBTROB Update RBT635 Robot RBTUSER/036401

KYTIME 000000000004 000000000004

JOBNAM HKDEP HKDEP

PROGDS

SAVTIM 0800 0000

The following examples show various changes to the reactive job’s status. This example shows the dependent job’s status (DEPJCD) of 'blank' was changed to 'S' within the reactive job HKREACT.

05/07/14 8:00:00 RBTDEP Update RBT658 ROBOTREACT/RBTUSER/036402

JOBNAM HKREACT HKREACT

KYTIME 000000000025 000000000025

DEPJOB HKDEP HKDEP

DEPJCD S

DEPDTE 0000000 1041110

DEPTME 0800

DELNME RBHKDEP ROBOT

DELUSE QPGMR RBTUSER

DELNBR 036548 036401

This example shows the dependent job’s status (DEPJCD) was changed from 'S' to 'R'.

05/07/14 8:00:01 RBTDEP Update RBT658 ROBOTREACT/RBTUSER/036402

JOBNAM HKREACT HKREACT

KYTIME 000000000025 000000000025

DEPJOB HKDEP HKDEP

DEPJCD S R

DELNME ROBOT RBHKDEP

DELUSE RBTUSER QPGMR

DELNBR 036401 036552

This example shows the dependent job’s status (DEPJCD) was changed from 'R' to 'C'.

05/07/14 8:00:01 RBTDEP Update RBT658 ROBOTREACT/RBTUSER/036402

JOBNAM HKREACT HKREACT

KYTIME 000000000025 000000000025

DEPJOB HKDEP HKDEP

DEPJCD R C

This example shows the dependent job’s status (DEPJCD) was changed from 'C' to 'blank', which means the job will now run.

05/07/14 8:00:01 RBTDEP Update RBT659 ROBOTREACT/RBTUSER/036402

JOBNAM HKREACT HKREACT

KYTIME 000000000025 000000000025

DEPJOB HKDEP HKDEP

DEPJCD C

DEPDTE 1041110 0000000

DEPTME 0800

Find out who did a DO on a job:

Search for the job number, UsrAct, or the date and time. This is an example of a job that ran because a DO override code was entered at 7:49 on 05/12/14 by user HEATH.

05/12/14 7:49:11 UsrAct RBT276 QPADEV0009/HEATH/037502

Job 000000000028 was executed with schedule override code D

Robot Schedule Security

Using Robot Schedule security, you can allow all users to view jobs only; allow selected users to run and edit all jobs; allow selected users to run and edit specific jobs; and prevent users from performing a DO, DS, or other overrides on a job. See the examples below. For a full list of override codes and detailed information about security, see the Robot Schedule User Guide.

To make changes, security must be active in the Robot Schedule General System Defaults. If your version is at least R09M25, you can display the Robot Schedule Security (authority) report by calling RBT400 in ROBOTLIB.

Set all users to view only

1. From the System Setup menu, select option 3, Maintain Secured Objects.

2. Enter 1 next to Specific Jobs and press Enter.

3. Set *PUBLIC to DISPLAY ONLY, then press F3.

4. Enter 8 next to Specific Jobs, then press Enter for the list of jobs.

5. Set *PUBLIC to DISPLAY ONLY for each job. This also can be accomplished by entering:

   RBTGRTAUT SECOBJ(*JOB) JOB(*RBTQRY) RBTQRY(QRYALLJOBS) USER(*PUBLIC) AUT(*DISPLAY)

   Note: You can create a Robot SCHEDULE query to be used with the RBTGRTAUT command, or just enter the job name. When creating new jobs, *PUBLIC authority is defaulted to *CHANGE and *DELETE.

Select users to run and edit all jobs

1. Perform steps 1 to 5 from the "Set all users to view only" procedure above to set *PUBLIC to DISPLAY ONLY. Or, set *PUBLIC to *EXCLUDE, which will not allow users to view jobs.

2. Enter 1 next to Specific Jobs, then add the user with *CHANGE authority.

Select users to run and edit specific jobs.

1. Perform steps 1 to 5 from the "Set all users to view only" procedure above to set *PUBLIC to DISPLAY ONLY. Or, set *PUBLIC to *EXCLUDE, which will not allow users to view jobs.

2. Enter 8 next to Specific Jobs, then press Enter.

3. Find the jobs and select them with a 1 to edit their profiles and authority.

4. Add the user and grant *CHANGE authority.

Prevent a user from performing a DO or DS on a job

1. From the System Setup menu, select option 3, Maintain Secured Objects.

2. Enter 1 next to JSL-DO, then press Enter.

3. Add the user or *PUBLIC (for all users) and enter X under *EXCLUDE.