IT in-scope Systems 2462
benhchang last edited by
I am trying to get a better understanding whether non-production systems
such as dev, qa, staging, etc systems should be in-scope for SOX. If it
should be in-scope, what is the reasoning?
Here are my thoughts:
Access Control - non-production systems cannot materially misstate financial records. Only production system can and only production s/b tested.
Change Management - Testing s/b performed in non-production environment and approved to migrate into production. The testing s/b focused on User Acceptance Testing and Change Control sign-off to migrate into production.
gmerkl last edited by
User access to non-production systems (development system, quality assurance system, etc.) should not be in scope. The risk that somebody makes unauthorized entries in such systems is low and the impact is insignificant. The only problem could be that if the quality assurance system is a recent copy of the production system and somebody has too much access, then this person could look at potentially confidential financial data (i.e. salaries, etc.).
However, a quality assurance sytem that is used for user-acceptance testing of own developments or new versions/releases of the package should be a recent copy of the production system with real-world data so that testing is happening in a comparable and realistic environment. Most releases have been tested by the software vendor and other customers anyhow, so the risk of material problems is low. I see the main risk in own developments or changes to customizing or master data that are not properly understood by the users if they have not read the documentation/help and have not tested how it works in a quality assurance environment.
In conclusion, due to low risks, I think it is rather out of scope.
Denis last edited by
The non-production systems would not be in-scope per se. However, when considering the effectiveness of General Computer Controls over the in-scope system one would look at the appropriate management of the programme changes across dev, test and prod.
There are several discussions around this on this fourm already
NC last edited by
Non-production systems may not be strictly in-scope, but they do play a major part in the application change management part, specially logical access to non-prod systems.
Ex- same user having capabilities to make changes in Dev and Mock, with ability to move such changes to prd, is a clear case of an SOD conflict and may even result in unauthorised changes being pushed to prd.
though, we can consider non-prod systems to be out of scope, it is a safer practice to consider them in-scope wherever considered appropriate.
of course this would depend on the application landscape and the apps team organization.
harrywaldron last edited by
I agree with all the good responses above … While UAT, QA, or other test sides of application development might not be in the ‘direct’ scope of financial IT controls, these environments certainly play a role in the SDLC process. Thus, they cannot be completely ignored.
A quick list of some recommendations include:
- Change Mangement and Test-to-Prod release controls are always important and would be on any auditors checklist.
- Classical audit controls are necessary:
– separation of duties (to ensure developers can’t release their own work)
– checks and balances (ensure multiple participants control the entire process)
– autonomy levels (ensure only authorized appointed personnel can approve releases)
- Test financial data should be made as fictitious as possible (so that confidential business results don’t leak out).
- Developers should not have access to sensitive production Financial information except as approved by management in support or under emergency conditions.
- IT security on the test side needs to be as strong as production, in that you don’t want outsiders breaking in through test and possibly getting to the PROD environment through some weak control. Security is only as strong as it’s weakest link
Most of these points fall under ITGC standards. Still, a weak General Controls audit would most likely lead to recommendations necessary for addressing under SOX 404 compliancy as well. While they are separate, many of the control principles are also inter-twined.