Your auditor found 47 users with Administrator access. Finance can edit closed periods. Sales reps can delete transactions.
Nobody meant for it to happen. A former employee needed temporary GL access for a project. An approver was out sick so someone got "full access for now." A consultant needed admin rights during implementation and nobody ever removed them.
That's permission creep -- and it's a compliance risk, a fraud risk, and an operational risk sitting in every NetSuite environment that's been live for more than six months.
This guide shows you how to clean up NetSuite roles and permissions using a systematic audit process. No breaking workflows. No locking people out of systems they need. No approvals grinding to a halt because someone lost the wrong permission at the wrong time.
We've run this process across 60+ NetSuite environments. The organizations that complete it cut high-risk access by 60-80% without a single escalation from operations.
How Do Roles and Permissions Work in NetSuite?
NetSuite's access control works through roles. Users don't get individual permissions -- they get assigned roles, and roles contain permission bundles.
Standard roles come with NetSuite. Accountant, Sales Manager, Customer Center, Employee Center. These cover common job functions but rarely match real workflows perfectly.
Custom roles are roles you build. Most organizations run 15-30 custom roles tailored to specific job functions, departments, or processes.
Permission levels control what users can do: View, Create, Edit, Full (which includes Delete). Different permissions apply to records (Sales Orders, Invoices), reports (saved searches), and setup (customizations, workflows).
The problem starts when roles accumulate permissions they don't need. A role created for "temporary GL access" becomes permanent. An "Accountant - Extended" role gets cloned into "Accountant - Super Extended" which becomes the new default.
Quick check: pull the Roles report (Setup > Users/Roles > Manage Roles > Reports). Count how many roles contain "temp," "old," "backup," or "admin" in the name. If the answer is more than three, you've got cleanup to do.
Why permission creep happens in every NetSuite environment
Nobody wakes up planning to give 50 people Administrator access. It accumulates through three patterns:
The result: users have far broader access than their job requires. That's the opposite of least privilege -- and it's what auditors flag first.
What Is Least Privilege in NetSuite?
Least privilege means users get the minimum permissions required to do their job. Nothing more.
An AP clerk needs to create and edit bills. They don't need to delete them. They don't need to edit closed periods. They don't need to modify GL accounts or approve journal entries.
A sales rep needs to create quotes and sales orders. They don't need Full access to customer records (which includes Delete). They don't need to see commission reports for other reps. They don't need setup permissions.
Least privilege isn't about being restrictive. It's about reducing the blast radius when something goes wrong.
If an AP clerk's credentials get compromised, least privilege means the attacker can create bills but can't delete transaction history or modify closed periods. If a sales rep accidentally deletes a customer record, least privilege means it doesn't happen because they never had Delete permission in the first place.
The three access principles that matter for NetSuite security
1. Least privilege -- Users get only the permissions their job requires, nothing extra.
2. Segregation of duties -- No single user can execute a complete sensitive process end-to-end. The person who creates journal entries can't approve them. The person who processes refunds can't also delete the audit trail.
3. Regular review -- Access gets reviewed quarterly. Permissions that made sense six months ago might not make sense now. People change roles, leave the company, or shift responsibilities.
These aren't theoretical concepts. They're what external auditors check during SOX compliance reviews, what internal audit flags during controls testing, and what forensic accountants look for when investigating fraud.
How to Audit NetSuite Roles and Permissions Safely
The goal isn't to lock everyone out. It's to reduce risk without breaking workflows.
Here's the systematic process.
Step 1: Document current role assignments (baseline)
Before changing anything, know what you have.
Report to run: Setup > Users/Roles > Manage Roles > User Access
This shows every user, every role assigned to them, and when the role was granted.
Export it. This is your baseline. If something breaks after you make changes, this document shows you exactly what access the user had before.
What to capture:
- User name and email
- All roles assigned
- Date role was granted
- User's department and supervisor
- Last login date (indicates active vs inactive users)
Look for patterns. Users with 3+ roles assigned. Roles containing "admin," "temp," or "backup" in the name. Users who haven't logged in for 90+ days but still have access.
Step 2: Map roles to job functions (what they should have)
Pull your org chart. List every job function: AP Clerk, AR Specialist, Sales Rep, Warehouse Manager, Financial Controller.
For each function, document what they need to do their job:
- Which record types do they create? (Bills, Sales Orders, Item Receipts)
- Which record types do they need to view but not edit? (Purchase Orders, Invoices)
- Which reports do they run?
- Which setup areas do they access? (Usually none for most operational users)
This becomes your target state. The permissions each role should have based on what the job actually requires.
Common functions and their minimum permissions:
These are starting points. Your workflows might differ. The goal is documenting what "correct" looks like before you start removing permissions.
Step 3: Identify high-risk permissions (what to fix first)
Not all permissions carry equal risk. Some are dangerous in the wrong hands.
High-risk permissions to audit first:
Administrator-level access -- Full control over customizations, integrations, user access, and all records. Should be limited to 2-3 people maximum. We've seen environments with 40+ admin users. That's a control failure.
Edit closed periods -- Allows modifying transactions in locked accounting periods. This bypasses period close controls and creates audit trail gaps. Only Controllers and CFOs should have this.
Delete transactions -- Permanently removes records from NetSuite. For most users, Edit is sufficient. Delete should be restricted or require approval workflows.
GL posting permissions -- Creating journal entries, modifying GL accounts, posting to restricted accounts. This is segregation of duties territory -- separate who creates from who approves.
Setup and customization -- Permissions to modify workflows, scripts, roles, integrations. Operational users don't need this. Most admins don't either.
Run a report showing which users have these permissions. That's your priority cleanup list.
Step 4: Test permission changes in a non-production environment first
If you have a NetSuite sandbox, use it. Clone your production roles and test changes there before touching production.
Test specifically:
- Can users still create the records they need to create?
- Do approval workflows still work?
- Can users access the reports they run daily?
- Are there any saved searches or workflows that break when permissions change?
The most common mistake: removing a permission that seems unnecessary but actually powers a background workflow or approval routing. Testing catches this before users do.
If you don't have a sandbox, start with low-impact roles. Test on a single user in a non-critical role. Verify they can still do their job. Then expand.
Step 5: Remove one permission category at a time
Don't strip 15 permissions from a role simultaneously. Remove one category per week and monitor for issues.
Week 1: Remove Delete permissions from operational roles Week 2: Remove Setup/Customization permissions from non-admin roles
Week 3: Restrict Edit Closed Period to Controllers only Week 4: Review and reduce Administrator access
This gives you time to catch workflow breaks before they compound. It gives users time to report issues before you move to the next category.
Step 6: Implement approval workflows for high-risk actions
Some permissions can't be removed entirely because users occasionally need them. For these, replace blanket permissions with approval workflows.
Example: Sales reps occasionally need to delete a quote. Instead of giving all reps Delete permission, build a workflow:
- Rep requests deletion via a custom form
- Sales manager receives email approval request
- If approved, manager (who has Delete permission) completes the action
Example: AP occasionally needs to edit a bill in a closed period. Instead of giving AP clerks Edit Closed Period permission:
- Clerk documents the reason and requests access
- Controller reviews and grants temporary access for 24 hours
- Automated workflow removes the permission after the window expires
This maintains least privilege while handling legitimate exceptions.
Step 7: Document role definitions and review quarterly
Create a role definition document that maps each custom role to:
- Job functions that should receive this role
- Specific permissions included and why
- High-risk permissions and their justification
- Approval required for assignment
- Review frequency (quarterly for high-risk roles, annually for standard)
Quarterly review process:
- Pull the User Access report
- For each user with high-risk permissions, verify they still need them
- Check for users who changed roles -- do they still need their old access?
- Identify inactive users (no login for 90+ days) and disable their access
- Review any new roles created since last quarter -- do they follow least privilege?
This becomes your ongoing NetSuite access control governance. Most organizations skip this step. That's why permission creep comes back six months after cleanup.
Common NetSuite Permission Issues and How to Fix Them
Too many admin users
The problem: 30+ users have Administrator access. Most don't need it.
The fix: Create tiered admin roles:
- Full Administrator (2-3 people) -- Complete system access
- Finance Administrator (Controllers) -- GL, reports, period close; no customization or user management
- Operations Administrator (IT/Operations leads) -- Workflows, saved searches, integrations; no financial posting
- Support Administrator (Help desk) -- View-only access to troubleshoot user issues
Migrate users to the appropriate tier. Most "admins" only need Finance or Operations admin, not full.
Users can edit closed periods
The problem: 15 users can modify transactions in locked periods, creating compliance risk.
The fix:
- Identify who actually needs this (usually just Controller and CFO)
- Create a custom role with Edit Closed Period permission
- Assign only to those who need it
- For everyone else who occasionally needs it, build an approval workflow with time-limited access
This is usually an auditor's first finding. Fixing it demonstrates controls exist.
Approvals bypassed because approvers have too much access
The problem: Purchase requisition approval workflow routes to a manager, but the manager has Full access to Purchase Orders, so they can bypass their own approval.
The fix: Separate the approver role from the full access role. The manager who approves requisitions shouldn't have permission to create POs directly. Someone else with PO creation rights processes approved requisitions.
This is segregation of duties. It prevents a single person from both approving spend and executing it.
Permissions too broad for the job function
The problem: Sales reps have Full access to Customer records (which includes Delete). AR clerks have Edit access to GL accounts.
The fix: Audit each role's permissions against actual job requirements:
- Sales reps need Create and Edit for Customers -- not Full
- AR clerks need Create and Edit for Invoices -- not GL account modification
- Warehouse users need View access to Items -- not Edit (which includes changing costs)
Most roles accumulate permissions over time that made sense once but don't anymore.
No documentation on who should have what access
The problem: When someone asks for access, there's no standard to compare against. Decisions are made ad-hoc.
The fix: Create a role assignment matrix:
New hires get the standard role package for their title. Deviations require documented approval. This prevents permission creep from starting.
The Stockton10 Approach: NetSuite Security Best Practices That Work
Why most NetSuite security audits fail to stick
Organizations run a security review, clean up roles, document everything. Six months later, permission creep is back.
Three patterns explain why:
No ongoing governance -- The cleanup was a project. Nobody owns maintaining it. New users get whatever access the last person in their role had, which might have been excessive.
Approval process doesn't exist -- There's no formal process for granting exceptions. Managers say "just give them access" because there's no documented alternative.
Role definitions aren't maintained -- New roles get created. Existing roles get modified. Nobody updates the documentation, so within months nobody knows what's supposed to be in each role.
NetSuite access control isn't a one-time cleanup. It's ongoing governance.
How Stockton10 implements sustainable access governance
Our approach across every NetSuite security audit services engagement focuses on building governance that survives after we leave:
Role-based access with documented standards -- Every role has a definition document. Job functions map to specific role assignments. Exceptions require documented business justification and time limits.
Quarterly access review built into the calendar -- Not "we should review access sometime." A scheduled process with assigned owners, review templates, and sign-off requirements.
Approval workflows for exceptions -- Temporary access needs, elevated permissions, cross-functional access -- all route through documented approval workflows rather than email requests.
Separation between operational and administrative access -- Finance admins don't customize the system. System admins don't post to GL. Segregation of duties is built into role design, not enforced through policy alone.
For more on how this applies across NetSuite compliance consulting post go-live, see our post-implementation guide.
What ongoing NetSuite access governance looks like
Monthly: New user access requests reviewed against role assignment matrix. Any deviations flagged for approval.
Quarterly: Full user access audit. Every user with admin-level permissions, Edit Closed Period, or Full access to sensitive records gets reviewed. Inactive users disabled. Role changes documented.
After any organizational change: Department reorganizations, acquisitions, leadership changes -- all trigger access reviews for affected users.
Annual: Complete role permission audit. Each custom role's permission set reviewed against current job requirements. Unused permissions removed. Role definitions updated.
This cadence prevents permission creep from restarting and maintains audit readiness year-round.
NetSuite Roles and Permissions: Reduce Risk Without Breaking Operations
The gap between NetSuite access control theory and practice isn't understanding roles and permissions. NetSuite's access model is well-documented.
The gap is systematic application of least privilege without breaking the workflows teams depend on.
Most organizations know they have too many admin users, too many people who can edit closed periods, too broad permissions on operational roles. The cleanup never happens because the risk of breaking something feels higher than the risk of leaving it alone.
That calculation is wrong. Permission creep creates compliance risk (audit findings, SOX violations), fraud risk (lack of segregation of duties), and operational risk (accidental deletions, data modifications that shouldn't happen).
Systematic cleanup -- starting with baseline documentation, testing changes before production, removing permissions one category at a time -- eliminates the breaking-workflows risk while addressing the security risk.
The seven-step process in this guide gives you the framework. Document current state, map to target state, identify high-risk permissions first, test before production, remove permissions incrementally, implement approval workflows for exceptions, maintain through quarterly reviews.
None of it requires expensive tools or consultants to execute. It requires intentional organization of NetSuite's native access control capabilities into a repeatable governance process.
Ready to clean up NetSuite roles and permissions without locking people out of systems they need?
Stockton10 provides NetSuite access review support and NetSuite managed services security governance for organizations that want sustainable access control.
Contact us to discuss your environment.
