Ever-changing compliance
Regulators tend to be heavy on demands but light on guidance. This is very much on purpose. As the world changes, so must you.You are expected to comply with the spirit of the law, even if all the technologies the law was intended to govern change—as is the case with Sarbanes-Oxley, or SOX.
It’s been two decades since SOX was written. Back then, the iPhone did not exist. Neither did Facebook. Salesforce was a mere three years old and popularizing a technology called “the cloud.” When SOX’s authors wrote “managers must design processes,” they had paperwork, not software, in mind, and nowhere in the entire 31,000- word document will you find the phrase “data security.” Such a thing was barely a consideration, for it involved tape decks and trucks. Yet you would be negligent not to address data security— aka unintended financial software configuration changes—when addressing SOX
In this guide, we’ll explore:
•
How the spirit of SOX has evolved
•
How the availability of new improved data governance technology has created an arms race for greater compliance
•
How some companies use Salto to overcome SOX
What SOX demands of you now
SOX was written in the aftermath of a string of epicU.S. public market disasters. Virtually overnight, an accounting scandal reduced Enron—then the seventh- largest company in the U.S.—to bankruptcy. Not long after, Worldcom’s implosion on similar grounds wiped out 30,000 jobs. SOX was passed in direct response, to impose consequences for misleading the public about a company’s financial performance.
Every U.S. public company must now abide by it, and every aspiring public company must prepare for it. But the law’s word and intent have diverged. In 2002, the sentence, “The signing officers … have designed such internal controls” referred largely to people, paperwork, and on-premise servers. Today, when most public companies house their financial information in a cloud- hosted ERP like NetSuite, it primarily means digital fields and software configurations.
Similarly, the phrase, “destroys, mutilates, [or] conceals” used to refer to binders and backup tapes, but now includes digital deletion. And when the law stipulates that managers must not only ensure compliance, but prove it, NetSuite truly begins to pose issues. NetSuite’s ERP product, launched in 1998, is lugging 25 years of architectural baggage and doesn’t lend itself to tracking and documenting script-level changes—something regulators now expect. And with your IT team in there making changes along with finance and business analysts, lots can go wrong. They can all easily alter permissions, and thus SOX introduces compliance demands most companies can’t solve on their own.
For challenges like this, a tool like Salto is helpful.
Guide
How to Supercharge Your
Business Applications with
Software Development Practices
Download the guide ≥A checklist for preparingNetSuite for SOX compliance
Because the law is somewhat vague, there’s no one checklist we can offer that will confer perfect SOX compliance. We wish we could. What we can offer are several degrees of risk mitigation and security used by our clients, the first and most importantof which is creating a structure that allows teams to document what changes were made within the system, by who, and for what reason.
This visibility must include all changes to NetSuite’s configuration. While some changes to NetSuite may not have a documented business requirement, you should be able to work back to some note about who made the change and why. And if the change did have a documented business requirement (usually captured in a ticket system like Jira or ServiceNow), you should be able to quickly and easily understand what change was made, and locate evidence of that change in the system.
Very often, teams rely on a ticketing system such as Jira or ServiceNow to manage business NetSuite requests. The challenge with this is that ticketing
systems don’t have any native documentation capabilities, so the tickets aren’t linked to actual configuration changes. That leaves this process reliant on the honor system and rigorous self-documentation. Notes developers keep for themselves about these changes may not be available to everyone, and even if they are collected, they probably aren’t searchable because everyone probably recorded things differently.
Furthermore, while NetSuite’s system notes allow you to see some types of changes, such as fields changing from A to B, you can’t see any details on changes to scripts or flows. You might know the script or flow changes, but you wouldn’t know what exactly happened. This makes it difficult to link it to a business requirement, even if you are using a ticketing system.
This process (or lack thereof) makes it difficult for new employees to get up to speed and understand the history of changes that preceded theirs. But even more to the point, it presents a real challenge for audit-readiness.Anyone who wants to investigate a change has to go into NetSuite to try to track down the change manually.
There’s also no way to gauge impact analysis
A lack of documentation is just the beginning. To implement truly defensible controls, you’ll also need the ability to anticipate the effects of changes before you make them. For instance, could altering a field or object in NetSuite have unintended consequences?Might it accidentally destroy financial information and expose the firm to some future risk? In NetSuite’s native offering, it’s difficult to know before you try.It’s also difficult to know if other systems connected to NetSuite, such as the CRM or billing system, are making changes, and what effects those could have.
Now, you can always purchase NetSuite’s development and sandbox service to test changes before implementing them, but it does little to remediate the problem. Without an ability to root out dependencies prior to testing, and to understand them across workspaces, you have no choice but to engage in some amount of trial and error.
NetSuite is very open about these shortcomings in its own marketing materials. One of its
white papers, intended for explaining how to achieve SOX compliance (among other things), states, “Customers may wish to consider using third-party tools.”
Anyone who wants to investigate a change has to go into NetSuite to try to track down the change manually
SOX requirements within NetSuite
| SOX requirement |
What it means in NetSuite |
Sections of the law |
| Executives are personally accountable
CEOs and CFOs are personally responsible and accountable for financial reports and internal structures.
|
Executives must be able to know everything that happens in the ERP Must be audit-ready
|
Sections 302, 802 |
| Retain your financial data
Responsible parties agree never to knowingly falsify financial data.
|
Need controls to retain all financial data
Need controls to prevent unauthorized parties from altering financial data Need an immutable audit trail to prove what changed where, and why Need the ability to analyze the impact before making changes
Need a segregation of duties (SOD)
|
Section 802 |
| Report on your compliance
Management creates “adequate internal control structure and procedures for financial reporting.” Management must also publish an annual assessment (control report) of the effectiveness of their compliance.
|
Must include a section on ERP compliance in your 10k
Must be aware of dependencies, opportunities, vulnerabilities, and compliance history Visibility into customizations (including scripts and unlocked bundles)
Track changes by anyone (including workflows and SuiteScripts) A way to request and approve changes and controls
|
Sections 401, 404
|
| Expert auditors must sign off on your compliance reporting |
Auditors must be able to audit ERP configuration changes |
Section 204 |
| Protect your data
Secure your data against all parties, internal or external, as well as threats.
|
ERP must be locked down to prevent malicious changes Must be able to prove ERP is secure
Need a segregation of duties (SOD)
|
Implied but not stated
|
How to use Salto to satisfy SOX
Salto helps with NetSuite compliance by providing a layer of visibility and structure where none exists today. NetSuite is highly customizable and in some cases, has gaps in what it can observe about its own operations, but Salto has the ability to observe and report on nearly everything. (The exception is locked bundles, but these are unlikely to be audited.)
Salto does this by integrating with your NetSuite instance and extracting all its configurations and operations into readable code. When everything is readable code, it becomes searchable, trackable, and understandable. With Salto, teams can see when changes are made beyond what’s visible in the system notes, including code changes, and the details of those changes.
Salto extracts NetSuite configurations
Salto is able to provide this structure because it uses NetSuite’s own SuiteCloud development framework (SDF) to extract the configurations. In the graphic pictured, you can see there’s a core Salto application which provides a graph of system configurations, which appear in a uniform structured language.Salto discovers what’s inside each of your NetSuite configurations using the NetSuite adapter (built in SDF)and pulls them into Salto’s uniform environment.
From the core environment, you can both fetch and deploy configurations. Because Salto’s SDF NetSuite adapter can see everything within NetSuite, including changes NetSuite can’t natively report on, you gain amore expansive view of what happens within.
Cross-environment visibility
Another important aspect of Salto’s NetSuite adapter is it offers full tracking across environments, if you have them. You gain visibility into what changes moved from a staging or user acceptance testing (UAT)environment to production. This means not only are configurations documented, but so are the stories ofhow those changes came into being.
.jpg)
How to get started
To implement SOX controls, you’ll need, at minimum, three systems:
.png)
Salto — for visibility into (nearly) all NetSuite configurations, for multi-environment visibility, and for impact analysis.
Jira or ServiceNow ticketing system (or similar)— for tracking business requests and confirming they were implemented.
.png)
Git (or similar version control system)— for documentation, versioning, and collaborating on configuration changes.
With this setup, you can connect a new Salto workspace to the company’s NetSuite production environment. You can create a GitHub repository for versioning, and connect it to the workspace.When the business team makes requests, they can submit them via the ticketing system.
With Salto and Git, teams can maintain multiple staging and testing environments, and contributors can create and merge branches to work productively in parallel. When the development team wants to make changes within NetSuite, they can do it from NetSuite (in which case it’ll show up in Salto). But they can also test and conduct impact analysis in staging environments of their choosing. Once they’re satisfied that a given change will work, they can use Salto to push the change into production and link the relevant Jira ticket to that Git commit, leaving documentation.
Salto provides several overlapping layers of control
Implementing Salto along with an interlocked ticketing and version control system provides structure and documentation. That structure and documentation serves as a control that’s a key part of satisfying SOX.
Specifically, this setup provides:
1. Documentation and an auditable record
Salto gives full visibility to the changes within scripts and flows which aren’t shown in NetSuite’s system notes. It also allows you to document changes (along with Git and a ticketing system) and to trace changes either from the ticket into the system or vice versa. What’s more, this documentation is available within Salto in a standardized, searchable fashion, for a fully auditable record.
Auditable record
Reduce risk and known unknowns
Cut audit prep time
2. Impact analysis
Because Salto allows teams to inspect elements within their NetSuite instance in multiple environments, they can run tests and understand the impact of a change before they make it.
Understand the impact of changes
Inspect elements and understand dependencies
Allow multiple teams to collaborate in a sandbox environment
3. Risk control and management
When implemented along with a versioning tool like Git or Github, Salto allows for broad impact analysis. Teams can create multiple sandboxes, allow multiple teams to merge development branches, test in production-like environments, and roll back changes.
Reduce the risk of making changes
Increase certainty for annual reporting
Troubleshoot faster
Improve executive awareness
Revert if needed
4. Structure your operations
Salto provides something of a common language for understanding NetSuite configuration changes, and for documenting them. This allows multiple people of varying skill levels and access to stay organized and compliant with a proper segregation of duties, across regions and over time. This reduces the potential for human error and speeds up onboarding.
Makes documentation searchable
Repeat your compliance process across other applications
Allows new team members to be productive more quickly
Allows you to scale the team
Case study: Software firm passes EY’s SOX audit test
This software firm was looking to its next phase of growth. The team realized that SOX compliance would be difficult to achieve given their current process, which was largely manual, and involved only a ticketing system that lacked documentation. In particular:
•
Its process wouldn’t scale. Administrators had to document that they were going to make a change, make the change, and return to document that they’d made the change.
•
The record wasn’t searchable. Different people documented things using different conventions.
•
The record wasn’t complete. In some instances, they couldn’t tell which configuration changes occurred.
•
It created potential for human error. If someone didn’t document properly, it wasn’t possible to understand where changes originated.
After a short evaluation, the team selected Salto and launched a project. The client’s team and Salto’s team worked together to rethink its compliance needs, under- stand its data, and set about automating the process and instituting better controls.
Together, the two teams:
•
Connected a new Salto workplace to the company’s NetSuite production environment
•
Created a GitHub repository for versioning and connected it to the workspace
•
Devised a process to allow employees to access Salto capabilities, but continue working in their NetSuite environment, which they were already used to
With the solution up and running, the team was able to:
•
Fetch their NetSuite configuration into the Salto workspace
•
Review the changes
•
Identify and classify the changes to the relevant business requests
•
Connect those requests to their respective Jira tickets
•
Gather them into a single Git commit
•
Push that commit to their GitHub repository for versioning control
Outcome: The firm sailed through EY’s SOX pre- audit process, in addition to saving a significant amount of ongoing time, at not having to manually search through NetSuite.
•
Saved a significant amount of operations time and resources
•
Lowered their risk of an audit failure Collaborated better internally, creating an orderly and transparent environment
•
Increased team confidence about handling surprise audits
Regulators tend to be heavy on demands but light on guidance. That creates an imperative for you to adapt, and to have as much visibility into your financial systems as possible.
As near-complete visibility becomes the norm in other systems, regulators will continue to demand it in Net- Suite. And like NetSuite tells its customers, sometimes it takes a trusted third party to make that happen.
With Salto, companies create a layer of observability and structure over NetSuite. This allows them to docu- ment, conduct impact analysis, identify gaps, get alerts, work across workspaces, and standardize operations in a way that satisfies auditors. And as things change further—as they inevitably will—you’ll be ready.
