How & Why Segregation of Duties is Important for Change Controls
Every company deals with changes to their IT systems, some more frequently than others. Individuals within a company may request changes to their IT staff for in-house systems or contact their vendors and submit a request to make a change for outsourced systems. These changes can be something minor in the coding that is not seen to users, or it could be a whole interface change; it all depends on the needs of the company. However, there are multiple steps that go into getting this change into production for their users to see. Part of a SOC 2 report, Common Criteria 8, relates to Change Management, which has to do with these application or infrastructure updates. It is extremely important that there is segregation of duties in place to handle these changes for compliance and other reasons. Below are 5 key items that explain how and why segregation of duties is important as it relates to Change Management.
1. Prevention of Fraud and Errors
In a typical SOC report, there are usually controls that state that system or infrastructure changes are reviewed, approved, tested, and implemented. It would be a best practice to split up these four tasks between several employees. There does not need to be four separate employees doing these tasks, but probably two or three. Those who review should not approve, and those that approve should not implement, to prevent fraud or errors from occurring.
2. Error Detection
Once a change request is reviewed, approved, and tested with the IT team, another best practice would be to walk through the change in the test environment with the individual who submitted the change request to confirm that the change meets that individual’s needs. The IT team might interpret and execute the change differently than the individual that submitted the request. Since those who submit change requests usually deal with the users of the applications firsthand, they know specifically what they are looking for as the outcome of the change request.
3. Business Continuity
Most IT teams have different environments in place to create, test, and implement a change request. If this is not the case, it is recommended that a test environment be created in order to prevent any problems occurring with the application when changes are implemented. If the new coding is implemented in the test environment first, the IT team can see how it will work with the rest of the in-place processes, and updates can be made if needed. This eliminates the risk of business operations being compromised as a result of a change request.
4. Meeting the IT Team’s Needs
Depending on the size of the IT team, sometimes individuals on the team are dedicated to specifically creating code, testing, or implementing the change. When a change request is submitted, the best people for the job should be assigned to the task. This should give the individual submitting the request some comfort, and it also helps with the prevention of fraud and errors. However, if only two people are tasked with the change request it would be best practice to take advantage of item number two above to make sure all aspects of the change are covered.
5. Compliance
Segregation of responsibilities is a focal point of the AICPA Trust Services Criteria, the framework used for SOC reporting. This concept is specifically called out in Common Criteria, “A process is in place to implement system changes with consideration of segregation of responsibilities (for example, restricting unilateral code development or testing and implementation by a single user) to prevent or detect unauthorized changes.” To be compliant with SOC requirements, segregation of duties must be in place.
There are likely more reasons to have segregation of duties in this setting, but the five listed above are a great starting point to help evaluate any change processes currently in effect. If your entity is interested in obtaining any additional information on SOC 2 reports, or if there are any other questions related to SOC, please contact us. For more information on these services and more, be sure to visit our SOC & Technology Consulting, Cybersecurity, and Forensic Examination pages, and don’t hesitate to contact Dave Hammarberg regarding our services.
About the Author
Kaity joined McKonly & Asbury in 2021 and is currently a Senior Accountant with the firm. She primarily works with clients in the SOC industry and employee benefit plan audits.
