SOX Audit Issue on system generated list of changes

[Flo4141]

Hello all, in our last SOX IT Audit, Auditors noted the following issue: "Auditor noted that a system generated list of JD Edwards data, configuration and job changes was not available to identify the true population of these JD Edwards changes made during the year". We run E1 8.11 on Windows/MSSQL.

Auditor did not consider an OMW list of objects changes as an acceptable solution. As far as I know, there is no logging/traceability in E1 that would provide a list of all possible changes to objects, data configuration points (version, processing options, udc, etc.) and job scheduler changes as well. I am curious to know if anyone else in the JDE Community have faced this issue before and how you have been able to remediate this issue. - Thanks.

 

[Robert Robinson]

I started on the Audit side before slipping over to the "dark" side

...my current company is also Sarb-Ox governed, so I realized that we needed a report to provide to the auditors. I created a report which taps into the F98210 file, which shows all object changes in all environments. The audit-facing version is one that shows all changes to objects in the Production environment. The auditors then focus on transfers to PRD from other environments, as well as changes to PRD objects (we have a standing rule that NO changes are to be made to PRD objects; rather object changes go through the normal life cycle. This report provides proof that we adhere to that rule). For objects that are transferred from CRP to PRD, we have a form which lists all objects which are to be worked on. When objects are to be created or changed, the requestor signs off as requesting, then a manager approves the proposed changes. We then create or change objects in DEV, then sign off on the changes. The changed objects are tested by the requesting user, then signed off in CRP. The objects are then transferred to PRD; if the user attests that the changes are worked as desired, that requestor then signs off in PRD. At the end of the month, accounting management then runs the report (R5598210), then requests the approved Change Management Forms, noting that all PRD transfers are accompanied by a Change Management Form. Our auditors have tested and approved this process, and have relied upon it since we went live on JDE E1 on 1/1/07.

I can discuss this report and process with you off line, as the details would bore others to tears...

 

[Luke Phillips]

Hi,

We have a solution if you use IBM.
It is an add on to JDE's Database Audit Manager which allows you to analyze and report on changes made to sensitive files. It would allow logging/traceability in E1 that would provide a list of all possible changes to objects, data configuration points (version, processing options, udc, etc.) and job scheduler changes as well, etc.

 

[altquark]

OMW logging is the correct way to go - but it still doesn't answer the fundamental question of "why" a user modified an object. It has to laboriously be cross referenced with documentation - which can really be a pain.

What is needed in E1 is a message box that pops up each time a user clicks "Check In" in DV. This could be driven through a processing option on the OMW version. The developer then could fill out a "quick" explanation of why they're checking in the object at that point in time, which is saved against the OMW logging information. This very simple OMW modification would completely make JDE SOX compliant, and would dramatically reduce auditing costs.

Just my 2c thought...someone should petition Oracle to modify this....

 

[Flo4141]

Luke, what do you mean by "If you use IBM"? Do you mean AS/400, DB2, or else? Thanks

 

[Luke Phillips]

AS/400