User & Role Security Guide
Comprehensive guide to NetSuite security: role design, permissions, segregation of duties, authentication, and audit compliance.
Security Fundamentals
NetSuite uses Role-Based Access Control (RBAC) to govern what users can see and do. Proper security configuration protects sensitive data, prevents fraud, and ensures regulatory compliance.
Three Pillars of NetSuite Security
Least Privilege
Grant users only the minimum permissions necessary to perform their job functions. Nothing more, nothing less.
Segregation of Duties
Divide critical tasks among multiple people so no single user can complete a fraudulent transaction alone.
Clear Documentation
Maintain documented policies for role assignments, access reviews, and permission changes.
NetSuite Permission Statistics
Understanding the scale of NetSuite's permission system:
| Category | Count | Notes |
|---|---|---|
| Distinct Permissions | 636+ | Across all functional areas |
| Tasks/Records/Searches | 4,923+ | Controlled by those permissions |
| Standard Roles | 40+ | Built-in by NetSuite |
| Permission Levels | 5 | None, View, Create, Edit, Full |
Never assign the Administrator or Full Access role "just to get things working." Never copy the Administrator role. These shortcuts create long-term security risks and compliance failures.
Role Architecture
Every NetSuite user requires at least one role to access the system. Roles define what records users can see, what actions they can take, and what reports they can run.
Role Types
| Type | Description | Best Practice |
|---|---|---|
| Administrator | Full system access, cannot be modified | Limit to 2-3 trusted users maximum |
| Standard Roles | Pre-built by NetSuite (A/R Clerk, Sales Rep, etc.) | Use as templates only, never assign directly |
| Custom Roles | Created by your organization | Preferred for all non-admin users |
| Center Roles | Simplified UI with specific center access | Good for external users or limited functions |
Key Standard Roles (Reference Only)
A/P Clerk
Vendor bills, payments, expense reports. No vendor master access.
A/R Clerk
Customer payments, deposits, credit memos. No customer master access.
Sales Representative
Opportunities, quotes, sales orders. Own records only by default.
Warehouse Manager
Inventory, fulfillments, receipts. No financial data.
2024/2025 New Standard Roles
- CRM Role (2024.2): Sales, CPQ, marketing, support activities
- NetSuite Support Center: Special role for accessing support resources
With the exception of Administrator and NetSuite Support Center, never assign standard roles directly to users. Clone them first, then customize permissions to match your organization's needs.
Permission Categories
NetSuite permissions are organized into categories. Understanding these categories helps you efficiently configure roles.
Permission Levels
| Level | Description | Use Case |
|---|---|---|
| None | No access to the record/feature | Explicitly block access |
| View | Read-only access | Auditors, reporting users |
| Create | Can create new records | Data entry roles |
| Edit | Can modify existing records | Standard operational roles |
| Full | Create, edit, and delete | Power users, supervisors |
Major Permission Categories
Path: Setup > Users/Roles > Manage Roles > [Role] > Permissions subtab
High-Risk Permissions
These permissions require extra scrutiny and should be granted sparingly:
| Permission | Risk | Mitigation |
|---|---|---|
| Vendor (Full) | Create fake vendors for fraudulent payments | Separate from Check/Payment permissions |
| Customer (Full) + Credit Memo | Create fake customers and issue credits | Separate customer master from A/R transactions |
| Make Journal + Approve Journal | Create and approve own journal entries | Never combine on single role |
| Override Period Restrictions | Post to closed periods | Controller/CFO only |
| Manage Roles | Grant self elevated permissions | Administrator only |
| Delete All Data | Permanent data destruction | Never grant |
Custom Role Design
Well-designed custom roles are the foundation of NetSuite security. Follow these patterns to create maintainable, secure role structures.
Role Naming Convention
Use consistent naming that explains the role at a glance:
/* Recommended Naming Pattern */
[PREFIX]_[DEPARTMENT]_[FUNCTION]_[MODIFIER]
/* Examples */
ACME_FIN_AP_Clerk // Finance AP Clerk
ACME_FIN_AP_Manager // Finance AP Manager
ACME_SALES_Rep // Sales Representative
ACME_SALES_Manager // Sales Manager
ACME_WH_Fulfillment // Warehouse Fulfillment
ACME_FIN_Controller // Finance Controller
ACME_AUDIT_ViewOnly // Auditor View Only
Creating a Custom Role
Path: Setup > Users/Roles > Manage Roles > New (or duplicate existing)
- Start with standard role or blank. Duplicate the closest standard role as a starting point, or start from blank for maximum control.
- Set role name and ID. Use your naming convention. Internal ID should be lowercase with underscores.
- Configure Permissions tab. Work through each category methodically: Transactions, Lists, Reports, Setup, Custom.
- Set Subsidiaries (OneWorld). Restrict to specific subsidiaries on the Subsidiaries subtab.
- Configure Restrictions. Set record-level restrictions (e.g., own records only) on Employee Restrictions subtab.
- Test thoroughly. Log in as a test user with only this role and verify access matches expectations.
Common Role Templates
AP Specialist
- Vendor Bill: Edit
- Vendor Payment: Create
- Vendor: View only
- Purchase Order: View
Vendor Manager
- Vendor: Full
- Vendor Bill: View
- Vendor Payment: None
- Banking: None
AR Specialist
- Customer Payment: Edit
- Invoice: View
- Credit Memo: View
- Customer: View only
Customer Manager
- Customer: Full
- Credit Memo: None
- Customer Refund: None
- Banking: None
Employee Restrictions
Limit what records a user can see based on relationships:
| Restriction | Effect |
|---|---|
| Own Records Only | User sees only records they created or are assigned to |
| Department | User sees records in their department |
| Location | User sees records at their location |
| Class | User sees records with their class |
| Subsidiary (OneWorld) | User sees records in assigned subsidiaries |
Segregation of Duties (SOD)
Segregation of duties prevents fraud by ensuring no single person can complete a fraudulent transaction alone. NetSuite does not enforce SOD by default—you must design it into your roles.
The Two-Person Rule
Critical processes should require 2-3 different people to complete. This can be achieved through:
- Role separation: Different roles for different steps
- Approval workflows: Secondary review/approval required
- Restricted access: Physical controls (check signing)
Common SOD Violations to Avoid
SOD-Compliant Role Structure Example
Procure-to-Pay (P2P) process split across roles:
| Role | Permissions | Cannot Do |
|---|---|---|
| Vendor Manager | Vendor: Full, Banking details | Create bills, payments |
| Purchasing Agent | PO: Full, Requisitions | Receive goods, pay vendors |
| Receiving Clerk | Item Receipt: Full | Create POs, pay vendors |
| AP Specialist | Vendor Bill: Edit, Payment: Create | Create vendors, approve payments |
| AP Manager | Payment Approval, Check Signing | Create vendors, enter bills |
SOD Analysis Using Saved Searches
Create these searches to identify SOD violations:
/* Search 1: Users and Their Roles */
Type: Employee
Results: Name, Role, Email
Export: Excel for analysis
/* Search 2: Role Permissions */
Type: Role
Results: Name, Permission, Level
Export: Excel, pivot by permission
/* Cross-reference to find users with conflicting permissions */
Consider third-party SuiteApps like Fastpath Assure or SafePaas for automated SOD analysis. These tools continuously monitor for violations and can reduce SOD audit time by up to 80%.
Authentication & MFA
Strong authentication prevents unauthorized access. NetSuite provides multiple authentication options including Multi-Factor Authentication (MFA).
Password Policies
Path: Setup > Company > General Preferences > Password Rules
| Policy Level | Requirements |
|---|---|
| Strong (Default) | 10+ characters, 3 of 4 types (upper, lower, number, special) |
| Medium | 8+ characters, 2 of 4 types |
| Weak | 6+ characters, no complexity requirements |
Multi-Factor Authentication (MFA)
MFA adds a verification code requirement beyond username/password:
- Required by default: Administrator, Full Access roles
- Configurable: Can be enabled for any role
- Methods: Authenticator app, SMS, email
Enabling MFA for a Role
- Navigate to role: Setup > Users/Roles > Manage Roles > [Role]
- Check "Two-Factor Authentication Required" on the role setup page.
- Save the role. Users will be prompted to set up MFA on next login.
Single Sign-On (SSO) Options
| Method | Use Case |
|---|---|
| SAML 2.0 | Enterprise SSO with identity providers (Okta, Azure AD) |
| OAuth 2.0 | Application integrations, API access |
| Token-Based Auth (TBA) | Script/integration authentication without user login |
Enable MFA for all users with access to sensitive data (financial, HR, customer PII). The minor inconvenience is far outweighed by the security benefit.
User Lifecycle Management
Properly managing user access from onboarding through offboarding prevents unauthorized access and maintains compliance.
User Onboarding Checklist
- Create employee record with correct supervisor, department, location
- Assign appropriate role(s) based on job function
- Set subsidiary access (OneWorld)
- Configure employee restrictions if needed
- Send password setup email
- Document role assignment with business justification
- Train user on system and security policies
Access Change Process
When an employee changes roles or responsibilities:
- Receive approved request from employee's manager documenting the change needed.
- Review SOD implications of adding new permissions to existing roles.
- Update role assignment - add new role and/or remove old role as appropriate.
- Document the change including date, approver, and business justification.
- Notify user of access changes and any training needed.
User Offboarding Checklist
- Receive termination notice from HR
- Remove all roles from employee record immediately
- Inactivate employee record (do not delete)
- Revoke any OAuth tokens/API credentials
- Reset password to random string
- Review recent activity for anomalies
- Transfer ownership of records/dashboards if needed
- Document termination date and who processed
Contractor/Temporary Access
Set calendar reminders to review and remove contractor access when projects end. Temporary access that becomes permanent is a common security gap.
Auditing & Monitoring
Regular auditing detects security issues before they become breaches. NetSuite provides built-in tools for monitoring user activity and access.
Key Audit Tools
| Tool | Path | Use |
|---|---|---|
| Login Audit Trail | Setup > Users > View User Login Audit Trail | Track who logged in, when, from where |
| System Notes | Record > System Information subtab | Track changes to any record |
| Audit Log | Setup > Users > View Audit Trail | Track setup changes |
| Search Audit | Reports > Saved Searches | Track search execution |
Recommended Monitoring Searches
Last Login Report
Identify inactive users who still have access. Users not logged in for 90+ days should be reviewed.
Role Assignment Changes
Track when roles are added or removed from users. Review for unauthorized changes.
Failed Login Attempts
Multiple failed logins may indicate attempted unauthorized access.
Admin Activity Log
Track all actions taken by Administrator role users.
Quarterly Access Review Process
- Export user-role matrix using saved search. Include: User, Role, Department, Last Login.
- Send to department managers for review. Ask: "Do these users need this access for their current job?"
- Collect attestations confirming access is appropriate or identifying changes needed.
- Remove unauthorized access identified during review.
- Document completion for audit trail.
Identifying Unused Roles
Search Login Audit Trail for all logins in the last 6 months. Any role not appearing in this list is unused and should be reviewed for deactivation.
/* Find unused roles */
SELECT Role
FROM LoginAuditTrail
WHERE LoginDate > DATEADD(month, -6, GETDATE())
GROUP BY Role
-- Compare against all active roles
-- Roles not in results = unused
Compliance Readiness
Proper security configuration supports compliance with SOX, GDPR, HIPAA, and other regulatory requirements.
SOX Compliance Considerations
While SOD is not legally required for private companies, SOX-compliant controls are essential for public companies:
- Documented policies for user access management
- Quarterly access reviews with management attestation
- Segregation of duties in financial processes
- Audit trail for all financial transactions
- Change management procedures for role modifications
GDPR/Privacy Considerations
- Limit access to personal data (customer, employee) to business need
- Track who accessed personal data using audit logs
- Support right-to-access and right-to-deletion requests
- Document data retention and deletion procedures
Audit Preparation Checklist
- Document all custom roles and their business purpose
- Maintain user access request/approval records
- Export quarterly access review attestations
- Document SOD analysis and any accepted risks
- Prepare login audit trail exports for requested period
- Document password and MFA policies
- List all users with Administrator or elevated access
- Document termination/offboarding procedures
- Fastpath Assure: Automated SOD analysis and continuous monitoring
- SafePaas: Real-time risk analytics and compliance reporting
- Netwrix: Access governance and audit reporting
Troubleshooting
Common permission issues and their solutions.
Common Issues & Solutions
| Issue | Likely Cause | Solution |
|---|---|---|
| User can't see a record type | Missing List permission | Add View or higher permission for that list |
| User can't create transactions | Missing Transaction permission | Add Create permission for that transaction |
| User sees blank dropdown | No access to related list | Add View permission for the dropdown's source list |
| User can't see specific records | Employee restriction | Review department/location/subsidiary restrictions |
| User can't run a report | Missing Report permission | Add View permission for that report category |
| User can't access a center | Role doesn't include center | Add center to role or use center-specific role |
| Saved search not visible | Search audience restriction | Edit search audience to include user's role |
| Button missing on form | Role doesn't have transaction permission | Check transaction permissions for that action |
Permission Debugging Steps
- Identify the specific action the user is trying to perform that's failing.
- Review role permissions for that transaction type, list, or report category.
- Check employee restrictions (department, location, subsidiary) that might limit visibility.
- Test with Administrator to confirm the feature works correctly (rules out data issues).
- Add permission incrementally and test after each change to identify the minimum required permission.
Permission Reference Resources
- Standard Roles Permissions Table - Oracle documentation
- NetSuite Roles Overview - Oracle documentation
Create a test employee record with the role in question. Use "Log in as" (if you have Administrator access) or ask the user to share their screen to see exactly what they see.