What *IS* a _and_quot;Program Change_and_quot;? 2339
Pipeline_IT last edited by
Our SOX manager insists that any changes made to a program is a program change, including backdoor changes of data. This is causing a very cumbersome process to correct simple data entry errors.
For example: A user need to change the year on a GL entry because she fat-fingered the keys when typing. Our SOX manager says that since we are making the correction via a SQL script, that is a ‘program change’.
I disagree. Who’s right?
Is there any guidance on what exactly falls under the ‘Program Change’ umbrella?
Hi Pipeline and welcome to the forums
Based on the specific scenario shared, I see this more as a ’ one shot’ data correction change . A one time program or script is written, and by definition these items would not need to maintained for another change in the future. Program changes reflect the underlying source code, that are maintained as part of the overall application system on a continual basis.
One shot data corrections still need to be documented and controlled via change management . However it most likely would not need to be documented and communicated in the exact same manner as program changes. Hopefully, you should be able to use a more abbreviated process (e.g., emergency or ‘fire ID’ type system to revise information outside the normal change control process.
On the topic of ‘program changes’, Sox 404 does not define this in detail, as instead it provides a more generic framework for IT financial controls across a broad range of industries. Secondly, many external SOX auditors use COBIT as a framework to measure IT based SOX controls to help assess 404 related concerns. Below is a link that provides a free copy if you register as instructed in the post:
COBIT 4.0 Standards - Free copy
There are many IT related changes that may not involve actual ‘code’ changes, including:
- SQL statements (in stored procedures outside the program)
- Forms, screens, or report layouts (where no code changes)
- Data corrections
- File rehosting (e.g., moving to new server or versions of OS or RDBMS)
Also, you might want to contact your external SOX auditors on how they suggest handling special situations like this that are outside the normal program change control process.
Denis last edited by
Why not just reverse the entry and repost?
Easier than writing a script and then you just have to keep the audit trail on the journal.
Pipeline_IT last edited by
Oh I was just using that as an example… I’m not an accountant, I’m just the IT guy.
But stuff like this happens all the time… minor corrections to data fields in the accounting database that have to be done through an SQL script. The same thing with our gas accounting application.
I think we need to talk to our SOX manager and come up with a new a control management process that doesn’t involve 10 pages of paperwork to run a 2-line SQL script. Change management is important, and I can see its usefulness in actual changes to code, but this is just silly.
Yes, I agree as I’m an IT guy also … Multiple change management approaches work best, as you don’t want to use elaborate program change control procedures on one-time data corrections. It should be a ‘lite’ version that flows somewhat naturally with the program change control approach (e.g., don’t ‘reinvent the wheel’, and use existing procedures, approvals, and autonomy levels where possible).
To balance SOX and other related audit trail needs – there is a need for good change management controls and documentation. It should be efficient, electronic, tamper-proof, and not bog down productivity. I’d recommend a meeting and maybe the external auditors can share ideas if applicable.
kymike last edited by
I’m with Denis on this one. The user should to create a journal entry to correct the error as the JE will leave an audit trail. If you make changes directly to the database, then you need to go through the change management process to document and test the change as that would be the only audit trail that exists.
Agreeing with Denis and Kymike as that is indeed a better way of documenting this adjustment from a SOX perspective, (e.g., accounting rather than IT is responsible for the applicable adjustment - although in this case IT had to lend a helping hand in writing some SQL to actually repair the data .
The original post was shared more from a conceptual viewpoint of how to perhaps address other situations where data corrections or adjusmtents might take place outside the normal program change management process. Hopefully, some of these ideas will help.