NetSuite: Overview of the Access Model

NetSuite’s access model is designed to control not just who can get into the system, but exactly what they can do once they’re there. At the highest level, every user is represented by a User Account, provisioned through the Employee Record. Access is governed by Roles, which act as permission bundles and can be assigned in multiples to the same user. Each role contains a set of Permissions—NetSuite’s version of security objects—that grant access to specific records, transactions, settings, preferences, data, and features.

NetSuite Access Model

NetSuite’s access model is built on a layered security design that governs who can log in, what they can do, and how granularly they can interact with data. The five core layers are:

1. User Accounts – Each individual identity in the system, provisioned through the Employee Record.
2. Roles – Bundles of permissions and access levels to such permissions that define functional access; each user may be assigned multiple roles.
3. Permissions / Security Objects – Discrete functions, privileges, and menu options granted to a role (e.g., access to transactions, reports, configuration pages, records). Permissions can also be directly provisioned to an employee record / user account through what NetSuite calls Global Permissions.
4. Permission Access Levels – The degree of authority granted for each permission:
   • VIEW – User has access to view existing files only. The user cannot create new, edit existing, or delete existing files.
   • CREATE – User can create new and view existing files. The user cannot edit or delete existing files.
   • EDIT – User has access to create new, view existing, and edit existing files. The user cannot delete existing files.
   • FULL – User has access to create new files and view, edit, and delete existing files
5. Granular Data Controls – Field-level and data-level restrictions, including inherent controls for high-risk fields (e.g., to view social security numbers users need access to the Employee Social Security Numbers permission) and configurable security for custom fields.

Permissions aren’t just on-or-off. They’re assigned an Access Level that defines the depth of control: View, Create, Edit, or Full. This structure means two users could both have “Vendor Record” permission, but one might only view vendors while another can create and edit them. Beyond this, NetSuite provides Granular Data Controls, allowing administrators to restrict access to specific fields—especially high-risk ones like Social Security Numbers—or to secure custom fields.

For custom fields, access can be defined by role, department, or subsidiary, and set to:

• Edit – Field visible and editable.
• View – Field visible but not editable.
• Run – Field visible in reports/search results only.
• None – Field completely hidden.

These settings define how fields are accessed both on the record and in searches/reports.

Compliance Requirements

This layered security access model aligns closely with compliance requirements such as SOX, NIST 800-53, and ISO 27001, all of which emphasize least-privilege access, documented role design, and segregation of duties. As with any ERP, however, its effectiveness depends entirely on how it’s implemented. Overly broad roles can grant far more access than a user needs, field-level restrictions can be overlooked, and missing data filters can allow cross-entity or cross-subsidiary activity that should be restricted. While NetSuite’s security model is straightforward and user-friendly, many of its standard roles contain embedded sensitive access risks and SoD risks within the roles themselves that don’t align with the role’s intended purpose—making them risky to deploy without modification.

Addressing Access Controls in NetSuite

To address these challenges, organizations should implement custom, well-defined roles that grant only the access necessary for a user to perform their job—no more, no less. Direct permission assignments through Global Permissions should be avoided, and quarterly User Access Reviews should be performed to validate ongoing appropriateness of access. When properly designed and maintained, NetSuite’s access model enables administrators to exercise precise control while giving auditors a fairly clear framework to confirm that least-privilege and SoD principles are being upheld.

Security can be further strengthened by implementing a granular sensitive-access and SoD risk ruleset and running periodic assessments—either through an assessment provider like ERP Risk Advisors or through GRC software—against it. Solutions like ERP Armor: Rules for NetSuite classify high-risk permissions, assign risk rankings, provide clear functional descriptions, and make them reportable at both the user and role level. For example, a SOX effective ruleset will scope privileged access like maintain supplier banking data, configuring workflows, and approving high-risk transactions. This gives process owners actionable insight to make informed access decisions and target remediation where it matters most. Effective rulesets also will scope critical and high SoD risks across all key business functions—both within individual roles and across multiple roles—in a way that is easy to review, track, and resolve, enabling faster remediation and a stronger overall ERP security posture.

If you would like to here more about our ERP Armor: Rules for NetSuite, ERP Armor: Assessments, or would just like our opinion on good GRC compliance software, please contact us at support@erpra.net.