This company had been on an impressive growth run and executives were thinking about what was next. They knew that step would require greater compliance. They also knew that the strictures of Sarbanes-Oxley (SOX) would require a more transparent and nimble look into what was happening within their internal systems than they could currently provide.
The goal of SOX is of course to protect investors by improving the accuracy and reliability of corporate disclosures. As business systems have moved into the cloud, conventions like information technology general controls (ITGC) have arisen to ensure the proper development, maintenance, and operation of these systems. Yet the controls often exceed what’s natively available in platforms like NetSuite.
Take audit trails and documentation, for example. These are complex and difficult to create within an ERP in a way that satisfies the ITGC’s demands for security, data integrity, availability, confidentiality, and privacy. The team’s workaround involved tracking every NetSuite change in their ticketing system Jira, which of course is not designed for this purpose. The team was more or less manually having to document their own requests to make changes, make those changes, and then document that they had made them. On top of this, all that information had to be made available to auditors on short notice, which meant it always had to be complete and organized.
This wasn’t all. Because the current setup was so reliant on employees’ behavior, they didn’t have a formal process to govern how changes were to be made in NetSuite. Thus, different people documented things differently, and the results were difficult to query. And whereas SOX requires a single individual deploy scripts to production, their NetSuite team was growing and working in multiple environments, and multiple people with varying experience levels were touching the system.
While the team could see when changes were made via SuiteScripts within the System Notes, it couldn’t tell them precisely what code changes occurred
While the team could see when changes were made via SuiteScripts within the System Notes, it couldn’t tell them precisely what code changes occurred. Thus, the code changes weren’t linked to requests. That meant they couldn’t tie those changes to the applicable business request to complete the trail for the audit. So, the NetSuite team had to manually check the history for each entity to see the changes and paste documentation into the applicable Jira ticket. This took time, to say nothing of the potential it created for human error.
Moreover, changes in one NetSuite entity flowed into others. This created waves of additional, indirect changes that were even more difficult to track. For example, a change to a certain workflow would trigger a change to someone’s Role, with no record of why. (Such ‘side effects’ can even occur in different, connected bundles.) The changes were hard to interpret, and even harder to explain to an auditor. As the executives came to understand the importance of proving compliance, it was clear something had to change.
After a short evaluation, the team selected Salto and launched a project. The two teams worked together to rethink the company’s compliance needs, understand its data, and set about automating it.
Together, the two teams:
With the solution up and running, the team was able to:
Under this new schema, users could add the relevant Jira ticket number and the Git commit, and thanks to the Jira-Github integration, it would automatically link the ticket. They had achieved their audit trail for every commit.
This meant the team could view the Git history from three levels: on a file level, on a system level, and on a business request level. On the file level, they could visit a file and see the history of changes—who touched what and when, and what changed as a result. On the system level, they could see all changes made throughout their history of use, across all configurations. When they clicked on a change, it showed them all the relevant files that changed. On the business request level, they could go into specific tickets on Jira and see the history of changes made across both Jira and GitHub that were related to that business request.
In the end, someone auditing the NetSuite System Notes could see a change, ask why it happened, and the team could simply search that element in Jira and find out why.
With automated documentation and business request trails, the team was able to review and keep a close track of changes made to NetSuite. For the first time, they could understand the context of each change and, automatically, tie those changes back to the relevant business requests as detailed in their respective Jira tickets. Now that they had documented versions of files from exact dates, they could also perform revert and debug operations. They could also proceed with their designs for growth.
Because of Salto, this company:
And, most importantly: Shortly after their initial deployment, the company leveraged the Salto solution to successfully complete EY’s pre-audit process.
"With Salto, we were able to ease our compliance concerns and make changes to the NetSuite system with confidence, knowing that we had a complete audit trail for every change request. We were extremely satisfied with the new level of transparency, order and overall control the Salto solution brought to our processes." -NetSuite Team Leader
This software company has helped E-Commerce companies since the early 2010s. Merchants rely on its platform to offer a better checkout experience and to better process payments. Because trust and automation are core to its software offering (many customers are among the Fortune 500), it felt incongruous for their NetSuite team to be pouring so many hours of manual work each week into their ERP.
"This really is 360-degree audit coverage for NetSuite. From every angle, we can see, track, and explain."