Devil's advocate...
"Where's your audit trail showing the source code you mention is actually the source code the object was created from? All you are showing me is who checked it out."
"Prove to me this source code was actually the one used to create the object?"
The vendors have dealt with these sorts of questions in the past and can supply your auditor the information regarding how their package's audit trails are created. You have to prove you use the package as it is intended to be used. This means developers become users of the product: No going directly to object to change anything. No changing production source code without first checking it out through the product and using the product to promote changes to production. This includes what may have been written to support operations.
If you must make a direct change, an audit trail is in order. This can be as simple as a Word document stating "At the direction of the vendor we used product EZVIEW to change field BLAH in table BLABLAH."
Whether you are a public company or not, setting up your procedures for a SOX audit is beneficial. All it does is help the honest remain honest, just like any other accounting controls. It isn't to be feared but embraced, and could be what saves your career. Just look at what happened to Bernie Madhof's programmers.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Wednesday, July 23, 2014 1:56 PM
To: Midrange Systems Technical Discussion
Subject: RE: Change Management for small shops
DSPOBJ on the application. Get username and date for who compiled the object and the source it was compiled from. Go to our checkout log for the source code. Show the request from the user associated with the source checkout and who checked it out.
What we would fail on is proving that programmer X does not have authority to production objects. They do. What we can show is that we log every change to every object
If one did have a purchased package are you required to answer the question "Prove to me your purchased package process actually does what it says it does." You, as the one being audited, have no way to answer than without access to source code. Although you can say here is the audited statement from the vendors auditors saying it is.
SOX is not something we have to audited on.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Monnier, Gary
Sent: Wednesday, July 23, 2014 4:44 PM
To: Midrange Systems Technical Discussion
Subject: RE: Change Management for small shops
The cost will depend on how you answer the auditor's "Prove to me" questions.
Questions like "Prove to me this production object has not been altered outside approved channels.", "Prove to me your home-grown process actually does what you say it does." And "Prove to me your procedures satisfy SOX compliance."
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike Cunningham
Sent: Wednesday, July 23, 2014 1:34 PM
To: Midrange Systems Technical Discussion
Subject: RE: Change Management for small shops
Without revealing any vendor secrets, what does a change management with deployment cost ? upfront and yearly. We only have 6 developers who all sit within 20 feet of each other and talk daily and they manager is also in the same space so never really found the cost to be justified and our auditors have been OK with it in the past. But auditors have different opinions sometimes and we just got someone new for the financial audit.
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Thomas Garvey
Sent: Wednesday, July 23, 2014 2:46 PM
To: Midrange Systems Technical Discussion
Subject: Re: Change Management for small shops
TD/OMS (formerly known as Tight As a Drum) handles all of that: source and object control, IFS documents (everything), complete life cycle management, and excels at roll-outs and roll-backs to multiple targets.
Thomas Garvey
<
http://www.unpath.com/>
On 7/23/2014 1:09 PM, rob@xxxxxxxxx wrote:
And a good change management product will tell you when you try to
roll out a printer file from development to production if someone
changed any attributes on the production, like changing default
printer, overflow line, etc. Stuff that you don't even need to recompile for.
Rob Berendt
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
