Documenting Changes

It is important that you model appropriate controls in your system development life cycle (SDLC) related to customizations of the NetSuite application, such as custom roles, scripts, custom records, workflows, and other customizations. Your change management process should ensure that changes are authorized, tested, approved, and documented.

You should document changes on a standard change request form. This form can be physical, but an electronic form is preferred. For example, depending on the nature of the change, the NetSuite product team maintains change documentation through issue records, production maintenance records (a custom record type created for this purpose), or feature records.

Depending on business needs, NetSuite custom records can be tailored to serve as change request forms. Ideally, whatever documentation is used, the form should contain information that can easily be completed by the requestor. The request should be tracked internally using a document repository tool, and should include an approval mechanism to move the request from stage to stage in the change management process. A benefit to using issue records or custom records within NetSuite is that you can run saved searches on these records to generate a list of all changes for specific periods. Saved searches also support filtering to deliver information needed for audits or reviews. Using custom records also makes it easier to ensure that required fields are completed before tickets are closed, and that approvals are obtained before a change request moves to the next level. Fields such as attachments of test plans, or summary of test results can be required within the request.

A change request form should include information such as:

• Requestor name

• Date of change request

• Description of change request

• Reason for change

• Assignee to implement change

• Authorization to begin work to implement change

Custom forms can be combined with a workflow to ensure that approvals are routed automatically when specific steps are completed. For example, after a requestor submits the form, it can go to an authorized individual or group to approve the change. The request can then be routed to other approvers as it moves through the following steps of the process:

• Development

• Testing / Quality Assurance (QA)

• Implementation in Production

Each step along the way should be documented on the request form. This documentation provides point-in-time information about each change, identifying the account in which the code change resides, responsibility for the change, and the impact of the change.

As with any process, exceptions may occur, and when they do, the change management process needs to document how to handle these exceptions and capture appropriate evidence. It is possible, for example, that if production code breaks, a developer may be required to go directly into the production code to quickly correct the problem. That change would then be worked backward into the other accounts, like test and development. In this example, that emergency change would be documented on the request form. It would be noted who performed the change in the production account, when it was performed and why it did not follow normal SDLC procedures. It is important to capture these details as evidence for auditors. A well-controlled program code change management process includes strong segregation-of-duties controls to ensure the right people are making the code changes and moving code to the correct accounts, only after receiving the proper approvals.

General Notices