Re: SOX compliance -- MIDRANGE-L

In essence:
1. The corporation has financial data.
2. Access to & manipulation of that data is defined by a set of controls.
3. The controls are followed.

Most everything in a SOX audit is derived from that. 2 means you have -
documented - controls. The controls are built on - documented -
processes. The processes cover things like approvals (change management,
ID requests), segregation of duties (developer access to prod, accountants
can't approve invoices they enter), proper network design, changes to the
data's environment (systems, applications, etc.) etc. 3 means you can
provide evidence that the controls are being followed. System &
application logs, change management records, a documented user ID
management process w/audit trails, etc. stem from that.

Really, it's about taking reasonable care of the financial data. The
controls, documented processes, and evidence are nothing more than what you
should have been doing all along. SOX just provides a formal audit
mechanism for the effectiveness. What's tlling about corporate struggles
with SOX is that many companies either didn't have documented processes or
didn't have formal processes at all. SOX is an attempt to rectify that.

In theory, as long as your controls are legal and reasonable, they don't
have to align with an auditor's views. They just have to exist and you
have to be able to provide evidence that you're following them.

That said, the smartest thing to do is pick a framework like COBIT or ITIL,
organize around that (which will provide you with controls, processes, and
evidence), and when the audit comes around tell the auditor "we're aligned
with COBIT; here's your evidence" and let them hog a conference room for a
few days while they write the report.

On Mon, Feb 25, 2013 at 10:03 AM, Rich Loeber <rich@xxxxxxxxx> wrote:

Joel,

SOX is all about getting executives to be responsible for the numbers
that
they are reporting. If you read the entire SOX act of 2002, you will
not
find the word "computer" anywhere in the document. However, reading
between the line, there are three sections of the SOX Act that apply,
specifically sections 302, 404 and 409. Find a copy of the act and
focus
on these three.

Here's a link to the details: [1]
http://www.sec.gov/about/laws/soa2002.pdf

Rich Loeber - @richloeber
Kisco Information Systems
[2]http://www.kisco.com

--------------------------------------------------------------------------

On 2/25/2013 10:43 AM, Stone, Joel wrote:

Does anyone have a summary of how SOX compliance should or could affect a
typical Iseries shop?

>From an IT auditing standpoint?

For example, outside auditors recommend all sorts of steps and often
reference SOX compliance. How detailed does SOX get regarding this such as:

- IT issues in general

- Separation of PROD and TEST environments (or even hardware)

- User ids; using IBM user-ids, control of job schedulers, etc

I thought SOX was more of a financial and top management responsibility
and accountability act. How far down the IT control structure of a typical
company does SOX reach?

Thanks!

______________________________________________________________________
This outbound email has been scanned for all viruses by the MessageLabs
Skyscan service.
For more information please visit [3]http://www.symanteccloud.com
______________________________________________________________________

References

Visible links
1. http://www.sec.gov/about/laws/soa2002.pdf
2. http://www.kisco.com/
3. http://www.symanteccloud.com/
--
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.