One of the great parts about SAAS (software as a service) products is that the burden of managing the hardware and software is abstracted away from the consumer. With NetSuite, it is now possible for an organization to implement an ERP system without worrying about standing up new servers, databases, or managing the security or compliance requirements of those systems. Part of NetSuite’s value-add is that they will take care of those requirements and provide evidence in the form of various reports (SOC, PCI, etc.) that outline the controls in place to meet those requirements. However, it is important to understand, that even with a SAAS product, there will always remain elements of NetSuite security that are the responsibility of the consumer. The purpose of this blog post is to help identify some key complimentary user entity controls that exist in NetSuite and provide a high level overview of why they might be important to your organization.
We’ll start with logical security, where the control objective is to provide reasonable assurance that logical access to data, applications, system data, and networks is restricted to properly authorized individuals. Furthermore, that security violations are identified, followed up on, and resolved on a timely basis. At a high level, this means ensuring that your NetSuite user access is properly defined and monitored, while risks are mitigated.
Properly defining user access starts with the design of security roles. Best practice dictates that roles should be focused on a specific job function and include the least level of access required, limiting errors and fraud. However, there is always a tradeoff between security and efficiency. While few roles with broad permission sets may make users more productive, it also increases risk. Roles should be assigned to users with a consistent, well documented process that includes the request for role assignment, approval, actual role assignment, and modifications to role assignments.
Once user access is defined, it is critical that each organization periodically reviews user access to validate correct role setup and role assignment. This is also a good time to check for orphaned users and pay special attention to any users with the Administrator or Full Access role. Best practice is to maintain at least two users with the Administrator role so they can cover for each other in absences. Any additional Administrators should be carefully considered on a case by case basis. User access reviews can be accomplished via saved searches, but it is important to note that the Administrator and Full Access roles do not show up in user access reports in NetSuite.
The next step is to assess and manage the risk inherent in user access. Segregation of duties (SoD) is a basic internal control that attempts to ensure that no single individual has the authority to execute two or more conflicting, sensitive transactions with the potential to impact financial statements. SoD typically consists of a three step process:
- Define conflicts – which processes / permissions can negatively impact your organization’s financials if abused (e.g.: a user with the ability to both create and pay a vendor creates a risk of fraudulent payments designed to benefit that user).
- Identify risk – where do conflicts exist in user access? It is important to consider that multiple roles and multiple subsidiaries can be assigned to users.
- Document / apply mitigating controls – map existing controls to the risks identified in step two and identify where gaps still exist that may require implementation of additional controls.
It is important to take a risk based approach to SoD and remember that the goal is not zero conflicts but rather that each conflict has been considered and mapped accordingly to mitigating controls.
Software Development Life-Cycle (SDLC)
The goal of a software development life-cycle is to provide reasonable assurance that changes to production application systems and programs are properly authorized, tested, approved, implemented, and documented. In the world of NetSuite, this is not referring to core application code as that is managed by NetSuite themselves with evidence provided in the form of a SOC 1 report. Instead, consumers need to focus on the components of NetSuite that are customizable by consumers: SuiteBuilder objects like custom records, forms, transactions, etc. and SuiteCloud objects like scripts and workflows. These objects can have a large impact on how data moves through your NetSuite account and it is important that proper controls are in place to govern changes.
There are entire books written on the topic of SDLC and we will not go into that level of detail here. Instead, we want to focus on some key areas of consideration and how they may apply to NetSuite.
Segregation of Duties (SoD)
There are several roles throughout the SDLC process from the developers who create the custom objects and scripts; to the quality assurance and user acceptance teams that test functionality; and finally the team responsible for deployment of customizations between the various environments. SoD here means aligning these various teams not only to the permissions necessary to complete their jobs, but also to the proper environments. A typical approach is below:
Developers – access to development or sandbox accounts used specifically for development projects along with source control repository systems. Permissions may need to be elevated for developers in these accounts in order to complete the requirements for a given project, but this risk is mitigated by the accounts being isolated from testing or production accounts.
Quality Assurance (QA) / User Acceptance Testing (UAT) – access to sandbox accounts used specifically for quality assurance or user acceptance testing. Similar to developers, QA may need elevated permissions to fully test all business processes while UAT should consist of users impacted by the changes with access to the necessary job functions.
Deployment Admins – access to development / sandbox accounts used for development or testing in addition to production accounts. Deployment admins will need the appropriate permissions to allow them to promote customizations between the various accounts, which can vary drastically depending on the SDLC approach taken.
A standardized change management process is a great way to reduce the risk associated with changes to production systems. The process should be well documented, auditable, and rigorously followed for all changes, regardless of size. A typical change management process is below:
Initiation – documentation of change request in a standardized change request form. Change request is then routed for approval to one or more users or groups to authorize changes prior to beginning development.
Development – using requirements outlined in change request, development teams make necessary changes in a development / sandbox account and ensure source code is checked into proper source control repositories. Check-ins are reviewed prior to committing to source control repositories.
Quality Assurance (QA) / User Acceptance Testing (UAT) – once development has been completed and approved by development team, deployment teams promote changes to test accounts and QA / UAT teams test changes to validate proper functionality as required by change request. Testing artifacts such as test plans and test cases should be documented by QA / UAT teams and attached to change requests.
Deployment – once the changes have been approved by QA / UAT, deployment teams promote the changes to production during a pre-defined release window to ensure there are no conflicts (SuiteApp updates / installs, NetSuite core updates, etc.) during the deployment process. The change request form is then updated to indicate when the changes were deployed and who deployed them.
Audit – the last step is to audit changes to production to ensure that the only components changed as a result of deployment were those expected and indicated on the change request. This can be accomplished via audit trails, system notes, history tabs, and other analytics within NetSuite.
Controls around transaction processing carry the objective of providing reasonable assurance that transactions posted in the system are accurate, valid, and complete. To determine the level of controls, a risk based approach should be taken to identify where it makes sense to implement automated or manual controls, prevent or detect controls, or a combination of both.
Transactions include three potential areas where controls can be implemented: input, processing, and output. Controls should align with one or more of the objectives to ensure accuracy, validity, or completeness.
Input controls should focus on how transactions are entered into the system and what may impact how data is collected for a given transaction. Considerations include:
- Access controls – what users have privileges to enter specific transactions?
- Dual authorizations – multiple users required to approve transactions prior to posting
- Configuration – system configuration can determine when / how transactions are entered (eg: credit limits, etc)
- Data verification – master data changes impact on transactions, critical data may require exception-based alerts
Processing / Output
Processing / output controls should focus on the impact transactions have on financials. Considerations include:
- Reporting / review – saved searches, system reports, and audit trails
- Data analytics – diagnostic tools to check for anomalies such as unusual dates, times, amounts, users, etc.
A Shared Responsibility
Clearly, implementation of controls is a shared responsibility between cloud service providers and consumers. It is important to understand where NetSuite’s responsibility ends and yours begins and to consider where internal controls may be necessary due to compliance requirements.
For more on Netsuite Nartive controls, join the webinar on Feb. 16th.