These subjects -- compliance with regulations like SOX and other
"quality-focused controls" are near and dear to my heart. And I have some
opinions and perhaps information about them. Hence a long-ish post. Maybe it
will help someone, somewhere.
The worst thing that happened as a result of the new SOX regulations is that
IT suckered ourselves with a double punch. First, we flat-out refused to
take a proactive part in this. We whined and whinged and wheedled and
wrangled our way out of things - developing strategies to AVOID DITCH and
DODGE the requirements -- energy and intelligence that could've been well
used in coming up with ways to BENEFIT from it. As a result the driving
force behind the compliance came from other parts of our organizations.
Battle lines were drawn. Overcompensation was rife. So -- water under the
bridge, but if your procedures are over-blown, cumbersome and
counter-productive CHANGE THEM. Nobody here is going to argue with a
straight-face that whacking away in live with no controls is BETTER, are
they? Find the sweet-spot. Push back. Make suggestions. The auditors
will buy into a lot of well thought out reasonable procedures. Not just buy
into, but jump on.
Many of my customers are small enough organizations, or small enough IT
shops anyway, that the segregation of duties was going to be a stumbling
block. But we put some controls into place to prevent a programmer from
testing their own software or from promoting their own change. And I
haven't seen any auditor balk at it. So we didn't have to add new staff, or
train somebody over in purchasing to do rollouts...we put our
checks-and-balances in place from within.
Similarly every company -- not just in our U2 world, but every company --
has a requirement to SEE a problem on live, perhaps even to FIX a problem
on live. That might be software, that might be data. We came up with
procedures and controls that accommodate and even capitalize on this -- and
which are compliant and have passed audit. When an auditor says "you cant
make any changes on live" you can respond with "This is how we make sure it
doesn't happen casually, and here are our controls and procedures (and
audits) for when it needs to happen". Voila! Everyone is happy.
As far as "going around" controls --
First, this constitutes fraud and the IT staff need to understand
that. It is (and should be) a "firing" offense to go around the controls,
just because you know how. {I always liken this to locking your convertible.
A rag-top can be easily compromised, but nobody doubts that slashing through
someone's convertible to take their car or things in their car is a CRIME.
And honest people won't do it.) The procedures that folks are expected to
follow have to be reasonable enough that everyone can be reasonably expected
to follow them.
Most importantly: remember the purpose of the SOX legislation. It
is for the prevention and detection of financial fraud. If a control is not
completely secure ask yourself "how attractive is this opportunity for
financial fraud?" Analyze and put risk values on your controls. Then spend
your time and effort where the risk lives. (This exercise can actually be
quite fun -- "How could I financially defraud my company from an IT
perspective?")
As an aside, the remote-VOC stuff in Universe (but sadly not
available in Unidata) can be used to really tie down some of the "go around"
methods described in this list over the last few days.
I'm going to get off my soapbox now, but naturally I'm going to drop in that
PRC is a software development life-cycle tool that can provide the IT
controls and procedures (the framework) to immediately and effectively meet
the requirements of SOX (and other regulatory compliance) while promoting
best practices and STREAMLINING productivity.
Susan Joslyn
SJ+ Systems Associates, Inc.
http://sjplus.com
[EMAIL PROTECTED]
(954) 796-9868
PRCR Real software configuration management for Multivalue/U2.
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
