Create an account Home  ·  Topics  ·  Downloads  ·  Your Account  ·  Submit News  ·  Top 10  
Modules
· Home
· Content
· Directory
· Downloads
· FAQ
· Forums
· Search
· Sox_Admin
· Statistics
· Submit News
· Surveys
· Top 10
· Your Account

Sarbox Compliance
The appropriately named Sarbanes-Oxley Compliance Toolkit includes a whole range of materials specifically put together to both introduce, and take you through this most important of legislation.

For detailed information see the toolkit's own website: Sarbanes-Oxley Compliance


SOX Act and Security
As security is such a major theme on the Act, many organizations are using the international ISO standards. The ISO 27001 Portal outlines these. A copy of the standards, and security policies, can be obtained via the ISO 17799 Toolkit.

The SOX email storage requirements can be fulfilled using the GFI MailArchiver


SOX Advertisers


Sarbanes What?
Our server logs indicate some interesting mis-spellings: Sarbannes Oxley, Sorbane Oxley, Sarbanne Oxley, Sarbaines Oxley, Sarbanesoxley, Sorbanes Oxley, Sabanes Oxley, Sarbane Oxley, and Sarbanes Oaxley, to name but a few!

Sarbanes-Oxley Act Forum: Forums

The Sarbanes Oxley Act :: View topic - DEV/QA/Production Environment deployment
 Forum FAQForum FAQ   SearchSearch   UsergroupsUsergroups   ProfileProfile   Login to check your private messagesLogin to check your private messages   LoginLogin 

DEV/QA/Production Environment deployment

 
Post new topic   Reply to topic    The Sarbanes Oxley Act Forum Index -> Sarbanes-Oxley: IT Issues
View previous topic :: View next topic  
Author Message
JLewis
Soxer
Soxer


Joined: Jun 17, 2008
Posts: 37
Location: Vancouver

PostPosted: Fri Jun 20, 2008 5:30 pm    Post subject: DEV/QA/Production Environment deployment Reply with quote

Currently there is discussion within my organization about testing and dealing with system failures. Right now we are dealing with a vendor that does not give a Dev environment to work on before implementation onto the live production environment. They seem to be of the belief that testing on a live system is ok. Crazy i know, what im looking for is documentation or a link to a best practice site that i can grab information on controls that need to be in place for Application deployment.

I know this is a retarded request, but im just not sure how to explain this in more detail to the vendor other than screaming in there face "DEV and even a QA environment is a must!!!!!" Any help would be greatly appreciated.

Thanks for the help

JL
Back to top
View users profile
Denis
SoxGuru
SoxGuru


Joined: Nov 25, 2004
Posts: 790
Location: London, UK

PostPosted: Mon Jun 23, 2008 4:04 am    Post subject: Reply with quote

I would just go down the screaming route icon_lol.gif

In all seriousness though there are several discussions on here already that may help:

http://www.sarbanes-oxley-forum.com/modules.php?name=Forums&file=viewtopic&t=171&highlight=development+production

http://www.sarbanes-oxley-forum.com/modules.php?name=Forums&file=viewtopic&t=1271&highlight=development+production

http://www.sarbanes-oxley-forum.com/modules.php?name=Forums&file=viewtopic&t=320&highlight=development+production

http://www.sarbanes-oxley-forum.com/modules.php?name=Forums&file=viewtopic&t=1526&highlight=development+production

http://www.sarbanes-oxley-forum.com/modules.php?name=Forums&file=viewtopic&t=381&highlight=development+production
_________________
"The art of life is to deal with problems as they arise, rather than destroy one's spirit by worrying about them too far in advance" - Cicero
Back to top
View users profile
harrywaldron
SoxGuru
SoxGuru


Joined: Jan 12, 2006
Posts: 849
Location: Roanoke, Virginia

PostPosted: Mon Jun 23, 2008 11:56 am    Post subject: Reply with quote

Yes, I agree with Denis icon_smile.gif ... If your company must adhere to SOX standards, the lack of a DEV or QA testing environment may represent a material financial risk, esp. if this is a Financial application.

For example, a developer can insert their own routines in to "add to the bit bucket". Below is one of the most extreme examples Denis shared with us, about allowing someone too much authority in an unchecked manner:

http://www.sarbanes-oxley-forum.com/modules.php?name=Forums&file=viewtopic&t=2289

Fundamentally developers should be isolated from Production data and programs as much as possible (e.g., developers should only access production on an emergency basis with logging, audit trails, special Fire ID accounts, etc.).

I'd continue trying to work with the vendor for an adequate solution.
Back to top
View users profile Visit posters website
Crcole0956
Newbie
Newbie


Joined: Dec 09, 2008
Posts: 2
Location: Waltham, MA

PostPosted: Tue Dec 09, 2008 1:55 pm    Post subject: Reply with quote

Along the lines of this discussion about DEV, TEST and PROD, has anyone devised an effective way to test that all of the components in PROD are connected and working?

I'm sure the code itself is working because it was unit testefd in DEV, then QA and UAT in TEST. Now that it is being moved into production, how can I verify that all of the pieces work together? Is DNS working? Is the database engine working?

In the old days, I would have run a few test entries to make sure it worked end to end. Now our auditors tell us that there ca be no test data in the PROD environment.

Does anyone have experience with this?
Back to top
View users profile Yahoo Messenger
harrywaldron
SoxGuru
SoxGuru


Joined: Jan 12, 2006
Posts: 849
Location: Roanoke, Virginia

PostPosted: Thu Dec 11, 2008 3:04 pm    Post subject: Reply with quote

Hi - Yes, PROD is difficult to test and breaking in security controls is usually one of the things that will go "bump" in the night or day as you bring the new system up.

The only ideas I can think of:

-- For brand new apps only, sometimes it's an acceptable practice to run in PROD in a simulated mode a week or so in advance to test out any last minute issues. Then after the simulated PROD test is over, scratch all DBs and folders and restage everything with any adjustments. Document this well in the change management process if this approach is used.

-- Release on a weekend in PROD and have users pilot test and support team work through early issues.

-- Create a mirror PROD environment to test in, but that's tough to match and keep updated in most instances
Back to top
View users profile Visit posters website
Crcole0956
Newbie
Newbie


Joined: Dec 09, 2008
Posts: 2
Location: Waltham, MA

PostPosted: Tue Dec 16, 2008 1:35 pm    Post subject: Thanks for the feedback Reply with quote

How do we verify that the existing PROD is still acting as expected? How can I prove that all of the components are working at any given time? Are there any options for this function besides trace reporting of previous transactions?
Back to top
View users profile Yahoo Messenger
NC
MasterSoxer
MasterSoxer


Joined: Jan 18, 2006
Posts: 122
Location: Chennai- India

PostPosted: Tue Dec 23, 2008 10:21 pm    Post subject: Reply with quote

I guess one way to ensure consistency between Production and Test environment( where users did the UAT, and an environment considered to be a replica of Production) is to compare the changes that were transported( i may sound bit SAPish, but so used to working with SAP now) to Test Environment with the ones that were further promoted to PRD

When a user tests a required change( config or additional functionality) he tests such change along with so many other changes that exist in the Test environment.

By confirming that all changes that were made to the Test environment are transported to the production environment, we can get some "COMFORT" on the appropriateness of the PRD environment's functionality.

Again, the above only gives some Comfort and not absolute assurance. After all organizations need some flexibility and cannot work in a prison like rigidly controlled environment( or atleast they claim so)
Back to top
View users profile
harrywaldron
SoxGuru
SoxGuru


Joined: Jan 12, 2006
Posts: 849
Location: Roanoke, Virginia

PostPosted: Tue Dec 30, 2008 1:57 pm    Post subject: Re: Thanks for the feedback Reply with quote

Crcole0956 wrote:
How do we verify that the existing PROD is still acting as expected?


NC shares some good ideas on mirroring PROD in a UAT approach. Still "PROD is PROD" and no amount of simulated testing will fully address all concerns. For example, IT security controls will certainly differ along with other unique factors that truly can't be checked out until AFTER the change is implemented there.

Crcole0956 wrote:
How can I prove that all of the components are working at any given time?


Personally, I like the combination of using NC's approach on building an environment close to PROD -- and then releasing a few hours earlier than when users arrive (if it's a big change over) to work through early issues. For example, if folks typically arrive at 8 am on Monday (release earlier on Saturday or at 6am on Monday if no other window is available).

Have early testers (power users) shake down the system and usually after a few minor adjustments things typically work well (or you can make a "no go" decision and back off as needed).
Back to top
View users profile Visit posters website


Display posts from previous:   
Post new topic   Reply to topic    The Sarbanes Oxley Act Forum Index -> Sarbanes-Oxley: IT Issues All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Forums ©

 
Trademarks referenced on the SOX Act Forum are property of their respective owners. Comments are property of their respective posters.
Sarbanes-Oxley Act Implementation Portal: Sarbanes Oxley compliance, information, software, & internal audit committee resources. Sarbox.
Site source is copyright nuke (c)2003, and is Free Software under the GNU / GPL licence agreement. All Rights Are Reserved.