<img height="1" width="1" style="display:none;" alt="" src="https://dc.ads.linkedin.com/collect/?pid=523033&amp;fmt=gif">

NetSuite Security and Controls, Part 4: Change Management

Change management procedures have evolved substantially over time in response to continuing changes in audit requirements, often to the detriment of many clients. Auditors are asking for more evidence for changes and modifications, increasing the burden on companies to demonstrate compliance.

NetSuite has an audit log, potentially a blessing and a curse. The system notes keep a record of all changes, but not all changes are subject to a change management control. Since the administrator in any system will have unrestricted access to everything, and this access cannot be restricted or tailored in any way, someone will always have that unrestricted “GOD” access in every system. This security risk is not unique to NetSuite. Still, the challenge to NetSuite is the inability to segregate the capability to develop a change from the capability to deploy that change.

The conflict is apparent. The administrator is in the singular position to make changes at any time without being subject to any systematic enforcement. It is possible that no other person will have reviewed, approved, and tested that change before it goes into production. However, there are several things that can be done to minimize the risk to security and create a more robust change management environment.

Restrict Who Has Administrator Access to IT Users

The first recommended solution would be to restrict administrator capabilities to only IT users. No person in another department, such as accounting or finance, should be given administrator access privileges. This should be a hard and fast rule in the company.

The second recommended solution is to have a process to log every change. This would resemble a JIRA system or a service ticketing system.

When employees need to initiate a change, a change request describing the nature of the change must be made. Such a change request would have to flow through an appropriate approval and testing process. NetSuite allows different changes to be made, but not every change would be subject to the same robust UAT and related testing. For example, there may be checkbox configurations that do not require testing, unlike SuiteScript changes requiring extensive testing. A policy should outline the different types of changes that the company makes, and this policy should list the different levels of testing required for each type of change request. The policy would also detail the procedure for handling emergency changes and ensure that appropriate precautions are implemented if emergency changes are necessary.

Audit non-System Changes by Administrators

Since administrators have unlimited access to everything, it is advisable to have some control in place to monitor their activity. This is to ensure that admins are not creating or modifying transactions or master data, unless there is an approved ticket asking them to do so. This is relatively easy to accomplish, with the ability to save searches and the system notes audit trail. In monitoring the administrators and curtailing their activities, it should be borne in mind that there is no need to be extravagant. The expression that comes to mind is “There is no need to boil the ocean”. In other words, the focus should be on the key things that admins should not be doing. Admins should not be creating or modifying journal entries. Admins should not be creating or modifying vendors or customers. Admins should not be creating sales orders. These are examples of the kinds of activities in which admins should not engage.

Some tools can help to govern admin activities. FastPath, for example, can implement this monitoring control and create a search of the changes made.

Monitor System Configuration Changes

Another layer of security protection is conducting periodic reviews of changes that IT should make. These would be system configuration changes, but not every change in the system will fall under this umbrella. Change Management, therefore, refers to workflows, scripts, custom objects, enabled features, bundles, and changes to roles.

It is possible to create a system that saves searches, pulls the changes to the objects of these searches, and can cross-reference this with a ticketing system to ensure that all of these objects have an appropriate ticket. All this may sound like an arduous manual task, and it is, but be aware that an auditor will want to see this. The auditor will want to know the measures taken to ensure that no one deliberately avoided the ticketing system process and created an unauthorized change. The only way to demonstrate that things were done correctly is to pull this list of changes and correlate it with the ticketing system.

A further recommendation would be to use a third-party tool. FastPath has a feature that allows this to be done in real time. It would be an efficient practice to review this process of checking the changes against the ticketing system on a weekly basis, for instance, or at the end of the month or the end of the quarter, to help avoid sifting through a long list of changes spanning months all at one time, which can be an extremely burdensome task.

Review and Test New System Releases

Finally, when dealing with change management it is important to have a process to test and review vendor-managed changes, such as the semi-annual NetSuite updates.

Any public company subject to an audit must have a process implemented where, at a minimum, the release notes are being read. It is also important to understand the information contained in the release notes, particularly details on anything that could break in the company’s system. Any new functionality features should be noted, and a system with a large number of customizations should be given close attention. A system with many customizations is more vulnerable to having something break from one of these semi-annual releases.

All this should be looked at carefully. It should be documented that changes were reviewed and sufficient testing was performed to demonstrate the new release will not affect system operation. Doing nothing is not the correct procedure.


Read Part 1 of this series, Gotchas in NetSuite.

Read Part 2, Journal Entries in NetSuite.

Read Part 3, Fraud Risk with Vendors and Payments

Learn how you can leverage native functionality to deploy effective change management in a NetSuite environment. Download your free copy of NetSuite Change Management: Recommended Tools and Practices.