Securing Processing Options and SOX

npde500

Member
List,

Like many companies we are going through SOX 404 risk and control assessments. One of the recommendations that has been made for PSE1 is to implement processing option security to mitigate the risk of users change IV/BV processing options on demand. Our understanding is that this will require Prompt for Values, Prompt for Versions, Change and Data Selection (BV) to be secured and all versions of IV/BV to be defined on the Menu/Task View.

While we understand the risk we see this as system functionality mitigated by end-user training and management review.

Questions for list:
1. Have you implemented security on Processing Options?
2. If yes, was this for SOX or other purposes?
3. Due to the work needed to setup and maintain Processing Option Security do you think it's a good use of limited resources?
4. Any other related comments?

Many thanks,

Nick

(Feel free to reply privately if you so wish).
 
We are in the process of setting up security right now and we are implementing processing option security. Not just because of SOX but that was part of the reason, the other being simply because we didn't want end-users prompting for different versions and values unless necessary. If another version is needed, we put another version on the menu.
 
Hi Nick,

You do not want users to play with processing options. I only give processing options to user if it is required (need to put a date in the processing option).

I debugged a problem once for days -- find out that a user changed a processing option. Changed it back, and everything started working again.

For prompting for version. If the report is only 2 or 3 versions, I create separate menu items/task for each and disable prompt from value and data selection.

If the user does not need to change data selection, don't give it to them. It will save you a lot of headaches.

Good Luck
 
Nick,

I agree with Adrian. To many "really bad things" can happen if you let users play with processing options except where absolutely neccessary. We also lock down data selection except where needed.

Regards,
 
Hi all,

To answer the questions in the original post:

1. We apply security to processing options.
2. It's not specifically for SOX. We generally try to follow the "secure
all, grant back access" model.
3. We minimise the effort required by allowing users to change the
processing options on all batch programs they have access to run. For
every report there are two entries, one for application security, the
other for processing option security. Users only run reports from the
menu, and the menu entry is configured to allow access to data
selection, processing options, or not.
4. Additional comments: it would be nice to be able to stop people from
changing processing options on all interactive programs, but allow
change on all batch programs.

Regards,
Mark
ERP 8, Update 1, SP22_S1, Windows 2000 (Server and Advanced), SQL Server
2000, Citrix Metaframe XP


######################################################################### ############
Note:
This message is for the named person's use only. It may contain confiden tial,
proprietary or legally privileged information. No confidentiality or pri vilege
is waived or lost by any mistransmission. If you receive this message in =20error,
please immediately delete it and all copies of it from your system, destr oy any
hard copies of it and notify the sender. You must not, directly or indir ectly,
use, disclose, distribute, print, or copy any part of this message if you =20are not
the intended recipient. Stockland and any of its subsidiaries each reserv e
the right to monitor all e-mail communications through its networks.

Any views expressed in this message are those of the individual sender, e xcept where
the message states otherwise and the sender is authorized to state them t o be the
views of any such entity.

Thank You.
######################################################################### ############
 
Back
Top