Typically in a NetSuite eco-system, there are multiple systems and each has their own intricacies when it comes to Change Management. Let us focus on NetSuite here in this blog. NetSuite as a system provides significant customization ability and hence Change Management in NetSuite should be considered as a material risk. Just today we had an unfortunate incident in one of our clients where an employee changed the underlying setup without appropriate consideration and that affected several transactions and we had to carefully undo the negative impact. Of course, access controls are also paramount but equally important is change management controls.

A two-minute overview of typical change management controls:

• Approval to embark on the project/change C1 – This is generally not considered a key control especially as an Internal Control for financial reporting (ICFR) but from an IT Governance perspective it is critical that limited IT resources are spent on only critical projects.
• User Acceptance Test C2 – Many changes should be tested by the end users in a different environment than the production. Changing something in a system that is live is like changing something in the car while it is running – testing it is very critical. There are so many aspects that should be considered for testing and we will get into that in a future blog.
• Data Validation C3 – Many projects have critical data migration that is required. This could be an import from an old system, from another system or from the same system but with a different format. For example, if a new field is introduced to capture additional data point, this field should be updated for old transactions too. Data validation can be performed at various times and multiple times during a project.
• Approval of the change C4 – This second approval is just before go-live. This is provided by the Business Process Owner and potentially other process owners if it is a cross process changes. The timing of the change, the success of the project, results of the UAT, the severity of open issues pending to be addressed, how well the end users are trained, ability to roll back the change if it was not successful and appropriate communications are few criteria that should be considered before the approval.
• Post-go-live validation C5 – In many cases, appropriate testing could not be done or need not be done before the production deployment but a post-go-live validation may be relevant.
• Review of (non-compliant) changes C6 – A detective control that requires a review of all changes on a periodic basis or if possible, review of changes that are not compliant.

We are going to try to provide a review of different changes that can be performed in NetSuite and what change controls may be relevant for them. Although it is tempting to say that all controls should be implemented for all type of changes, it may not be efficient. Depending on the risk appetite additional controls can be implemented. Please review your particular situations, such as the complexity of the system, experience of the users, segregation of duties, etc. before leveraging the table below.

* – Sometimes a report could be part of a workflow, a script or part of external communications and hence it may have an increased priority.

** – Configuration changes may range from a small benign change (example, “Show list when only one result”) to instance level change (example, enable a new functionality or a new segment) – As part of change ticket creation, this evaluation could be performed and what downstream controls to perform could be based on this evaluation.